Some criticisms of the Music Ontology by Chris Mungall
Frederick Giasson
This is a blog post (commented by me) by Chris Mungall. I post it there to stat
a discussion using its insightful comments about the ontology.
Chris: thanks for this wonderful blog post.
"Perhaps you may think that many of my points are not applicable to an ontology
like MO which is not intended to have the rigor of a scientific ontology." Yeah
well... you know, like me, that they all applies to the ontology, and it is what
is great with your writing!
However, I would like to specify some things before commenting your blog post.
First of all, as I already said, this is a first the draw of a Music ontology. I
based the current work on the MusicBrainz project (check the "background"
section of the ontology). However, from that starting point, I was hoping to get
comments and suggestions from intelligent people like you to create a real good
music ontology and to detach it from the musicbrainz project. By chance, it is
exactly what I got: insightful comments from really intelligent people.
So the method I use here, is mainly the same as Uldis Bojar used to develop the
SIOC ontology: creating the foundation of something (here a music ontology), and
then enhancing it with comments and suggestions from other people.
Please subscribe to this mailing list so we will be able to discuss your
comments on th ontology and you will be able to give your comments about other
ideas from other people.
Please read that revision proposition email: http://tinyurl.com/sjt5j
Okay, there is the original blog post from Chris: http://tinyurl.com/uft9h
Bellow are my comments about this blog post:
==========
>POOR DEFINITIONS
>
>Looking at the first term which is defined, “Album”, we see what is
>presumably the definition in the comment field:
>
> This is a generic term defining a package of tracks. This applies to
> compact disks, venils, CD singles, EPs, etc.
>
>First of all there’s no excuse for spelling errors in a flagship
>ontology such as this one. “venil” is presumably a vinyl record.
Definitely not. - Fixed -
And this is certainly not the only one, so please tell me if you find any other.
>Like a lot of current scientific ontologies, the definitions here
>conflate use/mention to some extent (eg “running is healthy and has 7
>letters”). The leading “This is a generic term definining” can simply
>be omitted, making the definition clearer.
Agree. I will re-work the definitions (after the new year eve) with the
suggestions you gave me in this blog post.
However, if you have some definitions in mind, please send them here so I can
change them into the spec.
>Most serious of all, it is completely unclear what the entities in
>reality which are denoted by this class. It is not clear whether the
>term denotes the physical entity (CD, vinyl record) or
>
>This is a generic term which is applied to solo artists, groups, and
>also “various artists”.
Right. A proposition has been made by Alex Passent to change the name (as long
as the definition) of this entity to mo:Release to make things clearer. Please
read the email of revision propositions I cited above for more information.
I totally agree that the current incarnation of this entity is somewhat... fuzzy? :)
>INCONSISTENCY BETWEEN TEXT DESCRIPTIONS AND RDFS REPRESENTATION
>
>Type:
>
> A type of Album release (mo:Album). There are several sub-classes of
> this type that explicitly define all of the release types that
> MusicBrainz database currently understands
>
>The comments state that Type is a type of Album release. This is
>incoherent; but in as much as it is understandable, it leads us to
>think that there would be some kind of link between Type and Album in
>the ontology. In fact there is none. And nowhere do we find “release”
>defined.
>
>Naming a class “Type” betrays a characteristic systematic
>methodological error found in many ontologies. In a realist ontology,
>all classes correspond to type (or universals), which are instantiated
>by individuals in the world. Even if the MO is not explicitly realist,
>calling a class Type seems odd. Are the instances/individuals of this
>class themselves Types, making the MO a kind of second order ontology?
>
>Type has many subclasses, such as Remix:
>
> A release (mo:Album) that primarily contains remixed material.
>
>The text definition states Remix is a release (Album), but again,
>there is no link between Remix and Album outside the incomprehensible
>text comments presumably intended for humans
Well it doesn't make any sense, you are right.
So, what about a mo:Release, where mo:EP, mo:Single, etc. are subclasses of
mo:Release.
And naturally we would have to delete the mo:Other class (as you suggested
bellow) so people would only has to use the mo:Release class instead.
However, what I would suggest to people that use this ontology to include Music
data into a triple store that doesn't support type inference is to define an
instance data with both types: mo:Release and mo:EP, etc. That way, if one need
all mo:Release (and not one of the subtype) then he will get them as well.
>Also, if we look the comments for Track (A track on a release
>(mo:Album). The term is not limited to simply music as it could cover
>a spoken word track, an audio book, etc) we would expect some kind of
>link between track and album. In fact no such link is stated.
Well, what you mean by "link between track and album"? Which type of link you
have in mind?
>MIXING EPISTEMOLOGY WITH ONTOLOGY
>
>The ontology commits the cardinal sin of mixing epistemology with
>ontology; it actually contains a class “Other”:
>
>Any release that does not fit or can’t decisively be placed in any
>of the other categories
>
>See
>http://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Recognition
>for this approach taken to the extreme
>
>There is no need for an “other” category. Simply place instances in
>the superclass category and have the application deal with epistemological aspects
Totally right, as I cited above, it will be deleted in the next revision
>POOR REPRESENTATION OF DOMAIN
>
>Remix:
>
> A release (mo:Album) that primarily contains remixed material.
>
>This incoherent definition is at odds with how the term Remix is used
>by domain experts such as DJs and so on. First of all, many remixes
>(sensu music fan) are not released (they may be played live as part of
>a DJ set for example). Secondly, they are typically not albums, but
>rather tracks (or often serial sequences of tracks with fiat
>overlapping boundaries)
Yeah well, you are right here too.
However, the mo:Remix if a mo:Release (in a world where mo:Album is replaced by
mo:Release) that contain remixes.
There are properties, applicable to both mo:Album (for the moment) and mo:Track
that explicit the fact that a track (or album) is a remix of another track (or
album).
In that case, would you suggest to delete this class and to infer it via one of
these mo:remix_of property? (if one track on an album is a remix of another
track, then the album is a mo:Remix)
>Live:
>
> A release (mo:Album) that was recorded live.
>
>This definition is circular, and it’s not clear what this means,
>especially in the context of a lot of current music. Recorded in front
>of a concert audience? Recorded in a continuous segment, without
>remixing etc?
Well, we could certainly define many properties specially for that class. In
that case, do you have any ideas of such properties? And where should we stop
defining them?
Well, this is another question: where to stop the granularity of an ontology?
>The choice of label is also poor. “Live” would be best reserved for
>a quality that can inhere in entities such as a musical recording.
>“Live Album” would be a far better choice of label. Labels are
>extremely important for the human users of an ontology.
I agree. But how to name it if we change mo:Album for mo:Release.
>If this is to be a serious ontology within its domain then the
>maintainers should ensure that domain experts from all across
>the domain have input such that the ontology is not slanted to
>the ontology maintainers favourite portions of the domain
Naturally, and it is for that exact reason why I released that early version of
the ontology and why I suggest to everybody interested in such a project to
subscribe and participate to that mailing list :)
>DOMAIM NOT CLEARLY SPECIFIED
>
>The blurb on the website states:
>
> The Music Ontology is an attempt to link all the information about
> musical Artists, Albums and Tracks together: from MusicBrainz to
> MySpace. The goal is to express all relations between musical
> information to help people finding anything about music and
> musicians. It is based around the use of machine readable
> information provided by any web site or web service on the Web.
>
>In fact the ontology contains Audiobook, “An audiobook is a book read
>by a narrator without music.”, as well as Interview and Spokenword.
>
>Of course, audiobook is close to music album in semantic space. They
>are frequently distributed on similar media, they are audio
>content. But the consequences of expanding the domain in this way are
>not clear. Are the authors and narrators both “Artists”?
Well, why not? It could be arguable I think ;)
>One would expect there to be some kind of representation of style or
>genre in a music ontology. Of course, even a stuffy formalist such as
>myself would advocate letting a thousand flowers bloom here. I’d love
>to see different fans producing different music style ontologies and
>try out various different mapping and alignment ontologies on them -
>this could be a really fun SW app.
>
>What is curious is the MO does not include a single recommendation of
>how style should be captured. One would expect at least an open-ended
>has_genre rdfs property. If the MO purports to link “all information
>about Artists, Albums and Tracks together” or to “help people finding
>anything about music and musicians” then surely style/genre must come
>into this?
Well, please refer to the ontology revision email cited above.
>It would seem that the MO is in fact more of a Music *Business*
>Ontology combined with an Audio *Media* Ontology, as there is very
>little about the domain of “music” as a musician would presumably
>understand the term. I would expect a music ontology to represent
>entities such as pitches, frequencies, instruments, timbres, sequences
>of sounds, keys and so on.
Right, and now is the time to extend it. So, would you have suggestion to do
about these pitches, frequencies, instruments, timbres, sequences, etc?
>INCORRECT USE OF RDFS SEMANTICS
>
>We see a classic mistake in the domains and ranges of remix_of:
>
> <rdf:Property rdf:about=”http://purl.org/ontology/mo/remix_of”
> rdfs:label=”remix_of”>
> <rdf:type rdf:resource=”http://www.w3.org/2002/07/owl#ObjectProperty”/>
> <rdfs:comment>Used to relate the remix of a work in a substantially
> altered version produced by mixing together individual tracks or segments
of an original source work.</rdfs:comment>
> <rdfs:domain rdf:resource=”http://purl.org/ontology/mo/Album”/>
> <rdfs:domain rdf:resource=”http://purl.org/ontology/mo/Track”/>
> <rdfs:range rdf:resource=”http://purl.org/ontology/mo/Album”/>
> <rdfs:range rdf:resource=”http://purl.org/ontology/mo/Track”/>
> <rdfs:isDefinedBy rdf:resource=”http://purl.org/ontology/mo/”/>
> </rdf:Property>
>
>This means that anything which is the domain or range of remix_of is
>*both* an Album and a Track. If these two classes are declared
>disjoint (it is not clear if they should be), then this will be an
>“empty class”
Right, in that case how can we fix that problem? Is the only way is to create
two remix_of properties: one for albums (releases) and another for tracks?
This is an interesting problem that I didn't saw when I wrote this first draw of
the ontology. However, has you can see, many properties has ranges and domains
for more than one class, and clearly, these classes are disjoint.
>
>DOES NOT TAKE TIME INTO ACCOUNT
>
>Like most semantic web resources (ontologies and ontology
>representation languages included), time is not treated seriously.
>
>member_of is a binary relation (which is forced when using rdf/owl
>properties to represent relations). The MO homepage gives as an
>example of use:
>
> <mo:Artist
rdf:about=”http://mm.Music.org/artist/2f58d07c-4ed6-4f29-8b10-95266e16fe1b”>
> <rdfs:label>Dave Mustaine</rdfs:label>
> <mo:member_of
rdf:resource=”http://mm.Music.org/artist/65f4f0c5-ef9e-490c-aee3-909e7ae6b2ab”/>
>
>The URL is enresolvable but from the other examples on the web page
>appears to reference Metallica. In fact, as every heavy metal fan
>knows, Dave Mustaine was one of the original members of Metallica,
>before his legendary falling out and subsequent formation of
>Megadeth. It is not clear how this vital fact is to be represented
>with MO.
Well yeah, we could certainly define new properties to describe such
relationship. It is the time of suggestions I was waiting for :0
In that case, we should certainly define these properties considering what we
talked about in the revision proposition email, re: how we will handle groups
using foaf:Group.
>RECOMMENDATIONS
>
>The developers of MO may like to look at formal ontology to guide
>future development of MO. For example, mereotopology (the study of
>parts and wholes) would be useful for understanding how musical wholes
>can be broken into parts and subparts. The current MO partition of
>musical entities into Tracks and Albums perpetuates an ontological
>division forced onto use by media that are rapidly becoming
>outmoded. Many forms of music, such as classical music and overblown
>70s concept albums with their more recursive part-whole structures
>require a less rigid breakdown.
>
>Formal ontology recognises a distinction between bona-fide and fiat
>bounadaries. A bona-fide boundary is an objective division in reality,
>such as that between a table and sourrounding space, or between two
>tracks separated by silence. A fiat boundary reflects a continuity in
>nature, such as the fiat boundary between my arm and torso.
>
>Soon-to-be-outdated media forces bona-fide musical divisions upon
>us. In fact, with the advent of turntables as a musical instrument in
>the 70s mereological divisions between musical parts in popular music
>has frequently been along fiat boundaries. It is to be expected that
>the internet will do more to dissolve these divisions than perpetuate
>them.
>
>Formal ontology is clear about the different kinds of entities in
>reality. The MO does not seem clear on the difference between actual
>physical instantiations of media or content bearing entities such as
>an actual physical CD and the actual content which is carried by that
>media. This is no problem for everyday linguistic usage; a human
>understands the different sense of “album” in the questions “how many
>albums have franza ferdinand put out” vs “how many albums have franz
>ferdinand sold”. Howevers, computers are less intelligent and cannot
>disambiguate in this way and thus it seems crazy not to make this
>explicit in the ontology.
See the revision ontology email.
>Music, language and living entities share certain essential
>characteristics. It would be interesting to try and share foundational
>relations. For example: bands and musical styles are continuants which
>endure through time, gaining and losing parts as they progress, just
>like a human composed of cells. Much of the work that has been done
>in foundational ontologies in biology (such as RO) could perhaps be
>applied here - eg developmental relations between different musical
>forms, fission and fusion between bands.
>
>The recommendation for more formality in the semantic web may seem
>curious, given that SW practitioners are keen to distance themselves
>from any kind of stuffiness in order to attrack the folksonomy crowd.
>
>In fact both can exist side by side; I want both. I’d like to tag
>musical content and content-producers with ad-hoc tags like “cheesy“,
>“evil“, “lively“, “mutant“, “good music for hangovers” etc. But I’d also like to
>get consistent answers back in searches for musical content across the
>semantic web and the only way to do that would seem to me to be using
>an ontology that is built on better ontological principles
Right
>Perhaps the best place to start would be to solicit some use cases;
>as it stands now it’s not clear exactly what problems the MO wants
>to solve, and which problems it is capable of solving.
Well, some use cases are available in the SPARQL queries section. However, a
live SPARQL endpoint using this ontology and data from musicbrainz data should
be available in January 2007. Then people will be able to test it and send
suggestion according to their tests.
==========
Well, thanks for these insightful comments and observations. It would be really
appreciated if you could continue to suggests things and answer couple of
questions in this email.
Thanks for your time and expertise,
Take care and happy new year,
Salutations,
Fred
glenn
grounding (ideally before you start writing, as I agree with Chris that
what you've got here feels misconceived, not just rough) is the IFLA's
Functional Requirements for Bibliographic Records
(http://www.ifla.org/VII/s13/frbr/frbr.htm). They begin by
distinguishing between the "work" (an abstract intellectual creation,
like a song), the "expression" of that work (e.g. a recording of that
song), the "manifestation" of that expression (e.g. the appearance of a
particular recording of a song on a CD), and the "item" (the CD), and
then go into the kinds of relationships possible between each of these
(and between the people and corporate entities responsible for them). A
practical Music Ontology for non-librarians would presumably want to be
a lot simpler than FRBR, but it might want to be a deliberate
simplification *of* FRBR, or diverge from it only for well-understood
reasons.
And when/if you take another stab at this, I highly recommend trying to
concentrate on enduring semantics rather than transient terminology and
examples. "Composition", "Composer" and "Performer", for example, are
real and integral, and can be defined with some precision and
generalization. "EP", "Bootleg" and "mashup_of" are fairly arbitrary
labels that belong to an entirely different level of description,
defined only approximately by convention, and subject to redefinition
across subgenre/subculture/history/etc. boundaries. And things like
"linkto_myspace" and "linkto_olga" should almost certainly be instances
of a general "reference" relationship, rather than appearing in the
base ontology at all...
Frederick Giasson
Frederick Giasson
Sorry about this "duplicated" email, but I just noticed that the answer I wrote
haven't been sent and that only an empty reply has been sent
So there we are:
> If you're serious about this, another good thing to study for
> grounding (ideally before you start writing, as I agree with Chris that
> what you've got here feels misconceived, not just rough) is the IFLA's
> Functional Requirements for Bibliographic Records
> (http://www.ifla.org/VII/s13/frbr/frbr.htm). They begin by
> distinguishing between the "work" (an abstract intellectual creation,
> like a song), the "expression" of that work (e.g. a recording of that
> song), the "manifestation" of that expression (e.g. the appearance of a
> particular recording of a song on a CD), and the "item" (the CD), and
> then go into the kinds of relationships possible between each of these
> (and between the people and corporate entities responsible for them). A
> practical Music Ontology for non-librarians would presumably want to be
> a lot simpler than FRBR, but it might want to be a deliberate
> simplification *of* FRBR, or diverge from it only for well-understood
> reasons.
Definitely a great work, I will read it carefully.
> And when/if you take another stab at this, I highly recommend trying to
Sure I will. This is just the start of the ontology, not the end ;)
> concentrate on enduring semantics rather than transient terminology and
> examples. "Composition", "Composer" and "Performer", for example, are
> real and integral, and can be defined with some precision and
> generalization. "EP", "Bootleg" and "mashup_of" are fairly arbitrary
> labels that belong to an entirely different level of description,
> defined only approximately by convention, and subject to redefinition
> across subgenre/subculture/history/etc. boundaries. And things like
I agree with you, but as I said, the primary goal was to catch up with the
MusicBrainz project. However, what if one want to define an approximate
convention such as mashup, booleg, ep, etc? Where to put the boundary of th
music ontology? What to define and what not to define? This is an important
question of granularity.
However, I come back to my first question: what i one want to define an
"flexible convention"? I agree that an ontology, ultimately, should only model
concepts that are "crystallized" in every people's mind. However, in the real
world people will want to define things (resources) using "non-crystallized" new
terms, hype words, etc. with undefined boundaries and fuzz conventions.
So, what to do?
> "linkto_myspace" and "linkto_olga" should almost certainly be instances
> of a general "reference" relationship, rather than appearing in the
> base ontology at all...
Yeah, please read the revision ontology proposition on this mailling-list.
Take care and an happy new year!
Salutuations,
Fred