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 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/
> 
*****************************************************************************************
To view the terms under which this email is distributed, please go to 
http://www.hull.ac.uk/legal/email_disclaimer.html
*****************************************************************************************

Reply via email to