[annotator-dev] Multiple Ranges

[Randall Leeds]

On Wed, Mar 6, 2013 at 11:06 AM, Abel Corver <contact at abelcorver.com> wrote:
> @Ernesto: I'm planning to implement this "link to other annotation"
> functionality soon for Hypothes.is. The code will as far as I can see be
> written in the Hypothes.is fork of Annotator though, so it'd be great if you
> want to cooperate on this. As I see it now, we need two things:

Make sure you connect with Gergley, who is also beginning this work.

>
> (1) An extra "grab URL" button that pops up when you highlight a piece of
> text, which returns a unique URL to that particular range. The information
> could either be completely stored in the URL, or the URL might be a
> shortened version that can be used to request all the information from the
> database.
>
> (2) Functionality that will display annotations differently when the
> Annotator 'notices' that a URL to another annotation has been inserted. It
> might for example display the other comment side-by-side. Markdown already
> supports URLs, so it should simply be a matter of displaying the URL
> differently.
>
> (3) We also might want to store the annotation-to-annotation separately - in
> addition to as part of the annotation body - so that it is easy to query
> "references" and "referenced by" information. That way the user can navigate
> "both ways"

In Hypothes.is so far, I had hacked together a threaded reply system
which functions something like email headers.

An annotation with a "thread" field is expected to contain a
'/'-delimited list of annotation IDs from oldest ancestor to parent.
This makes it easy to do a prefix search in the database and get the
entire conversation from any point. Since we have a different viewer,
we use the JWZ threading algorithm to assemble the conversation tree
client side and then display them in a tree view in a sidebar. For
annotator, the replies could just be added to the range span data for
the parent, in "conversation prefix order" or something. Indentation
optional.

If people like this scheme, I can pull out the threading code and put
it in a vanilla Annotator plugin which has no knowledge of the
display. From there, I'll leave it to the community to decide how the
Annotator interface shows them.

I've been thinking about linking to annotations as well. If
annotations have URLs which can be retrieved as HTML and these pages
only show the annotation body, but not the target, that's not maybe
not ideal. Yesterday, it occurred to me that there can be multiple
targets, so we could make some presentational intent explicit in the
URL.

A URL of the form https://hypothes.is/<
annotationID> would show a
standalone page with the annotation (or maybe frame the original site,
if it doesn't mind).

A URL of the form
https://hypothes.is/<annotationID>/<target_scheme>/<target_host_port>/<target_path>
would request that a conforming user agent (one with an annotator
built in) show the annotation in context on the target resource,
redirecting to the target.

However, I think that the idea of a reply as an annotation on an
annotation shouldn't be forgotten. I will change our code to store the
parent as a target.

We have also begun to move toward a data format which allows for
multiple targets (even pointing to distinct pages), not just multiple
ranges (ranges are only one kind of selector on a resource). It is
still JSON, but should be structured such that a JSON-LD context could
easily provide all the OpenAnnotation schema information without any
further transformation.

The user interface challenge of giving people the ability to weave
together references between pages is still very much open