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

At 09:40 AM 7/24/02 -0400, Frank Manola wrote:
>I hope this doesn't seem like jumping into something that's none of my 
>business, but I have some comments on this (below):

As a working group member, it's entirely your business :-)  Fire away!

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

Absolutely.  I hope my comments don't appear to be criticisms of the syntax 
document.

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

Mechanical search doesn't work on printed copy.  And it depends on knowing 
the exact keyword to enter.

This isn't scientific, but I was trying to illustrate that when covering 
information at the level of detail required for the document's purpose, 
some of the larger picture can become obscured.

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

Well, I'm not sure that everyone agrees.  I sense that some folks may feel 
it's OK if you have to read an entire specification end-to-end in order to 
extract the high-level information.  That is how I interpret the 
"traditional" approach to specification writing - which seems to hold that 
a specification should contain exactly its normative technical content, 
without repetition or deviation (or ...).  I come from a viewpoint that it 
is helpful for specifications to contain a limited amount of pedagogical 
material to help experienced readers see how the specification relates to 
their application.

Also, it's not all "Motherhood and Apple Pie" in that the statement above 
contains reference to real resistance I have experienced (recently) to 
adopting RDF, partly through unwillingness to seriously consider RDF.  To 
the extent that we make potential users work to find the key high-level 
information, I believe we exacerbate that problem.


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

I acknowledge that.  Indeed, I already suggested that as a possibility in 
the message to which you replied:
[[
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 was responding to a statement to the effect of "delete this, and no 
change is needed in the syntax document".

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

Again, still, I agree.  I think I have consistently been supportive of 
moving material to other documents where it may seem to sit more comfortably.

...

And generally (to everyone):  I'm not hell-bent on a particular outcome 
here.  I'd like our documents to be "Motherhood and Apple Pie".  To the 
extent that I feel there are issues of ease of access that we can 
constructively discuss, I may continue this discussion.  But if the group 
wants to make a decision and move on, please just say so.

I placed some text on the table and am trying to explain why I did it that 
way;  the issues are clearly subjective and we may find over-long debate 
isn't helpful.  As a proposer, I had an opinion;  as a document co-editor I 
am the working group's servant.

#g


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

Received on Wednesday, 24 July 2002 10:13:17 UTC