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!
Regards,
Oscar.
[1] http://foafing-the-music.iua.upf.edu/RDFize/pandora?username=tconrad
[2] http://foafing-the-music.iua.upf.edu/RDFize/lastfm?username=RJ
[3] http://musicbrainz.org
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.
Salutations,
Fred
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
Dear all,
Regards,
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.
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
> * 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.
Cheers!
Yves
...nice work you and Fred are doing here!
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:
mo:MusicGroup rdf:about="http://mm.Music.org/artist/65f4f0c5-ef9e-490c-
aee3-909e7ae6b2ab"
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.
Cheers, Oscar
> Yep! I agree.
> Anyway, I was inspired by the Level 1 examples:
>
> mo:MusicGroup rdf:about="http://mm.Music.org/artist/65f4f0c5-ef9e-
490c-
> aee3-909e7ae6b2ab"
>
> 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.
Take care,
Fred
> 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.
Take care,
Fred
On Mar 9, 2:29 pm, Frederick Giasson <f...@fgiasson.com> wrote:
> > 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 ;)
Ooops! right. I meant dbpedia (once it has more musical data in it).
Cheers, Oscar
> 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
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...
-----Original Message-----
From: music-ontology-sp...@googlegroups.com
[mailto:music-ontology-sp...@googlegroups.com] On Behalf
Hi Micheal,
Take care,
Fred
Events and reviews we've got (not quite live... Yet ;-))
Was thinking more of radio episode tracklists
Eg
http://www.bbc.co.uk/radio1/bobbyandnihal/
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...
> Events and reviews we've got (not quite live... Yet ;-))
> Was thinking more of radio episode tracklists
> Eg
> http://www.bbc.co.uk/radio1/bobbyandnihal/
>
> 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...
Hummm, what would you like to describe? Could you be more specific?
A list of radio episode, with the description of the episode, the author, the
signal, the broadcast channel, etc?
Take care,
Fred
Nice to meet you on this list.
>
> I assume you mean "hCalendar to describe musical events" not hReview.
> We embed our events listings with hCalendar (and hCard for venues).
> - Brian Dear (founder of Eventful)
Yeah, sorry about that, hCalendar and not hReview.
However I will probably re-contact you soon enough since I will eventually map
these hCalendar using MO, so I could have some questions for you.
One of the issue I see (without having take the time to check it in deep) is
that I will have to joint the hCalendar with free text fields with MBZ,
something that can lead to some errors in the linking of the two databases.
However, we will check that later.
Take care,
Fred
Clearly they should be marked up as tables ~ just wondering the best way
to embed the brainz ids we do have in the markup... Anyway, think I'm
drifting way off topic so apologies...
On a separate topic we've got a load of proms data knocking about not
doing much at the moment. It's in csv files waiting to be databased and
goes back thru the entire history of the proms (~1932). It's got every
performance, composers, performers, pieces etc. If I could get this data
to you (no promises) would it be helpful in testing the ontology?
Laters
Michael
-----Original Message-----
From: music-ontology-sp...@googlegroups.com
[mailto:music-ontology-sp...@googlegroups.com] On Behalf
Of Frederick Giasson
Sent: 10 March 2007 21:12
To: music-ontology-sp...@googlegroups.com
Subject: RE: Last.fm and pandora data to Music Ontology
Hi Micheal,
Take care,
Fred
> I'm trying to work out the best way to mark-up the track-list tables
> for an episode. These will be tuples of artist, track title, label
(and
> possibly composer, release title...)
> We'll have brainz ids for artists and composers but nothing else
for now
Okay, dunno what will be used to create the tracklist, but you could
create a property in that ontology to link to a MusicalExpression if
you have to describe the Signal (signal duration (track len), PID,
remix, etc.) or you can link directly to a MusicalManifestation (mo:
Track), to link to its creator, describe its title, and other
relations related to tracks (musical manifestations). Do you have an
example of such a track list? So I could write a little something to
show you what I am talking about here.
> On a separate topic we've got a load of proms data knocking about
not
> doing much at the moment. It's in csv files waiting to be databased
and
> goes back thru the entire history of the proms (~1932). It's got
every
> performance, composers, performers, pieces etc. If I could get this
data
> to you (no promises) would it be helpful in testing the ontology?
Yeah sure it would be wonderful :)
What would be interesting is to link these proms with musicbrainz and
integrate it into Zitgist (the only thing is that I would need a
clear licence to know if I can use it or not).
But sure it could be interesting, and I think that Ivan would be too
considering its interest for classical music :)
take care,
Fred
maybe not really the script you are looking for; however, maybe also a
look worth, since the following two RDFizer are very related to Oscar's one:
1. The DBTune Last.fm artist similarity RDF service [1]
2. The DBTune AudioScrobbler RDF service [2]
Cheers,
Bo
[1] https://github.com/motools/LFM-Artist-Similarity-RDF-Service
[2] https://github.com/motools/AS-RDF-Service
On 3/19/2012 11:32 AM, Andrea Pati�o wrote:
> Hi Oscar, I know its being a long time ago, but where can I find the
> script..
> I am working in a project and a good example would help a lot..
>
> Thanks in advance
>
> Andrea
>
> El jueves 8 de marzo de 2007 18:59:23 UTC+1, ocelma escribi�:
>
> Dear all,
>
> Still hot from the oven, heres a script that creates MusicOntology-RDF-
> Artists'-instances, based on the data coming from last.fm
> <http://last.fm> [1] and/or
> pandora [2].
>
> Heres how it roughly works:
> * last.fm <http://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 <http://last.fm>.