Re: JSON Serialization?

Is there someone who could make a concrete proposal for revising the JSON-LD keywords, specifically listing all the changes? We could then use that as the basis for a brief discussion/agreement.

Seems there is already rough agreement on the list as well as a rationale for making the change (Thanks Randall for articulating this)

regards, Frederick

Frederick Hirsch
Co-Chair, W3C Web Annotation WG

www.fjhirsch.com
@fjhirsch

> On Jun 18, 2015, at 11:51 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Yep, this is issue 12:
> 
> https://github.com/w3c/web-annotation/issues/12
> 
> Rob
> 
> On Thu, Jun 18, 2015 at 8:42 AM, Chris Birk <cmbirk@gmail.com> wrote:
> +1 as well ( especially revisiting the keywords ).  
> 
> I agree that the end value isn’t high for most producers from my perspective, but including that information in the HTTP return header should alleviate any issues there.
> 
> 
> 
> - Chris 
> @cmbirk
> (317) 418-9384
> 
> 
> On Thu, Jun 18, 2015 at 2:47 AM, Doug Schepers <schepers@w3.org> wrote:
> 
> Hey, folks– 
> 
> I agree with everything Randall said, and I'll add this: 
> 
> The RDF convention around predicates (e.g. hasX, isY, ZedBy) is intended 
> to impart a natural-language flow when reading it, which I respect. In 
> other languages and models, though, this violates expectations, and when 
> used in real natural language, keyword (even RDF keywords) are used as 
> different parts of speech, making it very awkward to talk about these 
> attributes. 
> 
> I'd very much like to revisit these keywords, as Randall suggests, and 
> design a @context that maps them to whatever terms are needed under the 
> hood. 
> 
> Regards– 
> –Doug 
> 
> On 6/18/15 2:01 AM, Randall Leeds wrote: 
> > See below for a response that I accidentally sent only to Ivan. 
> > 
> > ---------- Forwarded message --------- 
> > From: Randall Leeds <randall@bleeds.info <mailto:randall@bleeds.info>> 
> > Date: Wed, Jun 17, 2015 at 4:04 PM 
> > Subject: Re: JSON Serialization? 
> > To: Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>> 
> > 
> > 
> > On Wed, Jun 17, 2015 at 12:04 PM Ivan Herman <ivan@w3.org 
> > <mailto:ivan@w3.org>> wrote: 
> > 
> > 
> > > On 17 Jun 2015, at 10:01 , Doug Schepers <schepers@w3.org 
> > <mailto:schepers@w3.org>> wrote: 
> > > 
> > 
> > > 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 <http://schema.org>: 
> > schema.org <http://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) 
> > 
> > 
> > Agree with all of this. Thanks, Ivan. 
> > 
> > I still think the value proposition to producers isn't particularly 
> > strong, though. Intermediate consumers that want to link together data 
> > from disparate sources derive value, but the original producers it's 
> > less clear. 
> > 
> > 
> > > 
> > > 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.) 
> > 
> > 
> > I disagree. I think simple attribute names are really easy to agree on. 
> > Most people, when really challenged on it, don't want to bikeshed 
> > everything forever, in my opinion. 
> > 
> > However, I've never seen JSON in the wild that is anything like what we 
> > have in our context document. 
> > 
> > As a developer, I would never choose "hasTarget" over "target". The 
> > "has" is implied by the nesting. When working in JSON we don't see 
> > independent triples, we see framed wholes. The domain model and the 
> > framing obviates these prepositions. 
> > 
> > Often, for simple vocabularies, it's sufficient to use the type of the 
> > object range of the relationship as the key because there's only one 
> > meaningful relationship between the subject and that type of object. 
> > 
> > I've worked with JSON in dozens of domains and I never see anything like 
> > what we have. 
> > 
> > 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. 
> > 
> > 
> > Most keywords can be aliased, so this is not a problem: 
> > http://www.w3.org/TR/json-ld/#aliasing-keywords 
> > 
> > I would suggest our default context use "id" or "uri" or anything like 
> > this. When every single other key lacks a "@" (in absence of a context 
> > document, or with it sent in a header link) "@id" looks mighty strange 
> > and is not something I would expect anyone to do otherwise. 
> > 
> > I am aware of a number of JSON APIs that use a prefixing scheme, such as 
> > "@" or "_", to separate metadata and data, but that doesn't apply here. 
> > It's all properties or relations of the subject. None of this is, for 
> > instance, protocal or storage "metadata" "around" the, e.g., annotation. 
> > 
> > 
> > > 
> > > 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 think we should take another pass at our default context with an eye 
> > toward memorable, compact keys and a default aliasing for "@id". 
> 
> 
> 
> 
> 
> 
> -- 
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305

Received on Monday, 22 June 2015 19:34:59 UTC