W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2012

Re: Updated Editor's Draft of JSON-LD Syntax

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 23 Jan 2012 15:49:50 -0500
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: Ivan Herman <ivan@w3.org>, Linked JSON <public-linked-json@w3.org>
Message-ID: <A225DD87-E792-4A0C-9953-772123913B2F@greggkellogg.net>
On Jan 23, 2012, at 8:14 AM, Markus Lanthaler wrote:

>>> It is a separate issue.. and is not just about that. Consider the
>> following
>>> JSON-LD document:
>>> 
>>> {
>>> "@context": {"homepage": "http://xmlns.com/foaf/0.1/homepage"},
>>> "@id": "homepage#me",
>>> "homepage": {"@id": "homepage"}
>>> }
>>> 
>> 
>> I see where you are going but I think that
>> 
>> <homepage#me> <http://xmlns.com/foaf/0.1/homepage>
>> <http://xmlns.com/foaf/0.1/homepage> .
>> 
>> is probably the right answer, though clearly not the intended one...
> 
> That would be the output according to the current spec.

Only assuming there's no base-IRI for the document, in which case it would be made relative to that IRI, this is the same as with any other linked-data format.

>> Ie, if starting to define a microsyntax to expand parts of a string
>> (even if we know that the string is a URI) is feature creep for my
>> taste.
> 
> I can't see any problem with requiring relative IRIs to start with an "/" or
> ".", that's as much a microsyntax as the use of a colon to separate prefixes
> from suffixes:
> 
> {
>  "@context": {"homepage": "http://xmlns.com/foaf/0.1/homepage"},
>  "@id": "homepage#me",
>  "homepage": {"@id": "/homepage"}
> }
> 
> I would even go a step further and say that this makes a JSON-LD document
> much more readable and way easier to understand.

I really don't see the need to have special requirements for relative IRIs in JSON-LD, and we risk falling out of step with other serialization formats, where these forms of relative IRIs are legal.

As an advisory, we could suggest that relative IRIs start with a '.', or '/' to dis-ambiguate them with a potential conflict with term aliases, but the syntactic rules are clear, if it's a term (or prefix) perform the mapping, otherwise it's an IRI, either relative or absolute.

>> However... what this seems to ask for is a @base. An earlier version of
>> JSON-LS had this, afaik; maybe it is time to revisit this?
> 
> No, @base wouldn't solve the above issue per se. But you are right, you
> could use an empty prefix for this (which basically emulates @base) as
> follows:
> 
> {
>  "@context": {
>    "": "http://www.example.com/",
>    "homepage": "http://xmlns.com/foaf/0.1/homepage"
>   },
>  "@id": "homepage#me",
>  "homepage": {"@id": ":homepage"}
> }

An empty prefix allows a similar usage, just as it does in Turtle, but it is, of course, not identical. My previous vote was to drop @base, but this was because of the lack of a demonstrated need for it, the presence of relative IRIs potentially makes @base useful, as it is in Turtle, RDFa, RDF/XML and others.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
Received on Monday, 23 January 2012 20:52:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:36 GMT