91Èȱ¬

But of course, your programme identifiers (which humorously have recently all started with b00b!) aren't web-scale. Nobody else (e.g. ITV, Channel 4, HBO etc) can use your identifiers without risk of overlap.

Perhaps the 91Èȱ¬ should start a Program(me)Brainz system itself, or sponsor MusicBrainz to do so. You need someone who can be responsible for the identifiers and ensuring that two organisations don't use the same identifiers for different program(me)s...

I actually believe that the 3 Asimov rules, I mean semantic standards, are of decreasing importance:

1. URLs should be human readable
2. URLs should be hackable
3. URLs should persistently point to one concept

If 1 and 3 is not possible, then 1 takes priority.

Wikipedia does this quite well. If we use a similarly musical example, 'Queen' by itself will bring up a disambiguation list. 'Queen (Band)' will bring up the artist and 'Queen (Chess)' will bring up the playing piece. I know where I'm going to end up. If someone told me article 'sdkjh221' was about the band, there's no way to know until I visit it.

And let's say there were 2 bands called 'Queen' one would be 'Queen (1980s)' and the other would be 'Queen (2000s)'.

My lecturer in my database normalisation classes always made sure we understood that you rarely need to assign a random identity to an object. Unfortunately real life doesn't work out that way, as you have found. But experience has taught me that the manipulation of the original unique identifier is better than making one up your own.

Whilst inter-site compatibility is very important and a very useful tool, without some sort of consensus, there will be anarchy. Eventually the strongest will survive, and I'm willing to bet the ones that will survive are the ones that people can read.

I hope this makes some sense. It's a very abstract world and my explanation isn't very conclusive, certainly anecdotal. But I hope you can see that there are solutions out there that work, you just need a bit of imagination.

@mattcopp + @onpause Wikipedia's URLs are lovely to look at, nice-ish to type and swallowed whole by google but they're not persistent. They move as concepts are disambiguated. Somewhere in my head lurks a figure of 5% but since I don't know if that's per month, per year or forever it's a pretty useless figure. But even if that's the total movement over all time given the size of wikipedia that's a fair bit of shift. And obviously cool URIs don't change:

@ed + @onpause I suspect I've made myself misunderstood - I was certainly not claiming that b00c4wxm is globally unique.

The only true web-scale identifiers are URLs. They're how we uniquely identify and locate resources. I think we're all agreed there? But that's not quite what I'm talking about here.

In retrospect maybe this post should have been called 'Approximations of web-scale identifiers' but that's a bit of a mouthful. The bit I'm interested in is the fragment of the URL that's *almost* good enough to carry identity. So in the Panorama episode example a Google search for b00c4wxm returns 14 results and they're all about that episode on /programmes and iplayer. Now we know that that ID isn't globally unique and it's certainly not as powerful as a URL but it clearly carries some degree of unambiguous meaning

The same with derivadow. Again not globally unique. We could all register on a social network that Tom's not joined yet (cough) as derivadow. Now a google search for derivadow gives a fair few results but all the ones I'm seeing are our Tom. A search for 'Tom Scott' on the other hand brings back judges, musicians and mystery buyers. So while neither b00c4wxm (which doesn't start with b00b) nor derivadow are true web-scale identifiers they are pretty damn good approximations.

I should be able to type:

www.bbc.co.uk/programmes/rubbadubbers

and not have to remember:

www.bbc.co.uk/programmes/b0072hw8

If there is another programme called rubbadubbers then there should be disambiguation info at the readable url.

The 91Èȱ¬ partly encourages hackable urls. Why not extend that power to programmes and customers?

@ritchielee there's a task on our board to do just that. Should be there soon. In the meantime:

/programmes/a-z/rubbadubbers

does the job

I find the Wikipedia example interesting for two reasons that have nothing to do with each other:

1. The disambiguation aspect has been part of HTTP for a long time now via the 300 status code. Unfortunately because the main entry point to the web has been the browser for years now those kind of features have never really been implemented. They'd work well for automated processing.

2. English speaking speaker tend to forget that the rest of the World has to endure ugly URLs no matter what due to encoding issue. So the "readable URLs", although large in audience, is limited in its scope.

A follow-up, the 300 status code doesn't actually offer you a choice between multiple resources but between multiple representations of the same resource. That, of course, may not be what one wants.

Ok, I find this an interesting topic. Much could be read and written about it, and is. Thinking of the internet in database form (or RESTful) is quite a handy analogy.

I had to re-read your post to see what you were trying to acheive Michael, and now I see the purpose of using unique identifiers.

Musicians being creative types, database structure does not spring in to their minds when they chose their names. That is why there are 16 very similar Auroras. Wikipedia and Last.fm do get very conviluted about that subject, especially Wikipedia as it deals with much more than just artists.

Random and unique identifiers are quite a handy way of differentiating between them, and is only the really sensible way. But the problems with the length and that it's not human readable, but this is not the 91Èȱ¬'s fault, it's MusicBrainz who are trying to logicalize a very large and overlapping field.

I understand why you use MusicBrainz and not Wikipedia, because MusicBrainz is a consistant source.

I would ask though that when you are redirected to the artist page from the MusicBrainz style URL, you redirect the browser to the 91Èȱ¬'s identifier for that artist. Rather than just dumping us at /artist as the ting tings link above does.

> URLs should be human readable

I really don't understand how you consider the following to be human readable:
/music/artists/d5da1841-9bc8-4813-9f89-11098090148e

URLs should certainly contain the name of the artist / song that its describing.

Otherwise the URL of this blog post should be:
/blogs/radiolabs/2008/06/6fa26370-491f-11dd-ae16-0800200c9a66.shtml
Right? Otherwise you could run into some instance where there are TWO posts with the same name of "the_simple_joys_of_webscale_id" !!!!

Edge cases aren't worth trashing friendliness, hackability and usability.

99% of the artists won't have collision problems. So why would you don't design a system for 1% of your data set?

This comment was removed because the moderators found it broke the house rules. Explain.

This comment was removed because the moderators found it broke the house rules. Explain.