Re: Middle ground change proposal for httpRange-14 -- submission

As someone who has often commented publicly (and negatively) on matters 
of semWeb semantics and httpRange-14, I feel I have an obligation to 
offer comment publicly on the various change proposals being put forward 
[1].

Despite everyone's acknowledged fatigue about this issue, I think 
Jonathan Rees has done the community a real service pushing to 
re-surface and re-open this question for resolution. His efforts go back 
to 2007, showing just how slowly the wheels of standards sometimes turn 
[2].

I think everyone who has commented publicly on these issues over the 
years has an obligation to state their position: by submitting an 
alternative change proposal; by co-signing one of the existing 
proposals; or otherwise stating their views publicly. It is like 
democracy; if you don't vote, don't bitch about the outcome.

As for me, I am supporting two items:

1) the complete abandonment of the "information resource" terminology: 
bury it forever! and
2) David Booth's alternative change proposal [3].

I am supporting David's proposal because it:

* Sidesteps the “information resource” definition (though weaker than I 
would want)
* Addresses only the specific HTTP and HTTPS cases
* Avoids the constrained response format suggested by the TAG
* Explicitly rejects assigning innate meanings to URIs
* Poses the solution as a protocol (an understanding between publisher 
and consumer) rather than defining or establishing a meaning via naming
* Provides multiple “cow paths” by which resource definitions can be 
conveyed, which gives publishers and consumers choice and offers the 
best chance for more well-trodden paths to emerge
* Does not call for an outright repeal of the httpRange-14 rule, but 
retains it as one of multiple options for URI owners to describe resources
* Permits the use of an HTTP 200 response with RDF content as a means of 
conveying a URI definition
* Retains the use of the hash URI as an option
* Provides alternatives to those who can not easily (or at all) use the 
303 see also redirect mechanism, and
* Simplifies the language and the presentation.

BTW, I think it would be silly for the TAG not to address the entire 
range of httpRange-14 issues -- including terminology -- by hewing to an 
overly narrow interpretation of ISSUE-57.

Mike

[1] 
http://www.mkbergman.com/1002/tortured-terminology-and-problematic-prescriptions/
[2] http://www.w3.org/2001/tag/group/track/issues/57
[3] http://www.w3.org/wiki/UriDefinitionDiscoveryProtocol

Received on Wednesday, 28 March 2012 00:12:39 UTC