Re: ISSUE-126 (Revisit Datatypes): The list of normative datatypes should be revisited

Hi Boris,

While it is useful to have this proposal for the record, I think  
there needs to be some education within the working group in order to  
better understand the issues leading to this proposal, as well as the  
consequences of the solutions. For the excluded datatypes, we need to  
understand the impact on users and potential users.

I also think we need to clarify what being a supported datatype  
means. In particular it should be clarified whether this means that  
tools will simply reject ontologies that mention these types, even as  
annotation values, and whether there are possibly different levels of  
support - use/non-use of all facets/ some facts - ability to use the  
datatypes within nary predicates come to mind as examples where we  
might define a minimal level of support without eradicating the types  
completely. I am still working on understanding the technical issue -  
do I have it right that the issues really center around the nary- 
predicates? If there were no nary-datatypes and no facets, would any  
of these datatypes be a problem?

I also have a rather basic question about the datatype formulation in  
the OWL semantics. Specifically, although I believe the xsd datatypes  
are considered disjoint, their value spaces intersect, i.e. the value  
space of positive integers intersects the value space of xsd:float.  
Is that correct? Assuming that is the case, do cardinality  
restrictions apply at the value space level, i.e. is the cardinality  
of {"2^^xsd:int 2.0^^xsd:float} 1 or 2 (assuming, as I believe is the  
case, that 2 can be exactly represented as a floating point value).

Of your points below, 2 and 3 don't seem problematic from my point of  
view (internationalized string is missing from the list in 3- an  
oversight I presume). The others require more thought on my part.

Thanks,
Alan

On Jun 18, 2008, at 3:23 PM, Boris Motik wrote:

>
> Hello,
>
> So here is a proposal for resolving this issue.
>
> 1. We exclude xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear,  
> xsd:gMonthDay, xsd:gDay, xsd:gMonth, and xsd:base64Binary from the  
> list
> of supported datatypes. Note that this doesn't preclude people from  
> implementing them (if they can figure out how to do this).
>
> 2. We define xsd:anyURI to be a subset of xsd:string.
>
> 3. We allow the "pattern" facet only on the following datatypes:  
> xsd:string, xsd:anyURI, xsd:normalizedString, xsd:token,
> xsd:language, xsd:NMTOKEN, xsd:Name, and xsd:NCName.
>
> 4. We introduce a new owl:real datatype. This datatype would allow  
> for the following types of constants:
>
> - rational numbers written according to http://www.w3.org/2007/OWL/ 
> wiki/OWL_Rational
> - floating point numbers written in the format as specified in the  
> definition of xsd:float and xsd:double in the XML Schema
> - decimal numbers as written in the format as specified in the  
> definition of xsd:decimal
> - integer numbers as written in the format as specified in the  
> definition of xsd:integer and related datatypes
>
> Furthermore, we would make xsd:float and xsd:double (and possibly  
> xsd:decimal as well) synonyms for xsd:real. This would be the only
> definition from the XML Schema datatype system: there, some very  
> large numbers are not members of xsd:float. I believe, though, that
> this would bother people in practice.
>
> Finally, we can include xsd:nonPositiveInteger,  
> xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte,  
> xsd:nonNegativeInteger,
> xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort,  
> xsd:unsignedByte, and xsd:positiveInteger with the existing  
> semantics as
> usual.
>
> Regards,
>
> 	Boris
>
>

Received on Thursday, 19 June 2008 05:50:18 UTC