Definition of ma:fragments and ma:namedFragments

Dear all,

When working on the implementation of our mapping prototype we came across an issue with the definition of the ma:fragments and ma:namedFragments elements. My understanding was (and this is supported by the examples in the table) that both contain lists of identifiers conforming to the media fragment URI specification. I still think that this should be the case for ma:namedFragments, i.e. listing the defined name fragments for a resource.

However, in some metadata standards it is possible to assign identifiers to fragments (e.g. shots), and during mapping it seems to make sense to keep the identifier of the fragment (which could be any URI), and in addition provide the ma:locator property for the fragment, which would really be a media fragment URI (e.g. the temporal fragment representing the shot). If we require the identifiers in ma_fragments to be media fragment URIs, we would implicitly force them to be the same as the locators for the fragments. The other option would be to use ma:relation instead of ma:fragments in this case, which is in my opinion not appropriate.

To summarize: the current specification of the ma:fragments and ma:namedFragments properties is not very precise, it talks about fragment identifiers. I think that we should be clear whether we mean media fragment URI compliant ones or any URI. From the problem above it seems that it should be any URI for ma:fragments (which does of course not exclude media fragment URIs) and media fragment URIs for ma:namedFragments.

Best regards,
Werner

--------------------------------------------------------------------
  Werner Bailer
  Institute of Information Systems
  JOANNEUM RESEARCH Forschungsgesellschaft mbH
  Steyrergasse 17, A-8010 Graz, AUSTRIA
 
  phone:  +43-316-876-1218               mobile: +43-699-1876-1218
  web:    http://www.joanneum.at/iis        fax: +43-316-876-1191      
  e-mail: mailto:werner.bailer@joanneum.at
--------------------------------------------------------------------

Received on Wednesday, 30 September 2009 16:05:23 UTC