This version:
http://www.openannotation.org/spec/alpha1/
Latest version:
http://www.openannotation.org/spec/
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 Description Document
     2.3 Additional Properties and Relationships
     2.4 Versioning of Annotations
     2.5 Inline Content
     2.6 Segments of Resources
     2.7 Multiple Targets
     2.8 Time Dependent Annotations
     2.9 Replying to Annotations
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 events in which the annotator creates a relationship between two or more resources, at a point in time.

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.

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
dc http://purl.org/dc/elements/1.1/ Dublin Core elements [DC Elements]
dcterms http://purl.org/dc/terms/ Dublin Core terms [DC Terms]
dcmitype http://purl.org/dc/dcmitype/ Dublin Core types [DC Types]
foaf http://xmlns.com/foaf/0.1/ Friend of a Friend vocabulary terms [FOAF]
lode http://linkedevents.org/ontology/ Linking Open Descriptions of Events terms [ref]
oac http://www.openannotation.org/ns/ OAC vocabulary terms [OAC]
ore http://www.openarchives.org/ore/terms/ ORE vocabulary terms
owl http://www.w3.org/2002/07/owl# OWL vocabulary terms [OWL]
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 'ex' namespace is a fictional namespace which does not resolve to anything.

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 event in which an association is created between a Content resource and a Target resource. The Content must be somehow "about" the Target for the event to be considered an Annotation. By default, the 'aboutness' relationship is oac:annotates, with the Content as the subject and the Target as the object. This relationship is not necessarily made explicit in the model, it can be inferred from the presence of Annotation, Content and Target. This gives rise to a tripartite base model with the same basic structure as that of Annotea [ref:annotea].

Figure 1: Baseline Model

Both the Content 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)
An event in which the association between Content and Target resources is created. An Annotation is a Non-Information Resource [ref:noninfores], as it is an event and does not have a representation.
oac:Annotation is a subClass of lode:Event
oac:Content (S-1)
The content of the annotation. The Content is somehow about the Target resource. That is, the Content is the subject of the oac:annotates relationship and the Target is the object.
oac:Target (T-1)
The resource that is the object of the oac:annotates relationship, in which the Content is the subject.

And the following relationships:

oac:hasContent
The relationship between Annotation and Content.
oac:hasTarget
The relationship between Annotation and Target.
oac:annotates
The relationship to be inferred between Content and Target.

Example

A user creates a video that discusses an image. The video is therefore the Content 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:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFVhttp://www.youtube.com/watch?v=fgg2tpUVbXQ
RDF Transcription
ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent ex:HDFV .

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

2.2 Transcription

Since the Annotation event is a non-information resource, we need a document (information resource) that describes the event in order to transmit the information about the Annotation and its related resources. This should be in one of the RDF serialization format. This document is called a Transcription and 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 Transcription's URI, the server will return the serialization.

Figure 2: Transcription of Annotation

Ontology

Classes:
oac:Transcription
Document that transcribes (eg describes) the Annotation
Relationships:
oac:transcribes
A Transcription document transcribes an Annotation.
oac:isTranscribedBy
The inverse relationship from an Annotation to a Transcription, for example to link from the Annotation described in the Transcription document to other Transcriptions of the same Annotation.

Example

Example 2: Transcription Document
Model Instance
URI Table
oac:Transcriptionhttp://www.openannotation.org/ns/Transcription
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:transcribeshttp://www.openannotation.org/ns/transcribes
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
ex:Trnshttp://www.example.org/annotation/1/ttl
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFVhttp://www.youtube.com/watch?v=fgg2tpUVbXQ
dc:formathttp://www.purl.org/dc/elements/1.1/format
dcterms:modifiedhttp://www.purl.org/dc/terms/modified
RDF Transcription
ex:Trns a oac:Transcription ,
         oac:transcribes ex:Anno ,
         dc:format "text/turtle" ,
         dcterms:modified "2010-04-01 12:00:00" .

ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent ex:HDFV .

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

2.3 Additional Properties and Relationships

