This version:
http://www.openannotation.org/spec/extension/20120509.html
Latest version:
http://www.openannotation.org/spec/extension/
Previous version:
http://www.openannotation.org/spec/extension/20120501.html
Authors, Editors:
Robert Sanderson, Los Alamos National Laboratory
Paolo Ciccarese, Massachusetts General Hospital and Harvard Medical School
Herbert Van de Sompel, Los Alamos National Laboratory
Authors:
Tim Clark, Massachusetts General Hospital and Harvard Medical School
Tim Cole, University of Illinois at Urbana-Champaign
Jane Hunter, University of Queensland
Neil Fraistat, University of Maryland

Abstract

The Open Annotation Extension Specification describes Extensions to the Core Open Annotation data model to provide a mechanism for timely responses to cross-community requirements. It primarily defines subClasses of the Core classes with more explicit semantics and requirements, and provides recommended best practices for interoperability.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

Copyright © 2012 the Contributors to the Open Annotation Extension Specification, published by the Open Annotation Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

This specification was published by the Open Annotation Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

This document has been made available to the Open Annotation Community Group for review, but is not endorsed by them. This is a working draft, and it is not endorsed by the W3C or its members. It is inappropriate to refer to this document other than as "work in progress".

Please send general comments about this document to the public mailing list: public-openannotation@w3.org (public archives).


Table of Contents

  1. Introduction
    1. Namespaces
    2. Terminology
    3. Examples
  2. Classes
    1. Annotations
    2. Resources
    3. Agents
  3. Specifiers
    1. State
    2. Selector
      1. Text Selection by Offset
      2. Text Selection by Quotation
      3. Area Selection by SVG
    3. Style
      1. CSS Value Style
      2. XSLT Style
    4. Composite Specifiers
  4. Semantic and Data Annotations
    1. Semantic Tags
    2. Named Graphs
    3. Structured Resources
  5. Appendices
    1. References
    2. Acknowledgements
    3. Change Log

1. Introduction

There is a constant struggle in standards between stability and being flexible enough to deal with new requirements and use cases. The approach taken by Open Annotation is to split out the base-line functionality in a stable specification, from the Extensions specification which is intended to change at a modest rate based on community feedback.

This document describes the Extension namespace and recommended best practices for the use of the Open Annotation model. In particular, it describes subclasses of the Core Annotation and Specifiers, and provides guidance on the predicates and classes to describe resources in a way that will cover the majority of requirements without significant development costs.

1.1 Namespaces

The Open Annotation model defines two namespaces:

The Extension ontology is intended to be more fluid than the Open Annotation Core ontology, enabling responsiveness to community requirements. Before creating private extensions, communities should check this documentation to see if their requirements have already been accounted for. Also, if communities feel that their extension can be generally useful, then it should be discussed for inclusion within the Extension namespace.

The Core and Extension Namespace URIs will always remain the same, even if the ontology changes. All versions of the ontologies will remain available from version specific URLs, and the namespace URI will provide access to the most recent version.

The following namespaces are used in this document:

PrefixNamespaceDescription
oahttp://www.w3.org/ns/openannotation/core/ The core Open Annotation model
oaxhttp://www.w3.org/ns/openannotation/extensions/ Interoperable extensions to the core model
cnthttp://www.w3.org/2011/content#Representing Content in RDF
dchttp://purl.org/dc/elements/1.1/Dublin Core Elements
dctermshttp://purl.org/dc/terms/Dublin Core Terms
dctypeshttp://purl.org/dc/dcmitype/Dublin Core Type Vocabulary
foafhttp://xmlns.com/foaf/0.1/Friend-of-a-Friend Vocabulary
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#RDF
rdfshttp://www.w3.org/2001/01/rdf-schema#RDF Schema
trighttp://www.w3.org/2004/03/trix/rdfg-1/TriG Named Graphs

1.2 Terminology

The key words "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.

1.3 Examples

Examples used throughout the document will be conveyed as both a diagram and in the Turtle RDF format, and do not represent specific use cases with real resources. The Turtle examples do not provide namespace declarations, and should be considered to follow the Namespaces table in Section 1.1. Usage examples in SPARQL are given for each section, based on a requirement expressed in natural language. Additional examples of how to model and implement specific situations are available in the Annotation Cookbook.

