You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the rdf: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:Lists 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 rdfLists to @list form. This would then effectively make rdf: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 explicit rdf:firsts.
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.
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.
The text was updated successfully, but these errors were encountered: