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

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...

Ivan

> 
> --
> 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