Taking Pride and Prejudice, which has been several plays, radio plays and TV mini-series. This ambiguity was instrumental in going for a short opaque identifier. We were also thinking of creating identifiers that would be unique for 30-40 years, so not prone to the whims of a producer deciding that they had to have /programmes/prideandprejudice 5-10 years out and breaking the previous url. The Archers is too strong and persistent a brand to be useful in this case.

An amusing one is Bells on Sunday which is repeated on Monday morning…

The model that Amazon have since moved to with a unique URL identifier and an ignored pretty human readable section is a good compromise. Amazon also face the issue of multiple editions and formats for their books and DVDs etc.

thanks
Gavin

it’s been discussed yes. part of the trouble no-one wants to be /the_office_2 or /u2_2 and then things get political and you need human intervention

> Given all this, do you think it’s
> feasible/desirable to promote the
> opaque ids as magnets for chatter in
> the various -spheres?

YES :-) There’s a recent post on radiolabs discussing machine tagging the BBC that sets out some of it.

Also shonar is a prototype by Schulze and Webb that aims to track “buzz” around bbc programmes. It’s due to be integrated into /programmes at some point. For now it’s based on inbound links from blogs/twitter/etc but it could be expanded to use machine tags!?!

Not simple at all, in any domain. Namespace management is one of the hardest problems of all.

I’m sure you’ve thought about the possibility of decorating names with modifiers — sequence numbers, dates — to account for different programs using the same names.

But your points about resources to manage that system, and multiple languages, are well taken.

Given all this, do you think it’s feasible/desirable to promote the opaque ids as magnets for chatter in the various -spheres?

And many different programmes share the same name (there’ve been something like 7 “The Office”s over time). It’s made more difficult when you take into account not only all the programmes that may be made in the future but also the ambition to get all the programmes in the BBC archive into /programmes.

So whilst The Archers might be THE one and only Archers for now (and so be ok to sit at /programmes/the%20archers), there might be a different The Archers in the future (or in the past). When another The Archers goes into PIPs (the system that powers /programmes and iPlayer) then THE Archers would have to move URI to /programmes/:pid and we try to resist movement if at all possible.

Realise The Archers is a bit of a bad example here. It’s been around for decades and will probably be around for decades longer. I’m pretty sure there’s never been a different The Archers in the past and pretty certain no-one would be stupid enough to make a different The Archers in the future but the problem does exist for other programmes.

Whilst it’s fine for the period of time where names are unique, as more data gets added and uniqueness gets lost then stuff has to move…

You could build a system to manage human readable url keys over time and employ people to manage that system but I’m not sure that’s how I’d want my licence fee spent?!?

Finally there are plans to support multiple language variants of programme data (English, Welsh etc) which will hopefully sit at the same URIs and be content negotiated to the appropriate representation. In which case should the url key be english or welsh or opaque???

For such a simple thing as radio and telly programmes it does all get rather nastily complicated :-/

Thanks for your thoughtful response.

> – if there’s only one programme with that
> text in its name you’ll go directly to
> the programme as in http://www.bbc.co.uk
> /programmes
> /Kermode%20and%20Mayos%20Film%20Review

> – or if there are many programmes with
> that text in the name you’ll be taken to
> a disambiguation page as in
> http://www.bbc.co.uk/programmes/kermode

Well there you go. Beautiful! This works after all:

http://www.bbc.co.uk/programmes/The_Archers

This of course leads to the follow-on question: Should a system prefer to present the human-readable form when it is equivalent to a unique ID? In this case, for example, the system could resolve The_Archers to b006qpgr internally, as it does now, but hide the redirection.

This would signal to users that the human-readable form is available and in fact encouraged for interaction in the human realm. But it’s arguably wrong for robots, assuming that they aren’t prepared to deal with disambiguation. Unless of course they are, in which case we’re entering the scary zone of content negotiation.

Around and around we go!

Reading this I’m reminded that I really should get round to writing the blog post on the design decisions behind /programmes URIs that I’ve meant to write for the last year or so. They’ve been a source of contention inside and outside the bbc for quite a while but i think / hope there are sound reasons behind the final design.

Way back in 2004 Tom Coates wrote a blog post on developing a URL structure for broadcast radio sites that formed the foundations of the /programmes work. Since then numerous things have changed in both the data model and the pipes and conduits that feed it.

Afraid it’s all rather difficult to explain in the limited space of a comment box but factors we took into consideration were:

- cross network repeats (so no /radio3)
- programme name ambiguity (there are a lot of programmes called breakfast eg)
- programme brands that change name over time
- programmes that are never broadcast
- programmes from the archive
- the rather strange route that programme data takes before it reaches /programmes and iPlayer

Basically, human readable URIs are kinda nice (although not everyone speaks English and browsers are beginning to get to the language accept headers stage!?!) but persistence outweighs. And in almost every domain language and labeling change over time. Wiki|DBpedia have an easier job cos they’ve got a whole army of willing galley slaves to mint the webscale identifiers for them. Unfortunately most organisations aren’t so lucky.

For the record both /music and /programmes URIs are kinda hackable / guessable. If you type http://www.bbc.co.uk/programmes/programme_name:

- if there’s only one programme with that text in its name you’ll go directly to the programme as in http://www.bbc.co.uk/programmes/Kermode%20and%20Mayos%20Film%20Review

- or if there are many programmes with that text in the name you’ll be taken to a disambiguation page as in http://www.bbc.co.uk/programmes/kermode

The same’s true of /music so http://www.bbc.co.uk/music/artists/u2 gives you a disambiguation pages whereas http://www.bbc.co.uk/music/artists/stone%20roses takes you straight to the artist page. You don’t need to type the %20s – they’re just there for the benefit of wordpress comment processing – spaces work just as well. It’s a hackable feature of the URIs that we probably don’t make enough of…

Anyway, hope this explains a little. And I’ll try to write a post to explain more fully…

Michael

There are instances where we have content and Wikipedia doesn’t – in those instances we create new Wikipedia pages.

There might also be istances in the future were we could have problems – for example ‘World on the Move’ tracked individual animals, Big Cat does the same indeed lots of wildlife programmes do – I would like to have a URI for those animals but will the Wikipedia community think of these animals as sufficiently important to have a page? Possibly not – if that’s the case we’ll need to mint our own identifiers.

Glad you like the site and our design decisions, hopefully when we get radio content in there the site will become more engaging for those that live outside the UK .

Right. The example is predicated on the assumption that topics in natural science will, and that to the extent they do, BBC aggregations can align to that taxonomy.

This is an intriguing dilemma, of course. A URL namespace is a realm where the interests of computers/software/services intersect with the interests of humans/users/customers.

I can guess http://wikipedia.org/wiki/Madonna, and you’ll know what I (probably) mean, and it’ll at least partly work, by taking you to a disambiguation page.

I’ll never guess http://musicbrainz.org/artist/79239441-bfd5-4981-a70c-55c3f15c1287.html, and you’ll never know what I mean when you see it.

I don’t think that opaqueness and persistence are necessarily connected. The service that mints a namespace controls that namespace and determines its persistence. There are zillions of dead links of both sorts: opaque and readable.

Meanwhile, of course, thanks to Twitter, we are increasingly collapsing the readable names down to opaque IDs. Around and around we go!

The bottom line for me, though, is that computers and humans share the use of URL namespace. Computers don’t care, but humans bookmark URLs, copy and paste them, make lists of them, email them, blog them. Opaqueness adds considerable friction to these activities. Does it reduce friction elsewhere by an equal or greater amount? Maybe in some cases, but if so I’m not sure what they are.