-1 to Multiple JSON serializations

My argument against multiple JSON serializations:

We already have a primary serialization (JSON-LD) and a secondary one that
we inherit primarily from the LDP specification of Turtle.  There has been
significant pushback against doing multiple serializations at all, wanting
to avoid Turtle support as a requirement.  That's fine, and would certainly
make development much easier.

By introducing a second (or third) serialization that MUST be supported, we
make no one's life easier.  So the alternative is to make all of the
serialization formats optional, and you just have to pick one.  Now we have
some systems that only speak turtle, some that speak full JSON-LD, some
that speak only one crystalization that happens to be JSON-LD, and some
that speak the proposed non-LD JSON.

So, as a developer, I have a choice between supporting any of these that I
like the look of. The non-LD JSON looks slightly easier than the the
crystalized JSON-LD, so I do that.  For anyone coming to the specs who
doesn't already do JSON-LD, this seems like the rationale choice.  At which
point, we might as well not do Linked Data at all, as we'd have a large
number of implementations doing raw json, none of whom implement the
translation to -LD.

For current OA implementers, they probably would just do the JSON-LD form.
Or not bother to upgrade at all. Then there'd be Open Annotation in RDF,
and Web Annotation in JSON. Again, silos of information that don't
interoperate.

If someone did implement the translation algorithm, they'd likely only do
it in one direction... to get access to more data.  As most new
implementations would simply do JSON, the likelihood of anyone doing the
much harder JSON-LD to JSON translation seems very slim.

So we spend a huge amount of time designing a new format to make the
pattern of multiple bodies with different roles in a single annotation
slightly easier to implement, with test cases and multiple implementations
...



When we could spend that time making the implementation of the selected
JSON-LD structure hidden behind APIs in libraries that everyone can just
take and use.

If it makes sense to view the content as:

{
  "comment": "There's a typo for 'squirrel'",
  "change": "squirrel",
  "target": "http://cnn.com/"
}

Then great, let's write the translation layer *FROM* the interoperability
specification *TO* that ease-of-use structure, or any other that's
desired.  There's no need to try and kludge everything together, and end up
serving no one's best interest.  It doesn't need to do round trips

So my proposal to try and break the current stalemate:

* Define the model to fully encapsulate all of the requirements without
taking into consideration any serialization or convenience.
* The on-the-wire bits are the JSON-LD serialization of that model. We can
discuss later whether we need to require a specific crystalization or
whether we can just say JSON-LD.
* We provide implementations that take that serialization and further
compact it into whatever structure is most useful, but those are
non-normative. They're code that we can write to make developers' lives
easier.

Thus, developers are happy (they get to work with whatever structure they
want), and we have a real interoperability specification built entirely on
existing standards.

Thoughts?

Rob

P.S. I think there's a good deal of existing cruft in the model that could
be thrown out at the same time, including literal bodies, tags and semantic
tags having a different structure, and so forth, that were added because of
this trying to serve two masters approach, and making no one happy in the
process.


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