On Tue, Jan 6, 2009 at 11:15 PM, Adam Golding <adamgold...@gmail.com> wrote:
> This ontology looks right to me for 'standard classical music', but there's
> no predicting if it will turn out to be too restrictive in the future--and
> it's a major inconvenience to have to change things later.
>
> In general, the following method, which people seem to converge on, is
> dangerous:
>
> 1. Propose an ontology
> 2. Try to think of counterexamples
> 3. If you thought of counterexamples, return to 1
> 4. If no one's thought of any counterexamples for awhile, implement the
> ontology
>
>
> The problem, of course, is that this depends on how good our imaginations
> are. Keep in mind that part of an artist's contribution can actually *be*
> what they do to people's conceptions of musical ontologies, and in fact
> modern ontologies (such as CD/track) have actually helped to marginalize
> musics which have different ontologies, such as classical music.
>
> So I would say we need a system which imposes as few restrictions as
> possible, lest Musicbrainz end up limiting the ways that Artists can ask
> their listeners to think of the 'structure' of their output. That is, I
> propose the following method:
>
> 1. Lay out what we need of a 'works' ontology
> 2. Implement an ontology which is, more or less provably, the least
> restrictive ontology that gets us what we need in an ontology.
>
>
> minimally, we need at least the following:
>
> 1. entities, let's call them 'works', or perhaps we can find a more
> general name, which are not recordings, but which can stand in relations to
> recordings, and to other works.
> 2. The fluidity to define new such relations as they become needed.
> 3. The ability to specify condiitons that these relations must satisfy
> 4. We also need to be able to talk about sets of recordings, i.e. "the
> first 4 tracks of Album X"
>
> once this is in place, we can evolve the system as we go. We could have a
> system for voting on new relations (i.e. to decide if the relation is really
> 'new' or just falls under some old relation).
>
> For the issue of movements, subworks, etc, we would just define a
> relationship like isASuworkOf and make isARecordingOf automatically
> propagate to parent works, so that, where R is a recording or set of
> recordings:
>
> if A isASubworkof B and R isArecordingOf A, then R
> isARecordingOfPartOf B
>
> and
>
> if, for every A such that A isASubworkOf B, R isARecordingOf A, then R
> isARecordingOf B
>
>
> Obviously, this is just a start, but hopefully I can convince you of the
> spirit of this approach? :-)
>
>
With regards to the latter half - works and merging them, then yes, I
agree. That's pretty much exactly how I'd suggested we could handle it.
Somewhere in the wiki, there's actually some graphics I threw together
demonstrating just that approach.
With regards to your first point, however, I think maybe it misses the
point. Will some classical not fit that ontology, especially - thinking of
Nyman, Glass, Cage, or Reich here - modern classical? Sure. But what I'm
talking about is traditional classical, of which there are thousands, if not
tens or hundreds of thousands. Works as mere text strings may work fine for
other music. I know that would likely be the case for the 4 composers
mentioned a minute ago, plus, likely, jazz, as well as all pop, r&b, etc.
The ontology structure is also built to handle opera and musicals under the
current guidelines, except for roles support (which proposal I also would
love to see happen, but that's a different conversation).
This dual text string works & composited works concept is exactly how I
suggest we not marginalize different music ontological groups in future, as
we do now (artist - release - track). I recognize, however, that an element
based work system is a lot more complex to implement than a simple text
string one; hence my suggestion that we at least get basic (text string)
works support for all music, finalize CSG to a point it can be used in that
context, and eventually then essentially eliminate CSG when element based
works are possible, and we can simply compose a CSG-like title from the
elements, no longer needing to force classical into a single
one-for-everyone text string.
The point is, though, you don't have to only have one or the other. Works
as mere text strings are fine for most everything else. It's traditional
classical which doesn't fit that. A main argument a year ago was over how
much detail various people want in classical titles, and in which orders,
etc. CSG is an attempt to form a complete and consistent title, but it
doesn't and cannot address this other problem. Breaking the bits of
classical titles into all the various elements, however, does. It allows
for work title text to be generated (or rebuilt, via taggerscript, to user
preference) from the elements, as well as greatly simplifying translation
efforts for such elements.
As for your point #4:
>> 4. We also need to be able to talk about sets of recordings, i.e. "the
first 4 tracks of Album X"
...no, for works, we don't. The whole point is that works exist a level
above recordings, completely aside from the album. So why would we ever be
talking about the first 4 tracks of album X in a works context? The only
possible reason I can think of would be to link, say, the four movements of
something like a symphony. This too is something, I think, best linked at
the work level, not the album level, as it shouldn't ever change, unless
you're not actually dealing with the same work. But it already is in the
ontology: see the "Classical Work" at the top, encompassing the Classical
Movement(s), and itself a part, possibly, of a larger work ("Classical
Supra-Work"), which itself may be part of an Opus ("Opus / Catalogue /
Collection"), etc. http://wiki.musicbrainz.org/BrianFreud/ClassicalOntology
Brian
>
> 2009/1/6 Brian Schweitzer <brian.brianschweit...@gmail.com>
>
>> On Tue, Jan 6, 2009 at 4:27 PM, Frederic Da Vitoria
>> <davito...@gmail.com>wrote:
>>
>>> We should all know that things may not move for at least a few months.
>>> But in the meanwhile, we should make as sure as possible that we won't
>>> regret this later. For example, we have this idea of a WORK, but exactly
>>> what does WORK mean in the classical context? A work in the usual meaning (a
>>> symphony or a waltz), a movement, something in between, any of those? This
>>> can get tricky for example when we think of operas or of variation movements
>>> for which tracks may be split.
>>>
>>> I think our WORK concept must be precise enough to link precisely to a
>>> track, but it must also allow for wider points of view (when I search for
>>> Brahms' 3rd symphony, I am not necessarily interested in the 3rd movement
>>> ;-) ) It must be able to express all the different meanings we give to the
>>> word "work", including for example different versions.
>>>
>>>
>>> 2009/1/6 Adam Golding <adamgold...@gmail.com>
>>>
>>> So what needs to be done to get works off the ground? I can't offer
>>>> programming skills at this point, but I'd love to help with any of the
>>>> (thorny) design issues..
>>>>
>>>>
>>>> 2009/1/6 Paul C. Bryan <em...@pbryan.net>
>>>>
>>>>> +1
>>>>>
>>>>> I'm convinced, especially if different track titles could be
>>>>> represented
>>>>> with release events.
>>>>>
>>>>
>> I guess my answer is this:
>> http://wiki.musicbrainz.org/BrianFreud/ClassicalOntology
>>
>> That's what I mean by works broken down to collections of elements. I
>> could almost see us then building, either one by one, or for various music
>> types, strings to define generic ways these would be put together again for
>> (non-user, generic) work titles - essentially, CSG in its truest, most
>> tagger script form, merely taking the elements and putting them back
>> together. But that's likely a lot further off than simply works as text
>> strings.
>>
>> As for differing titles as on liners, there was that idea to allow for
>> multiple variations of track titles to be attached to a single release, with
>> variations tied to particular release events - that could work here.
>>
>> Brian
>>
>> _______________________________________________
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>>
>
>
> _______________________________________________
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
