W3C home > Mailing lists > Public > public-annotation@w3.org > July 2015

Re: [web-annotation] Yet Another JSON-LD the protocol spec to use?

From: Erik Wilde via GitHub <sysbot+gh@w3.org>
Date: Thu, 09 Jul 2015 17:42:33 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-120083374-1436463752-sysbot+gh@w3.org>
in the end, the simple question is the processing model of the media 
type: if i am processing the media type, how to i get from a 
serialization to a parsed model i can safely work with and robustly 
code against? the processing model then also tells me how i have to or
 how i can serialize and safely assume that different implementations 
will end up with the same understanding of what i have serialized.
the hard part is to think through open scenarios, such as a producer 
with a weirdo JSON library that produces strange but legitimate JSON. 
will all consumers (both those using JSON and those using JSON-LD 
toolsets) understand it in the same way? if not, something is broken, 
and the fix then is to either outrule the strange JSON (but then you 
are constraining JSON and that's not so great), or to tweak the 
processing model so that consumers indeed will get the same 
the tricky stuff usually happens across implementations, and even more
 so if they are built on different metamodels, one working in plain 
JSON only, and the other one by a team preferring RDF and using 
JSON-LD as their databinding. thinking through scenarios where these 
two interact, and both of them explore the limits of what they're 
allowed to do per spec, usually is a very educating exercise.
for the activity streams WG, we face the exact same problem: JSON-LD 
is used because some people like the fact that it's JSON, and another 
set of people like the fact that it's also RDF (but *only if* you get 
the tricky parts right that establish the RDF view such as using the 
right context). ideally, we should have defined everything in terms of
 pure JSON, so that people only dealing with JSON could read the spec 
and never even read about the RDF view. and then a separate spec could
 tell those interested in an RDF view of everything how to do this 
robustly on top of the JSON. we haven't managed to be that clean and 
clear, but at least logically speaking, this is the way to go.

GitHub Notif of comment by dret
Received on Thursday, 9 July 2015 17:42:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC