precedence of @vocab for compaction too strong?

[eroux]

This is related to #235: When I have the following document:

{
  "@context": {
    "@vocab"  : "http://vocab.getty.edu/",
    "a"     : "http://vocab.getty.edu/aaaaaaaaaat/"
  }, 
  "@id" : "http://vocab.getty.edu/aaaaaaaaaat/5001065997",
  "@type": "http://vocab.getty.edu/aaaaaaaaaat/datatype"
}

By point 3 of the spec, because http://vocab.getty.edu/aaaaaaaaaat/5001065997 contains the value of @vocab, it gets compacted as aaaaaaaaaat/5001065997 without even looking at the prefixes. I think this is not reasonable, in this case a:5001065997 would look much nicer IMO.

[gkellogg]

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.

[dlongley]

Is this using @vocab here or is it just compacting to a relative URL? We're talking about the value for @id, right?

[dlongley]

It compacts to a:5001065997 in the playground.

[eroux]

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.

[dlongley]

@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."

https://www.w3.org/TR/json-ld-api/#compaction-algorithm

[davidlehn]

Does the test suite cover this use case?

[gkellogg]

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.

[azaroth42]

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.

[eroux]

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?