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

[Simon Rainer]

Hi Robert, 

only briefly:

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

Cool!

+1 on the 'units' extension. 'fraction' and 'pixel' for the time being? (I'm also thinking about our use case with OpenLayers, which works with map coordinates. So this might be a nice way to handle those cleanly.) 

Regarding SVG: I'm also against using SVG directly (we've done it in the very first iteration of Yuma, and I've had similar experiences). But I think the base vocabulary (shape types/names, the property names to define the geometry of a particular shape) could be re-used. The HTML "area" feels a bit over-simplistic, and I agree that having geometry encoded just as strings of (unnamed?) numbers is not a good representation.

Regarding shape alternatives: hm. I still need to think through the entire case first I guess. But rather than having alternatives, I think, I'd simply add extra properties to the shape itself. Say something like:

shape : {
  type : 'Polygon',
  geometry : { units : 'pixel',  coords: [{x: 10, y: 10}, {x: 100, y: 10}, {x: 100, y: 20}, {x: 10, y: 20}] },
  anchorPoint: 0
}

and then 'unaware' clients would simply skip the anchorPoint property, dealing only with the raw shape. Or maybe the fact that it's (in this case) a "placename annotation" shouldn't be encoded in the shape at all, but rather at the level above (as part of the annotation). Anyways: still needs more thinking, I guess, and is part of another discussion, probably :-)

Regarding multiple targets: Annotorious doesn't have the necessary UI features for handling that use case at the moment. But I agree it's something we need to handle in the format sooner rather than later. I think I'm going to change my 'shape' field to 'shapes' and then simply use a JSON array of shapes, rather than a single object.

Cheers,
Rainer





-----Ursprüngliche Nachricht-----
Von: Robert Casties [mailto:casties at mpiwg-berlin.mpg.de] 
Gesendet: Donnerstag, 22. November 2012 11:23
An: Simon Rainer
Cc: Randall Leeds; annotator-dev at lists.okfn.org
Betreff: Re: AW: [annotator-dev] Request for discussion: non-text annotations?

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