My review paper presented the three changes from "Coordination points", together with my comments, as follows:
"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."
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. "
"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."
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?