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

On Thu, Jul 9, 2015 at 8:38 AM, Benjamin Young <bigbluehat@hypothes.is>
wrote:

> 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."
>

How would
    application/annotation+json
be different from
    application/ld+json;profile="http://w3.org/ns/oa#jsonldprofile"

Apart from requiring a full mime type registration rather than registering
a profile?

N.B. If we move away from ld+json, we would not be compatible with LDP any
more :(


> 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.
>

Yup, and you could have it check the profile to determine the shape rather
than requiring a web annotation media type, a iiif annotation media type, a
epub annotation media type, a annotator annotation media type ... that were
all the same model, just different shapes.


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

+1.  Interoperability :)


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

+1.  Implementability :)



> 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
>

As above, I think this is the profile param.


>  - JSON-LD + our specific @context URL
>

And this is without the profile param, but with our specific @context URL
in the content


>  - JSON-LD + any @context--which, after being fully parsed, is found to be
> an annotation (or contain annotation graph statements)
>

And this is without the profile (or with another profile) with a different
@context URL, or embedded context spec.


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).
>

Yep.  Though with a JSON-LD library that supports frames it's actually only
two lines of code:

  reframed = frame(annotation, basic_annotation_frame)
  output = compact(reframed, specific_context_uri)

There might be a little bit of tidying after that, on an implementation
dependent basis, but it would be very very close.
The entire code to demonstrate the context switching took me exactly 23
minutes to implement, and is available:

https://github.com/azaroth42/anno_context_switcher

HTH :)

Rob

-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305