Re: Musicbrainz
Kurt J
Great stuff. I am able to view some resources via the Dipper (which
is a very cool thing i was not aware of previously). However,
otherwise i'm getting lots of timeouts.
Also, I'm not able to see what's in the ad-hoc schema at
http://musicbrainz.dataincubator.org/schema/ - seems to 404
As you may know, there's a grant to make MusicBrainz' core a linked
data resource directly [1]. Of course the first order of business is
a mapping. Would you be willing to share the details of your
mappings? Perhaps the source codes?
Ian you are using the current Mbz database dump [2] or more
experimental Next Gen Schema dumps [3] ??? It seems like you're using
the NGS, am I wrong?
Altho I won't respond to them in detail, Bob's comments seems quite
apt as usual.
Finally, as part of the MusicBrainz mapping for the core - we want to
get ideas and comments from the various interested communities.
Perhaps setting up some kind of mapping wiki is the best way to do
this? How has this been done before?
Cheers,
Kurt J
[1] http://blog.musicbrainz.org/?p=571
[2] http://musicbrainz.org/doc/Database_Download
[3] http://ftp.musicbrainz.org/pub/musicbrainz/data/ngs/20100616/
On Mon, Jul 19, 2010 at 7:38 AM, Bob Ferris <za...@elbklang.net> wrote:
> Hi Ian,
>
> thanks a lot for your work.
> Here a some short suggestion from me (as far as I've reviewed only the
> examples for a short time).
>
> 1. New defined properties, why not using (I know it fits currently maybe not
> really to the simple mapping you proposed. However we can also discuss such
> issues in the Music Ontology mailing list[4]. I think for a good modelling
> you'll need the different levels (work, expression, manifestation, item).):
> - http://musicontology.com/#term_instrument
> - http://musicontology.com/#term_performer
> - http://musicontology.com/#term_composer
> - or the concepts, which could be used to describe such persons (see [1])
>
> 2. I would suggest you, to have a look at the Music Ontology class schema
> examples[2], where graphics for illustration purpose are included.
>
> 3. For a Discogs mapping it might maybe also useful to have a look at the
> extend release concept [3], e.g. maybe mo:SignalGroup instead of
> dimb:releaseGroup.
>
> 4. For modelling the links of a resource from different information
> services, I would suggest to use the new Info Service Ontology[5], which
> also opens the door for new or currently unknown (music) information
> services.
>
> More thoughts maybe later.
>
> Cheers,
>
>
> Bob
>
> [1]
> http://wiki.musicontology.com/index.php/Classes_Schemas#mo:MusicArtist.2C_mo:MusicGroup.2C_mo:Label_and_mo:Membership_schemas_.28extended.29
> [2] http://wiki.musicontology.com/index.php/Classes_Schemas
> [3] http://wiki.musicontology.com/index.php/ProposalRevision14 (this
> proposal is already a part of Music Ontology 2.0)
> [4] http://groups.google.com/group/music-ontology-specification-group
> [5] http://purl.org/ontology/is/infoservice.html
>
> Am 19.07.2010 13:27, schrieb Ian Davis:
>>
>> Hi datanauts,
>>
>> I have made a conversion of the MusicBrainz database available via
>> dataincubator. This is a new expression in RDF and includes all the
>> rich relationships that MusicBrainz records. I have followed the
>> mappings used by http://dbtune.org/musicbrainz/ where it makes sense,
>> but MB has evolved since that was put together (and have a major new
>> DB schema change in the pipeline).
>>
>> See http://musicbrainz.dataincubator.org/
>>
>> There are a few problems that I can see from a quick peruse of the
>> data. For example the foaf:member relationship is the wrong way round
>> on this resource:
>>
>>
>> http://musicbrainz.dataincubator.org/artist/ea87d0ee-dba4-4ab5-92ae-f2e286179a12
>>
>> And the same bug is messing up parentOf/childOf relationships:
>>
>>
>> http://musicbrainz.dataincubator.org/artist/16bf7aa1-7b25-427c-8d5b-aeb5b5da4896
>>
>> Some of the resource descriptions are very large and my webserver
>> times out rendering them. Dipper does a better job:
>>
>>
>> http://api.talis.com/stores/iand-dev1/items/dipper.html#q=http%3A//musicbrainz.dataincubator.org/artist/4e60a56a-514a-4a19-a3cc-49927c96b3cb
>>
>> Please take a look and report any problems so I can fix them for the
>> next release.
>>
>> Cheers,
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "Data Incubator" group.
> To post to this group, send email to datain...@googlegroups.com.
> To unsubscribe from this group, send email to
> dataincubato...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dataincubator?hl=en.
>
>
Yves Raimond
So as far as I know, we have three mappings from Musicbrainz to RDF (I
think this is a record :-) ):
1) The Zitgist/OpenLink mapping
2) The DBTune/D2R mapping
3) The DataIncubator one
... which is starting to be quite confusing for Linked Data users.
I think we should get our act together and actually push it to the
Musicbrainz codebase, now, especially as the NGS branch is being more
stable and stable.
Wrt. the new DataIncubator mapping, it looks like the only DB schema
change between the DBtune and the DataIncubator one is the addition of
ReleaseGroups (which was actually requested by the BBC :-) ).
On the mapping itself, I don't think ReleaseGroup needs to mint its
own concept. This is pretty well supported with the last release of
the Music Ontology, using the mo:SignalGroup concept.
Best,
y
> You received this message because you are subscribed to the Google Groups "Music Ontology Specification Group" group.
> To post to this group, send email to music-ontology-sp...@googlegroups.com.
> To unsubscribe from this group, send email to music-ontology-specific...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/music-ontology-specification-group?hl=en.
>
>
Yves Raimond
y
Bob Ferris
Am 19.07.2010 17:10, schrieb Ian Davis:
> Hi Bob,
>
> On Mon, Jul 19, 2010 at 1:38 PM, Bob Ferris<za...@elbklang.net> wrote:
>> Hi Ian,
>>
>> thanks a lot for your work.
>> Here a some short suggestion from me (as far as I've reviewed only the
>> examples for a short time).
>>
>> 1. New defined properties, why not using (I know it fits currently maybe not
>> really to the simple mapping you proposed. However we can also discuss such
>> issues in the Music Ontology mailing list[4]. I think for a good modelling
>> you'll need the different levels (work, expression, manifestation, item).):
>> - http://musicontology.com/#term_instrument
>> - http://musicontology.com/#term_performer
>> - http://musicontology.com/#term_composer
>> - or the concepts, which could be used to describe such persons (see [1])
>
>
> I have mapped a lot of the properties by hand already. Still quite a
> lot to do. I'll add these to the list.
>
>>
>> 2. I would suggest you, to have a look at the Music Ontology class schema
>> examples[2], where graphics for illustration purpose are included.
>
>
> I will do. The MO site was misconfigured for quite a while and was
> only serving RDF, so I couldn't see the examples.
>
>>
>> 3. For a Discogs mapping it might maybe also useful to have a look at the
>> extend release concept [3], e.g. maybe mo:SignalGroup instead of
>> dimb:releaseGroup.
>
> OK. The problem here is that MO is heavily influenced by an earlier
> version of MusicBrainz and the mapping to the current datamodel is
> rather awkward.
Oh, the Music Ontology 2.0 release should now cover the concepts from
MusicBrainz NGS and Discogs database schema. In the following, I made
some quick suggestions re. a mapping to Music Ontology concepts.
However, I haven't rechecked the descriptions in MusicBrainz NGS. You
should also have a look at this description here[1] from Yves in the
Music Ontology mailing list.
>
> These are how I am mapping the major tables:
>
> * artist: mo:MusicArtist (and mo:SoloMusicArtist / mo:MusicGroup )
> * release_group: dimb:ReleaseGroup (new class)
-> mo:SignalGroup
> * album: dimb:Release (new class)
-> mo:Release
> * label: mo:Label
> * release: dimb:ReleaseEvent (new class)
-> mo:ReleaseEvent
> * track: mo:Track
>
> This is consistent with the model described at
> http://musicbrainz.org/doc/DocumentationIndex
>
> Hmmm. Now I look again at the MO site I see that the ontology is at
> version 2 and has realigned its model somewhat. When I was working on
> this last week I was working with the RDF that was sent from the site
> which was revision "Revision: 1.03 - 2". I think I have some rework to
> do...
>
>
>
>>
>> 4. For modelling the links of a resource from different information
>> services, I would suggest to use the new Info Service Ontology[5], which
>> also opens the door for new or currently unknown (music) information
>> services.
>>
>
> OK, I'll take a look. I'll admit that I'm not really sure what an
> information service is - the term is very broad and my initial glance
> at the spec didn't tell me what one was and whether I would want to
> use it.
>
Okay, maybe you'll have a look at the proof-of-concept-example[2], then
it sohuld hopefully clear. Otherwise, don't hesitate to ask me questions
about it.
Cheers,
Bob
[1]
http://groups.google.com/group/music-ontology-specification-group/msg/3dd7dd9c66dc5cfe
[2] http://purl.org/ontology/is/infoservice.html#sec-example
Kingsley Idehen
> Hello!
>
> So as far as I know, we have three mappings from Musicbrainz to RDF (I
> think this is a record :-) ):
>
> 1) The Zitgist/OpenLink mapping
> 2) The DBTune/D2R mapping
> 3) The DataIncubator one
>
> ... which is starting to be quite confusing for Linked Data users.
>
> I think we should get our act together and actually push it to the
> Musicbrainz codebase, now, especially as the NGS branch is being more
> stable and stable.
>
+100
Kingsley
--
Regards,
Kingsley Idehen
President & CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Kurt J
On Mon, Jul 19, 2010 at 10:14 AM, Yves Raimond <yves.r...@gmail.com> wrote:
> Hello!
>
> So as far as I know, we have three mappings from Musicbrainz to RDF (I
> think this is a record :-) ):
>
> 1) The Zitgist/OpenLink mapping
> 2) The DBTune/D2R mapping
> 3) The DataIncubator one
>
> ... which is starting to be quite confusing for Linked Data users.
yes, it is a bit confusing. and we are starting our project in August
with MusicBrainz to make the mbz server a linked data server.
Sometime in the future, when you de-ref
http://musicbrainz.org/artist/<mbid> you will get linked data, I
promise ;-)
and not to diminish the previous work or Ian's current work, but our
hope is that this effort will make all other mappings sort-of
deprecated.
> I think we should get our act together and actually push it to the
> Musicbrainz codebase, now, especially as the NGS branch is being more
> stable and stable.
after much dithering, it finally looks like this will be a
more-or-less full-time job for me starting in August. sorry it's not
happening sooner - we're moving at the pace of academia...
soon there will be some concrete stuff, probably starting with some
pages on the MusicBrainz wiki, where interested parties can contribute
ideas.
cheers,
kurt j
Kingsley Idehen
I don't think there will be definitive mappings per se.
What we can attempt to do at this stage is harmonize what's been done so
far, mapping wise.
Linked Data is an art form (like music), no two hand paintings or live
performances are exactly the same once the artists differ. This reality
will hover over Linked Data forever, and for many good reasons :-)
Frederick Giasson
> yes, it is a bit confusing. and we are starting our project in August
> with MusicBrainz to make the mbz server a linked data server.
> Sometime in the future, when you de-ref
> http://musicbrainz.org/artist/<mbid> you will get linked data, I
> promise ;-)
>
> and not to diminish the previous work or Ian's current work, but our
> hope is that this effort will make all other mappings sort-of
> deprecated.
project with the MBZ group. In fact, if people remember, I started this
ontology, nearly 5 years ago, *exactly to reach this goal*. Then Yves
joined to push MO to become a more general music related ontology (so
that it is not too biased to a single usecase), and then Kurt, Simon and
all the others main contributors of the community.
So, it tooks about 5 years to make it happen, but well, apparently that
it will happen! :)
It takes time to change visions, techniques and practices, but it
eventually happen.
Thanks for your hard work guys! (I know I haven't been much active in MO
for more than a year :|)
Take care,
Fred
Kurt J
thanks for your insightful reply.
i totally understand this notion and our goal is to have the mapping
in the musicbrainz core be as harmonious as possible.
> Linked Data is an art form (like music), no two hand paintings or live
> performances are exactly the same once the artists differ. This reality
> will hover over Linked Data forever, and for many good reasons :-)
quite quotable - i like it ;-)
i think we'll find many things are pretty cut-and-dry wrt to
musicbrainz mapping. however some things, (e.g. the Advanced
Relationships) will perhaps have some different view points. as you
say, there's no reason alternative mappings shouldn't exist.
i suppose my hope is that music-related URIs of the form
http://musicbrainz.org/artist/<mbid> become more ubiquitous in linked
data. the level of replication we have now seems a bit confusing and
inefficient.
and to Frederick
> Thanks for your hard work guys! (I know I haven't been much active in MO
> for more than a year :|)
thank you for helping with the foundations! a bit sobering this is 5
years in the making! we're still here on the mo list whenever you
want to come back ;-)
-Kurt J
Yves Raimond
On Tue, Jul 20, 2010 at 1:28 AM, Ian Davis <m...@iandavis.com> wrote:
> I am wondering if a better table mapping would be:
>
> release_group ---> MusicalWork
No, that wouldn't work - the NGS introduces a 'work' table, so that
may be very confusing when the new schema is release. Also, a release
group is quite different from a work - this is a grouping of similar
releases, not a grouping of similar performances. For example, if I
were to make a cover album of Sergent Pepper, I would use the same
work, but result in a different release group.
So, I would think
release_group => mo:SignalGroup
>
> album ---> MusicalExpression
>
Album => mo:Record
> release ---> MusicalManifestation + ReleaseEvent
>
release => mo:Release / mo:ReleaseEvent
A record is a particular disk. A release is a group of disks, liner
notes, etc. A release event captures the date at which the release has
been released.
I hope that's clearer! But basically, the last version of the Music
Ontology was designed to map 1:1 (with the exception of the release
table split in release and release events) with the Musicbrainz NGS.
So that should hopefully work...
I planned to update the D2R mapping on DBtune with the NGS dump when
the new Music Ontology was released, but I didn't have the time.
Hopefully, I'll be able to do it soon.
Best,
y
> (Confusingly, the album table contains things that are called releases
> on the MB website, and the release table contains things called
> events)
>
> My reasoning is that in the MB database schema, the release table
> contains both a link to the album being released and the barcode/catno
> of the released item. This puts it at the manifestation level.
>
> The album table contains a link to the release_group table which
> represents a group of related "albums" that are of roughly the same
> creative content.
>
> For example:
>
> This is the release group for the Oasis album Definitely Maybe:
>
> http://musicbrainz.org/release-group/451dca98-c118-32e1-9244-c47ca9c3c0f9.html
>
> It seems to represent the abstract notion of Definitely Maybe as
> conceived by the group. And links to the individual releases in the
> group which could correspond to the expression of a work.
>
> http://musicbrainz.org/release/ef927fa4-2f6b-4431-8867-0573b0e9c234.html
>
> At the bottom of that page you can see the individual manifestations
> with their catalogue numbers.
>
> I'm going to try this out and see what it looks like...
>
> Ian
>