Re: action 78 - Discussion about interoperability

Pierre-Antoine Champin さんは書きました:
> Hi,
>
> for action 78, I had to write a wiki page about some concerns I raised
> during the last telecon about interoperability between mapped
> properties. Since this is supposed to be matter for discussion rather
> than a formal document, I think it is best to send it as a mail.
>
>
> What triggered my concern was the mapping for Media RSS, between
> ''dc:creator'' and ''dcterms:creator''. Just as a reminder, the Dublin
> Core vocabulary has two versions: the legacy "elements" (usually
> prefixed with ''dc'') and the "terms" (usually prefixed with
> ''dcterms''). Each term is more specific than its corresponding element,
> as its values are more constrained. For example, ''dc:creator'' can have
> any type of value (including a plain string), while 'dcterms:creator''
> must have a URI, which must denote an instance of ''dcterms:Agent''.
> If we decide to specify the ontology only as prose
> Let us consider the example of ''dc:creator'' with a sample of mappings:
>
> * for XMP, its value is a sequence of strings, each string being the
> name of an author.
>
> * for Media RDF, its value is either
>   - a plain string,
>   - an instance of ''foaf:Agent'' with at least a ''foaf:name'', or
>   - an instance of ''vcard'' with at least a ''fn''.
> Since they are using ''dcterms'', it must also be inferred to be a
> ''dcterms:Agent'' (which contradicts the use of a plain string...). It
> may represent only one ("the primary") creator.
>
> * for ID3, the value of TOPE is a string, where names are separated by "/".
>
>
> My point here is that, beyond the "high level" semantic links identified
> by the mapping table, there are some "low level" discrepancies that are
> both semantic (e.g. representing one or several creators) and syntactic
> (slash-separated string or structured sequence).
>
> Leaving these issues to the implementation will inevitably lead to major
> differences and a lack of interoperability. We could specify down to the
> syntactical level the mapping for each property in each format, but what
> about other formats ?
>
> I think a better way to limit the variability in implementations by
> specifying precisely, for each property of our ontology, the expected
> "low level" features of its value (and not only its "high level"
> meaning) so that implementors know what they can keep from the original
> metadata, and what they need to adapt (i.e. split ID3's TOPE field into
> multiple values).
>
> This has to be done at least at the API level. But I guess this could
> also be done to some extent at the ontology level (I do believe that
> those "low level" features are *not only* syntactic), but that raises
> again the problem of formally specifying the ontology or not.
>
> But the less specific we are in describing the ontology, the more
> precise we will have to be in describing the API, in order to avoid "low
> level" semantic discrepancies.
>   

I agree very much with your analysis, Pierre-Antoine. +1 to have a very 
low wheight ontology and to be more precise in the API description. Also 
I am hoping very much that people will volunteer to actually test the 
mappings in toy implementations, no matter if relying on a complex 
ontology or a detailed API. No matter which way we go, let's test them now.

Felix

>  regards
>
>   Pierre-Antoine
>
>
>
>

Received on Saturday, 24 January 2009 08:31:52 UTC