W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2003

Re: Action needed: subClassOf on datatypes

From: Dan Connolly <connolly@w3.org>
Date: Tue, 02 Sep 2003 07:57:50 -0500
To: pat hayes <phayes@ihmc.us>
Cc: w3c-rdfcore-wg@w3.org, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Message-Id: <1062507470.1062.93.camel@dirk.dm93.org>

On Mon, 2003-09-01 at 22:08, pat hayes wrote:
> Guys, this is to point out a recently identified buglet in the 
> datatype semantics and to outline  alternative ways to deal with it. 
> Mia culpa for not catching this earlier, but we need to fix it 
> somehow.
> Recall that we weakened the conditions on rdfs:subClassOf a while 
> back, so that being a subset was a necessary but not sufficient 
> condition for being a subClass. This means that the inference rule 
> rdfD4  is not valid, since even ddd's value space is a subset of 
> eee's value space and they are both datatypes, it still doesn't 
> necessarily *follow* that one is an rdfs:subClassOf the other.
> This means in turn that the text case we discussed 2 weeks ago which says that
> xsd:integer rdfs:SubClassOf xsd:number .
> is XSD-entailed by the empty graph, is wrong. In fact, the only 
> subclass assertions which follow from the empty graph are those of 
> the form
> aaa rdfs:subClassOf aaa .
> aaa rdfs:subClassOf rdf:Resource .
> even in D-interpretations.

even in D-interpretations? If you know the datatypes,
you know the relevant subclass relationships, no?

(hunting for pointer to current draft to comment more
intelligently... found 5 September 2003??? draft
from the WG homepage

Hmm... as written, it says a datatype can only constrain
interpretations in the lexical-to-value mapping. I never
thought of it that way. I would have thought a datatype,
like any other semantic extension, could constrain
things just about any way: introduce arbitrary triples,
maybe even rules. (do we mention that datatypes
are semantics extensions? we should.)

> ----
> I can think of four ways to fix this.
> (a) modify the test case doc by deleting the test case;
> (b) modify the test case to say that this only follows under the 
> strengthened extensional semantic conditions on rdfs:subClassOf 
> described in section 4.1 of the semantics document;
> (c) modify  the test case to say that the case is D-consistent with 
> the empty graph, not that it is D-entailed by it;
> (d) modify the semantics of D-interpretations to insist that datatype 
> class subsetting *is* treated extensionally, so that the rule rdfD4 
> is valid and the test case is OK. This can be done by adding the 
> following semantic condition on D-interpretations:
> if <aaa, x> and <bbb, y> are in D and the value space of x is a 
> subset of the value space of y, then <x,y> is in 
> IEXT(I(rdfs:subClassOf))

(e) note that semantics of datatypes includes subClassOf

> I would vote against (b), and think that (c) is wimpy; I think (a) 
> (or (c) ) is the best solution, but would be willing to go with (d) 
> if the WG feels that we *ought* to impose extensional conditions on 
> datatype classes.  In rule terms, do y'all think that rdfD4 *ought* 
> to be a valid rule (ie to be undeniably true under all 
> circumstances), or would it be better to allow people to make, but 
> also be free to not make, subClassOf assertions about 'external' 
> datatypes?

Er... that's (e), right? i.e. none of a-d.

I suppose (d) is acceptable to me, but I prefer (e).

>  I like that latter approach, myself, because it is more in 
> line with the intensional approach we have adopted generally, and it 
> neatly sidesteps issues involving identity versus equality and other 
> wierd stuff that seem to arise in XSD discussions. On the other hand, 
> it means work for some other editors, rather than for me.
> I have versions of the semantics document ready for both alternatives 
> (a or c) and (d).
> Pat
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Tuesday, 2 September 2003 08:57:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:07 UTC