This version:
http://www.openannotation.org/spec/alpha2/
Latest version:
http://www.openannotation.org/spec/
Previous version:
http://www.openannotation.org/spec/alpha1/
Editors
Robert Sanderson, Los Alamos National Laboratory
Herbert Van de Sompel, Los Alamos National Laboratory

Abstract

The Open Annotation Data Model specifies an approach for associating annotations with resources, using a methodology conformant with the Architecture of the World Wide Web and the Linked Data initiative. It draws on the Annotea model, as well as more recent extensions of that model.


Table of Contents

1. Introduction
     1.1 Notational Conventions
     1.2 Namespaces Used
     1.3 Note about Examples
2. OAC Data Model
     2.1 Baseline Model
     2.2 Resource Map
     2.3 Additional Properties and Relationships
     2.4 Segments of a Resource
     2.5 Inline Information
     2.6 Multiple Targets
     2.7 Time Dependent Annotations
     2.8 Replying to an Annotation
3. References

Appendices

A. Acknowledgements
B. Change Log


1. Introduction

Annotating, the act of associating one piece of information with one (or more) other piece(s) of information, is a pervasive activity shared by all humanity across all walks of life. Scholars and academics use annotations as part of their daily research, however many more web citizens make comments about online resources using either tools built in to the hosting web site, external web services, or the functionality of an annotation client. Comments about photos on Flickr, videos on Youtube, people's posts on Facebook, or resources mentioned on Twitter could all be considered as annotations associated with the original resource. There are a plethora of silo oriented web-based "sticky note" systems, such as Google's Sidewiki, and stand-alone multimedia annotation systems. The primary complaint about these systems is that the annotation is locked in to the web site or tool which was used to create them, and cannot be seen or managed with any of the other systems.

Annotating is also a pervasive element of scholarly practice for both the humanist and the scientist. It is a method by which scholars organize existing knowledge and facilitate the creation and sharing of new knowledge. It is used by individual scholars when reading as an aid to memory, to add commentary, and to classify, but more importantly it can also facilitate shared editing, scholarly collaboration, and pedagogy. Annotations can have value in their own right, as a means of scholarly communication.

Yet scholars also remain dissatisfied with the options available for annotating digital resources. Scholars wanting to annotate are in the same position of having to learn different annotation clients for different content repositories, have no easy way to integrate annotations made on different systems or created by colleagues using other tools, and are often limited to simplistic and constrained models of annotation.

The Open Annotation data model provides an interoperable method of describing annotations such that they can easily be shared between platforms, with sufficient richness of expression to satisfy scholars' needs while remaining simple enough to also allow for common use cases such as attaching a piece of text to a single web resource. Annotations are modeled as a set of connected resources, including a body and one or more targets, where the body is somehow about those targets.

Unlike previous attempts, the Open Annotation system does not prescribe a protocol for creating, managing and retrieving annotations. Instead it describes a web-centric method, founded on the ideas of the Linked Data initiative, which enables discovery and sharing of annotations without clients or servers having to agree on a particular set of operations on those annotations. This publish/discover approach is described in a companion document [not yet available].

1.1 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [IETF RFC 2119].

1.2 Namespaces Used

This specification uses the following namespaces and prefixes to indicate those namespaces:

Prefix Namespace URI Description
cnt http://www.w3.org/2008/content# Content in RDF [Content]
dc http://purl.org/dc/elements/1.1/ Dublin Core elements [DC Elements]
dcterms http://purl.org/dc/terms/ Dublin Core terms [DC Terms]
foaf http://xmlns.com/foaf/0.1/ Friend of a Friend vocabulary terms [FOAF]
oac http://www.openannotation.org/ns/ OAC vocabulary terms [OAC]
ore http://www.openarchives.org/ore/terms/ ORE vocabulary terms
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# RDF vocabulary terms [RDF Vocabulary]
rdfs http://www.w3.org/2001/01/rdf-schema# RDF Schema vocabulary [RDF Vocabulary]

1.3 Notes about Examples

The examples below are presented in the Turtle [Turtle] format for RDF.

The examples below use the following resources. Representations of these resources are included in the diagrams below.

