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

On Jan 23, 2012, at 16:35 , Markus Lanthaler wrote:

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

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.

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?

Ivan



> What should the Turtle output be for this document in your opinion?
> 
> One of the design goals of JSON-LD was to be able to enhance existing JSON
> documents by linking a context to them (we decided to do this via a HTTP
> link header so that no changes are necessary at all to the JSON document)
> and I believe we shouldn't give up that goal.
> 
> 
> 
>>> 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 "@".
> 
> Oh OK.. I misunderstood you a bit in that regard. Nevertheless I still don't
> see the need for something like that.
> 
> 
>>> 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...
> 
> I mentioned comments because I think to remember Niklas came accross a use
> case where he needed a way to add data to a document that should not be
> converted to triples.
> 
> 
> 
> 
>>> 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...
> 
> I think that would make the intention of the author clearer and explicit..
> 
> 
> 
> --
> 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