Warning:
This wiki has been archived and is now read-only.

OWLMetamodeling

From OWL
Jump to: navigation, search

Alan, et al,

 > alanr: I agree with Ian that we have a clear set of goals for the
 > language extensions (originally motivated from OWLED), but don't
 > want to close off new use cases. Given the timeline, if you think
 > there's something missing based on a use case
 > [1]

Here are a couple uses of OWL I think are important to support:

 - Specializing Class and Property.  This is critical to modeling
   manufactured products and processes, to ensure product and process
   models support subclassing, and classification of individuals (eg,
   individuals corresponding to actual cars and actual executing
   processes).  Current tools support this, but a message from Bijan
   (through Evan) said "owl:Class" in OWL 1 is part of the "disallowed
   vocabulary", ie, it can't be mentioned in an axiom, like one
   establishing a subclass.  Since instances of subclasses of owl:Class
   (Property) are classes (properties), it seems natural for these
   instances to be treated like any other class (property).
   See example [1] below.
 - OWL Full, in particular, having Class and Property be nondisjoint.
 - RDF Statements (reified triples).
   These are important together for specializing product models with
   properties that "expand" to a network of other objects and
   properties in subclasses.  I've heard punning might work in OWL 1.1
   to make instances of both Class and Property, but haven't checked it
   yet, in particular whether it would support a common subclass
   between Class and Property.
   See example [2] below.

Conrad

[1]

Alan, et al,

Here's a (nonsense) example of subclassing owl:Class that supports DL reasoning:

 <owl:Class rdf:about="&myspace;Foo">
   <rdfs:subClassOf rdf:resource="&owl;Class"/>
 </owl:Class>
 <myspace:Foo rdf:about="&dog;CockerSpaniel">
 </myspace:Foo>
 <myspace:Foo rdf:about="&dog;Collie">
   <owl:disjointWith rdf:resource="&dog;CockerSpaniel"/>
 </myspace:Foo>
 <myspace:Foo rdf:about="&dog;Mutt">
   <rdfs:subClassOf rdf:resource="&dog;CockerSpaniel"/>
   <rdfs:subClassOf rdf:resource="&dog;Collie"/>
 </myspace:Foo>

Racer (through Protege), Pellet (through TopBraid), and JENA can infer that Mutt is unsatisfiable. The complete file and reasoners tested is at http://www.w3.org/2007/OWL/wiki/OWLMetamodelingExample1.

>  > This is critical to modeling manufactured products and processes,
>  > to ensure product and process models support subclassing, and
>  > classification of individuals (eg, individuals corresponding to
>  > actual cars and actual executing processes).
>  It would be helpful to get some more motivation/explanation of how
>  the feature connects to the use cases. Off the top of my head, I
>  don't see why this can't be done with standard classes and
>  properties.

From an OWL point of view product designers define classes of individual products (individuals having serial numbers) or simulated versions of these (individuals uniquely identifiable in some other way). So a product model is a special kind (subclass) of OWL class. For example:

 <owl:Class rdf:about="&myspace;ProductModel">
   <rdfs:subClassOf rdf:resource="&owl;Class"/>
 </owl:Class>
 <myspace:ProductModel rdf:about="&carmodels;Car"/>
 <myspace:ProductModel rdf:about="&carmodels;SmallCar">
   <rdfs:subClassOf rdf:resource="&carmodels;Car"/>    
   <owl:disjointWith rdf:resource="&carmodels;LargeCar"/>
 </myspace:ProductModel>
 <myspace:ProductModel rdf:about="&carmodels;LargeCar">
   <rdfs:subClassOf rdf:resource="&carmodels;Car"/>    
 </myspace:ProductModel>
 <myspace:ProductModel rdf:about="&carmodels;SmallAndLargeCar">
   <rdfs:subClassOf rdf:resource="&carmodels;SmallCar"/>
   <rdfs:subClassOf rdf:resource="&carmodels;LargeCar"/>
 </myspace:ProductModel>

SmallAndLargeCar could be inferred to be unsatisfiable.

The ProductModel resource is needed as the beginning of a "metamodel" for product modeling that includes other subtypes of owl:class, such as requirements, form, geometry and properties relating these classes. These class and properties in these metamodels are instantiated by product design tools to capture a specific design, such as the design of a car.

Conrad

[2]

Alan, et al,

>  > - OWL Full, in particular, having Class and Property be
>  >     nondisjoint.
>  An example of what you want to accomplish with this would help.
>  >   - RDF Statements (reified triples).
>  >     These are important together for specializing product models
>  >     with properties that "expand" to a network of other objects
>  >     and properties in subclasses.

For example, a design for cars might start out with a property relating engines to wheels, and later that to include a clutch between the engine and wheels. This could be done with role inclusions, but in general the initial property might "expand" to an entire network of related objects, going beyond role inclusion, as far as I can tell. Just to take this simple example:

 <owl:Class rdf:about="&compmf;PropertyClass">
   <rdfs:subClassOf rdf:resource="&rdf;Property"/>
   <rdfs:subClassOf rdf:resource="&owl;Class"/>
 </owl:Class>
 <owl:Class rdf:ID="Engine"/>
 <owl:Class rdf:ID="Wheel"/>

Property classes are subclasses of Statement, with restricted predicate, subject, and object properties:

 <compm:PropertyClass rdf:ID="powersWheel">
   <rdfs:subClassOf rdf:resource="&rdf;Statement"/>
   <rdfs:domain rdf:resource="#Engine"/>
   <rdfs:range rdf:resource="#Wheel"/>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:on Property rdf:resource="&rdf;predicate"/>
       <owl:hasValue rdf:resource="#powersWheel"/>
       <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1
       </owl:cardinality>
     </owl:Restriction>
     <owl:Restriction>
       <owl:onProperty rdf:resource="&rdf;subject"/>
       <owl:allValuesFrom rdf:resource="#Engine"/>
       <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1
       </owl:cardinality>
     </owl:Restriction>
     <owl:Restriction>
       <owl:onProperty rdf:resource="&rdf;object"/>
       <owl:allValuesFrom rdf:resource="#Wheel"/>
       <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1
       </owl:cardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
 </compm:PropertyClass>
 <owl:Class rdf:ID="Clutch"/>
 <owl:ObjectProperty rdf:ID="clutchInPowersWheel">
   <rdfs:domain rdf:resource="#powersWheel"/>
   <rdfs:range rdf:resource="#Clutch"/>
 </owl:ObjectProperty>
   

Individual powerswheel statements will have individual engines and wheels as subject and object, respectively, and there will be triples linking them to indvidual clutches. The above approach scales up to a large network of related objects as the "expansion" of the powersWheel property.

Conrad


Rebuttal

Some of the above is from a very intense email debate. Many of the messages are missing, resulting in lack of context and lack of replies. In particular, the following message http://lists.w3.org/Archives/Public/public-owl-wg/2007Nov/0589.html is very relevant, and rebuts some of the points in the messages selected above.

However, the message cited above verifies that subclassing OWL class does not prevent reasoners from working on the instances of those subtypes as they normally would. The complete file and reasoners tested is at http://www.w3.org/2007/OWL/wiki/OWLMetamodelingExample1.