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