Pat Hayes wrote:
> At 9:08 PM -0600 4/12/08, Michaeljohn Clement wrote:
>> Xiaoshu Wang wrote:
>>> Michaeljohn Clement wrote:
>> Your redefinition of "resource" and "representation" to me is a new
>> re-invention of the Web.
>
> Its not a RE invention. Nothing about the current Web changes at all: it
> allows for a new way of using some existing Web technology, is all. This
> way is rational and seems to conform to the current architecture,
> provided we are willing to think a little outside of our current box.
We may have different perspectives on where the borders of our
respective boxes and of the architecture are, so this may beg the
question.
The architecture of the Web is somewhat socially determined and is
not necessarily all very well specified, nor necessarily can it be,
so it is in some cases difficult to say where the borders of one's
experience and expectation may be obscuring the true boundaries of
"the current architecture".
> And this might come as news to non-semantic Web mavens, but wa are
> already outside that box. We've been outside it ever since the TAG
> insisted that URIs can identify non-information things.
Indeed. For HTTP URIs I would be much more comfortable had that
particular cat been left in the bag, but such is life.
>> Let me ask the question differently: Do you believe the ability to
>> make statements about Web pages, simply identifying the page by its
>> URI, is worthwhile?
>
> Yes, that is worthwhile.
>
>> Your way of looking at (or redefining) the Web would lose that
>> capability.
>
> NO IT WOULD NOT. This is false. All it would do is move the
> responsibility of deciding what a URI denotes from a rather messy and
> widely ill-understood distinction based on http codes, to a matter of
> content negotiation.
Here's how I see it:
(P1) We are in this unfortunate situation in which it is now
considered legitimate for HTTP URIs to identify, e.g.,
the moon.
(P2.a) I would prefer to be able to write or use simple Semantic
Web tools to make statements about Web pages.
(P2.b) I would prefer to do this by using the URI of a Web page
as an identifier of that page. Such usage seems, to me,
simple, obvious, natural, correct, and indeed precisely
within the purpose for which the HTTP URI formalism was
created.
Because P1 holds, I cannot simply assume that any given HTTP URI,
even one that loads up a page in my browser, actually indentifies
that page. That makes P2.b no longer always correct, and P2.a
becomes more difficult.
Because of httpRange-14, however, any HTTP URI (sans fragment
identifier if any) which returns a 200 status code when
dereferenced, can be used for my (P2) purposes.
So, even if only by "pushing the problem to a smaller corner of the
architecture" as someone has said, httpRange-14 admits the simple,
broad ability to make statements about existing Web pages in a
collaborative way that I'm interested in.
> This would allow phenomena which violate
> http-range-14, but it would by no means insist on such violations in all
> cases.
But it renders incorrect the reliance on the most obvious relationship
between a URI and an ordinary Web page, which is what httpRange-14 gave
back, and which I find valuable.
When I said it would "lose that capability" what I meant was that it
would lose the ability to take that as given.
> In fact, if we were to agree on some simple protocols for content
> negotiation which themselves referred to http codes, it could provide a
> uniform mechanism for implementing the http-range decision.
Then we rebuild the existing Web to conform to this? Or do you mean
an implementation of, or alternative to, httpRange-14 which would
preserve the simple usage in a majority of cases?
>> ither the URI from which you get a 200 OK response
>> identifies an information resource, in which case we can make
>> statements about it, or it does not in which case we cannot any longer
>> make statements about the page by using the URI.
>
> Nonsense.
Granted, but please take it in the spirit of what I stated more
explicitly above.
> There is also the possibility of using some other URI to refer
> to it, for example by asserting explicitly that URI-1 refers to the
> thing identified by URI-2, perhaps using RDF to do the asserting.
Yes, of course.
> Again,
> I'm not suggesting that this would be required, or even a very common,
> situation; but it would be possible.
How would we know when it is required and when not, without httpRange-14?
Would we have a decision criteria that gives an unambiguous answer
for the bulk of the 200-returning Web out there?
> Moreover, this approach would put
> 'information resources' on exactly the same footing as all other things
> in the matter of how to choose representations of them for various
> purposes,
Yes. At issue is whether information resources are central enough to
the operation of the Web that they deserve to be privileged above all
other things in how we can identify them using HTTP URIs.
> a uniformity which means little at present but is likely to
> increase in value in the future.
A future in which such uniformity could co-exist with the
simplicity I'm interested in would be worth working for.
>> If you are doing that
>> then I must say that is not what conneg is for, and it matters because
>> the expectations of many others will break.
>
> It matters that we all agree on expectations, of course. But I really
> dislike the tone of pronouncements like "not what conneg is for". Who
> has the authority to say what conneg is for? All this means is "not what
> conneg has been used for until now".
Point taken, but...
> Conneg is just machinery, and we,
> as a society, can use for whatever we decide and find convenient.
It's just that my understanding was that we had already determined what
it was for, and that this was well known.
> The
> Web and the Internet are replete with mechanisms which are being used
> for purposes not intended by their original designers, and which are
> alien to their original purpose. For a pertinent example, the
> http-range-14 decision uses http codes in this way. That isn't what http
> codes are for.
Indeed. However I'm not sure that the layering of meaning onto HTTP
status codes has quite the same far-reaching effects on deployed
software, or on expectations, that this use of conneg would have.
Michaeljohn