The diagrams in the specification use the following style:

2. Classes

RDF has a very strong notion of classes and instantiation of classes, and as such this notion is widely used to convey information to consuming clients as to the overall nature of a resource. The Open Annotation model requires classes on all of its consitituent resources. This section lists a series of recommendations regarding classes to use when not prescribed by the core model.

2.1. Annotation Classes

In many cases it is important to understand the reasons why the Annotation was created. Open Annotation uses subClasses of the oa:Annotation class to model these reasons, and example instances of it might include Comment, Moderation, Reply, or Link.

It is RECOMMENDED that, if the class does not come from the set of Classes listed below, then the oa:Annotation class be explicitly provided to ensure that consuming clients are aware that the resource is an Open Annotation.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:BookmarkClass[subClass of oa:Annotation] The class for an Annotation that represents a bookmark to the target resources or recorded point or points within one or more resources. Bookmarks may or may not have a Body resource
oax:ChangeClass[subClass of oa:Annotation] The class for an Annotation that represents a request for a modification or edit to the target resource
oax:ClassificationClass[subClass of oa:Annotation] The class for an Annotation that represents the assignment of a classification type, typically from a controlled vocabulary, to the target resource(s)
oax:CommentClass[subClass of oa:Annotation] The class for an Annotation that represents a commentary about or review of the target resource(s)
oax:DescriptionClass[subClass of oa:Annotation] The class for an Annotation that represents a description of the target resource(s), as opposed to a Comment about them
oax:HighlightClass[subClass of oa:Annotation] The class for an Annotation that represents a highlighted section of the target resource or segment. A Highlight may or may not have a Body, and is likely to have both a Selector and a Style
oax:LinkClass[subClass of oa:Annotation] The class for an Annotation that represents a link (of unspecified semantics) between the body and target resources
oax:ModerationClass[subClass of oa:Annotation] The class for an Annotation that represents an assignment of value or quality to the target resource(s)
oax:QuestionClass[subClass of oa:Annotation] The class for an Annotation that represents a question about the target resource(s)
oax:ReferenceClass[subClass of oa:Annotation] The class for an Annotation that represents a reference for the target resource or segment
oax:ReplyClass[subClass of oa:Annotation] The class for an Annotation that represents a reply to a previous statement, either an Annotation or another resource
oax:TagClass[subClass of oa:Annotation] The class for an Annotation that represents a Tag on the target resource(s). The tagging resource may be of any type or format.
Annotation Class Model:

Figure 2.1. Annotation Class Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <Target1> ;
    oa:hasBody <Body1> .

Usage

Requirement: Find the annotations which are comments about something:
   SELECT ?anno WHERE { ?anno rdf:type oax:Comment }
=> <Canvas1>

2.2. Resource Classes

The basic type of the resources, such as if it is an Image, Audio or Video file, used as either Body or Target of the Annotation is very useful information to clients. This information prevents the need for classes of Annotation based on this type, and allows consuming clients to determine how to render the resource without maintaining a long list of mime types, or if they should attempt to render it at all.

The Dublin Core Types vocabulary is RECOMMENDED for expressing these classes. The most common classes are listed in the table below. The definitions are summarized from the DCMI types documentation. Please note that the advice of the DCMI to encode images of text as dctypes:Text is NOT RECOMMENDED within the context of Open Annotation, as it does not help consuming clients to interpret or render the resource, such as via HTML5 media elements.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
dctypes:DatasetClassThe class for a resource which encodes data in a defined structure
dctypes:ImageClassThe class for a image resources, primarily intended to be seen
dctypes:MovingImageClassThe class for a video resources, with or without audio
dctypes:SoundClassThe class for a resource primarily intended to be heard
dctypes:TextClassThe class for a resource primarily intended to be read
Resource Class Model:

Figure 2.2. Resource Class Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <Target1> ;
    oa:hasBody <Body1> .
    
  <Body1> a dctypes:Text .
  <Target1> a dctypes:Image .

Usage

