Re: CYCLES IN CLASS/PROPERTY HIERARCHIES

>> From: Vassilis Christophides [mailto:christop@ics.forth.gr]
>> One aim of RDF is always to give the user of RDF as much freedom as
>> possible. But if these cycle declarations are spread over different
>> namespaces (schemas) it will easily will get quite messy. ... and the
>> question always arises if the additional namespace I need to load to
>> validate my previous file is really trustful.
>
>That's true for any feature of RDF; it's undoubtedly possible to craft a RDF
>fragment that poisons another RDF fragment.  I would expect this to be true
>whether or not cycles are allowed.
>

I don't agree. We have succeed to validate RDF fragments (schemas and
data) from different namespaces w.r.t. the current RDF semantics
(i.e. no cycles). Here I am talking about the RDF graph semantics and
not the semantics users give to these graphs.

>> Also for properties a cycle would mean that we have different names
>> for properties expressing the same.  But for properties cycles even
>> make less sense.
>
>Not at all.  How else do you express the equivalence of two properties?
>

Between us: Equivalence means to give different names for the same
thinks. The issue here is whether or not these thinks are simple labels
or more complicated constructs like class and property definitions.

>> When we allow cycles it should at least be constraint
>> that the properties have equal domain/range definitions.
>
>Why?  If they don't, it is simply the case that any graph that contains
>those properties is not valid.  This isn't a bug; it merely shows that the
>graph shouldn't include those properties.
>

Again I don't agree. Equivalence should be propagated to other
affected constructs: from class to properties and from properties to
classes. Otherwise, the created descriptions are not anymore consistent. 

>Also, what do you do where the range of one is a superclass of the range of
>the other, or where the ranges intersect?  I see no particular reason to
>disallow these cases.
>
>I guess I'm coming at this from the description logic point of view, so I'm
>used to using cycles to define equivalence.  Certainly logics such as SHF,
>SHIQ and DAML have valid model theories that include cycles in concept and
>role hierarchies, so the theory appears to be worked out.

Yes I am aware of DL theories. Essentially, they rely on derived
concepts (e.g., the intersection concept of the two domain/range
classes). Derived concepts ARE defined in DAML-OIL and NOT in
RDF/S. In addition, I am wondering about the utility of this kind of
reasoning support for all applications. Consider the following example

We have two disjoin classes: MALE and FEMALE and I want to use a name
property on both classes. Since the intersection MALE and FEMALE is
empty we can't anymore express in the fact that both Males and Females
resources have a name property. Did you consider this as a reasonable
RDF feature. 

>There was a long discussion a few months ago about alternative ways to
>define equivalence, and IIRC the conclusion was that cycles were (a) the
>cleanest of the options and (b) the only option that will work on the
>Semantic Web, where arbitrary fragments of RDF may be merged into a larger
>graph.

I personally believe that RDF/S should not provide any other inference
mechanism than transitivity of subclasses/subproperties. If for adding
equivalence we need to complicate or even confuse the semantics of
RDF, I am wondering how we can anymore claim that RDF is the basic
format/syntax for the Semantic Web!!!

>
>		- Peter
>

Vassilis

Received on Friday, 26 October 2001 09:10:33 UTC