RE: Ontology for Media Resource 1.0

I hate the concept of "Data Element" because I'm never quite sure what
it means. In contrast, I like the concept of "Property" because it
implies a "Domain" and a "Range" that establish context. I especially
like the distinction between "Datatype Property" and "Object Property"
because I can equate them with the more sensibly named UML equivalents
"Attribute" and "Association". 

Water under the bridge...

Getting back to the point, what's wrong with applying a little extra
thought to subtle inconsistencies so we can use owl:sameAs and
owl:equivalentClass more often?

Jeff

> -----Original Message-----
> From: Karen Coyle [mailto:kcoyle@kcoyle.net]
> Sent: Saturday, August 14, 2010 6:13 PM
> To: Thomas Baker
> Cc: Felix Sasaki; Young,Jeff (OR); public-xg-lld@w3.org
> Subject: 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 23:37:13 UTC