Towards a position of neutrality on issue httpRange-14 for AWWW (was RE: referendum on httpRange-14 (was RE: "information resource"))

Hi Noah,

I find your comments very encouraging, that we might see
progress made on AWWW as it reflects existing concensus
rather than continue to see the TAG "spin its wheels", so to 
speak, trying to force AWWW to address the httpRange-14 debate
in any widely acceptable fashion.

I agree that this particular debate should not further 
confuscate the TAG's progress on AWWW and should be set
aside for the time being.

I would be content, at this juncture, to see AWWW reach a stable,
mature state without explicitly addressing issue httpRange-14,
provided that AWWW does not otherwise include content which
illustrates or favors one side of that issue but not the other.

If the TAG is trully in agreement about proceeding in a manner
which is neutral to issue httpRange-14, insofar as AWWW is
concerned, then I offer the following comments and suggestions,
per http://www.w3.org/2001/tag/2004/webarch-20041019/:

--

The inclusion of the definition of "information resource"
(albeit imperfect) is reasonable, as the mere presence of a
definition of such a class of resources does not, or at least 
should not, imply that the range of resources which http: URIs 
(or any other form of URI) can identify is constrained solely 
to such a class of "information resources". 

(though, IMO, the definition could be completely omitted without
AWWW incuring any notable loss of utility or coherence)

It should not be suggested however, implicitly or explicitly, by
AWWW that such a class of information resources is an essential
component of the web architecture itself, significant to the actual 
functioning of the web machinery -- as it has been demonstrated that,
for the general model side of the httpRange-14 debate, it is not; and
therefore to suggest any such thing is to favor one side of that
debate over the other.

--

Furthermore, examples which can be deemed to promote the use of URIrefs
with fragment identifiers to identify non-information resources,
such as in section 4.5.3 of the latest draft, either should be removed, 
made neutral, or expanded to provide equal presentation of both sides 
of issue httpRange-14.

I propose modifying such text to make the examples neutral to
the debate, e.g. for the example in section 4.5.3:

   "For flat namespaces, concatenation is one useful mapping. If namespace 
    URIs that end with a hash ("#") are chosen, then simple concatenation 
    of the namespace URI and the local name creates a URI for a secondary 
    resource (the identified term). This technique is used for many [RDFXML] 
    namespaces."

change the text to something akin to:

   "For flat namespaces, concatenation is one useful mapping. The simple 
    concatenation of the namespace URI and the local name creates a URI 
    for the identified term. This technique is used by [RDFXML]."

This revised text is compatible with either side of the httpRange-14
debate and hence fully neutral while still providing the intended
utility.

--

In general, examples containing fragment identifiers where the 
presence or absence of the fragment identifier is not significant 
to the utility of the example, should be revised to use URIs without
fragment identifiers.

E.g. in section 2.2, change 

   "http://example.com/somepath#someFrag"

to 

   "http://example.com/somepath" 

since the presence of the fragment identifier is not essential for 
providing the necessary utility of that particular example, and in
fact, may actually confuse the reader since the example is used to
reflect the signficance of a URI to the HTTP GET method, yet
fragment identifiers are irrelevant to GET requests.

--

Of course, many examples containing fragment identifiers such as in 
sections 2.6, 3.2.1, 3.2.2, 4.5.8 etc. are perfectly acceptable and
necessary and do not illustrate or favor either view of issue 
httpRange-14; and thus do not require (nor can allow) modification.

--

The TAG may also wish to examine forms of expression such as
in section 4.4:

   "When one resource (representation) refers to another resource with 
   a URI, this constitutes a link between the two resources."

as potentially suggestive of the nature of the referring resource (since
one can concieve of an information resource referring to another resource
but not a non-information resource necessarily doing so). 

As it is actually the representation that is doing the referring, stating 
this in a more neutral, and also a more precise, manner would be advisable. 
E.g. change the above text to:

   "When the representation of one resource refers to another resource 
    with a URI, this constitutes a link between the two resources."

etc.

--

I've not gone through the latest draft of AWWW with a fine toothed comb 
and the examples presented above do not constitute any kind of exhaustive
summary. I think the kinds of "neutralizing" changes illustrated 
about should (hopefully) be clear enough to the editors, and I
leave the application of such neutralizing changes to editorial
discretion.

Regards,

Patrick



> -----Original Message-----
> From: ext noah_mendelsohn@us.ibm.com 
> [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 20 October, 2004 17:38
> To: Stickler Patrick (Nokia-TP-MSW/Tampere)
> Cc: Norman.Walsh@Sun.COM; sandro@w3.org; timbl@w3.org; www-tag@w3.org
> Subject: RE: referendum on httpRange-14 (was RE: "information 
> resource")
> 
> 
> Patrick Stickler writes:
> 
> > Forced indirect access to representations via
> > URIrefs with fragment identifiers is inefficient
> > and non-scalable. Yes, it can work in some cases,
> > for some applications, for some data. But it is
> > *not* a scalable solution for the future of the
> > web and semantic web.
> 
> With the caveat that I'm still coming up to speed in this 
> long-running 
> debate and have not formed firm opinions, I have some 
> sympathy with the 
> particular statement above.  There is at least conceptual and perhaps 
> operational overhead in requiring that one resource be indirectly 
> identified as secondary to another, unless that relationship 
> is for other 
> reasons natural.    That doesn't by any means settle the httpRange-14 
> question, but I agree with the point taken in isolation. 
> 
> That said, my understanding is that the TAG has in Basel 
> suggested a way 
> forward, documented in the draft minutes at [1].  Specifically: 
> 
> "RESOLVED: to drop [I.e. from the Architecture Document 
> draft...Noah] the 
> HashSlashDuality text (section 2.2.1 and descendants in a 
> draft that was 
> projected) and use as input to finding on HTTPrange-14, DC, TBL 
> abstaining. ACTION DC: with Norm, develop a finding on httpRange-14 
> starting with the HashSlashDuality text"
> 
> I suggest that many of the important points on both sides of 
> the debate 
> have been made (perhaps more than once?) in this email 
> thread, and thus my 
> preference would be to back-burner the email  discussion until some 
> progress is made on a draft finding.  Then we'll have 
> something concrete 
> to debate and tune. 
> 
> Noah
> 
> [1] http://www.w3.org/2001/tag/2004/10/05-07-tag#infores234
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
>

Received on Thursday, 21 October 2004 10:19:38 UTC