Re: Publishing the Mapping Table (was minutes of 2009-03-10 teleconference)

Re: Publishing the Mapping Table (was minutes of 2009-03-1Hi David, all,
 
in my opinion the specification of two-way mappings is (currently) not necessary. Now we have a set of one-way mappings from XMP (which acts as our central authoritative ontology) to formats A, B, C, etc. This facilitates the implementation of "metadata import" API methods (e.g. getDate) which satisfy David's scenario 2 (the search interface of Spotlight). Certainly, if we want to support "metadata export" API methods (e.g. setDate), related to the scenario 1 (media conversion, metadata editing, etc.), we would need the inverse mapping semantics, but (currently) they can be easily inferred from the prose descriptions, or from the constructs that we are currently considering (skos:exactMatch, skos:narrowMatch, etc.). If later our mahince-processable mapping constructs get more complicated (e.g. using regular expressions as we are doing at JPEG), then maybe inferring the inverse relationships could become a non-trivial problem and specifying the inverse relationships could become a good idea.

Best regards,

Ruben

  ----- Original Message ----- 
  From: David Singer 
  To: Veronique Malaise ; Felix Sasaki 
  Cc: Raphaël Troncy ; public-media-annotation@w3.org 
  Sent: Thursday, March 19, 2009 1:44 AM
  Subject: Re: Publishing the Mapping Table (was minutes of 2009-03-10 teleconference)


  At 17:59  +0100 18/03/09, Veronique Malaise wrote:
    Hi Felix, all,


    I think that the first case that David was mentioning is typically answered by a "central authoritative" ontology or equivalence repository: for one query, it gives the possible properties in different vocabularies (XMP, MPEG7 etc); the second case is the skos modeling case *without* a "central authoritative" ontology or equivalence repository, which states that one property in one vocabulary is comparable (in some way) to a property in another vocabulary. But I might have misunderstood teh point...


    Véronique


  Perhaps!  We are both being rather brief, so let me explain more.


  QuickTime can convert files between different formats.  When we do that, there is a question of what we do with the meta-data.  Generally, we don't convert it, because conversion really needs a perfect bi-directional relationship:  if you were to convert and convert back, you'd still get something valid and true.  In many cases, the two tags are not perfect synonyms (for example, the discussion about creation tools and creation agents), and so it's not a reversible (two-way) relationship.


  We *also* have a system (spotlight) of indexing files on Mac OS X.  For this system we want to build a database from the meta-data, that is independent of the file format.  We want to answer questions like "who was the author", "when was it written", "what is the title", and so on.  For this purpose, we only need a one-way mapping, and it doesn't need to be an exact match.  If Spotlight is willing to accept more in (say) a 'created by' field than the file format is able to express, it doesn't matter.


  The second paragraph is dealing with "If X is your question, and Y is your file format, you can get an answer by doing Z".  It is way easier to answer than "If Q is your source format, and R is the meta-data item, and S is your destination format, then you can convert by doing actions T".


  Am I making better sense now?


  If we want to support uniform indexing and display of meta-data in media files, via DOM APis or recommended indexing practices, we probably only need the first of these, for a reasonable and small set of tags.  This is achievable...






    On Mar 18, 2009, at 5:34 PM, Felix Sasaki wrote:


      Hello Raphael,

      I missed that one, sorry. I think the reason is that David was asking whether we want to provide the functionality of a two way mapping, and not specifically referring to the expressive power of SKOS or another possible formalization which may be used to implement the functionality. If I understand you right you just explained the SKOS example, but did not ask for the functionality?

      Felix

      2009/3/18 Raphaël Troncy <Raphael.Troncy@cwi.nl>

        Dear Felix,



          everything we have done so far, including the mapping table, the toy implementations of the API and the formalization example in SKOS etc., are one way mapping, mostly using properties available in XMP as the target of the mapping. That is, property A-1 from format A can be mapped to property XMP-x. So far I have not seen anybody in the Working Group asking for a two way mapping, so I regard this as an unspoken consensus that we are working "only" on the one way mapping.



        This is *not* exactly true.
        In the case of the toy example of a possible mapping formalization in SKOS, we have a two-ways mapping, since for example, the skos:related property is owl:symmetric [1]. The skos:mappingRelation might be reflexive, symmetric too.

         Raphaël

        [1] http://www.w3.org/TR/skos-primer/


        --
        Raphaël Troncy
        CWI (Centre for Mathematics and Computer Science),
        Science Park 123, 1098 XG Amsterdam, The Netherlands
        e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
        Tel: +31 (0)20 - 592 4093
        Fax: +31 (0)20 - 592 4312
        Web: http://www.cwi.nl/~troncy/




-- 
David Singer
  Multimedia Standards, Apple Inc.