W3C home > Mailing lists > Public > www-webont-wg@w3.org > February 2003

RDF Semantics review: further comments

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>

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 Research
Received 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