RE: A possible structure of the datatype system for OWL 2 (related to ISSUE-126)

Hello,

This is mainly because that's the way how things work in RDF. In RDF, you have plain literals which can have a language tag or not.
owl:internationalizedString corresponds to plain literals with a language tag, and xsd:string corresponds to plain literals without
a language tag.

I see that this is rather silly from a user's perspective, and there might be a way of unifying things; however, it requires a
change to the value space of xsd:string. We could have the following definitions:

- The value space of owl:internationalizedString is a set of pairs of the form ("string",langTag), where langTag includes all ISO
language tags, as well as a special 'null' language tag.
- The value space of xsd:string is a set of pairs of the form (string,'null').

In this way, we've made xsd:string a subset of owl:internationalizedString. Strictly speaking, that is a backwards incompatible
change; however, I don't believe that it is detectable in any way (in RDF or in OWL 1), mainly because in RDF and OWL 1 there was no
way to refer to the set of all internationalized strings.

Let me know how everyone feels about this.

Regards,

	Boris

> -----Original Message-----
> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org] On Behalf Of
> Michel_Dumontier
> Sent: 08 July 2008 19:57
> To: OWL Working Group WG
> Subject: RE: A possible structure of the datatype system for OWL 2 (related to ISSUE-126)
> 
> 
> 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 Wednesday, 9 July 2008 07:33:58 UTC