Re: RDFCore WG minutes for the Telecon 2002-07-12

I hope this doesn't seem like jumping into something that's none of my 
business, but I have some comments on this (below):

Graham Klyne wrote:

> 
> At 05:35 PM 7/23/02 +0100, Dave Beckett wrote:
> 
>> >>>Graham Klyne said:
>> > At 09:42 PM 7/16/02 +0100, Dave Beckett wrote:
>> > >Move 6.4 into syntax - DaveB: already there, not needed.
>> >
>> > I'd like to push back a little on this decision.
>> >
>> > First, I note that the text concerned doesn't repeat material in the 
>> syntax
>> > draft, but refers to that material.  The reason I feel the text 
>> should stay
>> > here is because the syntax document (reasonably) places very heavy 
>> emphasis
>> > on the process of parsing RDF, and may be inaccessible to readers 
>> who are
>> > not concerned with parsing issues, yet this point may be of some 
>> concern to
>> > them.  The text concerned is quite short:
>>
>> The syntax doc does have sections for introducing the syntax which is
>> *not* related to parsing.  It takes a graph and explains how the
>> RDF/XML for it is built, and will cover more of the detail of the XML
>> syntax.  That isn't for parser writers but for explaining how the XML
>> syntax works, and all the little corners.
>>
>> Furthermore, the later section from turning a graph to RDF/XML, also
>> sometimes called serialising the graph, is also not for parser writers.
> 
> 
> What you say is, of course, quite true.  But it remains my perception 
> that this document is overwhelmingly concerned with detailing the 
> minutiae of mapping between XML syntax and the abstract graph syntax.


Sounds like exactly what the syntax document is supposed to be about 
though, right?


> 
> As you say, it explains how the syntax works, including all the little 
> corners.  Yes, there is other information here, but that's not clear 
> from cursory glance at the document.  For example, I just went to the 
> online copy of this document to try and work out where the QName to URI 
> correspondence was described, and it took me about 5 minutes to find 
> it.  The table of contents didn't help me on this point, and if I didn't 
> know if was here somewhere I might have failed to find it.


If you're referring to section 3.6, it took me about a second;  you plug 
"qname" into whatever your browser uses for "find in this document", and 
go through the places it finds (I think it was like the second one).


> 
>> > [[
>> > 4.3 Forming a URI reference from a Qname
>> >
>> > The RDF/XML syntax uses QName syntax [XML-NS] to identify various
>> > resources, notably RDF properties. But the RDF graph syntax contains 
>> only
>> > URI references, and does not recognize QName forms.
>> >
>> > Mostly, the handling of QNames is a matter for RDF parsers. But 
>> there are
>> > some occasions where an RDF writer needs to know the correspondence 
>> between
>> > QNames and URI references (e.g. when using a typed node production). 
>> The
>> > mapping is described in [RDF-SYNTAX], sections 3.1.2 or 3.1.4.
>> > ]]
>>
>> That says both too little and too much.
>>
>> It doesn't explain what an RDF parser is, or what an RDF writer is.
>> Neither of those is mentioned in the syntax doc either - we only talk
>> about the graph and the rdf/xml document[infoset].   This sounds like
>> RDF processing which we have avoided doing.
> 
> 
> OK - that can be easily fixed.
> 
>> What are QName forms?  I prefer 'XML qnames" [citing reference in XML].
> 
> 
> OK - that can be easily fixed.
> 
>> The subject of the section is "Forming a URI reference from a Qname"
>> but the words doesn't explain how this is done, so why is it here?
>> Either you should add this detail, and remove it from the syntax
>> document, or remove this section.
> 
> 
> You use the term "should" here without explaining your criteria, so I 
> cannot really agree or disagree with what you say.
> 
> I'm coming to this with the view that we should be making it as easy as 
> possible for developers (programmers, software designers and information 
> designers) to find the information they need.  I think that a key reason 
> for RDF not being especially successful to date, and I do find a 
> continuing reason for resistance to adopting RDF rather than 
> roll-your-own XML, is that smart people just don't get it.  If we want 
> RDF to really succeed, part of our job is to make it easy for people to 
> get it when they look at the specs.  The kind of audience I'm thinking 
> of here are experienced system architects who will make key decisions 
> about system design choices, without necessarily delving into all the 
> details of the specifications.  I say all this to explain the kind of 
> criteria I am applying, and why in my opinion it is important to call 
> out certain key features of RDF.


In the US, we'd say this was a "Motherhood and Apple Pie" statement.  I 
hope you don't think anyone disagrees with these aims (even in writing 
the existing documents).  The issue isn't a disagreement about aims, 
it's whether a particular document structure helps us address these 
aims, right?


> 
> In this case, I think the relationship between XML Qnames and URIs is 
> such an important feature.  The relationship is described in the syntax 
> document, but I found it was not easy to find.  So I feel it is 
> appropriate to call out the issue and provide a precise reference to 
> where the detail is defined.  Maybe there are other ways of achieving 
> this goal - for example, I'd say a heading in the syntax document table 
> of contents containing the word Qname might do it.


I agree that this relationship is important, but it seems to me that one 
of the questions to be answered here is where anyone would naturally go 
to find the answer.  It seems to me they would naturally go to the 
syntax document (that's certainly where I went).  If the answer is in 
the syntax document, but not easy to find, then it seems to me what 
should be done is to make the answer clearer and/or easier to find in 
the syntax document.  It's not clear to me that providing this 
information in a separate document is necessarily going to make things 
easier to find (even for newcomers to the specs).

To make a more general point:  If you wanted to find the answer to a 
specific question about RDF, and all the information was in *one* 
document, it might be difficult to find the information in that 
document, but you'd at least know which document to look in.  As it is, 
we have a collection of documents.  That already increases the 
difficulty of finding things, since now you have to pick a document, and 
*then* find (hopefully) the information in that document.  Adding 
another document doesn't necessarily simplify that process, particularly 
when the added document only covers *some* things, in varying degrees of 
detail.  I think this is something to consider very carefully in 
determining the content of the new document.

PS:  This is also going to be covered to a certain extent in the Primer 
(some of it is covered already).


> 
>> I think such XML syntax issues (graph to/from RDF/XML), and XML
>> qnames are best handled where the rest of the XML issues are
>> explained, in the RDF/XML syntax document.  These can then be linked
>> to the syntax grammar, examples and the appropriate test cases.
> 
> 
> Well, in a sense I agree with you, which is why I didn't try and 
> duplicate the material.
> 
> But... (see above).
> 
> #g
> 
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> 


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Wednesday, 24 July 2002 09:30:25 UTC