- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Wed, 26 Jan 2005 17:28:31 +0000
- 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 UTC