Taxonomy is used typically in the field of classification. If you're
merely trying to classify the components that make up a work, in a
hierarchical structure, I'm cool with it. If it's meant to describe
domains and relationships between entities, I'm more inclined to stick
with the word ontology.
-----Original Message-----
From: Frederic Da Vitoria <davito...@gmail.com>
Reply-to: MusicBrainz style discussion
<musicbrainz-style@lists.musicbrainz.org>
To: 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 10:06:52 +0100
No, "taxonomy" is better, I think.
2009/1/7 Frederic Da Vitoria <davito...@gmail.com>
BTW, wouldn't "cladism" be more appropriate than "ontology"?
2009/1/7 Frederic Da Vitoria <davito...@gmail.com>
I prefer Dave's and Adam's position. I once tried to
design something closer to my way of thinking:
http://wiki.musicbrainz.org/ClassicalFuture Sorry, the
schema is not clear at all, but in this schema a work is
generic and recursive (through "is part of"). I am not
sure I still agree with all the details of this schema,
though, and it certainly would need amending. I
understand that this flexibility has a cost in terms of
complexity, but
1 - ARs have a similar flexibility / complexity and ARs
are clearly one of the greatest ideas incorporated in MB
2 - flexibility at the database level is not necessarily
thrown into the face of the end-user, the user-interface
may "rigidify" this flexibility so that the end user
sees a well-delimited system.
3 - if Dave's and Adam's and my type of design are
flexible enough, Brian's ontology should fit into it so
that the end user would see an interface on Brian's
ontology. But if / when we need another ontology, we
won't have any database modifications to implement.
2009/1/7 Paul C. Bryan <em...@pbryan.net>
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.
--
Frederic Da Vitoria
Membre de l'April - « promouvoir et défendre le logiciel libre »
- http://www.april.org
--
Frederic Da Vitoria
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
_______________________________________________
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
