About return types in the API

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 UTC