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

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

From: Ivan Herman <ivan@w3.org>
Date: Mon, 23 Jan 2012 15:29:22 +0100
Cc: "'Linked JSON'" <public-linked-json@w3.org>
Message-Id: <856C256A-0C85-4BD8-8492-3D49FB8FF4AE@w3.org>
To: "Markus Lanthaler" <markus.lanthaler@gmx.net>

On Jan 23, 2012, at 15:06 , Markus Lanthaler wrote:

>>> What I'm saying is that that is
>>> wrong IMO.
>> Well... what is wrong? As you said, this is correct...
> I think it's wrong to assume that everything that wasn't mapped to a term
> and is not an absolute IRI (i.e. has a colon in it but the prefix is
> undefined) is a relative IRI. That would make it impossible to mix plain old
> JSON with JSON-LD without creating a large number of invalid triples.

This is a completely different issue from the one I am having, maybe worth separating those. Personally, I am not bothered by this relative URI issue, simply because I do not see the use case for the mix of non-JSON-LD data with JSON. Put it another way, I am a bit agnostic on this issue as long as the solution does not overcomplicate JSON-LD

>>> We need a clear way to distinguish undefined terms from relative IRIs
>>> (that's the referenced ISSUE-49).
>> And we, in fact, already have a mechanism. This is the usage of
>> predicates with a leading '@' which do have a special meaning.
> Things with a leading @ are reserved keywords in JSON-LD. I don't think we
> should encourage the use of @ for everything that should be ignored.

Yes. My proposal is to define yet another keyword, namely '@data". I do _not_ propose define any new and general mechanism for keys starting with a "@".

> Some
> people might need to put data in their JSON documents that should not be
> converted to triples (something like comments)..

I must say I am surprised that the JSON specification does not define a comment in general. But that is not our responsibility. But, if so, I am not sure why we should define something specific for comments; it seems that the JSON world is happy without it...

If we really need comments, we can use existing rdf terms; yes, they will be added to the RDF output, but so what? It won't do any harm anywhere.

We could, of course, add yet another @ keyword, but I would prefer not to...

>> So we
>> may be saying the same thing, in fact. Just as '@context' does not
>> generate data for the output, but simply instructs the JSON-LD to do
>> something special, so would '@data' instruct the processor to do
>> something special. That is what I had in my mail.
> But that would make it impossible for example to translate an already
> existing JSON document to a JSON-LD document if not all terms can be mapped
> to a vocabulary.

And I am not sure we should go out of our way for this...

>> Ie: we do not need any fundamentally new feature or behaviour. We have
>> it, we just have to define the exact behaviour.
>> Maybe we are saying the same thing...
> Neither do we need a new feature in my proposal. All we need to do is to be
> able to distinguish between relative IRIs and terms (I think that also good
> from an author's perspective) and simply ignore unknown terms.

And I am afraid that properly solving this would make the JSON-LD encoding a bit more opaque. I am haunted by the RDF/XML example of additional features...


> --
> Markus Lanthaler
> @markuslanthaler

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Monday, 23 January 2012 14:27:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:19 UTC