W3C home > Mailing lists > Public > public-lld@w3.org > October 2010

Re: Returning to OWL and application profiles

From: Antoine Isaac <aisaac@few.vu.nl>
Date: Tue, 12 Oct 2010 13:11:13 +0200
Message-ID: <4CB44251.2080802@few.vu.nl>
To: Mikael Nilsson <mikael@nilsson.name>, public-lld <public-lld@w3.org>
Hi Mikael,

Thanks for starting this interesting thread :-)

> I'm in the middle of finalizing my thesis on metadata interoperability
> and harmonization, and I'm right now formulating a section on RDF and
> application profiles, so the discussion I saw here comes at an
> interesting time for me :-)
> The issue from my point of view with using OWL for defining RDF
> application profiles, is that APs define domain-specific structural
> constraints while OWL adds semantics to existing classes.
> I.e. if I produce an OWL-based AP saying that the cardinality of
> dc:title is exactly 1, for a specific class, and someone else produces
> an OWL-based AP saying that the cardinality is 2 for the same class, the
> result is a *contradiction*.

Well, I have what I think is a quite traditional SW background, and I'd be tempted to turn the argument the other way round ;-)
If the instances of one class in an AP have one title and the instances of that class in another AP have two titles, then it is perhaps that these two APs are thinking of two different classes, really. Possibly they could be two subclasses of a common superclass, but two different classes, still.
I think this is quite in line with Jeff's message suggesting you could do things like this
baz:Widget rdfs:subClassOf foo:Widget.
to make the commitment of your various APs a bit clearer.

I'm also a bit puzzled by your "APs define domain-specific structural constraints while OWL adds semantics to existing classes." Again, I am pretty new to the APs as practiced in the DC realm, but why wouldn't you consider classes (and APs built on top of them) from a (SW) semantic perspective?
I understand that OWL and RDF will fail for arrangement/presentation of data (order of XML elements, e.g.), which is not really about semantics. But to me--and to many in the SW community--cardinality belongs to semantics of classes and properties.

> This differs substantially from the case with application profiles,
> where the cardinality is not seen as part of the semantics of a class,
> but rather part of a set of restrictions, external to and independent of
> the class. Multiple incompatible application profiles are perfectly
> normal.
> Therefore, publishing an OWL ontology defining domain-specific semantics
> for certain classes or properties is just as bad practice as if someone
> produces an RDF Schema saying the range of dct:creator is
> myorg:Employee. This defines new semantics of dct:creator, something
> that is simply not true, and can cause involuntary contradictions.
> The other issue is the open world assumption that I saw Pete mention,
> i.e. the fact that if an OWL ontology specifies a cardinality of 2 for
> dc:title, and only one is found, this results in the generation of a new
> dc:title statement, not in non-validity of the record.
> Thus, we would need an alternative semantics for OWL to perform
> validation.

Point taken. But even then I can still play the devil's advocate. What in a pure XML world I decide to create something like
<dc:title>a title<dc:title>
By saying that the cardinality for dc:title is 2, it seems that you overlook some info on your model (or AP). That these titles should not be empty or unknown, for example. And taking it properly into account may require some more subtle axioms/specs, both in traditional XML and with Semantic Web languages. Note that it could be that OWL(2) is not enough for all your constraints. But there could be some complementary checking mechanisms (using SPARQL queries is an obvious candidate, but there could be others) which would help you perform validation without changing the semantics.

> But that's exactly it - the semantics is "alternative" and on its face,
> the semantics of the published OWL file is something else entirely.
> As a concrete example, if I serve an OWL file from my web server, using
> application/rdf+xml as suggested by the OWL specs [1], the
> interpretation will be as RDF triples using the RDF and OWL built-in
> semantics, thus resulting in the generation of new triples, potentially
> contradiction with other ontologies, and not in validation as expected.

Well, contradiction (aka inconsistency) is what is used for data validation in the RDF/OWL world. So if we can detect contraditions I wouldn't be unhappy, at least from the perspective of us able to validate some data :-)

> What *would* work is using application profile specific classes for each
> separate OWL-based AP, and only constraining them, but that might appear
> a bit cludgy.

Or forcing you to make explicit the hidden assumptions of your profile...

It's really a situation where the cons for an OWL approach (and being awkward to manipulate is not the least default OWL has, sure) could be balanced by some strong pros, and we should not discard them too quickly!



> So, I'm a bit unsure regarding using non-standard semantics of OWL. I
> don't really see a clean solution at the moment.
> /Mikael
> [1] http://www.w3.org/TR/owl-ref/#MIMEType
Received on Tuesday, 12 October 2010 11:11:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 12 October 2010 11:11:48 GMT