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

On Thu, Jul 9, 2015 at 10:59 AM, Rob Sanderson via GitHub <sysbot+gh@w3.org>
wrote:

> The question is not "What happens if developers are using json-ld
> libraries", but the infinitely more common scenario of "What happens
> if developers are using json libraries". And in that 99% scenario,
> they would be unable to process the context to determine the semantics
>  of the new keys in the object.
>
> So, in my opinion, the benefit of not requiring an entire RDF stack
> (in the form of JSON-LD) while still being 100% compatible with it,
> outweighs any minor difficulty in applying supplied contexts and
> frames.
>
> The alternative (which I am not absolutely against) is to completely
> embrace linked open data and make decisions entirely based on
> technical validity, rather than trying to cater to ease of
> development.  In that mode, we could be much less constraining.
>

Being less constraining is certainly a powerful argument for possibly
moving that direction. I'm not sure, however, what that (or even the
current method laid out) will actually play out  during implementation on
both RDF(-ish) data stores and non-graph stores (i.e. most NoSQL, RDBMS,
etc).

Regardless of the above situation, we're going to need to mint a
"JSON-only" media type if we have expectations about consistent key naming.
I realize we're leveraging the JSON-LD @context (either as a key or in the
header) to essentially facilitate that, but if we expect non-LD devs to
send in plain old JSON using consistent key names, then they (and their
data stores) should probably know it's meant to be an annotation object and
not "just JSON."

For instance, Apache CouchDB stores any and all `application/json` I can
send it. However, I'd then have to do something within CouchDB to detect
what the content actually is--such as suss out what keys it uses, etc.

Alternatively, I can create an endpoint within CouchDB that checks the
media type used when it came in, and store additional information about the
media type used at write-time and then use that data to output just the
annotations (+ the context meta data, etc). I could do the same thing if
the client sent the JSON in with the @context.

Point being that we're circling around a core point:
 - how do clients and servers consistently produce data they both understand

We have the added design constraint of wanting to support both graph and
non-graph data stores (which is important because Web).

To that end, I'd like to explore these options:
 - plain ole JSON + a media type definition (`application/annotation+json`)
   - with the expectation that it matches the keys defined in the spec, but
MAY not include a @context
 - JSON-LD + our specific @context URL
 - JSON-LD + any @context--which, after being fully parsed, is found to be
an annotation (or contain annotation graph statements)

Me and CouchDB can do the first two. There's some chance (given enough
JSON-LD tooling) that I could at least parse the "random" @context values,
extract the key/values I need, store those, and then later produce a
version of the first two. The third, however, is the trickiest (and
consequently most flexible and future proof).

Obvious trade offs abound. :)

Does that paint the right picture? or am I missing something?


> --
> GitHub Notif of comment by azaroth42
> See
> https://github.com/w3c/web-annotation/issues/52#issuecomment-120016695
>
>