crism

crism: Wrong banner

2008-08-21T02:04:17.0012Z

Thank you

crism: Wrong banner

2008-08-21T01:55:19.0012Z

Thank you

carmenmfenn1

crism: Wrong banner

2008-08-20T21:42:28.0012Z

Jeff, my dear, the merge took place today and cheunger removed the delete flag manually!! Now I can breathe again and thank you all for the speedy action. It would have been a catastrophy to loose all that work...

carmenmfenn1

crism: Wrong banner

2008-08-20T21:37:16.0012Z

It will take a long time for this item to come up in the queue of merge/delete tasks (there are several hundred ahead of it), so this flag won't be cleared for awhile. But it won't be deleted; don't worry.

crism: Wrong banner

2008-08-20T21:36:17.0013Z

THANK YOU and be blessed!

carmenmfenn1

crism: Wrong banner

2008-08-20T21:33:40.0012Z

Hi Carmen,

This is probably an artifact of the merge. When the topics were merged, the delete flag was also merged. I've already filed a bug regarding this and in a future release, the flags should be reset after a merge. I've gone ahead and manually removed the flag.

crism: Wrong banner

2008-08-20T21:30:18.0012Z

EXACTLY!!

I hope you can stop this, I worry my head off .

carmenmfenn1

crism: Wrong banner

2008-08-20T21:27:05.0012Z

It looks like the bad topic got merged into the good topic, and the "delete" flag got merged along with it. This is clearly a bug -- thanks for bringing it to our attention!

crism: Wrong banner

2008-08-20T20:48:55.0017Z

Good morning, Cris

long ago I flagged the duplicate Lorenzo Ferrero with Merge or Delete. Today after the merge, the Delete banner appeared on the GOOD page. Please have a look, as it was never meant to be like this, the actual page is not for deletion! Thank you,

carmenmfenn1

crism: Test

2008-08-02T16:12:06.0012Z

Um… you’re welcome? I’m not really sure what I did, though. Or am supposed to do?...

crism: Test

2008-08-02T14:36:39.0012Z

http://www.computescotland.com/1501.php

Thanks for giving me some IT type link for Jura.

Best,

Gail

Music modeling: Classical works

2008-05-22T19:53:02.0007Z

This is an interesting start, simonhill.

