I agree with everything Brian said below, and add:
With great flexibility/extensibility usually comes great end-user
complexity. While we might be able to establish a flexible
architecture/data model, we should at least be cognisant of various
common usage profiles (e.g. popular, traditional classical, modern
classical, jazz standards) and ensure they can be accommodated without
requiring editors to jump though difficult hoops and perform
data-expression-contortions to get what we want in the end.
-----Original Message-----
From: Brian Schweitzer <brian.brianschweit...@gmail.com>
Reply-to: MusicBrainz style discussion
<musicbrainz-style@lists.musicbrainz.org>
To: adamgold...@adamgolding.com, MusicBrainz style discussion
<musicbrainz-style@lists.musicbrainz.org>
Subject: Re: [mb-style] The return of [clean up CSG]??? (was: Re: CSG
issues (was: 'Piano Sonata / Concerto' vs. 'Sonata / Concerto for
Piano))
Date: Wed, 7 Jan 2009 02:32:43 -0500
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
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
