Re: [backstage] Tivo StopWatch beginner questions...
James Ockenden wrote: Interesting news from Tivo, it has been measuring 20,000 users second-by-second viewing habits. The results show people actually like the direct response ads better... more interesting i thought was how StopWatch managed the 20,000 CRID/URI-style info streaming in every second for two months (that's a lot of data no?) and how it measured and identified each program, and, since this was primarliy for advertisers, how they identified each advert? by the station's output listing/time - surely unreliable? They could be fingerprinting the audio stream of ads/programmes to ascertain what is being watched. This is my understanding of how data is collected for Nielsen's BARB stats, that way you are able to not only report on what peopel are currently wacthing but also you can ascertain what people have watched on their DVDs/TiVo/DigiBox-recorders. Seán - 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] About our API
On Tue, 17 Jul 2007 00:19:34 +0100, Mr I Forrester [EMAIL PROTECTED] wrote: Following from the debate about links for programmes... how about this? http://blogs.sun.com/sandoz/entry/bbc_web_api_beta - found via George. Funny this should come up now. The system we were just talking about in the other thread (Pips) has evolved into something that no longer produces a actual pages but is solely a REST API. It meets all the requirements for addressability, statelessness, connectedness and uniform interface as described in RESTful Web Services. It's a shame it's internal only. I'd love it to be on Backstage. Cheers Jonathan - 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 mean that's better in some ways certainly, but you'd probably also want to create some sort of canonical identifier that would represent the band so that if anyone was doing anything programmatically across the web they would be able to connect the two concepts. I mean, YOU might know which Bliss is #1 and which is #2, but someone else might come to very different conclusions. I mean, you can take this to excess, clearly, but I think a good proportion of the time in areas where there are different spellings, namespace collisions and the like, that I'd prefer to stick an informationless identifier at the end of the URL to represent the specific thing. 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. On 16 Jul 2007, at 16:56, James Cridland wrote: In terms of music artists (I rediscovered the great band Bliss this weekend, and found three different Bliss's within the same last.fm page, of which I was only interested in one, and the pictures and everything is all really very messed-up) then perhaps disambiguation pages work like wikis. www.bbc.co.uk/music/artist/bliss/ is a disambiguation page, leading to www.bbc.co.uk/music/artist/bliss_1/ www.bbc.co.uk/music/artist/bliss_2/ ...etc This also has the benefit that you don't need a database call to link to an artist page on /music - just call str_replace( ,_,strtolower($artist)); instead. Not that it's quite that easy, of course. - 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
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] ===* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *
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] About our API
At 11:36 +0100 17/7/07, Jonathan Tweed wrote: On Tue, 17 Jul 2007 00:19:34 +0100, Mr I Forrester [EMAIL PROTECTED] wrote: Following from the debate about links for programmes... how about this? http://blogs.sun.com/sandoz/entry/bbc_web_api_beta - found via George. Funny this should come up now. The system we were just talking about in the other thread (Pips) has evolved into something that no longer produces a actual pages but is solely a REST API. It meets all the requirements for addressability, statelessness, connectedness and uniform interface as described in RESTful Web Services. It's a shame it's internal only. I'd love it to be on Backstage. Cheers Jonathan Plus ca change? Gordo -- Think Feynman/ http://pobox.com/~gordo/ [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
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. 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? 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. 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/ - 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
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 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
Re: [backstage] About our API
On Tue, 17 Jul 2007 14:32:18 +0100, Gordon Joly [EMAIL PROTECTED] wrote: Plus ca change? True, but the data differs in content as well as conceptual structure. I'm not overly familiar with the BBC Web API but there also seems to be more metadata in Pips. Pips is episode centric. You can ask for a schedule, but that's not where it's strengths lie. It's not a linear broadcast view of the world, it's about brands, series, episodes, versions, broadcasts and ondemands with the links between all of these. It's also the metadata store for iPlayer, so those oh so important unique identifiers are the same as they are in iPlayer, which would be very useful for tying iPlayer into mashups, widgets, etc. Cheers Jonathan - 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
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?* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *
Re: [backstage] Links to video/audio for specific shows
On 7/17/07, Darren Stephens [EMAIL PROTECTED] wrote: 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. Is that what TV-Anytime does? G - 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/