As an Annotation is a resource with a URI, additional properties and relationships can be attached to it. As an event, it should have a timestamp of when it occured (dcterms:created and a reference to the agent that initiated it (dcterms:created). It may also have a more expressive relationship than oac:annotates between the Content and the Target (via oac:predicate).

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 Content 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

Ontology

This figure introduces the following classes:
foaf:Agent (U-1)
An agent, in this case the creator of the Annotation
rdfs:Property (P-1)
A relationship or property in RDF
And the following relationships:
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
oac:predicate
The relationship that exists between Content and Target

Example

Example 3: Additional Properties and Relationships
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:predicatehttp://www.openannotation.org/ns/predicate
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFVhttp://www.youtube.com/watch?v=fgg2tpUVbXQ
ex:Userhttp://www.example.org/user/jbloggs
ex2:commentaryAbouthttp://www.example.net/predicates/commentaryAbout
dc:titlehttp://www.purl.org/dc/elements/1.1/title
dcterms:creatorhttp://www.purl.org/dc/terms/creator
dcterms:createdhttp://www.purl.org/dc/terms/created
foaf:namehttp://xmlns.com/foaf/0.1/name
foaf:mboxhttp://xmlns.com/foaf/0.1/mbox
RDF Transcription
ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent ex:HDFV ,
          oac:predicate ex2:commentaryAbout , 
          dc:title "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:Content .         

2.4 Updating Annotations via Versioning

As they are events, Annotations cannot change and an update to an Annotation is thus a new Event -- a new Annotation that replaces the older one. The suggested relationship is dcterms:replaces, however other versioning relationships exist that may be more appropriate in certain circumstances. It must be noted that Content and Target can change independently of the Annotation, for example an Annotation with the home page of a popular news website as its Target will quickly be targeting a resource with a very different respresentation from when the Annotation was created. Please see section 2.8 for more information about robustness of annotations in time.

A new Annotation should be created instead of changing an Annotation to point to a new Content URI, for example. Correcting an error in the Transcription is permissible, however fundamentally changing the graph of interconnected resources is not.

Figure 4: Versioning

Example

Example 4: Versioning
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
ex:Annohttp://www.example.org/annotation/1/
ex:Ann2http://www.example.org/annotation/2/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
dcterms:replaceshttp://www.purl.org/dc/terms/replaces
RDF Transcription
ex:Ann2   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent tw:12538647644 ,
          dcterms:replaces ex:Anno .

ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent tw:12538590890 ,

ex:HDFI-1      a oac:Target .
tw:12538590890 a oac:Content .
tw:12538647644 a oac:Content .       

2.5 Inline Content

The Content resource can have representations in any format. However, the Content's representation is typically plain text and this is handled according to the baseline model if the Content has a URI. There are many services online that will provide URIs for text, such as Twitter, various blog platforms and services, and various document hosting services such as Google Docs for longer texts.

To allow for the situation when the annotation client wants simply to put the text, or other encoded content, directly into the Transcription document, we can assign a unique non-resolvable URI (called a URN) as the identifier for the Content. 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].

In this case, the Content has a class of oac:Note. This is a hint to clients that the representation of the resource is also included in the document, and hence there is no need to dereference the URI of the resource. The text is then the literal object of the oac:body relationship attached to the oac:Note.

Figure 5: Inline Content

Ontology

This section introduces the following class:
oac:Note (URN)
A subclass of oac:Content, which includes its own content in the body property. The use of oac:Note is a hint to clients that there is no need to dereference the URI in order to retrieve the data.
And the following property:
oac:body
The value of the oac:body property is the inlined representation of the oac:Note resource

Examples

Example 5: Inline Content
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:Targethttp://www.openannotation.org/ns/Target
oac:Notehttp://www.openannotation.org/ns/Note
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:bodyhttp://www.openannotation.org/ns/body
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex3:uuidurn:uuid:074360F6-19F9-49A0-83BF-A07FEEF09D5D
RDF Transcription
ex:Anno   a oac:Annotation ,
          oac:hasTarget ex:HDFI-1 ,
          oac:hasContent ex3:uuid .

ex3:uuid a oac:Note ,
          oac:body "This image is very impressive!" .

ex:HDFI-1 a oac:Target .         

2.6 Segments of Resource

The user (or software agent) must be able to select a part of the resource as the Content 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 Content may be a paragraph within a longer text.