2. OAC Data Model

2.1 Baseline Model

An Annotation is an association created between a Body resource and a Target resource. The Body must be somehow "about" the Target for the event to be considered an Annotation. This gives rise to a tripartite base model with the same basic structure as that of Annotea [Annotea], however we consider the body and targets as a bounded aggregation of resources prompting the use of the ORE specifications as a baseline.

Figure 1: Baseline Model

Both the Body and the Target of the Annotation can be any resource on the web, identified by a URI. As such, they can have representations in any format, language (or no language), location, creator, and so forth, or no representations at all, such as for resources that denote a concept.

Ontology

This baseline model includes the following classes:

oac:Annotation (A-1)
The association between Body and Target resources. An Annotation is a Non-Information Resource [ref:noninfores], and does not have a representation. It can be considered as the reification of an 'annotates' relationship between Body and Target resources. As an aggregation of resources with its own identity, oac:Annotation is a subClass of ore:Aggregation. For more information about ore:Aggregations, please see the ORE Specification.
oac:Body (B-1)
The body or content of the annotation. The Body is somehow about the Target resource. It is the information which is annotating the Target. Note that this class is only for illustrative purposes, as a resource can be a Body in one Annotation, and have the role of Target in another.
oac:Target (T-1)
The resource that is being annotated. Like oac:Body, the class is for illustrative purposes only.

And the following relationships:

oac:hasBody
The relationship between Annotation and Body. oac:hasBody is a subProperty of ore:aggregates.
oac:hasTarget
The relationship between Annotation and Target. oac:hasTarget is a subProperty of ore:aggregates.

Example

A user creates a video that discusses an image. The video is therefore the Body of the Annotation, and the image is the Target, as the video is about the image.
Example 1: Baseline Model
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFV http://www.youtube.com/watch?v=fgg2tpUVbXQ
RDF
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 .         

2.2 Resource Map

Since the Annotation is a non-information resource, we need a document (information resource) that describes the Annotation and its related resources. This should be in one of the RDF serialization formats. As an Annotation is an ore:Aggregation, we describe it using a Resource Map which contains all of the triples for the Annotation and related objects, according to this data model. When an HTTP GET request is issued to the Resource Map's URI, the server will return the serialization.

We reuse the ore:ResourceMap class and related predicates directly.

Figure 2: Resource Map for an Annotation

Vocabulary Note

Classes Defined Elsewhere:
ore:ResourceMap
Document that describes the Annotation
Relationships Defined Elsewhere:
ore:describes
The Resource Map describes an Annotation.
ore:isDescribedBy
The inverse relationship from an Annotation to a Resource Map. For example to link from the Annotation described in the current Resource Map to other Resource Maps for the same Annotation.

Example

Example 2: ResourceMap Document
Model Instance
URI Table
ore:ResourceMap http://www.openarchives.org/ore/terms/ResourceMap
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ore:describes http://www.openarchives.org/ore/terms/describes
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
ex:ReM http://www.example.org/annotation/1/resourceMap.xml
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFV http://www.youtube.com/watch?v=fgg2tpUVbXQ
dc:format http://www.purl.org/dc/elements/1.1/format
dcterms:modified http://www.purl.org/dc/terms/modified
RDF
ex:ReM a ore:ResourceMap ,
         ore:describes ex:Anno ,
         dc:format "application/rdf+xml" ,
         dcterms:modified "2010-06-10 12:00:00" .

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 .         

2.3 Additional Properties and Relationships

As an Annotation is a resource with a URI, additional properties and relationships can be attached to it. It should have a timestamp of when the annotation relationship was created (dcterms:created) and a reference to the agent that created it (dcterms:creator).

Resources referenced by additional relationships may themselves have additional properties and relationships. The set of relationships below is by no means exhaustive: other relationships and properties not described here may also be used.

It is also important to note that the properties and relationships attached to the Annotation do not necessarily have the same values as for either the Body or the Target. The same property may be used on each of the three different resources with different values.

Figure 3: Additional Properties and Relationships

Vocabulary Note:

