From: <herman.ter.horst@philips.com>

Date: Thu, 6 Feb 2003 20:04:25 +0100

To: phayes@ai.uwf.edu, www-webont-wg@w3.org

Message-ID: <OF6A0F402E.BEE12650-ONC1256CC5.003D9550-C1256CC5.0068F22A@diamond.philips.com>

Date: Thu, 6 Feb 2003 20:04:25 +0100

To: phayes@ai.uwf.edu, www-webont-wg@w3.org

Message-ID: <OF6A0F402E.BEE12650-ONC1256CC5.003D9550-C1256CC5.0068F22A@diamond.philips.com>

RDF Semantics document Last Call version, 23 January 2003 Below I give a few comments to indicate several places where a small correction / clarification should be made, in my view. Section 0.3, third paragraph, last sentence: ...to obtain another set S' of graphs which are isomorphic to those in S. Here 'isomorphic' is not defined: it should be 'equivalent' (if this is the term that will be used) The same remark applies to a sentence near the end of Section 0.3: "By our convention, such isomorphic graphs are considered to be identical." 1.3 last sentence: "A simple interpretation can be viewed as having an empty vocabulary". This is confusing, as the vocabulary of any useful interpretation is not empty. Perhaps a term such as "special vocabulary" should be more formally introduced, so that the cited sentence could speak of an 'empty special vocabulary'. The next paragraph in Section 1.3 speaks of "simple literals", which are not defined. I guess that plain literals is what is meant here. Section 2, first paragraph. The definition of entailment is given for a "set of expressions" S and an (unspecified) E. Later, S always stands for a finite set of RDF graphs or for one RDF graph and E stands for an RDF graph. I believe that the readability would be much improved by introducing these intended meanings of S and E here already. Otherwise, the reader needs to match the word expression with the word RDF graph, which is not directly intuitive. It would also help the reader if it is stated here explicitly that if S entails E, then the vocabulary of S includes that of E. Suggestion for clarification in the next paragraph: > Any process which constructs a graph E from some other > graph(s) S is said to be (simply) valid if [add] in each case > S entails E, otherwise invalid. Without this addition, the meaning is not entirely clear, in my view. Section 2.1, second paragraph > Such an internally redundant graph is equivalent to one > of its own instances ... Here 'equivalent' is not defined: it is not 'RDF graph equivalence' (see other remark). What is apparently meant here is that there is entailment in both directions. Section 3.1, first sentence The abbreviation rdfRV is not clear: what does R stand for? It seems that this abbreviation could be omitted as it is not used elsewhere. The more fundamental vocabulary seems to be rdfV, introduced later. Section 3.1, example IR = {1,2,T,P} should be replaced by IR = LV union {1,2,T,P} Section 3.4, Datatype monotonicity lemma. This lemma involves the notion of D-entailment, which is not yet defined at this point in the text. This seems to need some more explanation, moreover. In order to prove the lemma, if the D'-interpretation I satisfies S, it needs to be proved that I satisfies E. So it is given that ICEXT((I(rdfs:Datatype))=D'. How is it concluded that ICEXT((I(rdfs:Datatype))=D, as is needed to conclude that I satisfies E? It is clear that the new version of the RDF Semantics document depends strongly on the RDF Concepts and Abstract Syntax document. The Semantics document is the more mathematically oriented document, and can be made more self-contained by just recalling/including in the beginning of Section 0.2 the abstract definition of RDF graph: given three pairwise disjoint sets U (urirefs), B (blank nodes), and L (literals), an RDF graph is a subset of U union B x U x U union B union L. This would clarify the Semantics document very much, and diminish strongly the dependence on another 23 page document. Much of the content of the RDF Semantics document depends only on this. For specific details about urirefs/literals, one needs to go to the Concepts document, of course. Herman ter HorstReceived on Thursday, 6 February 2003 14:06:25 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:56:51 UTC
*