Music Domain Documentation

Music Domain Documentation: Weird definition?

2007-08-15T13:12:17.0007Z

Oh yes, i completely forget, sorry about that:
http://linkeddata.org/

You can check the mailing list for up-to-date information about interlinked datasets, and this page for a concrete explanation of what we do and why we do it:
http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/LinkedDataTutorial/

I know Chris Bizer has been in touch with some freebase people, I don't know who, though.

Music Domain Documentation: Weird definition?

2007-08-10T22:08:57.0008Z

Yves,

By multiple tracks I meant substantially different audio artifacts. If the single is the same as the album track, then it should be the exact same object in Freebase. If, however, the single contains a shortened version, it should be a different track.

We’re not trying to replace MusicBrainz, so I am not sure that capturing recording sessions (i.e., performances) is necessarily the right thing. MusicBrainz’ next-generation schema should be capturing that level of detail; we will have to see if our community demands it from us as well. (I’ll put you down for one vote yea. (-:)

We have Composition, Arrangement, and Musical Track, flattening the intervening layers. We could also have relationships between tracks as needed for alternate takes, radio edits, etc. (analogous to MusicBrainz’ “advanced relationships”). Do you think that would suffice?

Do you have a link to the “linking open data project”?

Music Domain Documentation: Weird definition?

2007-08-10T13:10:44.0000Z

Hi Crism!

Just a quick comment re. "the same recording ends up as multiple tracks" - well, that happens a lot! (for example singles/albums, which often have at least one track in common).

Also I think you should capture the notion of Performance, between a Composition and a Track, exactly for this sort of reason?

Anyway, we have a mailing list for this sort of discussion - it would be great if you could join us!
http://groups.google.com/group/music-ontology-specification-group

So far, the data model that raised from discussions there is something like:
Composition (---> Arrangement) --> Performance --> Recording ---> Track, record, etc.

(btw, have you heard about the linking open data project? there is a big music-related part in it, and we already interlinked quite a few datasets - Jamendo, Musibrainz, Magnatune, DBPedia, John Peel sessions, etc. etc.)

Cheers!
y

Music Domain Documentation: Weird definition?

2007-08-09T17:46:28.0000Z

Hi, Yves! We do plan to add contributions to tracks as well as to albums. However, specifically for compositions, we have a Composition type that would handle that; you would have composed an instance of a Composition, and various Musical Tracks would be recordings of that composition.

Performance contributions (such as conductors) would then be a little easier to track; sometimes, the same recording ends up as multiple tracks (alternate versions on box sets, e.g., but that’s a relatively rare case and I think it’s not too much trouble to capture the performance contributions separately for those.

Music Domain Documentation: Weird definition?

2007-08-09T12:19:04.0004Z

Hello everyone!

Just taking a look at this definition, it seems a bit wrong to me: what if you want to attach to several track/album, etc., the same contribution? If I composed a particular song, I want all performance/recordings of this song attached to my particular contribution?

This seems to go back to the workflow stuff defined in the music ontology (http://musicontology.com/imgs/mo-workflow.jpg) - you can attach agents (performers, composers, conductors, whatever) to every event in the music production workflow (composition(/arrangement)/performance/recording)

Best,
Yves

Music Domain Documentation: better unit displays

2007-07-05T18:18:02.0012Z

I agree we should list them in hour:minute:second like the rest of the world; we just don't have this feature right now (it's a question of UI presentation of 301 seconds as "5:01")

I'll bring it up with the appropriate people.

Music Domain Documentation: Quick Questions

2007-06-26T22:06:12.0006Z

Tracks are given in number of seconds because number of minutes would be too hard (5.333333…). (-:
We are working on support for values with units, such as times in seconds, that will enable more user-friendly display and editing, but we’re not there yet. Having consistent underlying data (1220.0) instead of a possibly-parseable string (5:20, 5'20", 5m20s, 5.20) will make enabling that feature possible when the tools are ready.

Music Domain Documentation: Quick Questions

2007-06-26T19:50:31.0011Z

Hey folks,

Why on earth is track length listed in number of seconds?

And can album track listings have numbers next to them?

Music Domain Documentation: Musical artists: types vs professions

2007-06-17T20:30:04.0006Z

I think the use you point out is fine. I have two basic use cases in mind:

1. Find all the singers in Freebase. Unless you know in advance that the way you find this is via profession attributes on musical artist types, you will not be able to do this. Instead you will find the 5 instances of singers as types that someone has created. This is confusing.

2. Extract out from Freebase properties with which to tag individuals. In the case of musical artist or other types, this is easy (you just use the type). In the case of singers, you have to have separate logic that checks the profession slot to determine that the person is a singer.

If we're going to be using key information sometimes in a profession attribute, and sometimes in a type, one thing that would help would be an explicit handle on the possible (or existing) values for an attribute on that type, with a way to find all the instances that have that value. Then it would be clear when looking at a musician that there are multiple kinds (almost subtypes...) based on the profession.

Music Domain Documentation: Every track should have a song

2007-05-29T14:32:26.0006Z

You have a good point. The problem is just that composition credits are harder to find than recording credits, and so I’ve only been typing Musical Track instances as Song when I actually have composition information for them, and I’m sure they’re the definitive version.

Music Domain Documentation: Musical artists: types vs professions

2007-05-29T14:30:25.0006Z

The main reason for the Songwriter type is to enable the properties for songs composed and lyrics written. Singers of recorded songs are generally reflected by either band membership, direct recording credit, or contributions, so a separate type isn’t needed. The profession probably is a more appropriate place to record that information unless and until someone comes up with a compelling case for a Singer type.

Music Domain Documentation: Every track should have a song

2007-05-26T23:54:14.0011Z

I don't think you should say in the documentation that "if a track is the only or definitive version of a song, no song topic is needed". Every track should point to one or more songs, because there are certain attributes (composer, lyricist) that belong to the song, not the track.

(Note the "one or more songs" above. A track like Springsteen's "Devil with the blue dress / Good golly Miss Molly / Jenny Jenny" should be a single track pointing to three songs.

Music Domain Documentation: Musical artists: types vs professions

2007-05-26T21:17:00.0011Z

There seems to be some confusion about whether specializations of musical artists are themselves subtypes or professions. For example, there are hardly any instances of "singer" in freebase (only 5?), despite their being many musicians for whom it is clear that they are singers. Sometimes musicians have associated profession of "singer". But there is no type for "singer", so I don't see any way to easily add that information.

Why is "songwriter" a type, but "singer" only a profession?