On Mon, 2009-06-01 at 18:58 +0100, Noah Slater wrote: > Hey Thomas, > > I think you might be a little confused about how URIs work.
No, I'm not. I'm just talking about practice rather than theory. In practice, we are to a first approximation always using http/https method names beginning with a host-name for which the semantically proper resolution is whatever that specific host responds. We rarely use names of specific documents or computations. On the subtext list, someone else pointed out the same flaw in my rhetoric by pointing out that I was abusing the word "resource" - and he is correct. I'm quite open minded to hear better ideas about how to express the "in practice" concept I'm getting at. > A URI is just a formal way of naming a resource. That could be an information > resource with a representation you can get, like a HTML document. It could > also > be a non-information resource, like the moon. URIs do not even have to use the > HTTP scheme, or even when they do, they do not have to return representations. > You cannot get a representation of the moon via HTTP, but using a HTTP URI to > talk about the moon is perfectly okay. > > This is a valid URI: > > urn:ietf:rfc:2648 > > There is no way for me to dereference this, and hence there is no way I can > get > a representation of this resource from the URI alone. > > This is a valid URI: > > http://tools.ietf.org/html/rfc2648 > > I can dereference this URI with my browser, and get a HTML representation. That URI is the name of a host and a relative URI in that host -- it is the name of a set of queries, not a name for the ASCII text of the RFC. > This is a valid URI: > > http://tumbolia.org/ns/rfc2648 > > If you try to dereferencing that URI, you will find that my server responds > with > a HTTP 404 response. Even though you cannot get a representation of the > resource > named by that URI, it is still a valid identifier. Right. The URI of that form is the name of a query, not a document. > This is a valid URI: > > http://g0025.org/ns/moon > > I do not own that domain, nor have I got permission from the owner to create a > URI using it, but the URI is still a valid identifier. It does not matter if I > can get a representation of the resource or not. > > In the above cases, the URIs are valid and potentially useful identifiers that > can be used with a many technologies designed to work with Web architecture, > such as the Resource Description Framework. > > So, it is important to consider that: > > * Being able to dereference a URI is not required. True. URI's can just be "atoms" (in the lisp sense). They can be things against which content or a reply can be verifiably checked. They can be routing instructions for queries to specific hosts. To a first approximation, we're building the global hypertext, currently, out of a subset of URIs which are routing instructions for queries to specific hosts. Conceptually, people act as if these links were to content or abstract service rather than specific host. Wave introduces a shim that can close that discrepancy . > * Being able to fetch a representation by dereferencing is not required. > > * Controlling the representation dereferenced is not required. > > With all of that out of the way, You didn't catch me in a confusion but you did catch me stretching "terms of art" for a general audience to convey the concept. If you can think of a better way to express the concept, please share it. > the one issue your email does highlight is that > the ability to dereference URIs using the HTTP scheme is dependant on the > Domain > Name System, which is a central authority. It's deeper than that. That's an aspect, yes, but it's deeper. 1) There are names of routing instructions to specific hosts. 2) There are names unique(-ish) to specific content. 3) And there are names intentionally assigned to specific content. Common "http://example.com"; URLs are type (1). Git provides type (2) at least for files. Wave starts to give us (3) in a routable way. > > To quote Norman Walsh: > > In the case of the "http" name, the only part of the name that appears > beyond > my control is the DNS name. If I fail to maintain my registration, it may > get > reassigned and the new owner may not feel any obligation to maintain the > unambiguous nature of the names I assigned. The solution for this problem > seems straightforward to me. If you're worried about the persistence of my > names, ask me to demonstrate that I've purchased a 10 year lease on the > domain > name, or a 100 year lease, or a lease in perpetuity if you've got the legal > framework to do that. Problem sorted. > > In the case of "newscheme" names, users actually have to be persuaded to > follow the mandate of using only the portions of the namespace that they've > registered (considering the widespread use of unregistered URI schemes and > unregistered URN namespaces, there's no reason to be optimistic on this > score), the organization created to manage the naming space has to exist > indefinitely, and it has to successfully manage the naming space. > > Again, on this score, I think the safe money is on the DNS system. > > - > http://norman.walsh.name/2006/07/25/namesAndAddresses > > I would recommend reading the whole essay, it covers a lot more than this. > > So, to get back to your email: > > > Wave initiates the game of building a much needed and much anticipated > > overlay > > network that can operate in a distributed and decentralized way, giving > > names > > to resources rather than questions to hosts. > > I would like to see an explanation of how Wave improves on URIs. It does not improve on URIs, it puts them to good use. In Wave, to a first approximation, IDs (of waves, wavelets, docs) are not routing instructions per se but rather are indexes into Wave stores. It doesn't kill DNS so much as it subsumes it into something more general. -t _______________________________________________ Discuss mailing list [email protected] http://lists.autonomo.us/mailman/listinfo/discuss
