Representing Lists of values in OWL: "value partitions" and "value sets"

W3C Working Draft 12 June 2004

This version:

...

Latest version:

...

Previous versions:

This is the first public version

Editors:

Alan Rector, University of Manchester

Copyright © 2004 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

Abstract

There are many "qualities", "features", or "modifiers" used to describe other concepts, e.g. size, severity, texture, rank, for which in any one ontology there is a fixed list of 'values'. This document describes two methods to represent such lists of values: as partitions of classes or as enumerations of individuals. It does not disscuss the use of datatypes to represent lists of values.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document will be a part of a larger document that will provide an introduction and overview of all ontology design patterns produced by the Semantic Web Best Practices and Deployment Working Group.

This document is a W3C Working Draft and is expected to change. The SWBPD WG does not expect this document to become a Recommendation. Rather, after further development, review and refinement, it will be published and maintained as a WG Note.

This document is the First Public Working Draft. We encourage public comments. Please send comments to public-swbp-wg@w3.org

• Patterns for of use of datatypes to represent lists of values

Publication as a draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or made obsolete by other documents at any time. It is inappropriate to cite this document as other than work in progress.

General issue

There are many "qualities", "feature", or "modifiers" used to describe other concepts, e.g. size, severity, texture, rank, for which in any one ontology there are a fixed list of 'values'. There are at least three different ways to represent such lists of values:

1. As disjoint classes which exhaustively partition the parent class representing the quality;
2. As individuals whose enumeration makes up the parent class representing the quality;
3. As datatypes. Data types will more usually be used when there is a literal, numeric or derived dfata types rather than when there is an enumerated list of values. They will not be considered further in this paper although a supplement may be issued.

Use case examples

We want to describe persons as having qualities height: short, medium height, or tall; body type: slender, medium, or obese; and as having personality: introvert or extrovert, etc. It should not be possible to have more than one value for any of the qualities, e.g. it should be inconsistent (unsatisfiable) to be both tall and short. We will use the quality "height" in the examples. The others follow analogously. (Note that we refer here to "qualitative height" - i.e. tall, medium, short. Measured quantitative height must be represented separately with a datatype property.)

Diagraming Conventions

Ellipses represent classes. Squares represent instances. Closed undecorated arrows (pointing upwards if possible) represent rdfs:subclassOf; Open undecorated arrows indicate rdf:type; arrows decorated with a blob on the origin indicate restrictions if between classes or facts if between individuals. Restrictions are existential unless otherwise marked. Dotted arrows indicate that they are potentially inferrable by a reasoner from the other information. Upward facing square union symbols if spanning a set of rdfs:subclassOf links indicate owl:UnionOf; if spanning a set of rdf:type links indicate owl:oneOf. All classes are mutually disjoint and all individuals mutually different unless shown as overlapping or otherwise annotated.

Representation patterns

Pattern 1: Values as subclasses partitioning a quality

In this approach we consider the quality as a a class representing a continuous space that is partitioned by the values in the value set. To say that "John is tall" is to say that his height is inside the Tall_values partition of the Height_value quality. Theoretically, there is an individual height value, Johns_Height, but all we know about it is that it lies someplace in the Tall_value partition. The cass Tall_Person is the class of all those persons who have a height in the Tall_value partition. [See note 1]

Figure 1: A class-instance diagram of the use of partitioning classes for value sets

Some may find an alternative diagrammatic format adapted from Venn diagrams as shown in Figure 2 makes the intention clearer as it shows the partioning more explicitly.

Figure 2: An adapted Venn diagram showing the use of parttioning classes to represent lists of values. Every tall person must have a height from the Tall_value partition of Height_value. John has a specific instance of Height_Value that is in the Tall_value partition.

Representation for two variants of Pattern 1

Representation variant 1: Using a fact about the individual

{{The value set}}

:Height_Value
      a       owl:Class ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:unionOf (:Short_value :Medium_height_value :Tall_value)    {{This line makes the partition exhaustive}}
              ] .

:Tall_value
      a       owl:Class ;
      rdfs:subClassOf :Height_Value ;
      owl:disjointWith :Short_value , :Medium_height_value . {{The disjoint axioms make the subclasses partitioning}} 

:Medium_height_value
      a       owl:Class ;
      rdfs:subClassOf :Height_Value ;
      owl:disjointWith :Short_value , :Tall_value.

:Short_value
      a       owl:Class ;
      rdfs:subClassOf :Height_Value ;
      owl:disjointWith :Tall_value , :Medium_height_value .

{{The functional property}

:has_height
      a       owl:ObjectProperty , owl:FunctionalProperty ;  {{The property must be functional}}      rdfs:domain :Person ;
      rdfs:range :Height_Value

{{The class Person, its subclass Tall_person, and an individual person, John}}

:Person
      a       owl:Class.:John
      a       :Person ;
      :has_height :johns_height .
:johns_height
      a       :tall .

:Tall_person
      a       owl:Class ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:intersectionOf (:Person [ a       owl:Restriction ;
                            owl:onProperty :has_height ;
                            owl:someValuesFrom :Tall_value
                          ])
              ] .

Representation using variant 2: Placing an existential restriction on the individual

