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

Date: Thu, 20 Feb 2003 15:29:33 +0100

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

Message-ID: <OFCDFD00C3.1200725A-ONC1256CD3.003A5AC7-C1256CD3.004FC6C3@diamond.philips.com>

Date: Thu, 20 Feb 2003 15:29:33 +0100

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

Message-ID: <OFCDFD00C3.1200725A-ONC1256CD3.003A5AC7-C1256CD3.004FC6C3@diamond.philips.com>

Here is my next (third) set of comments on the last call version of the RDF Semantics document. Most of these comments are small corrections / editorial comments. The first comment is more substantive. == Consideration of rdfs-entailments from the empty RDF graph shows that there is an error in the RDFS entailment lemma. In line with the definition in 3.3, one triple should be entailed for each of the 13 entries following "IC contains": rdfs:Resource rdf:type rdfs:Class . etc. (including a triple rdfs:XMLLiteral rdf:type rdfs:Class . because of the omission noted below from the table in 3.3) and one triple should be entailed for each of the entries following "IP contains": rdf:type rdf:type rdfs:Property . etc. Each of these 13 + 16 + aleph-0 triples (16 is counted without duplicates, compare other comment below; the "aleph-0 triples" are from rdf:_1 etc.) follows by using the axiomatic triples in combination with the closure rules from 4.2, apart from one of these triples: The triple rdf:value rdf:type rdfs:Property is rdfs-entailed by but is not in the rdfs-closure of the empty rdf graph, since rdf:value never appears in either the axiomatic triples or the closure rules. (This gives a test case for this problem.) In particular, each of the 11 triples mentioned under part 1. of the definition of rdfs closure can safely be omitted from that definition. (Note that one of these 11 triples, rdf:nil rdf:ytpe rdf:list . is already in the definition of rdf closure.) The following 4 derivation patterns suffice for each of these 13 + 15 + aleph-0 proofs (This might be added to the proof sketch of the rdfs entailment lemma): I x rdfs:range y . rdfs:range rdfs:domain rdf:Property . rdfs:range rdfs range rdf:Class . together imply x rdf:type rdf:Property y rdf:type rdf:Class II similarly for domain instead of range III rdfs:subClassOf rdfs:domain rdfs:Class . rdfs:subClassOf rdfs:domain rdfs:Class . x rdfs:subClassOf y . together emply x rdf:type rdfs:Class . y rdf:type rdfs:Class . IV similary for subPropertyOf instead of subClassOf (For the proofs involving rdf:_1 etc. also the triples from part 2. of the definition of rdfs closure are used.) == Section 3.1, RDF interpretations: In the table defining an rdf-interpretation, IEXT(I(rdf:type)) is used before it is clear that I(rdf:type) is in the domain of this function (which is the set IP). Switching the first two lines of this table would remedy this. Section 3.3, RDFS interpretations: In the tables defining an rdfs-interpretation: IC should also be listed to contain I(XMLLiteral) IP is listed to contain I(rdfs:comment) and I(rdfs:label) twice Section 4.1, Rdf-entailment and rdf closures "Here xxx and yyy stand for any uriref, bNode or literal..." However, xxx cannot be a literal. Section 4.2, RDFS-entailment and RDFS closures (note that naming of sections 4.1 and 4.2 is not entirely consistent) Again, xxx cannot be a literal. two typos: heirarchies, heirarchy The triples rdf:_1 rdf:type rdfs:ContainerMembershipProperty . etc. are taken to be part of the "axiomatic triples" in Section 3.3. This is confusing, as they are clearly not implied in the use of the phrase "axiomatic triples" in part 1. of the definition of rdfs closure in Section 4.2. == Section 4.3, Datatype entailments This section only describes closure rules. However, more can be said. For each recognized datatype x (that is, if x is in D) the following triple is D-entailed already by the empty RDF graph: name(x) rdf:type rdfs:Datatype . This follows from the assumption on D-interpretations that D is a subset of ICEXT(I(rdfs:Datatype)). == Appendix B, Proofs of Lemmas Plain Subgraph Lemma The 'only if' is said to follow from the previous lemma, but it seems to be easier to use the Herbrand interpretation (which appears only hereafter). == The definition of subinterpretation I << J is not clear, as it is not clear what a "projection mapping from IR into JR, IS into JS, IL into JL and IEXT into JEXT" is. IR and JR are sets, so the first part is clear: a function from IR into JR. However, IS and JS are functions. What is meant by a mapping from a function to a function? It seems that the following definition suits the intended use in the Herbrand lemma: I is a subinterpretation of J, I << J, when there is a projection mapping f : IR -> JR such that the following hold: - f(IP) subsetof JP [this is needed for the last condition] - for each v in V, JS(v)=f(IS(v)) - for each typed literal l, JL(l)=f(IL(l)) - for each p in IP, { <f(x),f(y)> : <x,y> in IEXT((I(p)) } subsetof JEXT(f(p)) Then, automatically, any triple is true in J if it is true in I. == Proof of RDF closure lemma Why is IP-sub-H not simply called HP, in line with the definition of the interpretation I (and IP)? There is no interpretation I here. The proof of the "if" part of the second condition does not clearly start with what can be assumed to be given (namely, <p,H(rdf:Property)> is in HEXT(H(rdf:type)) ). Moreover, this proof can be made somewhat shorter, as follows: Suppose <p,H(rdf:Property)> is in HEXT(H(rdf:type)). Then rdfclos(E) contains the triple p rdf:type rdf:Property . so by the definition of Herbrand interpretation, HP contains p. Herman ter Horst Philips ResearchReceived on Thursday, 20 February 2003 09:31:40 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Monday, 7 December 2009 10:57:57 GMT
*