Re: JSON Serialization?

Hi Doug,

been there, done that (well, tried to do that):-)

> On 17 Jun 2015, at 10:01 , Doug Schepers <schepers@w3.org> wrote:
> 
> Hey, folks–
> 
> I was speaking to some developers about supporting the Web Annotation Data Model in their webapp (which has an inline commenting system that they're thinking of adapting for annotations).
> 
> A sticking point came up around JSON-LD; I explained to them (and I hope I'm correct) that the data model is very lightweight, and that JSON-LD is not a big burden on top of JSON, because you don't need to include the context inline, so it's just a matter of using the same attribute names and structures.

That is correct. If a client really wants, it has the possibility to a reference to @context in the HTTP return header. Pretty much invisible for anyone who does not need it.

> 
> Even with the relatively small additional overhead, they were skeptical there is any benefit to JSON-LD over plain JSON; with a simple, small, well-defined vocabulary, they didn't see why it shouldn't simply be stand-alone. I wasn't great at selling the notion of "reasoning", since they aren't using the Linked Data/SemWeb backend toolchains that would enable that; maybe somebody else could explain it more compellingly?

My 2 cents:

In my experience, reasoning as an argument does not really fly. In fact, only a few RDF systems do any kind of reasoning in the first place, and it does not scale over a certain size anyway (although those sizes are irrelevant for annotations).

What JSON-LD buys us (at least in my view) is its strong connection to Linked Data. Ie, the annotation data can be combined, if necessary, with data like the ones represented by dbpedia (ie, the whole of Wikipedia:-) or, these days, with WikiData which is gradually becoming the underpinning of Wikipedia. DBpedia, though not prominent, is not the only example of course, there are tons of others. To take another example, it can use the same terms as the ones used in web sites for schema.org: schema.org is, in reality, RDF, encoded in either microdata or RDFa Lite.

Ie: if the annotation data is used in strict isolation from the rest of the world, then JSON-LD does not buy anything. But if a system wants to bind this data to the outside world, it is a different ballgame. (Ie, the important bit is 'LD', not RDF)

> 
> They also didn't react especially well to some of the attribute names, like annotatedBy, annotatedAt, serializedBy, serializedAt, which didn't seem intuitive or descriptive, or to the value prefixes (like "oa:"). I couldn't really explain why some attributes start with @, and some not. (Though on further reading, maybe the @ represents a JSON-LD keyword [1]?)

Finding the good attribute names that would satisfy everybody needs a white table and lots of drinks (if you are in Amsterdam, you may want something else, too). Seriously: can anyone imagine any attribute name that would be agreeable to everybody? I doubt. (Sorry to be sarcastic.)

Seriously: this is not a JSON-LD issue. We can choose any names we want and we can agree on, that can be mapped on the data model terms through @context at our heart's content.

As for '@': afaik, they are, sort of, keywords. More exactly: '@id' is, because it assigns an identification to a resource. AFAIK, one can use any attribute to 'type' (mapped through the context), the usage of '@type' is just a convention.

> 
> I wondered if maybe there might be a path forward, by just defining a simplified JSON syntax that maps directly to the JSON-LD, but without the "data-typing" and URIs?
> 
> I know that might seem like a really bad idea, because multiple syntaxes makes interop harder. I don't have a good answer for that.
> 
> Can someone help me frame a description or an argument why this isn't a good idea?
> 
> On the surface of it, it does have the advantage that it would be simpler to understand (and mildly simpler to produce). Would there be any other advantages?
> 

I honestly believe it would not be simpler to produce. A bunch of different names is not a difference and, as I said, the @context can be swallowed by a server (ie, sent through HTTP). '@type' can be mapped to another property; finally, if a client/server does not want to use the '@id' then… how would one identify two resources to be the same? Note that, RDF-wise, even '@id' can be dropped, ie, the resource is a so called blank node; this is o.k. if one does not want to identify anything. The difference between bona fide JSON-LD and a 'pure' JSON would be probably so minimal that it would not be worth it.

All that being said: I may not be the good person to decide that, so I would not lie down the road; I have been involved with RDF way too long (even if I do much less with it these days) to be objective.

Cheers

Ivan



> [1] http://www.w3.org/TR/json-ld/#syntax-tokens-and-keywords
> 
> Regards–
> –Doug
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704