Re: Where DAML+OIL deviates from the RDF-Schema spec.

Here are some remarks related to the range-constraint issue in defense
of RDFS. 

What can be found below?

In [Range] We argue that allowing multiple range constraints does not
extend the expressibility of RDFS significantly. Furthermore, it leads
to new problems with respect to an open world assumption.

In [Proposal] we present a simple (semantic) extension mechanism for
RDF/S which "adds" semantics to RDFS by interpreting it as embedded in a
suitably chosen (and interchangeable) host formalism. We demonstrate how
this can be used to express arbitrary set-algebraic range constraints
while maintaining the one-range-only constraint of RDFS.


Best regards,

     Wolfram Conen, Reinhold Klapsing


[Range] (From an RDF/S perspective)

In [0], Frank van Harmelen quotes 
> "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."

Given two classes C1, C2 and a property p. Wouldn't it be nice to be
able to express the full range of possible set-algebraic constraints -
(C1 u C2), (C1 n C2), C1 \ C2, C2 \ C1, (C1 \ C2) u (C2 \ C1)? [This is
even more interesting for n classes.]

If multiple range constraints with the interpretation "intersection"
would be allowed in RDFS, only constraints of the form C1 n C2 n C3 ...
are expressible. With an open world assumption, you would never know if
a constraint is violated (because you can neither express nor conclude
that an entity is NOT in the intersection -- it can be included
elsewhere -- remember that all you can say in RDFS is that one class is
a subclass of another, nothing about "disjointness" can be expressed
(with the exception of Literals vs. Resources, which is neglected here).
You can not even safely say that the range constraints is satisfied for
certain triples, because, with multiple range constraints allowed, you
can never be sure to know all range constraints, and, even worse,
discovering additional range constraints may render the decisions you've
made faulty (because the set of allowed objects shrinks!). Remark: If
only one range constraint is allowed, and you find another one, you
would at least know that the modeling is faulty, see the
range_cardinality_violation in [1].

So, it does not seem as if allowing multiple range constraints in RDFS
would solve a lot of problems. At least, one would have to
discuss if intersection is the only reasonable interpretation (see the
possible (and reasonable) set-algebraic constraints above). (Only if
class expression are available to "construct" classes, the
expressibility would not be unnecessarily restricted -- however, with
class expressions, multiple range constraints should be expressible with
one (complex) expression anyway, so again, only one constraint is
needed).

Why don't we create an RDF/S-conform device that allows to specify the
semantic that one wants to see from within RDF/S (with the additional
effect that the semantics are describable in RDFS itself)? This only
requires to embed RDF/S (resp. its interpretation) in a (selectable)
host formalism (see below).

[Proposal]

In [2] (based roughly on [3]), we demonstrate (with an example available
executably on-line with the RDF Schema Explorer), how such constraints
(and much else) can be expressed in RDF/S without violating any
constraint of the spec. The approach is based on the assumption that "to
give RDFS semantics" could most easily be done by (axiomatically)
interpreting RDFS within a host formalism (that can be exchanged, if a
paradigm mismatch is looming). This has a number of advantages (IOHO):

- It relies on only one predicate (isDefinedAs) and a transformation
rule (transforming the RDF primitive "triple" into a corresponding
primitive in the host formalism), thus very little build-in semantics is
required (the rest will be described in the RDF (meta-) schemata and
thus, can be "described" by RDF, making room for nice abstractions on
the semantics themselves).  

- The interpretation is readily "executable" (in our case of a
Prolog/FOL-type interpretation). 

- each application domain can provide its own set of (meta-) schema with
nicely and accessibly specified semantics to be meaningful in a suitably
chosen host formalism. This enable an evolutionary approach to design a
semantically-meaningful "little language" for each domain (instead of
being forced to use the semantics of a paradigm-related language), thus,
it gives the freedom to search for a close fit of semantic constructs
and observed requirements. Nevertheless, it is still possible to use
other schemata (an RDFS-FOL-Axiomatization-Schema or an
OIL-KIF-Axiomatization-Schema - both would be easy to create from
available axiomatizations, compare [1] resp. [4]), and to do so happily
(because the semantics are given explicitly).

- The "semantics of RDF" could be expressed and discussed with respect
to a certain (axiomatic) interpretation in a formalism. (So, what could
be standardized is the transformation from XML-Syntax to the RDF triple
model (see Brian's email [5] on transformation grammars for a start),
the model should be specified completely clear, and basic
mappings/axiomatizations for (some) host formalisms should be given)

- and some more ...


[0] http://lists.w3.org/Archives/Public/www-rdf-logic/2001Feb/0106.html

[1]
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Aug/0122.html

[2]
http://nestroy.wi-inf.uni-essen.de/rdf/embedding_rdf_in_a_hostformalism.pdf

[3]
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Oct/0003.html

[4] http://lists.w3.org/Archives/Public/www-rdf-logic/2000Nov/0045.html

[5]
http://lists.w3.org/Archives/Public/www-rdf-interest/2001Feb/0223.html

Received on Monday, 5 March 2001 13:06:33 UTC