A Proposal for Annotating Resources

Annotations to one target, multiple targets or between targets

The annotation models proposed here are a work in progress, developed in meetings with
the XML Group (Dirk Wintergruen, Robert Casties). There are also some classes we added
when looking at Rainer Simon’s work on Yuma.Min. Any errors presented here are but my
own.

We settled on the following use cases: simple annotations in the manner of stickers,
annotations to multiple targets, and annotations which establish a relationship between
two targets — a constant problem for triple storage which we can overcome by defining
the first target actually as body.

Simple Annotations

In the case of simple annotations regarding just one target — much in the manner of
Post-It stickers — and relating to the whole target body the RDF model is quite
simple:

Simple 1-target annotation model

The RDF model would look like this (link):

ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasBody ex:uuid .
ex:uuid   a oac:Body ,
          a cnt:ContentAsText ,
          cnt:chars "This image is very impressive!" ,
          cnt:characterEncoding "utf-8" .
ex:HDFI-1 a oac:Target .

The OAC model also provides for the definition of fragments, which act much like narrowing
down the target. Instead of using these target fragments, though, we prefer the OAC
constraint model — and for a reason: the use of constraints allows us to separate much
more strictly the general target (in pilot talk, the “target area”) and the exact
constraint (the “landing spot”). We think this is a better approach in terms of the
underlying logic, and even more so in the case of multiple targets (which we discuss
below).

OAC 1-target constraint model

The RDF model would look like this (link):

ex:Anno   a oac:Annotation ,
          oac:hasTarget uu1 ,
          oac:hasBody tw:6312261983 .
uu1       a oac:ConstrainedTarget ,
          oac:constrains ex:HDFI-1 ,
          oac:constrainedBy uu2 .
uu2       a oac:BoxConstraint ,
          img:x 100 ,
          img:y 500 ,
          img:w 250 ,
          img:h 150 .
tw:6312261983 a oac:Body .

Another reason for preferring the constraint model was the possibility to use constraint
specific predicates which define the boundaries, for example character strings before or
after a certain text. This in addition to the XPointer model, thus giving extra security
to be able to locate a text passage even if the ID/XPointer model has become useless
(e.g. after an unfortunate update including all IDs).

OAC 1-target constraint predicates model

Annotations to multiple targets

In the case of annotations to multiple targets — where all targets are thought to be
equal — not much has changed, if not the duplication of targets. Note that by
introducing groups (RDF “bags”) we could further structure these targets — but we’re
not sure, ultimately, if this is going to be a real-world scenario. Anyway, the
following OAC model applies:

OAC n-target model

The RDF model would look like this (link):

ex:Anno a oac:Annotation ,
        oac:hasTarget ex:HDFI-1 ,
        oac:hasTarget ex:HDFI-2 ,
        oac:hasBody tw:10994605527 .
ex:HDFI-1 a oac:Target .
ex:HDFI-2 a oac:Target .
tw:10994605527 a oac:Body .

Relationships between targets

The OAC model does not provide for a scenario where an annotation targets two bodies and
at the same time establishes a relationship bewteen them. A classic case is an
annnotation pointing to a chapter X in text A and a chapter Y in text B commenting that
text B/Y is a copy (translation, transcription, ecc.) of text A/X.

We can overcome this problem by making text A/X the body (sic) of the annotation, text
B/Y the target and introducing the rdf:type class for establishing the kind of
relationship. The following OAC model applies:

OAC body-target relationship model

The RDF model would look like this (link):

ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasBody ex:HDFV .
ex:HDFI-1 a oac:Target .
ex:HDFV   a oac:Body .

Replies to Annotations

Replies to annotations just cite the uuid of the referenced annotation as target. The
following OAC model gives an example, although an unnecessarily complex one because it
models the original annotation and the reply annotation together. Instead, a normal use
case would be two separate instances.

OAC reply model

The RDF model would look like this (link):

ex:Ann2 a oac:Reply ,
        oac:hasBody ex:12665505503 ,
        oac:hasTarget ex:Anno .
ex:Anno a oac:Annotation ,
        oac:hasBody ex:12665463062 ,
        oac:hasTarget ex:HDFI-1 .
ex:HDFI-1 a oac:Target .
tw:12665505503 a oac:Body .
tw:12665463062 a oac:Body .	

The relevant classes

Below a list of classes for the models discussed above. For the sake of convenience we
don’t include namespaces here.

rdf:type cnt:ContentAsText
ex:BoxConstraint
oac:Constraint
oac:Annotation
oac:Reply
oac:Translation
oac:Transcription
oac:Descendant …
the relationship type (text, image, constraints, …)
oac:hasBody uuid the body’s unique id
cnt:characterEncoding UTF-8 the message encoding – we prefer UTF-8 all the way
cnt:chars string the text payload
oac:hasTarget uuid the target’s unique ID
oac:constrains uuid the (constrained) target’s unique ID
img:x
img:y
img:w
img:h
integer * the image constraints, expressed using y: topLeft from top,
x: topLeft from left,
h: bottomRight from
top,
w: bottomRight from left
* Alternatively, fractions of 1 (0-1) are allowed for interaction with DigiLib.
oac:constrainedBy uuid the (constrained) body’s unique ID
xp:constrained XPointer the target string, constrained between two XPointers.
xp:before XPointer the string, defined by an XPointer, immediately before the constraint.
xp:after XPointer the string, defined by an XPointer, immediately after the constraint.
foaf:name URI the creator’s name
foaf:mbox URI the creator’s email
dcterms:creator string the creator group
dcterms:created string the time the comment was created, expressed in seconds
tags string optional user-defined tags, separated by comma. Note: not part of OAC.
scope public
private
the scope of the comment, i.e. public or private. Default is “public”. Note: not
part of OAC.
This entry was posted in Annotation and tagged . Bookmark the permalink.

Leave a Reply