-
Notifications
You must be signed in to change notification settings - Fork 157
Can JSON-LD keywords be re-defined in the @context? #102
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
We already allow them to be overridden and warn that this is probably not a good idea. A term can be any JSON string, which includes the range of keywords. I could see some value in being able to express @type: {@container: @set}, or even @graph: {@container: @set}. I could also see value in expressly raising an exception if an attempt is made to alias @type to an IRI or another keyword. |
No, we do not allow this at the moment, we just silently ignore it. All algorithms look for direct matches and do not take context definitions into account at the moment. I could live with some ways to fine-tune how @type etc. works (think @container) but I don't really know if there are really enough use cases justifying that. Maybe we should instead evaluate how authors could use a rdf:type property instead of @type. |
RESOLVED: JSON-LD keywords MUST NOT be re-defined in the |
The question is if this also makes it impossible to use the compaction algorithm for getting compact JSON from RDF. Consider input like:
if I use a context which defines type as a regular term, like:
I want it to yield:
I would at least prefer that there is no magic "@type" key in compaction if the context defines a term for rdf:type. Or perhaps by explicitly define "@type": null. Do we need an issue on compaction for that? This need is also described in #91. |
The resolution to #91 addresses this need. |
Is this legal in JSON-LD?
"@context": {
"@type": {"@id": "http://example.org/vocab#type", "@type": "http://example.org/vocab#Class"}
}
Should we allow JSON-LD keywords to be overridden? There seem to be two options: 1) Yes, allow them to be overridden, but warn developers that bad things will happen if we allow this, or 2) Throw an exception if somebody tries to re-define a JSON-LD keyword.
The text was updated successfully, but these errors were encountered: