W3C home > Mailing lists > Public > www-rdf-interest@w3.org > July 2003

RE: rdfs:resource

From: Jon Hanna <jon@spin.ie>
Date: Fri, 25 Jul 2003 13:02:24 +0100
To: <www-rdf-interest@w3.org>

> > <cims:qualifierFlavor> <rdfs:subProperty> <cims:NamedElement> .
> > Only follows if <cims:NamedElement> is a property.
> >
> The <cims:qualifierFlavor> is a property applied in the context
> of another
> property (<cims:qualifier>), i.e. is a property of a property. Both, as
> all CIM elements, are rooted at the NamedElement.

They are both rooted at NamedElement in different ways than to
<rdfs:Property> though.

<cims:qualifierFlavor> <rdf:type> <cims:NamedElement> . says that
<cims:qualifierFlavor> is a NamedElement, and as such anything that is true
of all NamedElements is true of qualifierFlavor, qualifierFlavor can be used
where any NamedElement could be used, and so on. This is I think the
relationship you want between <cims:qualifierFlavor> and

<cims:qualifierFlavor> <rdfs:subProperty> <cims:NamedElement> .
Entails that both <cims:qualifierFlavor> and <cims:NamedElement> are
properties, and as such it is possible to say <A> <cims:NamedElement> <B>.
Unless you can say
1. that one resource is the NamedElement of another
2. that one resource being the qualiferFlavor of another implies that it is
also the NamedElement of that other

then this is not the relationship you want between <cims:qualifierFlavor>
and <cims:NamedElement>

> > which is a  <cims:Schema> is also a <cims:NamedElement> it does not
> > follow that <cims:Schema> itself is a <cims:NamedElement>.
> Hmm, but it should. Ok, lets see if it is only a matter of language
> (semantics...). All members of <cims:Schema> are members of the
> <cims:NamedElement>, as all members of <cims:qualifier> should be of the
> <cims:NamedElement>.
> If the <rdfs:Resource> is the superclass of everything, all other classes
> are subclasses of this one, namely the  <rdf:Property> and <rdfs:Class>
> classes. No?

It's worth noting that while <rdfs:Class> <rdfs:subClassOf> <rdfs:Resource>
<rdfs:Resource> <rdf:type> <rdfs:Class> .

That is, Class is a subClass of Resource, but Resource is a type of Class.

It is the difference between these two types of relationship that are coming
into play here.

Taking a less abstract concept than "NamedElement" Cod is a sub-class of
Fish, and hence anything that is a Cod is also a Fish, so we have a
subClassOf relationship. It does not follow however that the concept of
"Cod" is a itself a fish, and indeed it isn't.

Hence saying that Schema is a subClassOf NamedElement does not suffice to
say that Schema is itself a NamedElement. We need to either explicitly state
that, or else constrain NamedElement in such a way that its subClasses are
all also NamedElements (Possible with OWL, can't think of a way to do it in

> > I think what you want to indicate how your ontology works is:
> >
> > <cims:qualifierFlavor> <rdf:type> <cims:NamedElement> .
> > <cims:Schema> <rdf:type> <cims:NamedElement> .
> > <cims:Schema> <rdfs:subClassOf> <cims:NamedElement> .
> But then it is not stated that the <cims:qualifierFlavor> is a property,
> it has domain and range (this is important to my description). (it seems
> like the previous thread about which came first, the resource or the
> class...)

You began your original mail with:


cims:NamedElement rdf:type rdfs:Resource
cims:qualifierFlavor rdf:type rdf:Property
cims:Schema rdf:type rdfs:Class"

I continued that assumption in my reply, hence it is already stated that
<cims:qualifierFlavor> is a property.

It might be worth considering whether the fact that all objects in your
"native" ontology are instances of NamedElement is something that is still
of value when expressed in RDF. I couldn't say without seriously examining
how the entire ontology works, and you may have already considered and
dismissed the idea, but it might be worth thinking about.

Then again I have a strong bias against single-root hierarchies in OO that I
know isn't universal.
Received on Friday, 25 July 2003 07:59:33 UTC

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