[annotator-dev] Annotator and yuma-js media annotation toolkit?

[Rufus Pollock]

On 18 January 2012 21:38, Randall Leeds <tilgovi at hypothes.is> wrote:
> On Wed, Jan 18, 2012 at 11:00 AM, Simon Rainer <Rainer.Simon at ait.ac.at> wrote:
>> Hi Andrew,
>>
>> that sounds great! I'll stay tuned.
>>
>> <I wonder what more specifics you have in mind for interoperability.>
>>
>> Still need to dive into the details of Annotator to be able to tell that, I guess. But the main thing that occured to me is that Yuma (=working title for our tool) might be able to fill a niche where only parts of content embedded in a Web page should be annotated; in particular when it's about more "exotic" media types. (We already have support for maps, zoomable images, and audio/video is in preparation.)
>
> I looked at the Yuma demos and it's great. One thing about the current
> Annotator storage is that it extracts the text under the selected area
> and uses native selection I think, whereas Yuma uses the mouse events
> to drag a box over the page. Is there any reason why we couldn't use
> cancellation of mouse events to drag a custom selection overlay over
> the page? Then we could look at elementFromPoint() of the top-left and
> bottom-right points in this rectangle and do a search for the least
> common ancestor DOM element. Anyway, alternative selection behaviours
> and selection of rich media is a topic that interests me.
>
>>
>> Also, I thought there might be a chance to join forces somehow regarding server-side annotation storage. Our goal was always to make it easy for people to set up their own storage server, integrated with their own environment, login infrastructure, etc. At the same time, we've also been having the vision of a central hosting service for people who can't or don't want to set up their own solution (or who'd rather participate in a larger "social annotation network"). While I feel there are a few differences in how we approach things, we seem to share the fundamental ideas.
>>
>
> I'm working on a new store right now. The annotator store plugin today
> is JSON and the reference implementation is CouchDB + Werkzeug.

More specifically Flask than Werkzeug :-)

We also had a reference SQL based implementation until recently. I
also think we want to move away from CouchDB to either RDBMS or to
ElasticSearch, see:

<https://github.com/okfn/annotator-store/issues/24>

I also note several people have implemented custom stores for their
particular backend.

> However, the data model I'm aiming to work with is richer than the one
> used by the store plugin today. I'm tempted to go down the JSON-LD

I note that you can store *any* kind of data in the backend under the
current structure. The backend (and the frontend) will transparently
store any date you wish. Of course, particular plugins will utilize
particular fields but I should emphasize that annotator (both frontend
and backend) support an arbitrary data model.

> route, which seems to be gaining momentum, and exploring the current
> work on JSON-LD <-> RDFa conversions that have good fidelity. I also

We've been interested in JSON-LD for a while -- we tried using JSON-LD
quite heavily for a bibliographic data project earlier this year [1].
The issue we found there was providing good reliable round-trip
serialization to RDF. However, I think it is improving rapidly. In
addition I note that the design of JSON-LD is such that you can almost
'drop' it in to an existing JSON format you have.

I also think looking at JSON schema could be useful here.

[1]: http://lists.okfn.org/pipermail/openbiblio-dev/2011-April/000236.html

> want to wrap up an out-of-the-box solution that provides a basic
> annotation server. The vision (tentative) is that clients that wish to
> can consume the JSON directly, but CouchDB can render templates to
> generate RDFa for search engines and dumb clients. Even if it doesn't
> have advanced directory capabilities built-in it might IMO provide a
> great solution for personally hosting annotations if I can make this a
> pure CouchApp.

The first implemenation of AnnotateIt (called CommentOnIt) was written
as a CouchApp. We've moved away from that for a variety of reasons (at
least at the time CouchApp had some significant drawbacks especially
around auth ...).

>> But there are certainly other aspects I haven't thought about yet. Maybe we can even identify some low-hanging fruit for short-term cooperation, who knows. But in any case: it's always good to coordinate and join forces, so I'm happy get into discussion! :-)
>
> That's the first I've chimed in on this list. I hope I'm not hijacking
> the thread. Looking forward to playing with all this stuff.

Not at all and it's great to have your thoughts -- looking forward to
much more discussion!

Rufus

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



-- 
Co-Founder, Open Knowledge Foundation
Promoting Open Knowledge in a Digital Age
http://www.okfn.org/ - http://blog.okfn.org/