Compact @id's to relative IRIs

[lanthaler]

Currently @ids are transformed to absolute IRIs during expansion. It might make sense to re-compact them automatically to relative IRIs in compaction.

Example (assuming http://www.example.com/document.jsonld as base IRI):

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name"
  },
  "@id": "markus",
  "name": "Markus Lanthaler"
}

Expands to

[
  {
    "@id": "http://www.example.com/markus",
    "http://xmlns.com/foaf/0.1/name": [
      { "@value": "Markus Lanthaler" }
    ]
  }
]

and re-compacts to

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name"
  },
  "@id": "http://www.example.com/markus",
  "name": "Markus Lanthaler"
}

Instead I think it should compact to

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name"
  },
  "@id": "markus",
  "name": "Markus Lanthaler"
}

[niklasl]

Isn't there a risk that relative IRIs may collide with defined terms? If so, automatically compacting will alter data if there is a term in the context matching any resulting relative IRI.

(IIRC, due to the support for terms in the @id position, people have to guard against collision by prepending anything at risk with "./". )

[lanthaler]

Those collisions can be easily detected and thus avoided. The reason why I would like to have this behavior is because you could for example POST some data to a Web service (without knowing which URL the server assigns that document). The server would probably re-compact it using its own context and then assign the document a URL (maybe multiple, staging/production, think of Drupal e.g.). I would like that the processor handles that itself so that developers don't need to implement their own post-processing logic.

[niklasl]

Nothing should prevent a specific service from compacting IRIs in its own specific way. It can be argued that it's best to keep IRIs absolute all the time – since we have no @base support, storing local copies otherwise requires expanding them all. But as you say, needs will vary, and we should probably add that relativization is explicitly allowed.

I recommend to do that by always adding "./", or using absolute paths. Compaction should not have to look up every relative IRI in the context and treat those that collide with terms differently. That would lead to irregular data, be unnecessarily costly, and would break data which uses an external context that might change out of sync with the published documents.

(A long time ago, I suggested disallowing terms in values for @id and introduce a keyword like @symbol to differ between plain IRIs and TermOrCURIEorIRI (specifically used for @type). But we didn't, and I believe this need for caution against overshadowing by terms is very important to point out.)

[lanthaler]

Nothing should prevent a specific service from compacting IRIs in its own specific way.

Yes, that's what the optimize flag is for.

I recommend to do that by always adding "./", or using absolute paths. Compaction should not have to look up every relative IRI in the context and treat those that collide with terms differently. That would lead to irregular data, be unnecessarily costly, and would break data which uses an external context that might change out of sync with the published documents.

That's a very good point.

(A long time ago, I suggested disallowing terms in values for @id and introduce a keyword like @symbol to differ between plain IRIs and TermOrCURIEorIRI (specifically used for @type). But we didn't, and I believe this need for caution against overshadowing by terms is very important to point out.)

Maybe just saying that a term (or prefix, depending on its use) has to begin with a number or character would do the job. That way you can easily ensure that there's no collision with a relative IRI. Thoughts?

[lanthaler]

Actually, thinking more about it we might should reconsider whether we allow (compact to) terms and compact IRIs at all in @id.

@niklasl, @msporny, @gkellogg, what do you guys think?

[msporny]

@lanthaler I think compact IRIs in @ids have one pretty solid use case, and that's that Drupal folks would like to be able to do stuff like this:

site:/nodes/1 instead of spelling the whole thing out. @scor @linclark - is this true?

[msporny]

I could go either way on this feature. We don't have anybody really pushing for it, so my inclination is to leave it out for now. I feel like the feature buys us more trouble than it's worth. We can always add the feature in the future.

PROPOSAL: Do not support relative IRI compaction in JSON-LD 1.0.

[gkellogg]

I guess the only way that relative IRIs could be compacted is if we allow terms to be defined using relative IRIs. I don't see a good reason to allow this, even though I believe Turtle does.

+0.8

[lanthaler]

Gregg, I think you misunderstood the issue. It is about compacting the IRI which is the value of @id property to a relative IRI and whether we compact those IRIs using terms/prefixes.

Sometimes it is surprising (weird) to see a IRI in @id being compacted to a compact IRI.

Regarding the Drupal use case, would it be any different if the IRI would be compacted to /some/path/nodes/1 instead of site:/nodes/1? I actually think that would make more sense because it allows you to serve the data at different URLs (think staging, deployment, migration, etc.)

[niklasl]

I think it is problematic that we allow terms as values for @id. A relative IRI which happens to be lexically identical to a term in the @context thus resolves into the IRI bound to that term, whereas any other "term" resolves to the base IRI (or @vocab if present, I suppose).

On the other hand, this is exactly what we want for @type, which I think only needs to resolve as TermOrCURIEorAbsIRI (i.e. just like properties and types in RDFa). For @id, I would prefer to allow only CURIEorIRI (and thus not allow those to resolve against @vocab; again, just like in RDFa).

[msporny]

+1 to what Niklas said.

PROPOSAL: Do not allow terms as values for @id.

[gkellogg]

+1

We need to decide if this extends to CURIEs as well. Not quite as problematic, but not as consistent either.

[lanthaler]

Currently @vocab isn’t used for values of @id, only for values of @type. We decided in #162 that @type should, as a last resort, be resolved against the document’s base IRI. I still think this makes sense as the value of @type will always be an IRI. If nothing else is defined in the context, it should be expanded using the base IRI instead of throwing an error.

+1 to Manu’s 2nd proposal, I would like to extend it as follows

PROPOSAL 3: The value of @id is resolved as IRI (relative or absolute; terms, CURIES, @vocab are not considered). The value of @type is interpreted as decided in #162, i.e., as absolute IRI, term, CURIE, @vocab-relative and as last resort as relative IRI against the document’s IRI.