Requirement: Find the annotations with textual bodies:
   SELECT ?anno WHERE { ?anno oa:hasBody ?body ; ?body a dctypes:Text }
=> <Anno1>

2.3. Agents

The provenance of an Annotation is important to capture, as discussed in the Provenance section of the Core specification. This section recommends best practices for recording information about the agents involved in the Annotation, in particular the annotator and generator.

The terms listed below are RECOMMENDED for use in describing agents. Other terms from the FOAF vocabulary are also RECOMMENDED, but not presented explicitly. Other more specific vocabularies MAY also be used as appropriate.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
foaf:PersonClassThe class for a human agent, typically used as the class of the object of the oa:annotator relationship
dctypes:SoftwareClassThe class for a software agent, typically used as the class of the object of the oa:generator relationship
foaf:namePropertyThe name of the agent.
Each agent SHOULD have exactly 1 name property.
foaf:mboxRelationshipThe email address associated with the agent, using the mailto: URI scheme.
Each agent MAY have 1 or more mailboxes
foaf:openidRelationshipThe openId URI associated with the agent.
Each agent MAY have 1 or more openIds.
Model:

Figure 2.1. Agent Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <Target1> ;
    oa:hasBody <Body1> ;
    oa:annotator <Agent1> ;
    oa:generator <Agent2> .
  
  <Agent1> a foaf:Person ;
    foaf:openid <OpenId1> ;
    foaf:name "Some Person" .
    
  <Agent2> a dctypes:Software ;
    foaf:mbox <MailTo1> ;
    foaf:name "Some Software" .

Usage

Requirement: Find the annotations which are attributed to a person:
   SELECT ?anno WHERE { ?anno oa:annotator ?who ; ?who a foaf:Person }
=> <Anno1>

3. Specifiers

The Open Annotation Core model defines the base classes for Specifiers (State, Selector and Style) but only FragmentSelector as a class intended for direct instantiation. This document defines additional Specifiers to cover cross-community use cases and requirements.

3.1. States

Currently there are no defined subClasses of the State specifier in the Extension namespace. Future planned subClasses include a means to specify the HTTP headers necessary to retrieve the correct representation, and a subClass to record fixity information such as content digests or checksums to determine if the representation retrieved is the same as the one annotated.

3.2. Selectors

While the FragmentSelector class is good enough to cover many use cases, it is not sufficient for everything. This Extension document defines several further, media-type specific Selectors to fulfil cross-community requirements which are not covered by FragmentSelector.

3.2.1. Text Selection by Offset

Any sublist of an ordered list of characters can be selected by starting at a particular point in the stream and reading forwards for a number of characters. The starting character is included in the selection, and the first character in the list is character 0. It can also be thought of as the position of a pointer into the list, and the number of items to consume. Thus position 0 would be immediately before the first character, in this way of thinking. For example, if the document was "abcdefghijklmnopqrstuvwxyz", the start was 4, and the range was 3, the selection would be "efg".

The text should be normalized to a readable string before counting characters. HTML/XML tags should be removed, character entities should be reduced to the character that they encode, redundant whitespace should be normalized, and so forth. This allows the Selector to be used with different formats and still have the same semantics and utility.

The use of this Selector does not require text to be copied into the Annotation graph, unlike the the Text Selection by Quotation approach, but is very brittle with regards to changes to the resource. Any edits may change the selection, and thus it is RECOMMENDED that a State be used as well to help identify the correct representation.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:TextOffsetSelectorClass[subClass of oa:Selector] The class for a Selector which describes a range of text based on its starting position (oax:offset) and length (oax:range).
oax:offsetPropertyThe starting position of the segment of text. The first character in the full text is character position 0.
Each TextOffsetSelector MUST have exactly 1 oax:offset property.
oax:rangePropertyThe length of the segment of text selected. The last character is thus included within the segment.
Each TextOffsetSelector MUST have exactly 1 oax:range property.
Model:

Figure 3.2.1. Offset Selector Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <SpTarget1> ;
    oa:hasBody <Body1> .
    
  <SpTarget1> a oa:SpecificResource ;
    oa:hasSource <Target1> ;
    oa:hasSelector <TextSel1> .
  
  <TextSel1> a oax:TextOffsetSelector ;
    oax:offset 4 ;
    oax:range 3 .
    
  <Target1> a dctypes:Text .

