Re: OWL, XML-RDF and Imports

From: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Subject: RE: OWL, XML-RDF and Imports
Date: Mon, 17 Feb 2003 17:09:41 +0100

> 
> > >
> > > Semantically yes, syntactically no.
> >
> > Why not?  It is, after all the translation of a
> > semantically-equivalent bit
> > of syntax.
> 
> We would need to formalize that.
> Could be done in a mapping rule.

I believe that this is already handled correctly.

> > > I think that points to a way forward with these rules
> > >
> > > DisjointClasses(d1,...,dn)
> > >
> > > is equivalent to n(n-1)/2 statements
> > >
> > > DisjointClasses(di,dj)
> > >
> > > and the pair statements are easier to deal with syntactically.
> >
> > > To me the remaining problem is to how to do so without necessitating an
> > > explosion of repetition that might be necessary.
> >
> > What explosion?  At worst it would be n^2.
> 
> Hmmm, depending on the n I would see n^2 as an explosion.

Why?  It is not as if things could be any better in the RDF syntax for
OWL.  All that is happening is that the abstract syntax can be more succinct.

> In terms of the concrete syntax if the mapping rules only map pairs of
> DisjointClasses then the rules would be:
> 
> X owl:disjointWIth Y .
> 
> is permitted iff:
> Each of X and Y is either:
>   a classID uriref
> or
>   a well-formed description blank nodes which are not the object of any
> other triple, or the subject of some other owl:disjointWith or
> owl:sameClassAs triple.

... which occur only as the subject or object of owl:disjointWith triples ...

should work

> And is in OWL Lite if X is not a uriref. (dangling issue to explore ... as
> to whether this is correct).
> 
> This would move the disjoint classes case from "unacceptable to Jeremy" to
> "I don't like it, but at least it is possible to articulate it without
> serious difficulty".
> 
> Assuming we did the same with EquivalentClasses then the mapping rules for
> both would be:
> 
> DisjointClasses( d1, d2 )
> =>
> T(d1) owl:disjointWith T(d2) .
> 
> and
> 
> DisjointClasses( d1 ... dn )
> =>
> T(DisjointClasses( di dj ))
>   i < j, n > 2
> 
> (note this involves copying the description trees and generating multiple
> blank nodes for the same description)
> 
> [I note that the Feb 15th mapping rules have reduced the number of triples
> generated for EquivalentClasses; while this is a good thing it seems
> sensible to try and keep the two cases together]



> 
> In terms of test cases this would have oddities like:
> 
> OWL DL:
> 
> <owl:Class rdf:ID="x">
>   <owl:sameClassAs>
>     <owl:Class rdf:about="#y"/>
>   </owl:sameClassAs>
>   <owl:sameClassAs>
>     <owl:Class rdf:about="#z"/>
>   </owl:sameClassAs>
>   <owl:intersectionOf rdf:parseType="Collection">
>     <owl:Class rdf:about="#a"/>
>     <owl:Class rdf:about="#b"/>
>   </owl:intersectionOf>
> </owl:Class>
> 
> OWL Full:
> 
> <owl:Class>
>   <owl:sameClassAs>
>     <owl:Class rdf:about="#y"/>
>   </owl:sameClassAs>
>   <owl:sameClassAs>
>     <owl:Class rdf:about="#z"/>
>   </owl:sameClassAs>
>   <owl:intersectionOf rdf:parseType="Collection">
>     <owl:Class rdf:about="#a"/>
>     <owl:Class rdf:about="#b"/>
>   </owl:intersectionOf>
> </owl:Class>
> 
> But we are now at the level of aesthetic trade-offs.
> I note that permitting owl:sameClassAs and owl:disjointWith more liberally
> (like in my proposal) would either significantly damage the clarity of the
> direct semantics or require some other level of indirection where a
> construct like my
>   classComparison
> is mapped into DisjointClasses or EquivalentClasses prior to its semantic
> interpretation.
> 
> Jeremy


peter

Received on Monday, 17 February 2003 11:23:12 UTC