From: Michel_Dumontier <Michel_Dumontier@carleton.ca>

Date: Tue, 8 Jul 2008 14:57:05 -0400

Message-ID: <AB349814F1ECB143A5D4CD29C7A6456902EB300C@CCSEXB10.CUNET.CARLETON.CA>

To: "OWL Working Group WG" <public-owl-wg@w3.org>

Date: Tue, 8 Jul 2008 14:57:05 -0400

Message-ID: <AB349814F1ECB143A5D4CD29C7A6456902EB300C@CCSEXB10.CUNET.CARLETON.CA>

To: "OWL Working Group WG" <public-owl-wg@w3.org>

Hi Boris, I'm concerned about the disjoint spaces for xsd:string and owl:internationalizedString. What reasons do you have for the distinction? I view the latter as a specialization of a more generic string datatype. Can we not propose one owl:string that supports both? Cheers, -=Michel=- > -----Original Message----- > From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org] > On Behalf Of Boris Motik > Sent: July 8, 2008 12:16 PM > To: 'OWL Working Group WG' > Subject: A possible structure of the datatype system for OWL 2 (related to > ISSUE-126) > > > Hello, > > After a very in-depth discussion about the issues related to datatypes > (thanks everyone involved!), I thought it would be good to > summarize some of the outcomes of a discussion and to outline a possible > structure of the datatype system. Thus, in this e-mail, > I'll try to (semi-)formally define a datatype map -- the "thing" that > defines how datatypes would work in OWL 2. > > 1. Datatype Map > ---------------- > > A datatype map consists of the following things: > > - a set of datatypes > - each datatype provides a set of allowed facets > - a possibly infinite set of constants (likely to be renamed to literals, > but I'll stick to "constant" for the moment) > - each constant consists of a lexicalValue and a typeURI > - it is written as "lexicalValue"^^typeURI > > Each datatype DT is assigned a value space DT^D, which is just a nonempty > set. > > Each constant c is assigned a value c^D, which is just an object from the > union of the value spaces of all datatypes. > > > Thus, a datatype can be thought as a class with a predefined extension. > Note that this definition does not assume any relationship > between the set of supported typeURIs (which determine the allowed > constants) and the set of datatypes (which determine the allowed > sets of values). > > 2. Allowed datatypes > --------------------- > > Comformant OWL 2 implementations would be required to support the > following base datatypes, each of whose value spaces would be > disjoint: > > - owl:number - the value space is the set of all real numbers > - xsd:string - the value space is the set of all Unicode strings in normal > form C > - owl:internationalizedString - the value space set is the set of pairs of > the form (string,langTag) > - xsd:hexBinary - the value space is the set of all finite sequences of > octets > > The following datatype would also be supported in OWL 2: > > - xsd:integer - the value space is the subset of the value space of > owl:number containing all integers > > Finally, we might support the following "shortcut" datatypes, whose value > spaces can be defined from the value spaces of the above > mentioned datatypes using facets > > - various xsd:integer derivatives, such as xsd:int and xsd:long > - various xsd:string derivatives, such as xsd:Name > > 3. Allowed constants > --------------------- > > Conformant OWL 2 implementations are required to support the following > constant types: > > - "nnn"^^xsd:int and all derivatives that fall within xsd:int - all such > constants are to be interpreted as elements of owl:number > - "aaEbb"^^xsd:float - all such constants save for NaN and +-inf are to be > interpreted as elements of owl:number > - "abc"^^xsd:string - interpreted as "abc" > - "abc"@langTag - interpreted as a pair ("abc",langTag) > > > 4. Discussion > -------------- > > The set of constants is chosen such that implementations don't need to > support numbers with arbitrary precision, which might be > quite cumbersome. In fact, implementations are only required to support 32 > bit integers and single precision floating point numbers. > There are efficient ways to represent these on virtually all systems. > > The set of datatypes, however, allows one to refer to the sets of all > integers and real numbers. This allows one to specify the > ontology in a way that makes reasoning easy. > > Implementations are free to support other constants as well. Note that > these extensions do not necessarily mean that we need new > datatypes (i.e., new value spaces). For example, an implementation might > choose to support arbitrary precision numbers via constants > of the form "123.03"^^xsd:decimal. Note that the proposed list of > datatypes already contains the appropriate value space for such > constants (i.e., owl:number). > > The open issues are what to do with NaN and +-inf and with date-time > datatypes. > > Regards, > > Boris > >Received on Tuesday, 8 July 2008 18:56:08 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:42:05 UTC
*