Slashdot Mirror
IETF Draft Sets up Public Namespaces
figlet writes "A new IETF draft is out (URI Scheme for Information Assets with Identifiers in Public
Namespaces). It is a very cool idea and basically introduces namespaces through a new URI scheme. These would be used to refer to resources within their own context. NISO will be the registry for public namespaces. Example (from Herbert Van de Sompel): 'For example, assuming that the namespace of Dewey Decimal Classifications (ddc:) and the namespace of Library of Congress Control Numbers (lccn:) would be registered by their respective authorities, then: the Dewey Decimal Classification 22/eng//004.678 (for the term "Internet") could be expressed as the "info" URI:<info:ddc/22/eng//004.678> and the Library of Congress Control Number 2002022641 could be expressed as the
"info" URI <info:lccn/2002022641>.' NISO is going to act as the 'info' registry. Very neat. This basically sets up a parallel web of info spaces, where http/DNS space is just one of many, and anyone can register their namespace 'domain'. Way cool!!"
I call dibs on the pr0n:// namespace!
"Luck is the residue of design" -- Branch Rickey
URI
URI <info:goatsecx/hello>
Trolling is a art,
This seems like XML, only even more confusing. Arbitrary key names are now URIs? Where is the uniformity in this system?
Without strict discipline, users will create their own, incompatible URIs in the same namespace. Their needs to be a guiding hand in all this-a document or company that oversees this project VERY carefully. We don't want this turning into some aimless metanarrative like the "Information Superhighway".
(-1, Raw and Uncut is the only way to read)
To get a namespace registered? ICANN? Verisign? This part was interesting: The "info" URI scheme explicitly decouples identification from resolution. Applications SHOULD NOT assume that an "info" URI can be dereferenced to a representation of the resource identified by the URI, though some business processes MAY make "info" URIs resolvable either directly or conditionally. The purposes of the "info" URI scheme are the identification of information assets and the standardization of rules for declaring and comparing identity of information assets without regard to any resolution of the URI or even whether the information asset identified by the URI is accessible on the Internet. This makes it look like this was intended more for internal use than for routing to specific information on the net. Anyone have a clear idea how and why this would be used on the internet?
From the article:
"The "info" URI scheme explicitly decouples identification from resolution. Applications SHOULD NOT assume that an "info" URI can be dereferenced to a representation of the resource identified by the URI, though some business processes MAY make "info" URIs resolvable either directly or conditionally. The purposes of the "info" URI scheme are the identification of information assets and the standardization of rules for declaring and comparing identity of information assets without regard to any resolution of the URI or even whether the information asset identified by the URI is accessible on the Internet."
In other words, the info URI's will not be useful for anything other than providing context and identification. There is no resolution mechanism in place, nor do they intend to have any standard resolution mechanism, which makes the practical use of these URI's almost nonexistant (as current designed.)
Why do I h8 apple?
With addresses like URI:, I'll spend more time on the phone trying to help my mother get where she needs to.
Anyone else notice info-uri.niso.org doesn't exist?
How exactly will browsers implement this new protocol?
I'm confused about the concept of a "public namespace". If these new URIs are intended to point to information, where will that information be stored and how will it be retrieved?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
This has some interesting possibilities, especially in the context of representing real-world elements in virtual space, and assist in more accurate search engine results. For example:
info:map/40.47N/73.58W for NYC's Central Park
could be encoded into any Web page about Central Park; and
info:palm/model/P80900US for the Palm Tungsten C
could be included in every online retailer's site where the T|C is sold.
This would seriously enhance the now piece-meal effort to pick the best search term to find specific items that may have common names. {Jonathan}
-------------------
Prof. Jonathan I. Ezor
Associate Professor of Law and Technology
Director, Institute for Business, Law and Technology (IBLT)
Touro Law Center
300 Nassau Road, Huntington, NY 11743
Tel: 631-421-2244 x412 Fax: 516-977-3001
e. jezor@tourolaw.edu
BizLawTech Blog: http://iblt.tourolaw.edu/blog
Check out URI:
--Joe
Quick, without peeking at the answer, what's the difference between a URI, a URL, and a URN? OK, now that we are all on the same page :-), what is "info:"? you'd expect it to be a URN. It isn't (from the RFC):
7.2 Why Not Use a URN Namespace ID for Identifiers from Public Namespaces?
RFC 2396 [RFC2396] states that a "URN differs from a URL in that it's primary purpose is persistent labeling of a resource with an identifier". An "info" URI on the other hand does not assert persistence of resource names or of the resource itself, but rather declares namespaces of identifiers managed according to the policies and business models of the Namespace Authorities. Some of these namespaces will not have persistence of identifiers as a primary purpose, while others will have locator semantics as well as name semantics. It would therefore be inappropriate to employ a URN Namespace ID for such namespaces.
Which I read to mean that an info: URI may, or may not, be a URL (i.e., useful for actually accessing the resource); may, or may not, be a URN (i.e., provides some semblence of a chance that it means the same thing today as it did yesterday). Oh, did I mention that it may, or may not, be case sensitive, and may or may not be subject to scheme-specific normalization rules?
It seems that someone (say "Perfection") got fed up holding the fort agains a hoard of requests for top-level URI schemes - or someone (say "Kludge") got fed up with the demand that these schemes actually have some well defined semantics. Or both. Either way, they had this brilliant notion... why don't we have a junk^H^H^H^Hinfo: URI scheme with as little control over semantics as we can get away with? If some top-level URI scheme sucks, we'll just put it there. We'll spin off a company to be the registrar so "Perfection" will be able to pretend not to see it, and "Kludge" will be able to register all the junk^H^H^H^Hinformation URIs he wants!
I guess it does make some sort of twisted sense... In the meanwhile, proposals like the taguri proposal languish. Here's a years-old proposal that attempts to define coherent semantics for time-persistant identifiers, without requiring a (new) registration agency. We can't have that, can we?
Sigh. Insert mandatory "I for one welcome the arrival of our new info:disposable:gjyr4784ghf89yf4h URI masters" post here...
I know the document discusses this, but I don't know that I buy the explanation. The spec says a URN should be persistent, and since we don't want to enforce persistency we go off and create something new?
So now when I want to come up with a new way to label information internally, I have two avenues that are now, for most intents and purposes, competitors. If I want a persistent label (for my own definition of persistency, since either way, these are still my labels), I can go with URN or info at my discretion. If I don't want persistency, and want to be anal about my interpretation of a URN, I'm sort of "encouraged" to go with "info".
It just seems counter-productive to create something brand new when a URN is probably going to be good enough. Maybe we just need to use urn:dyn or urd: or urt: instead of urn: if we want to make it very clear that the namespace underneath that will be dynamic.
It just bugs me when standards bodies go off and start considering two different implementations of something that overlap 99% in purpose.
Am I missing something? Is the persistency thing really that much of a blocker that a URN is so inappropriate that something else entirely needs to be invented?