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

[Randall Leeds]

On Thu, Nov 22, 2012 at 3:59 AM, Robert Casties <casties at mpiwg-berlin.mpg.de
> wrote:

> Hi Rainer,
>
> On 22.11.12 12:08, Simon Rainer wrote:
> > +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.)
>
> Sounds good to me. So Openlayers uses lat/lon coordinates?
>

In terms of practical examples, Open Annotation has a wiki that's sort of
buried over at the W3C site. In this example, both Well-Known-Text and SVG
are used to select part of a map. It might give us some inspiration:
http://maphub.github.com/api/#comment_example


>
> > 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 }
>
> Looks Ok to me. A small thing: I would like to use a lower case type
> "polygon" similar to the SVG spec.
>
> I like your explicit coordinate pairs for polygon.
>

+1.

I'll defer judgment on whether it's best to use a string or a series of x-y
objects, but I wonder if including units is useful? Couldn't we just
specify that they are always normalized to 0-1 range? Is there a good
reason not to do this? One advantage I see is that it makes it possible to
apply the shape to a scaled image without knowing the scale / the size of
the original. This seems the simplest thing to me.


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

There's been a lot of discussion on the OA list recently about composite vs
fallback selections and how to specify and handle them. It's a really
thorny issue. I'm not 100% convinced that it's necessary (for many use
cases) to be so explicit. I think the common case is progressively better
anchorings, like you describe, where the selection is specified in multiple
ways with no indication of interdependence, precedence, etc.


>
> I think the "anchorPoint" is OK since it enhances the shape. Something
> doesn't have to be a place name to have an anchor point. But I agree
> that parts specifying the semantics of the annotation should be on the
> annotation rather than on the shape.
>

+1. To me that looks like an altogether separate anchoring.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/annotator-dev/attachments/20121124/34386edb/attachment-0002.html>