ISSUE 5.19 proposal to resolve

SSUE 5.19 - Classes as instances

I propose to resolve this issue in the following way:

1. Treating classes/properties as instances of other
    classes/properties is allowed in OWL under certain semantic
    interpretations, as specified in the OWL semantics document [1].

2. For presentation purposes [2] we describe OWL in our documents as
    containing three varieties, namely OWL Lite, OWL DL and OWL Full,
    where only OWL Full contains the "classes as instances"
    feature.

3. We adapt the text of the GUIDE working draft [3] in the way
    indicated in the appended text, in an effort to make clear that the
    "classes-as-instances" feature is a regular OWL feature and not
    just for advanced users.

Guus

[1] http://www.w3.org/TR/2002/WD-owl-semantics-20021108/
[2] http://lists.w3.org/Archives/Public/www-webont-wg/2002Oct/0310.html
[3] http://www.w3.org/TR/2002/WD-owl-guide-20021104/



[NOTE: Changes are marked with tags <add> and <del>, resp. standing
for add or delete this piece of text.]


THE SPECIES OF OWL

OWL is in fact a set of three, increasingly complex languages.

* Owl Lite has been defined with the intention of creating a simple
   language that will satisfy users primarily needing a classification
   hierarchy and simple constraint features. For example, while it
   supports cardinality constraints, it only permits cardinality values
   of 0 or 1. For these reasons, it should be simpler to provide tool
   support for Owl Lite than its more complex relatives.

* OWL DL includes the complete OWL vocabulary, interpreted under a
   number of simple constraints. Primary among these is type
   separation. Class identifiers cannot simultaneously be properties or
   individuals. Similarly, properties cannot be individuals. OWL DL is so
   named due to its correspondence with description logics.
   <add>
   OWL DL is expected to be supported by reasoning tools based on
   description logic.
   </add>

* OWL Full includes the complete OWL vocabulary, interpreted more
   broadly than in OWL DL, with the freedom provided by RDF. In OWL
   Full a class can be treated simultaneously as a collection of
   individuals (the class extension) and as an individual in its own
   right (the class intension).
   <del>
   Another significant difference from OWL
   DL is that a DatatypeProperty can be marked as an
   InverseFunctionalProperty. These are differences that will be of
   interest to the advanced user. This document does not describe the
   use of these features.
   </del>

<add>
RDF users "upgrading" to OWL should consider whether they require OWL
Full. This decision mainly depends on how much they want to keep using
the metamodelling facilities of RDF Schema (i.e. defining classes of
classes). The price you have to pay for OWL FULL when compared to OWL
DL is that reasoning support is less predicatable. For more
information about this issue see the <ref>semantic document</ref>.
</add>

When we introduce constructs that are only permitted in OWL DL or OWL
Full, they are marked by "[OWL DL]" <add>resp. [OWL Full]</add>.


Design for Use

There are important issues regarding the distinction between a class
and an individual in OWL. A class is simply a name and collection of
properties that describe a set of individuals, and individuals are the
members of those sets. Thus classes should correspond to naturally
occurring sets of things in a domain of discourse, and individuals
should correspond to actual entities that can be grouped into these
classes.

In building ontologies, this distinction is frequently
<del>confused</del><add>blurred</add>
in two ways:

     * Levels of representation: It is well known that in certain
       contexts something that is obviously a class can itself be
       considered an instance of something else. For example, in the
       wine ontology we have the notion of a Grape, which is intended
       to denote the set of all species of
       grapes. CabernetSauvingonGrape is an example instance of this
       class, as it denotes the actual species of grapes called
       Cabernet Sauvignon. However, CabernetSauvignonGrape could itself
       be considered a class, the set of all actual Cabernet Sauvignon
       grapes.

     * Subclass vs. instance: It is very easy to confuse the
       instance-of relationship with the subclass relationship. For
       example, it may seem arbitrary to choose to make
       CabernetSauvignonGrape an individual that is an instance of
       Grape, as opposed to a subclass of Grape. This is not an
       arbitrary decision, however<del>, but solid engineering</del>.
       The Grape
       class denotes the set of all species of grapes, and therefore
       any subclass of Grape should denote a subset of these species.
       <add>
       This implies that CabernetSauvignonGrape should be considered an
       <b>instance of</b> Grape, and not a subclass (it does not
       describe a subset of Grape species, it IS a grape species).
       </add>

Note that the same distinction arises with the treatment of the Wine
class. The Wine class actually denotes the set of all varieties of
wine, not the set of actual bottles that someone may purchase. Each
instance of Wine could be considered the class consisting of all the
bottles of wine of that type. It is easy to imagine an information
system, such as an inventory system for a wine merchant, that needs to
consider individual bottles of wine.
<del>
The wine ontology as it currently exists would require the ability to
treat classes as instances in order to support such an interpretation.
</del>
<add>
Note that in OWL you can achieve this by using the expressivity of OWL
Full, which allows you to treat an instance of a wine variety to act
also as a class of wine bottles.
<todo>add example OWL code?!</todo>
As remarked before, the price you have to pay when using this feature
is that reasoning support is less predictable.
</add>

In a similar vein, the wines produced by wineries in specific years
are considered vintages. In order to represent the notion of a
vintage, we must determine where it fits in the current ontology. An
instance of the Wine class, as discussed above, represents a single
variety of wine produced by a single winery, for example
FormanChardonnay.  Adding that the wine produced in the year 2000 is
considered a vintage poses a challenge, because we don't have the
ability to represent a subset of a given wine individual. This vintage
is not a new variety of wine, it is a special subset of the wine -
that produced in the year 2000.
<del>
Unless we allow for representation of classes as instances, we are
forced to consider Vintage as a separate class whose instances have a
relationship to the Wine they are a vintage of.
</del>
<add>
One option is to use use OWL Full and treat the wine instances as
classes with subclasses (subsets) denoting vintages. Another option is
to use a workaround and to consider Vintage as a separate class whose
instances have a relationship to the Wine they are a vintage of.
</add>
For example, FormanChardonnay2000 is an individual Vintage with a
vintageOf property whose value is the Wine, FormanChardonnay. We
define the Vintage class below.
<add>
The latter option results in conceptually less clear model, but this
may be a price you are willing to pay to get the reasoning support
available for OWL DL.
</add>

<del>
These issues are certainly for the more advanced ontology builder, and
are not addressed in this document further.
</del>
The point of this discussion is to note that the development of an
ontology should be firmly driven by the intended usage. These issues
also underlie one major difference between OWL Full and OWL DL. OWL
Full allows the use of classes as instances and OWL DL does not. The
wine ontology is designed to work in OWL DL, and as a result
individuals like FormanChardonnay cannot simultaneously be treated as
classes.

-- 
A. Th. Schreiber, SWI, University of Amsterdam,
http://www.swi.psy.uva.nl/usr/Schreiber/home.html

Received on Thursday, 21 November 2002 06:18:17 UTC