Re: URIs & Namespaces

me again.

Mike Schinkel wrote:
>> This is where microformats are at the moment: most people 
>> process the info from the short name.  Few need the backup.  
>> But the full drill is still to publish the backup to avoid 
>> future problems as people start to use the design pattern more.
> I don't follow what you mean by "the backup?"

i think al is talking about grddl-like approaches, where you can 
transform some microformat stuff to full rdf glory, if that's what you 
prefer for processing.

> Now you might think that "BerkeleyPlaces.org" is too long; fine then; look
> for something short that is available, i.e. brkpl.org: 
>     http://clubs.brkpl.org/golf/tilden 
>     http://clubs.brkpl.org/golf/metro 

i am not concerned about the length of uris, but i do think that having 
to register a dns domain and set up a server is not really what you 
should have to do, when you want to establish a shared vocabulary for 
place names.

> I'll counter that piggybacking is exactly what you want, and that I believe
> schemas are designed to be piggybacked on, whenever reasonably possible and
> reasonably appropriate.  And HTTP is brilliant for piggybacking.   Take a
> look at HTTP URLs:
> 	http://{domain}/{stuff}
> The {stuff} is an opaque string; it can easily embed your own location
> identifier scheme, and browsers can deal with it assuming it followed the
> HTTP request/response protocol spec.

sure, you *can* piggyback anything on http, and thus claim that http is 
the only uri scheme that the web should ever use. but do you really 
think all entries in http://www.iana.org/assignments/uri-schemes.html 
should have been http:{uri-scheme}/{value} and then the web would be 
better off than it is today?

just a diversion: what i do think is that most browsers are simply 
terrible and allowing to plug-in uri scheme handlers. they are pretty 
flexible for dynamically adding media type handlers, but noch such 
mechanism is provided for uri schemes. i think that is actually 
something that is part of the reason why creating new uri schemes looks 
like a bad idea.

> When you piggyback you get all the previously paved roads (i.e. all the
> in-place infrastructure) without any of the cost of paving.

sure. which is fine as long as you want to drive on these roads. or, put 
differently: should the web exclusively be about http interactions? 
isn't it nice that i can send mail and place phone calls from my 
browser? that i could fire up my navigation gadget by pointing to a 
location? sure, the majority of web traffic is and probably always will 
be http, but there are other things which are useful, too.

> Let's look at my examples above using a hypothetical "LOC:" scheme:
> 	http://clubs.brkpl.org/golf/tilden 
> 	http://clubs.brkpl.org/golf/metro 
> 	loc:brkpl/clubs/golf/tilden 
> 	loc:brkpl/clubs/golf/metro
> Have you really gained anything by creating a new scheme?  You've shortened
> by 7 characters, but for your local short names of "tilden" and "metro"
> nothing has changed.

something has changed: in the latter case i know i talk about locations, 
which i don't know in the former case. that's an important change.

> But for argument let's say there really is a great reason to create a "LOC:"
> scheme.  Okay then start with HTTP and tell everyone to use the format of
> "http://{sub-ns}.{ns}.{tld}/{cat}/{name}" for HTTP but transform it to
> "{ns}/{sub-ns}/{cat}/{name}" when storing it in a database or referring to
> it elsewhere.  Once use of these location identifiers becomes ubiqutious you
> can then introduce a "LOC:" scheme and translation software that transforms
> from HTTP: URL to LOC: URI.  But then I doubt you ever would take this last
> step because you'd be loosing all the benefits HTTP provides.  At best I
> would expect that you'd introduce LOC: as shorthand where it is known how to
> convert from an LOC: URI to an HTTP: URL. JMTCW anyway.

now this means you expect all people to basically implement a loc: 
scheme but simply write it down with a http: syntax. and implement some 
magic check to recognize when they encounter such a loc-http uri...

