On Apr 24, 2010, at 3:32 AM, Benedicto Rodriguez wrote: (01)
> Hi Alan,
>
> Thanks for the detailed reply as well! It's very interesting that
> this thread caught your attention because the original email was in
> part motivated by some findings regarding the application of the
> Normalisation mechanism. In fact, the main "building blocks" that I
> am using in the ontology models from the :Person and :Wine domain
> examples are the Normalisation and "Specified Values" pattern that
> you refer to.
>
> However, even after using Normalisation and Specified Values (value
> partitions), I still "feel" the need to somehow *explicitly*
> represent the classification criteria of "person by gender", "person
> by kinship", "wine by color" and "wine by grape" in the respective
> ontologies. My first intuitive attempt to do so, was to use OWL
> classes (:PersonByGender, ..., :WineByGrape) but I realized the
> problems of this approach after Pat's and Doug's comments.
>
> I'll try to summarize how I got to that point. I'll use the :Wine
> domain example this time because I think it helps better to see the
> generic case behind the modeling issue. Using Normalisation and
> Specified Values, a portion of the :Wine ontology model including 2
> classification criteria (by grape and by color) might look somewhat
> similar to this (please bear with me for the limitations of
> illustrating the hierarchy structure using the text editor):
>
> :Independent_Entity (aka :Self_Standing_Entity)
>
> |-- :Grape
> |-- :WineGrape
> |-- :MerlotGrape
> |-- :ChardonnayGrape
> |-- (etc...)
>
> |-- :Wine
>
> |-- :MerlotWine
> |-- :ChardonnayWine
> |-- (etc... meaning rest of "wines by grape")
>
> |-- :RedWine
> |-- :RoseWine
> |-- (etc... meaning rest of "wines by color"
> although in this case, only :WhiteWine is left)
>
> |-- :SpecificMerlotWineClass
> |-- :SpecificRedWineClass
> |-- :SpecificMerlotAndRedWineClass
> |-- :SpecificChardonnayWineClass
> |-- :SpecificWhiteWineClass
> |-- :SpecificChardonnayAndWhiteWineClass
> |-- (etc... meaning rest of "specific" wine classes that
> we would need to represent and automatically classify
> by the reasoner based on their "grape" and "color")
>
> :Dependent_Entity (aka :Refining_Entity)
>
> |-- :Value_Partition
> |-- :WineColor
> |-- :Red
> |-- :Rose
> |-- :White
>
> Some notes/clarifications about this model:
>
> * For space and simplicity, some important aspects of the
> Normalisation mechanism have not been fully specified, such as the
> fact that the subclasses of :Wine associated to a classification
> criterion are "defined classes" (:MerlotWine, ..., WhiteWine) and
> the specific wine subclasses to be automatically classified by the
> reasoner are "primitive classes" (:SpecificXxxWineClass). For
> example, [1] and [2] show the definitions of :MerlotWine
> and :SpecificMerlotWineClass respectively. These definitions would
> cause the reasoner to infer that :SpecificMerlotWineClass is a
> subclass of :MerlotWine. (Perhaps this link might help illustrate
> what I'm trying to refer to: http://www.gong.manchester.ac.uk
> /odp/html/Normalisation.html).
>
> * The "wine by color" classification criteria is represented using
> the "Specified Values" value partition pattern.
>
> And again, looking at the inheritance structure of the :Wine
> hierarchy now *normalised*, it presents the *same* issue mentioned
> at the beginning of my original email! Which was that we could
> argue that the inheritance structure is not satisfactory because
> "different concepts are represented by classes at the same level".
> Sorry for repeating myself, but the structure seems to be "asking"
> for some classes to separate these different concept groups. The
> already mentioned :WineByColor, :WineByGrape and now maybe even
> a :SpecificWine or :NamedWine or for consistency :WineByName
> classes. The hypothetical inheritance structure would be:
>
> |-- :Wine
> |-- :WineByGrape
> |-- :MerlotWine
> |-- :ChardonnayWine
> |-- (etc...)
> |-- :WineByColor
> |-- :RedWine
> |-- :RoseWine
> |-- (etc...)
> |-- :WineByName
> |-- :SpecificMerlotWineClass
> |-- :SpecificRedWineClass
> |-- :SpecificMerlotAndRedWineClass
> |-- (etc...)
>
> And so, this is my dilemma. The ontology is normalised and still
> seems to "need" this :WineByClassificationCriterion classes. (I'd
> like to point out that the examples illustrating this issue in the
> original email didn't mention the Normalisation mechanism on
> purpose. My intention was to try to simplify the background and yet,
> convey the point of the modeling problem).
>
> Based on the replies gathered so far, the consensus seems to be that
> using a class is not the best approach to represent a
> "classification criterion" in OWL DL. Allow me to recap. The
> suggestion instead, is to use a restriction on a property to define
> the classes that form the "classification criterion". For
> example, :MerlotWine is the restriction of the
> property :madeFromGrape to :MerlotGrape (see [1]), :RedWine is the
> restriction of the property :hasColor to :Red, and so on. However,
> as part of the Normalisation mechanism, all these properties and
> restrictions are already asserted in the ontology model!
>
> This leaves me thinking that the "vision" of separating the post-
> normalisation flat hierarchy of subclasses of :Wine (or :Person or
> in general any other normalised :DomainConcept) into homogeneous
> subgroups is *not really necessary or possible* after all, given the
> semantics of OWL DL. Not sure if everyone would agree with that as
> the final conclusion but if that was the case, it would feel somehow
> kind of hard to accept. (02)
But why would it be hard to accept? After all, the semantic model
underlying OWL-DL is very straightforward. So, ask how your vision can
be re-stated in terms of classes considered as simple sets. What
differences **between sets** could account for the distinction between
Wines and WinesByColor ? And I think it is fairly clear that there is
no difference between them, when they are considered as sets,
independent of the class hierarchy you see them as belonging in. They
have to be the same set: so, in OWL-DL, they have to be the same class. (03)
I suspect that you are used to thinking of classes as nodes in a
classification hierarchy, but that is not the primary OWL intuition.
The subclass hierarchy in OWL-DL is simply a consequence of the
extensional subset relationship: if all the members of A are also
members of B, then A is a subClass of B. That is what subClass
**means** in OWL-DL (and similar languages.) (04)
I find it interesting that you feel that the normalized ontology seems
to 'need' these XByY classes, and that the **structure** 'seems to be
asking' for them (my emphasis.) But this way of thinking is entirely
alien to the semantics of OWL (or any other extensional - set-based -
language), where the 'structure' of the subsumption hierarchy is
emergent rather than imposed from above. Subsumption here is a binary
relation between sets, and is determined entirely by their membership.
Any "structure" that the overall hierarchy has must arise from this
purely binary relationship. (05)
Good luck with your project, but you need to be using a formalism with
a different kind of underlying semantics than that used by OWL-DL. (06)
Pat Hayes (07)
>
> (There are some additional findings regarding the application of the
> Normalisation mechanism that I think it would interesting to
> discuss. However, given that they deviate from the core topic
> explored so far, together with this already lengthy reply, I think
> it'd be better to leave for a separate post to follow up shortly).
>
> Any comments or feedback are indeed very welcome.
>
> Regards,
> Bene Rodriguez-Castro
>
> ----
> [1] Definition of :MerlotWine.
>
> :MerlotWine rdf:type owl:Class ;
> rdfs:subClassOf :Wine ;
> owl:equivalentClass [ rdf:type owl:Restriction ;
> owl:onProperty :madeFromGrape ;
> owl:someValuesFrom :MerlotGrape ] .
>
> [2] Defintion of :SpecificMerlotWineClass.
>
> :SpecificMerlotWineClass rdf:type owl:Class ;
> rdfs:subClassOf :Wine ,
> [ rdf:type owl:Restriction ;
> owl:onProperty :madeFromGrape ;
> owl:someValuesFrom :MerlotGrape ] .
>
>
>> -----Original Message-----
>> From: Alan Rector [mailto:rector@xxxxxxxxxxxx]
>> Sent: Thursday, April 22, 2010 9:36 AM
>> To: Benedicto Rodriguez
>> Cc: ontolog-forum@xxxxxxxxxxxxxxxx; OwlED-list; Robert Stevens
>> Subject: Re: The notion of a "classification criterion" as a class
>>
>> Benedicto
>>
>>
>> For a generic reference on the mechanism we call "Normalisation"
>> which
>> addresses this issue, see
>> A. Rector 2003. Modularisation of domain ontologies Implemented in
>> description logics and related formalisms including OWL. Knowledge
>> Capture 2003. 121-128.
>> http://www.cs.man.ac.uk/~rector/papers/Modularisation-normalisation-
>> rector.pdf
>>
>> Robert Stevens, copied on this email, has an extensive family history
>> ontology that addresses all these issues.
>>
>>
>> In principle we would address issues of this sort following the
>> reference above as something like:
>>
>>
>> Independent_entity
>> ...
>> Person
>>
>>
>> Dependent Entity
>> Value_partition
>> Gender
>> Male
>> Female
>>
>>
>> Plus properties such as
>> has_child
>> has_sibling
>>
>>
>> Then Parent == Person that has_child some Person.
>> Man == Person that has_gender some Male
>> etc.
>> (If you prefer you can see individuals for values such as male and
>> female; there are
>> tradeoffs in either approach. See the W3C Best Practice note on
>> "Specified Values".
>> http://www.w3.org/TR/swbp-specified-values/ )
>>
>>
>> It would be nice to define the relation has_sibling in terms of
>> has_child, but this is tricky, since if you use the natural
>> representation:
>>
>>
>> inv(has_child) o has_child --> has_sibling
>>
>>
>> then everybody is their own sibling. There's no easy way around this.
>>
>>
>> As to categories such as "Person by Gender" that might be defined in
>> OWL as
>> "Person that has_gender some Gender", there are two problems: one
>> technical and one philosophical.
>>
>>
>> The technical problem is that if you have made the generic assertion
>> that all people have genders,
>> Person subclassOf has_gender some Gender
>> Then
>> Person_by_gender is logically equivalent to Person.
>>
>>
>> If you are willing to forgo the generic statement, then you can
>> create
>> the subclass.
>>
>>
>> The Philosophical problem concerns the status of classes such as
>> "Person by Gender" which many ontologists deplore as not being a
>> proper
>> "universal". From a purely logical point of view, this need not be a
>> problem. In practice such constructs are commonly used in OWL KBs
>> for
>> convenience, but best defined to reflect the developer's
>> intentions, so
>> that as the KB evolves, the reasoner keeps the KB consistent with
>> those
>> intentions.
>>
>>
>> Regards
>>
>>
>> Alan
>>
>>
>>
>>
>> On 15 Apr 2010, at 20:30, Benedicto Rodriguez wrote:
>>
>>
>> Hello everyone,
>>
>> Apologies for cross-posting but I thought the email might be
>> relevant to both mailing lists: ontolog-forum@xxxxxxxxxxxxxxxx and
>> public-owl-dev@xxxxxxx
>>
>> I am trying to put together an ontology design pattern (or
>> combination of patterns) with the intent of modeling multiple
>> alternative classification criteria of a domain concept. At this
>> point, I have to commit my focus to OWL (or more specifically, to an
>> expressivity level within OWL-DL).
>>
>> In the process I have come across what I think it is an
>> interesting modeling scenario. Let me use a simple example to
>> describe
>> it extracted from [1]. Consider the following set of classes (as a
>> subset of a larger ontology model) in the popular domain of "family
>> relationships" organized according to the following subsumption
>> hierarchy:
>>
>> :Person
>> |-- :Man
>> |-- :Woman
>> |-- :Parent
>> |-- :Child
>> |-- :Sibling
>>
>> We could argue that this inheritance structure is not
>> satisfactory because different concepts are represented by classes at
>> the same level. That is, the concept of gender, represented by the
>> classes :Man and :Woman, and the concept of kinship relationships,
>> represented by the classes :Parent, :Child and :Sibling. In that
>> sense, the concepts of gender and kinship could be seen as two
>> different classification criteria for all the subclasses of :Person.
>>
>> The issue that I am trying to solve deals with how to
>> incorporate
>> the representation of these classification criteria concepts into the
>> ontology model.
>>
>> An initial approach (kind of intuitive to me) would be two
>> represent the two classification criteria as classes (say
>> :PersonByGender and :PersonByKinship) and regroup all the
>> subclasses of
>> :Person accordingly. The result would look like:
>>
>> :Person
>> |-- :PersonByGender
>> | |-- :Man
>> | |-- :Woman
>> |-- :PersonByKinship
>> |-- :Parent
>> |-- :Child
>> |-- :Sibling
>>
>> However, I see a conceptual problem with this model regarding
>> the
>> subsumption relation between :Person and the classification criteria
>> classes :PersonByGender and :PersonByKinship, given that:
>>
>> - Who would be the individuals of classes such
>> as :PersonByGender
>> and :PersonByKinship? For example, if we consider :John and
>> individual
>> of type :Man, we can say that :John is also of type :Person. But
>> does
>> it make sense to say that :John is of type :PersonByGender???
>>
>> - Are these classes :PersonByGender and :PersonByKinship in fact
>> meta-classes? (If I could use an analogy with object-oriented design,
>> it is as if these two classes could be seen as abstract or deferred
>> classes).
>>
>> This type of modeling scenario can be found in many concepts
>> from
>> various domains (essentially any concept whose individuals/instances
>> could be grouped according to multiple different classification
>> criteria). Below is another popular example in the OWL literature
>> modified to fit into the same scenario and illustrate the problem
>> [2]:
>>
>> :Wine
>> |-- :WineByColor
>> | |-- :WhiteWine
>> | |-- :RedWine
>> | |-- (etc.)
>> |-- :WineByGrape
>> |-- :PinotGrigioWine
>> |-- :MerlotWine
>> |-- :CabernetSauvignonWine
>> |-- (etc.)
>>
>> In this case the classification criteria of :Wine are wines
>> based
>> on their color and wines based on their type of grape. Like in the
>> example of :Person, the classification criteria classes :WineByColor
>> and :WineByGrape seem intuitive choices to group the rest of all
>> subclasses of :Wine. However, the subsumption relation between :Wine
>> <- :WineByColor and :Wine <- :WineByGrape seems problematic. Who
>> would be the individuals of classes such as :WineByColor or
>> :WineByGrape?
>>
>> In general terms, the subsumption relation between a
>> :DomainConcept and a :ClassificationCriterion for that concept
>> seems a
>> bit controversial. For example, It does not seem to fit into one of
>> the 4 kinds of is-a relations defined by Johansson[3] plus I think
>> it
>> would violate the constraints of the OntoClean evaluation as well.
>> (Even though, for the most part I understand the theory behind the
>> OntoClean method and I think it is very useful, I personally find
>> it a
>> bit difficult to apply coming from a software developer background).
>>
>> In summary, after this lengthy introduction, below are the
>> questions that I am trying to answer:
>>
>> - Are subsumption relations such as :Person <- :PersonByGender
>> or
>> :Wine <- :WineByGrape acceptable?
>>
>> - Can classes such as :PersonByGender or :WineByGrape be
>> "correctly" represented in the ontology model? That is, classes that
>> correspond to a "classification criterion" and that may not have
>> individuals (or extensional representation) in the real world.
>>
>>
>> - Are there some guidelines or good-practices on how to
>> represent
>> concepts that correspond to a"classification criterion" of the domain
>> concept that is being modeled?
>>
>> Thanks a lot for any comments you may have!
>>
>> (For the record, I'll mention that this work is part of my PhD
>> research. One aspect of the overall idea is trying to adapt faceted
>> classification design guidelines to ontology design. The notion of
>> "facet" and "classification criterion" seem to be fairly similar.
>> Identifying a reasonable representation of a "classification
>> criterion"
>> in an ontology can help to bridge the gap between these two design
>> methodologies and that's the reason for the examples above.
>> Finally, I
>> would like to present if possible, the overall outcome as an ontology
>> design pattern or combination of them).
>>
>> Regards,
>> Bene Rodriguez-Castro
>>
>> Postgraduate Student | Intelligence, Agents and Multimedia Group
>> | School of Electronics and Computer Science | University of
>> Southampton | Southampton SO17 1BJ | United Kingdom | Phone: +44 23
>> 8059 4059 | Email: b.rodriguez@xxxxxxxxxxxxxxx
>>
>> ----
>> [1]
>> http://protege.cim3.net/file/pub/ontologies/generations/generations.owl
>> [2] http://protege.cim3.net/file/pub/ontologies/wine/wine.owl
>> [3] Ingvar Johansson. Four kinds of is_a relations: genus-
>> subsumption, determinable-subsumption, specification, and
>> specialization. In WSPI 2006: Contributions to the Third
>> International
>> Workshop on Philosophy and Informatics, Saarbrucken, 2006.
>>
>>
>>
>> -----------------------
>> Alan Rector
>> Professor of Medical Informatics
>> School of Computer Science
>> University of Manchester
>> Manchester M13 9PL, UK
>> TEL +44 (0) 161 275 6149/6188
>> FAX +44 (0) 161 275 6204
>> www.cs.man.ac.uk/~rector
>> www.co-ode.org
>> http://clahrc-gm.nihr.ac.uk/
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 9.0.814 / Virus Database: 271.1.1/2826 - Release Date:
>> 04/21/10 12:09:00
> (08)
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes (09)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (010)
|