W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

Re: reference needed - w3.org versioned documents

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 7 Apr 2008 09:06:36 -0400
Message-Id: <AAD4FD66-17A8-476B-9F20-444A6435BD3E@creativecommons.org>
Cc: noah_mendelsohn@us.ibm.com, Pat Hayes <phayes@ihmc.us>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
To: Richard Cyganiak <richard@cyganiak.de>

Richard, I'm sorry for my tone, and I should be more careful.

On Apr 6, 2008, at 4:31 PM, Richard Cyganiak wrote:
> On 6 Apr 2008, at 19:41, Jonathan Rees wrote:
>>>> The utility of httpRange-14 is significantly reduced as long as  
>>>> not all minters of URIs for non-IRs adhere to it. I have no idea  
>>>> what the penetration of httpRange-14 is, but my guess is that it  
>>>> is and will remain low.
>>> Any backup for that guess?
>> Nope, sorry - that's why I called it a guess. I know of people  
>> using URIs to name non-IRs who either disagree with httpRange-14,  
>> or do not know about it, or cannot arrange for 303s, so there is  
>> some noncompliance out there.  Even if penetration is prettty  
>> high, a few bad apples will spoil the bunch, in situations where  
>> it matters (not that I know what those are, but I assume they exist).
> I call FUD. Who are those people you know? Anyone else except Pat  
> Hayes and the Dublin Core folks?

It didn't occur to me I was FUDding since I have always been an  
advocate of the httpRange-14 resolution... but point taken.

There's the LSID proxies, which matter because people are writing  
http://proxy/... owl:sameAs urn:lsid:... without restricting 200s to  
things that are IRs. This affects the taxonomic databases and the  
Encyclopedia of Life project, I believe, among other things. I'm told  
TDWG plans to fix this, and put not-200 into a future LSID proxy  
recommendations document, but knowing how busy they are I think this  
will be a while. I have no idea about the other LSID proxies.

I also have two biology semantic-web projects in mind, but I think  
that if I publicize them here that would work against my efforts to  
reform them. I'll send you the links privately.

> You say that a few bad apples will spoil the broth. Why do you  
> think so? The Web doesn't break just because a few people don't  
> follow standards.

You are right. I think I just wanted to state the obvious, which is  
that not everyone follows the standards (recommendations,  
resolutions, etc.) we would like for them to follow, and the buyer  
has to beware. I think it's a matter of degree - a question of  
assessing the practical risk of assuming compliance, as a function of  
target application and RDF corpus. The more effective social pressure  
such as yours and mine is, the lower the risk/cost of assuming  
general compliance. I'm happy to assume there's no big problem right  
now; the point is just a cautionary one for future users and  
application builders.

You appear to think the caution will be obvious or unnecessary to  
readers of the "Cool URIs" note, because you state without  
	If, on the other hand, a request is answered with one of the usual  
status codes in the 2XX range, like 200 OK, then the client knows  
that the URI identifies a Web document.

If I had written this, I would have added a footnote saying that as  
with any protocol, there can be bugs and noncompliance, and as of  
April 2008 Dublin Core (and perhaps some other sources) are  
noncompliant, so you need to be cautious in interpreting 2XX this  
way. This to me is just a little bit of epistemological hygiene. But  
then I'm a bit of a paranoid about things like this.

>> Of course it would be delightful if there were perfect compliance.
> It would be delightful if there was a solid consensus around  
> httpRange-14. Perfect compliance is of course neither realistic nor  
> required nor important.

I agree. I'm sorry I used the word "perfect". That was provocative.

Received on Monday, 7 April 2008 13:13:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:20 UTC