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.

> 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?

> 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.

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.

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.

		- Peter

Received on Friday, 26 October 2001 07:59:08 UTC