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

Also, I think it would be helpful to put the `@context` "fear" aside.

As a developer, it's pretty easy to pick out the bits of a data structure
that you need, and ignore the others. If it really keeps them up at night,
they could put a couple lines together that strip that key out on the
JSON(-LD)'s way to whatever storage thing they're currently using.

Additionally, Rob, you mentioned something about "just using the
`;profile=` structure" vs. registering a custom media type. If we go that
route, I'm guessing clients could do one of the three following things,
correct?
 - Accept: application/json
 - Accept: application/ld+json
 - Accept: application/ld+json;profile=http://...

Each with increasing "accuracy" and/or meaning, correct?

I guess in the case of the last two the server *could* respond with the
more accurate Content-Type containing the full profile URL based on what it
found?

I'm mostly trying to see the forest for the trees. :) This conversation has
been great, but in it lies some pretty (drastic?) assumptions about the
groups we're serving, how much they understand, and what they're OK /
not-OK with.

I'd like to see us get back to: "if we do X, then it's (im)possible to do
Y." Less theory; more practice...maybe? :)

Thanks to everyone who's contributed to this thread (and the other related
ones). It's been fun, helpful, and generally a good time. ;)

Cheers!
Benjamin

On Mon, Jul 13, 2015 at 1:08 PM, Rob Sanderson via GitHub <sysbot+gh@w3.org>
wrote:

> > Do not understand this last point. If the returned JSON payload does
>  not include `@context`, it is easier on pure JSON based
> implementations, while JSON-LD implementations go on unchanged because
>  they get the `@context` through the header. I do not think it is the
> same.
>
> It involves more work on the server side to add the header, more work
> on the JSON-LD client side to retrieve the header, and doesn't save
> any work on the JSON client side, as it must just ignore the context
> key that it doesn't understand anyway.  No one is going to write code
> looking for structure that they then can't process.  There's no
> savings in transferred bytes, as the context is there in the HTTP
> headers, just much less accessible to systems that do want it.
>
> The header option is designed to allow previous non-json-ld systems to
>  assert their context without changing existing representations.
>
>
> --
> GitHub Notif of comment by azaroth42
> See
> https://github.com/w3c/web-annotation/issues/52#issuecomment-120995060
>
>