W3C home > Mailing lists > Public > public-swbp-wg@w3.org > January 2005

Re: [XSCH] editors draft - finished?

From: Jeff Pan <pan@cs.man.ac.uk>
Date: Thu, 27 Jan 2005 17:22:17 -0000
Message-ID: <252a01c50494$d2436430$fec15882@Newton>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: <public-swbp-wg@w3.org>


> 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.

In general, it is fine with me. I have slightly revised it and put it in


For ease of review, I also put it here:

**The 3rd papa of Section 1.1:

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 and user defined datatypes. 

** The para just before Section 2.1:

%% This section only deals with the problem of how to refer to such datatypes. Their semantics is treated in the appendices. Appendix A reviews the semantics of datatypes from the RDF and OWL recommendations. Appendix B describes how to integrate Description Logics (such as the SHOIN DL, which is the underpinning of OWL DL) with user defined datatypes. 

** The last para in Appendix B:

[Pan 2004] shows that we can combine any decidable DL (including SHOIN, the underpinning of OWL DL) that provides the conjunction and bottom constructors with a conforming unary datatype group and the combined DL is still decidable. 


Dr. Jeff Z. Pan  ( http://DL-Web.man.ac.uk/ )
School of Computer Science, The University of Manchester

> 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 17:24:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:41 UTC