W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2001


From: Manos Batsis <m.batsis@bsnet.gr>
Date: Fri, 26 Oct 2001 15:38:29 +0300
Message-ID: <A35E2040C17F0C48B941B8F4D0DF122908E386@ermhs.Athens.BrokerSystems.gr>
To: "Peter Crowther" <peter.crowther@networkinference.com>
Cc: <www-rdf-interest@w3.org>

> -----Original Message-----
> From: Peter Crowther [mailto:peter.crowther@networkinference.com] 

> > From: Vassilis Christophides [mailto:christop@ics.forth.gr]
> > 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?

By another property (that shows the equivalence relationship) used it in
the property definition ;-)

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

Neither do I.

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

Well... Nothing is absolute. One may have different requirements about
the graph than someone else. For example, one may want to actually merge
all equivalents and I am sure that using another property to declare
equivalence is a lot faster to do that.
I think that cycles (as mentioned in this thread) will be used as
special constructs. For example, one may show a series of  properties
that have different levels of similarity or a set of recourses that form
an integral set (properties, classes, whatever you may call them) that
cannot be so easily and well defined using the traditional
class/subclass relationships.

Kindest regards,

Received on Friday, 26 October 2001 08:36:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:38 UTC