non-http uris

hello.

there was a recent discussion about the httprange-14 issue, which 
basically asked whether a http-identified resource can be anything, or 
just an information resource (i.e., something which by its very nature 
can be retrieved through http).

noah_mendelsohn@us.ibm.com wrote:
> BTW: I'm not sure it makes sense to go to far with this discussion here. 
> www-tag is a public list, and much of this ground has been covered there. 
> If there's more to discuss on httpRange-14, wouldn't it make sense to do 
> it on www-tag?  Thanks.

sorry for sticking to uri@w3.org, but since i seem to be the one who is 
least happy with the puristic http approach to identifying resources, i 
would like to expand the discussion a bit. i guess i can live with the 
httprange-14 consensus, but even though this consensus allows http 
resources to identify anything (as long as they return 303), it does not 
say anything about non-http resources.

and since the consensus forces me to use http retrieval to learn about 
the special nature of the identified resource, once again i am coming 
back to my claim that for sufficiently relevant types of resources 
(please note the very vague qualification...), it makes sense to use 
non-http uri schemes, because that makes the non-http nature of the 
resources transparent (i.e., does not rely on http response codes to 
disclose the non-http nature of the resource).

and in a way, shouldn't rdf users be more happy as well if they could 
write assertions about geoloc:27.987328,86.923828 when talking about 
mount everest, rather than having to rely on the rather awkward 
httprange-14 consensus and some mapping service http uri for identifying 
the location of the mountain's summit?

i guess i simply still don't quite buy the point that under all 
circumstances it would be the better solution to use http uri schemes, 
only because they can work against http servers. in the end, i guess it 
is simply a matter of weighting. from my point to view, i see this as 
follows:

- pro http-based uris: http dereferencable to some http representation 
of the resource, more graceful behavior in older clients.

- pro non-http uris: non-http nature of the resource reflected in uri, 
no "magic domain names", no requirement for managing the "magic domain 
names".

well, i think we have been through these arguments already, and this was 
not the information i was originally looking for on this list 
(http://lists.w3.org/Archives/Public/uri/2007Dec/0015.html is how this 
started), but i would be disappointed to see that the uri space would be 
limited to older schemes and new resource types would have to be mapped 
to http or introduced as urn (which would turn urns into some kind of 
back door to get non-http schemes).

maybe i have to adjust my understanding of web architecture, but i am 
still very curious to see how the discussion about geolocation uris will 
be received in the web community. personally, i think the web would be 
better off to take these resources as seriously as email addresses and 
phone numbers and grant them a uri scheme of their own.

happy holidays,

dret.

Received on Wednesday, 26 December 2007 21:30:47 UTC