Closed eroux closed 6 years ago
Indeed, @vocab
is a powerful tool, which can wreak havoc to assumptions. Compact IRIs have a long and complicated relationship in JSON-LD, and there are those who would rather exclude them entirely.
The WG was pretty clear on this prioritization, so I don't see turning that around for 1.1. However, the scoped contexts feature of 1.1 may be useful to turn off the @vocab
(or turn it on) in specific scopes: setting @vocab
to null
makes it as if it were never set.
Is this using @vocab
here or is it just compacting to a relative URL? We're talking about the value for @id
, right?
It compacts to a:5001065997
in the playground.
Well, I don't think I can keep up with all the history of JSON-LD and I don't think I can be of much help here (I'm not sure communicating my dissatisfaction with this feature of the spec would be helpful), but I've reported it on jsonld.js.
@eroux,
Actually, I think jsonld.js is doing the right thing. It compacts to what you were expecting. Whatever tool you were using (jsonld-java?) appears to be using @vocab
when it shouldn't be. @vocab
is not used to compact @id
per the spec (emphasis mine at the end):
Step 7.1 "If expanded property is @id or @type:" Step 7.1.1 "If expanded value is a string, then initialize compacted value to the result of using the IRI Compaction algorithm, passing active context, inverse context, expanded value for iri, and true for vocab if expanded property is @type, false otherwise."
Does the test suite cover this use case?
It compacts to a:5001065997
for me too, but that's because @vocab
is not used of @id
, but only for values of @type
and properties themselves (vocab
is true
).
@type
compacts to "aaaaaaaaaat/datatype"
, because it uses vocabulary-based compaction.
I think the root cause of the issue is that @type
has its processing model constrained by the specification, rather than by interpreting the context (and hence @vocab
). As @dlongley says, it's compacting to a relative URL rather than a prefixed compact IRI.
Is anyone willing to propose changing the definition of @type
? Otherwise I think we have to close the issue as wontfix
.
Well, I would say that changing @type
to use prefixed compact IRIs would be good yes... also, how does the spec work when @type
is aliased? Does it behave in a different way?
Transfered to the WG: https://github.com/w3c/json-ld-api/issues/7.
This is related to https://github.com/json-ld/json-ld.org/issues/235: When I have the following document:
By point
3
of the spec, becausehttp://vocab.getty.edu/aaaaaaaaaat/5001065997
contains the value of@vocab
, it gets compacted asaaaaaaaaaat/5001065997
without even looking at the prefixes. I think this is not reasonable, in this casea:5001065997
would look much nicer IMO.