- From: Peter Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 12 Jun 2013 10:28:12 -0700
- To: RDF WG <public-rdf-wg@w3.org>
I think that there is indeed something that is not correctly nailed down in Semantics. Semantics says that datatype IRIs must identify datatypes, but it does not say that the datatype IRI must the denote the datatype that it identifies. This should be added to definition of D-interpretations. If that is the problem with D-interprtations that Antoine refers to, then I think that the change above addresses his comment. However, if Antoine is commenting more generally about the change away from datatype maps, here is my description of the changes between the 2004 semantics and the semantics in the current editors' draft. In the 2004 Semantics the semantics of datatypes are given via datatype maps, which contain pairs consisting of a URI and a datatype which is, in turn, a triple consisting of the lexical space, the value space, and the L2V mapping. In the current editor's draft of RDF 1.1 Semantics the semantics of datatypes are given via a set of IRIs that must each identify a datatype. With my change above in a D-interpretation a datatype IRI must denote its datatype. (Without the change a datatype IRI must denote something with an L2V mapping and a value space.) It may appear that something is lost here. Given a only set of IRIs identifying datatypes, where are the actual datatypes? There are two answers here: 1/ Before you can say that the IRIs identify datatypes you have to have a datatype in question, so everything works out correctly. 2/ It doesn't really matter. The actual workings of a datatype are external to the formal machinery of RDF, so there is necessarily some magic so there is no way to be as precise as is really required. This is true even for the 2004 version. Although there is the formal statement of a dataype map, there is no formal RDF machinery for specifying the internal workings of a dataype. Instead one would say that a datatype map contains xsd:integer and maps xsd:integer to the XSD integer datatype. The only change is that there now is no formal datatype map, so that one can't say that D is a datatype map and just use D thereafter in a document. Instead one says that D is a set of datatype IRIs and that they identify particular datatypes and just use D thereafter in a document. So suppose that I want to create a particular system that handles four datatypes - HTML literals as defined in RDF concepts, integers as defined by XSD, real numbers as defined by the OWL WG, and complex numbers as defined by me. Under the 2004 way I would proceed by creating a datatype map, F = {<rdf:HTML,A>,<xsd:integer,B>,<owl:real,C>,<pfps:complex,D>}, where A is the HTML datatype as defined in RDF 1.1 Concepts at http://www.w3.org/TR/owl2-syntax/#Real_Numbers.2C_Decimal_Numbers.2C_and_Integers, B is the integer datatype as defined in XS Datatypes at http://www.w3.org/TR/xmlschema11-2/#integer, C is the real datatype as defined in OWL 2 at http://www.w3.org/TR/owl2-syntax/#Real_Numbers.2C_Decimal_Numbers.2C_and_Integers, D is the datatype whose value space is pairs of real numbers .... Thereafter I just F, perhaps also pointing back where F is specified. Under the current way I would proceed by saying that F = {rdf:HTML,xsd:integer,owl:real,pfps:complex} where rdf:HTML identifies the HTML datatype as defined in RDF 1.1 Concepts at http://www.w3.org/TR/owl2-syntax/#Real_Numbers.2C_Decimal_Numbers.2C_and_Integers, xsd:integer identifies the integer datatype as defined in XS Datatypes at http://www.w3.org/TR/xmlschema11-2/#integer, owl:real identifies the real datatype as defined in OWL 2 at http://www.w3.org/TR/owl2-syntax/#Real_Numbers.2C_Decimal_Numbers.2C_and_Integers, pfps:complex identifies the datatype whose value space is pairs of real numbers .... Thereafter I just use F, perhaps also pointing back to F is specified. Actually, under the current way I don't need to say what the interpretation of rdf:HTML or xsd:integer is because these interpretation are fixed by RDF 1.1 Concepts. peter
Received on Wednesday, 12 June 2013 17:28:42 UTC