Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab`

[niklasl]

The following compact data expands as expected to a @list of vocabulary term IRIs:

{
  "@context": {
    "owl": "http://www.w3.org/2002/07/owl#",
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "owl:unionOf": {"@container": "@list", "@type": "@vocab"},
    "@base": "http://purl.org/ontology/bibo/"
  },
  "@graph": [
    {
      "@id": "authorList",
      "rdfs:range": {
        "owl:unionOf": ["rdf:List", "rdf:Seq"]
      }
    }
  ]
}

However, when compacting the results using the same context, the JSON-LD 1.1 algorithm fails to produce the same compact form.

Here is the above example and the problematic compaction behaviour in the playground.

There are many use cases where a compact form of the combination of @container: @list and @type: @vocab is useful, such as when expressing an owl:unionOf or a owl:propertyChainAxiom, a FRESNEL lens or various expressions in ShEx and SHACL .

I have implemented a fix for this in TRLD. As this implementation strives to follow the specification algortihm, these changes ought to be fairly easy to apply in the specification too (adjusting some prose, and introducing a new section for the new sub-algorithm).

[gkellogg]

Presumably, the problem lies in the term selection algorithm, rather than the compaction algorithm itself. Are there some specific errata that should be raised against the spec?

[niklasl]

I thought so too, but term selection does provide the necessary structure to make compaction work in this case. It just isn't used for contained list values (it is only checked with the list object itself).

In the TRLD fix for this I addressed this by:

• factoring out step 4.15 to 4.19 of IRI Compaction to a new "get preferred values" sub-algorithm;
• use that to populate preferred values either for each contained value in a @list value, or for the value itself as per the original algorithm.

I do believe this ought to be raised as an errata against the spec, yes. While I think this fix ought to be enough, I'd love to have more eyes on it. If we agree on this solution, I can make a PR to the spec reflecting the change.

[gkellogg]

We've been holding off on making normative updates, in case we want to publish an update with editorial changes only. But, highlighting the proposed updates in the issue, would be great.

Compaction of list items is indeed a shortcoming, as is framing lists. Not sure it's an erratum, though, as it's not an error by design, but definitely something that should be considered for future normative updates.