W3C home > Mailing lists > Public > uri@w3.org > January 2008

RE: non-http uris

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Tue, 8 Jan 2008 08:08:29 -0500
To: "'Erik Wilde'" <dret@berkeley.edu>, <uri@w3.org>
Cc: <noah_mendelsohn@us.ibm.com>
Message-ID: <023501c851f7$94a4cf20$0702a8c0@Guides.local>

Erik Wilde wrote:
> in the past week, i played around with the uri schemes of 
> various map services (which would be more or less what noah 
> and mike have been proposing with a http-based geolocation 
> scheme), and they are pretty hard to match. of course they 
> have much more features (zoom levels, map types, geocoding, 
> business ids), but creating some mapping between these uris 
> is surprisingly hard. my short term goal is to do this (which 
> would create some sort or "virtual uri scheme" for 
> geolocations because supported map service uris can be 
> translated between services), but this is an ugly hack (i 
> think) and also can easily break, because no map service 
> publishes documentation about their map service uris.

I would *love* to see a writeup on your blog about your experiences during
that process, if you are so inclined.  I think it would be very instructive
for many people, including me.

> the geolocation folks are happy with their gis 
> systems and just build web interfaces for them, but don't 
> really think about merging them into the web.

It's amazing how short-sighted people can be, then someone comes along and
makes them wake up and it becomes a race.

I've been lamenting how few companies recognize the value of exposing an API
on their website for years. Then Facebook comes along with an API, gets
valued at $15B, and now everyone wants and API (but even still, most are
just cargo-culting it.)

> > I'm with you. Too bad Erik has such an aversion to 
> http-scheme URIs, 
> > especially since I think he could easily get it working with 
> > http-scheme URIs in a manner that would be compatible with 
> a geoloc: 
> > scheme.  He could start with the former, go through the process in 
> > parallel, and then later a recommendation could be announced to 
> > transition from http-scheme URIs to
> > geoloc: scheme if and when it makes sense, i.e. 
> > htpp://geoloc.{domain}/{loc} => geoloc:{loc}
> this sounds as if i had some kind of pathological problem 
> with http. i have not, but i still fail to see what should be 
> good about http-based schemes, if they identify something 
> that is (a) ubiquitous, (b) not an information resource, and 
> (c) has other ways of interaction than http. 

Sounds to me like a pathological problem in all but maybe name... ;-)

But seriously, you get an additional benefit from using HTTP.  Using HTTP
means that it now not only identifies a location but it also participates on
the broader web, and the more URIs available to be dereferenced on the web,
the more valuable the web becomes.  After all, the value of the network
increases with the square of the number of nodes.

> and i do note that nobody so far was able to point to a case 
> where such a magig "uri scheme" based on a fixed http-based 
> prefix has been deployed successfuly. i think there is a 
> reason for that.

I pointed several out in prior emails. Purl, for example.  Wikipedia is
another.  And several more that escape me at the moment.  Why do you not
acknowledge them?  Or at least challenge their applicability.

> the tag scheme would be the worst location. it would have the 
> geoloc scheme's disadvantage of not allowing http 
> dereferencing, and the http scheme's disadvantage of "hiding" 
> the semantics in some magic prefix. i think we can at least 
> agree that the tag way is not the way to go.

I'll agree with your there!

> i would hesitate to make a transition from a 
> http-based scheme to a real uri scheme as well as 
> unilaterally introducing a scheme. it is basically the same. 

How is it basically the same?  As Noah pointed out, the risk of damage to
the global namespace is much less great going the HTTP approach; if you get
it wrong, it's easier to fix it. So you work on that until you work through
the issues, possibly going through several different approaches, and then
when you find the good one that everyone agrees to you can transition to a
scheme that uses the same approach as the http approach's path, if it really
is important to do so.

-Mike Schinkel
Received on Tuesday, 8 January 2008 13:08:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC