Data.Information.Knowledge.Web

At the moment there is no Web standard for addressing complex spatial regions (ellipses, polygons, etc.) in media objects by means of URIs. Applications that need to support that feature, such as our multimedia annotation clients (e.g., http://dme.arcs.ac.at/annotation/), currently use their own schemes for defining such regions, with the result that annotations created by one client cannot interpreted by others that do not support/understand these schemes.

The W3C Media Fragments URI specification proposes a syntax for addressing media fragments in several dimensions (temporal, spatial, etc.). However, the spatial dimension currently supports only rectangular segments, which insufficient for most annotation use cases. A few days ago I raised that issue at the MF public mailing list: http://lists.w3.org/Archives/Public/public-media-fragment/2010Sep/0000.html

The following snippet (taken from http://www.w3.org/2001/Annotea/User/Protocol.html) shows how “document”-based annotations worked back in 2002, when the Web was still quite document-centric. At that time, XPointer was sufficient for addressing regions in Web documents:

 
  
  
    http://serv1.example.com/some/page.html#xpointer(id("Main")/p[2])
  
  Annotation of Sample Page
  ...
 

In the last decade people started building multimedia annotation tools that require more sophisticated fragment identification mechanisms than XPointer. Because there was no specification for how to represent complex media fragments, they introduced their own solutions with the side-effect that interoperability among annotation clients is not given anymore. Another annotation client would probably understand the <a:annotates> property but since there is no fragment definition in the media object URI and no <context> property it would simply assume that there is no fragment.

Here is an example of how we represent an image annotation with a polygon region using SVG fragments, which does not mean that any other client can interpret this. In our SVG definition we embedded the annotated image so that also any non-RDF but SVG-capable client (e.g., browsers) can render the annotation.

  
    
	Some annotation text....

	
		
		
			
				
				
		
		
		
	

 

With the MF specification there is – at least in my opinion – a chance to bring this back on the interoperability track. We could, for instance, allow for the specification of complex segments in MF URIs, which could result in something like this:

  
    
	Some annotation text....
 

…which does not really make sense, because there is such a variety of possible fragment types that it is hardly possible to cover them all in a single spec. Therefore we propose to introduce a by-reference MF identification, which is a key/value pair telling the clients that there is some more info about (spatial) fragments available at some other resource. Here is an example how this could look like:

	
		
		Some annotation text....
	
	
		image/svg+xml
		...
	

This tells a client, which receives that RDF document and should now render the annotation, that the annotation annotates an image (http://example.com/image1.jpg) and that there is information about the fragment available at resource . In this example I used a URN instead of a URL to illustrate that a URI in RDF is not necessarily dereferencable. In this case it is simply defined in the annotation RDF document.

Technically, we can achieve the same by defining a new annotation standard that provides means (additional classes and properties) for representing complex media fragments. However, if we can reuse the MF spec for addressing complex segments in media objects we can avoid the divergence between browser implementations and annotation use cases.

In 2002 it was possible to address segments in documents with existing Web specs (XPointer). IMHO it should be possible to address complex segments in media objects on the Web with existing and upcoming Web specs (e.g., MF).