- From: Dan Connolly <connolly@w3.org>
- Date: 22 Nov 2002 11:33:27 -0600
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: RDF Core <w3c-rdfcore-wg@w3.org>
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