Re: Action needed: subClassOf on datatypes

>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
>   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/
>from the WG homepage
>   http://www.w3.org/2001/sw/RDFCore/)
>
>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.)

If you think of a datatype as defining a semantic extension of its 
own, then yes, it can do that or indeed a whole lot of other stuff, 
as you note. But the issue here is whether the basic RDF datatyping 
rules for *all* datatypes should require that datatyping subClassOf 
is to be understood extensionally, as a particular datatyped-RDFS 
condition on datatype classes in general. I would rather not do this, 
partly on aesthetic grounds, but chiefly because it kind of forces 
RDFS datatyping to get involved with these genuinely difficult issues 
of whether things of one type are the same as things of another type, 
and so on. Whereas if we let RDFS be intensional in its approach to 
datatype subclassing, we can allow users to make their own assertions 
about datatype relationships according to their own understanding. 
This allows someone who just wants to conform to our spec to keep out 
of the tar-pit.

>
>>  ----
>>
>>  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
>relationships.

I think that is just (d) said a different way.  (?? Or do you mean, 
that each datatype class would include subClassOf relationships? So 
that part of the XSD package would be some subClassOf assertions? If 
so, then yes, that is  OK; but then we would still have to modify the 
test case since the subClassOf wouldn't be *valid*. )

>
>>
>>  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.

Actually that is (a) or maybe (c). I'll take it as a vote for (a) :-)

Pat
-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 3 September 2003 02:29:26 UTC