2.6.1 Media Fragments

The W3C Media Fragment URI specification [ref:W3CMFURI] allows us to create a URI that identifies a segment of a resource for many common cases. Briefly, Media Fragments work by appending a fragment to the URI of the full resource that describes the section of interest. 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 which is the object of the hasContent or hasTarget relationship of the Annotation. The data model is therefore the same as the baseline described in section 2.1.

Example 6.1: Media Fragments
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1#xywh=50,100,640,480http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg#xywh=50,100,640,480
tw:6312261983http://twitter.com/---/status/6312261983
RDF Transcription
ex:Anno a oac:Annotation ,
        oac:hasContent tw:6312261983 ,
        oac:hasTarget ex:HDFI-1#xywh=50,100,640,480 .

tw:6312261983 a oac:Content .
ex:HDFI-1#xywh=50,100,640,480 a oac:Target .

2.6.2 Segment Descriptions

However, the Media Fragments work can only describe simple rectangular cases for segments of images, and there is a need for non rectangular boundaries in order to accurately capture the part of a resource which is the Target or Content of an Annotation. For example, if the region of interest spanned approximately a diagonal line from one corner of the image to the opposite corner, then a rectangular box would include the entire image. Also, there are many more media types that are not covered in the specification. For example, one might want to annotate a slice of a dataset, a gene within a particular biological model, or a component within a 3 dimensional model.

In order to allow for these use cases, the approach taken is to include a pointer to a resource which describes the segment of interest. The content of this resource will be dependent on the type of the resource for which the segment is described. It is then up to the annotation client to interpret the data with respect to the segmented resource. This segment cannot be attached directly to the Content or Target, as it is only true within the context of the Annotation rather than true in all circumstances. This requires adding a Context node, which stands for the Content or Target within the context of the Annotation.

Figure 6.2: Segment Descriptions

Ontology

Classes introduced in this section:
oac:Context (C-1, C-2)
The Context node stands for the Target or Content within the context of the Annotation.
oac:SegmentDescription (SD-1, SD-2)
The SegmentDescription is a resource which contains a description of a segment of another resource.
Relationships introduced:
oac:hasTargetContext
The relationship from the Annotation to a Context node that is about the Target of the Annotation.
oac:hasContentContext
The relationship from the Annotation to a Context node that is about the Content of the Annotation
oac:contextAbout
The relationship from the Context node to the Target or Content which the Context is about.
oac:hasSegmentDescription
The relationship from the Context node to the SegmentDescription that describes the segment of the Target of Content which the Context is about.

Example

Example 6.2: Segment Descriptions
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:Contexthttp://www.openannotation.org/ns/Context
oac:SegmentDescriptionhttp://www.openannotation.org/ns/SegmentDescription
oac:hasTargetContexthttp://www.openannotation.org/ns/hasTargetContext
oac:contextAbouthttp://www.openannotation.org/ns/contextAbout
oac:hasSegmentDescriptionhttp://www.openannotation.org/ns/hasSegmentDescription
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
tw:6312261983http://twitter.com/---/status/6312261983
ex:Ctxthttp://www.example.org/context/1/
ex:Sdschttp://www.example.org/segdesc/1/svg
dc:formathttp://www.purl.org/dc/elements/1.1/format
RDF Transcription
ex:Anno a oac:Annotation ,
        oac:hasContent tw:6312261983 ,
        oac:hasTarget ex:HDFI-1 ,
        oac:hasTargetContext ex:Ctxt .

ex:Ctxt a oac:Context ,
        oac:contextAbout ex:HDFI-1 , 
        oac:hasSegmentDescription ex:Sdsc .
             
ex:Sdsc a oac:SegmentDescription ,
         dc:format "image/svg+xml" .

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

2.7 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.

The oac:predicate applies uniformly from the Content to each of the Targets individually. For example, if the predicate is the default oac:annotates, then the inferred relationships are that Content oac:annotates Target-1, and Content oac:annotates Target-2.

Figure 7: Multiple Targets

Example

