Still hot from the oven, heres a script that creates MusicOntology-RDF- Artists'-instances, based on the data coming from last.fm [1] and/or pandora [2].
Heres how it roughly works: * last.fm: Gets the top 5 artists of the user, plus similar artists. * pandora: Gets 5 artist-based radio stations of the user (from the user's RSS), and gets similar artists from last.fm. (in both cases, the script is a bit slow, as is querying all these APIs, parsing RSS, etc.)
Moreover, it connects to the MusicBrainz [3] repository (plus Amazon WS to get the images) to gather some useful information.
Please, handle with care. It has not yet been fully tested...at all!
> Still hot from the oven, heres a script that creates MusicOntology-RDF- > Artists'-instances, based on the data coming from last.fm [1] and/or > pandora [2].
> Heres how it roughly works: > * last.fm: Gets the top 5 artists of the user, plus similar artists. > * pandora: Gets 5 artist-based radio stations of the user (from the > user's RSS), and gets similar artists from last.fm. > (in both cases, the script is a bit slow, as is querying all these > APIs, parsing RSS, etc.)
> Moreover, it connects to the MusicBrainz [3] repository (plus Amazon > WS to get the images) to gather some useful information.
> Please, handle with care. It has not yet been fully tested...at all!
This is a really interesting mashup of many sources of information (at least 4 different APIs)... this is really beautiful to see :)
It makes a quite interesting music recommendation system.
By the way, for everybody information:
1- A new revision of the ontology should be released next week (mo:Show, the shortcuts discussion, revision of some definitions, and some more schemas to explain how things interact together).
2- The MBZ->MO mapping should be released (Virtuoso RDF VIew at least) on Monday, and the RDF dump should come next week too.
I'm doing a similarish mashup with vcs[1] Hacking together an app that listens for track playing notifications from vcs and uses the mb track api to bring back artist, track and release ids
Unfortunately vcs only has artist, composer, track title, label and cat # ~ enough to do music reporting but no release title!?! We've got a local install of brainz ~ one option we're considering is rewriting the lucene indexing to index cat #s... Or just changing vcs. Anybody got any thoughts on the coverage of cat #s in brainz? I know the model has changed pretty recently
Anyway I've wrapped the data in ruby on rails and it uses the brainz api to bring back brainz data including the wikipedia links, then scrapes wikipedia to bring bits of that in. Have started to think about pulling in users last.fm profiles to recommend bbc programmes but not got very far yet... Maybe this weekend
Unfortunately it's an internal only demo ~ the aim is to generate personalised podcasts of bbc programmes based on user taste so we can't make it external any time soon... But if any of you are in the vicinity of broadcasting house....
Slightly interesting(?) stats on automated matching for networks: BBC radio 1 ~ 66% (pop stuff) BBC 6Music ~ 75% (music for 30 somethings to wash their cars to) Radio 2 ~ 89% (dad rock) 1xtra - 32% (urban) A lot of the errors are down to bad data in vcs but I'm not sure if the 1xtra stats are down to problems matching collaborations (it seems to struggle) or lack of genre coverage in brainz
Slightly [more] off topic but have any of you any thoughts on microformats around music. Just trying to come up with a good way of marking up programme tracklists and the microformats mailing list scares me
[1] a hard disc playout system (like a giant ipod) used on daytime bbc radios 1,2,6music and 1xtra
[mailto:music-ontology-specification-group@googlegroups.com] On Behalf Of ocelma Sent: 08 March 2007 17:59 To: Music Ontology Specification Group Subject: Last.fm and pandora data to Music Ontology
Dear all,
Still hot from the oven, heres a script that creates MusicOntology-RDF- Artists'-instances, based on the data coming from last.fm [1] and/or pandora [2].
Heres how it roughly works: * last.fm: Gets the top 5 artists of the user, plus similar artists. * pandora: Gets 5 artist-based radio stations of the user (from the user's RSS), and gets similar artists from last.fm. (in both cases, the script is a bit slow, as is querying all these APIs, parsing RSS, etc.)
Moreover, it connects to the MusicBrainz [3] repository (plus Amazon WS to get the images) to gather some useful information.
Please, handle with care. It has not yet been fully tested...at all!
http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.
On 3/8/07, Michael Smethurst <Michael.Smethu...@bbc.co.uk> wrote:
> That rocks
> I'm doing a similarish mashup with vcs[1] > Hacking together an app that listens for track playing notifications > from vcs and uses the mb track api to bring back artist, track and > release ids
> Unfortunately vcs only has artist, composer, track title, label and cat > # ~ enough to do music reporting but no release title!?! > We've got a local install of brainz ~ one option we're considering is > rewriting the lucene indexing to index cat #s... Or just changing vcs. > Anybody got any thoughts on the coverage of cat #s in brainz? I know the > model has changed pretty recently
Just fast answer : if you're speaking about catalogue number associated to label and release, it should arrive in MB as soon are the label stuff goes to prod (normally and hopefully quite soon)
> * last.fm: Gets the top 5 artists of the user, plus similar artists. > * pandora: Gets 5 artist-based radio stations of the user (from the > user's RSS), and gets similar artists from last.fm. > (in both cases, the script is a bit slow, as is querying all these > APIs, parsing RSS, etc.)
> Moreover, it connects to the MusicBrainz [3] repository (plus Amazon > WS to get the images) to gather some useful information.
This is great!!
Just a small technical point though: should we keep the MBZ URIs to refer to an artist object (or any MBZ stuff)? In fact, my point is that, if we dereference it, it doesn't give much useful information.
Fred, you may have come across this problem while mapping MBZ. How did you solve that?
I was thinking about an inverse functional property mo:mbz, or something like that.
On Mar 8, 11:19 pm, "Yves Raimond" <yves.raim...@gmail.com> wrote:
> Just a small technical point though: should we keep the MBZ URIs to > refer to an artist object (or any MBZ stuff)? In fact, my point is > that, if we dereference it, it doesn't give much useful information.
Yep! I agree. Anyway, I was inspired by the Level 1 examples:
So, I thought that this URI looked very similar to the MusicBrainz (MB) ones ;-) And, in my case, I'm looking to a simple way of integrating all this artist (and track) info from different sources, for doing music recommendation. Thus, I thought MB (or maybe last.fm) could be the most useful ones...
Anyway, what do you think it would be the best option, then? Referencing to the Artist wikipedia URI (if available), or last.fm one?
> Fred, you may have come across this problem while mapping MBZ. How did > you solve that?
> I was thinking about an inverse functional property mo:mbz, or > something like that.
> So, I thought that this URI looked very similar to the MusicBrainz > (MB) ones ;-) > And, in my case, I'm looking to a simple way of integrating all this > artist (and track) info from different sources, for doing music > recommendation. Thus, I thought MB (or maybe last.fm) could be the > most useful ones...
> Anyway, what do you think it would be the best option, then? > Referencing to the Artist wikipedia URI (if available), or last.fm > one?
Well, wikipedia URi wouldn't be dereferencable neither ;)
There is no magic trick to make it happens. The only way is that somebody host the data with some uri that are deferencable. I will be one of these person in a somewhat near future. In fact, I will use Zitgist as URI for musical things. that way, people will be able to dereference musical resources from Zitgist, and then follow links to musicbrainz, wikipedia, etc. For now, continue to use MBZ for URI description, but next week, you will get the URI schemas I will use to refers to them, and then you will be free to choose what to use.
> Just fast answer : if you're speaking about catalogue number associated to > label and release, it should arrive in MB as soon are the label stuff goes > to prod (normally and hopefully quite soon)
Yeah, think they planned by the end of March or something like that.
> Slightly [more] off topic but have any of you any thoughts on > microformats around music. Just trying to come up with a good way of > marking up programme tracklists and the microformats mailing list scares > me
As long as I know is that they use hReview to describe musical events (eventful.com, upcoming.com, etc.). All the projects I am aware of (public or private) are going into that direction.
Wondering if anyone has any thoughts on how this would be best marked up (yes with links... We know that) I'd like to embed brainz ids (where available) in the html for easy parsing
Anyway if anyone has any thoughts on how we could make this useful to you...
[mailto:music-ontology-specification-group@googlegroups.com] On Behalf Of Frederick Giasson Sent: 09 March 2007 13:35 To: music-ontology-specification-group@googlegroups.com Subject: RE: Last.fm and pandora data to Music Ontology
Hi Micheal,
> Slightly [more] off topic but have any of you any thoughts on > microformats around music. Just trying to come up with a good way of > marking up programme tracklists and the microformats mailing list scares > me
As long as I know is that they use hReview to describe musical events (eventful.com, upcoming.com, etc.). All the projects I am aware of (public or private) are going into that direction.
Take care,
Fred
http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.