Musicbrainz

[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

[Bob Ferris]

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

[Kurt J]

Hi Ian,

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/

> --
> 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.
>
>

[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.

These are how I am mapping the major tables:

* artist: mo:MusicArtist (and mo:SoloMusicArtist / mo:MusicGroup )
* release_group: dimb:ReleaseGroup (new class)
* album: dimb:Release (new class)
* label: mo:Label
* release: dimb:ReleaseEvent (new class)
* 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.

> More thoughts maybe later.
>

Thanks - very helpful

Ian

[Bob Ferris]

Hi Ian,

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

[Kurt J]

Hello,

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

[Kurt J]

Hi Kingsley,

thanks for your insightful reply.

> Kurt,
>
> 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.

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]

Oops - sorry for the spam, it looks like dataincubator is members-only.

y

On Mon, Jul 19, 2010 at 4:14 PM, 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.
>

> 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.
>>
>>
>

[Ian Davis]

Just moderated on first post for spam reasons

>>>> [3]  <http://wiki.musicontology.com/index.php/ProposalRevision14>>> 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.
>>>
>>>
>>
>

[Ian Davis]

I am wondering if a better table mapping would be:

release_group ---> MusicalWork

album ---> MusicalExpression

release ---> MusicalManifestation + ReleaseEvent

(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

[Yves Raimond]

Hello Ian!

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

[Ian Davis]

Thanks Yves,

On Tue, Jul 20, 2010 at 10:15 AM, Yves Raimond <yves.r...@gmail.com> wrote:
> Hello Ian!
>
> 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...
>

Yes, very much so!

I think part of my problem is that I was working with the current
database schema not the NGS one. I'm going to look at the NGS dump at
http://ftp.musicbrainz.org/pub/musicbrainz/data/ngs/ and take it from
there

> 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.

That would be good to see.

>
> Best,
> y

Thanks,

Ian