Example 7: Multiple Targets
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:predicatehttp://www.openannotation.org/ns/predicate
oac:annotateshttp://www.openannotation.org/ns/annotates
ex:Annohttp://www.example.org/annotation/1/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
ex:HDFI-2http://imgsrc.hubblesite.org/hu/db/images/hs-1996-01-a-full_tif.tif
tw:10994605527http://twitter.com/---/status/10994605527
RDF Transcription
ex:Anno a oac:Annotation ,
        oac:predicate oac:annotates ,
        oac:hasTarget ex:HDFI-1 ,
        oac:hasTarget ex:HDFI-2 ,
        oac:hasContent tw:10994605527 .

ex:HDFI-1 a oac:Target .
ex:HDFI-2 a oac:Target .
tw:10994605527 a oac:Content .

2.8 Timeless and 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 event. 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 oac:when property from either the Annotation or the Content 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 oac:when property.
  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 Context nodes for each resource, again using the oac:when property.

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

Figure 8: 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 Context node, it refers to the resource which that Context is about.

Examples

Example 8.1: Uniform Time
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:whenhttp://www.openannotation.org/ns/when
ex:Annohttp://www.example.org/annotation/1/
ex:cnnhttp://www.cnn.com/
tw:11002497449http://twitter.com/---/status/11002497449
RDF Transcription
ex:Anno a oac:Annotation ,
        oac:hasTarget ex:cnn ,
        oac:hasContent tw:11002497449 ,
        oac:when "2010-03-27 15:05:00" .

ex:cnn a oac:Target .
tw:11002497449 a oac:Content .
Example 8.2: Varied Time
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:hasTargetContexthttp://www.openannotation.org/ns/hasTargetContext
oac:hasContentContexthttp://www.openannotation.org/ns/hasContentContext
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:whenhttp://www.openannotation.org/ns/when
ex:Annohttp://www.example.org/annotation/1/
ex:Ctx1http://www.example.org/context/1/
ex:Ctx2http://www.example.org/context/2/
ex:cnnhttp://www.cnn.com/
ex:mlbhttp://www.mlbdailydish.com/
RDF Transcription
ex:Anno a oac:Annotation ,
        oac:hasTarget ex:cnn ,
        oac:hasContent ex:mlb ,
        oac:hasTargetContext ex:Ctx2 ,
        oac:hasContentContext ex:Ctx1 .

ex:Ctx1 a oac:Context ,
        oac:contextAbout ex:mlb ,
        oac:when "2010-04-20 13:45:00" .

ex:Ctx2 a oac:Context ,
        oac:contextAbout ex:cnn ,
        oac:when "2010-04-20 12:00:00" .

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

2.9 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 oac:predicate of the replying Annotation should be oac:repliesTo.

Figure 9: Replying to an Annotation

Ontology

oac:repliesTo
The inferred relationship between the Content of an Annotation that replies to another as its Target

Example

Example 9: Replying to an Annotation
Model Instance
URI Table
oac:Annotationhttp://www.openannotation.org/ns/Annotation
oac:hasTargethttp://www.openannotation.org/ns/hasTarget
oac:hasContenthttp://www.openannotation.org/ns/hasContent
oac:Targethttp://www.openannotation.org/ns/Target
oac:Contenthttp://www.openannotation.org/ns/Content
oac:repliesTohttp://www.openannotation.org/ns/repliesTo
ex:Annohttp://www.example.org/annotation/1/
ex:Ann2http://www.example.org/annotation/2/
ex:HDFI-1http://commons.wikimedia.org/wiki/File:Hubble_ultra_deep_field.jpg
tw:12665505503http://twitter.com/---/status/12665505503
tw:12665463062http://twitter.com/---/status/12665463062
RDF Transcription
ex:Ann2 a oac:Annotation ,
        oac:hasContent ex:12665505503 ,
	oac:hasTarget ex:Anno ,
	oac:predicate oac:repliesTo .

ex:Anno a oac:Annotation ,
        oac:hasTarget ex:12665463062 ,
	oac:hasContent ex:HDFI-1 .

ex:HDFI-1 a oac:Target .
tw:12665505503 a oac:Content .
tw:12665463062 a oac:Content .	

3. References

[Creative Commons]
Creative Commons, Creative Commons, May 18 2008. Website http://creativecommons.org/
[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/

A. Acknowledgements

B. Change Log

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