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
