Open Annotation Data ModelCommunity Draft, 08 February 2013 |
Open Annotation Data ModelCommunity Draft, 08 February 2013 |
The OA Community Group's February 2013 Open Annotation Data Model (this document) has been superseded the following W3C Web Annotation Working Group Candiate Recommendations (July 2016):
Implementers are encouraged to begin using the newer specifications as soon as practicable.The Open Annotation Core Data Model specifies an interoperable framework for creating associations between related resources, annotations, using a methodology that conforms to the Architecture of the World Wide Web. Open Annotations can easily be shared between platforms, with sufficient richness of expression to satisfy complex requirements while remaining simple enough to also allow for the most common use cases, such as attaching a piece of text to a single web resource.
An Annotation is considered to be a set of connected resources, typically including a body and target, where the body is somehow about the target. The full model supports additional functionality, enabling semantic annotations, embedding content, selecting segments of resources, choosing the appropriate representation of a resource and providing styling hints for consuming clients.
This section describes the status of this document at the time of its publication. Other documents may supersede this document.
Copyright © 2012-2013 the Contributors to the Open Annotation Core Data Model 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).
Annotating, the act of creating associations between distinct pieces of information, is a pervasive activity online in many guises but currently lacks a structured approach. 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 mentions of resources on Twitter could all be considered as annotations associated with the resource being discussed. In addition, there are a plethora of closed and proprietary web-based "sticky note" systems and stand-alone multimedia annotation systems. The primary complaint about these types of systems is that the user-created annotations cannot be shared or reused due to a deliberate "lock-in" strategy within the environments where they were created. The minimum requirement for any solution is a common approach to expressing these annotations.
The Open Annotation data model provides an extensible, interoperable framework for expressing annotations such that they can easily be shared between platforms, with sufficient richness of expression to satisfy complex requirements while remaining simple enough to also allow for the most common use cases, such as attaching a piece of text to a single web resource.
An annotation is considered to be a set of connected resources, typically including a body and target, and conveys that the body is related to the target. The exact nature of this relationship changes according to the intention of the annotation, but most frequently conveys that the body is somehow "about" the target. Other possible relationships include that the body is an identifier for the target, provides a representation of the target, or classifies the target in some way. This perspective results in a basic model with three parts, depicted below. The full model supports additional functionality, enabling content to be embedded within the annotation, selecting arbitrary segments of resources, choosing the appropriate representation of a resource and providing styling hints for consuming clients. Annotations created by or intended for machines are also considered to be in scope, ensuring that the Data Web is not ignored in favor of only considering the human-oriented Document Web.
Unlike previous attempts at annotation interoperability, the Open Annotation system does not prescribe a transport protocol for creating, managing and retrieving annotations. Instead it describes a web-centric method, promoting discovery and sharing of annotations without clients or servers having to agree on a particular set of network transactions to communicate those annotations.
The specification is divided into the essential core plus distinct modules that add functionality. The modules cover cases where the exact nature of the body or target cannot be sufficiently captured in a URI, explicit semantics for multiplicity and recommendations for publishing best practices.
The primary aim of the Open Annotation Data Model is to provide a standard description mechanism for sharing Annotations between systems. This interoperability may be either for sharing with others, or the migration of private Annotations between devices. The shared Annotations must be able to be integrated into existing collections and reused without loss of significant information. The model should cover as many annotation use cases as possible, while keeping the simple annotations easy and expanding from that baseline to make complex uses possible.
A single, consistent model that can be used by all interested parties is the goal of the standardization process. The number of RDF triples required or bytes needed for serializations, while a consideration, is less important than the coherency of the model. All efforts are made to keep the implementation costs for both producers and consumers to a minimum. A single method of fulfilling a use case is strongly preferred over multiple methods, unless there are existing standards that need to be accommodated or there is a significant cost associated with a method that is otherwise necessary.
The methods of storage and maintenance for Annotations are not specified by the model: databases do not need to be restructured, RDF triplestore technologies do not need to be used, and existing websites and interfaces do not need to be re-scripted or re-engineered. The only requirement is that at least one serialization of the model describing the Annotations be made available for other systems to retrieve, potentially along side serializations into other models. Every effort has been made to ensure this mapping from internal structures to the Open Annotation Data Model is as clear and straightforward as possible.
The Open Annotation model defines a namespace for its classes and properties, and uses several others as listed below. The namespace URI will always remain the same, even if the ontology changes. All versions of the ontology 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 specification:
Prefix Namespace Description oa http://www.w3.org/ns/oa# The Open Annotation ontology cnt http://www.w3.org/2011/content# Representing Content in RDF dc http://purl.org/dc/elements/1.1/ Dublin Core Elements dcterms http://purl.org/dc/terms/ Dublin Core Terms dctypes http://purl.org/dc/dcmitype/ Dublin Core Type Vocabulary foaf http://xmlns.com/foaf/0.1/ Friend-of-a-Friend Vocabulary prov http://www.w3.org/ns/prov# Provenance Ontology rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# RDF rdfs http://www.w3.org/2000/01/rdf-schema# RDF Schema skos http://www.w3.org/2004/02/skos/core# Simple Knowledge Organization System trig http://www.w3.org/2004/03/trix/rdfg-1/ TriG Named Graphs
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.
The examples throughout these documents 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 above. Usage examples in SPARQL are given for each section, based on a query expressed in natural language. Additional examples of how to model and implement specific situations are available in the Tutorial and the Annotation Cookbook.
The diagrams in the specification use the following style:
rdf:type) is depicted as a straight black line with white arrow head.anno1 is a specific instance of an Annotation, whereas oa:Annotation is a classIn general terms, an Annotation expresses the relationship between two or more resources, and their metadata, using an RDF graph. The Open Annotation Core framework explains how to identify and describe the related resources, and how to provide information concerning the creation and intent of the Annotation.
Typically an Annotation has a single Body, which is the comment or other descriptive resource, and a single Target that the Body is somehow "about". The Body provides the information which is annotating the Target. This "aboutness" may be further clarified or extended to notions such as classifying or identifying, discussed in more detail in the section on Motivations.
The Body and Target may be of any media type, and contain any type of content. The Body and Target SHOULD be identified by HTTP URIs unless they are embedded within the Annotation.
All Annotations MUST be instances of the class oa:Annotation,
and additional subclassing is ONLY RECOMMENDED in order to provide additional, community-specific constraints on the model.
The model does not define classes for Body and Target, as the Body of one Annotation may be the Target of another,
and thus the classes would not convey any usable information.
Instead, typing based on the resource content is RECOMMENDED.
The model defines two relationships, oa:hasBody and oa:hasTarget,
to associate the Body and Target resources, respectively, with the Annotation.
Vocabulary Item Type Description oa:Annotation Class The class for Annotations
The oa:Annotation class MUST be associated with an Annotation.oa:hasBody Relationship The relationship between an Annotation and the Body of the Annotation
There SHOULD be 1 or more oa:hasBody relationships associated with an Annotation but there MAY be 0.oa:hasTarget Relationship The relationship between an Annotation and the Target of the Annotation
There MUST be 1 or more oa:hasTarget relationships associated with an Annotation.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> .
SELECT ?anno WHERE { ?anno oa:hasTarget <target1> }
=> <anno1>
SELECT ?body WHERE { ?anno oa:hasBody ?body ; oa:hasTarget <target1> }
=> <body1>
Information concerning the general content type (Text, Image, Audio, Video etc) of the Annotation's related resources
is useful to applications. This is expressed using typing of the Body and Target resources, and thereby allows the client to
easily determine if and how it can render the resource without maintaining a long list of media types. For example,
an HTML5 based client can use the information that the Target resource
is an image to generate a <img> element with the appropriate
src attribute, rather than having to maintain a list of all of the image media types. The creator of the Annotation may
also not know the exact media type of the Body or Target, but should at least be able to provide this general class.
The Dublin Core Types vocabulary is RECOMMENDED
for expressing this information by means of RDF classes. The most common classes are listed in the table below, but other classes MAY also be used.
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.
There SHOULD be 1 or more content-based classes associated with the Body and Target resources of an Annotation.
Vocabulary Item Type Description dctypes:Dataset Class The class for a resource which encodes data in a defined structure dctypes:Image Class The class for image resources, primarily intended to be seen dctypes:MovingImage Class The class for video resources, with or without audio dctypes:Sound Class The class for a resource primarily intended to be heard dctypes:Text Class The class for a resource primarily intended to be read
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> .
<body1> a dctypes:Text .
<target1> a dctypes:Image .
SELECT ?anno WHERE { ?anno oa:hasBody ?body . ?body a dctypes:Text }
=> <anno1>
Some previous annotation systems have used a property with a string literal to represent textual Bodies.
However the Open Annotation model employs the W3C's Content in RDF specification
for consistency with non-textual Bodies and other types of resources. The Content in RDF specification introduces a resource with the class
cnt:ContentAsText to represent the content, and a property cnt:chars
to hold the content string itself.
If it is important that the Body have an identity, then it is RECOMMENDED that the cnt:ContentAsText resource be
identified with a UUID URI, but other URIs MAY be used. If this is not considered to be important, for example for short personal notes,
then an RDF blank node SHOULD be used instead. This pattern reduces the burden for minting and maintaining identifiers when it is not necessary to do so, but makes it impossible for further Annotations or other systems to refer to the Body without a Skolem IRI.
If known, the media type of the body SHOULD be given using the
dc:format property, for example to distinguish between embedded comments in plain text versus those encoded in HTML.
As above, the dctypes:Text class MAY also be assigned along with the cnt:ContentAsText class,
as there could be other uses of cnt:ContentAsText that encode resources with content other than plain text.
This model was chosen over having a literal as the Body directly for the following reasons:
Vocabulary Item Type Description cnt:ContentAsText Class A class assigned to the Body for embedding textual resources within the Annotation.
This class SHOULD be assigned to the Body, however it can be inferred from the presence of the mandatory cnt:chars property.cnt:chars Property The character sequence of the content.
There MUST be exactly 1 cnt:chars property associated with the ContentAsText resource.dc:format Property The media type of the content.
There SHOULD be exactly 1 dc:format property associated with the resource.dc:language Property The language of the content, if known.
There MAY be 0 or more dc:language properties. Each language SHOULD be expressed as a language tag, as defined by RFC 3066.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> .
<body1> a cnt:ContentAsText, dctypes:Text ;
cnt:chars "content" ;
dc:format "text/plain" .
SELECT ?comment WHERE { ?anno oa:hasBody ?body . ?body a dctypes:Text ; cnt:chars ?comment }
=> "content"
Tagging a resource, either with a short text string or a with a URI, is a common use case for Annotation. Tags are typically keywords or labels, and used for organization, description or discovery of the resource being tagged. In the Semantic Web, URIs are used instead of strings to avoid the issue of polysemy where one word has multiple meanings. In this situation, one would use two different URIs to refer to the "bank" of a river versus a financial institution.
In the Open Annotation Core model, the tag is represented as the Body of the Annotation, and the resource being tagged is the Target.
For example, one might wish to associate the textual tag "paris" with an image of the capital of France to describe what is being depicted.
Similarly, "capital", "city", "photo", "stunning" might all be used as tags for the same image. This situation is modeled using the same method as
embedded textual bodies described in the previous section. The body resource SHOULD also have the oa:Tag
class assigned to it, as applications render comments and tags in very different ways. Figure 2.1.3.1 below depicts this.
For semantic tags, where the tag is expressed as a URI, the Body is the URI of the tagging resource. The above example might instead use the URI
http://dbpedia.org/resource/Paris as the Body, and is typically a term from a controlled vocabulary intended to be widely reused. It is also necessary to know that this resource should not be retrieved and rendered for the user, and thus the oa:SemanticTag class MUST be associated with the tagging resource. Note well that semantic tags, and other URIs, may have a fragment component, where the purpose is NOT to select a segment of the document. As such, these resources MUST NOT be re-expressed using FragmentSelectors as that would mean they were selecting a segment of interest. The semantic tagging model is depicted in Figure 2.1.3.2.
As explained in the Motivation section, Annotations that tag resources, either with text or semantic tags,
SHOULD also have the oa:tagging motivation to make the reason for the Annotation more clear to applications, and MAY have other motivations as well.
It is NOT RECOMMENDED to use the URI of a document as a Semantic Tag, as it might also be used as a regular Body in other Annotations which would inherit
the oa:SemanticTag class assignment. Instead it is more appropriate to create a new URI and link it to the document, as demonstrated in figure 2.1.3.3 using the foaf:page predicate.
Vocabulary Item Type Description oa:Tag Class A class assigned to the Body when it is a tag, such as a embedded text string oa:SemanticTag Class [subClass of oa:Tag] A class assigned to the Body when it is a semantic tagging resource; a URI that identifies a concept, rather than an embedded string, frequently a term from a controlled vocabulary foaf:page Relationship The foaf:page relationship expresses the link between a Semantic Tag and the document that describes or somehow embodies the tagging concept.
<anno1> a oa:Annotation ;
oa:motivatedBy oa:tagging ;
oa:hasBody <tag1> ;
oa:hasTarget <target1> .
<tag1> a oa:Tag, cnt:ContentAsText ;
cnt:chars "tag" .
<target1> a dctypes:Image .
<anno1> a oa:Annotation ;
oa:motivatedBy oa:tagging ;
oa:hasBody <term1> ;
oa:hasTarget <target1> ;
<term1> a oa:SemanticTag .
<target1> a dctypes:Image .
<anno1> a oa:Annotation ;
oa:motivatedBy oa:tagging ;
oa:hasBody <term1> ;
oa:hasTarget <target1> ;
<term1> a oa:SemanticTag ;
foaf:page <document1> .
<target1> a dctypes:Image .
SELECT ?anno WHERE { ?anno oa:hasBody ?body . ?body a oa:Tag }
=> <anno1>
Many Annotations are about part of a resource, rather than its entirety. Resources can be arbitrarily large, and annotations arbitrarily precise as to their segment of interest. In the Architecture of the World Wide Web, segments of resources are identified using URIs with a Fragment component that at the same time both describes how to extract the segment of interest from the resource, and identifies the extracted content. For simple annotations, it is valuable to be able to use these fragments as either Body or Target.
It is important to be aware of the consequences of using a Fragment URI for the purpose of identifying parts of a resource, and the restrictions that using them places on implementations.
http://example.com/image.jpg#xywh=1,1,1,1 would not be discovered in a simple search for
http://example.com/image.jpg, even though it is part of it.For systems where these issues are not a concern, or would provide a significant burden to implementation, Fragment URIs MAY be used as either the Body or Target of an Annotation. It is otherwise RECOMMENDED to use the Selector mechanism described in the Specific Resources module, which includes a transition mechanism (oa:FragmentSelector) to ensure compatibility with existing and future fragment specifications.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <t1#xywh> .
<body1> a dctypes:Text .
<t1#xywh> a dctypes:Image .
SELECT ?anno WHERE { ?anno oa:hasTarget <t1#xywh> }
=> <anno1>
SELECT ?anno WHERE { ?anno oa:hasTarget ?x . FILTER ( regex (str(?x), "^t1")) }
=> <anno1>
A special case exists when the Annotation does not have a Body resource. Examples of this sort of situation include bookmarking a particular resource, marking a point within a resource, and highlighting a section of a resource without making a comment about why it is highlighted. A Body may be added to these Annotations later, perhaps explaining the importance of the resource and thus why it was bookmarked.
No new relationships or classes are introduced for Annotations without a Body.
<anno1> a oa:Annotation ;
oa:hasTarget <target1> .
SELECT ?anno
WHERE { ?anno oa:hasTarget <target1> .
FILTER(NOT EXISTS { ?anno oa:hasBody ?notbody })
}
=> <anno1>
Please note that this query uses features from SPARQL version 1.1.
Conversely to the previous section, it is also possible for an Annotation to have multiple Bodies and/or Targets. Each Body is considered to be equally related to each Target individually, rather than the complete set of Targets. This construction may be used so long as dropping any of the Bodies or Targets would not invalidate the Annotation's meaning. Thus in Figure 1.1.5 below, all of the following are individually true:
Example use cases include having multiple tags about a single target image, or a single comment that applies to several web pages.
For situations when the Annotation needs different semantics for multiple Bodies or Targets, such as when a comment is comparing or contrasting the Targets, and hence not about each equally and individually, it is necessary to use further constructions described in the Multiplicity module. It also allows the Bodies or Targets to be ordered, or for a choice to be made by the client on which one of the resources is most appropriate for the user.
The Open Annotation model does not define any new relationships to enable multiple Bodies or Targets. The oa:hasBody
and oa:hasTarget relationships are used multiple times with the same Annotation as the subject.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasBody <body2> ;
oa:hasTarget <target1> ;
oa:hasTarget <target2> .
SELECT ?anno WHERE { ?anno oa:hasTarget ?t1 ; oa:hasTarget ?t2 .
FILTER( ?t1 != ?t2 ) }
=> <anno1>
It is important for consuming clients and services to understand the context in which the Annotation was created. In particular, the person or machine responsible for the Annotation deserves credit for their contribution, and the time at which the Annotation was created is useful for filtering out old, potentially irrelevant annotations. The creator of the Annotation is also useful for determining the trustworthiness of the Annotation, potentially based on reputation models. Also, the software used to create and serialize the model, along with when that activity occurred, is useful for both advertising and debugging.
Provenance information can be attached to the Annotation, Body, Target or any other resource in the Annotation graph. Thus, the provenance information attached to an Annotation is not necessarily true for the Body or the Target resources. For instance, a PhD student in 2013 could be formalizing Charles Darwin's notebooks from 1836 as Annotations with textual comments, and so the student would be the author of the Annotation, while Darwin would be the author of the Body. Additional provenance information, such as Darwin as the creator of the Body, SHOULD be provided where possible, but it is considered out of scope for this specification to formalize further requirements. Existing vocabularies, such as Dublin Core Terms, SHOULD be used.
A complete mapping for the Annotation's provenance in the W3C PROV model is provided in Appendix A. Please note that the Annotation node primarily represents the concept of the Annotation, but for simplicity the model allows serialization level properties to be attached to it. If a more accurate model with distinct identifiers is required for particular use cases, then the model expressed in Appendix A is RECOMMENDED.
Vocabulary Item Type Description oa:annotatedBy Relationship [subProperty of prov:wasAttributedTo] The object of the relationship is a resource that identifies the agent responsible for creating the Annotation. This may be either a human or software agent.
There SHOULD be exactly 1 oa:annotatedBy relationship per Annotation, but MAY be 0 or more than 1, as the Annotation may be anonymous, or multiple agents may have worked together on it.oa:annotatedAt Property The time at which the Annotation was created.
There SHOULD be exactly 1 oa:annotatedAt property per Annotation, and MUST NOT be more than 1. The datetime MUST be expressed in the xsd:dateTime format, and SHOULD have a timezone specified.oa:serializedBy Relationship [subProperty of prov:wasAttributedTo] The object of the relationship is the agent, likely software, responsible for generating the Annotation's serialization.
There MAY be 0 or more oa:serializedBy relationships per Annotation.oa:serializedAt Property The time at which the agent referenced by oa:serializedBy generated the first serialization of the Annotation, and any subsequent substantially different one. The annotation graph MUST have changed for this property to be updated, and as such represents the last modified datestamp for the Annotation. This might be used to determine if it should be re-imported into a triplestore when discovered.
There MAY be exactly 1 oa:serializedAt property per Annotation, and MUST NOT be more than 1. The datetime MUST be expressed in the xsd:dateTime format, and SHOULD have a timezone specified.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> ;
oa:annotatedBy <agent1> ;
oa:annotatedAt "2013-01-28T12:00:00Z" ;
oa:serializedBy <agent2> ;
oa:serializedAt "2013-02-04T12:00:00Z" .
SELECT ?anno WHERE { ?anno oa:hasTarget <target1> ; oa:annotatedBy <agent1> }
=> <anno1>
This section recommends best practices for recording information about the agents involved in the Annotation, in particular the annotator and serializer.
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 required. The PROV class is used as FOAF does not define a SoftwareAgent class.
prov:Agent and foaf:Agent are equivalent classes.
Vocabulary Item Type Description foaf:Person Class The class for a human agent, typically used as the class of the object of the oa:annotatedBy relationship prov:SoftwareAgent Class The class for a software agent, typically used as the class of the object of the oa:serializedBy relationship. It might also be used for the object of the oa:annotatedBy for machine generated annotations. foaf:Organization Class The class for an organization, as opposed to an individual. This might be used as the class of the object of the oa:annotatedBy relationship, for example. foaf:name Property The name of the agent.
Each agent SHOULD have exactly 1 name property.foaf:mbox Relationship The email address associated with the agent, using the mailto: URI scheme.
Each agent MAY have 1 or more mailboxesfoaf:openid Relationship The openId URI associated with the agent.
Each agent MAY have 1 or more openIds.foaf:homepage Relationship The home page for the agent.
Each agent MAY have 1 or more home pages.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> ;
oa:annotatedBy <agent1> ;
oa:serializedBy <agent2> .
<agent1> a foaf:Person ;
foaf:openid <OpenId1> ;
foaf:name "A. Person" .
<agent2> a prov:SoftwareAgent ;
foaf:homepage <HomePage1> ;
foaf:name "Code v2.1" .
SELECT ?anno WHERE { ?anno oa:annotatedBy ?who . ?who a foaf:Person }
=> <anno1>
In many cases it is important to understand the reasons why the Annotation was created, not just the agents involved. Although previous systems have subclassed the core Annotation class to convey these motivations, it was considered that a richer and better description could be obtained by using a SKOS Concept hierarchy. Motivations are SKOS Concepts, and can be inter-related between communities with more meaningful distinctions than a simple class/subclass tree. This frees up the use of subclassing for situations when it is desirable to be more explicit and prescriptive about the form an Annotation takes.
Each Annotation SHOULD have at least one oa:motivatedBy relationship to an instance of oa:Motivation, which is a subClass of skos:Concept.
A list of high level Motivations is presented below. For more information about how these can be inter-related and new Motivations created, please see Appendix B.
Vocabulary Item Type Description oa:Motivation Class [subClass of skos:Concept] The Motivation for an Annotation is a reason for its creation, and might include things like Replying to another annotation, Commenting on a resource, or Linking to a related resource. oa:motivatedBy Relationship The relationship between an Annotation and a Motivation.
There SHOULD be at least 1 Motivation for each Annotation, and MAY be more than 1.Instances of oa:Motivation oa:bookmarking Instance The motivation that represents the creation of a bookmark to the target resources or recorded point or points within one or more resources. For example, an Annotation that bookmarks the point in a text where the reader finished reading. Bookmark Annotations may or may not have a Body resource. oa:classifying Instance The motivation that represents the assignment of a classification type, typically from a controlled vocabulary, to the target resource(s). For example to classify an Image resource as a Portrait. oa:commenting Instance The motivation that represents a commentary about or review of the target resource(s). For example to provide a commentary about a particular PDF. oa:describing Instance The motivation that represents a description of the target resource(s), as opposed to a comment about them. For example describing the above PDF's contents, rather than commenting on their accuracy. oa:editing Instance The motivation that represents a request for a modification or edit to the target resource. For example, an Annotation that requests a typo to be corrected. oa:highlighting Instance The motivation that represents a highlighted section of the target resource or segment. For example to draw attention to the selected text that the annotator disagrees with. A Highlight may or may not have a Body resource oa:identifying Instance The motivation that represents the assignment of an identity to the target resource(s). For example, annotating the name of a city in a string of text with the URI that identifies it. oa:linking Instance The motivation that represents an untyped link to a resource related to the target. oa:moderating Instance The motivation that represents an assignment of value or quality to the target resource(s). For example annotating an Annotation to moderate it up in a trust network or threaded discussion. oa:questioning Instance The motivation that represents asking a question about the target resource(s). For example to ask for assistance with a particular section of text, or question its veracity. oa:replying Instance The motivation that represents a reply to a previous statement, either an Annotation or another resource. For example providing the assistance requested in the above. oa:tagging Instance The motivation that represents adding a Tag on the target resource(s). Please see the section on Tagging and Semantic Tags for more information.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> ;
oa:motivatedBy oa:editing .
SELECT ?anno WHERE { ?anno oa:hasTarget <target1> ; oa:motivatedBy oa:editing }
=> <anno1>
While it is possible using only the constructions in the core data model to create Annotations that reference parts of resources by using fragment URIs, there are many situations when this is not sufficient. For example, even a simple circular region of an image, or a diagonal line across it, is not possible. Selecting an arbitrary span of text in an HTML page, perhaps the simplest annotation concept, is also not supported by fragment URIs. This module of the specification introduces methods to identify and describe a segment of interest, how to obtain the correct representation of a resource, how to associate style information with an Annotation, and provide scoping information for the Body and Target resources specific to the Annotation.
Specifiers in the Open Annotation model are used to describe the contextual details of the resources that the Annotation refers to. This could be by describing a particular segment of a resource, the applicable timestamp of a resource which frequently changes, or by providing style information for rendering. In order to ensure that the segments have an identity that can be globally referenced, the model introduces a Specific Resource class that is used to identify the resource, typically a segment, described by the Specifiers.
Specifiers are associated directly with each Specific Resource, which takes the role of either Body or Target in the Annotation. In this context, the full resource is called the Source resource, and thus the Specifier describes how to determine the aspects of the Source that constitute the Specific Resource. For example, a circular area of an image is identified by the Specific Resource, described by a Specifier, and the complete image resource is the Source. The properties and relationships that can be expressed about Body and Target resources, such as type, format and provenance, should remain attached to the Source resource.
The Open Annotation Model defines two primary Specifier classes with different roles: oa:State and
oa:Selector. A State describes how to determine the correct representation of the Source resource,
and a Selector describes how to discover the correct segment of that representation. The Specific Resource may also have rendering information, associated with it via a Style, and information regarding other resources that provide a more definite scope for the resource, such as its appearance within another resource.
It is expected that if a State is present, it will be processed first to ensure the correct representation is retrieved. Then, if there is a Selector, it would be applied to determine the correct segment of the representation. Finally, if there is a Style, it would be applied to ensure the correct rendering or the resource or segment. As Scopes do not affect the rendering directly, they may be processed in any way deemed appropriate for the user interface or application.
States, Selectors and Styles are intended to be reusable by multiple Annotations, and are thus not linked directly to the Source resource. For example, an instance of a Selector MAY be re-used to select the same segment of multiple resources, or an instance of a State MAY be re-used to ensure a consistent time or set of HTTP request headers. The Specific Resource MAY also be re-used if the information associated with it is applicable in the new context, including any States, Selectors, Styles and Scopes.
The Specifier's description MAY be conveyed as an external or embedded resource, or as RDF properties within the graph. The description SHOULD use existing standards whenever possible. If the Specifier has an HTTP URI, then its description, and only its description, MUST be returned when the URI is dereferenced.
If the Specific Resource has an HTTP URI, then the exact segment of the Source resource that it identifies, and only the segment, MUST be returned when the URI is dereferenced. For example, if the segment of interest is a region of an image and the Specific Resource has an HTTP URI, then dereferencing it MUST return the selected region of the image as it was at the time when the annotation was created. Typically this would be a burden to support, and thus the Specific Resource SHOULD be identified by a globally unique URI, such as a UUID URN. If it is not considered important to allow other Annotations or systems to refer to the Specific Resource, then a blank node MAY be used instead.
Note Well: The same Specifier classes are used for both Specific Target and Specific Body. The diagrams in this module only depict one of these, however the same model applies for both.
Vocabulary Item Type Description oa:SpecificResource Class The class for Specific Resources
The oa:SpecificResource class SHOULD be associated with a Specific Resource to be clear as to its role as a more specific region or state of another resource.oa:hasSource Relationship The relationship between a Specific Resource and the resource that it is a more specific representation of.
There MUST be exactly 1 oa:hasSource relationship associated with a Specific Resource.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource }
=> <anno1>
Many Annotations refer to part of a resource, rather than all of it, as the Target. Examples include Annotations on an area within an image or video, a range of characters in text, a time segment in an audio file or a slice of a dataset. Equally, the segment may be the Body of the Annotation, where the comment is given at a particular point in the video, or in a particular paragraph of text.
A Selector is a Specifier which describes how to determine the segment of interest from within the retrieved representation of the Source resource. The nature of the Selector will be dependent on the type of the representation for which the segment is conveyed. For example the methods used to describe a section of an image will be very different to the methods used to discover the correct paragraph of text, or the correct slice of a dataset.
Only one Selector can be associated with a Specific Resource. If multiple Selectors are required, either to express a choice between different optional, equivalent selectors, or a chain of selectors that should all be processed, it is necessary to use the constructions described in the Multiplicity module.
Typically if all of the information needed to resolve the Selector (or other Specifier) is present within the graph, such as is the case for the FragmentSelector, TextQuoteSelector, TextPositionSelector and DataPositionSelector classes, then there is no need to have a resolvable resource that provides the same information. However for the SvgSelector any other specifiers that have a representation with a life of its own, it may be easier or more efficient to have the SVG document resolvable separately from the Annotation via an HTTP URI.
It must also be noted that the model allows several equivalent expressions of the same segment of interest. For example, to describe a rectangular area, it is possible to use URIs with fragments directly (as in the Core document), the FragmentSelector class, or the SvgSelector. Similarly for plain text documents, either RFC 5147 or the Text Selectors could be used. While this is not optimal from an interoperability perspective, this could not be avoided at the same time as keeping the Open Annotation model flexible and compatible with existing specifications. It is RECOMMENDED that communities implement shared bridging strategies and follow the recommendations of the specification and any best practice documents wherever possible.
Vocabulary Item Type Description oa:Selector Class The super class for individual Selectors. This class is not used directly in Annotations, only its subclasses are. oa:hasSelector Relationship The relationship between a Specific Resource and a Selector.
There MUST be exactly 0 or 1 oa:hasSelector relationship associated with a Specific Resource.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:hasSelector <selector1> .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:hasSelector ?select }
=> <anno1>
The web architecture defines a method of identifying a particular segment of a resource, using the fragment part of the URI. This has been used for media type specific fragments (such as XML and PDF) and more recently for media fragments that are applicable to entire classes of resources, such as Image and Video, regardless of their exact media type.
The Open Annotation model defines a fragment-based Selector (oa:FragmentSelector) which allows
both existing and future fragment specifications to be used to describe the segment of interest.
The description of the segment is the syntax for the fragment identifier component
of the URI, and it is included in the Annotation graph via the rdf:value property.
Thus a fragment URI may be reconstructed by concatenating the
oa:hasSource resource's URI, plus a '#', plus the value.
For example, if the resource's URI was http://www.example.com/image.jpg
and the rdf:value property was "xywh=1,2,3,4", then the resulting URI would
be http://www.example.com/image.jpg#xywh=1,2,3,4.
It is RECOMMENDED to use oa:FragmentSelector rather than annotating the fragment URI directly,
as expressed in the Core, although consuming applications MUST be aware of both.
Publishing systems MAY rewrite fragment URIs into the corresponding oa:FragmentSelector form.
Clients MUST process the value of the FragmentSelector based on the standard that it conforms to, expressed using the
dcterms:conformsTo relationship. If that is not present, then the client should use the media
type of the Source resource to determine the meaning of the fragment. This is to prevent misinterpretation of the fragment
identifier component, which is by definition media type dependent. For example, it is possible to construct a fragment identifier
that looks like it conforms to the W3C Media Fragment specification
as part of an HTML anchor (for example, #xywh=1,2,3,4 also refers to this section of this
HTML document, not a 3 by 4 pixel area, starting at 1,2). Clients MUST therefore also use any State
information provided to be certain that the representation appropriate for the FragmentSelector is retrieved.
Vocabulary Item Type Description oa:FragmentSelector Class [subClass of oa:Selector] A resource which describes the segment of interest in a representation, through the use of the fragment identifier component of a URI. rdf:value Property The contents of the fragment identifier component of a URI that describes the segment of interest in the resource.
The oa:FragmentSelector MUST have exactly 1 rdf:value property.dcterms:conformsTo Relationship The Fragment Selector SHOULD have a dcterms:conformsTo relationship with the object being the specification that defines the syntax of the fragment.
URIs used to identify fragment specifications:
Fragment Specification Description http://tools.ietf.org/rfc/rfc3236 XHTML, and HTML. Example: #namedSection http://tools.ietf.org/rfc/rfc3778 PDF. Example: #page=10&viewrect=50,50,640,480 http://tools.ietf.org/rfc/rfc5147 Plain Text. Example: #char=0,10 http://tools.ietf.org/rfc/rfc3023 XML. Example: #xpointer(/a/b/c) http://www.ietf.org/rfc/rfc3870 RDF/XML. Example: #namedResource http://www.w3.org/TR/media-frags/ W3C Media Fragments. Example: #xywh=50,50,640,480 http://www.w3.org/TR/SVG/ SVG. Example: #svgView(viewBox(50,50,640,480))
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSelector <selector1> ;
oa:hasSource <source1> .
<selector1> a oa:FragmentSelector ;
dcterms:conformsTo <spec1> ;
rdf:value "namedSection" .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:hasSelector ?select . ?select a oa:FragmentSelector .
?select rdf:value "fragment1" }
=> <anno1>
There are several selectors that describe how to extract segments that have a start and end in linear data, such as extracting characters from text or bytes from data. Range selectors are also used to describe points within linear data, for example a cursor location for where to insert information into a web page. This is done by giving a 0 length selection.
Three Range Selectors are defined by the model, two for text and one for bitstreams.
Any sublist of an ordered list of characters can be selected by starting at a particular point in the stream and reading forwards until an end point.
The start can be thought of as the position of a cursor in the list. Position 0 would be immediately before the first character, position 1 would be immediately before the second character, and so on. The start character is thus included in the list, but the end character is not as the cursor stops immediately before it.
For example, if the document was "abcdefghijklmnopqrstuvwxyz", the start was 4, and the end was 7, then the selection would be "efg".
The text MUST be normalized before counting characters. HTML/XML tags should be removed, character entities should be replaced with the character that they encode, unnecessary whitespace should be normalized, and so forth. The normalization routine may be performed automatically by a browser, and other clients should implement the DOM String Comparisons method. This allows the Selector to be used with different formats and still have the same semantics and utility. For a Selector that works from the bitstream rather than the rendered characters, please see the Data Position Selector.
The use of this Selector does not require text to be copied from the Source document into the Annotation graph, unlike the Text Quote Selector, 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 additionally used to help identify the correct representation.
Vocabulary Item Type Description oa:TextPositionSelector Class [subClass of oa:Selector] The class for a Selector which describes a range of text based on its start and end positions. oa:start Property The starting position of the segment of text. The first character in the full text is character position 0, and the character is included within the segment.
Each TextPositionSelector MUST have exactly 1 oa:start property.oa:end Property The end position of the segment of text. The last character is not included within the segment.
Each TextPositionSelector MUST have exactly 1 oa:end property.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:hasSelector <selector1> .
<selector1> a oa:TextPositionSelector ;
oa:start 4 ;
oa:end 7 .
SELECT ?anno WHERE { ?anno oa:hasTarget ?spt . ?spt a oa:SpecificResource .
?spt oa:hasSelector ?txt . ?txt a oa:TextPositionSelector .
?txt oa:start ?s ; oa:end ?e . FILTER (?s < 5) .
FILTER (?e > 6) }
=> <anno1>
This Selector describes a range of text by copying it, and including some range of text immediately before and after it to distinguish between multiple copies of the same sequence of characters within the document. The 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 MUST be normalized before recording. Thus HTML/XML tags should be removed, character entities should be replaced with the character that they encode, unnecessary whitespace should be normalized, and so forth. The normalization routine may be performed automatically by a browser, and other clients should implement the DOM String Comparisons method. 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 Text Position Selector is perhaps more appropriate.
Vocabulary Item Type Description oa:TextQuoteSelector Class [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. oa:exact Property A copy of the text which is being selected, after normalization.
Each TextQuoteSelector MUST have exactly 1 oa:exact property.oa:prefix Property A snippet of text that occurs immediately before the text which is being selected.
Each TextQuoteSelector SHOULD have exactly 1 oa:prefix property, and MUST NOT have more than 1.oa:suffix Property The snippet of text that occurs immediately after the text which is being selected.
Each TextQuoteSelector SHOULD have exactly 1 oa:suffix property, and MUST NOT have more than 1.
<anno1> a oa:Annotation ;
oa:hasBody <body1> .
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:hasSelector <selector1> .
<selector1> a oa:TextQuoteSelector ;
oa:exact "efg" ;
oa:prefix "abcd" ;
oa:suffix "hij" .
SELECT ?anno WHERE { ?anno oa:hasTarget ?spt . ?spt a oa:Specific Resource .
?spt oa:hasSelector ?txt . ?txt a oa:TextQuoteSelector .
?txt oa:exact "efg" }
=> <anno1>
Very similar to the Text Position Selector, the Data Position Selector uses the same properties but works at the byte in bitstream level rather than the character in text level. This is useful, for example, for annotating segments of disk images for forensic purposes, or the part of a stream of data recorded from a sensor.
Vocabulary Item Type Description oa:DataPositionSelector Class [subClass of oa:Selector] The class for a Selector which describes a range of data based on its start and end positions within the byte stream. oa:start Property The starting position of the segment of data. The first byte is character position 0.
Each DataPositionSelector MUST have exactly 1 oa:start property.oa:end Property The end position of the segment of data. The last character is not included within the segment.
Each DataPositionSelector MUST have exactly 1 oa:end property.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:hasSelector <selector1> .
<selector1> a oa:DataPositionSelector ;
oa:start 4096 ;
oa:end 4104 .
SELECT ?anno WHERE { ?anno oa:hasTarget ?spt . ?spt a oa:SpecificResource .
?spt oa:hasSelector ?data . ?data a oa:DataPositionSelector .
?data oa:start ?s ; oa:end ?e . FILTER (?s < 4100) .
FILTER (?e > 4100) }
=> <anno1>
Although simple rectangular areas can be described using media fragment selectors, it is often useful to be able to describe circles, ellipses and arbitrary polygons.
An SvgSelector defines an area through the use of
the Scalable Vector Graphics
standard. The content of the Selector is a valid SVG document.
It is RECOMMENDED that the document contain only a single shape element and that element SHOULD be one
of: path, rect, circle, ellipse, polyline,
polygon or g. The g element SHOULD 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 both the shape and the SVG canvas 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.
Using only this module, it is necessary to have the SVG document as a separate resource. For example, in the diagram below, the resource named "Selector1" might actually have the URI "http://www.example.com/selections/2341.svg", which would return an SVG document when dereferenced. Please see Embedding Resources for how to embed the SvgSelector within the Annotation instead.
Vocabulary Item Type Description oa:SvgSelector Class [subClass of oa:Selector] The class for a Selector which defines a shape using the SVG standard.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSelector <selector1> ;
oa:hasSource <source1> .
<selector1> a oa:SvgSelector .
SELECT ?anno WHERE { ?anno oa:hasTarget ?spt . ?spt a oa:SpecificResource .
?spt oa:hasSelector ?svg . ?svg a oa:SvgSelector }
=> <anno1>
The State Specifier describes the intended state of a Body or Target resource as applicable to the particular Annotation, and thus gives a consuming client the information needed to retrieve the correct representation of that resource. As web resources change over time, it might include a link to an archived copy of the Source resource, or the timestamp at which the Annotation applies to assist in discovering appropriate archived representations. Resources may have multiple representations in different formats, and the Annotation may only apply to one of them, and thus the State could describe how to retrieve the representation in the correct format directly from the Source. Other facets include fixity or checksum information to determine whether the retrieved representation is the same as the annotated one, whether the resource requires authentication to retrieve, the user-agent string to send to the web server, and so forth.
Consuming clients MUST process a supplied State before processing any supplied Selector or style information.
Vocabulary Item Type Description oa:State Class A resource which describes how to retrieve a representation of the Source resource that is appropriate for the Annotation. This class is not used directly in Annotations, only its subclasses are. oa:hasState Relationship The relationship between a oa:SpecificResource and an oa:State resource.
There MAY be 0 or 1 oa:hasState relationship for each SpecificResource.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasState <state1> ;
oa:hasSource <source1> .
SELECT ?anno WHERE { ?anno oa:hasBody ?body . ?body a oa:SpecificResource .
?body oa:hasState ?state }
=> <anno1>
A Time State specifier records the time at which the resource is appropriate for the Annotation, typically the time that the Annotation was created. Consuming applications can then use that information to discover an appropriate representation of the resource from that time, for example using the Memento protocol. The State may also have a link directly to an appropriate cached or archived copy of the resource's representation from that time.
Vocabulary Item Type Description oa:TimeState Class A resource which describes how to retrieve a representation of the Source resource that is temporally appropriate for the Annotation. oa:when Property The timestamp at which the Source resource should be interpreted for the Annotation. The timestamp MUST be expressed in the xsd:dateTime format, and SHOULD have a timezone specified.
There MAY be 0 or more oa:when properties per TimeState, but there MUST be at least one of oa:when and oa:cachedSource. If there is more than 1, each gives an alternative timestamp at which the Source may be interpreted.oa:cachedSource Relationship A link to a copy of the Source resource's representation, appropriate for the Annotation.
There MAY be 0 or more oa:cachedSource relationships per TimeState, but there MUST be at least one of oa:cachedSource and oa:when. If there is more than 1, each gives an alternative copy of the representation.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasState <state1> ;
oa:hasSource <source1> .
<state1> a oa:TimeState ;
oa:cachedSource <copy1> ;
oa:when "2012-07-20T13:30:00Z" .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:hasState ?state . ?state a oa:TimeState . ?state oa:cachedSource ?copy }
=> <anno1>
As there are potentially many representations that can be delivered from a resource with a single URI, and a Specific Resource may only apply to one of them, it is important to be able to record the HTTP Request headers that need to be sent to retrieve the correct representation. The HttpRequestState resource maintains a copy of the headers to be replayed when obtaining the representation.
Vocabulary Item Type Description oa:HttpRequestState Class A resource which describes how to retrieve an appropriate representation of the Source resource for the Annotation, based on the HTTP Request headers to send to the server. rdf:value Property The HTTP request headers as a single, complete string, exactly as they would appear in an HTTP request.
There MUST be exactly 1 rdf:value property per HTTPRequestState.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasState <state1> ;
oa:hasSource <source1> .
<state1> a oa:HttpRequestState ;
rdf:value "Accept: text/plain" .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:hasState ?state . ?state a oa:HttpRequestState ; rdf:value ?headers }
=> <anno1>
The interpretation of a particular Annotation may rely on rendering style being consistent between clients. For example, if the Body refers to the part of an image highlighted in yellow, as compared to the red highlighted part, then these colors need to be maintained. Equally, annotators may convey information via the styling alone, perhaps only to themselves. In order for this implicit information not to be lost between systems, the styling needs to be consistently represented. For example, an annotator may know that green highlights are intended to be referred back to, but that they disagree with sections highlighted in red.
The Style resource is associated with the Annotation itself, and the content of the resource provides the rendering hints about the Annotation's constituent resources. Styles may also require additional information to be added to the Annotation graph for processing. If there are multiple Style resources that must be associated with the Annotation, then the use of the Multiplicity Constructs is RECOMMENDED.
Consuming applications MAY process these instructions, and publishing systems MUST NOT assume that they will be processed; they are only provided as hints rather than requirements. If a client cannot understand or act upon the style, then it MAY continue to render the selection or resource regardless.
Vocabulary Item Type Description oa:Style Class A resource which describes the style in which the selection or resource should be rendered. This class is not used directly in Annotations, only its subclasses are. oa:styledBy Relationship The relationship between an Annotation and the oa:Style.
There MAY be 0 or 1 styledBy relationships for each Annotation.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> ;
oa:styledBy <style1> .
SELECT ?anno WHERE { ?anno oa:styledBy ?style }
=> <anno1>
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.
CSS is used in the Open Annotation model via the oa:CssStyle subClass of oa:Style. It uses the common approach of class-selectors and the class label is attached to a Specific Resource using the oa:styleClass property. This class label must only be attached to Specific Resources, as it is not universally true that the Source resource has that class.
Each block in the CSS resource has the format:
.classname { css-value }
And thus to associate the color red with a Specific Resource that has a class "red", one would use in the CSS:
.red { color: red }
And the Specific Resource (spres1) to be styled would have the property in the Annotation's RDF:
<spres1> oa:styleClass "red" .
When rendering a Specific Resource, consuming applications SHOULD check to see if it has a oa:styleClass property. If it does, then the application SHOULD attempt to locate the appropriate selector in the CSS document, and then apply the css-value block. If a Specific Resource has a styleClass, but no such class is described by a oa:CssStyle attached to the Annotation, then the oa:styleClass MUST be silently ignored.
The CSS resource MAY have its own dereferenceable URI that provides the information. For example, "Style1" in the diagram below might actually have the URI "http://www.example.com/styles/annotations.css". It MAY be embedded within the Annotation using the inline constructions described in Embedding Resources.
It bears repeating that the exact rendering of the Specific Body or Target is, ultimately, up to the user's client. It is understood that not all consuming clients will include CSS parsers, and thus be unable to process the styling information. The use of this Style in Open Annotation does not preclude non-HTML based clients, although implementation may be more difficult even if the information can be parsed. It must be expected that such clients will not process all, or even any, of the styling hints provided in the CSS Style resource.
Vocabulary Item Type Description oa:CssStyle Class [subClass of oa:Style] A resource which describes styles for resources participating in the Annotation using CSS. oa:styleClass Property The string name of the class used in the CSS description that should be applied to the Specific Resource.
There MAY be 0 or more styleClass properties on a Specific Resource.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> ;
oa:styledBy <style1> .
<style1> a oa:CssStyle .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:styleClass "red" .
SELECT ?anno WHERE { ?anno oa:styledBy ?style . ?style a oa:CssStyle .
?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:styleClass ?styleclass
}
=> <anno1>
It is sometimes important for an Annotation to capture the context in which it was made, in terms of the resources that the annotator was viewing or using at the time. For example, it may be important to know that an annotation on a particular image was made in the context of one web page rather than another. This does not imply an assertion that the annotation is only valid for the image in the context of that page, it just records that the page was being viewed. This might also be useful for annotating a resource in the context of a particular collection.
As such scoping information is only true for a particular Annotation, it must be attached to a Specific Resource,
and not to the Source directly. This is true even if there is neither a Selector or a State, as other Annotations that refer to the Source would otherwise incorrectly inherit this assertion. The object of the oa:hasScope relationship is the resource that somehow scopes or provides the context
for the resource in this Annotation.
For example, in the diagram below, the resource named "scope1" could be the webpage "http://www.example.com/index.html",
and the Source resource "source1" could be an image "http://www.example.com/images/logo.jpg", where the
Body is a comment that it should not be in that page.
Vocabulary Item Type Description oa:hasScope Relationship The relationship between a Specific Resource and the resource that provides the scope or context for it in this Annotation.
There MAY be 0 or more hasScope relationships for each Specific Resource.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasScope <scope1> ;
oa:hasSource <source1> .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:hasScope <Scope1> }
=> <anno1>
There are many use cases where an Annotation comprises multiple Bodies, Targets or both. The semantics defined in the Core for multiple Bodies and Targets are that each resource is related to the others individually, however this is not always the case. It is useful to associate the Annotation with one resource from a group of alternatives, for example to have a comment that is available in three different languages and for the user's client to display only the most appropriate one. Or to annotate a set of resources where all of the resources are equally important, as is the case when comparing resources with each other. In this case, the comment does not apply individually to the resources, it applies to all of them together. Finally, it is useful to consider ordering that set of resources, particularly for grouping Selectors that must be processed in the correct sequence to extract the intended segment.
The Open Annotation model includes three multiplicity constructs to model these requirements:
oa:Choice, oa:Composite and oa:List respectively. These nodes are used as the object
of the oa:hasBody, oa:hasTarget, oa:hasSelector, oa:hasState, oa:styledBy and oa:hasScope relationships,
and refer in turn to their constituent resources using the oa:item relationship. The items may either be
resources or further such constructions of multiple resources. For example, a Composite may have two items, one of which is a
resource and the other an oa:Choice between two further resources.
Multiplicity Constructs SHOULD have a globally unique URI to identify them, such as a UUID URN. The URI MAY be resolvable, and if it is then the RDF description of the construct, as in the Annotation's graph, MUST be returned when it is dereferenced. This identity recommendation is not typical for the equivalent classes of rdf:Alt, rdf:Bag and rdf:List, and further processing and modeling requirements based on those classes could not be asserted. The Constructs MAY instead be modeled using RDF blank nodes if it is not considered important that they be referenced directly by other Annotations or systems.
Note Well: All of the examples below display only a single construction at a single level, however the same patterns follow for all of the relationships and structures composed of more than one grouping resource.
Vocabulary Item Type Description oa:item Relationship [subProperty of rdfs:member] The relationship between a multiplicity construct node and its constituent resources.
There MUST be 1 or more item relationships for each multiplicity construct.
A Choice is a set of resources from which an application that is consuming the Annotation should select only one to process or display. For Specifiers, the Client should choose one of the constituent resources to use, as they are somehow comparable or equivalent. Clients MAY use any algorithm to determine which resource to choose, and SHOULD make use of the information present in the Annotation to do so automatically, or MAY present a list and require the user to make the decision.
The Choice SHOULD have a default option. This is the constituent resource that the Annotation's publisher recommends
to be used if the client does not have a preference of its own. This feature should especially be used to express a
preferred Selector or State. Note that rdf:Alt does not have an equivalent property.
Vocabulary Item Type Description oa:Choice Class [subClass of rdf:Alt] A multiplicity construct that conveys to a consuming application that it should select one of the constituent resources to display to the user, and not render all of them. This construct is equivalent to the rdf:Alt container class. oa:default Relationship [subProperty of oa:item] The constituent resource to use as a default option, if there is no other means to determine which would be most appropriate.
There SHOULD be exactly 1 default relationship for each Choice.
<anno1> a oa:Annotation ;
oa:hasBody <choice1> ;
oa:hasTarget <target1> .
<choice1> a oa:Choice ;
oa:default <body1> ;
oa:item <body2> .
SELECT ?anno WHERE { ?anno oa:hasBody ?body . ?body a oa:Choice .
?body oa:default ?default }
=> <anno1>
A Composite is a set of resources that are all required for an Annotation to be correctly interpreted. Examples include an Annotation that compares the differences between two resources, or an Annotation where the Body consists of both a human readable review and a necessary structured data file. These are different from individual bodies and targets, as each would individually annotate or be annotated. It is also important to be able to combine Specifiers, such as using two Selectors where one gives the time range in a video, and a second gives a non-rectangular area to plot over that time range.
The data model defines a class oa:Composite, and then uses the oa:item relationship
defined above. Each Composite MUST have two or more constituent resources, and as all are required there is no default.
Vocabulary Item Type Description oa:Composite Class [subClass of rdf:Bag] A multiplicity construct that conveys to a consuming application that all of the constituent resources are required for the Annotation to be correctly interpreted. This construct is equivalent to the RDF container class rdf:Bag.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <comp1> .
<comp1> a oa:Composite ;
oa:item <target1> ;
oa:item <target2> .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:Composite .
?target oa:item <Target1> }
=> <anno1>
A List is a Composite that also provides an order to its constituent resources in the context of the Annotation. Examples of use are particularly strong for Selectors, where a processing application must first make one selection then another, and if it did it in the other order, the result would be incorrect. This includes situations like first referencing a particular page in a book that does not have its own URI, and then doing a text selection within that page. Another use case would be to assign order to a set of Styles to give precedence to the definition of classes within them.
The order should be provided using the rdf:List construction, and the oa:List resource is at
the same time an rdf:List with rdf:first and rdf:rest relationships.
The resources should be processed in the order given. Serialization formats have different methods of representing lists
that hide the complexity depicted in the diagram below.
Annotation producers SHOULD provide both oa:item and the list predicates. This allows consuming clients to fall back to processing the list in an unordered fashion without iterating through the linked list construction.
oa:item statements from the rdf:first, rdf:rest pattern could be:
rdf:first rdfs:subPropertyOf oa:item .
oa:item owl:propertyChainAxiom ( rdf:rest oa:item ) .
Vocabulary Item Type Description oa:List Class [subClass of oa:Composite] A multiplicity construct that conveys to a consuming application that all of the constituent resources are required for the Annotation to be correctly interpreted, and in a particular order. rdf:List Class An rdf:List is a resource that can be used to build descriptions of ordered lists and other list-like structures. rdf:first Relationship The first resource in a particular list, the remainder being referenced by rdf:rest. rdf:rest Relationship Either an instance of rdf:List, or rdf:nil if there are no further items in the list. rdf:nil Resource A particular instance of rdf:List that represents the empty list.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:hasSelector <list1> .
<list1> a oa:List, rdf:List ;
oa:item <selector1>, <selector2> ;
rdf:first <selector1> ;
rdf:rest ( <selector2> ) .
SELECT ?anno WHERE { ?anno oa:hasTarget ?target . ?target a oa:SpecificResource .
?target oa:hasSelector ?list . ?list a oa:List }
=> <anno1>
Although the Open Annotation data model does not specify how Annotations should be transferred between systems at a network protocol level, there are some issues regarding publication in general that it must deal with for interoperability. These include how to embed resources within an Annotation rather than referencing them by external URIs, expressing equivalence between resources to assist with deduplication between multiple systems, and how to express an Annotation using a Named Graph structure.
The serialization of the Annotation MAY be in any format capable of expressing the RDF graph. It MAY be embedded within other resources, such as using RDFa to embed the Annotation within a web page.
If the Annotation has an HTTP URI, then when that URI is dereferenced, then a representation of the Annotation MUST be returned in an appropriate graph serialization format. When the serialization is embedded within other resources, such as when expressed in RDFa, this HTTP URI MUST continue to be expressed in the serialization. If the Annotation is not available from any dereferenceable URI, but only embedded within a containing resource, then it MUST have a globally unique URN identifer such as a UUID or tag URI.
The RECOMMENDED serialization format is JSON-LD. This is to enable web-browser
based implementations to easily consume Annotations using tools and methods familiar to developers.
The Context presented below is RECOMMENDED to ensure consistency between implementations, and can be
referenced as http://www.w3.org/ns/oa-context-20130208.json.
It is RECOMMENDED to support content negotiation for other serialization formats, including especially RDF/XML and Turtle.
{
"@context": {
"oa" : "http://www.w3.org/ns/oa#",
"cnt" : "http://www.w3.org/2011/content#",
"dc" : "http://purl.org/dc/elements/1.1/",
"dcterms": "http://purl.org/dc/terms/",
"dctypes": "http://purl.org/dc/dcmitype/",
"foaf" : "http://xmlns.com/foaf/0.1/",
"rdf" : "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs" : "http://www.w3.org/2000/01/rdf-schema#",
"skos" : "http://www.w3.org/2004/02/skos/core#",
"hasBody" : {"@type":"@id", "@id" : "oa:hasBody"},
"hasTarget" : {"@type":"@id", "@id" : "oa:hasTarget"},
"hasSource" : {"@type":"@id", "@id" : "oa:hasSource"},
"hasSelector" : {"@type":"@id", "@id" : "oa:hasSelector"},
"hasState" : {"@type":"@id", "@id" : "oa:hasState"},
"hasScope" : {"@type":"@id", "@id" : "oa:hasScope"},
"annotatedBy" : {"@type":"@id", "@id" : "oa:annotatedBy"},
"serializedBy" : {"@type":"@id", "@id" : "oa:serializedBy"},
"motivatedBy" : {"@type":"@id", "@id" : "oa:motivatedBy"},
"equivalentTo" : {"@type":"@id", "@id" : "oa:equivalentTo"},
"styledBy" : {"@type":"@id", "@id" : "oa:styledBy"},
"cachedSource" : {"@type":"@id", "@id" : "oa:cachedSource"},
"conformsTo" : {"@type":"@id", "@id" : "dcterms:conformsTo"},
"default" : {"@type":"@id", "@id" : "oa:default"},
"item" : {"@type":"@id", "@id" : "oa:item"},
"first": {"@type":"@id", "@id" : "rdf:first"},
"rest": {"@type":"@id", "@id" : "rdf:rest", "@container" : "@list"},
"chars" : "cnt:chars",
"bytes" : "cnt:bytes",
"format" : "dc:format",
"annotatedAt" : "oa:annotatedAt",
"serializedAt" : "oa:serializedAt",
"when" : "oa:when",
"value" : "rdf:value",
"start" : "oa:start",
"end" : "oa:end",
"exact" : "oa:exact",
"prefix" : "oa:prefix",
"suffix" : "oa:suffix",
"label" : "rdfs:label",
"name" : "foaf:name",
"mbox" : "foaf:mbox",
"styleClass" : "oa:styleClass"
}
}
Its use results in serializations similar to the two examples below:
{
"@context": "http://www.w3.org/ns/oa-context-20130208.json",
"@type": "oa:Annotation",
"hasBody": "http://www.example.org/body1",
"hasTarget": "http://www.example.org/target1"
}
{
"@context": "http://www.w3.org/ns/oa-context-20130208.json",
"@id": "http://www.example.org/annotations/anno1",
"@type": "oa:Annotation",
"annotatedAt": "2012-11-10T09:08:07",
"annotatedBy": {
"@id": "http://www.example.org/people/person1",
"@type": "foaf:Person",
"mbox": {
"@id": "mailto:person1@example.org"
},
"name": "Person One"
},
"hasBody": {
"@id": "urn:uuid:1d823e02-60a1-47ae-ae7f-a02f2ac348f8",
"@type": ["cnt:ContentAsText", "dctypes:Text"],
"chars": "This is part of our logo"
},
"hasTarget": {
"@id": "urn:uuid:cc2c8f08-3597-4d73-a529-1c5fed58268b",
"@type": "oa:SpecificResource",
"hasSelector": {
"@id": "urn:uuid:7978fa7b-3e03-47e2-89d8-fa39d1280765",
"@type": "oa:FragmentSelector",
"conformsTo": "http://www.w3.org/TR/media-frags/",
"value": "xywh=10,10,5,5"
},
"hasSource": {
"@id": "http://www.example.org/images/logo.jpg",
"@type": "dctypes:Image"
}
}
}
The Open Annotation Core describes how to embed textual bodies within an Annotation, however it is frequently useful to also embed Selectors, Styles and potentially even Targets to ensure that the representation is available.
The web architecture assumes that every resource has a URI, and furthermore the expectation is that they are available for retrieval from HTTP URIs. Some clients, however, may not be able to generate dereferenceable URIs on their own for all of the resources that are created as part of the annotation process. This includes the Body, any Specifiers, Styles or other user generated information, but also potentially the Target if it is not available online.
It is important to have a model that deals gracefully and consistently with both online, dereferenceable resources, and embedded resources. In both cases, the content is expressed as a resource, rather than using only a string literal, as motivated in the section on embedded textual bodies. Both cases must also deal with any content type, including binary data, and deal with any class of resource within the Open Annotation model: Body, Target, Style, Selector, or State.
The Open Annotation model uses the Representing Content in RDF
specification to include the representation of such resources directly within the
Annotation graph. The resource SHOULD be assigned a non-resolvable URN, and
an appropriate class from the Content in RDF ontology, such as
cnt:ContentAsText or cnt:ContentAsBase64. If identity of the resource is not considered
to be important, then an RDF blank node MAY be used instead of the URN.
For information about embedding serializations of RDF graphs within the Annotation, please see Embedding RDF Graphs.
Vocabulary Item Type Description cnt:ContentAsText Class The representation of a resource, expressed as plain text. cnt:ContentAsBase64 Class The representation of a resource, expressed as Base 64 encoded text. cnt:chars Property The property of a ContextAsText that contains the representation.
There MUST be exactly 1 cnt:chars property for a ContentAsText resource.cnt:bytes Property The property of a ContentAsBase64 that contains the representation.
There MUST be exactly 1 cnt:bytes property for a ContentAsBase64 resource.cnt:characterEncoding Property The character encoding of the content string in either cnt:chars or cnt:bytes.
There SHOULD be exactly 1 cnt:characterEncoding for a ContentAsText or ContentAsBase64 resource.dc:format Property The media type of the representation.
There SHOULD be exactly 1 dc:format per embedded resource.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <sptarget1> ;
oa:styledBy <style1> .
<style1> a oa:CssStyle, cnt:ContentAsText ;
cnt:characterEncoding "utf-8" ;
cnt:chars ".red { color : red }" .
<sptarget1> a oa:SpecificResource ;
oa:hasSource <source1> ;
oa:styleClass "red" .
SELECT ?anno WHERE { ?anno oa:styledBy ?style . ?style a oa:CssStyle .
?style a cnt:ContentAsText }
=> <anno1>
One particular case of embedding resources within an Annotation is embedding statements expressed as RDF graphs. The triples that make up these resources MUST NOT be simply put into the Annotation graph, as the triples must remain distinguishable as to authorship and provenance. If it were done otherwise, the metadata and identifier of the Body or Target graph would be lost and subsumed in the Annotation's graph.
The simplest method is to publish the graph as any other resource with a dereferenceable HTTP URI, and refer to this URI in the Annotation. This method is RECOMMENDED.
If a single document is required and thus the graph must be embedded within the Annotation, then there are two possibilities:
dc:format and the class given of trig:Graph
Vocabulary Item Type Description trig:Graph Class The class of Named Graphs
{
<anno1> a oa:Annotation ;
oa:hasBody :graph1 ;
oa:hasTarget <target1> .
:graph1 a trg:Graph .
}
:graph1 {
<target1> relationship <thing1> .
}
SELECT ?anno, ?what WHERE { ?anno oa:hasBody ?g . ?anno oa:hasTarget ?t .
GRAPH ?g { ?t relationship ?what } }
}
=> <anno1>, <thing1>
Although it is not a challenge unique to Annotations, deduplicating resources that have been syndicated between systems is greatly reduced by expressing the equivalence between multiple copies, or very close derivatives. A system that could not discover duplicate Annotations would naïvely present all of them, resulting in a very poor experience. Systems that generate statistics, reputation models, spam filtering for annotations and similar would also have very poor results without this capability. Given these requirements, the Open Annotation model includes a relationship to assert that while two resources are not absolutely identical, they are equivalent and hence should not be both maintained and processed separately.
If a system retrieves an Annotation and republishes it at a different HTTP
URI, then it SHOULD express the oa:equivalentTo relationship between the
original Annotation and the republished one. The system then SHOULD
update the oa:serializedAt and oa:serializedBy properties,
as the graph has changed by adding the oa:equivalentTo relationship.
Embedded resources SHOULD be treated in the same way when republished with their own HTTP URIs. If a system publishes an embedded resource at a new HTTP URI, then it SHOULD express the oa:equivalentTo relationship between the resource's URN and the new URI from which it is available. If the embedded resource is conveyed as a blank node, then the Skolemization technique described in RDF Concepts 1.1 SHOULD be used. The system MAY also remove the embedded resource from the graph and reference only the dereferenceable URI, at its discretion. When this occurs it is possible for the Annotation's graph to change significantly from the initial version to its republished state, while still remaining equivalent.
Vocabulary Item Type Description oa:equivalentTo Relationship [subProperty of prov:alternateOf] The subject and object resources of the oa:equivalentTo relationship represent the same resource, but potentially have different metadata such as oa:serializedBy, oa:serializedAt and serialization format. oa:equivalentTo is a symmetrical and transitive relationship; if A oa:equivalentTo B, then it is also true that B oa:equivalent A; and that if B oa:equivalentTo C, then it is also true that A oa:equivalentTo C.
The Annotation MAY include 0 or more instances of the oa:equivalentTo relationship between copies of the Annotation or other resources, and SHOULD include as many as are available.
<anno1> a oa:Annotation ;
oa:hasBody <body1> ;
oa:hasTarget <target1> ;
oa:serializedAt "2012-12-12T12:12:12Z" ;
oa:equivalentTo <anno2> .
<anno2> oa:serializedAt "2013-01-28T20:00:00Z" .
SELECT ?anno WHERE { <Anno1> a oa:Annotation ; oa:equivalentTo ?anno }
=> <anno2>
The Open Annotation data model specifies a very simple method of expressing the provenance of an Annotation. This is able to be mapped into the richer and more complex W3C PROV model.
The PROV model is expressed in terms of Activities and Entities consumed or produced by those Activities.
There are two Entities in the Open Annotation model, which for expediency and simplicity are collapsed into just oa:Annotation.
These are the Annotation document, and the concept that the Annotation embodies or describes.
This is the distinction between oa:annotatedBy and oa:annotatedAt,
versus oa:serializedBy and oa:serializedAt. In the PROV model we have to split these apart again.
We use the oa:Annotation for the concept, and thus still require an Annotation document.
There are also two Activities, Annotating and Serializing, which produce these Entities. In this case, Annotating is the process of annotating a resource, and should not be confused or conflated with the Motivation of the same name. Serializing is the process by which the Annotation Document is created.
The Annotation document is derived from the concept, which necessarily comes first.
The concept was produced as the outcome of the Annotating process, which was performed by an Agent,
the object of oa:annotatedBy. The Annotation document was produced as the outcome of the Serializing process,
which was also performed by an Agent, the object of oa:serializedBy. Both of these processes happened at a
particular point in time, oa:annotatedAt and oa:serializedAt, respectively.
<anno1> a oa:Annotation ;
a prov:Entity ;
prov:wasGeneratedBy <serializing1> ;
prov:wasDerivedFrom <annoConcept1> ;
prov:generatedAt "datetime1" ;
oa:serializedAt "datetime2" ;
oa:serializedBy <agent2> ;
oa:annotatedBy <agent1>
oa:annotatedAt "datetime1" ;
<annotating1> a prov:Activity ;
prov:wasAssociatedWith <agent1> .
<annoDocument1> a prov:Entity ;
prov:generatedAt "datetime2" ;
prov:wasGeneratedBy <serializing1> .
<serializing1> a prov:Activity ;
prov:wasAssociatedWith <agent2> .
Although the list of Motivations in the specification is derived from an extensive survey of the annotation landscape, there are many situations where more exact definitions of Motivation are required or desirable. In these cases it is RECOMMENDED to create a new Motivation resource and relate it to one or more that already exist.
New Motivations MUST be instances of oa:Motivation, which is a subClass of skos:Concept.
The skos:broader relationship SHOULD be asserted between the new Motivation and at least one existing Motivation, if there are any that are broader in scope. Other relationships, such as skos:relatedMatch, skos:exactMatch and skos:closeMatch, SHOULD also be asserted to concepts created by other communities.
oa:motivationScheme a skos:ConceptScheme ;
oa:editing a oa:Motivation ;
skos:inScheme oa:motivationScheme ;
skos:prefLabel "Editing"@en .
new:correcting a oa:Motivation ;
skos:inScheme new:aScheme ;
skos:broader oa:editing ;
skos:prefLabel "Correcting a Mistake"@en .
new2:fixing a oa:Motivation ;
skos:inScheme new2:anotherScheme ;
skos:broader oa:editing ;
skos:closeMatch new:correcting ;
skos:prefLabel "Fixing a Mistake"@en .
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 Andrew W. Mellon Foundation for the Open Annotation Collaboration and funding the initial reconcilliation between the Annotation Ontology and Open Annotation Collaboration models.
| Date | Editor | Description |
|---|---|---|
| 2013-02-08 | rsanderson | Namespace change for W3C best practice |
| 2013-02-05 | rsanderson | W3C Community Draft 2 |
| 2013-01-28 | rsanderson | W3C Community Draft 2 (internal for final review) |
| 2013-01-07 | rsanderson | W3C Community Draft 2 (internal for review) |
| 2012-05-09 | rsanderson | License Correction |
| 2012-05-01 | rsanderson | W3C Community Draft |
| 2012-04-05 | rsanderson | Internal Draft 2 |
| 2012-03-30 | rsanderson | Internal Draft 1 |