Closed gkellogg closed 6 years ago
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.
Closing, wontfix, as the API should not make decisions based on rdf predicates. WG Resolution: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld#section2-1
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.Original issue: Expanding ordered lists #654.