RE: referendum on httpRange-14 (was RE: "information resource")

> -----Original Message-----
> From: www-tag-request@w3.org 
> [mailto:www-tag-request@w3.org]On Behalf Of
> ext Sandro Hawke
> Sent: 18 October, 2004 21:43
> To: Norman Walsh
> Cc: www-tag@w3.org
> Subject: referendum on httpRange-14 (was RE: "information resource")
> 
> 
> 
> 
> > / Sandro Hawke <sandro@w3.org> was heard to say:
> > [...]
> > | Some of us think that an HTTP "200 OK"
> > | response on a GET or HEAD for some URI means it identifies an
> > | information resource
> > 
> > Yeah, but some people don't think that. There is not consensus on
> > whether or not http://example.com/dog must identify only an
> > information resource. I see no evidence to suggest that any 
> amount of
> > discussion will ever achieve consensus on this point.
> 
> It would be easy for everyone to drop the issue if this were a "coin
> flip" decision, where things work pretty much the same either way, and
> anyone who thorougly studies both sides can see that.  But that's not
> the case here.  Here it seems to each side as if the other side is
> merely ignorant of the big picture, and with a bit of education
> they'll come around.

Not all of us think that way.

I myself consider the 'hash over slash' view to be fully coherent.
I simply do not find it to be *better* than the more agnostic view.

I consider the issue to be decided on deployed solutions demonstrating
greater benefit from one approach than the other.

I've documented, and demonstrated, the problems relating to scalability
of access to secondary resources when URIrefs with fragids are used
and the clear benefits to being able to use primary URIs without fragids
to denote non-information resources.

I've yet to see *any* substantial, demonstrated benefit to real world
web applications based on using URIrefs with fragids.

The only use case where there is clear, proven benefit, and which has
been pointed out previously, is the syncronization of a browser view
to what might be considered a kind of representation of a secondary
resource, per a given representation (of some other resource). I.e.
having your browser sync to an anchor point.

Yet that special use case is *fully* compatible with the more general,
agnostic view. Accepting that a URI without fragid can denote anything
does *not* preclude the use of URIs with fragids where there is clear
benefit for doing so, such as in the above use case. 

Deciding this issue must to be based on actual benefit to applications, 
not only thought experiments or personal preferences for particular
ways of modelling resources.

For those who are 'hash' proponents: 

   Show us the solutions. Show us the benefit.

The bottom line is that the narrower view is predicated on the presumption 
that a URI without fragid *cannot* denote anything but an "information 
resource" yet since it can be demonstrated that that is *not* garunteed 
given existing broadly deployed practice, such a position is simply not 
maintainable, and therfore must be abandoned.

Certain individuals may lament such a state, but that's the state
of the web. 

As I said in another post, the community has *already* decided this
issue. To presume that the TAG or any other body is going to get
a large segment of the web community to declare their successfully
deployed applications as "broken" and reform their systems -- particularly
when the alternative has *known* scalability issues, is (to put it
nicely) unrealistic.

> > | So from a process perspective, having Information Resource defined
> > | turns httpRange-14 into pretty much a Yes or No question, 
> although I'm
> > 
> > I think httpRange-14 is a yes or no question no matter how 
> you define
> > (or even if you bother to define) information resource. The 
> answer is:
> > the community does not agree on what the answer is.
> 
> I dare say the question has never been put to "the community" in a
> coherent way.   Something like this:
> 
>      Try to imagine that each working HTTP URL is the name of some
>      particular conceptual entity.  Some of these entities may be easy
>      to conceptualize, such as a blog or price list, while others may
>      be less obvious.  (What exactly does "http://www.google.com" or
>      "http://www.uroulette.com/visit"[1] name?)

This is an invalid question. *NO* user can know what those URIs name
unless the creator/owner of those URIs *tell* them what they name.

And any guesses about the nature of the resource denoted by a given
URI based on representations one may be able to access via that URI
are just that: guesses.

*That's* why we *NEED* the semantic web!  So that folks can find out
what the @$*&#*! a particular URI names. 

>      Remember that web protocols support format and language
>      negotiation, so that from a single URL you may obtain content in
>      different languages and in different formats, depending on your
>      browser settings and capabilities.  And of course content changes
>      over time.
> 
>      Now the question: are there any generalization you can make
>      about all such entites?  If so, what are they?  What properties
>      do all such entities have?   Can you think of a good name for
>      this class of entities?
> 
>      [1] Visiting this URL results in a redirect to a random other
>      location.

Why don't you ask them this:

   If you have some thing, such as a story, a dog, an event, a
   favorite recipe, your daughter, whatever and you want to tell
   people about that thing, would you find it useful to be able
   to name that thing with a URI such that anyone could enter that
   URI into their browser and obtain information about that thing?

   For those things which are bits of information themselves, such as
   a recipe or a story, you could provide that entire thing to
   others via that URI. For those things which are not information,
   you can nevertheless provide information about them. In either
   case, the same solution and process would be used for all things.

Now ask them:

   What if, instead, you could only use URIs to name and access those
   things which are bits of information, and if you wanted to name and
   talk about other kinds of things, you would need to first conceive
   of and name some bit of information that might include information
   about it, and then use a special form of name for the non-information
   kind of thing, and when folks want to get information about that thing,
   they have to first get some information about another thing, which 
   may include within it some information about the thing in question.

Which do you percieve as the simpler solution?
Which do you thing people will prefer? The simpler, more general,
direct solution, or the more complicated, indirect solution?

Of course, asking such questions is a waste of effort, since folks
are already successfully using the simpler, more general, direct
solution (while allowing as well the indirect solution if so desired).

> I'm also not sure what the community is.   Maybe the W3C AC Reps would
> be fun place to start.  :-)   Call it a W3C Referendum.   Or maybe we
> could try it as a slashdot quick.   Ha!   How many people would check
> "I'm pretty sure Cowboy Neil is a web page" ?

Again, that is an entirely different issue. You could have ambiguity about
the denotation of a URI, even if the URI denotes an information
resource. It could denote a poem, and folks could still incorrectly
presume that it denotes a "web page" because they GET some HTML from 
a server.

> Seriously, I'm writing this while procrastinating about answering this
> for myself in Ontaria.  I need a tab on which to display information
> about any resource for which dereference worked, and I'm not sure what
> users are going to want to see on that tab.  I'm also not sure what to
> call it (ie what the class name is), but I'm leaning towards 
> "Document".

I think the only safe class name would be "Resource".

(unless of course the web authority is URIQA englightened, and you
 MGET an authoritative description that provides a more specific
 classification ;-)

Patrick

Received on Tuesday, 19 October 2004 07:47:38 UTC