Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why are URNs not more popular?

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Ask HN: Why are URNs not more popular?

#51

Post by bmn__ »

> Why are URNs not more popular? […] Why has it not catched on?

1. Usability: a developer must register a URN with IANA which is a huge hurdle compared with minting a URI which only requires control over an email address or domain name. http://enwp.org/Tag_URI_scheme>

2. Cumulative advantage: everyone knows how to dereference an IRI/URI/URL with the HTTP scheme because the software capable of doing so is deployed million-fold, and dereferencing may also lead to a representation describing the resource which is readable by humans and machines. One can't really do the same with URNs, or at the very least it's much less convenient.

3. Flexibility: if you mint a PURL http://enwp.org/PURL> with an extremely long lived redirecting service (e.g. http://w3id.org> or http://purl.org>), you are able to point the identifier to different resources, this indirection leaves you with options over the time of its existence. URNs have no redirects, they need to be perfect from the start, which is not a reasonable assumption when humans are involved.

Re: Ask HN: Why are URNs not more popular?

#52

Post by pbhjpbhj »

duskwuff wrote: post #9
cratermoon wrote: post #6

Earlier quoted context omitted.

How have I not heard of "Borges Encyclopedia" before? Thank you for pointing me this. And I 100% agree with the idea of the reification of subjects without buying into a formal hierarchy. As long as the system gets the right ideas into the heads of the right people, it's workable.

The specific reference is to the essay "The Analytical Language of John Wilkins", in which Borges likens an taxonomy proposed by Wilkins to a (almost certainly fictitious) Chinese encyclopedia which groups animals into fourteen categories: > (a) those that belong to the Emperor, (b) embalmed ones, (c) those that are trained, (d) suckling pigs, (e) mermaids, (f) fabulous ones, (g) stray dogs, (h) those that are includ…

That's a very creative way to say "I don't like your taxonomy". Serious commitment to the put-down.

Re: Ask HN: Why are URNs not more popular?

#53

Post by Kwpolska »

dagss wrote: post #39

OP here. Thanks for a lot of useful insights and references. An overall comment about a lot of the replies: A lot seem to say "you do not want to use URN because X" in much the same way I think that one might criticise JSON when JSON was launched: What is the point of using JSON? Don't you realize that both systems still need to agree on a custom protocol? Yet JSON is wildly successful. I could have worded my initial…

A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re working with a language that cares about types, you can also make idSource into an enum (so it’s harder to make a typo or implicitly forget about handling a value). And if your API offers a documentation (such as OpenAPI, or a GraphQL schema), the documentation will include a list of possible values, and tooling might even generate the nice enum for you.

Is it a standard? No. But does it need to be to be useful and obvious to everyone?

Re: Ask HN: Why are URNs not more popular?

#54

Post by strogonoff »

hobofan wrote: post #42
strogonoff wrote: post #33

Earlier quoted context omitted.

Content-addressed RDF (possibly with the help of hashlinks and/or ERIS) feels like another good way to solve data stability/mutability, without introducing a package manager in the mix.

Yes, for that side of the problem content-addressing is a good solution. I've also explored content-addressed RDF and OWL in a past project[0], based on IPFS and multiformats. While it gives you good certainty about stability, migrating semi-popular concepts across the ecosystem is a big pain, as you have to regenerate all dependent data (if you go the hardcore route). I think package managers are in general a pretty…

I’m not sure what you mean by “regenerated”. Sure, URNs will need to be updated to content-addressed ones, probably gradually, but you’d need to do the same to switch to a package manager.

Re: Ask HN: Why are URNs not more popular?

#55

Post by ElFitz »

TheCapeGreek wrote: post #27

There's something almost hinted at in some comments here that I'd like to raise. Often times the localised name for something might differ, despite being effectively the same piece of information. The a good example of this is the Google Places API[0] - if you just want to fetch the region of a place in a country, what you might actually be looking for could be one of several different things. Google abstracts this t…

In the same way all these American websites’ address forms insist on having everyone on Earth input a state. Or it’s equivalent. Even when there is no point to it, it makes no sense, and the country doesn’t have an equivalent.

Re: Ask HN: Why are URNs not more popular?

#56

Post by dagss »

Kwpolska wrote: post #53
dagss wrote: post #39

OP here. Thanks for a lot of useful insights and references. An overall comment about a lot of the replies: A lot seem to say "you do not want to use URN because X" in much the same way I think that one might criticise JSON when JSON was launched: What is the point of using JSON? Don't you realize that both systems still need to agree on a custom protocol? Yet JSON is wildly successful. I could have worded my initial…

A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re working with a language that cares about types, you can also make idSource into an enum (so it’s harder to make a typo or implicitly forget about handling a value). And if your API offers a documentation (such as OpenAPI, or a GraphQL schema), the documentati…

Agreed and in fact this is what is in our code even before I made the post. My main problem is that we have to invent this idSource string for all registries we support.

Re: Ask HN: Why are URNs not more popular?

#58

Post by cratermoon »

dagss wrote: post #7
cratermoon wrote: post #2

> Why are URNs not more popular? For the same reason that lots of general-purpose classification schemes are not popular: they are brittle and unstable. They smear information out into awkward and hard-to-reuse hierarchies. I refer you to https://www.gwern.net/docs/technology/2005-04-shirky-ontolog...

I don't really want to classify objects. I want to refer to a registration in a registry. Objects can of course be regidtered many places for many reasons but that is not my concern here. As long as I can serialize the tuple (registry-somone-made, id-in-that-registry) in a standard and readable way that would be a huge step forward

> I want to refer to a registration in a registry.

But that's not the question you posed in the original post. You asked about URNs, and the URN registry imposes a taxonomy. You're wanting a registry of identifiers classified by country and type. That's a taxonomy.

Why depend on someone else's registry? Make your own, don't worry about taxonomy, and use it.

Re: Ask HN: Why are URNs not more popular?

#59

Post by Kwpolska »

dagss wrote: post #56
Kwpolska wrote: post #53

Earlier quoted context omitted.

A JSON object can solve all your problems. {"idSource": "dkCRV", "value": "12345"} or {"idSource": "plPESEL", "value": "2137"} would be quite obvious. If you’re working with a language that cares about types, you can also make idSource into an enum (so it’s harder to make a typo or implicitly forget about handling a value). And if your API offers a documentation (such as OpenAPI, or a GraphQL schema), the documentati…

Agreed and in fact this is what is in our code even before I made the post. My main problem is that we have to invent this idSource string for all registries we support.

What does “support” entail? Whether “we print its friendly name on the invoice before its value” or “we validate it, fetch the business data from the national registries and auto-fill the rest of the form”, you still need some special handling and registration. In that case, you don’t save much by using an existing scheme, and you there is a bigger risk of someone providing a schema you don’t support.
Post reply on HN