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

Re: General comments on XSCH Datatypes note

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 26 Jan 2005 17:28:31 +0000
Message-ID: <41F7D33F.9080006@hplb.hpl.hp.com>
To: Jeff Pan <pan@cs.man.ac.uk>
CC: www-archive@w3.org


great ...

Jeremy

Jeff Pan wrote:
> 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).
> 
> 
> OK.
> 
> 
>>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.
> 
> 
> OK.
> 
> 
>>>* 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] 
> 
>  Jeff
> 
> 
> 
Received on Wednesday, 26 January 2005 17:28:54 GMT

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