ACTION 2001-10-12#5: frankm respond to gk text

This action is to discuss some problems that *I* had with the text that 
appeared in the agenda for the anonymous nodes issue (I'm only speaking 
for myself;  others may have other issues).  For reference purposes, 
this text, that appeared in the agenda for the 2001-10-12 meeting, 
circulated on Oct. 11, is as follows:

> 12: Issue: Identity of anonymous resources
> PROPOSE the WG RESOLVE
> 
> 1. Resources that are described but not named in an XML serialization (by 
> rdf:ID or rdf:about) are represented in an RDF abstract graph by nodes that 
> do not have any associated URI.  Such nodes, called bNodes (from blank 
> nodes) are thereby distinguishable from other described resource nodes, 
> which do have an associated URI-reference label.
> 
> To directly address the question of the issue:  a so-called anonymous 
> resource has no URI.
> 
> 2. To reflect un-named descriptions in N-triples, local names must be
> introduced (i.e. of the form '_:name').  These names are not URIs, and
> their scope is the N-triples document in which they appear.
> 
> 3. In the defined use of RDF to express ground facts, the meaning of bNode 
> is to assert the existence of at least one resource which is the subject 
> and/or object of properties as indicated by the graph.  This is covered 
> more formally by the Model Theory [3], section 2.  See also the anonymity 
> lemmas in section 3.2.
> 
> NOTE:  it has been proposed that the RDF graph syntax can be used for form 
> a query, in which bNodes may be interpreted as query variables.  This 
> resolution confirms that bNodes can be distinguished from other labelled 
> nodes within the graph syntax, but is silent about if and how the graph 
> syntax might be used to represent a query.
> 
> This resolves specific questions in the original issue raised thus:
> 
> [1.] Should anonymous resources have URI's?
> -- No (point 1 above).
> 
> [2.] If so, should they be clearly distinguishable as parser generated URI's?
> -- Not applicable:  the parser is not required to generate URIs.
> 
> [3.] Should there be a standard algorithm for generating URI's which ensures
>   that different parsers generate the same URI's from the same source
>   input document?
> -- No:  the parser is not required to generate URIs.
> 
> [4.] How might these automatically generated URI's be affected by changes
>   in the source document?
> -- There no automatically generated URIs to be affected.
> 

Paragraphs 1 and 2 above were essentially those that appeared in 
Graham's message of 10 Aug 
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Aug/0030.html.
Those two paragraphs, plus paragraph 3 and the following NOTE, appeared 
in Graham's message of 2 Oct
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0028.html
That same text also appeared in Brian's message of 9 October adding the 
item to the Oct. 12 meeting agenda.

I have no problem with any of that text.  What appears to me to be 
problematic is the concatentation of that text with discussion of how it 
presumably resolves the specific questions raised in the original issue. 
    The first time this latter text appeared was in a message sent by 
Graham on Oct. 10 
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0147.html.

I unfortunately did not have time to read this last message (or the same 
text which appeared in the agenda) in detail until just before the 
teleconference.  I'm sorry about that, but not sorry about not having 
raised any questions before Oct. 10 about text which did not appear 
before Oct. 10.