{{The same as variant 1 except that for the individual Jim, is represented as}}

:Jim
      a       :Person ;
      [a      owl:Restriction;                  
                  owl:onProperty :has_height ;                 
                  owl:someValuesFrom :Tall_value].

Considerations using Pattern 1:

• The result is in OWL-DL and classifies correctly using either FaCT or Racer - and almost certainly any other reasoner that handles any reasonable subset of OWL-DL.The semantics faithfully represent the partitioning a continuous quality space into a set of discrete values.
• The values can be further subpartitioned, e.g. Tall_value might be split into Moderately_tall_value and Very_tall_tall_value, simply by subdividing the Tall_value partition.
• There can be several alternative partitionings of the same quality space.
• If variant 2 is to be used as part of a database schema or similar, then a convention for creating anonymous instances in the database is required. (Logicians call such anonymous instances "skolem constants".) In practice, this can usually be ignored. A common convention is to use the class name or a string derived from it, e.g. "tall" as the symbol in the database. The fact that, strictly speaking, the semantics require the symbol to be interpreted in each case as a different anonymous instance of the class Tall_value will, in this case, be irrelevant to most applications and invisible to most users.
• The use of classes for values seems unintuitive to many people coming from the database and frame communities in which value sets are usually enumerated lists of symbols.

Code for this example

[N3] [RDF/XML abbrev] [Abstract syntax] [Protege-OWL]

See Note 2 on viewing this files with the Protege-OWL-CO-ODE tools or with OilEd.

Pattern 2: Values as individuals whose enumeration is equivalent to the quality

In this approach, the class Height_Value is considered as the enumeration of the individuals tal, medium_height, and short. Values are sets of individuals. To say that "John is tall", is to say that "John has the value tall for height" This assumes that a value is just an unique symbol, and a value set is just a a set of such symbols. Normally, the values will all need to be assertedt o be different from each other. ( In OWL, any two individuals might represent the same thing unless there is an axiom to say, explicitly, that they are different. In other words, OWL does not make the "Unique Name Assumption".) If we did not include the differentFrom axiom in the example, then it would be possible to have a person who was, for example, both tall and short.

The approach is shown diagrammatically in Figure 3.

S

Figure 3: A class-instance diagram of the use of enumerated instances to represent lists of values

Representation for Pattern 2

{{The value set}}

:Height_value
      a       owl:Class ;
      owl:equivalentClass
              [ a       owl:Class ;
                owl:oneOf (:medium_height :tall :short)  {{Define as one of three individuals}}
              ] .
:tall
      a       :Height_value ;
      owl:differentFrom :short , :medium_height .  {{Make values different. Otherwise might be inferred the same}}

:medium_height
      a       :Height_value ;
      owl:differentFrom :short , :tall .

:short
      a       :Height_value ;
      owl:differentFrom :tall , :medium_height .

:has_height
      a       owl:ObjectProperty , owl:FunctionalProperty ;
      rdfs:range :Height_value .

Considerations using Pattern 2:

• The representation is in OWL-DL, and a DL reasoners should eventually be expected to make correct inferences with individuals used in this way. However, neither FaCT nor Racer (the two most widespread open source reasoners in use today) perform all the expected inferences reliably.
• There is no possibility of further subpartitioning of values. This is because OWL supports only equality or difference between individuals. It does not allow individuals to have partial overlaps. It is not possible, as it is for classes, to say that one individual is equivalent to the the union (disjunction) of two other individuals.
• There is no way to represent alternative partitionings of the same quality space. Because individuals cannot overlap, if Height_value is defined as equivalent to enumeration of one list of distinct values, it cannot also be equivalent to a different list of distinct values. To do so would cause the reasoner to indicate a contradiction. (i.e that Height_Value was "unsatisfiable".)
• There is a straight forward match to the usage in databases and many frame systems without any assumptions or conventions about anonymous individuals..
• Many people find this the more intuitive approach.

OWL code for this example

See Note 2 on viewing this files with the Protege-OWL-CO-ODE tools or with OilEd.

Notes

[Note1]. In this document we have carefully distinguished between the class partitioning the value type as used in Pattern_1, e.g. Tall_value, and and individual value in a value type as used in Pattern_2, e.g. tall. In any given ontology we would normally advise against mixing the two patterns. If an ontology uses Pattern_1 consistently, then we might drop the _value suffix and begin the value partition name with a lower case letter to indicate its intent. However, we strongly suggest maintaining consistent naming and case conventions throughout any one ontology.

[Note2] The code in these examples has been produced using the Protege-OWl plugin and CO-ODE additional wizards and OwlViz available from http://protege.stanford.edu and following plugins/backends/owl. Some files may require the co-ode plugins linked to that page or at http://www.co-ode.org. Classification involving individuals cannot all be shown in this form and has been tested using oiled available from http://oiled.man.ac.uk. In all cases the Racer classifier has been used, available from http://www.sts.tu-harburg.de/~r.f.moeller/racer/.

References

Rector, A., Modularisation of Domain Ontologies Implemented in Description Logics and related formalisms including OWL. in Knowledge Capture 2003, (Sanibel Island, FL, 2003), ACM, 121-128. pdf here