W3C home > Mailing lists > Public > www-archive@w3.org > January 2005

Re: General comments on XSCH Datatypes note

From: Jeff Pan <pan@cs.man.ac.uk>
Date: Wed, 26 Jan 2005 17:14:02 -0000
Message-ID: <219701c503ca$80a60c10$fec15882@Newton>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: <www-archive@w3.org>

Hi Jeremy,

Sorry for the delay.

> Summary:
> - in-line thoughts about Evan's general comments
> - action plan???
> I've been a bit remiss in not driving forward with this. We're meant to 
> have a new version for Thursday.
> I think we've basically got the detailed comments dealt with, except for 
> actually editing.
> I think we don't have to resolve the question between us of how much 
> does OWL DL cover user defined datatypes or not (although we should try 
> and have a verbal discussion about this, maybe in Boston - I think it 
> would be interesting). I think your DL material is relevant whether or 
> not OWL already presupposes it (it certainly doesn't adequately document 
> it).


> Going through Evan's comment in-line:
> ewallace@cme.nist.gov wrote:
>> My review of "XML Datatypes in RDF and OWL" [1] 
>> Overall, this is a good document.  It discusses a number
>> of issues related to the use of datatypes in RDF and OWL that were left
>> unresolved by the Recommendations.  It is comprehensive in addressing
>> the issues discussed: covering alternative approaches and providing
>> appropriate references and/or quotes as necessary.  In fact, because
>> of this comprehensiveness and the importance of the references,
>> reviewing this document was more of a project than I had originally
>> envisioned (although reading these references proved enlightening)..  
>> I have no major issues with this document, although I do have some
>> lesser concerns and comments.  These fall into two categories: general
>> and detailed.  The detailed concerns were already presented in an
>> email sent to the list yesterday [details].  The general concerns
>> follow below.
>> * The document covers a number of loosely related subjects.  It is
>>   like a bag of datatype issues and other related material.  Different
>>   parts will be of interest to different audiences.  I mentioned this
>>   before, but my main concern now is that someone reading linearly
>>   through the document will encounter the interpretation descriptions
>>   in 1.2, 1.3, and 1.4 and stop reading.  

>>  I think such material would
>>   be better placed as an appendix. 
> Really for you to either agree with or argue against.
> I tend to agree with Evan and would suggest following changes:
> Merge current
> 0. Intro and 1.1 XML Schema
> with
> 1. Intro
> Current text without namespaces stuff
> 1.1 Structure of this document
> Give an indication of the intended reader and role of each section
> In particular highlight the role of DL stuff as providing theoretical 
> background for the meaning of user-defined datatypes in OWL DL, and role 
> of appendix as supplementing material in RDF and OWL Semantics to cover 
> this document.

We could provide an overview of Appendix B at the beginning of Section 2 (before Sec 2.1), making it clear that in the rest of Section 2 we discuss only the URI problem.

I can further comment on these parts once I see your draft tomorrow morning.

> 1.2 Namespace declarations
> 1.3 XML Schema stuff

> New appendix
> A. (Title?)
> A.1  old 1.2
> A.2  old 1.3
> A.3  old 1.4

We could structure the above three sections as follows.

A. Summaries of RDF and OWL Datatyping

A.1 old 1.2
A.2 old 1.3

B. Integrating Description Logics with User-Defined Datatypes

old 1.4

Note that example IDs should change accordingly.

>>  It was also not clear to me the
>>   purpose and role of such material in this document.  By role, I mean
>>   are the interpretation descriptions in 1.2 and 1.3 quotes from the
>>   RDF and OWL semantics documents respectively or a different form for
>>   the same content?
> We should add URLs to the respective documents and indicate clearly any 
> differences if any.

>> * An important reference for datatypes in computing environments is
>>   the ISO standard on Language-independent datatypes - ISO/IEC
>>   11404:1996.  It provides an excellent framework for describing
>>   datatypes and appears to have been a strong influence on the XML
>>   Schema base types document [2] (which includes a reference to
>>   11404).  The XSCH note could benefit referencing the ISO work
>>   directly and using some of its terminology, although I don't think
>>   that this is necessary for this iteration of the note.
> Suggest we add the reference and a single sentence in the XML Schema 
> introductory section.