Classes Defined Elsewhere:
foaf:Agent (U-1)
An agent, in this case the creator of the Annotation
Relationships Defined Elsewhere:
dc:title
The name of the Annotation
dcterms:creator
The creator of the Annotation
dcterms:created
The time and date at which the Annotation was created
foaf:name
The name of the creator
foaf:mbox
The email address of the creator

Example

Example 3: Additional Properties and Relationships
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFV http://www.youtube.com/watch?v=fgg2tpUVbXQ
ex:User http://www.example.org/user/jbloggs
dc:title http://www.purl.org/dc/elements/1.1/title
dcterms:creator http://www.purl.org/dc/terms/creator
dcterms:created http://www.purl.org/dc/terms/created
foaf:name http://xmlns.com/foaf/0.1/name
foaf:mbox http://xmlns.com/foaf/0.1/mbox
RDF
ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasBody ex:HDFV ,
          dc:title "Annotation of Hubble Deep Field Image" ,
          dcterms:creator ex:User ,
          dcterms:created "2010-02-01 12:34:56" .

ex:User   a foaf:Agent ,
          foaf:name "J. Bloggs" ,
          foaf:mbox "jbloggs@example.org" .

ex:HDFI-1 a oac:Target .
ex:HDFV   a oac:Body .         

2.4 Segments of a Resource

The user (or software agent) must be able to select a part of the resource as the Body or Target for their Annotation, not just the entire resource. Many Annotations have this requirement, as resources can be arbitrarily large and frequently there is only a small part of interest. For example, the Target may be a section of an image or a video, or the Body may be a paragraph within a longer text.

2.4.1 Segment Descriptions

In order to allow for all such use cases, the approach taken is to include a pointer to a resource which describes the segment of interest. The nature of this description will be dependent on the type of the resource for which the segment is conveyed. It is then up to the annotation client to interpret the segment description with respect to the segmented resource. For example, an SVG path element could be used to describe an area within an image, a SPARQL or SQL query could be used to describe a slice of a database, or a series of XPaths or XPointers could be used to identify the appropriate parts of an XML file.

This segment cannot be attached directly to the Body or Target, as it is only true within the context of the Annotation rather than true in all circumstances. This is a restriction of the RDF data model, as all statements must be globally true, not only true within a particular graph or description. This requires adding a Proxy node, which stands for the Body or Target within the context of the Annotation.

Figure 4.1: Segment Descriptions

Ontology

Classes:
ore:Proxy (P-1)
The Proxy node stands for the Target or Body within the context of the Annotation.
oac:SegmentDescription (SD-1)
The SegmentDescription is a resource which contains a description of a segment of another resource.
Relationships:
ore:proxyIn
The relationship from the Proxy that stands for the Body or Target to the Annotation node.
ore:proxyFor
The relationship from the Proxy to the Body or Target that it is a proxy for in the context of the Annotation
oac:hasSegmentDescription
The relationship from the Proxy to the SegmentDescription that describes the segment of the Body or Target which the Proxy is about.

Example

Example 4.1: Segment Descriptions
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ore:Proxy http://www.openarchives.org/ore/terms/Proxy
oac:SegmentDescription http://www.openannotation.org/ns/SegmentDescription
ore:proxyFor http://www.openarchives.org/ore/terms/proxyFor
ore:proxyIn http://www.openarchives.org/ore/terms/proxyIn
oac:hasSegmentDescription http://www.openannotation.org/ns/hasSegmentDescription
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
tw:6312261983 http://twitter.com/---/status/6312261983
ex:Prox http://www.example.org/proxy/1/
ex:Sdsc http://www.example.org/segdesc/1/svg
dc:format http://www.purl.org/dc/elements/1.1/format
RDF
ex:Anno a oac:Annotation ,
        oac:hasBody tw:6312261983 ,
        oac:hasTarget ex:HDFI-1 .

ex:Prox a ore:Proxy ,
        ore:proxyIn ex:Anno ,
        ore:proxyFor ex:HDFI-1 , 
        oac:hasSegmentDescription ex:Sdsc .
             
ex:Sdsc a oac:SegmentDescription ,
         dc:format "image/svg+xml" .

