RE: Returning to OWL and application profiles

Mikael,

I think it would be better to encourage the use of owl:subClassOf and owl:subPropertyOf to resolve this scenario instead. For example:

General-purpose class:
foo:Widget a owl:Class .

General-purpose property:
bar:title a owl:Property .

Limited-purpose domain:
baz:Widget owl:subClassOf foo:Widget.
baz:title owl:subPropertyOf bar:title .

Domain-specific cardinalities can be applied to terms in the domain-specific ontology without creating general semantic clashes. Other limited-purpose domains could do the same.

Jeff

> -----Original Message-----
> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Mikael Nilsson
> Sent: Monday, October 11, 2010 10:15 AM
> To: public-lld@w3.org
> Subject: Returning to OWL and application profiles
> 
> Hi all!
> 
> 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*.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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 Monday, 11 October 2010 21:05:32 UTC