DAML+OIL Required Changes to RDF(S)

DRAFT

Frank Manola
26 July 2001

Introduction

Coordination points between RDF(S) and DAML+OIL identified three changes that the DAML+OIL community  felt were required in RDF(S).  In my review paper, I reviewed those proposed changes, noting that there had not yet been any discussion of these issues.  The purpose of this paper is to initiate that discussion, present  some of the background material, and briefly review some of the discussion that had taken place on these issues in the www-rdf-logic mailing list.  It seems to me that a strong case exists for making these changes.

My review paper presented the three changes from "Coordination points", together with my comments, as follows:

What changes does DAML+OIL require

As indicated in the DAML+OIL reference document and as summarised in a message to the www-rdf-logic mailing list, DAML+OIL takes exception to the intended/inferred semantics of RDF Schema in three places:


Background

The following material is provided to provide further background for discussing these issues.

Domains

The DAML+OIL reference document defines a property element as containing:

     "zero or more rdfs:domain elements (each containing a class expression).
     Each domain element asserts that the property P only applies to instances of the class expression of the element. More formally: if a pair (x,y) is an
     instance of P, then x is an instance of the class expression. This implies that multiple domain expressions restrict the domain of P to the intersection of the
     class expressions.
     Warning: This is contrary to the semantics of the domain element in the RDF Schema specification, which we believe to be flawed. Note that unlike any
     of the property restrictions mentioned above, these domain restrictions are global. The property restrictions above are part of a class element, and are
     only enforced on the property when applied to that class. In contrast, domain restrictions apply to the property irrespective of the Class to which it is
     applied. This is by virtue of their semantics in RDF Schema;
     Because of this, domain elements should be used with great care in DAML+OIL.

The RDF Schema spec says

    "A property may have zero, one, or more than one class as its domain. If there is no domain property, it may be used with any resource. If there is
    exactly one domain property, it may only be used on instances of that class (which is the value of the domain property). If there is more than one
    domain property, the constrained property can be used with instances of any of the classes (that are values of those domain properties). "

It goes on to say:

    "Note: This specification does not constraint the number of rdfs:domain properties that a property may have. If there is no
      domain property, we know nothing about the classes with which the property is used. If there is more than one rdfs:domain
      property, the constrained property can be used with resources that are members of any of the indicated classes. Note that unlike
      range this is a very weak constraint."

Ranges

The DAML+OIL reference document defines a property element as containing:

     zero or more rdfs:range elements (each containing a class expression).
     Each range element asserts that the property P only assumes values that are instances of the class expression of the element. More formally: a pair (x,y)
     can only be an instance of P if y is an instance of the class expression.
     Warning: Although the RDF Schema specification only allows one range restriction for each property, it seems quite natural to allow multiple range
     restrictions. These would then again be interpreted as saying that the range of P must be the intersection of all the class expressions. Furthermore, as
     with domain restrictions, range restrictions are global, by virtue of RDF Schema;
     Because of this, range elements should be used with great care in DAML+OIL."

The RDF Schema spec says:

    "A property can have at most one range property. It is possible for it to have no range, in which case the class of the property value is
      unconstrained. "

It goes on to say:

     "Although it is not permitted to express two or more range constraints on a property, a similar outcome can be achieved by
       defining a common superclass for any classes that represent appropriate values for some property. For example, to express the
       constraint that a property xyz:drivesMotorVehicle can have values which are Vans, Trucks or PassengerVehicles, we
       assert that xyz:drivesMotorVehicle has a rdfs:range of MotorVehicle. If Van, Truck and
       PassengerVehicle are known to be subclasses of MotorVehicle, then all these types of resource are acceptable values
       for xyz:drivesMotorVehicle. In cases where a common superclass does not exist, one can be defined in a schema in the
       normal manner. "

Classes

The DAML+OIL reference document defines a class element as containing:

     "zero or more rdfs:subClassOf elements (each containing a class-expression).
     Each subClassOf element asserts that C is a subclass of the class-expression mentioned in the element. (Each class-expression defines a (possibly
     anonymous) class).
     Warning: The RDF Schema specification demands that the subclass-relation between classes must be acyclic. We believe this to be too restrictive, since
     a cycle of subclass relationships provides a useful way to assert equality between classes. Consequently, DAML+OIL (March 2001) places no such
     restriction on the subClassOf relationship between classes;"

