This is a draft document explaining some early design thoughts and ideas for discussion and feedback on www-annotation list. It has not gone through much review and may contain errors.
Currently Annotea annotations can be attached to any part of an XML document by using the XPointer technology. For instance, we can annotate documents containing XHTML, but also documents with SVG images, or mathematical formulas expressed in MathML.
In addition to pointing to an XML document with XPointer values, we would also like to be able to use other adressing schemas with other kinds of documents and values. For instance, we might want to annotate a person presented in a .png or some other raster image by using an SVG outline in a similar way it is done in FOAF. Similarly the value expressing a location in a video recording or an audio stream could be a SMIL time definition or a time code.
In addition to storing simple location values, developers might have needs for storing other information related to processing the values, for instance, extra information may be stored for helping to make more robust XPointer values.
Here we discuss how the current addressing schema for Annotea context could be extended. Section 2 illustrates the current implementation and section 3 examines a new context schema that allows us to add more information about the address directly into the model. It also discusses about compatibility issues with previous client and server versions. Section 4 talks about other ideas, such as a solution where a type is added to a string itself or the use of the schema definitions for context properties.
Figure 2.1: An annotation with original context property [.svg image].
The Annotea context property is used to define
the annotated location within a document as demonstrated in Figure 2.1.
Currently the value of the context property is an XPointer
string. The simple definition of the context property is
presented in Figure 2.2. It does not retrict the type of the value, so in
that sense it could be something else than an XPointer as well.
<rdf:Property rdf:about="http://www.w3.org/2000/10/annotation-ns#context">
<rdfs:label xml:lang="en">context</rdfs:label>
<rdfs:comment>The context within the resource named in 'annotates' to which
the Annotation most directly applies.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/annotation-ns#"/>
</rdf:Property>
Figure 2.2: Definition of context property.
The current use of the Annotea context property
is illustrated in Figure 2.3. It is attached directly to the annotation node
such as the other annotation related properties.
<?xml version="1.0" ?>
<r:RDF xmlns:r="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:a="http://www.w3.org/2000/10/annotation-ns#"
xmlns:d="http://purl.org/dc/elements/1.1/">
<r:Description about="http://www.example.org/Annotation/3ACF6D754">
<r:type resource="http://www.w3.org/2000/10/annotation-ns#Annotation"/>
<r:type resource="http://www.w3.org/2000/10/annotationType#Comment"/>
<a:annotates r:resource="http://example.com/some/page.html"/>
<d:title>Annotation of Sample Page</d:title>
<a:context>http://example.com/some/page.html#xpointer(id("Main")/p[2])</a:context>
<d:creator>Ralph Swick</d:creator>
<a:created>1999-10-14T12:10Z</a:created>
<d:date>1999-10-14T12:10Z</d:date>
<a:body r:resource="http://www.example.org/Annotation/3ACF6D754text"/>
</r:Description>
</r:RDF>
Figure 2.3: Use of context property in a sample annotation.
To allow different types of locations the context schema is extended to so that it can not only take a string as a value but also a new resouce with a type describing how to apply the properties when creating the location. The simplest case is to define a type for the XPointer location with rdf:type property.
Xpointer location includes an httpbody property for storing the XPointer string and httpcontentType property for defining the MIME type for the string. The MIME type defines how the string can be parsed. For XPointer it has value "text/plain" as the XPointers are not supposed to be presented separately but just downloaded from the server so that they can be applied to the annotated document and the result can be highlighted in selected way. An example of the application of extended context for an Xpointer is presented in Figure 3.1.
The the string value in the httpbody property included in the extended context property can be used the same way as the original context property.
Figure 3.1: An annotation with new context property with XPointer value [.svg image].
Another way of extending the context is to store some SVG so that it can be presented on top of a raster image to select part of the image. These locations have type SVGoutline. They also include an httpbody property for storing the SVG outline in a string and httpcontentType property for defining the MIME type for the string. For SVGoutline we use value "image/svg+xml" as the SVG is supposed to be presented on top of the raster image. An example of the application of extended context for an SVGoutline is presented in Figure 3.2.
Figure 3.2: An annotation with new context property with SVG value [.svg image].
Figure 3.3 presents the RDF metadata definitions that are needed for defining the extended context and the location related classes and properties.
<rdf:Property rdf:about="http://www.w3.org/2000/10/extlocation-ns#context">
<rdfs:label xml:lang="en">context</rdfs:label>
<rdfs:comment>The context within the resource named in 'annotates' to which
the Annotation most directly applies. Can be also used in other similar
situations e.g. with bookmarks or replies.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/extlocation-ns#"/>
</rdf:Property>
<rdfs:Class rdf:about="http://www.w3.org/2002/11/extlocation-ns#Location">
<rdfs:label xml:lang="en">Location</rdfs:label>
<rdfs:comment>The target type of an extended context resource.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2002/11/extlocation-ns#"/>
</rdfs:Class>
<rdf:Property rdf:about="http://www.w3.org/2000/10/extlocation-ns#type">
<rdfs:label xml:lang="en">type</rdfs:label>
<rdfs:comment>The type of the extended context resource. The type defines how to
apply the properties of the location e.g the httpbody.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/extlocation-ns#"/>
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/10/extlocation-ns#httpbody">
<rdfs:label xml:lang="en">context</rdfs:label>
<rdfs:comment>The content of the location info in a string format.
The type of the resource defines how to process the string e.g.
an XPointer string defines a location in an XML document just as the original context,
while SVG outline can be used to define part of a raster image.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/extlocation-ns#"/>
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/10/extlocation-ns#httpcontentType">
<rdfs:label xml:lang="en">httpcontentType</rdfs:label>
<rdfs:comment>The content of the location info in a string format.
For an XPointer string this would be the same as the value of
original context.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/extlocation-ns#"/>
</rdf:Property>
Figure 3.3: Definition of an extended context property and other related classes and properties.
For this to work and be backwards compatible, we need to define the equivalence of the original a:context and the httpbody of the extended context when the new:context is of type XPointer. Unfortunately, this equivalence definition is not a simple equivalence between two properties and need a rule language and engine to work.
New clients have no problems as they can be programmed to handle either the original context or the new extended context according to the namespace definitions used. Maybe it is possible to handle a rule to the annotation server that converts old type of context values to new types so that the client only need the code for the new context definitions.
What needs to be decided here is if the properties in the new extended context structure are returned when doing a GET to the annotation or if another GET is needed. We have discussed a little bit returning the structures which don't have their own URI (=blank nodes) and not giving a URI to the value of the new extended context.
When new extended context types are used by the annotations the older versions of clients might not be able to handle them as they are not familiar with the new definitions. It would be nice if the definition of the extended type could add a pointer a program that provides some way of viewing the context but at least now it might be too dependent on the client's implementation.
It should be however possible to define that the extended context with type XPointer is processed the same way as the original context. How can we define that these two values equivalent? Intuitively it seems that there should be a simple way to do this with OWL. However, the current understanding is that we need rules to do this.
Another question is what to do when the other location types than XPointer are not known by the older clients. Possibilities include:
1) return a warning?
2) don't return anything as from the client's viewpoint the context is missing and the annotations are defective
3) have a default way of presenting annotations without context (at the beginning of the document or at the list of all annotations).
The current RDF specification does not give much support for defining different types of strings as a value for a property. The new RDF Core seems to define a way to add types to the property values, for instance, a string containing an integer can be defines as "27"^^xsd:integer.
If the same mechanism could be used for SVG code it could be possible to give type XPointer and SVG outline by giving the XPointer or SVG doctype as a type as in Figure 4.1 (not sure if this is possible though).
"<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN"
"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="12cm" height="4cm" viewBox="0 0 1200 400"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<desc>Example polygon01 - hexagon</desc>
<!-- Show outline of canvas using 'rect' element -->
<rect x="1" y="1" width="1198" height="398"
fill="none" stroke="blue" stroke-width="2" />
<polygon fill="lime" stroke="blue" stroke-width="10"
points="850,75 958,137.5 958,262.5
850,325 742,262.6 742,137.5" />
</svg>"^^http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd.
Figure 4.1: A string containing SVG with a ^^ type definition.
From backwards compatibility point of view it would be nice to keep using the original a:context definition for XPointer type positions as presented in Figure 2.2. In that case each new type of context would need a new property name e.g. outlineContext or timeContext. The values of these properties may be structured if necessary but otherwise they are simple values.
To define that these context properties actually belong to the same family we can define an abstract property abstractContext that all the other properties would have a subpropertyOf relationship with. In this way, it seems possible to keep backwards compatibility and still define new kinds of position values afterwards that are related to each other through the abstract property.
<rdf:Property rdf:about="http://www.w3.org/2000/10/advlocation-ns#abstractContext">
<rdfs:label xml:lang="en">Abstract context</rdfs:label>
<rdfs:comment>The abstract context for describing the location within the resource
named in 'annotates' to which the Annotation most directly applies.
Can be also used in other similar situations e.g. with bookmarks or replies.
This property is not used by itself, rather the subproperties of this property
are used to describe the different types of locations.</rdfs:comment>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/advlocation-ns#"/>
</rdf:Property>
<rdf:Description rdf:about="http://www.w3.org/2000/10/annotation-ns#context">
<rdfs:subpropertyOf>rdf:resource="http://www.w3.org/2000/10/advlocation-ns#abstractContext"/>
</rdf:Description>
<rdf:Property rdf:about="http://www.w3.org/2000/10/advlocation-ns#outlineContext">
<rdfs:label xml:lang="en">outline context</rdfs:label>
<rdfs:comment> The context for describing an SVG outline that can be applied to
an image to define an area to which the Annotation most directly applies.
Can be also used in other similar situations e.g. with bookmarks or replies.</rdfs:comment>
<rdfs:subpropertyOf>rdf:resource="http://www.w3.org/2000/10/advlocation-ns#abstractContext"/>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/advlocation-ns#"/>
</rdf:Property>
<rdf:Property rdf:about="http://www.w3.org/2000/10/advlocation-ns#timeContext">
<rdfs:label xml:lang="en">time context</rdfs:label>
<rdfs:comment> The context for describing a SMIL time code or a range that can be applied
to an audio or video stream to define a point or range in time
to which the Annotation most directly applies.
Can be also used in other similar situations e.g. with bookmarks or replies.</rdfs:comment>
<rdfs:subpropertyOf>rdf:resource="http://www.w3.org/2000/10/advlocation-ns#abstractContext"/>
<rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/10/advlocation-ns#"/>
</rdf:Property>
Figure 4.2: Definition of an abstract context property and its subproperties.
Last updated $Date: 2003/01/10 17:35:07 $