[annotator-dev] JSON-LD as data interchange format [WAS Re: Branching v2.0.x]

[Nick Stenning]

Ed Summers wrote:
> Is it worthwhile considering JSON-LD and OpenAnnotation for v2.0? I 
> know that OpenAnnotation is mentioned quite a bit w/r/t Hypothes.is 
> and it seems like JSON-LD would possibly fit in fairly well with the
>  annotator.

Randall Leeds wrote:
> First we would need to resolve the remaining differences between the
>  annotator model and the open annotation model. Then JSON-LD can be 
> added in various places at any time.

So, here are a few thoughts:

Most people, when they first come across Annotator, have not thought
about the deeper semantic modelling of annotation that OA is trying to
achieve. They have a specific problem domain and a specific set of goals
("I want my users to be able to make notes on this document").

I think we should be wary of exposing the full complexity of OA to users
(or integrators, or plugin developers) unless we are clear on exactly
what benefits that brings.

The mechanism used by Anna Gerber is the one I'd like us to consider
pursuing, where Annotator continues to have its own internal model of
the annotation, without any conceptual or technological "linked data"
overhead. To speak concretely, that means that a plugin still deals with
plain ol' JavaScript objects. No contexts, no "@"-symbols.

It's then up to a specific storage engine to render that object into an
interchange format of it's own choosing. Conveniently, JavaScript
objects are more-or-less already an interchange format, so the default
store can simply pass the object (or rather a JSON-stringified version
thereof) back to the reference annotator-store.

I am very keen, however, to see a parallel effort (which should be made
vastly simpler by the changes now in progress for Annotator 2.0.x) to
develop a store plugin which transforms the Annotator internal
representation into JSON-LD and uses that as an interchange format.
Perhaps someone will even integrate this with an existing triple store?

The point here is that it is possible to do useful work as a plugin
author without necessarily having to engage with the full complexity of
OA data modelling. I don't believe we are providing any particular
benefit to plugin authors or integrators by pushing the OA
representation through the whole of Annotator.

(I am, however, prepared to be convinced otherwise...)

=====

And on the specific question of how we model tags... well, this is a
nice example of where OA forces us to think more clearly about what we
are representing.

My opinion is that tags as currently implemented are intended to be
alternative bodies of a single annotation.

Rob Sanderson wrote:
> In particular, the Open Annotation model says that all bodies of an
> annotation are about the target of the annotation.  So if a single
> annotation has two tags and one comment, then all three of those
> things are about the target(s) of the annotation, not the annotation
> itself.

Agreed.

As such, we can keep the "tags" key as just an array of strings within
Annotator, with no loss of generality. If an OA-compatible store plugin
then wishes to convert these to additional bodies on the resulting
annotation, that's possible.

Hope that's all clear,

Best,
-N