- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Mon, 26 Jan 2004 14:12:20 +0200
- To: "ext Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
- Cc: www-rdf-interest@w3.org
On Jan 26, 2004, at 13:32, ext Hammond, Tony (ELSLON) wrote: >> I simply can't fathom any real benefit to having a URI >> which, by definition, cannot be used to access such knowledge. > > The reason is to keep the barrier to entry as low as possible. By > explicitly > excluding dereference we have devised a very simple, focussed > registration > mechanism which requires almost zero maintenance and is consistent > across > the whole INFO namespace with a predictable behaviour (i.e. disclosure > of > identity). This is a baseline service - think of it as something like > the > Model T. Well, er, fair enough. But I don't know anyone these days who would particularly *want* to drive a Model T as their primary vehicle. But let me address what I understand as the key components which you identify above: 1. low barrier to entry The bottom line here is that the info: scheme does not offer any lower barrier to entry than http:, and in fact, if the principles of PURLs and well-choosen and maintaned domain names are understood, I'd argue that info: has a higher barrier than http: (i.e. domain name registration). 2. zero maintenance After obtaining the namespace (either info: or http:) neither info: or http: URIs require any more maintanance than the other. Both simply require that the owner of the particular namespace keep track of which URIs are minted to avoid collisions. But since there is no requirement that http: URIs resolve to any representation, or that there actually be any HTTP server accessible at any address/port per the web authority component of the URI, http: URIs impose no greater maintenance overhead than the proposed info: URIs. 3. consistent, predictable behavior This seems to be the only possible distinction between info: and http: URIs; however (a) the intended behavior (or lack thereof) of interpreting info: URIs cannot be guarunteed (per DDDS and other non-HTTP resolution protocols) (b) one is actually likely to find great inconsistency in localized resolution of info: URIs, since systems will still want/need to store and retrieve labels, descriptions, and other knowledge about the terms (resources) for various purposes, and since info: defines no resolution mechanism, everyone will have to roll their own (c) any term worth minting an info: URI for is likely of sufficient importance that folks will *want* to be able to dereference that URI to get a description of the term in question (d) providing for a user-friendly, consistent, and informative response for any http-based URIs grounded in an INFO managed namespace -- for cases where representations and/or descriptions are not available -- is simple to do, and thus in no way justifies prohibiting everyone from exploiting a globally deployed infrastructure to provide representations and/or descriptions if so desired. -- So, to summarize, the only distinction between the use of info: URIs rather than http: URIs -- intended non-resolvability -- is a distinct and significant *disadvantage*. > > I agree that it would be useful to have resource representations > sitting out > there on some network endpoint - but that is just way too expensive > for the > namespaces we are interested in fostering. I'll give you the software to do it for free. Really. All you need is the RDF. And the server will automatically fall-back to trying to return a description if no representation is otherwise available. > There are no (human) resources > available to maintain such an undertaking. Surely someone, somewhere is maintaining the formal definitions of these vocabularies. Surely you will have somewhere descriptions of those term sets, with the labels/titles/descriptions of those terms. Even a trivially simple RDF schema that just lists the terms as terms would be better than nothing (though I expect that in reality, it would not be much work to create fairly respectible RDF descriptions of those terms based on existing materials). Also, you'd want to delegate the work as much as possible, to each owner/manager of each subnamespace. Yes, there will be a few vocabularies where the actual owners will perhaps not want to do anything other than give permission for minting the URIs, but I would expect that to be the exception rather than the rule. > The conclusion is that we either > go this zero-resolution route or we accept that many of these > namespaces > will continue not to be represented on the Web. That does not need to be the conclusion. Rather, why not simply begin with http: URIs grounded in your own INFO organization's top level domain, such that initially there is no resolution provided (or perhaps providing a fall-back to a nice user-friendly explaination of why clicking on that URI isn't providing anything useful) and then, *when* the descriptions are created, *BINGO* you've got web-accessible descriptions of those terms! With *zero* impact to any usage of those terms as names. Thus, the real conclusion is that choosing http: URIs which don't resolve to anything costs you nothing more in effort or overhead than info: URIs, yet keeps the door open to when (not if) folks will need/want those descriptions. > Which means that we will > continue to be frustrated by not being able to 'talk' about well-known > public information assets in Web description technologies. > You'll be able to talk just fine with/about those terms using http: URIs as you will with info: URIs, but eventually be able to do so much more. All of your goals can be met *better* and with no more cost/effort by http: URIs. Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Monday, 26 January 2004 07:12:36 UTC