should JSON-LD vocabulary include cardinalities?

[onthebreeze]

From Slack thread Andreas Pelekies:

And a last one (for today) - According to the Guideline Occurrences (0..1, 1..1, 0..*, ...) are defined to be represented in a specific way. E.g. it is stated that a 1..n or n..x (with x>=1) maps to a "required schema property". I cannot find anything like this in the vocab. What am I missing?

[onthebreeze]

In my view, cardinalities are an implementation construct and not a vocabulary construct. So

• the JSON-LD vocabulary should not specify them
• The API designer should specify them in whatever tool they use.
• It may be convenient if the tool did some defaulting during vocabulary import - for example
  • make all properties of classes 0..1
  • make all relationships between classes 0..*

[Fak3]

Cardinality and required fields are API and use-case specific. Maybe at some point we will discover common request\response API patterns for the vocabulary and then we can provide openapi \ json-schema \ shacl shapes for those cases and link these from the vocabulary...

[AP-G]

I do not agree. If we had some generic vocab you are right. But we do not have. The task is to provide a vocab representing the semantic reference data model achievements agreed to by many industries and countries around the world in UN/CEFACT. So removing these achievements would not fit the intended outcome. In any way you are still able - as today with XML / EDIFACT / ... - to change cardinalities in a specific context. Especially to restrict it if needed. But to achieve a new level of (semantic) interoperability the cardinalities are a must-have. Else semantic achievements are lost and the new-to-cefact-developer will not be able to create interoperable cross-industry and cross-country solutions, if he does not get CEFACT-Expert support telling him exactly the missing cardinalities etc...

Summarized the solution to add shapes for json-schema only helps if the vocab is used exactly for this purpose. But the vocab should not be limited to this solution but should be usable as it is (intended) - a vocab representing the UN/CEFACT reference data models

[onthebreeze]

Well then I think we disagree on this one. RDMs so far as I can see are almost always open with everything optional (0-1) cardinality anyway. I don't see any value in describing cardinality in a vocabulary

In any case I don't think there is any useful predicate for it. So if we did do it then it would be done highly custom thing in the CEFACT metadata part of the vocabulary

If you really insist we can put it there. But I think it's a bit useless ?

[onthebreeze]

Ok thinking about this more - IF/WHEN we add a lot more @context files for more and more specific subsets of the base BSP RDM - THEN we can probably expect many more meaningful cardinality restrictions

But @Fak3 - can you think of a way to specify cardinalities in a @context file that references a vocabulary (which I still believe should not have cardinalities)

[AP-G]

Exactly, this is why I raised issue #54 to get a better feeling/understanding for this. But I do not feel @context-expert enough to create it on my own.

[Fak3]

But @Fak3 - can you think of a way to specify cardinalities in a @context file that references a vocabulary (which I still believe should not have cardinalities)

We can use OWL vocab to annotate cardinality restrictions. See how One Record ontology uses it: https://github.com/IATA-Cargo/ONE-Record/blob/master/working_draft/ontology/IATA-1R-DM-Ontology.ttl#L3826

:Address rdf:type owl:Class ;
                 rdfs:subClassOf [ 
                                   rdf:type owl:Restriction ;
                                   owl:onProperty address:country ;
                                   owl:maxCardinality "1"^^xsd:nonNegativeInteger
                                 ] ,

[Fak3]

Alternatively we can annotate cardinalities with SHACL:

{
       "@id": "uncefact:Address",
       "@type": ["rdfs:Class", "sh:NodeShape"],
       "sh:property": {
      "sh:path": "uncefact:countryId" ,
      "sh:minCount": 1,
      "sh:maxCount": 1,
       }
}

[AP-G]

I see. Although the SHACL notation looks a little more convenient, I'd prefer OWL to stay closer to schema.org and its extensions. E.g. https://www.w3.org/ns/json-ld directly demonstrates the use of OWL as well, so it is likely to be more spread around the developers.

If we let out the typing of the cardinality (which seems to be valid and the cardinality in the UN/CEFACT scope will always be a nonNegativeInteger), it is pretty similar.

I found a nice comparison between SHACL and OWL on this topic here: https://spinrdf.org/shacl-and-owl.html. It may be useful for the complete subject including #54, as it demonstrates how to solve the described problem.

I updated your example as follows:

{
       "@id": "uncefact:Address",
       "@type": ["rdfs:Class", "owl:Class"],
       "rdfs:subClassOf": {
      "@type": "owl:Restriction",
          "owl:onProperty" : "uncefact:countryId" ,
      "owl:minCardinality": 1,
          "owl:maxCardinality": 1,
       }      
}

So, in general I would propose to leave the vocab as it is, but to add (several) context files, that

• define the renaming of basic classes
• define the cardinalities between the classes

This way the CEFACT-definitions are published, but usable in the specific context. The question that is left from my side is how to deal with the combination of several context files if they are mutually exclusive (overlapping different definitions). But maybe this should be discussed in #54 ...