Re: Ontology for Media Resource 1.0

Hi Tom,

2010/8/14 Thomas Baker <tbaker@tbaker.de>

> Hi Felix,
>
> On Sat, Jul 24, 2010 at 08:33:20AM +0200, Felix Sasaki wrote:
> > This is because one use case for the mappings of existing
> > formats to the "ma" vocabulary is to be information used by an API, as
> > described in the "API for media resources" document, see
> > http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/ . In that use
> case,
> > you basically need to know about the mappings and apply them e.g. in API
> > methods like this one
> >
> http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/#contributor--interface
> .
> >
> > That is, you don't need any Semantic Web based machinery to implement
> this.
> > Another use case is to provide a mapping using an RDF-based ontology. A
> task
> > force within the working group is working on that, since there is a heavy
> > demand for this use case as well. Nevertheless it is important that the
> > working group produces a set of mapping which can be used for both use
> cases
> > and which fulfills both needs - e.g. a browser-centered, let's say
> > JavaScript-API and the application of the mappings for linked data
> > scenarios. It is unfortunate that you don't see the RDF-based ontology
> yet,
> > but it is on it's way.
> >
> > Finally let me emphasize that the key to the whole endavour is to get
> broad
> > consensus about the mappings, no matter if they are expressed as a table
> or
> > as RDF. So I encourage you to have a detailed look at the mappings and
> > provide comments to the working group.
>
> Thank you for bringing us up to date on this and putting the
> mediaont endeavor into perspective.
>
> I am interested to read in the Introduction [1] the rationale
> for creating properties based on Dublin Core properties, only
> more tightly constrained and under the control of the mediaont
> editors [2].
>
> The more general issue here, as I see it, is what are the
> tradeoffs for interoperability between simply "reusing"
> existing external properties (by citing them) as opposed to
> creating new properties related to the external properties
> (the approach taken in mediaont).
>
> I suspect the answer is not black-and-white because, as the
> Introduction points out, there are issues of constraints and
> control when relying on external vocabularies, but on the other
> hand, if every specification were to reinvent, say, "title",
> resolving mappings of more "specialized" properties to more
> "core-like" properties would involve a significant amount of
> (human and machine) processing overhead.
>


In general I agree, but in the specific application case of the ontology the
"new terms" make sense (I hope). See also the graphic in the "use cases"
document at http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121/#scope .
The main application scenario for the ontology is access to existing
multimedia metadata . Now, if you take an example like XMP
http://www.w3.org/TR/mediaont-10/#d0e9670 , there is a title in terms of
dc:title, and a title in terms of xmpDM:album. One has language information
associated, the other hasn't. One is defined as an array, the other isn't.
For a JavaScript developer who wants to use the media annotation ontology
mappings via the API for media resources
http://www.w3.org/TR/2009/WD-mediaont-api-1.0-20091020/ , this mapping
information is crucial. Note that such constraints are rather technical
(that is "data type" constraints), not a question of control about external
vocabularies.

There is another aspect: the only application scenario of the ontology is:
being a mediator between existing formats, and the main usage scenario is to
get information about a media resource, but not to annotate a resource using
the "ma" properties. That puts the properties on an orthogonal level,
compared to dublin core or other formats, who are mostly used for direct
reading and writing. Note btw., that there was a discussion about a
requirement to write metadata via the ontology
http://www.w3.org/TR/2010/WD-media-annot-reqs-20100121/#req-r02 , but that
so far did not lead to any results, since most of the mappings lead to loss
of information, so writing in the base format does not work.



>
> As for reviewing the mappings: the mappings are currently
> defined between elements of fixed "formats" -- e.g., for
> Dublin Core, there are relevant mappings to be found in 4.2.2.3
> (EBUCore), 4.2.2.8 (MediaRDF), and 4.2.2.16 (XMP) [2,3,4].
>
> For the mappings to be effective in (and reviewable for use
> in) linked data, the "properties" would need to be declared
> specifically as RDF or OWL properties and the "mappings"
> would need to be declared using triples. Section 4.2.1.3,
> Mapping Expression [5], seems to say that mappings may
> eventually be expressed using SKOS mapping relationships:
>
>    The mapping expression corresponds to the concrete
>    implementation or representation of the mappings defined
>    in the previous paragraph, both at a semantic level
>    and at syntactic one.  ... [SKOS] defines a vocabulary
>    for representing Knowledge Organization Systems, such as
>    vocabularies, and relationships amongst them. In SKOS the
>    mapping properties that we take into account in the mapping
>    table are expressed as: skos:exactMatch, skos:narrowMatch,
>    skos:broadMatch and skos:relatedMatch. A future version
>    of this specification MAY include additional information
>    after interoperability and/or other feedback mechanisms
>    have been completed.
>
> I think we are touching here on another issue of general
> importance for LLD XG -- best practice for expressing mapping
> relationships in a linked data environment.  I'm wondering
> if the mediaont group working on the RDF expression is
> considering using more powerful equivalence assertions,
> e.g. with rdfs:subPropertyOf or even owl:equivalentProperty?
>


No. See a draft of the ontology at
http://www.salzburgresearch.at/~tbuerger/ma-ont-rev4.owl . As You can see
this uses only rather simple means of OWL. The ontology is in a very early
stage, and we aim to reuse existing vocabularies as much as possible, but
want to be clear about the vocabulary for ourselves before taking that step.



>
> On the other hand, if we were seeing here the start of
> a trend towards use SKOS mapping properties for mapping
> RDF properties, what assumptions are being made about how
> consuming applications should process such triples when
> merging or linking data?
>
> In a word: What is the emerging best practice for expressing
> mappings?  Is the existing arsenal of RDF, OWL, and SKOS
> properties usable for mappings both rich enough (e.g.,
> in differentiating between exact, close, more general,
> more specific...) and semantically powerful enough (e.g.,
> for inferencing) to meet requirements for mappings?
>
> More immediately, unless I am missing something, the basis
> on which members of this group might currently evaluate the
> mediaont mappings from a linked-data perpective has not yet
> been created (but is in the works?).
>


Your questions above all make sense, but I'm afraid that neither the media
annotation WG nor the lld group is ready to answer them yet. In my view the
media annotation working group is here rather in a "consuming state": if
there is consensus about answers to your questions from a group like lld, we
are happy to apply it, or to put it differently: to implement comments on
the ontology.

Felix



>
> Tom
>
> [1] http://www.w3.org/TR/mediaont-10/#introduction
> [2] http://www.w3.org/TR/mediaont-10/#d0e5511
> [3] http://www.w3.org/TR/mediaont-10/#d0e3064
> [4] http://www.w3.org/TR/mediaont-10/#d0e9670
> [5] http://www.w3.org/TR/mediaont-10/#mapping-expression
>
> --
> Thomas Baker <tbaker@tbaker.de>
>
>