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'm really confused

[Gizzmonic]

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".

Domain squatters

[jmerelo]

That mean there'll be domain squatters in many different levels. And for free!

This is bad

[Cranx]

We already have top-level domains for that sort of thing. The resource identifier system (http:, gopher:, etc.) are already in-use and they're NOT used as namespaces.

We don't need this sort of half-thought-out component to the domain name system. If you're going to do anything with resource identifiers, make a change to BIND to allow DN servers to map them to A records.

You know what's going to happen. People are going to register these namespaces and use them instead of domain names. Then we're going to have two parallel systems: the name.dom style and the space:name style.

Dumb dumb dumb.

Re:Dibs

[Directrix1]

How do people find this good? Right now in XML you can just declare your namespace to be anything. So now you have to pay for it? Fuck that.

Here we go again.

[inertia187]

I remember radio ads way back in 1997, 98 where they'd read out the entire URL, which was excruciating:

"H T T P colon slash slash W W W dot (pause) whatever dot (pause) com"

Are we going to have to relive that if new namespaces are added?

Dewey Decimal is not a good example

[furrygeek]

Perhaps the Dewey Decimal classification isn't the best example. After all, it's not in the public domain [slashdot.org].

Re:This is bad

[valdis]

It's only dumb if you are thinking of using it for resolving actual Internet resources. In fact, if you actually *read* (gasp, shock) the draft, it's *really* about providing a *SYNTAX* so you can represent things like a Dewey Decimal number or a product number or the VIN of your car or....

Re:Some further possibilities

[Fnkmaster]

Yes, and unfortunately, like other semantic web-style proposals, it will take about 5 minutes to be abused so much by people trying to harvest clicks and user attention that it will rapidly become useless. If we can't rely on users to accurately list meta-keywords in HTML documents, why would any other such identifiers work better, without some sort of meaningful web-of-trust system built in?

Just a thought. I would hate to go looking for info:palm/model/P80900US and find 8 million links to people trying to get me to surf over to their porn site.

Re:Still need DNS equivalent...

[axlrosen]

The only things that need to be accessible is a list of the "namespaces" (i.e. the second-level bits). For example, it'll say that the "ddc" namespace is run by the Dewey Decimal Society (or whatever) and give their contact information. It won't resolve these URIs into resources, they way that a browser resolves a URL into a web page. (Though in some cases it may point to a resolver mechanism.)

Don't expect to type these into your browser and view the results. This system is more for tagging and identification, not resolution.

UR* Jungle...

[oren]

Quick, without peeking at the answer [w3.org], 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 [ietf.org] 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...

relationships with DOI?

[deepsky]

Looks to me this proposal is another way of uniquely tagging digital content.
Could someone explain if and how this proposal is somehow similar to (or different from) the Digital Object Identifier [doi.org] standard (DOI)? DOI, although proprietary (like EAN, UPC, etc) is gaining momentum; for example, here in Italy is going to be adopted as a general standard for the public administration documents.

Re:important info

[sreilly]

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

There is a big difference between not requiring a resolution mechanism and not assuming a resolution mechanism. It may very well be that a client knows how to resolve info:dcc/* but not info:ssn/* URIs. The point is that info: URIs will identify objects, rather than specify one location where a digital instance of the object may be accessible.

URIs have become the de-facto standard for referencing documents on the Internet. Don't you think it is more useful to reference documents/objects by their unique ID rather than a URL where one instance of that document may reside?

As for not being useful without a resolution mechanism... are you saying that ISBN's, SSN's (if in the USA), and UPC barcodes aren't useful? This URI scheme simply provides a way to identify objects (digital or not) using a common identification scheme. The resolution mechanism can be added after the fact (or not, depending on the type of object, or how it is used).

Re:Potential for abuse by stupid people

[DongleFondle]

That's a really good point and probably a very likely scenario considering some people who probably don't consider themselves "stupid people" damn-near post the SOC in their ./ sig.

*sigh*

Why not URN?

[Fastolfe]

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?

This is ridiculous!

[getnuked]

Everyone will become totally confused, not only because this is a new obfuscated URI scheme, yet because there is a .info TLD [afilias.info]!