>> * My primary interest in these datatype issues is with the treatment
>>   of numeric types being consistent with their use in engineering
>>   applications (or at least usable by those applications).  Loss in 
>>   precision or unexpected changes in values due to automatic type
>>   conversion could be problematic in an engineering environment.
>>   Engineering view of some numeric types:
>>   To explain the engineering point of view on this, let me mention
>>   three important numeric types for that domain: count, measurement,
>>   and constant.
>>   A count is an integer representing essentially the
>>   cardinal number for a set of things classified by some set of tests.
>>   An example would be the count of packages of candy available for
>>   shipment.  A count is an exact number.  Tests may include
>>   measurements, but a count is not an approximation of a sum of 
>>   these measurements nor is it a sum of the approximation of these 
>>   measurements.
>>   A measurement is an inexact numeric value (usually represented as a
>>   real) produced by some measurement method.  This value denotes a
>>   value range which includes the actual value.  The actual value is
>>   unknowable, but more precise measurement methods can reduce the
>>   range of uncertainty up to a point.  The precision or uncertainty is
>>   usually included with the measurement value.  Either implicitly
>>   using significant figures or explicitly using a seperate property
>>   value such as error range.
>>   A constant is an exact value used in computation.  It may or may not
>>   be possible to express exactly as a numeric.  An inch is exactly
>>   2.54 centimeters, but Pi is not 3.14159.
>>   This suggests some potential needs and concerns for a type system
>>   underlaying this.  1. Because the value spaces for these types
>>   are different, measurements are disjoint from counts and constants.
>>   2.  Some means of capturing precision or error/uncertainty is needed
>>   for measurement values. 3. Some means is needed for denoting
>>   constants that cannot be expressed precisely in numeric form.
>>   Some answers about how 1 and 2 can/must be handled with XML Schema
>>   types are revealed in the XML Schema Datatypes document. In [2] the
>>   description for Decimal explicitly states that, "Precision is not
>>   reflected in this value space, the number 2.0 is not distinct from
>>   the number 2.00."  Thus precision cannot be encoded in decimal
>>   values or other types derived from or constructed with
>>   Decimal. Meaning: that objects must used to state precision or error
>>   properties for measurements (this is not a bad approach any since
>>   there are often other properties or metadata associated with a
>>   measurement as mentioned previously by Bernard [3]).  Measurements
>>   on the SW are thus not datatypes and the disjoint type issue becomes
>>   mute.
> At telecon I agreed to draft a new section based on this point, I would 
> put it before the appendix. It could be a second appendix, although it 
> feels less heavy than typical appendix material.

 I am not too sure if I have enough time to provide much comments on this tomorrow, although I second the idea of having such a section. 

>>   For issue 3, there remains no answer.  As far as I know there is no
>>   way to denote a rational value without using a numeric literal, but 
>>   many important values cannot be expressed precisely as numeric 
>>   literals.
>>   Information on these issues may belong in this datatype note or not,
>>   I am not sure.  I do think that the SWBPD wg should present these
>>   issues in some one of its notes, though.
>> -Evan 
>> [1] http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/
>> [2] http://www.w3.org/TR/xmlxschema-2/
>> [3] http://lists.w3.org/Archives/Public/public-swbp-wg/2004Dec/0119.html
>> [details] http://lists.w3.org/Archives/Public/public-swbp-wg/2005Jan/0040
> I'm happy to have a stab at making all these changes except for changes 
> inside your text (other than those precisely described in your e-mail 
> response to Evan). The most notable thing I would be missing is links 
> into the semantics docs for how the current sections 1.2, 1.3, 1.4 
> relate to them. I would leave clear markers where I need your help and 
> hopefully have this ready in time ....

Here are the URLs:

RDF: http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#DTYPEINTERP

OWL: http://www.w3.org/TR/2004/REC-owl-semantics-20040210/direct.html#3.1

Unary datatype group: [Pan2004] 

Received on Wednesday, 26 January 2005 18:38:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:50 GMT