- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 27 Mar 2012 19:42:29 -0500
- To: Bernard Vatant <bernard.vatant@mondeca.com>
- Cc: Dave Reynolds <dave.e.reynolds@gmail.com>, Jonathan A Rees <rees@mumble.net>, Jeni Tennison <jeni@jenitennison.com>, public-lod community <public-lod@w3.org>, Leigh Dodds <leigh@ldodds.com>, Ian Davis <me@iandavis.com>
On Mar 26, 2012, at 9:15 AM, Bernard Vatant wrote: > All > > Like many others it seems, I had sworn to myself : nevermore HttpRange-14, but I will also bite the bullet. Hi Bernard > Here goes ... Sorry I've hard time to follow-up with whom said what with all those entangled threads, so I answer to ideas more than to people. > > There is no need for anyone to even talk about "information resources". > > YES! I've come with years to a very radical position on this, which is that we have create ourselves a huge non-issue with those notions of "information resource" and "non-information resource". Please show any application making use of this distinction, or which would break if we get rid of this distinction. > And in any case if there is a distinction, this distinction is about how the URI behave in the http protocol (what it accesses), which should be kept independent of what the URI denotes. The neverending debate will never end as long as those two aspects are mixed, as they are in the current httpRange-14 as well as in various change proposals (hence those interminable threads). > > The important point about http-range-14, which unfortunately it itself does not make clear, is that the 200-level code is a signal that the URI *denotes* whatever it *accesses* via the HTTP internet architecture. That has always been my understanding of the intent of the decision. I think the way that TimBL phrases it, as a choice betweeen the identified resource *being* the meaning (200-code response) or *describing* the meaning (303 response) is basically the same distinction with a cherry on top. > > The proposal is that URI X denotes what the publisher of X says it denotes, whether it returns 200 or not. The problem here is that virtually all publihers don't do this, and there is absolutely no sign that anything more than a vanishingly small percentage ever will. Not to mention there is no accepted way to do this, or to check when it has been done. And, as TImBL reported in a recent email, many people (read: the TAG) want it to be the case that there is a 'default' in such cases, and that it should be that the URI denotes the Web document which it accesses, so that the semantic web can easily talk about the nonsemantic web. > > This is the only position which makes sense to me. What the URI is intended to denote can be only derived from explicit descriptions, whatever the way you access those descriptions. Well, except that in fact you can't do this, as we all know (fix a referent by giving a description). You have to rely on actual ostention at some point, both an and off the Web; and on the Web, existing Web pages are the only contact point for using ostention (ie explicitly pointing to something and saying, in effect, "I'm referring to *that*" > And assume that if there is no such description, the URI is intended to provide access to somewhere, but not to denote *some* *thing*. It's just actionable in the protocol, and clients do whatever they want with what they get. It's the way the (non-semantic) Web works, and it's OK. > > And what if the publisher simply does not say anything about what the URi denotes? > > Then nobody knows, and actually nobody cares But people do care, see above. > what the URI denotes, or say that all users implicitly agree it is the same thing, but it does not break any system to ignore what it is. Or, again, show me counter-examples.. TimBL has many. > > After all, something like 99.999% of the URIs on the planet lack this information. > > Which means that for the Web to work so far, knowing what a URI denotes is useless. But it's useful for the Semantic Web. So let's say that a URI is useful for, or is part of, the Semantic Web if some description(s) of it can be found. And we're done. > > What, if anything, can be concluded about what they denote? > > Nothing, and let's face it. > > The http-range-14 rule provides an answer to this which seems reasonably intuitive. > > Wonder if it can be the same Pat Hayes writing this as the one who wrote six years ago "In Defence of Ambiguity" :) http://www.ibiblio.org/hhalpin/irw2006/presentations/HayesSlides.pdf > Quote (from the conclusion) > "WebArch http-range-14 seems to presume that if a URI accesses something > directly (not via an http redirect), then the URI must refer to what it accesses. > This decision is so bad that it is hard to list all the mistakes in it, but here are a few : > - It presumes, wrongly, that the distinction between access and reference is based > on the distinction between accessible and inaccessible referents. > ... [see above link for full list] > > Pat, has your position changed on this? Not on the ambiguity point, but yes on http-range-14. I still dislike it wholeheartedly and I wish there was some other way to go, but I can see that it is useful and relatively simple and enables people to move forward, and it seems to kind of work. Maybe this (or some other) way will work better, and I will be delighted. > > What would be your answer? Or do you think there should not be any 'default' rule in such cases? > > I would say so, because such a rule is basically useless. But it is very useful indeed for using RDF as metadata talking about Web pages. And for the rest, I will just use hash IRIs and ignore this entire discussion :-) Pat > As useless as to wonder what a phone number denotes. A phone number allows you to access a point in a network given the phone infrastructure and protocols, it does not denote anything except in specific contexts where it's used explicitly as an identifier e.g., to uniquely identify people, organizations or services. Otherwise it works just like a phone number should do. > > Best regards > > Bernard > > -- > Bernard Vatant > Vocabularies & Data Engineering > Tel : + 33 (0)9 71 48 84 59 > Skype : bernard.vatant > Linked Open Vocabularies > > -------------------------------------------------------- > Mondeca > 3 cité Nollez 75018 Paris, France > www.mondeca.com > Follow us on Twitter : @mondecanews > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 28 March 2012 00:43:04 UTC