W3C home > Mailing lists > Public > public-media-annotation@w3.org > October 2009

About return types in the API

From: Pierre-Antoine <pierre-antoine.champin@liris.cnrs.fr>
Date: Fri, 09 Oct 2009 18:41:02 +0200
Message-ID: <4ACF679E.1080607@liris.cnrs.fr>
To: "public-media-annotation@w3.org" <public-media-annotation@w3.org>
I am not entirely satisfied with the return types of the API. In some 
examples, URIs are used while many in-scope formats will rather used 
free text. However, some formats (like media-rdf) would return a URI, 
and URIs should be used whenever possible, because they are more 
computer-friendly than labels. Also, they should be recognized as URIs.

So I suggest that wherever a URI may or may not appear, we provide a 
mean to decide whether this is a URI. We could enforce that strings 
starting with "<" and ending with ">" are URIs (as suggested by RFC3986 
URI). Or we could use in those places an object like

interface OtherResource: Unstructured {
     attribute DOMString uri;
     attribute DOMString label;
};

where either uri or label should be non-empty.

Note that those should be used as well to qualify roles or relations. So 
Contributor would become

interface Contributor: Unstructured {
     attribute object contributor; // must implement OtherResource
     attribute object role; // must implement OtherResource
};

A little verbose, but useful.

Furthermore, whenever in-scope formats define a controlled vocabulary of 
roles or relations, we should use a URI rather than a label. Since those 
format do not always do it, we should define a URI prefix for such 
vocabularies. For example, ID3 has several properties for contributors 
(composer, lyricist...) corresponding to different ID3 frames 
(~properties). I think providing URIs like

   http://w3.org/mediaann/id3/role/composer
   http://w3.org/mediaann/id3/role/lyricist
   etc.

to be used as role URI would prove much more powerful than using plain 
strings to qualify contributor roles.

   pa
Received on Friday, 9 October 2009 16:41:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 9 October 2009 16:41:36 GMT