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

RDF Semantics review: several corrections /suggestions for clarification

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>
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 Horst
Received on Thursday, 6 February 2003 14:06:25 GMT

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