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

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 3.3, RDFS interpretations:
note that the rdfs:ContainerMembershipProperty condition
speaks of rdfs:Property instead of rdf:Property.

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.

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.

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.

Section 3.2: Reification, containers

The text on reification contains some rough spots, in my view.
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.

Herman ter Horst
Philips Research

[1] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0313.html

Received on Friday, 21 February 2003 11:11:21 UTC