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.

[lanthaler]

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

[lanthaler]

RESOLVED: The following value types are supported for @id - document relative IRIs, absolute IRIs, and CURIEs.

[lanthaler]

RESOLVED: When compacting, attempt to compact absolute IRIs to document-relative IRIs.

[lanthaler]

I've just updated the spec and the test suite according the resolution. IRIs in @id are now automatically converted to relative IRIs during compaction. Terms in @id are ignored in expansion.

Unless I hear objections I will therefore proceed and close this issue in 24 hours.

[lanthaler]

RESOLVED: Add an at-risk issue on compacting IRIs as relative.

[msporny]

There is a problem with the resolution that we have made. In PaySwarm, we have objects that look like this in compact form:

{
"foo": "ps:PurchaseRequest"
}

We'd like to express this like so, as a term:

{
"foo": "PurchaseRequest"
}

However, with the latest resolution we've made, it makes doing that impossible. Here's why. The thing above expands to this:

{
"foo": { "@id": "http://purl.org/payswarm#PurchaseRequest" }
}

and since we said this RESOLVED: The following value types are supported for @id - document relative IRIs, absolute IRIs, and CURIEs.

we can't compact back down to this:

{
"foo": "PurchaseRequest"
}

That's really bad for the PaySwarm use case because we're trying to express this data using only terms since folks have complained about the use of CURIEs in the markup.

[lanthaler]

Manu, what is "foo" in your example? It appears to be @type, is that correct? In that case it would work as expected. If it is a random property that is type coerced to @id it won’t - but it also wouldn’t expand as you suggest.

[msporny]

In some cases it is @type, but that's not the case I'm worried about. I'm worried about the cases where we specify something like: "rateType": "FlatAmount":

http://payswarm.com/vocabs/commerce#FlatAmount

I know this is in direct conflict of being able to compact down to relative IRIs, but I think this use case is more important than being able to compact down to relative IRIs.

So, if we want to support compacting to relative IRIs, the processors should probably compact down to an IRI that starts with './'. The problem with that is that it is only applicable to certain schemes, like HTTP. That may not be a big issue in practice, though, this whole discussion is making me think that compacting to a relative IRI is a mistake and we should revisit the decision. I'd be fine with a flag (that is off by default) that compacts @ids to relative IRIs and either: 1) skips terms when doing the IRI compaction or 2) appends ./ to the name if it is an HTTP IRI or 3) exposes the risk that you may accidentally compact down to a term.

[lanthaler]

RESOLVED: If "@type": "@vocab" is specified for a term in the active context, then processing for the value associated with the term attempts to resolve it as an IRI - first processing it as a term, then a CURIE, then an absolute IRI, then against the active @vocab (if present), then a document-relative IRI.

[lanthaler]

RESOLVED: The value space for terms tagged with "@type": "@id" is compact IRI, absolute IRI, relative IRI, the value space for "@type": "@vocab" is term, compact IRI, absolute IRI, @vocab, relative IRI.

[lanthaler]

Both the syntax and the API spec have been updated to include the new "@type": "@vocab" type-coercion feature. Furthermore, quite a number of test cases has been added. Unless I hear objections, I will therefore proceed and close this issue in 24 hours.