- From: Mark Baker <distobj@acm.org>
- Date: Wed, 24 Apr 2002 09:58:20 -0400
- To: Miles Sabin <msabin@interx.com>
- Cc: www-rdf-interest@w3.org
Re disambiguation, as I've said repeatedly (don't people believe me? 8-), HTTP has the Content-Location header for doing just this. The issue is though, when do you use it? For the human-centric side of the Web, I am a believer in using it *after* humans (other than the publisher) have decided, via common use, what the URI identifies. Neither browsers nor Web servers support it very well in my experience, so I don't think there's any use in trying to convince them to obey what the header says. Re the IBM web site, I would expect that somewhere on the order of 99% of all the back links to "http://www.ibm.com" are using it to identify the company, not the Web page. Google seems to back me up on this; a look at the first few pages of this query yields nobody talking about IBM's HTML; http://www.google.com/search?q=link:http://www.ibm.com/&hl=en&start=30&sa=N Once machines are doing more of the browsing, only then (IMO) does it become really necessary to help them disambiguate, without going down the slippery slope of using heuristics. At that point, using the Content-Location header seems like the right thing to do, and to do it so that it reflects what humans are already using your URIs for, not what you would ideally want them to be. But in the meantime, you can be careful about how your web site is laid out. For example, a GET on "http://rdfig.xmlhack.com" returns a redirect to "http://rdfig.xmlhack.com/index.html". This will give the RDF IG problems in the future, because some assertions will be made about "http://rdfig.xmlhack.com/index.html" that are about the RDF IG. So try to avoid using redirects to solve problems that your Web server can help you with by using Content-Location. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Wednesday, 24 April 2002 09:51:37 UTC