[XSCH] editors draft - finished?

Hi the version at:

http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/

integrates the respones to Evan's comments.
Still to do is to update the table of contents and the example numbers 
in the new appendices.

Two new sections added in response to Evan are:

http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/#sec-structure
Section 1.1 Reading this Document

(consequential change made after restructuring the document as Evan 
suggested)

and

http://www.w3.org/2001/sw/BestPractices/XSCH/xsch-sw/#sec-numerics
Section 5 The Use of Numeric Types

(essentially the text of Evan's comment with editorial changes)

Jeff will hopefully give the thumbs up for the changes this afternoon 
and I will circulate a version with fixed ToC and example numbers before 
the telecon.

For ease of review of new material here it is:


[[
1.1 Reading this Document

%% new section

While this document can be read from start to finish, many readers will 
benefit from skipping sections.

The intended reader is informed about RDF and/or OWL, and may be a 
creator or user of metadata or ontologies, or may be an implementor of 
systems that implement the RDF or OWL Recommendations, or may be the 
author or editor of related specifications.

The reader who is interested in defining their own datatypes should read 
section 2 and maybe appendix B, which gives a formal treatment in terms 
of OWL DL.

The reader who is interested in the correct use of datatypes should read 
section 3, concerning which values are the same, and section 5 
concerning numerics, particularly, but not exclusively, for engineering 
applications.

Implementors probably should read most of the document: appendix A 
summarizes the formal treatment of datatyping from the recommendations; 
section 3 gives an extended discussion about equality; section 2 
discusses the mapping from URIs to user defined types.

Readers most interested in formal semantics will find most value in 
appendix B, concerning user defined datatypes, and section 3 concerning 
equality. Such readers should start by reviewing appendix A, which 
should be familiar.

Section 4 on durations, is of more limited interest, but is significant 
to any reader who wishes to use, implement or build on top of duration 
datatypes.
]]


[[
5. The Use of Numeric Types

%% whole section is new

For much data on the Semantic Web a motivation for providing type 
information is to permit the use of the data by engineering 
applications, and interoperation between engineering applications. Most 
such data will be marked up using the numeric types from XML Schema.

Loss in precision or unexpected changes in values due to automatic type 
conversion could be problematic in an engineering environment.

In the engineering domain there are three important types of usage for 
numerics: count, measurement, and constant.

count
     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 type such as xsd:integer or a 
type derived from xsd:integer is appropriate for counts.
measurement
     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. Either 
the xsd:float or xsd:double datatypes are appropriate for measurement, 
but it should be noted that these do not include a precision or 
uncertainity, which should be included as the value of a separate 
property. [XML SCHEMA2] explicitly states for xsd:decimal that, 
"Precision is not reflected in this value space, the number 2.0 is not 
distinct from the number 2.00."
constant
     A constant is an exact value used in computation. It may or may not 
be possible to express exactly as a numeric. A millimeter is exactly 
0.001 meters, but Pi is not 3.14159. Often an xsd:decimal will be more 
appropriate than an xsd:float or xsd:double for expressing a constant.

This suggests some potential needs and concerns for a type system 
underlaying this.

     * Because the value spaces for these types are different, 
measurements are disjoint from counts and constants.
     * Some means of capturing precision or error/uncertainty is needed 
for measurement values.
     * Some means is desirable for writing down constants that cannot be 
expressed precisely in numeric form.

The first of these issues will generally be reflected in the use of 
xsd:integer for counts, xsd:float and xsd:double for measurements, and 
xsd:decimal for constants.

The second issue concerning precision of measurements, must be addressed 
at the modelling level by using objects 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.

For the third issue, concerning some constants, no solution is offered.
]]

Jeremy

Received on Thursday, 27 January 2005 12:23:08 UTC