The RDF Schema spec says:

   "A class can never be declared to be a subclass of itself, nor of any of its own subclasses. Note that this constraint is not expressible
     using the RDF Schema constraint facilities provided below, and so does not appear in the RDF version of this specification given in
     Appendix A."

and

   "A class can never be declared to be a subclass of itself, nor of any of its own subclasses. Note that this constraint is not expressible
     using the RDF Schema constraint facilities provided below, and so does not appear in the RDF version of this specification given in
    Appendix A."


Discussion

These issues have been (in some cases extensively) discussed on the www-rdf-logic email list.  The following are some pertinent extracts and references:
 

Range and Domain

In http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0004.html Tim Berners-Lee  says that he hopes "the new RDFcore group regards these as bug fixes."  [The "these" also includes the class hierarchy issue.]

Classes

In http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0016.html , Deborah Mcguinness makes some observations based on experience with a number of Web taxonomies, and other ontologies, and concludes:
> Thus, I support the notion particularly for widely used ontologies that:
> 1 - cycles occur in practice
> 2 - sometimes (rarely in my subjective view) people really want to keep the cycles
> 3 - a kb should not be considered broken because it includes a cycle
> 4- tools should be provided that warn users of cycles and suggest repair strategies if
> possible

In http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0015.html  (which contains a whole series of quoted messages on the subject of both subtype loops and the range and domain issue), Ian Horrocks makes the point that:

> ... we don't want/need to use subClassOf cycles to assert
> equality. However, we have to decide what to do with such cycles when
> they are detected - it is no use just saying that they are "forbidden",
> because by the standard argument they will occur out there on the
> web. The choices are either:
>
> a. barf - declare the ontology to be illegal/broken
>
> b. accept the facts as presented and draw the appropriate conclusions
> (and possibly issue some kind of warning as to the consequences).
>
> I much prefer b. Here are just a few reasons:
>
> 1. There is no semantic justification for declaring such an ontology
> to be broken - we are just guessing that it contains one or more
> errors. This seems to be setting a very dangerous precedent - we could
> declare many other DAML+OIL constructions illegal on the grounds that
> they are often used in error.
>
> 2. It is not, in general, possible to "fix" cyclical ontologies
> automatically as there is no way to know where the cycle should be
> broken. So it is hard to do anything sensible when a cycle is detected
> other than to just reject the ontology.
>
> 3. Given that we have to detect cycles anyway, surely it is much
> better to deal with them and simply warn users that a two or more
> classes have collapsed into a single class.
>
> 4. In DAML+OIL we can easily create ontologies with cycles that
> include implicit subClassOf relations that cannot be detected
> syntactically. Are these kinds of ontology also illegal?

In http://lists.w3.org/Archives/Public/www-rdf-logic/2001May/0025.html, Pat Hayes notes that

> The issue is rather how to understand 'subclass' ; is this
> like < or like =< ? Is a class considered to be a subclass of itself?
> RDFS seems to assume not (ie it understands 'subclass' to be strict
> subclass), but DAML says yes. The two notions of 'subclass' can
> coexist without interference. To assert RDFS:subclass is a stronger
> assertion than asserting DAML:subclass but it is not inconsistent
> with it, in much the same way that asserting 2<=3 is not inconsistent
> with the fact that 2<3. (Notice there is no need to make a
> distinction between integers and cyclic integers.)
 

In http://lists.w3.org/Archives/Public/www-rdf-logic/2001Mar/0020.html Tim Berners-Lee notes that

> DAML is in my opinion right.  If a is a subclass of b and b of a
> mean that a and b are equivalent classes - this is not a bug.  You can't go
> peperring the
> underlying logical framework with exceptions just because in some cases
> a loop is formed by mistake.

and

> I don't know how you would make *local* rules to enforce the macroscopic
> acyclic property - which is what you have to do in a scalable system. The
> obvious
> way is to insist that the Property not be used for equivalent classes, that
> it be proper subclass.
> To have a proper subclass relation as the only standard tool would be very
> difficult - to have
> not only to establish that every member of a was a member of b but also that
> there was some member of b not a member of a?



$Revision 1.0 $ of $Date: 2001/07/26 21:45:17 $