If you can have human readable URLs and persistence then you should do that. That’s what we’ve done for Wildlife Finder – if you can only have one I would go for persistence.

I think I’ve also mislead you re what folks do vis-a-vis data entry. The data behind /programmes (and /music and Wildlife Finder) is stored within a database (as data not html) – to edit the info you see on a page nobody edits mark-up! No webmaster nor content producer. The webpage is generated dynamically from a web app – that’s true for all the representations (desktop, mobile and RDF/XML).

Thanks for the comprehensive reply!

Just to be clear from my standpoint I am absolutely in favour of digital preservation and understand the role of persistent ids in that world (afterall I do work for an organisation for whom it it a major preoccupation). I just hope that we can find a way to achieve that while maintaining human-readable URIs rather than the terrifying machine-generated identifiers I have seen suggested elsewhere. I can see why this might not be possible for an enormous dataset like /programmes but very few of us are operating on that scale.

Like I said in my post I do for the most-part think the BBC is a unique case in an awful lot of ways if for no other reason that you have content creators producing markup! In the 10 years I have been involved with large, information rich CMS driven websites I can only think of a tiny percentage of people who would be able/willing to do that (and I wouldn’t be one of them). It has been my experience that the majority of people publishing on websites I’ve been involved with never looked beyond the WYSIWYG view and only supplied the minimum amount of metadata to get published – the idea that they would add RDFa seems a long way off.

As for the files/folder thing – I regret writing that if I’m honest – not sure why it bugged me as its been a long time since I thought of websites in those terms – maybe it was nostagia!

As the person that said doing linked data is a hard is a myth and as one of the people on the side of persistence I thought I should try to explain where I’m coming from on a few things:

How hard is it? In my experience the thing that’s difficult is the basic IA – working out how to structure your information is difficult, but it’s difficult when designing and building any large site. Modelling is difficult. Publishing that information as RDF/XML is easy, it really is.

URLs human readable and persistence – if you can create human readable and persistent URLs than that is marvelous and you should do it. Indeed that’s what I’ve done with bbc.co.uk/wildlifefinder. But it’s not always that easy – when you have very large volumes of data (e.g. bbc.co.uk/programmes) creating human readable URLs is not practical: you could do it, but the cost would be prohibitive. And if I had to choose between human readable URLs and persistence I would go for persistence. But that’s not for linked data reasons, it’s because I think it’s important because people bookmark, link to and discuss your content using your URLs and it’s best not to break them.

Re files and folders – again this isn’t about linked data but a recognition that trying to define a mono-hierarchy isn’t intuitive as soon as you get lots of stuff. In my opinion modelling information and the relationships between bits of information in the way people think about it rather than shoehorning it into a file/folder structure makes sense.

FWIW none of this means that content needs to be mediated via a webmaster – at the BBC the none of the people creating content on e.g. /programmes, /music nor /wildlifefinder deal with mark-up none of it is done via a webmaster. They just author content.