Dear Marc,
Your proposed approach works indeed very
nicely. Especially when we use one more indirection: using a (one) generic MetaClass
and its individual first (“Variant” resp. “Occurrence”)
and then further subclass “Variant” and pull all other generated
classes (== variant meta-class individuals) under the “Occurrence class”).
This way we can attach generic info relevant for all variants (ie having shape)
and all occurrences (ie having occurrence hasParts relation).
We are internally now discussing the
disadvantages you already expressed wrt computability.
I have one more question on your remark at
the end of your mail (“…a better representation would
be to do away with the thingType pattern and simply have a Wine class
hierarchy (since "type" is equivalent to "class") “).
Do you mean that it would be an
alternative to treat the variant/type level as the lowest (leaf) class level ? This
is still an non owl-full approach that I like myself. The only thing then is
that it seems conceptually ok but this lowest level should be treated more
dynamicaly (ie not too invariant if you see what I mean). This lowest
level would be typically created as an alternative to instantiating what’s
there (ie for reuse on a specific client/project etc.). So it would be
technically/conceptually the same but one would use these classes differently. (also
because you sometimes cannot anticipate an infinite amount of leaf classes
anyway). My question actually is: did you mean such an approach or did you mean
some other alternative ?
Finally, I think but I am not sure that
the “individual” meta-concept was meant to denote occurrences
anyway (and one should indeed turn all intermediate “types” into
classes). But I cannot find any evidence in the owl semantics for this ….This
would again give some good reason to go for the last mentioned approach…
Thanks a lot again,
Michel
Ps
For those interested I hereby copied my
current solution/pattern based on Marc’s ideas
<?xml
version="1.0"?>
<!DOCTYPE rdf:RDF [
<!ENTITY owl "http://www.w3.org/2002/07/owl#" >
<!ENTITY xsd
"http://www.w3.org/2001/XMLSchema#" >
<!ENTITY rdfs
"http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY rdf
"http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
]>
<rdf:RDF
xmlns="http://www.owl-ontologies.com/Ontology1139477608.owl#"
xml:base="http://www.owl-ontologies.com/Ontology1139477608.owl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:owl="http://www.w3.org/2002/07/owl#">
<owl:Ontology rdf:about=""/>
<owl:Class
rdf:ID="Door">
<rdfs:subClassOf rdf:resource="#Variant"/>
</owl:Class>
<owl:DatatypeProperty rdf:ID="height">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Window"/>
<rdfs:range rdf:resource="&xsd;float"/>
</owl:DatatypeProperty>
<Variant
rdf:ID="Occurrence">
<width rdf:datatype="&xsd;float">2.0</width>
<height rdf:datatype="&xsd;float">3.0</height>
</Variant>
<Placement rdf:ID="P1"/>
<Placement rdf:ID="P2"/>
<owl:Class
rdf:ID="Placement"/>
<owl:ObjectProperty
rdf:ID="placement">
<rdfs:domain rdf:resource="#Occurrence"/>
<rdfs:range rdf:resource="#Placement"/>
</owl:ObjectProperty>
<Door
rdf:ID="StandardDoor">
<rdfs:subClassOf rdf:resource="#Occurrence"/>
</Door>
<StandardDoor
rdf:ID="StandardDoor-no4">
<placement rdf:resource="#P2"/>
</StandardDoor>
<owl:Class
rdf:ID="Variant">
<rdfs:subClassOf rdf:resource="&owl;Class"/>
</owl:Class>
<owl:DatatypeProperty rdf:ID="width">
<rdf:type rdf:resource="&owl;FunctionalProperty"/>
<rdfs:domain rdf:resource="#Window"/>
<rdfs:range rdf:resource="&xsd;float"/>
</owl:DatatypeProperty>
<owl:Class rdf:ID="Window">
<rdfs:subClassOf rdf:resource="#Variant"/>
</owl:Class>
<Window
rdf:ID="Window-2-3">
<rdfs:subClassOf rdf:resource="#Occurrence"/>
<width rdf:datatype="&xsd;float">3.0</width>
<height rdf:datatype="&xsd;float">2.0</height>
</Window>
<Window-2-3
rdf:ID="Window-2-3.no1">
<placement rdf:resource="#P1"/>
</Window-2-3>
</rdf:RDF>
H.M. (Michel) Bohms
Senior Consultant Construction Innovation
TNO Built Environment and Geosciences
Email: [hidden email]
Phone: +31 15 276 3107
Fax: +31 15 276 3024
Visiting Address:
Van Mourik Broekmanweg 6
2628 XE Delft
The Netherlands
Postal Address:
P.O. Box 49
2600 AA Delft
The Netherlands
http://www.tno.nl
The disclaimer that applies to e-mail from TNO Built Environment and Geosciences can be found on
http://www.tno.nl/disclaimer/email.html
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Mark Feblowitz
Sent: Wednesday, February 08, 2006
3:43 PM
To: [hidden email]
Subject: [protege-owl] Re: Classes
as Individuals
I have done this on a few occasions, to the consternation of others who
don't see the merit (sometimes the requirement) for a token-class-metaclass
approach to modeling. Sometimes, classes do need to be treated as individuals,
instances of metaclasses.
The way I've done it is to first create the metaclass (MyMetaclass) as a
sublcass of owl:class, and then to create the individual (MyClass), which, in
Protege Owl, automatically appears as a subclass of owl:Thing.
To do this with the Protege Owl plugin, you first have to make owl:Class be
visible (OWL menu --> Preferences ... --> Visibility, and then check
owl:Class). Once that's done, you'll see rdfs:class in the class browser. Twist
it open and you'll see owl:class. In the Individuals tab, create the new
"individual class."
The Object and DataType properties (e.g., myProp) in the metaclass are induced
in the individuals, so the classes have additional properties. And the new
properties for the metaclass appear in Class Editor (a testament to the good
design of the Protege Owl Plugin).
A few things to note:
First, the Protege Owl plugin handling of individuals seems to require that the
class (MyClass) be created anew as an individual, and then manipulated as
a class. I have not found a way to associate an existing class as an individual
in class MyMetaClass.
Next, remember that such a model is Owl Full and is no longer computable and
can no longer benefit from reasoners (any?). It's a major frustration
when the token-class-metaclass model is the cleanest way to express your model.
There may be ways to factor out the Owl-Full-ness into a separate ontology,
providing the computability in the one without metaclasses and the
expressiveness in the Owl Full ontology, but I've found that to be very inconvenient
(to say the least).
It would be great to hear of a way to use metaclasses and be able to perform
inferencing on the resultant models. But my understanding is that such
reasoning is outside of Owl DL and thus would require some non-DL reasoner. You
could build your own, but you'd have to re-implement all of the Owl-DL
reasoning, and, as I understand it, you'd have no guarantees of computability.
In some cases, the Token-Class-Metaclass means of modeling is not entirely
warranted, especially for Owl ontologies. There are times when I've wanted
metaclasses only because I've wanted the classes to be values of properties
(e.g., a Wine hasWineType property, with range WineClass). With some redesign
(and a bit more "Owl-ish" thinking), a better representation would be
to do away with the thingType pattern and simply have a Wine class
hierarchy (since "type" is equivalent to "class"), or
to consider a property with allValuesFrom restriction (so the class constrains
values constrained by the class). And either alternative remains in Owl-DL, so
Owl reasoning is possible.
Hope that makes sense.
Mark
At 08:26 AM 2/8/2006, you wrote:
Dear OWL-modeller,
In the OWL Guide it is indicated that with OWL Full one can model multiple
type-layers by treating a class as an instance again (the wine, wine type,
bottle example). However I cannot find any details on how to do this! (the wine
example stays DL and just does not model bottles…). I want to apply (in
the European SWOP project) this idea towards product modelling where we like to
have a 3-level approach: generic product class, specific product variant and
actual (pointable/placed) product occurrence which form the primary nodes in a
product decomposition tree (BOM-structure).
Treating the specifc variant as lowest level classes (leafs) is often not
desirable (just relevant for one customer not in general ie not invariant
enough) or even impossible (potentially infinite amount of subclasses; think of
a window variant with non-constrained width and height datatype properties).
Currently we decided to go foor classes and variants (being the individuals of
those classes) and RELATE the occurrences (i.e. not via type). Clearly we would
prefer the more elegant 3-level type-approach promoting the first variant-individual
to a class that can be instantiated again with occurrence-individuals.
If we stayed on rdf level it would be trivial (just have a chain of type links)
but if possible we want to do it in OWL (even if it has to be OWL Full).
Any help/advice is greatly appreciated,
Michel Bohms
H.M.
(Michel) Bohms
Senior Consultant Construction Innovation
TNO Built Environment and Geosciences
Email: [hidden email]
Phone: +31 15 276 3107
Fax: +31 15 276 3024
Visiting Address:
Van Mourik Broekmanweg 6
2628 XE Delft
The Netherlands
Postal Address:
P.O. Box 49
2600 AA Delft
The Netherlands
http://www.tno.nl
The disclaimer that applies to e-mail from TNO Built Environment and
Geosciences can be found on http://www.tno.nl/disclaimer/email.html
Locked
