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

Overall, great job of exposition, badly needed.

-------------

Few typos/comments:
section 2.2

You say that the use of simpleTypes#adultAge violates RFC2396, citing this:
"
The semantics of a fragment identifier is a property of the data 
resulting from a retrieval action, regardless of the type of URI used 
in the reference. Therefore, the format and interpretation of 
fragment identifiers is dependent on the media type [RFC2046] of the 
retrieval result. [...]"

but I see no contradiction there. Indeed, one could use a retrieval 
action on http://example.org/simpleTypes, right? And it might be an 
RDF ontology, in which case the semantics might well be said to be a 
'property of the data resulting from' the retrieval action. OK, Im 
splitting hairs, but we have to split hairs when dealing with 
out-of-date documents like RFC2396.

Section 2.4
Daml//DAML

You might also point out that the id= solution has the merit that 
according to Xpointer,
"If no element information item is identified by a shorthand 
pointer's NCName, the pointer is in error."
which means that the use of a URIref in this way whose root URI does 
not provide any (hopefully definitive) uses of the element is an 
error, which Im sure TBL will find congenial as a piece of Web 
discipline. .

Section 2.5

"Both the XSCD and the id solutions have the problem that the 
proposed URI references designate a syntactic thing, rather than the 
datatype itself."

Seems to me (maybe Im alone here, but ..) that this is just one 
example of a whole range of related issues about URI denotation, and 
that we should just grasp this nettle and say that URI's can IDENTIFY 
(RFC 2396) one thing (typically syntactic, seen from a SW 
perspective) and also, and simultaneously, DENOTE something else; and 
that this is quite OK as long as the thing they identify (is closely 
related to something that) denotes the thing they denote. And this is 
not URI punning (a Tag Bad Thing) but rather a systematic way of 
relating identification with denotation. It does not rule out the 
simple URN case where identify=denote, but it allows a 2-step version
URIref--indicates-->piece of syntax--denotes-->thingie
which can also be contracted to be URN-like:
URIref--denotes-->thingie
where convenient (as for example in RDF). Then this takes care of the 
second problem with the wording of 2396, which you cite:
"A fragment identifier is only meaningful when a URI reference is 
intended for retrieval and the result of that retrieval is a document 
for which the identified fragment is consistently defined."

3.1
Or in other words, when are two literals, which are written down 
differently, refer to the same value
// referring to the same value
OR:
//when do two literals

---
3.2
the RDF and OWL Semantics are
Semantics//semantics
--
Similar OWL DL entailments could be constructed, illustrating the same issues.

why didn't you give DL examples, then? (Question springs to the 
reader's mind at this point.)
--
3.2.1

Example uses "15.0"^^xsd:decimal  but then switches to "15"^^xsd:decimal

Example 3J says 'this is only a rounding error' but you might observe 
that since it is possible to express restrictions on such values in 
OWL, ignoring rounding errors can give rise to clear inconsistencies. 
Your phrasing makes it sound like an unimportant kind of issue.

3.3

You might remark that the relation ~ is conventionally written as '=' 
and called equality.

The formal definition you give is slightly broken, since you say that 
~ is a relation, but you equate it to a class. Also, IL and Ed are 
not strictly speaking invertible. ( I see what you mean, but you are 
using mathematical abuses of notation that might confuse some 
readers.) This might be better:

~  = {<x,y> : IL(x)=IL(y) }

and the equivalence classes are defined slightly circularly in this way:

X= { x: IL(x)=IL(y) for any y in X}

Or, less circularly, as

X = {x: IL(x)=z }

for some value z, where this is the equivalence class of expressions 
denoting the given literal value z.  (But not X= {x: exists z. 
IL(x)=z} :-)

---

section 5
measurement.... The actual value is  unknowable, but more precise 
measurement methods can reduce the  range of uncertainty up to a 
point.

"up to a point" is perhaps an unfortunate way of phrasing it (unless 
its a small joke.)

seperate //separate

This value denotes a  value range which includes the actual value."  ;
Well not exactly. Might be better to say that it 'indicates' a value 
range. But in fact in real engineering apps the error range is 
usually specified somewhere, perhaps contextually, so what denotes 
the value range is not the value itself but the value plus the error 
range.

The basic point is that measurements are typically given as a number 
and one or more error ranges, and clearly xsd:decimal refers to the 
former but not the latter. This needs noting because of the common 
engineers convention of indicating the error range by the number of 
decimal places given, so 2.00 is 2 plus or minus 0.009.
---

"This is not a bad approach any since  there are"

//.. approach in any case, since...

BTW, there is an issue here that you don't address. Typical error 
ranges are stated as bounds ("+ or - 0.001 cm"). OK, but what 
datatype should be used to state the bounds themselves? Would it make 
sense to write something like
"32.65++0.001"^^xsd:boundederrorfloat
? That would be extremely convenient for engineering applications, 
but it requires treating the 0.001 differently (exactly) from the 
literal value itself (approximate).  Could this be defined as an xsd 
derived datatype?

---

underlaying//underlying
(underlay is what you put under a carpet)

Appendix A

Might be interesting to relate the RDF/OWL definitions to the XML 
definition given at the start. XML doesnt mention value spaces at 
all, and its use of 'facets' strongly suggests that the XML view 
simply allows questions of identity to be highly contextual, in 
contrast to the model-theoretic approach we used. Might be worth 
expanding on this difference, which is responsible IMO for many of 
the complexities and ambiguities you discuss.

---

As far as OWL Full is concern, the disjointness restriction about 
object and datatype domains is not required.
// In OWL Full, the disjointness restriction between...
-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes