[annotator-dev] Request for discussion: non-text annotations?

Wed Nov 21 21:18:26 UTC 2012

On Wed, Nov 21, 2012 at 7:12 AM, Robert Casties
<casties at mpiwg-berlin.mpg.de> wrote:
> Hi Annotator-devs,
>
> while building image-annotation support for the digilib viewer I came
> across the issue of integrating annotations with a different format of
> "the annotated thing" into the Annotator code. I found that
>
> a) I really like the Anotator UI and code with its plugins for loading,
> displaying and editing the annotations
>
> but
>
> b) there are some hard-wired assumptions about the existence and
> structure of a "range" in annotator.coffee that I had to monkey-patch in
> my DigilibIntegration plugin
> <https://github.com/robcast/annotator/blob/master/src/plugin/digilibintegrator.coffee>

I'll take a look. I may have done something similar for hypothesis. It
would be good to get these assumptions out of annotator core and into
a plugin.

(Side note, I'd love feedback about publishing annotator core and
plugins as bower packages:
https://github.com/okfn/annotator/issues/117#issuecomment-10096820)

>
> Currently I put the coordinates of the annotated region of the image in
> an separate "areas" list analog to "ranges" like this:
>
> "areas":[{
>   "height":"0.0170",
>   "width":"0.3291",
>   "y":"0.5557",
>   "x":"0.6938"}
> ]
>
> The coordinates are decimal fractions [0..1] of the image width and
> height, independent of the current image size.
>
> Currently I switch on the existence of the "areas" list in my code.
>
> Is it a good idea to have a separate property or should the image
> coordinates also go in "ranges"?
>
> It would be even better if the Annotator code would be able to switch on
> the fly between different implementations of "ranges", maybe even as
> plugins.
>
> What do you think?

Absolutely. Extensible selectors is exactly where we need to go, IMO,
for new media types as well as more robust text anchoring (issue
#115).

Maybe we should start collecting some proposals for addressing this.
One might go like this: "Allow setupAnnotation to delegate to
selectors registered on / triggered by a particular field, e.g.
'ranges'."

It looks like the yuma/annotorious work uses a "shape" field instead
of "ranges" [0].

We could start collecting these on the wiki so that we might start to
form a common set that we can all share for interoperability. In the
future, we can reflect our our lazy consensus to the Open Annotation
group to help inform a common set of candidate selectors for the
extension document [1].

Rainer, would you please point me to any documentation you have of the
format of the shape field?

[0] https://github.com/annotorious/annotorious/blob/master/src/okfn/okfn_image_plugin.js#L129
[1] http://openannotation.org/spec/extension/#Selector