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

Thu Nov 22 10:23:16 UTC 2012

Hi Rainer,

On 22.11.12 09:26, Simon Rainer wrote:
> 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

The "shape" part looks good, I would like to switch my implementation to
this format.

I would use relative coordinates. Should we have a way to specify
coordinate units or just mandate relative coordinates?

How about:

shape : {
  type : 'Rectangle',
  geometry : {
    units : 'fraction',
    x : 0.0123,
    y: 0.345,
    width : 0.567,
    height: 0.789}
}

I would assume units=fraction unless specified otherwise.

> 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

I did not like using SVG too much, it seems easy at first but real SVG
is much too complex and you can do lots of mayhem with transformations
on parts of the DOM. So you have to restrict the allowed implementation
like in <http://openannotation.org/spec/extension/#Selector>

I had in mind something like the shapes in the HTML area tag
<http://www.w3.org/TR/html-markup/area.html> but they don't have "point"
and specify only integer pixel coordinates.

On second thought, maybe we should go the restricted-SVG route. At least
the documentation is better and the polygons have separated coordinate
pairs instead of being just a string of numbers :-)

For types I would start out with point, rectangle and (closed) polygon.

> 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.)

On the point of extensibility, how about adding an additional shape of
one of the standard types when you add your own special stuff? Then a
client could render the standard shape if it doesn't understand the
special one.

That would require a "shapes" list with the implied semantics that these
shapes are alternatives.

Without getting too much into the discussions on the semantics of
multiple targets in openannotation, would we need different semantics
for annotations with multiple shapes in the short to medium term? Whats
the semantics of multiple ranges in Annotator BTW?

Best
	Robert