Re: RDF Semantics: another 11 comments

>RDF Semantics document,
>last call version, 23 january 2003
>Most of the corrections / editorial comments given below
>were mailed earlier to the WebOnt WG [1].

For the record, all of these comments have been accepted as editorial 
changes by the editor and suitable corrections have been, or will 
shortly be, incorporated into the editor's draft.

>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

Fixed

>Section 3.3, RDFS interpretations:
>note that the rdfs:ContainerMembershipProperty condition
>speaks of rdfs:Property instead of rdf:Property.

Corrected

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

Wording clarified

>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

Wording clarified, spelling fixed.

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

Wording will be fixed.

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

Text fixed (from an earlier comment).  The IP/HP conventions was 
found confusing by several readers, has been replaced by an explicit 
definition.

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

Correction will be made (editorial corrections to lemma proofs are 
deliberately delayed until the rest of the text is considered 
completely stable.)

>Section 3.2: Reification, containers
>
>The text on reification contains some rough spots, in my view.

Editor agrees. This text has been re-worded in an attempt to make the 
points more clearly.

>The second of the next two cited sentences is rather complicated
>to follow.  Therefore, I would suggest to add some explanation,
>for example as between the following brackets []:
>>  This could be stated formally as follows:
>>  <x,y> is in IEXT(I(rdf:subject))
>>  just when x is a token of an RDF triple of the form
>>
>>  aaa bbb ccc .
>Suggestion: use instead the same example as given just before this:
><ex:a> <ex:b> <ex:c> .
>>
>>  and y is I(aaa) [I(<ex:a>)]; similarly for predicate and object. Notice
>>  that the value of the rdf:subject property is not the subject
>>  uriref itself but its interpretation, and so this condition
>>  involves a two-stage interpretation process: we have to
>>  interpret the reified node - the subject [_:xxx] of the triples in
>(this addition because _:xxx was called earlier reified triple)
>>  the reification - to refer to another triple, then treat
>>  that triple as RDF syntax and apply the interpretation
>>  mapping again to get to the referent [I(<ex:a>)] of its subject.
>(this addition because 'referent' is undefined).
>
>>  We emphasize that the semantic extension described here requires
>>  the reified triple that the reification describes - I(_:xxx) in
>This is very confusing: several paragraphs earlier not I(_:xxx)
>but _:xxx was called the reified triple.
>  > the above example - to be a particular token or instance of a
>>  triple in a (real or notional) RDF document, rather than an
>>  'abstract' triple considered as a grammatical form.
>
>About containers:
>>  This should not be taken as meaning that these assumptions are false,
>>  but only that RDF does not formally       entail
>(here it should rather be something like:) [support entailments]
>>that they must be true.

Correction to text will be made.

>Herman ter Horst
>Philips Research
>
>[1] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0313.html


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Monday, 24 February 2003 11:00:30 UTC