The Opera domain was done as its own project; the Opera type should probably be refactored to include Composition (and similarly Opera Composer should include Composer.

Some technical notes on your types:

The catalog abbreviation and opus number should be text (or even machine-readable strings), not Topics; making D (the topic about the fourth letter of the English alphabet) the abbreviation for Schubert’s catalog is a bit strange, likewise for the number 1.
The expected types for other properties could also be adjusted; the “composer” property should expect Composer, “musicologist” should expect Person, or ideally, a new Musicologist type.
I would also have your composition include the Composition from the Music domain to make it easier to see what properties are already present and which need to be added. Is a discrete “title” really needed, in addition to the name of the topic?

Thanks for getting this started.

Music modeling: Classical works

2008-05-21T08:10:43.0005Z

I have a lot of classical music data (composers and their works, with opus numbers and catlog numbers etc.) which I'd be happy to load up.

However, I note that there are some issues around the schema in this area; e.g. there separate entities for composition and opera. (Surely, this can't be correct - an opera is a type of composition), there is no provision for opus numbers, catolog numbers etc.

Is anyone working in this area? Anyone have any recommendations for a good, practical way forward?

Music modeling: Date and place of recording tracks

2008-04-17T17:44:40.0007Z

definitely interesting data. i endorse the simple model. putting the onus on the developer to deduce some obvious questions seems reasonable:

Did trackA originate from the same session as trackB (by the same artist)? If the location is the same and the date is close (say to the month) then True

Seems easy enough.

Music modeling: Date and place of recording tracks

2008-04-17T06:11:03.0007Z

I understand now, Robert. That is kind of the crux of the question; we could be more pedantic and expicitly model masters and/or recording sessions which underlie tracks. That would be a more robust and thorough model, but it would also complicate actual use. Al’s opinion is that the track level is sufficient for now, and as he is more likely to use this than I am, I am inclined to go with that, as we can always garden out an implicit session from a track later on.

Music modeling: Date and place of recording tracks

2008-04-17T05:57:39.0007Z

I'm sorry. I asked my question badly. If you are attaching recording-session specific data to a track, would the track be the "definitive" version of that recording, or would there be other instances of tracks that represent that same recording? In other words, would people be able to find the session data if there are many representations of the recording?

Music modeling: Date and place of recording tracks

2008-04-16T01:00:32.0007Z

A Musical Track should be a bit of recorded sound expicitly instantiated somewhere, whether it’s in a file, on a disc, or on a tape. Some tracks will come from single recording sessions, others will be mixed from multiple sessions, and sample-based tracks might not ever have been really “recorded” at all, at least not by the credited artist.

Music modeling: Date and place of recording tracks

2008-04-15T23:45:19.0007Z

How abstract is "track" now? That is, how often will there be tracks in freebase that are copies of a specific recording session?

Music modeling: Release label, catalogue ID, and format

2008-04-15T23:43:02.0000Z

I believe your analysis is right, Jeff, and I agree that it is easier to keep the format, the physical medium, on the release event. It also harmonizes better with the MusicBrainz data. Now I just need to see if it makes anyone else cranky. (-:

Music modeling: Date and place of recording tracks

2008-04-15T21:09:43.0007Z

This works for me.

Music modeling: Release label, catalogue ID, and format

2008-04-15T21:08:36.0000Z

To get this straight:

If we put the format on "release event", a "musical album" would only have multiple "musical releases" if the releases had different tracks (either because they were remastered or because releases have different track listings).

If we put the release format on "musical release" instead, then the US, UK, and Japanese CD releases of an album would all be one "musical release", and the simultaneous US, UK, and Japanese LP releases (from the same respective labels) would be different "musical releases".

Is that right? If so, I think the first one is probably better -- the second one seems confusing to me.

Music modeling: Release label, catalogue ID, and format

2008-04-15T02:18:04.0000Z

And should the release format (78, 45, LP, EP, 8-track, cassette, cassingle, CD, CD-single) be on this release event CVT? That mimics the MusicBrainz model, but if that’s not what we want to do, we could put the format on the release itself and force multi-format releases to split.

Music modeling: Date and place of recording tracks

2008-04-15T02:15:02.0000Z

I have modeled these on sandbox. I hedged; the two properties do not use a CVT and have singular names, but they are non-unique. If there is significant user confusion or demand for more complex models, we can always promote the existing values to use a CVT.

Music modeling: Release label, catalogue ID, and format

2008-04-15T01:18:22.0007Z

I have modeled a release event on sandbox. I’m not keen on the name—I picked it for the release rather than the label/catalog association—but please let me know if you like the model and/or if you have a better suggestion for the name.

Music modeling: Date and place of recording tracks

2008-04-15T00:37:11.0000Z

This sounds like fun data to me. Good cocktail party discussion. How about using "Place of recording" because this might differ from where it was engineered or mastered. The location property could be added as a CVT with date and permitted to hold multiple entries for instances when multiple takes are included on a single track (an option that probably won't be used that much).

Music modeling: Date and place of recording tracks

2008-04-14T19:33:20.0007Z

I think date and location are good properties for tracks in general; I don't have a strong opinion about the depth of the model, though.

Music modeling: Date and place of recording tracks

2008-04-14T18:48:16.0000Z

Getting finer grained than track seems like overkill. I'd be happy with Place and Date on Track. How about on Album too? Most albums are recorded in the same place, and most live albums are recorded at the same time.

Music modeling: Track contributions

2008-04-14T18:43:29.0007Z

Very nice. You may want to remove /common/topic as an included type.

Music modeling: Track contributions

2008-04-14T18:14:06.0007Z

I like it.

Music modeling: Release label, catalogue ID, and format

2008-04-14T18:11:26.0000Z

The current model doesn't currently support the MusicBrainz's model, either, since we don't correllate release date to label. I had assumed that each label/date/format combination constituted a different "musical release" already. Obviously, a CVT would simplify this somewhat, if we wanted to assert that a "musical release" only implied that the tracks were the same, regardless of when/where/how/by whom it was released.

The one possible issus I see with this would be the "credited as" property, which would most likely differ on foreign releases. But I don't have any good ideas about dealing with the MB IDs.

Music modeling: Release label, catalogue ID, and format

2008-04-12T04:10:02.0012Z

Right now, a release is linked with its label (or labels). However, the catalogue number and format is not given.

If we add this information, it will mean a new compound value type, since the catalogue number has to be associated with the label and format. See MusicBrainz’s record for Sgt. Pepper’s Lonely Hearts Club Band for an example of how this would be modeled.

Is this too complex? Should a so-called “release” with multiple formats be forced to split into multiple releases? If so, what happens to the MusicBrainz-correlating IDs, since MusicBrainz is not so careful?

Music modeling: Track contributions

2008-04-12T04:05:36.0012Z

Right now, one can model contributions by an artist who isn’t the primary recording artist on the album level, but there is no way to capture equivalent information at the track level. I have modeled a proposal on sandbox; please check it out and comment in this thread.

Music modeling: Changing the name of the Musical Artist "Songs" property

2008-04-12T04:02:19.0007Z

This is done; “Tracks Recorded.” I don’t like “Other tracks” since it can be used just fine for tracks on albums by that artist. However, the key has remained unchanged lo these many years, so this is negotiable.

Music modeling: Changing the name of the Musical Artist "Songs" property

2008-03-07T23:04:07.0012Z

The "Songs" property on Musical Artist is confusing as it points to tracks (not songs) and it doesn't include all tracks an artist has made. In most cases, this property only includes tracks on compilations. At some point, it may contain all tracks, but for now this is confusing.

I suggest we rename this to "Other tracks".

Music modeling: Composition: Uses Melody From and Uses Chord Changes From

2008-03-07T03:57:57.0012Z

It’s been proposed, and experimented with briefly, to add two new pairs of properties to Composition: “Uses Melody From”/“Melody Used By” and “Uses Chord Changes From”/“Chord Changes Used By.” Trivial examples are “The Star-Spangled Banner” uses the melody from “The Anacreontick Song,” and half of the jazz tunes in the world use chord changes from “I Got Rhythm.” Thoughts on either the structure or the property names?

Music modeling: Pseudonyms going away

2008-03-07T03:53:52.0007Z

This happened. One interesting side-effect is that many artists are currently named by their legal names instead of their better-known performance names. If you run across, them, please do change them. We will be running a gardening sweep later to attempt to determine their best-known names (based on the Creative Work credits), but some human input certainly wouldn’t hurt.

Music modeling: Pseudonyms going away

2008-01-28T21:57:06.0012Z

As posted on the data modeling mailing list, the Pseudonym type is going away. A new type, Creative Work, is being used to capture the literal credit on Musical Releases, but the artist relationship will connect to the actual artist, regardless of name.

Music modeling: MusicBrainz data updated

2007-12-20T21:15:29.0005Z

Artist, album, and release information has been updated from MusicBrainz. It’s not detailed yet, but the objects should all be there, labeled and connected correctly. See any problems? Let me know, please!

Music modeling: Albums vs. Releases

2007-11-30T01:16:48.0007Z

This operation is done. Every album for which we have any release information from MusicBrainz should now have at least one explicit release.

Music modeling: Music Ontology

2007-11-28T23:50:47.0040Z

Ah—these are the guys that Robert Kaye from MusicBrainz was talking to when we were meeting in London. Our goal is to be compatible with them, and with the next-generation MusicBrainz schema, but not necessarily have a complete one-to-one correspondence. We would like to be a little more flexible than a rigid ontology, for instance; note that they have taken MusicBrainz’ release type list verbatim, while Freebase allows users to enrich the categorization of release types. (For example, MusicBrainz and Music Ontology don’t allow an album to be a live spoken-word recording, or a remixed EP.)

Music modeling: Albums vs. Releases

2007-11-28T23:44:59.0043Z

I am not sure I am completely following all the abstract jargon here, being elbows-deep in concrete instances. (-: This process is running on the production system right now, and will complete tonight. What it means is that (effectively) every album will have at least one release. Each album will have a set of tracks; those tracks will be the same as the track listing for the first known release.

As for abstract tracks, this is what the notion of Song and Composition are intended to address. MusicBrainz’ next-generation schema will have a notion of mix, recording, arrangement, and composition, for users that want to get to that level of detail, but I think that (for now, at least) that is beyond the scope of Freebase. I could be persuaded otherwise, but part of that persuasion would have to be a large cadre of users prepared to enter that data manually, as it’s not readily available anywhere that I’m aware of.

Music modeling: Music Ontology

2007-11-28T16:55:05.0033Z

Have you guys seen The Music Ontology in RDF/OWL, www.purl.org/ontology/mo/ ? (Actually if you're not into reading raw RDF then you will probably prefer reading http://musicontology.com/)

There may be some ideas you can share... the same people are also working on a TV/Radio Programmes ontology for us at the BBC, which we're going to release publicly Real Soon Now...

Music modeling: Albums vs. Releases

2007-11-26T18:53:23.0007Z

I would definitely prefer that same level of abstraction on the track level.

The only reason why I hesitate at the idea of a definitive release, as its much more likely that "releases" will be added to a group of tracks than another track will be added to a release. Wouldn't it make more sense to populate albums based on the tracks, or "recorded works" and not the other way around? A definitive "recording body" ? Releases tend not to share much meta-data with the first album other than information that really could come from the track meta-data anyway. They often have different mastering engineers, release dates, formats, and sometimes even labels.

For one manifestation to be denormalized as a convenience, it should conveniently have meta-data that we are most likely going to use. Since its the track meta-data that tends to re-appear and not the details of any one initial release, it seems to me it's worth bringing track information up for convenience instead of repeating album meta-data.

Music modeling: Albums vs. Releases

2007-11-24T19:58:16.0007Z

Adam -- Chris is picking a release that might be considered as the "definitive" release and denormalizing the tracks and other data to the properties on the Album. This is done as a convenience to someone writing an application who's not interested in sifting through the various releases to find a track listing when building a simple application.

To clarify: The new Album type is a collection of manifestations, where one manifestation is denormalized as a convenience. Even though this information suggests that it's a particular release, the Album should still be used in an abstract way. If you want to attach the Album to a DVD, you can.

I'm beginning to wonder, however, if instead of tracks, an Album should point to "recorded works", which are abstract in the same way.

crism: Test

2007-11-20T02:13:29.0129Z

Is this thing on?

Music modeling: Albums vs. Releases

2007-11-19T23:44:56.0007Z

I guess what I'm getting at is why must we associate the "meta-album" with a physical album? I would think that all meta-information should be tied to releases of cd's but have the "album" be just a node. I say this because then DVD's about the album could also be tied to this node, as well as the artist- without having to incorrectly state that a particular actual release is the official manifestation of the recorded experience.

For looking up information about a track, if you have a live album, and there is DVD of that recording in video form, shouldn't we be able to find that connection through Freebase? Wouldn't that connection be easier if "album" was a collection of manifestations, instead of having an official manifestation with many releases related to it? What is gained by associating a recorded experience with an official version of it, especially if that experience may not live completely in the auditory domain?

Music modeling: Albums vs. Releases

2007-11-19T02:26:24.0007Z

Adam, this is, as Robert suggests, where we’re headed. The missing use case is the one where I slap a piece of plastic into my computer’s drive and want to look it up, or I have an audio file that I ripped a long time ago or which I bought on-line, and which I want to look up. (I am not proposing that Freebase should be the lookup service, but having found an identifier from MusicBrainz, how much information can I then glean from Freebase?) In that case, I need a database of separate, distinct tracks and releases. Now, we could aggregate all the relevant MusicBrainz identifiers onto the relevant albums, but I would like to know whether this is the shorter American mix or the longer UK mix, or whether it’s the lousy initial CD release or the gold-remastered high-quality later release.

As far as track identity, which you touch on, the idea is that truly identical tracks—such as if the single version is the exact same mix as the album—then the track should really be a single entity in Freebase. But if it’s been remastered (dance mix, short version, etc.) then it should be a different track. It should, however, be the same composition; I look forward to the point where we can get that rich information.

Music modeling: Albums vs. Releases

2007-11-16T03:26:39.0000Z

I'm a bit confused. Isn't what you're proposing pretty much the same as what Chris was proposing? That there is a more abstract "album" that would contain the human-friendly meta-information and that there would be aggregations of releases that were very similar?

Music modeling: Albums vs. Releases

2007-11-15T00:42:28.0007Z

I really do wonder about this album modeling issue. I understand why you went with it to begin with, but I think there is a simpler way to model this.

If you consider each album as a collection of track recordings, you can bypass all the complexities of releases and different versions. When you consider the use case, most people want to associate ties between listening experiences. That experience is dictated by the recording, not the metadata associated with the album.

singles can be tied to relevant tracks
7inch singles are versions of 7 tracks
12 inch singles are versions of the same 7 tracks
Promo releases of an album, that were released, then recalled, then re-released under a different mastering engineer, are still the same 7 tracks.

This would allow one to infer a "meta-album" between multiple releases. If you have 6 different releases, but the tracks are exactly the same, you can infer that this collection is one consistent "album" regardless of how many forms it has. To work backwards from the album adds a lot of complexity.

If a promo release has different tracks than the "official" release, why are they grouped together? In a purchase decision, these are separate products, even if they have similar components.

To solve the cluttered discography issue, you can set a view for simliarity. If more than 70% of the tracks are simliar, view as one meta-release.

I only suggest this because why would someone want to find their way back to the album through the tracks, if the tracks do not contain any of the "fun" information?

Music modeling: Albums vs. Releases

2007-11-13T19:54:47.0007Z

I think you definitely want "running time" on the release. As to whether it should be on the album as well, I'm a little torn. I agree with Chris that it's potentially useful to have it attached to the album, but given that the model is moving in the direction of more abstraction at the album level, it may not make sense to have it there.

I think this is one of those cases where inherited properties ("transitive properties"? what were we calling them?) would be handy, e.g. "the running time of a release is the running time of the album unless a value exists for the release"