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

Thu Nov 22 08:26:01 UTC 2012

Hi Randal, hi all,

at the moment there is not much documentation available yet. But, yes, in Yuma/Annotorious (long story... but there's a name-change lurking ;-) things are kept relatively simple.

As you say, there's a "shape" field, which holds a 'type' identifier (currently 'Rectangle', 'Point', 'Polygon'), and a 'geometry' field with the actual coordinates/shape properties. Early beginnings of documentation, with an example for 'Rectangle' are here:
https://github.com/annotorious/annotorious/wiki/JavaScript-API

Coordinates are encoded as pixels. But I'm also considering switching to relative coordinates, since it makes it easier to properly handle images that are scaled in the browser from their original source resolution. Regarding our 'type' vocabulary: we really made that up, based on what I want to have in Annotorious in the near future, with no 'standard' behind it at all. But I'm thinking of at least aligning with the SVG shape types and property naming conventions:

http://www.w3.org/TR/SVG/shapes.html 

Not sure whether this captures all possible use cases; so extensibility is definitely needed nonetheless. (E.g. we currently have a use case for annotation of placenames on maps - https://github.com/rsimon/toponymotator. In this case we're dealing with (tilted) rectangles that have a dedicated "anchor point" and "baseline". We can simply cover that by encoding them as polygons, with the convention that the first coordinate is always the anchor, and the line to the second coordinate is always the baseline. But possibly a little more 'semantics' in the representation would be nice.)

Cheers,
Rainer

-----Ursprüngliche Nachricht-----
Von: annotator-dev-bounces at lists.okfn.org [mailto:annotator-dev-bounces at lists.okfn.org] Im Auftrag von Randall Leeds
Gesendet: Mittwoch, 21. November 2012 22:28
An: Robert Casties
Cc: annotator-dev at lists.okfn.org
Betreff: Re: [annotator-dev] Request for discussion: non-text annotations?

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/digilibin
> tegrator.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

_______________________________________________
annotator-dev mailing list
annotator-dev at lists.okfn.org
http://lists.okfn.org/mailman/listinfo/annotator-dev
Unsubscribe: http://lists.okfn.org/mailman/options/annotator-dev