tw:6312261983 a oac:Body .
ex:HDFI-1     a oac:Target .

2.4.2 Media Fragment URIs

The W3C Media Fragment URI specification [Media Fragments] allows the creation of a URI that identifies a segment of a resource for common cases. Briefly, Media Fragment URIs are created by appending a fragment that describes the section of interest to the URI of the full resource. For the easy case of images, this works by appending #xywh= and the top left x and y coordinates, width and height separated by commas. For example, a section of an image (http://www.example.com/image) which started at x=50 and y=100, and was 640 pixels wide and 480 pixels high, would result in the URI: http://www.example.com/image#xywh=50,100,640,480 Other dimensions exist for other media types including track number and a duration within the normal play time of a video or audio file. For more information, please see the specification [MediaFrags]

In this case, the fragment URI identifies the resource that is the Body or Target of the Annotation. The data model is therefore the same as the baseline described in section 2.1. with one exception. It is strongly recommended that the dcterms:isPartOf relationship be used, linking back to the resource's URI without the fragment, for user agents that do not understand Media Fragments.

The Media Fragment solution does not work for all cases, whereas the SegmentDescription approach does. Also, the Media Fragment specification is still actively being updated. Should it progress to a W3C recommendation, and be able to capture other types of segments, it would be recommended for use rather than the SegmentDescription approach above.

Figure 4.2: Media Fragments

Ontology

Relationships Defined Elsewhere:
dcterms:isPartOf
The related resource is logically part of the subject

Example

Example 4.2: Media Fragments
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1#xywh=50,100,640,480 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg#xywh=50,100,640,480
tw:6312261983 http://twitter.com/---/status/6312261983
RDF
ex:Anno a oac:Annotation ,
        oac:hasBody tw:6312261983 ,
        oac:hasTarget ex:HDFI-1#xywh=50,100,640,480 .

tw:6312261983 a oac:Body .

ex:HDFI-1#xywh=50,100,640,480 a oac:Target ,
          dcterms:isPartOf ex:HDFI-1 .

2.5 Inline Information

The baseline model assumes that all resources will have URIs, and be available on the web. Some clients may not be able to generate URIs on their own for the resources that are created as part of the annotation process. For example, it may be necessary for the client to transmit a single document (the Resource Map) which includes the Body as plain text, and any Segment Descriptions. There are many services online that will provide URIs for such text, such as Twitter, various blog platforms and services, and various document hosting services such as Google Docs for longer texts.

Likewise, a SegmentDescription could be a very small amount of data that could easily be included inline within the Resource Map. For example, a single SVG element to overlay on an image, an xpointer or xpath to identify a node within XML, or an SQL query to identify resources within a database.

To allow for the situation when the annotation client must simply put the data directly into the Resource Map, we can assign a unique non-resolvable URI (called a URN) as the identifier for the Body or SegmentDescription. It is suggested that a UUID be used, however any URN is possible. This would be appropriate for clients that function primarily offline, or cannot generate URIs for the text entered by the user. Servers which discover these URIs should rewrite them into HTTP URIs which they control. More information about this process is available in the companion publish/discovery document [ref].

The OAC data model leverages the W3C's "Representing Content in RDF" specification to include information directly within the Resource Map.

Figure 5.1: Inline Body

The same approach can be applied to Segment Descriptions.

Figure 5.2: Inline Segment Description

Ontology

Classes:
cnt:ContentAsText
Relationships:
cnt:chars
The representation of the resource, as plain text.
cnt:characterEncoding
The name of the character encoding of the object of the cnt:bytes property, such as "utf-8" or "ascii"

Examples

Example 5.1: Inline Body
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
cnt:ContentAsText http://www.w3.org/2008/content#ContentAsText
cnt:chars http://www.w3.org/2008/content#chars
cnt:characterEncoding http://www.w3.org/2008/content#characterEncoding
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:uuid urn:uuid:074360F6-19F9-49A0-83BF-A07FEEF09D5D
RDF
ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent 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 .         