The text that discusses how the resolution of the anon-resources issue 
addresses the specific questions raised in the issues list entry 
certainly correctly quotes those questions, but it addresses them in a 
very "literal" (if you'll pardon the expression) way.  That is, the 
original questions in the issues list discussed "generated URIs", and 
the agenda text basically says there aren't such things as generated 
URIs, so all questions about them are essentially non-issues.  However, 
our explanation in the agenda text also says (in effect) that instead of 
"generated URIs" there are "local names that must be introduced", i.e., 
"generated names that aren't URIs".   So if the point of approving the 
text is that the text will serve to explain our decision to people 
reading the issues list, I don't think it's as clear as it might be in 
addressing the original questions, since the text addresses (if you 
will) the syntax of the questions, but not the semantics.

Since what we were asked to approve was (as I understood it) *that 
text*, I said I had some problems with it.  That is not the same as not 
agreeing with what we decided at the F2F about this issue, or what 
Graham had written in previous messages (I will amplify on that point a 
bit later).

A clearer explanation of how our resolution affected the questions that 
were originally raised would explicitly address the existence of the 
locally-generated names we talk about (at least in Ntriples), and would 
go something like this:

"This resolves specific questions in the original issue raised thus:

[1.] Should anonymous resources have URI's?
  -- No (point 1 above).  However, they are assigned local names, of the 
form '_:name'.  These names are not URIs, and their scope is the 
N-triples document in which they appear.

[2.] If so, should they be clearly distinguishable as parser generated 
URI's?
  -- Stricly speaking, the parser is not required to generate URIs.  The 
parser *is* required to generate local names (that are not URIs) for 
anonymous resources. These names *are* distinguishable from URIs.

  [3.] Should there be a standard algorithm for generating URI's which 
ensures that different parsers generate the same URI's from the same 
source input document?
  -- Once again, the parser is not required to generate URIs.  There is 
also no requirement that parsers use a standard algorithm for generating 
local names for anonymous resoures that ensures that different parsers 
generate the same local name from the same source input document, since 
these names are for purely local use.

   [4.] How might these automatically generated URI's be affected by 
changes in the source document?
  -- There are no automatically generated URIs to be affected.  Changes 
in the source document might require the re-generation of local names 
for anonymous resources that appear in the document, but since these 
names are purely local, they can simply be re-generated by re-parsing 
the changed document."


Now to address some issues Dan raises below.  Obviously I'm addressing 
them as if Dan's comments were addressed specifically to me, but I'm 
perfectly prepared to wear that shoe if it fits.

Dan Connolly wrote:

> 
> We could be just about done... or very much further along...
> if folks put a bit more value on building consensus
> and less on tearing it down.

> 
> For example, take item "12: Issue: Identity of anonymous resources"
> from today's agenda. That issue was discussed thoroughly
> and decided at the ftf meeting: the meaning of
> 	<rdf:Description>
> 		<dc:title>ABC</dc:title>
> 		<dc:date>2001-04-23</dc:date>
> 	<rdf:Description>
> 
> is: "there is something whose title, in the dublin core sense,
> is ABC, and whose dc:date is 2001-04-23."
> 
> From the record:
> 
>   "The WG agreed that nodes in an RDF graph arising from
>   description elements without and rdf:about or an rdf:ID
>   attribute can be distinguished from nodes that had such an
>   attribute."
> 	-- http://www.w3.org/2001/sw/RDFCore/20010801-f2f/
> 
> We have since clarified that in excruciating mathematical
> detail in the model theory; we have demonstrated several
> pieces of software that implement RDF this way... software
> that, in fact, implemented RDF that way on the basis
> of the original RDF 1.0 recommendation, before the WG
> decided to clarify it exactly this way.
> 
> After the publication of the model theory, just to tidy
> up the issues list, Graham dotted the last i's and
> crossed the last t's by writing up a resolution; first
> on 10 Aug
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Aug/0030.html
> and then refined it 2 Oct
>   http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0028.html
> Art contributed test cases.
> 
> Since the substantive discussion at the ftf, noone
> has objected to the the way bNodes are handed in the MT draft,
> nor to either of Graham's resolutions.
> 
> The chair put it on the agenda. By all indications,
> this should have been a simple "any objections? hearing
> none, so ordered" sort of decision.
> 
> But folks objected. Folks that
> were at the ftf meeting; folks that had every opportunity,
> over the last month or so, to object to the MT draft
> and/or either of Graham's resolutions.
> 
> Indeed, if that's the way we conduct business, who
> knows how long it will take us to close all the issues?
> 


I certainly am in favor of "building consensus, and not in "tearing it 
down."  And certainly if the question had been put to me as to whether I 
  agreed with our original consensus on anon resources as we decided it 
at the F2F, and in Graham's first two messages, I'd have agreed.  But 
that wasn't what we were asked to agree to.  We weren't asked to agree 
to some general notion of consensus on this issue, we were asked (or, at 
least I thought I was being asked) whether we had any problems with some 
specific words.  Words, I should point out again, which were not in the 
earlier discussions that Dan refers to.  Well, I did have some problems 
with those words;  and I've explained why in the first part of the 
message;  and I think that the additional points I've covered in my 
suggested revision might make some things clearer to anyone interested 
in what we think about anon resources.


Now, I don't think that sort of clarification constitutes "tearing down 
consensus".  Nor does worrying about the actual words we're going to 
convey to our audience, as opposed to general ideas of "consensus" we 
may have in our heads, constitute "tearing down consensus".  The only 
way we can convey any consensus we have in our heads to readers of our 
specs or our interest email lists is if we take some trouble to write 
the words that express that consensus down accurately and completely. 
Our model theory goes a long way toward doing that.  So does any 
explanatory text we write in the issues list, and in our other 
documents, *provided it's accurate*.  Graham did a good job in 
summarizing our resolution of this particular issue.  But I thought the 
way his last version addressed the specific questions raised in the 
original issue needed some amplification *in order to make our consensus 
clear*.

One thing that *does" "tear down consensus", in my opinion, is if people 
are going to assume that general consensus on an issue is the same as 
what some specific words that try to describe that consensus happen to 
say, and then get all hot and bothered about people who think those 
things aren't necessarily the same. If you want to ask for agreement or 
disagreement with specific text, that's OK, but you had better take any 
disagreement with the text as *disagreement with the text*.  If what you 
want is agreement or disagreement with a general "consensus", that's OK, 
but that's *not the same thing*.  (I'd also say at this point that I did 
try to get some clarification of exactly what we were voting on).  If we 
weren't going to bother about what the text before us actually said (or 
didn't say), what was the point of asking Graham to produce it in the 
first place?

--Frank

-- 
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 Friday, 12 October 2001 19:13:21 UTC