Closed pjohnston-wiley closed 6 years ago
Fixed typos in (2) & (3).
I added this for WG review, but I don't think we'll end up bringing further RDF interpretation into algorithms other than to/from RDF. This would also mean interpreting rdf:type
as @type
, something we explicitly avoided in 1.0.
To work around this would be to turn your JSON-LD source using rdf:List
into quads, and then perform the fromRDF algorithm to get it back into normal JSON-LD form.
OK, but then it may be worth mentioning this somewhere in the spec or in a field guide - once you are in the Land of JSON-LD® you are expected to relinquish all ties with rdf:
constructs or you will get unexpected behaviors. Maybe it is there already and i missed it, in which case i apologize.
Thanks for the workaround - that's essentially what i ended up doing, but i was hoping for something a tiny bit more efficient.
Transfered to WG: https://github.com/w3c/json-ld-api/issues/9.
Consider the following inputs:
(1)
and
(2)
When resolved as N-Quads on the playground, they both result in:
(3)
In other words, they are semantically identical, ordered lists.
However, if i submit them to JSON-LD expansion, the former preserves
@list
, while the latter preserves therdf:List
construct. This causes knock-on inconsistencies when i compact and/or frame.In order to resolve this, i propose that the expansion algorithm explicitly take into account
rdf:List
s in expanded form. In other words, whether the input is (1) or (2), the result of expansion should always be:Alternatively, you can specify that any conversion to JSON-LD always convert
rdfList
s to@list
form. This would then effectively makerdf:first
/rdf:rest
verboten in JSON-LD-land. I realize the algorithm seems to cover the conversion (though i admit not fully understanding how), but the spec itself does not preclude JSON-LD with explicitrdf:first
s.