How to handle oneOf in the JSON Schema to JSON-LD context code

[BenjaminMoe]

Update JSON-LD processor to support oneOf schema functionality

[nissimsan]

What should the resulting @context look like to support this?

[OR13]

On the call, we discussed how domain and range might be relevant to oneOf and anyOf.

cc @TallTed

[nissimsan]

@TallTed , please add requirements how we can solve this

[TallTed]

@TallTed to consider and rant about rdfs:domain & rdfs:range vs schema:domainIncludes & schema:rangeIncludes and JSON-Schema's oneOf, anyOf, allOf (& not) ...

(Had we not decided to move off JSON Schema to OpenAPI/Swagger? In either case, OpenAPI also has these constructs.)

allOf is akin to rdfs:domain and rdfs:range.

Where a property P has more than one rdfs:domain property, then the resources denoted by subjects of triples with predicate P are instances of all the classes stated by the rdfs:domain properties.

Where P has more than one rdfs:range property, then the resources denoted by the objects of triples with predicate P are instances of all the classes stated by the rdfs:range properties.

anyOf is akin to schema:domainIncludes & schema:rangeIncludes

OWL brings a number of additional properties which may also be useful, at least informationally, toward addressing this.

(Tangentially, JSON Schema in RDF may be a useful reference.)

[TallTed]

(rant posted above)

[TallTed]

It would have been super cool (and still could be!) to include a link to the issue that prompted this one in the initial comment on this issue.

(The immediate "@BenjaminMoe mentioned this issue on Aug 16" here, that linked to #395, does not achieve the same result, as there's no indication here of WHY this issue was referenced over there.)

[BenjaminMoe]

In what cases or scenarios would we want to use oneOf, are there any requirements around this?

[BenjaminMoe]

I think this issue is a result of confusion with the way JSON schema and JSON-LD are displayed with syntax. To do a minimum reproduction of the source for this issue, we can look at the following example:

oneOf:
  leiCode:
    title: Legal Entity Identifier Code
    description: Legal entity identifier code
    type: string
    $linkedData:
      term: leiCode
      '@id': https://schema.org/leiCode
  globalLocationNumber:
    title: Global Location Number
    description: The GS1 GLN of the organization.
    type: string
    $linkedData:
      term: globalLocationNumber
      '@id': https://schema.org/globalLocationNumber

In this example we have the case where you need to enter either a leiCode or globalLocationNumber. Where you need one or the other. The linked data terms are added as attributes under each one of these. So we have the question of how JSON-LD would handle this optionality.

The answer is that the schema is effectively orthogonal to the way JSON-LD does processing. So in this example we would expect the result of the JSON-LD context to have both terms defined.

{
  leiCode : "https://schema.org/leiCode",
  globalLocationNumber : "https://schema.org/globalLocationNumber"
}

Thus when we define oneOf in the schema. As long as both terms are defined in the context, then it doesn't matter which of the attributes shows up in the object being created will product valid JSON-LD and pass the schema check.

{
  "@context" : {
    leiCode : "https://schema.org/leiCode",
    globalLocationNumber : "https://schema.org/globalLocationNumber"
  },
  leiCode: "12345"
}

and

{
  "@context" : {
    leiCode : "https://schema.org/leiCode",
    globalLocationNumber : "https://schema.org/globalLocationNumber"
  },
  globalLocationNumber: "abcdef"
}

Both of which would pass schema validation and be correct JSON-LD. The main difference is that we would not want to use oneOf in the same object where we define the RDF type. We would want to the RDF type to define all of the terms used, and for the schema to contain the logic for managing the schema as we've started to do with examples such as the Verifiable Business Card and CTPAT Certification.

So the implementation of oneOf is already possible with the current tooling, just not with the syntax originally suggested when this issue was created. I suggest closing this issue as we have a way to implement this functionality with proper use of the current tools, and we can provide guidance in the situations where this approach would be needed.

[mkhraisha]

To confirm if we use current tooling we are able to define oneOf as described above, and it will generate a context with both terms defined in it and you would rely on the JSON schema to enforce that only one shows up in a credential.

if that is true we can close this.