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

No, these were not intended as formal comments at this stage. We 
might get to that later. But even if they were, I would be happy to 
accept your response as an adequate reply to my comments.

>  please send a follow-up to 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.

Quite. The DAWG chair asked me to informally review for internal WG 
purposes, and I got interested enough to send some comments directly, 
is all. Brief responses follow.


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

OK, you know this odd XML world better than I do. But humor me, as I 
am now puzzled. It seems that you are assuming a very deep and 
important distinction between name= and id=. I have always taken 
these to be simply synonyms of one another. No doubt this reflects a 
misunderstanding on my part, perhaps from being more steeped in HTML 
than XML, but can you briefly summarize what the significance of this 
difference is, and why it is so important in the light of the topic 
at issue here, viz. reconciling the RFC 2396 doctrine on retrieval 
actions and media types with the RDF qname conventions? On the face 
of it, this seems to have nothing to do with the name= vs. id= 
distinction. If this can be clarified in a couple of sentences it 
would be helpful for at least one reader.


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

I thought not.

>>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 
>Yes it does,

Can you point me to where? I read all of the (old) XSD part 2 
carefully looking for it.

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

OK. Maybe we should write a paper about it instead :-)

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

Received on Thursday, 24 February 2005 20:53:57 UTC