RE: abstract class

>   The thing is we would like to say that we cannot
> have
>      <ns:C rdf:ID="foo"/>
>   without having
>      <ns:A rdf:ID="foo"/>
>   or
>      <ns:B rdf:ID="foo"/>
>   or any other subclass of C.
>
>   so we couldn't have a resource that is only of type
> C.
>   In other words, we would like to define C as
> abstract.

I don't really think that makes much sense.

To say "If it is of type C then it is either of type A or type B". Makes
sense, and is possible:

<owl:Class rdf:ID="C">
	<owl:unionOf rdf:parseType="Collection">
		<owl:Class rdf:about="#A"/>
		<owl:Class rdf:about="#B"/>
	</owl:unionOf>
</owl:Class>

You can also use DAML+OIL, for which there might be more current support.

However to add "or any other subclass of C" seems to me to be a given in any
case. For any given categorisation of anything one can almost always come up
with a more finely grained ontology. Often this more finely grained ontology
is only of interest to someone or something with more specialised knowledge.
We enable interoperability by enabling people to work at the degree of
specialisation that is suitable for them. Hence for every rdf:type statement
that could be made there is the theoretical possibility of a rdf:type
statement that uses a subclass.

When you code the RDF/XML <ns:C rdf:ID="foo"/> it is not comparable to "foo
= new C" in C++, Java or whatever. Where the latter *creates* an object the
former merely provides information about a resource. The concept of
"abstract" exists in C++ and Java to prevent one creating an object where
that is undesirable (and generally meaningless). Since resources are created
in RDF statements about them there is no need for abstract classes (or
conversely, you could say that *all* RDF classes are abstract).

Received on Thursday, 23 January 2003 12:01:49 UTC