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

Dear Pat,

thanks for these comments - I'm not sure how you want these treated at 
this point. I'll give you inline responses now, and I will try to work 
any changes into the doc soon. "OK" below indicates that I completely 
accept your comment.

I reject three of your comments, indicated by "No"; if you would like 
any such rejected comment treated more formally, please send a follow-up 
to public-swbp-wg@w3.org indicating whether it is a personal or WG comment.


I've bcc-ed SWBP to keep that group informed ...

If there is anything here that should be made a WG to WG comment, I 
assume that such a comment will be made on public-swpb-wg in the near 
future, or as a verbal comment in Boston.

Jeremy


Pat Hayes wrote:
> 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.

No.
The http://example.org/simpleTypes doc, in the DAML+OIL examples is an 
XML Schema, with the XML Media type which (sort of) uses id="adultAge" 
in the interpretation of this fragID, and definitely does not use 
name="adultAge". I think I stand by the text.

> 
> Section 2.4
> Daml//DAML

OK

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

OK

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

Hmmmm, I will think about adding a shorter piece of text, perhaps along 
the line:
"Perhaps this reflects that in the Semantic Web we are interested in the 
formal concept of `denotation' which may not in all cases be identical 
to the RFC 2396 concept of `identify'."

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

OK (the latter)


> ---
> 3.2
> the RDF and OWL Semantics are
> Semantics//semantics

OK

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

Answer: the DL examples are slightly longer and do not add additional 
clarity, at least for me. Perhaps change to:

"Similar, slightly longer, OWL DL entailments ..."

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

Good catch, change to "15.0"^^xsd:decimal in both instances

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

I will delete the word 'only'

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

OK

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

OK, I'll be little more precise and less expecting a degree in maths.

> 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} :-)
> 

I'm not sure which of these I will follow yet, but I will avoid the 
identification of a partition into equivalence classes with the 
equivalence relation.

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

OK will delete "up to a point"

> 
> seperate //separate

OK

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

OK, s/denotes/indicates/

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

OK

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

No.

Perhaps we should add an example

eg:item eg:weight _:w .
_:w eg:units "kilogram" .
_:w eg:value "73.1"^^xsd:float .
_:w eg:errorRange "0.1"^^xsd:float .

to indicate a weight in the interval (73.0Kg, 73.2Kg)

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

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

Yes it does, it doesn't define the l2v mapping as such.

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

No. Feels too difficult.

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

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

thanks for these comments

Jeremy

Received on Tuesday, 22 February 2005 18:11:02 UTC