>> for example, the tel: and mailto: schemes make sense (i 
>> think), because not only do they identify things, they also 
>> clearly define how to interact with them. 
> They may make sense, but they are not nearly as widely used as HTTP.  What's
> more, they are not dereferenceable which IMO is being able to dereference a
> URI is an incredible benefit.  "URN:ISBN:0-395-36341-1" is interesting, but
> http://isbn.info/0-395-36341-1 is far more useful (assuming it returns
> information for the book designated by ISBN # 0-395-36341-1). 

well, being able to tap a tel: uri on my iphone and just place a call is 
something i find useful. and while the same thing could be achieved be 
using a magic http prefix http://telnumbers.org/{number}, this never 
happened, and would not reduce the complexity of implementations (it 
would have the advantage of being able to display something to a user 
with a non-phone browser, though).

but: if the skype folks wouldn't be as narrow-minded as they are, they 
would have introduced tel: handlers into all major browsers by now (or 
at least would have pushed for plugin features and deployed plugins for 
skype), and the web could be better integrated with the non-http world.

> I'm pretty sure I'll have the same opinion of any other URI schemes; feel
> free to try me.

ok, tell me how to piggyback these onto http:

file:
fax:
sip:
news:
https:
tag:

(just kidding, don't do it) i don't want to come across as somebody who 
wants to have uri schemes for all kinds of things, but i think there are 
cases where it makes sense.

> This can work using HTTP URLs and a domain.  Of course if you need to be
> able to determine that it *is* a location, you can set up a webservice at
> LocationRegistry.org (or similar) that can validate if a domain is a
> registered namespace or not, i.e. ah HTTP 200 means it is valid, and HTTP
> 404 means it is not:
> 	http://locationregistry.org/BerkeleyPlaces
> And/or the HTML document returned by dereferencing
> http://www.BerkeleyPlaces.org could include a <meta> element, something
> like:
> 	<meta name="location-namespace" content="Namespace for UC Berkeley
> Places">

so i use a http uri, dereference that, get some html, find a magic name 
in a meta tag, and then conclude that, in reality, this was a http-loc 
uri and then i am where i would have been with a loc uri in the first 
place? and for all of that to work i need to know the magic 
LocationRegistry.org service? and how does that service know that some 
domain is a location domain? do i need to register with that magic 
service when registering my place name dns name? and if i don't then my 
place name dns name is not really a place name dns name?

> I don't see how HTTP forces anything.  If the world gets behind
> "LocationRegistry.org" it would be no different then them getting behind a
> "LOC:" scheme.  Actually I believe the chances of them getting behind an
> HTTP-based solution would be greater because it is built on top of existing
> schemes and protocols, and because LocationRegistry.org would provide them a
> place to dereference.

well, for the gps scenario you might see google maps as this service, so 
instead of using loc:27.987328,86.923828 most people use 
http://maps.google.com/maps?ll=27.987328,86.923828&spn=0.090637,0.148659&t=k&hl=en. 
but who is the one having this precious domain? if we had magic domains 
for tel and fax, who would own those? and have the right to route people 
to some service?

> Though I can't speak for W3C or ITEF, I personally would like to see wgs84
> piggyback HTTP.  OTOH, I don't have a problem with a dual system (i.e. both
> a scheme and an HTTP version of the scheme) ASSUMING we do get an HTTP
> version with a mapping to the other scheme or URN.

so, for the coordinates, what's the http solution? google maps? yahoo 
maps? microsoft virtual earth? something else? if so, what? i would 
prefer a neutral way to say "that's a pair of coordinates", and then 
users can choose.

for example, the iphone does some pretty dirty hacks and based on some 
pattern matching re-routes you from its web browser to the builtin 
mapping app. they can do this because they mostly look for google maps 
patterns in uris, but it really is a terrible hack.

> Erik Wilde wrote:
>> now, if location is a web concept (which is open to 
>> discussion), should non-gps locations be expressed in that 
>> conceptual space, or should they be mapped to http prefixes? 
> I don't' follow that...

if we had a loc: scheme for wgs84 coordinates, would you prefer that 
place names should still use http, or should they be folded into the loc 
scheme?

cheers,

dret.

Received on Tuesday, 11 December 2007 06:55:42 UTC