search

json-ld / json-ld.org

JSON for Linked Data's documentation and playground site
https://json-ld.org/
Other
853 stars 152 forks source link

Nested context compaction w/ multiple types #763

Closed sharpfives closed 2 years ago

sharpfives commented 2 years ago

I've noticed some interesting behavior when compacting JSON-LD input of a node that contains multiple types, using a context that contains nested contexts specific to those types. The following example contains a node with two types, ["http://typeA", "http://typeB"], and a single name property "http://name" which should compact to either "nameA" or "nameB" depending on the type. In this case the node has both types, so which compacted name property should be used?

Example case

The current result is that "http://name" is compacted to "nameA".

After some experimentation, the order of operation in which the nested contexts are applied seems to be relative to the length and alphabetical sorting of the compacted property name. So, changing "nameA" in TypeA's context to "nameABC" results in "http://name" being compacted to "nameB" using TypeB's context (example), but, changing "nameA" to "name0" still results in TypeA's "name0" in the output (example). In summary, it chose the shortest compacted property name first, followed by the first alphabetically sorted property name.

I would like to propose a more dynamic approach to applying a nested context to nodes with multiple types, rather than the current sorting approach. Some options / thoughts for discussion:

  1. Since @type is an array, would using the order the types on a node be appropriate for determining the order in which contexts are applied? Currently, reversing the order of the types in the input to ["http://typeB", "http://typeA"] yields the same behavior above, but perhaps this could imply the order of context preference.
  2. Would there be any harm in the compacted result containing BOTH a "nameA" and "nameB" property, since they refer to the same value and IRI? I've noted that the reverse expansion of this case contains two @values rather than one, as a negative side effect in its current state. Expanded result
  3. Perhaps the context itself could dictate the order of preference in which its sub-contexts are applied.

Thank you for your time and consideration!

-Alex

gkellogg commented 2 years ago

Determining the proper term to use when compacting is covered by the Term Selection algorithm in the API using the active context. Given two type-scoped context, the order in which they are applied to the active context is also determined algorithmically in step 11 of the Compaction Algorithm, which does involve ordering those expanded types lexicographically. It's important that these are handled in the specified order for interoperability.

The general term selection algorithm was determined in the JSON-LD 1.0 timeframe by closing the shortest and lexicographically earliest term meeting the criterion; only in JSON-LD 1.1 were type-scoped contexts introduced, with their own ordering considerations.

While a future WG could consider revising this, it would be a tall order to do so and introduce incompatibilities.