# Re: RDF MT: rdfs interpretations of subClassOf and subPropertyOf

From: Jeen Broekstra <jeen.broekstra@aidministrator.nl>
Date: Fri, 22 Nov 2002 13:31:37 +0100
Message-ID: <3DDE23A9.4030306@aidministrator.nl>
To: pat hayes <phayes@ai.uwf.edu>
```
pat hayes wrote:
>
>> This came up during a discussion on www-rdf-interest, and while I
>> am not quite sure I read the logic right, it seems there is an
>> oddness in the interpretation rules for subClassOf and
>> subPropertyOf in the new draft of the RDF MT, which I would like
>> clarified.
>>
>> From Section 3.3:
>>
>> <x,y> is in IEXT(I(rdfs:subClassOf)) if and only if x and y are in
>> IC and ICEXT(x) is a subset of ICEXT(y)
>>
>> Now suppose we have an RDF model which contains a single triple
>> definining a class:
>>
>> <_:MyClass> <rdf:type> <rdfs:Class>
>>
>> Would not the above condition imply that from this triple we can
>> deduce:
>>
>> <_:MyClass> <rdfs:subClassOf> <rdfs:Class>
>>
>> (since MyClass and rdfs:Class are both in IC and ICEXT(MyClass) is
>> the empty set).
>
>
> How do you know that ICEXT(I(MyClass)) is empty? It could be
> anything, given only what you have said in the first triple.

You're right of course, thanks for clearing that up. It leaves me with
another question though: how do we ever determine whether the extension
of any class is a subset of another - apart from explicitly stating that
it is by adding a subClassOf statement?

Put another way: what is the value of having the IFF condition if there
is no way to determine the truth of the right hand side of the equation?

If it is simply for the purpose of having a more elegant model, I'll
just shut up about it and be happy that it doesn't really affect the
semantics, i.e. no new triples are suddenly being derived :)

Jeen
--
jeen.broekstra@aidministrator.nl
aidministrator nederland bv - http://www.aidministrator.nl/
julianaplein 14b, 3817 cs amersfoort, the netherlands
tel. +31-(0)33-4659987, fax. +31-(0)33-4659987
```
Received on Friday, 22 November 2002 07:32:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:19 UTC