Usage

Requirement: Find the annotations that are about some short segment of text:
   SELECT ?anno WHERE { ?anno oa:hasTarget ?spt ; ?spt a oa:SpecificResource ;
            ?spt oa:hasSelector ?txt ; ?txt a oax:TextOffsetSelector ;
            ?txt oax:range ?rng ; FILTER (?rng < 10) }
=> <Anno1>

3.2.2. Text Selection by Quotation

This Selector describes a range of text by copying it exactly, and including some range of text immediately before and after it to distinguish between multiple copies of the same text within the resource. The specific length of the prefix and suffix should be determined from the context of the document.

For example, if the document were again "abcdefghijklmnopqrstuvwxyz", one could select "efg" by a prefix of "abcd", the quotation of "efg" and a suffix of "hijk".

The text to be quoted should be normalized to a readable string before recording. Thus HTML/XML tags should be removed, character entities should be reduced to the character that they encode, redundant whitespace should be normalized, and so forth. This allows the Selector to be used with different encodings and still have the same semantics and utility.

If the content is under copyright, then this method of selecting text is potentially dangerous. A user might select the entire text of the document to annotate, and a client naïvely copy it into the Annotation and publish it openly on the web. For static texts with access and/or distribution restrictions, the use of the Offset Selector is perhaps more appropriate.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:TextQuoteSelectorClass[subClass of oa:Selector] The class for a Selector that describes a textual segment by means of quoting it, plus passages before or after it.
oax:exactPropertyA copy of the text which is being selected, after normalization.
Each TextQuoteSelector MUST have exactly 1 oac:exact property.
oax:prefixPropertyA snippet of text that occurs immediately before the text which is being selected.
Each TextQuoteSelector SHOULD have exactly 1 oac:prefix property, and MUST NOT have more than 1.
oax:suffixPropertyThe snippet of text that occurs immediately after the text which is being selected.
Each TextQuoteSelector SHOULD have exactly 1 oac:suffix property, and MUST NOT have more than 1.
Model:

Figure 3.2.2. Quotation Selector Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <SpTarget1> ;
    oa:hasBody <Body1> .
    
  <SpTarget1> a oa:SpecificResource ;
    oa:hasSource <Target1> ;
    oa:hasSelector <TextSel1> .
  
  <TextSel1> a oax:TextQuoteSelector ;
    oax:exact "efg" ;
    oax:prefix "abcd" ;
    oax:suffix "hijk" .

Usage

Requirement: Find the annotations targeting text segments which read "efg":
   SELECT ?anno WHERE { ?anno oa:hasTarget ?spt ; ?spt a oa:Specific Resource ;
            ?spt oa:hasSelector ?txt ; ?txt a oax:TextQuoteSelector ;
            ?txt oax:exact "efg" }
=> <Anno1>

3.2.3. Area Selection by SVG

An SvgSelector defines an area through the use of the Scalable Vector Graphics standard. The content of the Selector, either embedded as an Inline Specifier or accessible as a dereferencable resource, is a single SVG element; it is RECOMMENDED to embed the element within the Annotation as it is not a valid SVG document by itself. The shape element MUST be one of: path, rect, circle, ellipse, polyline, polygon or g. The g element may only be used to construct a multi-element group, for example to define a donut shape requiring an outer circle and a clipped inner circle.

The dimensions of the shape MUST be relative to the dimensions of the Source resource. For example, given an image which is 600 pixels by 400 pixels, and the desired section is a circle of 100 pixel radius at the center of the image, then the SVG element would be: <circle cx="300" cy="200" r="100"/>

It is NOT RECOMMENDED to include style information within the SVG element, nor Javascript, animation, text or other non shape oriented information. Clients SHOULD ignore such information if present.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:SvgSelectorClass[subClass of oa:Selector] The class for a Selector which defines a shape using the SVG standard.
Model:

