-
Notifications
You must be signed in to change notification settings - Fork 34
Expanding ordered lists #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 To work around this would be to turn your JSON-LD source using |
Closing, wontfix, as the API should not make decisions based on rdf predicates. |
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: