Review semantics document (2002-12-13#7) - part 1

Per my action 2002-12-13#7, as minuted:
   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Dec/0231.html
this is my partial review of:
   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/
up to and including section 3.3.

Many of my comments are marked [Editorial] or [Typo], which are merely 
issues I draw to the editor's attention.

Some are marked [For discussion], which may or may not be problems with 
this document, and request wider review.

One is marked [Error], which I think needs to be fixed.


...

[Editorial]
Abstract:
Isn't this meant to stand alone, separately from the document?  The 
citations here militate against this.

...

[Editorial]
Section 0.2, para 2:
The second sentence is slightly confusing concerning the referent of "which 
occur in either the S or O position...".  On first reading, I took it to be 
saying the a _literal_ can occur in S or O position.  Suggest reorganization:
[[
Draw one oval for each blank node, and for each uriref occurring in either 
the S or O position in any triple in the set, and one rectangle for each 
literal, and write each uriref or literal as the label of its shape.
]]

...

[Editorial]
Section 0.2, para 4:
Treating ex: as an imaginary URI scheme seems a little odd to me.  Why not 
just some arbitrary (unspecified) Qname prefix?   (I guess changing this 
would require all examples to be revised to drop angle brackets around 
<ex:...>.)

Also, use of monospace font for some prefixes but not for 'ex:' or the 
suggested corresponding URI.

...

[For discussion]
Section 0.2, Prefix xsd: namespace:
Maybe this is OK, but I think it should be checked.  Some time ago, DanC 
posted a "Get off my lawn" comment -- 
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Sep/0162.html, 
pointing out that folks shouldn't define URIs occupying namespaces that are 
controlled by some other group.

It's not clear to me that the XML schema specs define URIs of the form 
(e.g.) http://www.w3.org/2001/XMLSchema#decimal, since the concatenation 
convention is something introduced by RDF.  Also, the XML schema 
specification does not introduce a '#' into its namespace.  There has been 
some discussion about this issue, but I'm not sure that it's fully 
resolved;  it's not clear to me that the XML schema specs sanction use of 
(say) http://www.w3.org/2001/XMLSchema#decimal to denote an RDF datatype.

Also, I note that the normative references cite XML schema part 2, but the 
document one gets by retrieving http://www.w3.org/2001/XMLSchema refers to 
part 1 only.  I think this may be an omission in the document there rather 
than an error in this specification.

...

[Editorial]
Section 0.3, para 3:
Is it really possible for two distinct graphs to share any blank nodes?  I 
suppose in some obscure abstract sense it may be, but wouldn't it be easier 
to simply assert that no blank node may appear in more than one graph?  The 
next paragraph seems to deal adequately with the node identifier renaming 
issue which is a real practical concern.

...

[Editorial]
Section 0.3, para 7:
The concept of a triple being an instance of another triple is used here, 
but I haven't seen it previously explained.

...

[For discussion]
Section 1.1, para 2:
Restriction to non-looping RDF graphs?   Is this really possible, in light 
of section 0.1 about the requirement to honour the base semantics in any 
extension, and the fact that in an RDFS-interpretation everything must be 
an instance of rdfs:Resource, including rdfs:Resource?  It seems this is 
allowed if a semantic extension does not include RDFS-interpretation 
constraints;  it seems odd to me that the specification seems to be almost 
recommending a course that conflicts with other parts of itself.

This also suggests to me that section 0.1 maybe needs to be more explicit 
about exactly what semantic entailments must be included in any semantic 
extension.  The language there currently says:
[[
Semantic extensions of RDF MUST conform to the semantic conditions in this 
document.
]]
and
[[
The semantic conditions imposed on an RDF semantic extension MUST define a 
notion of vocabulary entailment which is valid according to the model- 
theoretic semantics described in the normative parts of this document ...
]]
which can be taken to mean that simple-, rdf- and rdfs- entailments MUST be 
supported.  I think it might be better to state this explicitly, if that is 
what is intended.  I think that extensions must support at least simple- 
and rdf-entailments, and should also be required to support 
rdfs-entailments if that can be squared with the point made about avoiding 
looping RDF graphs.

...

[Typo]
Section 1.3, para 3:
"particularn" in
"Some interpretations may assign special meanings to the symbols in a 
particularn vocabulary,..."

Also, double '..' in 'etc..'

...

[For discussion]
Section 1.3, interpretation of literals:
Did the issue of whether plain literals denote themselves or denote some 
member of the value space of xsd:string ever get resolved?  [I think DanC 
raised this -- I don't have a reference to hand.]

(May also affect section 1.4: I(E)=E for plain literals)

...

[For discussion]
Section 1.3, para 5 about LV:
It seems that the set LV is independent of any particular vocabulary of 
interpretation.
In which case, it seems to me that LV must include all of IR, thus:
(1) suppose in some interpretation on some vocabulary V there is a value or 
set of values in IR that are not in LV.
(2) define a new interpretation on V' which is the same as the the previous 
interpretation, except that V' is V with an added URI for a new datatype, 
defining a literal form for at least one value not in LV.  I see nothing 
that prevents this.
(3) by the definition of LV, it must contain the value space of the new 
datatype introduced in V'.  If LV is independent of vocabulary, this 
contradicts the supposition (1).

Further, since the IR for a vocabulary is defined to be a superset of LV, 
this suggests IR=LV for all vocabularies of interpretation.

If this is truly an issue, I suggest the set LV is defined with respect to 
a vocabulary (as is an interpretation).  I think this then permits a 
sharper definition of LV (i.e. all strings, all <language,string> pairs and 
the union of all the value spaces of the datatypes whose URIs are in V).

Alternatively, what is the need to distinguish LV?

...

[Editorial]
Section 1.4, figure 1:

The diagram claims that IR has just two members.  But you have stated 
elsewhere that IR must include LV, which includes strings like "whatever", 
because they map to themselves when used as plain literals...

...

[Editorial]
Section 1.5, para 2, et seq:

The use of anon(E) is a throwback to older terminology, since 
dropped.  Would it be more appropriate to use, say, blank(E)?

...

[Editorial, inconsistency?]
Section 2, para 3:
The description of "valid" here is with respect to a "process or 
technique".  But the glossary version is with respect to an "inference".

Suggest:  extend glossary definition to allow "of an inference, process or 
technique"?

...

[Editorial, spurious content?]
Section 2, just before 2.1:
[[
It might be thought that the operation of changing a bound variable would 
be an example of an inference which was valid but not covered by the 
interpolation lemma, e.g. the inference of

_:x <ex:a> <ex:b> .

from

_:y <ex:a> <ex:b> .

Recall however that by our conventions, these two expressions describe 
identical RDF graphs.
]]

I can't see what new information is being added here.  In particular, I 
think the inference suggested *is* covered by the interpolation lemma, 
because "_:y <ex:a> <ex:b> ." is a subgraph of the merge of the set 
containing just itself, and is also an instance of "_:x <ex:a> <ex:b> .", 
which  are exactly the conditions for entailment according to the 
interpolation lemma.

...

[Editorial, consistency of style]
Section 3, para 1:
The font used for rdf: and rdfs: prefixes is different from that used in 
section 0.2, para 4.

...

[For discussion]
Section 3, para 3:
[[
... we use the Qname namespace prefixes to identify the various 
distinctions ...
]]

The nature of Qnames, as defined by XML namespaces, is that the prefix is 
arbitrary;  i.e. it is defined locally.

It is merely a *convention* that (say) rdf: is widely used as the prefix 
for members of the RDF namespace, and valid Qnames for these concepts may 
quite legitimately be different (as long as they are different from other 
prefixes used locally to refer to different namespaces).

The fix may be very simple:
[[
... we use the Qname namespace prefix conventions to identify the various 
distinctions ...
]]

...

[Editorial]
Section 3, para 3:
[[
... Intuitively, a conclusion may follow from some of the extra assumptions 
incorporated in the semantic conditions imposed on the reserved vocabulary.
]]

This seems to say the additional conclusions are consequences of the extra 
assumptions alone.

Suggest:
[[
... Intuitively, a conclusion may depend upon some of the extra assumptions 
incorporated in the semantic conditions imposed on the reserved vocabulary.
]]

...

[Editorial]
Section 3.1, para 1:

The phrasing here "Consider..." suggests this is a throw-away example.
I suggest:
[[
The following (rather small) reserved vocabulary is called rdfRV:
]]

...

[Editorial]
Section 3.1, para 3:
[[
The first condition forces every rdf interpretation to contain a thing 
which can be interpreted as the 'type' of properties.
]]

The first condition being
[[
IP contains   I(rdf:type)
]]

This doesn't make sense to me.  I am guessing something like this is meant:
[[
The first condition forces every rdf interpretation to contain a thing in 
IP denoted by rdf:type;  this will be used as a property to associate 
'type' values with resources.
]]

The original text seems to describe the second condition.

...

[Error]
Section 3.3:

Contains some instances of rdfs:XMLLiteral, as well as 
rdf:XMLLiteral;  should all be rdf:XMLLiteral, I think.

...

That's me done for now.  More later.

#g



-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 31 December 2002 13:19:09 UTC