Figure 3.2.3. SVG Selector Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <SpTarget1> ;
    oa:hasBody <Body1> .
    
  <SpTarget1> a oa:SpecificResource ;
    oa:hasSelector <Svg1> ;
    oa:hasSource <Target1> .
    
  <Svg1> a oax:SvgSelector ;
         a cnt:ContentAsText ;
    cnt:chars "<circle cx="300" cy="200" r="100"/>" .

Usage

Requirement: Find the annotations with a target that has a segment specified in SVG:
   SELECT ?anno WHERE { ?anno oa:hasTarget ?spt ; ?spt a oa:SpecificResource ;
                ?spt oa:hasSelector ?svg ; ?svg a oax:SvgSelector }
=> <Anno1>

3.3. Styles

3.3.1. CSS Value Style

The standard style language for the web is the W3C's Cascading Style Sheets (CSS). It promotes the separation of presentation layer and the content layer for HTML and XML structured documents.

The Style class in the Open Annotation model for CSS uses only the value part of the CSS, typically a block of definitions enclosed in {} characters. The ruleset selector (typically the name of the element, its class or id) is not used, as this would restrict implementation choice of naming conventions. For example, if the border of the selection should be colored red, the representation of the Style resource would be: {border: 1px solid red}

As the content is not a valid CSS document, it is RECOMMENDED that it be embedded within the Annotation, unless it is intended for use by multiple Annotations.

The exact rendering of the Specific Body or Target is, ultimately, up to the user's client. The use of this Style in Open Annotation does not preclude non-HTML based clients, but it must be expected that such clients will not process all, or even any, of the styling hints provided in the CSS Value Style.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:CssValueStyleClass[subClass of oa:Style] The class for representing CSS styling information for Specific Resources
CSS Value Style Model:

Figure 3.3.1. CSS Value Style Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <SpTarget1> ;
    oa:hasBody <Body1> .
    
  <SpTarget1> a oa:SpecificResource ;
    oa:hasStyle <Css1> ;
    oa:hasSource <Target1> .
    
  <Css1> a oax:CssValueStyle ;
         a cnt:ContentAsText ;
    cnt:chars "{border: 1px solid red}" .

Usage

Requirement: Find the annotations with CSS styled targets :
   SELECT ?anno WHERE { ?anno oa:hasTarget ?spt ; ?spt a oa:SpecificResource ;
            ?spt oa:hasStyle ?style ; ?style a oax:CssValueStyle }
=> <Anno1>

3.3.2. XSLT Style

Resources encoded in XML can be transformed into other formats or schemas using Extensible Stylesheet Language Transformations (XSLT). Using XSLT, a single resource could encode a machine readable version of the information to be conveyed, and a client can still display a customized human readable version after the transformation.

After retrieving the representation of the Source resource, potentially applying a Selector to extract a segment of it, the client SHOULD then apply the transformations specified in the XSLT to the representation or segment. The format of the representation SHOULD therefore be XML, so attention MUST be paid to any State Specifiers that describe how to retrieve the correct representation.

It is RECOMMENDED that, unlike CSS Value Styles, XSLT Styles should be unique dereferencable resources rather than embedded within the Annotation. This is due to the size of the XSLT stylesheet, and that it is a full document conforming to the XSLT specification.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:XsltStyleClass[subClass of oa:Style] The class for representing an XSLT Stylesheet to be applied to an XML representation of a resource
Model:

Figure 3.3.2. XSLT Style Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <SpTarget1> ;
    oa:hasBody <Body1> .
    
  <SpTarget1> a oa:SpecificResource ;
    oa:hasStyle <Xslt1> ;
    oa:hasSource <Target1> .
    
  <Xslt1> a oax:XsltStyle .
  
  <Target1> a dctypes:Text ;
    dc:format "text/xml" .

Usage

Requirement: Find the annotations with targets that should be rendered using an XSLT stylesheet:
   SELECT ?anno WHERE { ?anno oa:hasTarget ?spt ; ?spt a oa:SpecificResource ;
            ?spt oa:hasStyle ?style ; ?style a oax:XsltStyle}
=> <Anno1>

3.4. Composite Specifiers

The Core Open Annotation model specifies the interpretation for multiple Specifiers attached to the same Specific Resource as being alternatives. This allows for a choice between a set of alternatives, but not the composition of multiple Specifiers such that all must be taken into account. Allowing the composition of multiple specifiers would cover use cases such as non-rectangular sections of a Video resource, described using an oax:SvgSelector at a particular point in the video, encoded using a media fragment in a oa:FragmentSelector. The Open Annotation Extension model defines three Composite Specifiers, one for each type of Specifier, to fulfil such use cases.

The interpretation of oa:hasState, oa:hasSelector and oa:hasStyle when the subject resource is a Composite Specifier is that ALL of the object Specifiers must be processed. The order in which the Specifiers are processed is left up to either further subClasses or the consuming client to determine. In some cases this will not matter, such as selecting the area of the video and then the time or vice versa, and in other cases it will be very important; an XSLT Style must come before a CSS Value Style to result in the correct rendering, for example.

Please Note that while oax:CompositeSelector is used in the example below, the other Composite classes follow exactly the same pattern.

Model

The Open Annotation Extension model uses:
Vocabulary ItemTypeDescription
oax:CompositeStateClass[subClass of oa:State] The class for a State which encapsulates more than one other State which must be processed.
oax:CompositeSelectorClass[subClass of oa:Selector] The class for a Selector which encapsulates more than one other Selector which must be processed.
oax:CompositeStyleClass[subClass of oa:Style] The class for a Style which encapsulates more than one other Style which must be processed.
Composite Specifier Model:

Figure 3.4. Composite Specifier Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <SpTarget1> ;
    oa:hasBody <Body1> .
    
  <SpTarget1> a oa:SpecificResource ;
    oa:hasSelector <Comp1> ;
    oa:hasSource <Target1> .
    
  <Comp1> a oax:CompositeSelector ;
    oa:hasSelector <Selector1> ;
    oa:hasSelector <Selector2> .

Usage

Requirement: Find the annotations which use Selector1 as part of a Composite Specifier :
   SELECT ?anno WHERE { ?anno oa:hasTarget ?spt ; ?spt a oa:SpecificTarget ;
            ?spt oa:hasSelector ?comp ; ?comp a oax:CompositeSelector ;
            ?comp oa:hasSelector <Selector1> }
=> <Anno1>

4. Semantic and Data Annotations

4.1. Semantic Tags

A common use for annotation is to associate a small piece of text, called a tag, with the resource to aid in the classification or understanding of a resource. These tags can assist in indexing and discovery, visualization with tag clouds and so forth. There are resources called Semantic Tags identified by a URI which fill the same role as the plain text tag, but with explicit definitions rather than the semantically ambiguous short piece of text.

Semantic tags often convey what the resource is referencing or depicting, a classification of the resource into a type or set, or a quality of the resource such as important or funny. Many tags are both user and time specific, so it is important to include the provenance information in the Annotation graph in these cases.

These tags are associated with the Target resource by the use of the oax:hasSemanticTag predicate. This enables an Annotation to also have a Body to explain the tagging, or give any other additional information. In some cases the semantic tags are extracted, by either a human or software agent, from the Body text and added to the Annotation after its creation. No indication is given as to the relationship between the tag and the Target resource or resources. If a more explicit relationship, or other additional information, is desirable, please see the following sub-section on Named Graphs.

Model

The Open Annotation model uses:
Vocabulary ItemTypeDescription
oax:hasSemanticTagRelationshipThe relationship between an Annotation and the Tagging Resource.
There MAY be 0 or more oax:hasSemanticTag relationships associated with an Annotation. An Annotation MAY have a Body as well as one or more Semantic Tags.
Semantic Tag Model:

Figure 4.1. Semantic Tag Model
 <Anno1> a oa:Annotation ;
    oax:hasSemanticTag <Tag1> ;
    oa:hasBody <Body1> ;
    oa:hasTarget <Target1> .

Usage

Use Case: Find all of the resources which are tagged with a particular tag.
  SELECT ?target WHERE { ?anno oax:hasSemanticTag <Tag1> . ?anno oa:hasTarget ?target }
=> <Target1>

4.2. Named Graphs

Instead of using the Content in RDF specification to embed RDF graphs, Named Graphs can be used. This enables complex SPARQL queries to search within the embedded graph, instead of requiring the system to extract, parse and store the embedded triples separately.

This form MUST ONLY be returned when dereferencing an Annotation's URI if the client explicitly requests a Named Graph serialization via Content Negotiation. This restriction is to ensure interoperability with clients that can not parse the Named Graph serialization, and hence would be unable to parse the Annotation graph at all.

It is RECOMMENDED to have a dereferencable resource that contains the serialization of the graph, rather than to use Named Graphs.

Model

The Open Annotation model uses:
Vocabulary ItemTypeDescription
trig:GraphClassThe class of Named Graphs
Inline Graph Model:

Figure 4.2. Named Graph Model
  {
    <Anno1> a oa:Annotation ;
      oa:hasBody :Graph1 ;
      oa:hasTarget <Target1> .

    :Graph1 a trg:Graph .
  }
    
  :Graph1 { 
    <Target1> relationship <Thing1> . 
  }

NB. This figure is given in the Trig format, rather than Turtle.

Usage

Use Case: Find all of the annotations with bodies that express a relationship about the target.
  SELECT ?anno, ?what WHERE { ?anno oa:hasBody ?g . ?anno oa:hasTarget ?t .
           GRAPH ?g { ?t relationship ?what } }
  }
=> <Anno1>, <Thing1>

4.3. Structured Resources

It is desirable to facilitate more complex structures than a simple tag, without requiring the use of Named Graphs and specific serializations. For example, an RDFa serialization could not encode the structure described in the previous sub-section. In order to accomplish this, the Open Annotation Extension model allows for arbitrary graph structures to be included, and used in the role of Body or Target. The identifier MUST NOT be dereferencable; if it is, then the information SHOULD be available from the dereferencable resource like any other representation.

The use of this approach is NOT RECOMMENDED when cross-community interoperability is important, as the structures are unlikely to be correctly processed without prior knowledge. Further considerations include:

  • Implementations that expect a resource with a serialization separate from the Annotation graph may not be able to store structured resources
  • The agent responsibe for asserting the triples in the structure is assumed to be the oa:annotator, but this may not be correct

Model

Structured Resource Model:

Figure 4.3. Structured Resource Model
  <Anno1> a oax:Comment ;
    oa:hasTarget <Target1> ;
    oa:hasBody <Struct1> .
    
  <Struct1> c <X> .

  <X> b <Y> ;
    b <Z> .
    
  <Z> a 123 .

Usage

Use Case: Find all of the annotations with structured bodies that express that X b Y.
  SELECT ?anno WHERE { ?anno oa:hasBody ?sb ; ?sb c <X> ; <X> b <Y> }
=> <Anno1>

A. References

[Creative Commons]
Creative Commons, Creative Commons, May 18 2008
[Content in RDF]
Representing Content in RDF 1.0, Koch, J. Velasco, C. 29 October 2009
[DC Elements]
Dublin Core Metadata Elements, DCMI Recommendation, 18 December 2006.
[DC Terms]
DCMI Metadata Terms, DCMI Usage Board, 18 December 2006.
[FOAF]
FOAF Vocabulary Specification 0.91, D. Brickley, L. Miller. 2 November 2007.
[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)
[Memento]
Memento: Time Travel for the Web, Van de Sompel, H, Nelson, M, Sanderson R. October 2010.
[RDF]
RDF Primer, F. Manola, E. Miller, Editors. W3C Recommendation, 10 February 2004.
[RDF Vocabulary]
RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004.
[RFC 3986]
Uniform Resource Identifier (URI): Generic Syntax, Berners-Lee, T., Fielding, R., and L. Masinter, STD 66, RFC 3986, January 2005.

B. Acknowledgements

This specification builds upon the work from many previous annotation efforts, including in particular:

The editors would like to acknowledge the financial support of the Mellon Foundation for the Open Annotation Collaboration and funding the initial reconcilliation between the Annotation Ontology and Open Annotation Collaboration models.

The editors would like to thank the following for their valuable contributions:

C. Change Log

Date Editor Description
2012-05-09 rsanderson License Correction
2012-05-01 rsanderson W3C Community Draft
2012-04-15 rsanderson Internal Draft 1