Example 5.2: Inline Segment Description
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
cnt:ContentAsText http://www.w3.org/2008/content#ContentAsText
cnt:chars http://www.w3.org/2008/content#chars
cnt:characterEncoding http://www.w3.org/2008/content#characterEncoding
ore:proxyFor http://www.openarchives.org/ore/terms/proxyFor
ore:proxyIn http://www.openarchives.org/ore/terms/proxyIn
ore:Proxy http://www.openarchives.org/ore/terms/Proxy
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
tw:6312261983 http://twitter.com/---/status/6312261983
ex:Prox http://www.example.org/proxy/1/
ex:uuid urn:uuid:074360F6-19F9-49A0-83BF-A07FEEF09D5D
RDF
ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent tw:6312261983 .

ex:Prox   a ore:Proxy ,
          ore:proxyIn ex:Anno ,
          ore:proxyFor ex:HDFI-1 ,
          oac:hasSegmentDescription ex:Sdsc .

ex:uuid   a oac:SegmentDescription ,
          a cnt:ContentAsText ,
          dc:format "image/svg+xml" ,
          cnt:chars "" ,
          cnt:characterEncoding "utf-8" .

ex:HDFI-1 a oac:Target .
tw:6312261983 a oac:Body .

2.6 Multiple Targets

Annotations can be about multiple resources, such as Annotations that compare or contrast two resources. The data model therefore needs to allow for multiple Targets for a single Annotation. This can be handled simply by expressing multiple hasTarget relationships.

While the Annotation normally stands for the relationship between the Body and the Target node, if there are different relationships between the Body and individual Targets in the multiple Target scenario, it is encouraged to be explicit and include these relationships in the Resource Map.

Figure 6: Multiple Targets

Example

Example 6: Multiple Targets
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ex:Anno http://www.example.org/annotation/1/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFI-2 http://imgsrc.hubblesite.org/hu/db/images/hs-1996-01-a-full_tif.tif
tw:10994605527 http://twitter.com/---/status/10994605527
RDF
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 .

2.7 Time Dependent Annotations

The data served from a URI at any given time (the representation) is not necessarily the same as the representation served at any other time. For some resources the data is very frequently different, as in the case of news pages, search results and so forth. However the Annotation is likely to apply only to the resource as it was at the time of the Annotation. Furthermore, the Annotation could be created at a different time than the resources involved.

The data model distinguishes three different types of annotation, with respect to time. These can be distinguished via the use of the mem:when property from either the Annotation or the Body and Targets.

  1. Timeless Annotations: These Annotations are always relevant, and thus time is not a concern. The Annotation might be about the semantics of the resource, rather than the data served from it. For example, the Content "This is the homepage of CNN" would be true of the Target http://www.cnn.com/ regardless of what was currently on the page.
    Timeless Annotations do not need a timestamp for when to interpret the resources involved in the Annotation.
  2. Uniform Time Annotations: These Annotations are valid at a particular time, and all of the resources involved (the Content and the Targets) should be interpreted at that time. This would occur when the Content was created at the time the Target resource was delivering the data that the Content was about. For example, a tweet about the current stories on the CNN home page.
    Uniform Time Annotations need a single timestamp. This is attached to the Annotation node using the mem:when property from the Memento ontology [cite:memento].
  3. Varied Time Annotations: These Annotations are also dependent on time, however the resources involved should be interpreted at different times. This would occur when the Content was created at a different time to the state of the Target resource that it is about. An example content might be a blog post about the CNN home page of the previous day.
    Varied Time Annotations need a timestamp for each resource involved. They are attached to the Proxy for each resource, again using the mem:when property.

For further information about persistent annotations, please see our JCDL 2010 paper [JCDL 2010].

Figure 7: Timeless and Time Dependent Annotations

Ontology

Relationships:
oac:when
The timestamp at which the resource(s) should be interpreted. If attached to an Annotation, it refers to the Content and Targets. If attached to a Proxy, it refers to the resource which that Proxy is a proxy for.

Examples

