Re: Cyclic Classes/Properties [was: Re: DAML Correction: Same Is Not A Sub Of Sub]

[...]
> > An additional problem is that if you let class hierarchies by
> > cyclic, then you might start getting inconsistencies quite easily
>
> The last time this came up (late Feb/early March), a lot of heat
> was generated.  The DAML+OIL approach is that a cycle in a
> class hierarchy defines a set of equivalent classes --- so if A is a
> subclass of B, B is a subclass of C, and C is a subclass of A,
> then A, B, and C are equivalent.

Cyclic classes worry me slightly simply because I don't think you have
to enable them in order to state that two classes are equivalent.
Surely a subClass is defined as:-

   [ ( m + M ) M ]

Where "something that is an M but not an m" may or may not exist? If
it doesn't exist, then the two classes are equivalent, i.e. there are
no members of either class which cannot belong to one another, and the
only property you need to declare that is daml:equivalentTo. This is
coming from a non-logician, but I don't see why unecessary levels of
expression should be added to such a basic level of RDF structuring,
when the devices for declaing equivalence are already there. In other
words, if someone can come up with an practical real world example of
why cyclic classes should be introduced over equivalence (or why
cyclicity is required for equivalence... in Notation3!), then I would
be very glad to hear it.

OTOH, if it's just an theoretical thing, then I don't see the point.
I'm looking to implement these on a practical basis, for EARL, for
SWAG, and so on, and I'd like to at least be able to use some DAML
terms. I don't think it's a strong foundation for the Semantic Web if
some of the core schemas and ontologies have whacking great schema
inconsistencies in them.

> > Unfortunately, all instances of rdf:Property and
> > daml:CyclicProperty would have to be daml:Disjoint...
>
> Also known as 'if I don't look at it, maybe it'll go away' :-).
> [...] Yes, it would be possible to define a whole new structure
> on top of triples that completely ignores RDFS; but I don't
> think that helps.

Agreed; I was just fudging it... although it must be accepted that
cyclic and non-cyclic properties and classes are disjoint. If the REC
version of RDFS uses a different namespace (which it should if
anything changes), then the classes and properties declared therein
will be daml:disjointWith classes/properties from the current RDFS
version.

[...]
> What would break in RDFS if the wording "A property can
> never be declared to be a subproperty of itself, nor of any of
> its own subproperties" were removed?

Well, I still believe that you'd have to have some way of restricting
whether a certain class could have sub classes also be super classes,
but on the whole very little, because I don't think there are all that
many serious applications of RDFS. It's only a CR, so it can be
changed.

Having said that, one thing that would break is my little RDFS
validator [1] (which I'm extending to do some DAML), which contains
the rule:-

   { :x15 rdfs:subClassof :y15 . :y15 rdfs:subClassOf :x15 }
   log:implies
   { :x15 :schemaInconsistency """x cannot be a subClass of y when
   y is a subClass of x""" } .

Although it wouldn't be all that difficult to remove, or change the
wording to "is being used as a cyclic class". Whatever, with namespace
changes I'd have to mess about with it anyway [2].

[1] http://infomesh.net/2001/rdfsvalid/
[2] Side note, shouldn't it be possible to define a set of rules to
convert from the current version of RDF Schema to future versions?
That's one of the core aims of the Semantic Web in general.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Sunday, 6 May 2001 10:40:35 UTC