RE: The notion of a "classification criterion" as a class

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.

(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@cs.man.ac.uk]
> Sent: Thursday, April 22, 2010 9:36 AM
> To: Benedicto Rodriguez
> Cc: ontolog-forum@ontolog.cim3.net; 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@ontolog.cim3.net and
> public-owl-dev@w3.org.
>
>       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@ecs.soton.ac.uk
>
>       ----
>       [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

Received on Saturday, 24 April 2010 08:34:59 UTC