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

RE: UFDTF Metamodeling Document

From: Conrad Bock <conrad.bock@nist.gov>
Date: Wed, 28 Nov 2007 13:58:59 -0500
To: "'Peter F. Patel-Schneider'" <pfps@research.bell-labs.com>
Cc: <public-owl-wg@w3.org>
Message-ID: <123b01c831f0$bd79fe60$b3200681@MEL.NIST.GOV>


 >  > It would be fine with me if it weren't, because it would reduce
 >  > cross-talk with OMG.  Not sure what Elisa and Evan think.  I
 >  > misunderstood which draft documents were on the recommendation
 >  > track.  BTW, I assume draft documents that are not never included
 >  > in the recommedation track will just remain unofficial work of the
 >  > WG?

 >  They can be "submissions"/notes, which gives them some official
 >  status, and permanency.

I'd prefer if they weren't even notes, to prevent cross-talk with OMG.
Not sure what Elisa and Ecan think about this.

 >  > I meant that in the OWL 1 sense (namespace:name).  See 
 >  > example above.

 >  Then I don't see any reason that M1:car is the "type" of 
 >  M0:johns-car.

The message didn't have the complete example, it would be:

 <owl:Class rdf:about="&m1;Car">

 <m1;Car rdf:about="&m0;johns-car">

which, as I understand it, are XML formats for rdf:type statements.

 >  > 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.  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.

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.

 >  >  > 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.  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.

 >  >  > (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?

Received on Wednesday, 28 November 2007 18:59:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:00 UTC