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: [email protected] 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/[email protected]/
