Re: Last Call comments on "Concepts and Abstract Syntax"

WG: 
[[ WG process
Graham please comment on (1) (10)
Other editorial issues not needing a formal ID or WG
consideration
  are (3) (8) (9)
but we should make sure they don't get lost
please assign me an action on (8) to track down what text we
intended to publish.

Brian please assign three ids for 
  (2) urirefs: nodes or labels
  (4,6) s/uriref/IRI/
  (5) subj/pred/obj terminology
       (if we currently have not got an ID assigned
        for this one)

(There may be more, depending on response to this
message).
]]

Hi Stuart

this message is simply a first pass on your comments.
Some I accept, some I suggest adding to the LC issue
list, others I discuss and look for your response.


> 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/

Graham, are you happy to accept that as an editorial 
improvement?

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

The issue of whether the nodes in the graph are labelled
with uri references and/or literals or *are* uri references
or literals has been discussed a number of times by the WG.
Your suggestion here is different from any of the combinations
we have discussed:
 that literal nodes are literals
 that uri reference nodes are labelled with uri references

I am glad that the comment was not that some parts of the
document took one point of view, and other parts the other.

It would be helpful to the WG if you advocated a change
with more force than "I'd prefer to see ...", or 
alternatively withdrew this. The WG has at different times
considered different wordings, and so far preferred the
current wording over alternatives
(see for example the wording in:
http://www.w3.org/TR/2002/WD-rdf-concepts-20020829/#section-Graph-Node
)

Partly we have found it advantageous to not need
a discussion of tidiness.


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

Correct, thanks, accepted.
> 
> Example (C): are the <> around A:Clown significant or simply a typo?

A typo, accepted thank you.

> 
> 4) Section 6. Abstract Syntax (Normative)
Brian: name of issue is "s/URIref/IRI/"
> 
> 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.

As you have understood the definition of an RDF URI reference
is intended to be an IRI as understood by XML Namespaces 1.1.
We could reference XML Namespaces 1.1 directly.

Is your preferred change to globally substitute URI reference for
IRI throughout the RDF recommendations? Or did you have something
less extensive in mind?

A further technicality is to do with Unicode NFC.
The Namespace 1.1 defn does not mention this,
although it is implicit in as much as Namespaces 1.1
is understood within the context of XML 1.1,
in which all attribute values must be in NFC.

The RDF specs, structured differently, cannot
piggy back such a feature on XML 1.1 which is
not assumed by RDF. (In fact RDF Concepts tries
hard not to assume XML but is intended to be
open to languages like N3).


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

Aspects of this problem have been discussed by the 
WG on the 7th Feb.

We are trying to clearly distinguish discussion of the
syntactic structures (triples nodes urirefs) from discussion
of the semantic concerns (statements and resources).

However, there are numerous editorial errors which we
are currently trying to fix.

This seems extensive enough to require an issue ID.
Brian is there one already?

However, if the proposal in item 8:

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Feb/0073.html

does not address your issue then we will need to give
this further consideration.
Please indicate whether the planned editorial correction
to uniformly use the syntactic language you did not like meets 
your comment.


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

I take that as an invitation to educate and advocate the
current solution.

AFAIK, on the side of a bus NFC and NFD strings are identical.
However a sequence of characters from the UCS may be in NFC
or may not be.
As an example an e acute as a single character in the UCS
is transcribed identically to an e followed by a non-spacing
acute accent (two characters in the UCS).

Motivating examples for this constraint are found in:
http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-charmod-uris/error001.rdf
http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-charmod-uris/test001.rdf

The two tests when viewed with an appropriately Unicode aware
tool (I have found Internet Explorer adequate), appear to 
be using the same URIref as the subject of the triple in
each file.

This problem is independent of the method of transcription
of the unicode string, and hence seems appropriate for 
an *abstract* syntax.

Do you still wish your comment to be considered?

> 
> 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(:-)).

(This was my reading of (4))
Do you prefer the WG to consider two issues:
- s/URIref/IRI/
- drop term "RDF URI reference"
or is it OK to conflate the two?

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

a)
The motivation is that the concepts document is about
syntactic structures not their meaning. The meaning is
found in the semantics doc.

b)
A second motivation is the open world assumption.
We wish to permit user defined datatypes which are
not universally understood; hence we need some
definition of what an RDF system should do for
an unrecognised datatype.
We also do not wish to forbid RDF implementations
that are datatype unaware, or only partially
implement XML Schema Datatypes.

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


Yes - that's a typo - looks like a cut and paste error.
Accepted 
(I remember the WG agreeing which of these two it prefered
but I don't remember which - one was meant to be deleted).
One or other paragraph will go. Do you want to hear back on
this (i.e. should we assign an issue ID?)

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

I believe we intended it as informative.
Accepted.

> 
> 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.
> 
I will leave this one to Graham, too. It looks editorial.

Received on Thursday, 20 February 2003 11:48:43 UTC