json-ld/json-ld.org — Issue #49: Relative IRIs may clash with terms
Author: niklasl
Created: 2012-01-10 17:15:34+00:00
State: open

Altough we've removed `@base`, the issue remains where relative IRIs (who seem to be still supported) and terms may clash. For instance, consider this data (assuming it is located at ):

{
"@context": {"homepage": "http://xmlns.com/foaf/0.1/homepage"},
"@id": "homepage#me",
"homepage": {"@id": "homepage"}
}

Currently, the triple for this data would become:

.

Not the intended:

.

This is because the `@id` given for `homepage` would be found among the terms and not be resolved against "http://example.org/".

There are various ways of resolving this:

1. Only allow full IRIs. That will probably be problematic since there are many good use cases for them, e.g. for referencing contexts, and if nothing else it is most certainly common practise for linking on the web.

2. Not allow relative IRIs that might be confused with terms, e.g. by requiring non-full IRI paths to start with either "/" (i.e. be absolute) or "./" (which is already a [requirement in the URI spec](http://tools.ietf.org/html/rfc3986#section-4.2) if the first segment contains a colon, to disambiguate from a protocol). This could work but perhaps suffers in part of the problems of 1 (since it isn't uncommon for relative links to be given as only the leaf segment of a path).

3. Don't allow terms or CURIEs as values in `@id` (including for coerced values). That's problematic since there are many needs for these, both in contexts and in certain instance data cases for referencing e.g. classes and properties (and as `@type` is basically defined as `{"@id": "rdf:type", "@type": "@id"}`). We could have two different keywords, one for taking TERMorCURIEorAbsIRI values (mainly used in coercion, possibly named `@term`), and one for only IRIs or perhaps CURIEorIRI. (See [RDFa 1.1](http://www.w3.org/TR/rdfa-core/#s_datatypes) for the definitions of these.)