Re: Ontology for Media Resource 1.0

Quoting Thomas Baker <tbaker@tbaker.de>:


> 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 predict that in general we will see communities create their own  
data elements rather than re-use for some practical reasons: 1) having  
their own elements gives them more control over their metadata 2) it  
is extremely hard to find elements that mean EXACTLY what your  
community wants it to mean. This latter is a function of context, I  
believe. So my next prediction is that metadata elements (properties  
and vocabularies) will continue to be created within schemas that  
respond to the specific problem the metadata is being designed to  
solve, because that's what people need to actually *do* with metadata.  
The metadata will not be defined for universal use, but for use within  
that specific context. Taking the elements out of the context of the  
schema for use elsewhere causes the meaning of the element to degrade  
in most cases.

An example of this latter is dcterms:title, which has the very broad  
definition "A name given to the resource." It has been suggested that  
since persons are resources and dcterms can be used for any resource,  
that a person's name could be coded as dcterms:title. Most of us  
wouldn't consider using it this way  (and if we had, then we wouldn't  
have needed foaf:name) because we have in mind the context of dcterms  
within which dcterms:title is defined, and it matches our concept of  
"title" as used in natural language. Using it in this other way is  
likely to cause confusion among metadata developers and users.

This is not some oddity of metadata, but a fundamental aspect of  
meaning (in the human sense), which is highly dependent on context. We  
also seem to have trouble ignoring natural language meanings, even  
when we know we should.

>
> 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.

I would love to see a true "core" of classes that at least cover some  
very basic concepts that we shouldn't have to reinvent: time, place,  
currency, colour, size, etc etc etc. Some of these appear in library  
data, but not all. See the RDA vocabularies:
    http://metadataregistry.org/rdabrowse.htm

There are also some in the bio vocabulary (http://vocab.org/bio/). If  
nothing else we could gather a list of these in a handy place and do  
some analysis of them. It's very frustrating to find yourself  
pondering how to represent something extremely common, and knowing  
that the concept should *not* be buried within your metadata but  
should surely be available in a larger context.

kc

>
> 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?
>
> 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?).
>
> 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>
>
>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Saturday, 14 August 2010 22:14:11 UTC