Re: [backstage] BBC News - Googlejuice vs Usability
what's a reading score, brian? Best Cs Sent from my iPhone On 20 Nov 2009, at 12:55, Brian Butterworth briant...@freeview.tv wrote: 2009/11/20 John O'Donovan john.odono...@bbc.co.uk Thanks Mo, Hi Brian. We thought long and hard about this, but basically we think it's an improvement. Surely the idea should be to demonstrate that something is an improvement, rather than just changing it. As I pointed out if you calculate the reading score for these longer headlines, they score higher, meaning they are less good to those (unlike ourselves) who have lower reading skills. For higher skilled people, they just take longer to scan. If you said it was for SEO, that would be fine. But for usability, it sucks. For example, this headline may be short, but what is the article really about? http://news.bbc.co.uk/1/hi/7390109.stm Great tits cope well with warming That's just a fantastic headline. As an example, I think for this story: http://news.bbc.co.uk/1/hi/business/8369764.stm Procter Gamble recalls 120,000 Vicks nasal sprays ...is much clearer than... Thousands of Vicks spray recalled Especially if you don't know what Vicks is. Why would I be interested in this story if I don't use the product. I would suspect that MORE people don't know what a Procter Gamble is. John O'Donovan Chief Technical Architect BBC Future Media Technology (Journalism) BC3 C1, Broadcast Centre, 201 Wood Lane, London http://news.bbc.co.uk/ http://news.bbc.co.uk/sport/ http://news.bbc.co.uk/weather/ -Original Message- From: owner-backst...@lists.bbc.co.uk [mailto:owner-backst...@lists.bbc.co.uk] On Behalf Of Mo McRoberts Sent: 20 November 2009 11:57 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] BBC News - Googlejuice vs Usability On 20-Nov-2009, at 11:45, Brian Butterworth wrote: Here's a nice little dillemma. http://www.bbc.co.uk/blogs/theeditors/2009/11/ changing_headlines.html BBC News headlines go from 33 characters (because of Ceefax) to 66 One the one hand, king of usability Jacob Neilson has said the BBC News headlines are the world's best http://www.useit.com/alertbox/headlines-bbc.html On the other, Google likes lots of relevant keywords, the higher the reading score the better in fact. It's not like BBC News comes bottom of any Google search, is it? My question - which is more important, SEO or usability? Given the context: short headlines on the linking pages, longer headlines on the pages themselves, I'd suggest it strikes a good balance. However, I can't stand the short headlines. Everything's phrased as though it's a lie. Yes, I know the reasons, it still reads terribly, no matter what Neilson reckons. So in fact, I'd actually prefer to see the longer headlines all of the time (which does SEO no harm at all). BBC headlines 'lengthened'. M. -- mo mcroberts http://nevali.net iChat: mo.mcrobe...@me.com Jabber/GTalk: m...@ilaven.net Twitter: @nevali Run Leopard or Snow Leopard? Set Quick Look free with DropLook - http://labs.jazzio.com/DropLook/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html . Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ -- Brian Butterworth follow me on twitter: http://twitter.com/briantist web: http://www.ukfree.tv - independent digital television and switchover advice, since 2002
RE: [backstage] Free as in 'Free Bird'
...and this bird you cannot chay... ay-ayee-a-ay-a-ay-ange...
RE: [backstage] 4oD + Facebook Connect = TestTubeTelly
I checked this out late last week. Very cool promising! I want to spend more time with it now! -Original Message- From: owner-backst...@lists.bbc.co.uk on behalf of Tom Loosemore Sent: Mon 7/13/2009 11:48 AM To: backstage@lists.bbc.co.uk Subject: [backstage] 4oD + Facebook Connect = TestTubeTelly http://blogs.channel4.com/platform4/2009/07/13/4od-facebook-test-tube-telly/ - Few 1000 C4 programmes on demand with Facebook-powered social nav. Also includes broadcaster's stuff from their YouTube channels. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] Radio Pop
genius stuff guys! -Original Message- From: [EMAIL PROTECTED] on behalf of Ian Forrester Sent: Wed 9/3/2008 6:01 PM To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Radio Pop http://backstage.bbc.co.uk/news/archives/2008/09/radio_pop_goes.html And lots of APML ;) Ian Forrester This e-mail is: [x] private; [] ask first; [] bloggable Senior Producer, BBC Backstage Room 1044, BBC Manchester BH, Oxford Road, M60 1SJ email: [EMAIL PROTECTED] work: +44 (0)2080083965 mob: +44 (0)7711913293 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tristan Ferne Sent: 03 September 2008 17:37 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Radio Pop Hello everyone, Thanks for checking Radio Pop out and keep those bug reports coming. Radio Pop - tracklistings - last.fm is certainly on the list of things to look at. Specially for Backstage-type people there's an API you might want to look at http://www.radiopop.co.uk/api, including using OAuth to submit data to Radio Pop. Get in contact if you want to use it. Looking forward to the next Track Playing revision. Tristan - Tristan Ferne Senior Development Producer, RD Future Media Technology for BBC Audio Music Interactive http://www.bbc.co.uk/blogs/radiolabs/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Riley Sent: 03 September 2008 16:08 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Radio Pop Hi Dafyd, From the looks of it Radio Pop is only intended to record the radio programmes you're listening too, not the music. But I guess it wouldn't be too hard for them to add in the link between the programmes you've listened to and the track listing for those programmes to extrapolate some more information about your music taste, and ultimatly chuck that at last.fm Until then though it looks like I might be able to add support for Radio Pop to my Track Playing website - http://www.trackplaying.com - it is quite a nice fit. If you are using Track Playing to find out about the artist playing on the radio, I then know what radio station you're listening to and can tell Radio Pop, and let you Pop aswell. And with the further update I want to make to Track Playing of having it scrobble the track information to last.fm, I might have quite a nice little service going on! FYI I've been making constant updates to Track Playing over the last week, but I'll post more on those later. All in all well done to the Radio Labs team, looks like a nice little prototype you've built there! (Note the link to widgets on http://www.radiopop.co.uk/help links to http://www.radiopop.co.uk/pulse, and that says Page not found.) Cheers, Chris 2008/9/3 Dafyd Jones [EMAIL PROTECTED] Don't think this has been posted to the list yet: Radio Labs' Radio Pop [http://www.radiopop.co.uk]. Social radio? Fit! Now, who's going to get it to talk nicely to Last.fm...? Blog post at http://www.bbc.co.uk/blogs/radiolabs/2008/09/radio_pop_social_radio_listeni.shtml. D. -- e: [EMAIL PROTECTED] w: www.dafyd.me.uk m: 07834 356 324
RE: [backstage] Radio now playing feeds
because computers are evil, dude! ;-) -Original Message- From: [EMAIL PROTECTED] on behalf of Brian Butterworth Sent: Fri 8/1/2008 5:34 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Radio now playing feeds Backstage people might enjoy this thread: http://www.guardian.co.uk/commentisfree/2008/jul/31/internet.internetipos 2008/8/1 Michael Smethurst [EMAIL PROTECTED] the other issue is around our legal agreements with the music industry around how much timing data we can give out for tracks playing O RLY? Would you be kind enough to expand on what the issues are? Unless you can't give it out for legal reasons of course! yup, u got me. not legal reasons but complete lack of expertise. sure other people are in a better position to answer... I look forward to finding out why you can take many music tracks and broadcast them from thousands of high power transmitters and satellite covering the whole of Europe, and on the internet and then you can't list them. -- Brian Butterworth http://www.ukfree.tv - independent digital television and switchover advice, since 2002
RE: [backstage] Quick idea for BBC News video
much of the BBC News video and audio does autostart, no? for instance: http://news.bbc.co.uk/1/hi/sci/tech/7489776.stm best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Mr I Forrester Sent: Fri 7/4/2008 12:18 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Quick idea for BBC News video -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm not so sure, its actually a good idea I think. A simple querystring element which starts the video as soon as possible. I'll put it in our ideas section, including your reason why not :) Peter Bowyer wrote: You pretty much talked yourself out of that one, then :-) Peter 2008/7/4 Matt Barber [EMAIL PROTECTED]: Hi, just browsing the news and I wanted to send a link to a friend, and was wondering if it would be good to have a switch we could append to the URL, to make the video play automatically. Unsure if this would in some ways be detrimental - i.e. I could then force someone to unwittingly start a video, and at work with the sound up that could cause problems for some people, also maybe it's a feature that noone would use... but yeh, just a thought. As it's said, the signal is the noise! Ta, Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIbgb4QiJ2fWCDT3cRArnVAJ0Wgi5kbHA5BYTg98RO4pBx63EkwACdF/iK yWnszMfbrFtqlvTUJ3rZr+I= =WdIV -END PGP SIGNATURE- - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] BBC Topics - in beta
there are a few machine readable page types available: http://www.bbc.co.uk/programmes/developers#alternateserialisations more to come quite soon. (warm up that triple store) best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Tom Loosemore Sent: Fri 6/6/2008 11:16 AM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] BBC Topics - in beta lovely... really solid start IMHO... so when do we get machine readable versions of /topics ? They were promised soon for /programmes when that launched back in Oct 2007? ;o) 2008/6/5 Brian Butterworth [EMAIL PROTECTED]: James, This does, indeed, look very promising. I'm hoping that we can have automatic links to these pages from the BBC News and other content pages. 2008/6/4 James Cridland [EMAIL PROTECTED]: For those of you who don't read the (full RSS feed) at http://www.bbc.co.uk/blogs/bbcinternet/ you might have missed out on today's announcement - http://www.bbc.co.uk/blogs/bbcinternet/2008/06/bbc_topics_in_beta.html With my personal developer hat on, I was impressed at Matt's bit of FAQ in his post that says: Can I get the feeds and build them into my own website or personal feeds? Yes, feeds will be available soon. Oooh. j -- Brian Butterworth http://www.ukfree.tv - independent digital television and switchover advice, since 2002 - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] Soundindex
good suggestions, chris -- and what you describe is indeed the general plan... i think Sound Index is undergoing a public value trial, tho, so its fate is not absolutely clear. i agree that it has fantastic potential, tho, and is headed in the right direction... best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Chris Jackson Sent: Wed 5/21/2008 4:57 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Soundindex 2008/5/20 Peter Bowyer [EMAIL PROTECTED]: This has to be a target for Backstage http://uk.techcrunch.com/2008/05/20/bbcs-sound-index-is-good-but-we-wont-get-the-data/ Really good to see the BBC producing interesting aggregations of activity on the web. However, it is a shame that Soundindex it is not integrated with the excellent pages driven by musicbrainz under http://www.bbc.co.uk/music/ The /music/ site does a great job of indexing the many places across the BBC where an artist is featured, as well as reviews and samples etc. Soundindex offers no path to all that good stuff. For example, compare content on the The Ting Tings pages: http://www.bbc.co.uk/music/artist/fmbd/ vs. http://www.bbc.co.uk/soundindex/profiles/artist/?id=811 Maybe an RSS hack could take the Soundindex ordering, but link back to the /music page, joining on a suitable 3rd party URL? Chris - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage-developer] Accessing http://www.bbc.co.uk/programmes/a-z from PHP
that threw me too, but it's the last element of each broadcast: start2008-04-28T00:50:00+01:00/start best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Brian Butterworth Sent: Tue 5/20/2008 9:34 AM To: backstage-developer@lists.bbc.co.uk Subject: Re: [backstage-developer] Accessing http://www.bbc.co.uk/programmes/a-z from PHP 2008/5/19 Paul Clifford [EMAIL PROTECTED]: Add .xml to the end of a schedule URL to get an XML representation, or .json for JSON. The format of the .xml and .json representations isn't fixed yet, but we're interested in any feedback from people using them. The XML (ie http://www.bbc.co.uk/bbcfour/programmes/schedules/2008/04/28.xml) has: duration3600/duration end2008-04-29T04:10:00+01:00/end Which is bit of an odd way of presenting schedules, even if it there is a certainly logic to it. Might be easier for general use to have the start as well? -- Brian Butterworth http://www.ukfree.tv - independent digital television and switchover advice, since 2002
RE: [backstage] b00b3zjr
that query string isn't very cool, tho, is it? ;-) --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Dan Brickley Sent: Mon 4/28/2008 8:48 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] b00b3zjr Jonathan Tweed wrote: On 28 Apr 2008, at 16:53, Dan Brickley wrote: http://www.bbc.co.uk/iplayer/page/item/b00b3zjr.shtml?src=ip_mp Page Three Teens Whose cool URI is that? We are not worthy :) Yeah we've been having a good laugh about that one in the PIPs team. I swear it wasn't deliberate ;-) We even removed the vowels from pids to stop things like this, but we forgot about the numbers that look like letters... Oh, how awful. You must have been horrified when you realised your mistake. Still, cool URIs don't change so I guess you're stuck with it! Dan -- http://danbri.org/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] b00b3zjr
google will crawl these as 2 different pages, no? http://www.bbc.co.uk/iplayer/page/item/b00b3zjr.shtml?src=ip_mp http://www.bbc.co.uk/iplayer/page/item/b00b3zjr.shtml that seems a real shame. helpfully (?), Google can hide all this a bit with its In order to show you the most relevant results, we have omitted some entries very similar to the 17 already displayed. If you like, you can repeat the search with the omitted results included approach... but then that's just sweeping awkward uncool URIs stuff under the rug, IMHO. witness: http://www.google.co.uk/search?q=site:www.bbc.co.uk/iplayer+Page+Three+Teens+b00b3zjrfilter=0 4 distinct pages in the google index, in total... that's because of the use of the query string when linking thru to the iPlayer episode page. seems a shame, following the don't make me think! school of web product design, to ask search engine users to parse thru more than one google choice for what amounts to the same page/episode... but hey, that's just me. and i love that it's the Page Three Teens programme and b00b in the URL that's brought this up. brings a certain refreshing silliness to the typical cool URI proceedings, i feel. best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Jonathan Tweed Sent: Mon 4/28/2008 9:15 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] b00b3zjr But the right thing to do in this example. A resource shouldn't have different URLs depending on where you click from, so if you can't track the outgoing link for some reason then a query parameter seems correct to me. But as you already know, I do definitely prefer the much nicer http:// www.bbc.co.uk/programmes/b00b3zjr for the URL itself ;-) Cheers Jonathan On 28 Apr 2008, at 21:00, Chris Sizemore wrote: that query string isn't very cool, tho, is it? ;-) --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Dan Brickley Sent: Mon 4/28/2008 8:48 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] b00b3zjr Jonathan Tweed wrote: On 28 Apr 2008, at 16:53, Dan Brickley wrote: http://www.bbc.co.uk/iplayer/page/item/b00b3zjr.shtml?src=ip_mp Page Three Teens Whose cool URI is that? We are not worthy :) Yeah we've been having a good laugh about that one in the PIPs team. I swear it wasn't deliberate ;-) We even removed the vowels from pids to stop things like this, but we forgot about the numbers that look like letters... Oh, how awful. You must have been horrified when you realised your mistake. Still, cool URIs don't change so I guess you're stuck with it! Dan -- http://danbri.org/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/ mailing_list.html. Unofficial list archive: http://www.mail- archive.com/backstage@lists.bbc.co.uk/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] What would you love to see coming out of BBC Vision in the near future?
I think we absolutely agree in principle, richard, great suggestions and advice... Within an organisation such as the BBC, maybe what is most important in the first instance is a common set of principles for managing and publishing IDs rather than a one size fits all system? -- agreed, and that lingua franca is no doubt going to be (is already starting to be) URI identifiers exchanged (internally in the 1st instance) over HTTP... so, in many cases this is in the form of system-namespace/GUID : http://some.internal.system.bbc.co.uk/ba853904-ae25-4ebb-89d6-c44cfbd56thy (which for instance, might mean the iPlayer genre Drama to that system...) and then there's going to need to be an equivalency engine which helps map between all the different systems across the Beeb which know about and have an ID for, say, Torchwood series 2 episode 6 or Jonathan Ross... there's no one true ID or URI for these concepts... how true does that ring for you? and, though I really don't want to start a what does a URI represent? or who's more Restful? flame war, I'm interested in unpacking what you mean by the musicbrainz example should be a location where you find out information about ³Blur²... isn't that what the following URL does? http://musicbrainz.org/artist/ba853904-ae25-4ebb-89d6-c44cfbd71bd2.html i.e. that URI is a location where you find out metadata about Blur, isn't it? BTW, I'm thinking about all this in terms illustrated by the following: http://www.w3.org/DesignIssues/LinkedData.html http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ http://ivanherman.wordpress.com/2007/10/12/wikipedia-uri-s-as-reliable-identifiers-for-the-semantic-web/ http://fgiasson.com/blog/index.php/2007/05/22/browsing-musicbrainzs-dataset-via-uri-dereferencing/ best-- --cs ** From: [EMAIL PROTECTED] on behalf of Richard Cartwright Sent: Thu 3/6/2008 10:13 AM To: BBC Backstage Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? Hi Chris It¹s not the size or form of your ID that matters, it is what you do with it that counts ;-) For UUIDs, UMIDs or URLs, you need a common understanding of what happens to them in inevitable change. I think of one use for a URL as a reference to a location where content can be expected to change, such as a news service home page, whereas I consider a UUID is immutable, it refers to one item of content for ever. Create a new version of the content and you have to create a new ID. However, this is a way of thinking and true for most ID schemes ... it all depends on how you choose to manage your identifiers. My excursion into the world of AAF has taught me a lot about comprehensive techniques for structuring and managing IDs for, and relationships between, all kinds of different media material. Most of what AAF is about is structural metadata, how one thing relates to another in a package, along a timeline, encoded with a particular codec etc.. This allows you to trace relationships between content through its various authoring stages back to its original source, a kind of super edit decision list. Structural metadata can be enhanced with descriptive metadata, normally using a schema of your own choosing as there is limited agreement between organisations about what this should be. So to build and expose your EverythingBrainz, perhaps what is needed is an API for exploring structural relationships between items of content, perhaps based on UUIDs, and an API for searching on descriptive metadata (actors, locations, scripts, awards) that may return results including related UUIDs? These APIs could be WSDL or ReSTful in style. For example, I personally think the musicbrainz example should be a location where you find out information about ³Blur² ... http://musixbrainz.org/artist/blur Where an item is currently published is really an item of descriptive metadata. Every generation of the page should have its own ID within a content management system and the published URL refers to the currently published version. The API I propose would allow you to find out the ID of the currently published version and, with appropriate permissions, to explore previous versions of the page via ID relationships. UUID, URL, maiden name, doesn¹t matter as long as the relationships are consistent. In summary, I believe that you could use many different ID schemes and many different descriptive metadata schemas. The important things are: understanding relationships between IDs are how they managed over time; how to map between the ontologies of the various different descriptive schema. Within an organisation such as the BBC, maybe what is most important in the first instance is a common set of principles for managing and publishing IDs rather than a one size fits all system? Cheers, Richard On 4/3/08 23:17, Chris Sizemore [EMAIL PROTECTED] wrote: cool stuff richard. so how do/should we expose
[backstage] speaking of identifiers that scale to the Web...
FW: [Linking-open-data] EXTENDED DEADLINE: Identity and Reference onthe Semantic Web (IRSW2008) at ESWC2008 -Original Message- From: Giovanni Tummarello [mailto:[EMAIL PROTECTED] Sent: Fri 3/7/2008 3:42 PM To: Linking Open Data Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; DERI Research Subject: [Linking-open-data] EXTENDED DEADLINE: Identity and Reference onthe Semantic Web (IRSW2008) at ESWC2008 Due to many requests , we are extending the deadline for Papers and Extended Abstracts to March 13 * . Thanks for your interest! ** our apologies if you receive multiple copies of this message ** == CALL FOR PAPERS ESWC 2008 Workshop Identity and Reference on the Semantic Web (IRSW2008) Entity-centric Approaches to Information and Knowledge Management on the Web Tenerife, Spain - June 1 2008 http://www.okkam.org/IRSW2008 == The recent developments of the Semantic Web - and the fast rise of Web 2.0 applications - make more and more evident that the problem of identity and reference through URIs is perhaps the single most important issue for fostering the Semantic Web on a global scale. In a nutshell: the effective use of the Semantic Web on a global scale requires the systematic reuse of stable and global URIs. This in turn requires that there exist decentralized agreement on how URIs can be used to identify and refer to the same object. So far, uniqueness of URIs and reference have often been taken for granted. Initiatives like Linked Data, OntoWorld and the large number of proposals aiming at using popular identifiers (e.g. Wikipedia's) as canonical URIs (especially for real world objects that aren't accessible on the Web) show that a solution to this issue is both urgent and relevant. Solving this issue would enable and foster the decentralized and open publication of data on the Semantic Web, would allow better and faster semantic search engines, would be the basis for a new generation of Semantic Web browsers, would start the development of smarter applications on the Web. Other vertical (and often commercial) initiatives (like XRIs, LSID, DOI, etc.) prove that there is also a practical and business potential in a standard solution. So far, there is little agreement on how this problem should be addressed and solved. On the one hand we need to address technical issues: * How do we make sure that people and applications can find and reuse pre-existing URIs for different types of entity? * Is HTTP the most appropriate addressing scheme for these URIs? * Should URIs for commonly identified entities, like people, organizations or countries, be managed by a central service? If so, under what conditions? * Are centralized registries of URIs for different types of entities necessary? Can such a registries be built in a decentralized manner while still linking data? There are also issues of trust and security: * What if the same URI is used to make contradictory or undesired statements about an entity? * Do people or groups really want that a single URIs is consistently used to represent knowledge about them on the Web, one that could be used to effectively gather data about them? * What is an acceptable level of security for any kind of URI registry? * Where is the boundary between describing entities and violating their privacy? Despite the high level of awareness in the community, the potential for the integration of information currently published on the Semantic Web is still mostly unexploited. FOAF profiles do not have canonical and reusable URIs for pointing to people one knows (only ad hoc solutions are available, like the email hashcode); the most popular ontology editors mint new URIs for any newly started OWL project; social networks are not easily portable. Starting from such a situation, this workshop aims at collecting contributions which can roughly be grouped as follows: * Foundations: formal and conceptual theories of identity and reference for the Semantic Web * Vision papers: visionary solutions to the problems of identity and reference * Project papers: descriptions of research development projects in this area * Experiences: contributions from research and industry that illustrate case studies or approaches to deal with the issues of identity and reference * Critical viewpoints: discussions of advantages and disadvantages of previously proposed approaches. We especially encourage contributions from groups or organizations which are working on identification schemes for large semantic data collections, in order to compare the
RE: [backstage] What would you love to see coming out of BBC Vision in the near future?
anyone got any thoughts or experiences with the UUID system for uniquely identifying objects mentioned below? in our collective opinion and experience, is there anything like that, or close to that, in existence yet? does MusicBrainz qualify in terms of Music object identification and IDs? best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of David Greaves Sent: Tue 3/4/2008 12:23 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? Ian Forrester wrote: Hi All, I was hoping to get a brainstorm of ideas for APIs and Feeds you would love to play with in the near future, while focusing on Vision/TV I got most of the obvious stuff like, - A reference page or service for all programmes (/programmes in XML) - keywords Anything more? I'm not sure of the scope of the above points... Given concepts like crossover and product placement it may be worth looking at in-program timing of generic 'objects'. eg: 25:00-26:23 Music: Band:Ah-ha Track:Take On Me Album:... 25:00-26:23 Actor: Bruce Lee Character: Benny 25:00-26:23 Product: Coca Cola 25:00-26:23 Actual Location : Slough GPS-coords:39729358734652 25:00-26:23 Fictional Location : Monaco for *that* famous scene :) This does not need to be commercial - I could see it being used to identify concepts in educational material too. Who does this? Well, collaborative approaches could be used (FreeDB/CDDB worked), some companies would provide product/media info (would need guidelines), some programme makers would find it added value (education) - heck maybe an actor's agent would provide the data as part of the service (or the actor themselves if they were on the 'bronze' package ;) ) Clearly this works when it's about providing meta-information rather than links to a page. Those come from the apps using the meta-data. Tied to this (and many of the other points raised) would be a UUID system for uniquely identifying objects, resolving duplicates and possibly establishing relationships. Clearly one or two minor issues to resolve but... David - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] What would you love to see coming out of BBC Vision in the near future?
cool stuff richard. so how do/should we expose GUIDs to the outside world, in a sorta Web kind of way? cause it's not enough to just generate unique IDs internally, we also have to broadcast their, um, meaning to the world at large... in other words, seems like you need the ID, some metadata to describe the thing ID'd, and a publishing/broadcasting mechanism so that other people/systems know you have info to communicate. a la: http://musicbrainz.org/artist/ba853904-ae25-4ebb-89d6-c44cfbd71bd2.html sounds like the Web to me... and MusicBrainz, for instance, is an example of all of the above, no? but now, don't we need an EverythingBrainz (as a colleague of mine recently put it)? (BTW, i'm a person that feels that URLs, by definition, are GUIDs) best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Richard Cartwright Sent: Tue 3/4/2008 5:31 PM To: BBC Backstage Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? Chris I¹ve a lot of recent experience with 16-byte UUIDs for identifying content (RFC 4122) and the slightly more media-savy 32-byte Unique Material Identification (UMID) from SMPTE (SMPTE 330M). Both standards are the basis for the Advanced Authoring Format, an industry standard used by video production tools from companies such as Avid and Quantel, and the related Material Exchange Format (MXF) used for production material interchange and now supported by a number of broadcast quality cameras, transcoders etc.. UUIDs are also known as GUIDs and are common to Microsoft Windows OS. Many unix OSs have a ³uuidgen² command to create UUIDs. Java has a ³java.util.UUID² class for generating and representing UUIDs. UUIDs are very well supported and have been the subject of some interesting security issues as without careful use they can expose your host ids outside your network. I am working on a media-specific Java API for AAF and MXF that includes support for UUIDs and UMIDs. Both can be generated at source and, as long as a consistent generation strategy is used, should be globally unique. Richard On 4/3/08 12:40, Chris Sizemore [EMAIL PROTECTED] wrote: anyone got any thoughts or experiences with the UUID system for uniquely identifying objects mentioned below? in our collective opinion and experience, is there anything like that, or close to that, in existence yet? -- Dr Richard Cartwright media systems architect portability4media.com [EMAIL PROTECTED] mobile +44 (0)7792 799930
RE: [backstage] What would you love to see coming out of BBC Vision in the near future?
wow, now that's a cool idea. any BBC DMI guys lurking on the list? -Original Message- From: [EMAIL PROTECTED] on behalf of Michela Ledwidge Sent: Wed 3/5/2008 1:08 AM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? BBC Vision edit log data would be good. Lots of useful meta-data there. As for getting the meaning out there. GUIDs might be less important than being able to perform semantic queries on whatever naming conventions exist already around the Beeb. e.g. creating a pool of edit log data and opening it up for SPARQL queries would perhaps be very useful. Not necessarily that useful having a particular tape ID as a GUID The ability to run queries over film/video logs, typically only viewed by editors, would no doubt reveal gems for repurposing and redistribution, let along allowing the Beeb to track and re-use source material better. Cheers .M. On Wed, Mar 5, 2008 at 10:17 AM, Chris Sizemore [EMAIL PROTECTED] wrote: cool stuff richard. so how do/should we expose GUIDs to the outside world, in a sorta Web kind of way? cause it's not enough to just generate unique IDs internally, we also have to broadcast their, um, meaning to the world at large... in other words, seems like you need the ID, some metadata to describe the thing ID'd, and a publishing/broadcasting mechanism so that other people/systems know you have info to communicate. a la: http://musicbrainz.org/artist/ba853904-ae25-4ebb-89d6-c44cfbd71bd2.html sounds like the Web to me... and MusicBrainz, for instance, is an example of all of the above, no? but now, don't we need an EverythingBrainz (as a colleague of mine recently put it)? (BTW, i'm a person that feels that URLs, by definition, are GUIDs) best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Richard Cartwright Sent: Tue 3/4/2008 5:31 PM To: BBC Backstage Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? Chris I¹ve a lot of recent experience with 16-byte UUIDs for identifying content (RFC 4122) and the slightly more media-savy 32-byte Unique Material Identification (UMID) from SMPTE (SMPTE 330M). Both standards are the basis for the Advanced Authoring Format, an industry standard used by video production tools from companies such as Avid and Quantel, and the related Material Exchange Format (MXF) used for production material interchange and now supported by a number of broadcast quality cameras, transcoders etc.. UUIDs are also known as GUIDs and are common to Microsoft Windows OS. Many unix OSs have a ³uuidgen² command to create UUIDs. Java has a ³java.util.UUID² class for generating and representing UUIDs. UUIDs are very well supported and have been the subject of some interesting security issues as without careful use they can expose your host ids outside your network. I am working on a media-specific Java API for AAF and MXF that includes support for UUIDs and UMIDs. Both can be generated at source and, as long as a consistent generation strategy is used, should be globally unique. Richard On 4/3/08 12:40, Chris Sizemore [EMAIL PROTECTED] wrote: anyone got any thoughts or experiences with the UUID system for uniquely identifying objects mentioned below? in our collective opinion and experience, is there anything like that, or close to that, in existence yet? -- Dr Richard Cartwright media systems architect portability4media.com [EMAIL PROTECTED] mobile +44 (0)7792 799930 -- MOD Films http://modfilms.com +44 208 144 8981 (UK) +61 2 8003 4811 (AU)
RE: [backstage] What would you love to see coming out of BBC Vision in the near future?
oh, but you mention SPARQL queries, so doesn't that mean that we'd need full resource/RDF/URIs approach at least internally at the Beeb? or at least the capability and internal structure and data model in place internally to publish our data out to the world at a SPARQL end-point? to really offer SPARQL GUIDs are probably neither here nor there, but we'd need to do pretty well with URIs, no? personally, i liked the suggestion earlier to use dBpedia.org URIs as a starter lingua franca of URIs... clearly that wouldn't be relevant for IDing many of the resources pertinent to the editing suite, but even there it'd be relevant for some (people the video clip was about, etc) best-- --cs -Original Message- From: Chris Sizemore Sent: Wed 3/5/2008 6:38 AM To: backstage@lists.bbc.co.uk; backstage@lists.bbc.co.uk Subject: RE: [backstage] What would you love to see coming out of BBC Vision in the near future? wow, now that's a cool idea. any BBC DMI guys lurking on the list? -Original Message- From: [EMAIL PROTECTED] on behalf of Michela Ledwidge Sent: Wed 3/5/2008 1:08 AM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? BBC Vision edit log data would be good. Lots of useful meta-data there. As for getting the meaning out there. GUIDs might be less important than being able to perform semantic queries on whatever naming conventions exist already around the Beeb. e.g. creating a pool of edit log data and opening it up for SPARQL queries would perhaps be very useful. Not necessarily that useful having a particular tape ID as a GUID The ability to run queries over film/video logs, typically only viewed by editors, would no doubt reveal gems for repurposing and redistribution, let along allowing the Beeb to track and re-use source material better. Cheers .M. On Wed, Mar 5, 2008 at 10:17 AM, Chris Sizemore [EMAIL PROTECTED] wrote: cool stuff richard. so how do/should we expose GUIDs to the outside world, in a sorta Web kind of way? cause it's not enough to just generate unique IDs internally, we also have to broadcast their, um, meaning to the world at large... in other words, seems like you need the ID, some metadata to describe the thing ID'd, and a publishing/broadcasting mechanism so that other people/systems know you have info to communicate. a la: http://musicbrainz.org/artist/ba853904-ae25-4ebb-89d6-c44cfbd71bd2.html sounds like the Web to me... and MusicBrainz, for instance, is an example of all of the above, no? but now, don't we need an EverythingBrainz (as a colleague of mine recently put it)? (BTW, i'm a person that feels that URLs, by definition, are GUIDs) best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Richard Cartwright Sent: Tue 3/4/2008 5:31 PM To: BBC Backstage Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? Chris I¹ve a lot of recent experience with 16-byte UUIDs for identifying content (RFC 4122) and the slightly more media-savy 32-byte Unique Material Identification (UMID) from SMPTE (SMPTE 330M). Both standards are the basis for the Advanced Authoring Format, an industry standard used by video production tools from companies such as Avid and Quantel, and the related Material Exchange Format (MXF) used for production material interchange and now supported by a number of broadcast quality cameras, transcoders etc.. UUIDs are also known as GUIDs and are common to Microsoft Windows OS. Many unix OSs have a ³uuidgen² command to create UUIDs. Java has a ³java.util.UUID² class for generating and representing UUIDs. UUIDs are very well supported and have been the subject of some interesting security issues as without careful use they can expose your host ids outside your network. I am working on a media-specific Java API for AAF and MXF that includes support for UUIDs and UMIDs. Both can be generated at source and, as long as a consistent generation strategy is used, should be globally unique. Richard On 4/3/08 12:40, Chris Sizemore [EMAIL PROTECTED] wrote: anyone got any thoughts or experiences with the UUID system for uniquely identifying objects mentioned below? in our collective opinion and experience, is there anything like that, or close to that, in existence yet? -- Dr Richard Cartwright media systems architect portability4media.com [EMAIL PROTECTED] mobile +44 (0)7792 799930 -- MOD Films http://modfilms.com +44 208 144 8981 (UK) +61 2 8003 4811 (AU)
RE: [backstage] What would you love to see coming out of BBC Vision in the near future?
sounds like a great plan, tom -- many of us inside the BBC are quite into dbpedia and linked data, so i think it's not out of the question to attempt what you suggest... here's an example of some work in that direction by my colleague michael smethurst: http://bbc-hackday.dyndns.org:2825/programmes/29xn (currently down, tho -- michael?) my followup question for you and the list, though, is this: what algorithms and methods exist to bootstrap the kind of linking you advocate? it's doubtful that we're going to be able to do all this linking, however valuable, by hand. i.e. what (semi-)automated methods exist for linking all the BBC programme catalogue resources to their corresponding dbpedia/wikipedia/musicbrainz et al resources? for instance, we should be linking: http://www.bbc.co.uk/programmes/b009070m perhaps http://www.bbc.co.uk/iplayer/page/item/b0091v4d.shtml to http://en.wikipedia.org/wiki/Find_Me_The_Face (or rather its dbpedia URI: http://dbpedia.org/resource/Find_Me_The_Face, i guess) but what ways exist to do this script-o-matically? thoughts? best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Tom Morris Sent: Mon 3/3/2008 8:37 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? On Mon, Mar 3, 2008 at 7:13 PM, Ian Forrester [EMAIL PROTECTED] wrote: Hi All, I was hoping to get a brainstorm of ideas for APIs and Feeds you would love to play with in the near future, while focusing on Vision/TV I got most of the obvious stuff like, - A 31 day schedule in XML - TV schedules as a API with past and future ability - Direct links to iplayer programmes - XML/RSS/ATOM/JSON of upcoming iplayer programmes - XML/RSS/ATOM/JSON of programmes about to drop off iplayer - Links between programmes and their programme catalogue entry - The Programme Catalogue! :) It'd be nice if the BBC could publish RDF of their whole programme catalogue and add it to the already growing sphere of Linked Open Data: http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData Hook the programmes in with parts of the diagram on the page - eg: - for all programmes, link them to the DBPedia resource for that programme if it exists on Wikipedia - for actors and presenters, link them to their DBPedia resource - for music programmes, link bands and songs in - for news and factual programmes, link them to online stories that cover the same story - for review programmes (like Newsnight Review), link in the relevant discussed books/authors/films/plays etc. - for things which happen in a particular place, link them into Geonames - for dramatic re-enactments, link them to what they were re-enacting (historical events, books, plays etc.) - in political coverage, link through to details about the relevant politicians and legislation Less hacking RSS and Atom to do things for which they were not intended (they are feed formats, not universal containers). -- Tom Morris http://tommorris.org/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ winmail.dat
insist on the Giant Global Graph... was: [backstage] Muddy Boots on Backstage
all-- been sitting on this term extraction topic (no pun...) for over a month now, and i've got a more extensive treatise brewing, but not finished... so, meanwhile, a couple of things to mention in this area... 1) tom loosemore: So, why not throw the copy through several more term extractors then only use the overlapping terms? Rhys: Though I'm uneasy about a possible situation where one of your term extractors comes up with a great set of terms, but the others miss them completely, and so your output is a bad compromise of terms that aren't that meaningful. i've personally explored this approach somewhat thoroughly over the past few years, at work and at, um, play, and feel it's really effective -- in practice, i haven't come across a situation where your output is a bad compromise of terms that aren't that meaningful... -- tho i suppose that depends on the particular use cases you apply it to... i'll post a little code/prototype app that illustrates this approach for people to poke at soon... 2) here's something i've been exploring and would like to suggest others try, to see if you agree it's promising: download wikipedia dump... index it into Lucene, one Lucene doc per wikipedia page/concept/URI... compare your own (text) content to that Wikipedia-in-Lucene collection, using Lucene's MoreLikeThis... MoreLikeThis suggests wikipedia articles similar to your content... let the term extraction-like, but with unique, semantic web-ready unique ID/URI hijinks begin... again, i should have some (nasty) code/prototype web app available for comment/debunking soon... 3) The BBC has at least one *excellent* term extractor in house which adds extra metadata like 'this term is a person/place/topic'... would be a lovely API to offer, hint hint... Ah - has this been used to derive the subject categories and contributors for the web version of Infax, by any chance? If so, and even if not, that would be a gorgeous API to offer - please, BBC... agree that the Beeb should try to make this into a public-facing API! 4) i agree that http://sws.clearforest.com/ws is really good and useful... anyone made any progress with GATE/ANNIE tho? how about LingPipe? what about the new-ish Yahoo! Pipes entity extraction? 5) in this term extraction/semantic web space, this could be REALLY big, check it out and let us know what you make of it: Calais - Overview Calais: Connect. Everything We want to make all the world's content more accessible, interoperable and valuable. Some call it Web 2.0, Web 3.0, the semantic web or the Giant Global Graph - we call our piece of it Calais. http://reuters.mashery.com/ insanely useful? thoughts? best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Rhys Jones Sent: Tue 11/27/2007 11:09 AM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Muddy Boots on Backstage On 26/11/2007, Tom Loosemore [EMAIL PROTECTED] wrote: ...you can minimise false positive terms by running the copy through several different flavours of term extractor, and only using terms thrown up by x or more of them (where x depends on your appetite for false positives vs false negatives). So, why not throw the copy through several more term extractors then only use the overlapping terms? This should work (and it's been suggested on the backstage-dev list recently). Though I'm uneasy about a possible situation where one of your term extractors comes up with a great set of terms, but the others miss them completely, and so your output is a bad compromise of terms that aren't that meaningful. Do any APIs let you see the confidence score on their output terms? Having admittedly not thought about this much, it seems to me that a confidence score is key to any realistic combination algorithm. In terms (sorry) of quality of output, people seem to like Yahoo's API. I've come across Trynt's offering too (http://www.trynt.com/trynt-contextual-term-extraction-api/ ), but ominously their website is giving me a 403 Forbidden error right now. http://www.programmableweb.com/api/clearforest-semantic-web-services1/ has also been suggested on the pure technical discussion list. - The BBC has at least one *excellent* term extractor in house which adds extra metadata like 'this term is a person/place/topic'... would be a lovely API to offer, hint hint... Ah - has this been used to derive the subject categories and contributors for the web version of Infax, by any chance? If so, and even if not, that would be a gorgeous API to offer - please, BBC... Rhys - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] BBC Hires Dirk-Willem van Gulik as CTA
well, ian -- i'll say this: sounds like a good day for BBC-based semantic web geeks like me, with both Dirk-Willem van Gulik Zavisa Bjelogrlic joining the Beeb... we've actually got an RDF schema for /Programmes lying around here somewheres... best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Ian Forrester Sent: Thu 1/17/2008 5:10 PM To: backstage@lists.bbc.co.uk Subject: RE: [backstage] BBC Hires Dirk-Willem van Gulik as CTA Well well, all quiet on the backstage list... :) Ian Forrester This e-mail is: [ x ] private; [ ] ask first; [ ] bloggable Senior Producer, BBC Backstage BC5 C3, Media Village, 201 Wood Lane, London W12 7TP e: [EMAIL PROTECTED] p: +44 (0)2080083965 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Stone Sent: 17 January 2008 16:38 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] BBC Hires Dirk-Willem van Gulik as CTA Yet again. Another example of the BBC being in hock to Gates and the evil oh hang on a minute. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Loosemore Sent: 17 January 2008 16:16 To: backstage@lists.bbc.co.uk Subject: [backstage] BBC Hires Dirk-Willem van Gulik as CTA It's only mid-Jan, but I bet the below is the best news about the BBC I will hear this year. http://www.paidcontent.co.uk/entry/419-industry-moves-joost-cto-leaves-to-build-new-bbc-network/ More on the man... http://www.go-opensource.org/go_open/episode_3/big_guns/ winmail.dat
RE: [backstage] Thoughts from a previous BBC employee
indeed, 'pioneering' is in the eye of the beholder... (i'm thinking: radio 4, pioneering?!?!?!?!) -Original Message- From: [EMAIL PROTECTED] on behalf of vijay chopra Sent: Mon 10/8/2007 9:14 PM To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Thoughts from a previous BBC employee On 08/10/2007, Jeremy Stone [EMAIL PROTECTED] wrote: I was with you up until this point: - probably the most pioneering (Radio 1) media brand online in the UK But that's probably just because I can't stand Radio 1... Personally I think a much more valuable contribution to society, and somewhere where the Beeb is defiantly leading the way amongst traditional broadcasters is the BBC archivehttp://www.bbc.co.uk/archive/trial/login2.shtmlOK, it's still a trial but one of the best things that the BBC is offering at the moment. Along with Radio 4 and BBC online as a whole it's well worth the licence fee. The TV sure isn't, but that's not a problem exclusive to the Beeb. Vijay.
RE: [backstage] Links to video/audio for specific shows
speaking of which (open data xchange standards/ontologies, tasty URIs for programmes, et al), I find this relevant and suggest the group has a read: http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LinkedDataTutorial/#hown ame best-- --cs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Stephens Sent: 17 July 2007 16:12 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Links to video/audio for specific shows Now, I might have this wrong - but you're suggesting that there should be a standard way of... describing data suggested by the BBC, so that all systems structure their data in the same way? Not quite. There should be one or more standards for appropriate applications suggested by a wider community (broadcasters - of which the BBC is but one) so that all systems structure their data in a way that is able to be widely understood. For example, agreeing a common ontology for programme/schedule data. The partners don't even have to publish the data in the same formats, just agree the ontologies and data formats to allow apps to do transforms and comparisons more easily between sets of data. That's more what I'm getting it. Call me a dreamer... I think the BBC has given up trying to do that even internally, and instead relies on being able to map piece of data A in system X on to piece of data B in systemY, and be reasonably sure they're the same thing. Isn't that what an ontology is supposed to do? If so, why not just write it down? But yes, I understand why even the simplest thing might turn into a major nightmare. I really get the feeling that 95% accurate mappings between different ways of describing stuff is the best we can hope for. The suggestion of gentle harmonisation is preferable to 'having to do it X way always or else' in any big organisation. And, in fact, any system involving fallible meatbags doing data entry. This is coloured by having spent some time up to my elbows in SMEF and datamodelling at the BBC, and also by trying to persuade editorial teams to enter their HTML metadata vaguely consistently. http://www.bbc.co.uk/guidelines/smef/ I agree, the problems of the real world do get in the way, and stuff needs to get done. The only thing is that, great though mashups are, they tend to be incredibly ad hoc, so when the slightest thing changes, lots of developers pipe up aying things like, oh look my feed aggregator or somesuch has just died a death because they've changed the feed format. Some things never change, do they? - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] Links to video/audio for specific shows
I agree with tom coates on this one: if you DON'T use Wikipedia as a Web-native classification engine in your application, then you are missing a trick, because it proves intensely useful! one URI per distinct Concept? use those as subjects and objects in your RDF... talk about evidence for document categorisation (http://en.wikipedia.org/wiki/Training_set)... and it's available now! but if you wait around for some ontology/URI set with notionally more long term stability, I fear that you'll never ship your app? wikipedia is useful NOW, and it's the best we've got in that everybody-can-point-to-these-URIs-for-Concepts space... I suggest we use Wikipedia as our starting point, then build some standard ontologies to make it easy for heavy duty (RDF-heavy) applications talk nicely to each other on top of it... hey, wait! that sounds a lot like Freebase (http://radar.oreilly.com/archives/2007/03/freebase_will_p_1.html) and dbpedia (http://dbpedia.org/docs/), both of which bootstrap raw Wikipedia content as building blocks of much more sophisticated ontological apps... oh, and you can download entire copies of Wikipedia and thus freeze them and use them forever, so I'm not sure long term stability is that much of an issue? hmmm... BBC = stable, and forever... Wikipedia = fly-by-night, temporary... guess time will tell, won't it? ;-) (my bet is on the one with the best URLs, frankly...) best-- --cs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Stephens Sent: 17 July 2007 12:01 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Links to video/audio for specific shows OR I'd go for something much more interesting. Given that Wikipedia has pages on most of these artists and that-by its nature-it has to have a separate page for each one of them, then you can view that as a well maintained centralised controlled vocabulary. I'd probably go with using their URLs as some kind of identifier and perhaps even translating their URL conventions locally. Having said htat, they don't have any of the three artists called 'Bliss' so maybe that wouldn't work. Hmm, such a setup would very much depend upon how critical/commercially sensitive a project might be. to place it at the mercy of a fairly unregulated and somewhat haphazard classification schema might be seen as a bit risky. Let's be honest, as nice and useful as Wikipedia might be, I certainly wouldn't create an app that needed any kind of long term stability in classification with it. But maybe that's just me being a sad anal sort of chap If we're talking sematic applications, it might actually be good for an organisation like the BBC (and partner broadcasters to actually sit down and work out some standard ontologies to make it easy for heavy duty (RDF-heavy) applications talk nicely to each other. It may even have some applications in more lightweight formats as it would give developers some clues as to what particular parts of the data streams actually do. This does seem to be a big stumbling block with semantic applications: having ambiguity of terminology across applications. For example, consider a Tx time: a single ontology could specify whether this meant a first transmission or just the latest, whether a timezone is optional or required and so on. And applications could both parse and transform data knowing that this was the case, not guessing. Should this be a longer term strategic goal for the BBC: trying to work with others to try to create content that is as universally usable and transformable as possible? I've just read this back and if it sounds a bit po-faced and pompous, sorry, wasn't meant to be. === Darren Stephens MBCS CITP School of Arts and New Media University of Hull Scarborough Campus www : http://www.hull.ac.uk/ email : [EMAIL PROTECTED] === - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] Links to video/audio for specific shows
well said, darren... I must admit, I share your dream that auntie might play a role in the area you describe... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Stephens Sent: 17 July 2007 14:59 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Links to video/audio for specific shows Don't get me wrong, for the right apps wikipedia is just great and gives you a great resource to work with. And it's true that in some cases if you DON'T use Wikipedia as a Web-native classification engine in your application, then you are missing a trick. Just not always. It's just that the whole 'URI per distinct Concept?' doesn't sit well with me really. A colleague of mine has been doing some research about contextual searching of just this sort on large sets (specifically very sizeable chunks - gigabytes - of wikipedia) and he is running into issues of contextual ambiguity. Not necessarily major, but they are still there, making sure that he can't sometime tell how closely related things might be because he can't satisfactorily disambiguate them. I'm just not sure that for some things, it's quite robust enough. But that's ok. Tying wikipedia to your apps has a place. Stuff like Freebase, DBPedia and even areas such as Semantic wikpedia and Semantic Mediawiki http://en.wikipedia.org/wiki/Wikipedia:Semantic_Wikipedia definitely have a place too. But I do still still hold that in some cases, large organisations (like Auntie) have to drive some of this forward to 'guarantee' (as far as one can) a relatively speedy critical mass to tip such things into the mass marketplace, or at least to be used by it. but if you wait around for some ontology/URI set with notionally more long term stability, I fear that you'll never ship your app?. True enough, unless of course there is a sound commerical reason for having it. And that's where having a big fish in the pond to chivvy things along can help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Sizemore Sent: Tuesday, July 17, 2007 2:01 PM To: backstage@lists.bbc.co.uk Cc: Matthew Wood Subject: RE: [backstage] Links to video/audio for specific shows I agree with tom coates on this one: if you DON'T use Wikipedia as a Web-native classification engine in your application, then you are missing a trick, because it proves intensely useful! one URI per distinct Concept? use those as subjects and objects in your RDF... talk about evidence for document categorisation (http://en.wikipedia.org/wiki/Training_set)... and it's available now! but if you wait around for some ontology/URI set with notionally more long term stability, I fear that you'll never ship your app? wikipedia is useful NOW, and it's the best we've got in that everybody-can-point-to-these-URIs-for-Concepts space... I suggest we use Wikipedia as our starting point, then build some standard ontologies to make it easy for heavy duty (RDF-heavy) applications talk nicely to each other on top of it... hey, wait! that sounds a lot like Freebase (http://radar.oreilly.com/archives/2007/03/freebase_will_p_1.h tml) and dbpedia (http://dbpedia.org/docs/), both of which bootstrap raw Wikipedia content as building blocks of much more sophisticated ontological apps... oh, and you can download entire copies of Wikipedia and thus freeze them and use them forever, so I'm not sure long term stability is that much of an issue? hmmm... BBC = stable, and forever... Wikipedia = fly-by-night, temporary... guess time will tell, won't it? ;-) (my bet is on the one with the best URLs, frankly...) best-- --cs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Stephens Sent: 17 July 2007 12:01 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Links to video/audio for specific shows OR I'd go for something much more interesting. Given that Wikipedia has pages on most of these artists and that-by its nature-it has to have a separate page for each one of them, then you can view that as a well maintained centralised controlled vocabulary. I'd probably go with using their URLs as some kind of identifier and perhaps even translating their URL conventions locally. Having said htat, they don't have any of the three artists called 'Bliss' so maybe that wouldn't work. Hmm, such a setup would very much depend upon how critical/commercially sensitive a project might be. to place it at the mercy of a fairly unregulated and somewhat haphazard classification schema might be seen as a bit risky. Let's be honest, as nice and useful as Wikipedia might be, I certainly wouldn't create an app that needed any kind of long term stability in classification with it. But maybe that's just me being a sad anal sort of chap If we're talking sematic applications, it might actually be good
RE: [backstage] Links to video/audio for specific shows
yes, i agree that TV-Anytime supplies some of the requirement (indeed, perhaps everything brian was suggesting... brian?) but does TVA, despite the URN (the crid, i.e. crid://my.id.creator/xxx88r; http://en.wikipedia.org/wiki/Crid), supply the on the Web part? depending on one's philosophical bent, that's one of the potential problems with URNs thus CRIDs: they can't (easily) be dereferenced, in the way that a regular old URL can be... URNs aren't on the Web... i guess what i'm saying is that the regular old URL for a programme Episode should be just as permanent as the TVA CRID -- and because it's permanent AND on the Web, the regular old URL is even more useful than the CRID. the permanent URL works great for people AND machines (which can follow the link from the URL to the CRID and thus to the asset(s))... everybody wins? best-- --cs From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Burras Sent: 13 July 2007 08:37 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Links to video/audio for specific shows Isn't that TV-Anytime ? Each programme has a unique URI identifier. Then a separate data source holds a mapping between the IDs and the locations it can be obtained from Cheers... ...Andy B. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Sizemore Sent: 12 July 2007 17:03 To: backstage@lists.bbc.co.uk Subject: RE: [backstage] Links to video/audio for specific shows excellent, we're all on the same page, then! A Permanent URL for each Programme as well as its Episodes... (tho i still think that's what this URL is: http://www.bbc.co.uk/radio3/themakingofmusic/pip/aio4h/ a permanent representation of an Episode on the Web... linking to all available A/V for that Episode... ) best-- --cs From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth Sent: 12 July 2007 16:32 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows On 12/07/07, Chris Sizemore [EMAIL PROTECTED] wrote: hee hee, i'm guessing Kim is crying at the suggestion that the URL would change when the programme moves between catchup, commercial, and archive... That's the opposite of what was proposed - that there should be a permanent URL for each show which has tracks/links/redirects to the content as it moves from one system to another, or for different territories. the URL should remain the constant the same forever, surely? (though, agreed, should be will be are very different beasts) --cs From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Brian Butterworth Sent: 12 July 2007 09:23 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows On 11/07/07, Kim Plowright [EMAIL PROTECTED] wrote: /me cries Please can you cry your suggestion please? On 11/07/07, Chris Jackson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ideally the BBC would maintain a set of permanent URLs for each programme and episode, which in turn reference a range of URIs where the audio and video can be found, now or in the future, whether via DVB various or Internet. This would be particularly helpful if content will change URL when it moves between the mooted BBC 'catch-up' window, commercial and archive services. To me, it all sounds a bit like the semantic web, although I'm no expert there. - Sent via the backstage.bbc.co.uk http://backstage.bbc.co.uk/ discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ -- Please email me back if you need any more help. Brian Butterworth www.ukfree.tv http://www.ukfree.tv/ -- Please email me back if you need any more help. Brian Butterworth www.ukfree.tv __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ** This email and its attachments may be confidential and are intended solely
RE: [backstage] Links to video/audio for specific shows
hee hee, i'm guessing Kim is crying at the suggestion that the URL would change when the programme moves between catchup, commercial, and archive... the URL should remain the constant the same forever, surely? (though, agreed, should be will be are very different beasts) --cs From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth Sent: 12 July 2007 09:23 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows On 11/07/07, Kim Plowright [EMAIL PROTECTED] wrote: /me cries Please can you cry your suggestion please? On 11/07/07, Chris Jackson [EMAIL PROTECTED] wrote: Ideally the BBC would maintain a set of permanent URLs for each programme and episode, which in turn reference a range of URIs where the audio and video can be found, now or in the future, whether via DVB various or Internet. This would be particularly helpful if content will change URL when it moves between the mooted BBC 'catch-up' window, commercial and archive services. To me, it all sounds a bit like the semantic web, although I'm no expert there. - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ -- Please email me back if you need any more help. Brian Butterworth www.ukfree.tv
RE: [backstage] Links to video/audio for specific shows
i'm intrigued by this, and sense it's a great idea, brian, so forgive me for pressing for more detail? so, i think i see what you mean about a live TV or Radio stream being accessed at, for instance: http://live.bbc.co.uk/radio4 BTW, in your scenario, would that URL check which format of AV the requesting client wanted? (that's a bit that media selector currently does, methinks)... but now, leaving a live stream behind for the moment, what about URLs for individual programmes and their episodes... in your scenario, would there be a difference between: http://watch.bbc.co.uk/doctorwho/3/42 http://www.bbc.co.uk/doctorwho/3/42 ?? is one completely about AV assets and one more of a normal webpage? is there a reason why both should exist? couldn't the normal webpage link to the iPlayer asset, perhaps at: http://www.bbc.co.uk/doctorwho/3/42/watch http://www.bbc.co.uk/doctorwho/3/42/watch or from my Radio 3 example: http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/ http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/(an episode of Breakfast) could link to its iPlayer asset at: http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/listen am i still missing your point, tho, brian? best-- --cs From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth Sent: 11 July 2007 12:01 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows Chris, Not really, as this is just a sensible directory structure. I'm meaning that http://www.bbc.co.uk/mediaselector/check/player/nol/newsid_661/newsi d_6615400?redirect=6615433.stmnews=1nbram=1bbram=1nbwm=1bbwm=1 is replaced by http://livetv.bbc.co.uk/bbcnews24 IMHO you would still need the normal bbc.co.uk pages, the links would be used ONLY for audio (listen.) or video (watch.) content and could be retained for a long time. On 11/07/07, Chris Sizemore [EMAIL PROTECTED] wrote: i very much agree with you... the way radio 3's website is set up kind of hints in this direction, no? http://www.bbc.co.uk/radio3/breakfast http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/ (programme index) http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/ (episode) http://www.bbc.co.uk/radio3/classicalcollection (programme index) http://www.bbc.co.uk/radio3/classicalcollection/pip/6xmlt/ (episode) best-- --cs From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Brian Butterworth Sent: 11 July 2007 11:30 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows Chris, I agree with your comments. It would be very useful for there to be a URL-based heiracy for accessing BBC programmes so they can be linked to, no matter what format they are in. For example, you could have URLs for live channel streams, viz: http://livetv.bbc.co.uk/bbcone http://livetv.bbc.co.uk/bbc2w And then for indivusual programmes something like this for indexes... http://watch.bbc.co.uk/doctorwho http://watch.bbc.co.uk/eastenders http://listen.bbc.co.uk/thenowshow and then individual programmes... http://watch.bbc.co.uk/doctorwho/3/42 http://watch.bbc.co.uk/eastenders/12/4 In my reconing this could then have a iPlayer link, links to clips on YouTube, BBC streams or whatever. But it would allow the posting of the URL on systems such as Wikipedia and would allow programme links to be posted in Blogs etc. The page could also provide local schedule information for non-Internet transmission too, and could also include purchase information where required. On 11/07/07, Chris Jackson [EMAIL PROTECTED] wrote: Are there any plans to add links to the audio and video files for specific shows in the BBC TV and Radio API? The data is clearly available, but the 'locations' section of the schedule API gives us channel URIs (multicast, dvb streams), rather than links to the actual content. Links to audio in the BBC Radio Player appeared for Hackday, but were promptly removed. The BBC iPlayer beta seems to use somewhat clean links to content, based on TV Anytime Content Reference IDs Ideally the BBC would maintain a set of permanent URLs for each programme and episode, which in turn reference a range of URIs where the audio and video can be found, now or in the future, whether via
RE: [backstage] Links to video/audio for specific shows
excellent, we're all on the same page, then! A Permanent URL for each Programme as well as its Episodes... (tho i still think that's what this URL is: http://www.bbc.co.uk/radio3/themakingofmusic/pip/aio4h/ a permanent representation of an Episode on the Web... linking to all available A/V for that Episode... ) best-- --cs From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth Sent: 12 July 2007 16:32 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows On 12/07/07, Chris Sizemore [EMAIL PROTECTED] wrote: hee hee, i'm guessing Kim is crying at the suggestion that the URL would change when the programme moves between catchup, commercial, and archive... That's the opposite of what was proposed - that there should be a permanent URL for each show which has tracks/links/redirects to the content as it moves from one system to another, or for different territories. the URL should remain the constant the same forever, surely? (though, agreed, should be will be are very different beasts) --cs From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Brian Butterworth Sent: 12 July 2007 09:23 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows On 11/07/07, Kim Plowright [EMAIL PROTECTED] wrote: /me cries Please can you cry your suggestion please? On 11/07/07, Chris Jackson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Ideally the BBC would maintain a set of permanent URLs for each programme and episode, which in turn reference a range of URIs where the audio and video can be found, now or in the future, whether via DVB various or Internet. This would be particularly helpful if content will change URL when it moves between the mooted BBC 'catch-up' window, commercial and archive services. To me, it all sounds a bit like the semantic web, although I'm no expert there. - Sent via the backstage.bbc.co.uk http://backstage.bbc.co.uk/ discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ -- Please email me back if you need any more help. Brian Butterworth www.ukfree.tv http://www.ukfree.tv/ -- Please email me back if you need any more help. Brian Butterworth www.ukfree.tv
RE: [backstage] Links to video/audio for specific shows
i very much agree with you... the way radio 3's website is set up kind of hints in this direction, no? http://www.bbc.co.uk/radio3/breakfast http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/ (programme index) http://www.bbc.co.uk/radio3/breakfast/pip/jrjen/ (episode) http://www.bbc.co.uk/radio3/classicalcollection (programme index) http://www.bbc.co.uk/radio3/classicalcollection/pip/6xmlt/ (episode) best-- --cs From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Butterworth Sent: 11 July 2007 11:30 To: backstage@lists.bbc.co.uk Subject: Re: [backstage] Links to video/audio for specific shows Chris, I agree with your comments. It would be very useful for there to be a URL-based heiracy for accessing BBC programmes so they can be linked to, no matter what format they are in. For example, you could have URLs for live channel streams, viz: http://livetv.bbc.co.uk/bbcone http://livetv.bbc.co.uk/bbc2w And then for indivusual programmes something like this for indexes... http://watch.bbc.co.uk/doctorwho http://watch.bbc.co.uk/eastenders http://listen.bbc.co.uk/thenowshow and then individual programmes... http://watch.bbc.co.uk/doctorwho/3/42 http://watch.bbc.co.uk/eastenders/12/4 In my reconing this could then have a iPlayer link, links to clips on YouTube, BBC streams or whatever. But it would allow the posting of the URL on systems such as Wikipedia and would allow programme links to be posted in Blogs etc. The page could also provide local schedule information for non-Internet transmission too, and could also include purchase information where required. On 11/07/07, Chris Jackson [EMAIL PROTECTED] wrote: Are there any plans to add links to the audio and video files for specific shows in the BBC TV and Radio API? The data is clearly available, but the 'locations' section of the schedule API gives us channel URIs (multicast, dvb streams), rather than links to the actual content. Links to audio in the BBC Radio Player appeared for Hackday, but were promptly removed. The BBC iPlayer beta seems to use somewhat clean links to content, based on TV Anytime Content Reference IDs Ideally the BBC would maintain a set of permanent URLs for each programme and episode, which in turn reference a range of URIs where the audio and video can be found, now or in the future, whether via DVB various or Internet. This would be particularly helpful if content will change URL when it moves between the mooted BBC 'catch-up' window, commercial and archive services. To me, it all sounds a bit like the semantic web, although I'm no expert there. Of course, it would be relatively trivial to screen scrape this stuff and keep the links on a 3rd party site, but there are real advantages to the BBC providing and maintaining the data, I think? There's a downside for the BBC in providing these links - they help the audience to watch or listen to individual shows outside a context of BBC web pages, with no equivalent to the offline trail. Traditionalists could argue that this reduces the public value of the content, because there is less ability to point an East Enders viewer to Panorama etc etc. I'm hoping that the BBC approach recognises the public value to be gained from getting the content out there, even if they lose a few website visits. Is this the case? Chris -- Chris Jackson http://simsocast.com/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ -- Please email me back if you need any more help. Brian Butterworth www.ukfree.tv
RE: Uploading the BBC programme catalogue to freebase (was RE: [backstage] Programme Catalogue vs. Freebase (was: BBC Programme Catalogue -any APIs yet?))
http://catalogue.bbc.co.uk/catalogue/infax/series/DR+WHO holy synonomous concepts, batman... (http://open.bbc.co.uk/catalogue/infax/series/DOCTOR+WHO) point is, it would be easy to merge these on freebase, nearly impossible directly in the BBC Programme Catalogue context... suppose this all has to do with the different purposes of the 2 products... arguably, the BBC has done it's part by making the Catalogue data available via RDF and Atom? if freebase is a useful (interim) destination for this data, isn't the assumption that the community will make it happen? (hint, hint?) best-- --cs -Original Message- From: [EMAIL PROTECTED] on behalf of Brendan Quinn Sent: Mon 7/9/2007 9:30 PM To: backstage@lists.bbc.co.uk Subject: Uploading the BBC programme catalogue to freebase (was RE: [backstage] Programme Catalogue vs. Freebase (was: BBC Programme Catalogue -any APIs yet?)) I was considering entering a hack for Hack Day around that very thing. But then they went and made me one of the judges ;-) Wanna help? A simple set of scripts that scrape the archive (er I mean call that big RESTful API) and post entries/updates to the freebase sandbox server would be an interesting experiment. I agree that freebase is an amazing resource, especially when the programme data is curated properly: compare http://www.freebase.com/view/?id=%239202a8c04000641f80012406 with http://open.bbc.co.uk/catalogue/infax/series/DOCTOR+WHO ! There may be some rights issues around what would basically amount to opening up the programme catalogue under the creative commons attribution license, where the attribution wouldn't go to the BBC but to Freebase... Brendan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver Cole Sent: 09 July 2007 20:51 To: backstage@lists.bbc.co.uk Subject: [backstage] Programme Catalogue vs. Freebase (was: BBC Programme Catalogue -any APIs yet?) I've been following the Programme Catalogue since it was announced, and its pretty interesting. I do however have a question for the BBC people on the list - have you considered simply uploading all the information to Freebase[1]? I can understand that you might want to keep it in house, but if you merged it with the wealth of information on Freebase you can do exponentially more. For example, if it was properly integrated you could run a query that would tell me how many of the contributors to Spooks series 2 were born in London. Regards, Oli [1] http://www.freebase.com - A very cool structured database, currently handling 2.3 million instances of 870 'types' - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
RE: [backstage] This one's for Cridland... BBC A/V interface ideas
(golly, mr cridland, looks like you've got the expectations of a whole darn mailing list on your shoulders?!? frankly, tho, first things first: i've got a whole stack of holiday leave forms waiting for you to sign when you're able? ah, the multi-faceted responsibilities of a newly-appointed dept. head... ;-) best-- --cs) -Original Message- From: [EMAIL PROTECTED] on behalf of Brian Butterworth Sent: Tue 5/22/2007 7:47 PM To: backstage@lists.bbc.co.uk Subject: RE: [backstage] This one's for Cridland... BBC A/V interface ideas The BBC News facility that works with Windows Media Center (XP or Vista) is a much better way to view these videos (when it works) and does much of what you describe. Personally, I've stuffed all the video feed URLs on an iGoogle tab... Brian Butterworth HYPERLINK http://www.ukfree.tv/www.ukfree.tv _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Woods Sent: 22 May 2007 18:35 To: backstage@lists.bbc.co.uk Subject: [backstage] This one's for Cridland... BBC A/V interface ideas Whilst on the subject of interface and UI design, I was thinking about the BBC site's design. So, the BBC has a burgeoning portfolio of online multimedia offerings, and they have their BBC Audio/Video link in the left bar of the BBC News site (and elsewhere on the site), but once you're actually on that page you're given a rather odd selection of videos. Why not give surfers the best of both worlds, having an AV player interface which takes elements from the old player and gives you a different menu for the regular Programmes (Panorama etc) and then gives you a category list? Sometimes I just want to watch all the most recent SciTech videos, for example, which was as easy as clicking through the list on the old player, but is nigh on impossible on the new one... There's only three videos per category! Consolidating all the available videos for a certain time period in sections on the page would be very useful and helpful, plus it would probably attract more eyes because when the content is easier to get to, people'll come back! I just feel there's room for improvement, and it'd be great to have a little area in the AV player where you can choose to watch N24, or the o' clock news broadcasts, or any of the programmes, all from one place with two clicks MAX - none of this faffing about having to go to the respective programme's page just to fire up the player with the relevant stream (although that can stay, because I'm sure people do it that way too if they're entering via that particular page). Just throwing these ideas into the pot.. No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 21/05/2007 14:01
RE: [backstage] Flickr Photo Map...
wow, this one blows me away: http://www.flickr.com/map/birmingham does it know I'm geoIP'd in the UK? is anyone in the states right now? does this URL show you birmingham, alabama or brum? best-- --cs -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Loosemore Sent: 10 November 2006 15:12 To: backstage@lists.bbc.co.uk Subject: [backstage] Flickr Photo Map... http://www.flickr.com/map/london/ Nice... Though I don't understand the logic behind the 'pages' approach - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/ - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
