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

Randall Leeds tilgovi at hypothes.is
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:

> 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

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.

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

More information about the annotator-dev mailing list