W3C home > Mailing lists > Public > public-owl-wg@w3.org > November 2007

Re: UFDTF Metamodeling Document

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Thu, 29 Nov 2007 04:14:28 -0500 (EST)
Message-Id: <20071129.041428.259801198.pfps@research.bell-labs.com>
To: conrad.bock@nist.gov
Cc: public-owl-wg@w3.org

From: "Conrad Bock" <conrad.bock@nist.gov>
Subject: RE: UFDTF Metamodeling Document
Date: Wed, 28 Nov 2007 13:58:59 -0500

[...]

>  >  > That's my question.  :) They work in OWL 1, including reasoners
>  >  > (see example above), so I was expecting OWL 1.1 would be backward
>  >  > compatible in this.
> 
>  >  Well, they don't work in OWL DL, only in OWL Full, as subclassing
>  >  owl:Class is outside of OWL DL.  They also don't work in OWL 1.1, as
>  >  OWL 1.1 is (currently) only has a DL-style definition.
> 
> I should have said work in the OWL 1 tooling.  

Well, perhaps it would be better to say that this works with tools that
handle supersets of OWL DL or tools that handle OWL Full.  However,
although existing practice on extensions can be a good input to
extending a recommendation, there may be good reasons not to use the
this practice.

> Racer (through Protege),
> Pellet (through TopBraid), and JENA can infer that Mutt is unsatisfiable
> in example [1] in http://www.w3.org/2007/OWL/wiki/OWLMetamodeling.  Will
> get the working files from one of our researchers and post.

That would be useful, but it would also be useful to know which version
of Protege, Racer, Pellet, TopBraid, and JENA are involved, and what is
being passed to the reasoner.  (For example, it may be that Protege is
converting to OWL DL and thus that Racer isn't handling this ontology.)

> The tools behave how I'd expect them to, ie, instances of subclasses of
> owl:Class are instances of owl:Class, so it's natural that they'd behave
> consistently with "direct" instances of owl:Class.

Well, they are certainly not behaving how I expect them to.  I expect
OWL DL tools to report "syntax" violations when given inputs that are
not in OWL DL.

>  >  >  > How could it be guaranteed that there are no effects to the DL
>  >  >  > reasoning paradigm?
> 
>  >  > If the modeler subclasses owl:Class or owl:Property in a way that
>  >  > affects DL reasoners, then they're in OWL Full.  We can't make
>  >  > guarantees when we can't control the modeler.  However, 
>  >  > the applications
>  >  > I'm aware of would be introducing properties or restrictions in
>  >  > subclasses that would either
> 
>  >  >   - not affect DL reasoning, or
>  >  > 
>  >  >   - affect it in a way that can be expressed in DL (eg,
>  >  >     uml:class.isAbstract is equivalent to making the 
>  >  >     class equivalent to
>  >  >     union of its subclasses), or
>  >  > 
>  >  >   - the affect would be unspecified and not accounted for by DL
>  >  >     reasoners.
> 
>  >  Yes, but how can you be sure that you aren't affecting DL reasoning
>  >  or even affecting it in an "acceptable" manner?  For example, if the
>  >  isAbstract property above has a range, then providing an illegal
>  >  value would affect DL reasoning.  Determining whether the modelling
>  >  affects DL reasoning could, in the worst case, require complete OWL
>  >  Full reasoning.
> 
> Didn't follow this.  By "DL reasoning" I meant, for example, determining
> whether particular instances of owl:Class or its subclasses are
> satisfiable.  I wasn't expecting DL reasoning to tell if the value of
> isAbstract on an instance of uml:Class is within range.  

Well, to determine whether the input can be correctly translated into a
DL style, there would have to be some determination of whether the
initial ontology made semantic sense.  This could involve lots of
things, including checking that values of isAbstract are acceptable.

> It would be
> handy, of course, to apply DL at the "meta" level to check that
> instances of owl:Class or its subclasses satisfy their types, but it
> wasn't what is immediately needed.

Why not?  Consider an ontology in which the meta-level was semantically
incoherent.  Should this incoherency be ignored?  If so, then what is
the use of the metalevel?  If not, then the checking could be very
complicated.  Even picking out simple patterns/languages for which it is
easy to check inhcoherency is not easy.  (Just look at the early history
of Description Logics for several examples.)

>  >  >  > (I can see at least one way of setting up this sort of thing in
>  >  >  > OWL 1.1, but I don't know whether it would suit this usage
>  >  >  > because I don't know what is supposed to happen.)
> 
>  >  > Would be very interested to hear about it.
> 
>  >  Sure, just use the OWL 1.1 metamodelling facilities in an obvious
>  >  manner.  Set up a class, say uml:Class, and say things like:
> 
>  >  	SubClass( <umlclass> ... )
>  >  	ClassAssertion( <umlclass> uml:Class )
> 
>  >  You can even add information to the UML classes by adding
>  >  information to the ClassAssertion axiom.
> 
> What is "..." in the SubclassOf axiom?

The necessary condition for <umlclass>, as in the OWL 1.1 specification.

> Conrad

peter
Received on Thursday, 29 November 2007 09:31:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:27 GMT