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

Jeremy,

Thank you for your responses... a few further comments below.

Best regards

Stuart
--

<snip/>

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

Yes... I believe that document has adopted a consistent position throughout.

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

The wording you reference in the August version is much closer to what I
would have expected, indeed, the notion that literal nodes are labelled by
literals rather than themselves being literals seems more consistent with
URIRef nodes being labelled with, rather than being, URI References.

That said, I am content to know that the WG has discussed this at length and
has made a reasoned choice to adopt the position that it has. I am not
inclined to make an issue. I can also see that with the current definitions,
graphs are inherently tidy (I think) which is nice.

<snip/>

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

Well... in the "Abstract Syntax" are the URIRef nodes 'URI References' or
'IRI References' (or labelled therewith)? Decide and then be consistent (and
yes through the entire family of recommendations)!

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

:-) I'm open to being educated...

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

Ok... I was trying to find a more abstract form of character sequence and
maybe UCS as too concrete a choice.

Looked in Charmod for some further inspiration
(http://www.w3.org/TR/charmod/#sec-Characters) to no avail.

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

The problem being that a given 'presentation string' can have different
multiple encodings... *if* the aim in the abstract is that two visually
identical strings compare equal, then NFC seems like a constraint on a
concrete encoding so that the comparison can be done by comparing encoded
octet sequeuences.

> 
> Do you still wish your comment to be considered?

I guess I could see it both ways - and I did designate this as 'picky'. 

I was really trying to help. The presense of the NFC constraint seem to be
the main inhibitor to making a reference to some other definitive (or
proto-definitive) work.

I will not protest if you choose to resolve this (ie. 6) with no-action.

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

Either (or indeed neither)... as you wish... 

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

Ok... thanks... makes sense, but still feels odd.


<snip/>

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

Agreed... and it may only be me that's stumbled over parsing the sentence.

Received on Monday, 24 February 2003 11:40:53 UTC