- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 17 Jun 2015 04:01:04 -0400
- To: W3C Public Annotation List <public-annotation@w3.org>
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. 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? 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]?) 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? [1] http://www.w3.org/TR/json-ld/#syntax-tokens-and-keywords Regards– –Doug
Received on Wednesday, 17 June 2015 08:01:08 UTC