Example 7.1: Uniform Time
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
mem:when http://www.mementoweb.org/terms/tb/when
ex:Anno http://www.example.org/annotation/1/
ex:cnn http://www.cnn.com/
tw:11002497449 http://twitter.com/---/status/11002497449
RDF
ex:Anno a oac:Annotation ,
        oac:hasTarget ex:cnn ,
        oac:hasBody tw:11002497449 ,
        oac:when "2010-03-27 15:05:00" .

ex:cnn a oac:Target .
tw:11002497449 a oac:Body .
Example 7.2: Varied Time
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasBody
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ore:proxyFor http://www.openarchives.org/ore/terms/proxyFor
ore:proxyIn http://www.openarchives.org/ore/terms/proxyIn
ore:Proxy http://www.openarchives.org/ore/terms/Proxy
mem:when http://www.mementoweb.org/terms/tb/when
ex:Anno http://www.example.org/annotation/1/
ex:Prx1 http://www.example.org/proxy/1/
ex:Prx2 http://www.example.org/proxy/2/
ex:cnn http://www.cnn.com/
ex:mlb http://www.mlbdailydish.com/
RDF
ex:Anno a oac:Annotation ,
        oac:hasTarget ex:cnn ,
        oac:hasBody ex:mlb .

ex:Prx1 a ore:Proxy ,
        ore:proxyFor ex:mlb ,
        ore:proxyIn ex:Anno ,
        mem:when "2010-04-20 13:45:00" .
        
ex:Prx2 a ore:Proxy ,
        ore:proxyFor ex:cnn ,
        ore:proxyIn ex:Anno ,
        oac:when "2010-04-20 12:00:00" .

ex:mlb a oac:Body .
ex:cnn a oac:Target .

2.8 Replying to an Annotation

Many systems allow users to reply to Annotations, for example to correct a misinterpretation or make a comment about the original. This is modeled as the first Annotation being the Target of the second Annotation. The class of the Annotation should be oac:Reply.

Figure 8: Replying to an Annotation

Ontology

Classes:
oac:Reply
The type of Annotation which is a reply to another Annotation. This is a subClass of oac:Annotation.

Example

Example 8: Replying to an Annotation
Model Instance
URI Table
oac:Annotation http://www.openannotation.org/ns/Annotation
oac:Reply http://www.openannotation.org/ns/Reply
oac:hasTarget http://www.openannotation.org/ns/hasTarget
oac:hasBody http://www.openannotation.org/ns/hasContent
oac:Target http://www.openannotation.org/ns/Target
oac:Body http://www.openannotation.org/ns/Body
ex:Anno http://www.example.org/annotation/1/
ex:Ann2 http://www.example.org/annotation/2/
ex:HDFI-1 http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
tw:12665505503 http://twitter.com/---/status/12665505503
tw:12665463062 http://twitter.com/---/status/12665463062
RDF
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 .	

3. References

[Annotea]
Kahan, J. Koivunen, M. et al. "Annotea: An Open RDF Infrastructure for Shared Web Annotations" Computer Networks 39 (2002) pp 589-608
[Creative Commons]
Creative Commons, Creative Commons, May 18 2008. Website http://creativecommons.org/
[JCDL 2010]
Making Web Annotations Persistent over Time, Sanderson, R, Van de Sompel, H. Procs. of the Joint Conference on Digital Libraries 2010, Surfers Paradise, Australia. (Presentation available)
[Linked Data]
How to Publish Linked Data on the Web, Bizer C. Cyganiak, R. Heath, T., 2007
[Media Fragments]
Media Fragments URI, W3C Working Draft, Troncy, R. Mannens, E (eds), 17 December 2009.
[Turtle]
Turtle - Terse RDF Triple Language, David Beckett, 20 November 2007. Available at http://www.dajobe.org/2004/01/turtle/
[Web Architecture]
Architecture of the World Wide Web, Volume One, I. Jacobs and N. Walsh, Editors, World Wide Web Consortium, 15 January 2004. Available at http://www.w3.org/TR/webarch/
[Further references to be added post review]

A. Acknowledgements

B. Change Log

Date Editor Description
2010-04-19 rsanderson Internal alpha release
2010-06-30 rsanderson External alpha2 release
 
Creative Commons LicenseThis work by the Open Annotation Collaboration is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.