Last Call comments on "Concepts and Abstract Syntax"

[Resend: Originally sent 9 Feb, but missing from the archive]

-----Original Message-----
From: Williams, Stuart 
Sent: 09 February 2003 05:39
To: www-rdf-comments@w3.org
Subject: Last Call comments on "Concepts and Abstract Syntax"


Overall a useful and worthwhile document. A few review comments... 

Best regards

Stuart
-- 

1) Section 3.1 "Graph Data Model" 1st para: Editorial
Last sentence begins:

"The RDF graph is a set of triples:" suggest s/The/An/

2) Section 3.2 1st Para: (Picky)
Defines "Nodes in an RDF graph are URIs with... literals or blank..." ie.
states that one kind of RDF node is a "URI Reference". I'd prefer to see
language that said that and a node in an RDF graph may be labelled with a
URI reference that denotes/identifies the resource/thing which the node
represents. 

Suggested rewording:
"Nodes in an RDF are either literals, blank (having no separate form of
identification) or labelled with a URI Reference with optional fragment
identifiers."

This has knock on effects on the next two para's which are written with the
tone that (some) nodes in an RDF graph *are* URI References rather the tone
that (some) nodes in an RDF graph are *labelled* with URI References.

3) Section 4.5 Example (Informative): Editorial
Example (B) s/rdf:subClassOf/rdfs:subClassOf/ (I think).

Example (C): are the <> around A:Clown significant or simply a typo?

4) Section 6. Abstract Syntax (Normative)

Prior to section 6 the document consistently uses the terms URI and URI
Reference. This section then switches to using the term "RDF URI Reference".
This feels awkward. Firstly, typical informal usages is for "HTTP URI" or an
"FTP URI" or a "MAILTO URI" to be use to speak of URI scheme specific URI,
hence "RDF URI Reference" is suggestive of an 'rdf' URI scheme which is not
the case. Secondly, the apparent need to prefix the term "URI Reference"
with 'RDF' leads one to ask what distiguishes an "RDF URI Reference" from an
ordinary "URI Reference". Section 6.4 gives some account (more comments on
6.4 below) - which indicates that the authors would probably have preferred
to be using Internationalised Resource Identifiers. It is unfortunate that a
normative spec. for IRI's is not available for normative reference. I think
it would be better for section 6 to either speak of URI References a la
RFC2396 or to anticipate IRI and speak of them instead, in anticipation of
an appropriate work to reference. As is, the term "RDF URI Reference" might
be seen by some as yet another example of RDF taking some well understood
term and using it in a gratuitously different way.

This document needs to decide whether it is dealing in URI or IRI and then
be consistent throughout.

5) 6.1 RDF Triples: (picky)

The 3 bullets use language that indicate that the subject, predicate and
object of an RDF triple may each be an "RDF URI Reference" rather than the
thing that the "RDF URI Reference" identifies/denotes. This is symptomatic
of the same 'complaint' as comment 2) above. It may be a conscious choice of
the WG/Editors to speak directly of nodes and properties being URI rather
than the things that such identifiers denote/identify - just doesn't mesh
with my mental model of RDF (which I'm willing to accept may be flawed).

6) 6.4 RDF URI References: (picky)

Particularly in a subsection on *Abstract* syntax, it seems overly concrete
to speak of NFC and "Unicode string". I'd have expected an "abstract syntax"
to speak of sequences of characters taken from the UCS without speaking of
concrete constraints on their encoding - looking at UCS character sequence
on the side of a bus... is it possible to determine whether they are NFC
(don't know, it may be evident in the transcribed form, in which case I'd
withdraw this comment).

The notes in this section suggest a strong relationship with IRI ("...as
defined by [XML Namespaces 1.1]." I think it would be better for RDF and for
this draft for it to align identifiers with either URI References (as they
are :-( ) or with the emerging IRI specification(:-)).

7) 6.5.1 Literal Equivalence.

It appears that, as written, typed literal equivalence is based lexical
space and not value space comparison. I found this suprising... no-doubt the
WG spend considerable time discussiong whether equivalence of type literals
should be based on lexical or value space comparisons... and I'm not arguing
that this be changed... merely commenting on my surprise on this discovery.

8) 6.5.2 The value corresponding to a typed literal.

I read the last two paragraphs before the note in this section several times
without being able to tell whether or not they say the same thing. I think
they do, and if they don't I can't tell what one says that the other does
not. [Paras beginning "If the lexical form..." and "A typed literal for
which..."].

Equally, I think I have completely missed the point of the note at the end
of the section.

9) Section 7 Fragment Identifiers.

This section (and many others) is not explicitly labelled as normative or
informative (both deginations are used elsewhere). I assume this is an
informative section, but I think it would be helpful to be explicit in this
case rather than leave any doubt.

10) Section 7, 2nd Para: "These apparently conflicting views can be
reconciled by considering that, in an RDF graph, any RDF URI Reference
consisting of an absolute URI and a fragment identifier identifies the same
thing as the fragment identifier does in an application/rdf+xml
[RDF-MIME-TYPE] representation of the resource identified by the absolute
URI component. Thus:..."

This is a hard paragraph to get right and clear. I think is is possible to
both read and mis-read its intent, I certainly did the latter first and on
further re-reading found I could also read it as I think it was intended.
The misreading probably stems from the length of the first sentence and the
phrase "...a fragment identifier identifies the same thing as a fragment
identifier does in an application/rdf+xml representation...". Without the
final clause "...of the resource identified by ther absolute URI component."
it gives the impression that the "fragment identifier" is viewed as occuring
within an RDF/XML document, pointing out (which is backward because the
application/rdf+xml applies to the thing being pointed from (referee) rather
than the thing being pointed at (referent)). However, somewhat late in the
process of parsing the sentence, the last clause switches ends, to it being
a (hypothesised) RDF/XML representation of the referent with the graph as
referee.

I think I have concluded that the sentence does indeed say what I think it
was intended to say, but it does take several readings for it to take on
that meaning.

Received on Wednesday, 12 February 2003 12:31:26 UTC