Re: datatype test case (value spaces, rdfs:subClassOf)

On Fri, 2002-11-22 at 10:48, Brian McBride wrote:
> 
> Does the empty graph datatype(xsd:integer, xsd:decimal) entail
> 
> xsd:integer rdfs:subClassOf xsd:decimal .

yes.

Justification:

Step 1:

"The final condition indicates that RDF uses a datatype uriref in two
ways: as a name for the datatype itself, and (when used as a class name)
to indicate the class containing the elements of the value space of the
datatype."

 -- http://www.w3.org/TR/rdf-mt/#dtype_interp

So the class extension of xsd:decimal, ICEXT(I(xsd:decimal))
is its value space, and likewise for xsd:integer.

Step 2:

"integer is ·derived· from decimal by fixing the value of
·fractionDigits· to be 0. "
  -- http://www.w3.org/TR/xmlschema-2/#integer

"[Definition:]  A datatype is said to be ·derived· by restriction from
another datatype when values for zero or more ·constraining facet·s are
specified that serve to constrain its ·value space· and/or its ·lexical
space· to a subset of those of its ·base type·. "
 -- http://www.w3.org/TR/xmlschema-2/#dt-basetype

So the value space of integer is a subset of the value
space of decimal. i.e. ICEXT(I(xsd:integer)) is
a subset of ICEXT(I(xsd:decimal)).


Step 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)"
 - http://www.w3.org/TR/rdf-mt/#rdfs_interp

So <I(xsd:integer), I(xsd:decimal)> is in IEXT(I(rdfs:subClassOf));
written in n-triples-plus-qnames, that's

  xsd:integer rdfs:subClassOf xsd:decimal .

Q.E.D.


Some related conjectures come to mind:

  xsd:float rdfs:subClassOf xsd:double.

That is *not* datatype(xsd:float, xsd:double) entailed
by the empty graph; the value space of float is *not*
specified to be a subset of the value space of double.
So there's no justification ala step 2 above.

For details, see
		Floating-point datatypes are not real datatypes
			Mark Reinhold <mr@eng.sun.com>
				5 October 1999
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000JanMar/0130.html


Another:

  xsd:integer rdfs:subClassOf xsd:float.

Likewise, no justification ala step 2.

  xsd:hexBinary rdfs:subClassOf xsd:base64Binary.

That one *is* datatype(xsd:hexBinary, xsd:base64Binary)
entailed by the empty graph; the justification
ala step 2 is:

"The ·value space· of hexBinary is the set of finite-length sequences of
binary octets. "
-- http://www.w3.org/TR/xmlschema-2/#hexBinary

"The ·value space· of base64Binary is the set of finite-length sequences
of binary octets."
-- http://www.w3.org/TR/xmlschema-2/#base64Binary

i.e. we don't appeal to any subtype relationship, but
we observe that they are specified to have the same
value space. One might have quibbled whether
"finite-length sequences of binary octets" in one
part of the spec refers to the same set as "finite-length
sequences of binary octets" from another part of the spec.
While yes, at the end of the day, this is a matter
of mathematical philosophy, it's clear enough to me,
since it says "*THE SET* of finite-length sequences of binary
octets" in both cases. Anyone who feels there
is any lack of clarity should follow the advice
in the model theory spec, "questions of identity between items in value
spaces of two different datatypes should be referred to the authorities
who defined the datatypes" but I find the situation
abundantly clear.





-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 22 November 2002 12:33:31 UTC