Decide how to deal with the cardinality of properties

[manuelfiorelli]

The RDF data model is quite flexible with respect to the cardinality of properties, since you can assert any number of triples for a given subject using the same predicate. In JSON, on the other hand, a property should be used once, while multiple values should be managed as an array.
Therefore, the schema associated with the MOD API must define for each property whether it holds a single value or an array.

In fact, by default, JSON-LD disregards any array, assuming that their use if just to support re-use of the same property. This is shown by the following JSON-LD documents, the first with a single value, the latter with an array (with one item), which are interpreted the same:

{
  "@context": {
    "ex": "http://example.org/",
    "ex:knows": { "@type": "@id" }
  },
  "@id": "ex:bob",
  "ex:knows": "ex:alice"
}

and

{
  "@context": {
    "ex": "http://example.org/",
    "ex:knows": { "@type": "@id" }
  },
  "@id": "ex:bob",
  "ex:knows": [ "ex:alice" ]
}

The actually represent the same RDF triple:

<http://example.org/bob> <http://example.org/knows> <http://example.org/alice> .

Please note that there is a dedicated syntax to represent that the array should me modeled as an actual list in RDF (which is important to retain order):

{
  "@context": {
    "ex": "http://example.org/",
    "ex:knows": { "@type": "@id" }
  },
  "@id": "ex:bob",
  "ex:knows": {
    "@list": [ "ex:alice" ]
  }
}

The document above is interpreted as:

<http://example.org/bob> <http://example.org/knows> _:b0 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/alice> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .

Note that the use of an rdf:List can be defined once in the context, an applies regardless the fact that in JSON it is used a single value or an array:

The following document

{
  "@context": {
    "ex": "http://example.org/",
    "ex:knows": { "@type": "@id", "@container": "@list" }
  },
  "@id": "ex:bob",
  "ex:knows": [ "ex:alice" ]
}

and this one (without the array):

{
  "@context": {
    "ex": "http://example.org/",
    "ex:knows": { "@type": "@id", "@container": "@list" }
  },
  "@id": "ex:bob",
  "ex:knows": "ex:alice"
}

represent the same graph:

<http://example.org/bob> <http://example.org/knows> _:b0 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/alice> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .

[jonquet]

Pre-discussed to day in T4.2 meeting. Although MOD (GSheet spec) provides cardinalities for mod:SA object.. this has not been translated yet to the OWL file of MOD... for multiple reasons including the fact that most MOD properties are. reused from other vocabularies and are annotation properties on which cardinalities formally have no consequence...

Proposition is to ignore this aspect for the moment and let every MOD-API implementation decide what they return (array or not) based on what they have. We ack that it could decrease the impact/facility of use of the results returned by the SACs.

[manuelfiorelli]

Hi @jonquet

I agree with you that it is better not to constrain the implementers. In my understanding of JSON Schema, however, if we declare in the schema that a property has a certain type, say a string, than it would not be possible to return multiple values.