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

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

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