Skip to content

Relative IRIs may clash with terms #49

Closed
niklasl opened this Issue Jan 10, 2012 · 5 comments

4 participants

@niklasl
JSON-LD Public Repositories member
niklasl commented Jan 10, 2012

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 http://example.org/):

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

Currently, the triple for this data would become:

<http://example.org/homepage#me>
    <http://xmlns.com/foaf/0.1/homepage> <http://xmlns.com/foaf/0.1/homepage> .

Not the intended:

<http://example.org/homepage#me>
    <http://xmlns.com/foaf/0.1/homepage> <http://example.org/homepage> .

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 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 for the definitions of these.)

@lanthaler
JSON-LD Public Repositories member
@dlongley
JSON-LD Public Repositories member

+1 for option 2.

@lanthaler
JSON-LD Public Repositories member

Issue #46 might be related to this, especially the need for IRI normalization.

@lanthaler
JSON-LD Public Repositories member

2012-01-24 Telecon:

RESOLVED: The lexical space for keys in JSON-LD key-value statements is if a term: NCName, if a prefix: NCName for the prefix, otherwise the lexical space for an IRI.

RESOLVED: The lexical space for keys in JSON-LD Context key-value statements is if a term: NCName, if a prefix: NCName for the prefix, otherwise the lexical space for an absolute IRI.

@gkellogg gkellogg added a commit that referenced this issue Jan 27, 2012
@gkellogg gkellogg Add definitions for absolute IRI and relative IRI.
Add requirements that keys expand to absolute IRIs to be processed.
(It's an open issue of what to do with the value of keys that do not expand to absolute IRIs).
This partially addresses issue #49 and the resolution of 1/24/2012 http://json-ld.org/minutes/2012-01-24/#resolution-1
ae24034
@gkellogg
JSON-LD Public Repositories member
gkellogg commented Apr 9, 2012

Also completed in d3c4996.

@gkellogg gkellogg closed this Apr 9, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.