Re: URI for abstract concepts (domain, host, origin, site, etc.)

Erik Wilde wrote:
> hello.
>
>   
>> I don't think a URI scheme has to do anything with transportation 
>> protocol.
>>     
>
> the URI scheme specifies the protocol that has to be used the resource. 
> how can that have nothing to do with the protocol?
>   
Oh, I mean what a URI denotes has nothing to do with how you obtain the 
representation.

Besides, I do believe that we need *one* URN.  My position is, however, 
different from other URN proposal in that: I think we need *only one* 
URN but *many* URL. And the syntax that I have in mind for this URN to 
be schemeless.

In other words, the URN is an HTTP-URL sans "http:"

There are several advantages of this.  Although an HTTP-URL can be taken 
as a URN as well as a URI.  But this dual mode makes people very 
uncomfortable.  This scheme-less URN helps easy the issue.

Second, it solves existing issue.  For instance, the identity of an HTTP 
and an HTTPS URI is always hard to define with the current URI spec.  In 
my proposal,

"//danbri.org/foaf.rdf#danbri" would denote Dan Brickley the person. But
"http://danbri.org/foaf.rdf#danbri" would denote an information path to  
Dan.  Obviously, what Dan is should be independent of how his 
information is obtained.  This also explain the fragment identifier 
semantics, it is just another information path (traversed after the 
first path).

Third, with the schemeless URN defined, there will be no longer any 
issue about if we need a new URI scheme.  The answer is changed to an 
easy answer one, do we need a new URL. And this in fact will encourage 
the development of new transportation protocol, which will make the Web 
evolve gracefully with the stable set of URN.  Also, we can take the 
concept of the Web to real life too.  For instance, it is thus possible 
to "snailmail://danbri.org/foaf.rdf#danbri" a post-card, where snailmail 
is a transportation protocol implemented by a postal office.

Of course, there is one important issue:  Given a URN, how can a user 
know which protocol it should use?

My suggestion is to let them not be defined technically, but be run as a 
common human knowledge. To use the Web, knowing HTTP is the most 
popularly supported transportation protocol is like knowing the "ABC" in 
order to use a language. Thus, when someone is given a URN, s/he should 
know that (at the current time) s/e should try it with the "http" 
protocol.  And, from resource provider's point of view, we can take the 
"http" service as our bootstrap protocol., from which we can use content 
negotiation to either redirect or inform some other kind of protocol 
that it may support.  I think this scheme-URN + the completion of the 
URI syntax would establish a very solid foundation for the Web.  At 
least, it solves most of the architectural issues of the Web that I know of.
 
>> No matter what URI you use, after de-reference, you get a 
>> *representation*, which is a different thing from the *resource* that 
>> the URI denotes.  And a representation must have a content type, 
>> regardless how you retrieved it.
>>     
>
> that's HTTP and HTTPS, but probably not many other protocols. if you use 
> mailto: or tel: or fax: or sms:, then there are other modes of 
> interaction with the identified resource, and for those interactions 
> there is no concept of a media type. and even for ftp:, there is no 
> media type info; you can guess, but there is no protocol mechanism that 
> supports it. so it really seems to me you're focusing on HTTP URIs which 
> is fine; i just wanted to find out.
>   
Of course, there isn't a name for these *reprentations* yet. But that 
does not mean they are not typed.  Whatever kind of message that each of 
these protocol they use, the structure of the message must be specified 
somewhere, which in essence makes them a media type, right?

Xiaoshu
> cheers,
>
> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
>         dret@berkeley.edu  -  http://dret.net/netdret
>         UC Berkeley - School of Information (ISchool)
>

Received on Sunday, 28 June 2009 03:31:22 UTC