Music Ontology revision 1.10: introduction of musical performances as events in time
Frederick Giasson
I am pleased to publish the revision 1.10 of the Music Ontology. As
you can see in the change log [1]
many things changed in that revision of the ontology. In fact, all
the ambiguities people noticed with the latest revisions should now
be fixed. Yves Raimond worked hard to implement the Time Ontology
along with its Event and Timeline Ontologies into the Music Ontology.
The result is a major step ahead for the Music Ontology. Now
different levels of expressiveness are available trough the ontology.
In fact, one can describe simple things like MusicBrainZ data and
relations, or they can describe the recording of a gig on a cell
phone, published on the web, by two different people. Take a look at
the updated examples to see what each of these three levels of
expressiveness can describe.
As you can see, all the examples are now expressed in N3 and XML.
These examples are classified in three different levels of
descriptiveness. Most people will describe musical things using the
first level of expressiveness, however closed and specialized systems
will be able to express everything they want related to music using
the Musical Ontology (check examples level 2 and 3 for good examples
of this new expressiveness power)
One of the last things we have to fix is how genres should be
handled. Right now we are typing individuals with its genre. However
considering that genres evolve and change really quickly and that
they are strongly influenced by cultures, a suggestion has been made
to create individuals out of the class Genre and then describing
them. Also, we could create s mo:subGenre property (domain: mo:Genre;
range: mo:Genre) that would relate a genre to its sub-genre(s).
This idea is really great and would probably be the best way to
describe genres considering their “volatile” meaning over time.
However the question is: how to link a mo:MusicalWork,
mo:MusicalExpression, mo:MusicalManifestation and mo:Sound to its
genre? If we create a mo:genre (domain mo:MusicalWork... etc; range
rdf:resource), then people could use that property to link a
MusicalWork, etc. to anything (anything that is a resource).
Personally I think that it is not necessarily a good thing to
introduce such a non-restricted property into the ontology.
Note that it is not the same thing as the property event:hasFactor
since anything can be a factor of a musical event.
Now that the ontology is becoming pretty stable, the next step is
starting to use it to describe things related to music. The first
step will be to convert MusicBrainZ’s data into RDF using the Music
Ontology. Soon enough I should make available a RDF dump of this data
along with a Virtuoso PL that will enable people to re-create this
RDF dump from a linked instance of a MusicBrainZ Postgre database
into Virtuoso
Finally I would like to give a special thanks to Yves for its hard
work and involvement for the publication of that new revision of the
Music Ontology.
http://pingthesemanticweb.com/ontology/mo/#sec-changes
Take care,
Fred
Alexandre Passant
On 2/26/07, Frederick Giasson <fr...@fgiasson.com> wrote:
>
>
> One of the last things we have to fix is how genres should be
> handled. Right now we are typing individuals with its genre. However
> considering that genres evolve and change really quickly and that
> they are strongly influenced by cultures, a suggestion has been made
> to create individuals out of the class Genre and then describing
> them. Also, we could create s mo:subGenre property (domain: mo:Genre;
> range: mo:Genre) that would relate a genre to its sub-genre(s).
>
> This idea is really great and would probably be the best way to
> describe genres considering their “volatile” meaning over time.
> However the question is: how to link a mo:MusicalWork,
> mo:MusicalExpression, mo:MusicalManifestation and mo:Sound to its
> genre? If we create a mo:genre (domain mo:MusicalWork... etc; range
> rdf:resource), then people could use that property to link a
> MusicalWork, etc. to anything (anything that is a resource).
> Personally I think that it is not necessarily a good thing to
> introduce such a non-restricted property into the ontology.
It seems at the moment genres (Rock, Blues ...) are subclass of the
mo:Genre, and not instances.
Yet, it sounds more natural IMHO to create instances, unless you want
to create instances of the Rock style, etc.
Yet, it doesn't solve the problem of subclassing / relating genres.
So what about creating a "genre" taxonomy with SKOS ?
Maybe wikipedia defined genres [1], [2] can be scrapped and converted
to such a taxonomy, also using relations between narrower genres.
Another idea would be simply to use blank nodes for genres and linking
them to their wikipedia homepage with mo:wikipedia ? Or even to the
corresponding dbpedia resource, so that we can have links to related
genres / artists - or considering genres as dbpedia resources
associated to wikipedia genre pages ?.
As, as you mentionned, creating a complete list of genres will be a
certainly huge and evolving work, so the wikipedia / dbpedia approach
could be a best practice to use within the ontology.
Maybe some work is to be done with dbpedia here.
Best,
Alex.
[1] http://en.wikipedia.org/wiki/Category:Music_genres
[2] http://en.wikipedia.org/wiki/List_of_genres_of_music:_A-F
Yves Raimond
> It seems at the moment genres (Rock, Blues ...) are subclass of the
> mo:Genre, and not instances.
Yes, it is a bit "work-in-progress" so far, so everything is unstable.
I guess what we intended to do here was to create a really simple
taxonomy, and let the user create its own genre resource, instance of
"Punk" and "Funk", or something like that... But, yes, it is almost
sure that we won't succeed to create an efficient enough taxonomy that
everybody agrees on, so we need to find a way to keep the "cultural"
aspect of such concepts.
> Yet, it doesn't solve the problem of subclassing / relating genres.
> So what about creating a "genre" taxonomy with SKOS ?
I quite like this idea!! I think it could give enough
flexibility/expressiveness for dealing with this concept. We could
create start-points in MO (rock, jazz, ...), and let users build on
top of it, by creating new genres, and relate genres together using
SKOS properties.
> Another idea would be simply to use blank nodes for genres and linking
> them to their wikipedia homepage with mo:wikipedia ? Or even to the
> corresponding dbpedia resource, so that we can have links to related
> genres / artists - or considering genres as dbpedia resources
> associated to wikipedia genre pages ?.
I really don't know what sort of information is available in dbpedia:
what information did they succeed to capture? If it can give access to
everything: subgenres, stylistic/cultural origins, mainstream
popularity, derative forms... it may be more than enough! in this
case, mo:genre could just point to such dbpedia resources. And I think
wikipedia is modeling quite well the cultural aspect by itself :-) I
ll take a look at it!
Regards,
Yves
florent
Lurker from the beginning, I was always thinking at this problem of genre information but now the point is raised, i will stop lurking and start talking (temporarily ?)
Hi all!
> It seems at the moment genres (Rock, Blues ...) are subclass of the
> mo:Genre, and not instances.
Yes, it is a bit "work-in-progress" so far, so everything is unstable.
I guess what we intended to do here was to create a really simple
taxonomy, and let the user create its own genre resource, instance of
"Punk" and "Funk", or something like that... But, yes, it is almost
sure that we won't succeed to create an efficient enough taxonomy that
everybody agrees on, so we need to find a way to keep the "cultural"
aspect of such concepts.
From what I seen on the net, it seems that this genre definition seems to be a place were folksonomy shaw their potential and it could be a possibility to think about it.
I wonder if useful information could for exemple be extracted from a site like lastfm (they use mbId for their music saw it should be possible somehow, but would it be usefull ?)
I remember having looked a while ago if they gave "tags proximity information by tags" and it's not the case, and the extraction should be recalculated from artists and tracks tags (which looks painfull) but they promise from the beginning to release dataset... (By the way, I'm still not sure how this can be usefull with the quantity of what I'd call "junk tags" like "seen live" and others...this is folksonnomy...)
> Yet, it doesn't solve the problem of subclassing / relating genres.
> So what about creating a "genre" taxonomy with SKOS ?
I quite like this idea!! I think it could give enough
flexibility/expressiveness for dealing with this concept. We could
create start-points in MO (rock, jazz, ...), and let users build on
top of it, by creating new genres, and relate genres together using
SKOS properties.
I really think this is the kind of information SKOS is well suited to deal with.
> Another idea would be simply to use blank nodes for genres and linking
> them to their wikipedia homepage with mo:wikipedia ? Or even to the
> corresponding dbpedia resource, so that we can have links to related
> genres / artists - or considering genres as dbpedia resources
> associated to wikipedia genre pages ?.
I really don't know what sort of information is available in dbpedia:
what information did they succeed to capture? If it can give access to
everything: subgenres, stylistic/cultural origins, mainstream
popularity, derative forms... it may be more than enough! in this
case, mo:genre could just point to such dbpedia resources. And I think
wikipedia is modeling quite well the cultural aspect by itself :-) I
ll take a look at it!
It seems that at least part of theses pages have been extracted in dbpedia, as seen there :
http://dbpedia.org/page/category/Musical_subgenres_by_genre
and
http://dbpedia.org/page/category/World_music_by_region
this look like a very good starting point for a SKOS "genre taxonomy" but I couldn't find the eqivalent of the genre-list page from wikipedia...
regards,
Florent
Ivan
On Feb 27, 4:41 pm, "Yves Raimond" <yves.raim...@gmail.com> wrote:
> I quite like this idea!! I think it could give enough
> flexibility/expressiveness for dealing with this concept. We could
> create start-points in MO (rock, jazz, ...), and let users build on
> top of it, by creating new genres, and relate genres together using
> SKOS properties.
>
Me too. Actually, I wonder whether we should not do the same with the
instruments. I have played with an example just now (I will post what
I did in a few minutes) and the instruments really need more work. I
wonder whether there is a taxonomy somewhere on instruments that we
could convert into a SKOS taxonomy and take it from there...
Ivan
>
> Regards,
> Yves
Yves Raimond
> It seems that at least part of theses pages have been extracted in dbpedia,
> as seen there :
>
> http://dbpedia.org/page/category/Musical_subgenres_by_genre
> and
> http://dbpedia.org/page/category/World_music_by_region
>
> this look like a very good starting point for a SKOS "genre taxonomy" but I
> couldn't find the eqivalent of the genre-list page from wikipedia...
Mmmm... It seems that they just extract the "category" information,
which they model using skos:broader. I think that we should definitely
try to get access to the related infobox information (see [1]). So
maybe, first, we should try to create some properties related to what
can be expressed in these boxes, and then dump their content using
this vocabulary?
Regards,
Yves
Ivan
by now you probably realized that I work with examples.... Actually, I
did some examples in the previous round of discussion you had with
Yves but, for some reasons, my posting did not make it to the list. Oh
well...
Anyway, I have done an encoding of one of my CD-s to see how it works
out. I have put some comments below. I may have made some mistakes,
please check! Overall
- describing a composition seems to be quite o.k. I must admit that
the separation of 'Composition' and 'MusicalWork' is a little bit odd
at first, but one can get used to it
- I had much more difficulties to describe the CD itself. Somehow it
smells a bit too complex, and I wonder whether there is a possibility
to simplify it. The chain/usage of Performance, Sound, Signal, Record
seems a bit of an overkill for me, you or Yves still have to convince
me that this is really necessary. I also had small expression
problems, see the comments
- Actually, just for user-friendliness, I wonder whether it would be
possible to rename some of the properties. Outsiders will have a real
hard time using properties like 'hasFactor', 'hasProduct', 'hasAgent',
etc. It is not really intuitive for the everyday person who just want
to store his/her CD references...
Here is what I did:
@prefix mo: <http://purl.org/ontology/mo/>.
@prefix keys: <http://purl.org/NET/c4dm/keys.owl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix time: <http://purl.org/NET/c4dm/time.owl#>.
@prefix event: <http://purl.org/NET/c4dm/event.owl#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
:pianoconcertoNo2Comp a mo:Composition;
event:hasAgent [
a foaf:Person;
mo:wikipedia <http://en.wikipedia.org/wiki/Rachmaninov>;
a mo:MusicArtist;
foaf:name "Sergei Rachmaninoff".
];
event:hasProduct :pianoconcertoNo2;
# If I wanted to find a place to record the time of the composition
# it could/would go here. But I am not really interested by it now..
.
:pianoconcertoNo2 a mo:MusicalWork;
mo:composer :rachmaninoff;
dc:title "2nd Piano Concerto";
mo:opus "Op. 18";
mo:key keys:CMinor;
mo:title "Piano Concerto no. 2";
mo:wikipedia <http://en.wikipedia.org/wiki/Piano_Concerto_No._2_
%28Rachmaninoff%29>;
mo:has_movement [
a mo:Movement; # this is redundant with and RDFS reasoner; it is
inferred from the range spec.
mo:movementNum "1"^^xsd:integer;
mo:tempo "Moderato".
];
mo:has_movement [
a mo:Movement;
mo:movementNum "2"^^xsd:integer;
mo:tempo "Adagio sostenuto".
];
mo:has_movement [
a mo:Movement;
mo:movementNum "3"^^xsd:integer;
mo:tempo "Allegro scherzando".
];
.
#######################################################
:gavrilovPerf a mo:Performance;
event:hasFactor :pianoconcertoNo2.
event:hasAgent [
# Hm. The document also has mo:performer. What is the difference
# between these two? Is mo:performer a subproperty of hasAgent???
a foaf:Group;
foaf:member [
foaf:name "Andrei Gavrilov";
# we need then a type for 'Performer'
mo:instrument [ # This property seems to have disappeared!!!!
a mo:Keyboard;
# Keyboard is really not fine enough. Either we build up a full
taxonomy of instruments
# (that might exist somewhere!), or we use the title below
rdfs:label "piano";
]
];
foaf:member [
foaf:name "Ricardo Muti"
# I need something here to say 'conductor', how do I do that?
];
foaf:member [
foaf:name "The Philadelphia Orchestra";
mo:instrument [
a mo:Orchestra; #???? This does not exist!
]
].
];
event:hasFactor :pianoconcertoNo2;
event:hasProduct :thePerformance;
.
:thePerformance a mo:Sound.
:theRecord a mo:Recording;
event:hasFactor :thePerformance;
event:hasProduct [
a mo:Signal;
mo:publishedAs [
# that is, if I understand it well, the set of all CD-s for
a mo:Record;
mo:releaseStatus mo:official.
]
]
.
Cheers,
Ivan
Yves Raimond
> - describing a composition seems to be quite o.k. I must admit that
> the separation of 'Composition' and 'MusicalWork' is a little bit odd
> at first, but one can get used to it
Yes - composition is the actual event, where the composition occurred.
If successful ( :-D ), such an event might create a MusicalWork (which
is the abstract work itself,as in FRBR).
> - I had much more difficulties to describe the CD itself. Somehow it
> smells a bit too complex, and I wonder whether there is a possibility
> to simplify it. The chain/usage of Performance, Sound, Signal, Record
> seems a bit of an overkill for me, you or Yves still have to convince
> me that this is really necessary. I also had small expression
> problems, see the comments
I will comment it below. The thing is that there is a minimum
complexity we cannot avoid. And it is better to put this complexity on
things that we *know* that actually exists (performances,
recordings...) instead of things that are arguable (like: what is
MusicalExpression, and what properties should be linked to such
things? which is the sort of question everyone will come up with a
different answer -- and that's normal, due to its vague definition).
But by sticking to the first level of expressiveness, it is a lot
simpler than before:-) So yes, you gain simplicity on one point,
complexity on the other, but at least this complexity is linked to
more concrete things that are a bit less arguable and subject to
change. And I think your example is a perfect proof-of-concept for
this - as I will detail in my comments.
> - Actually, just for user-friendliness, I wonder whether it would be
> possible to rename some of the properties. Outsiders will have a real
> hard time using properties like 'hasFactor', 'hasProduct', 'hasAgent',
> etc. It is not really intuitive for the everyday person who just want
> to store his/her CD references...
Yes - but I think most of the people will just use
MusicalManifestation for this (and maybe Signal, which corresponds to
"Tracks" in MusicBrainz -- a Track in MO is "a track on a particular
record"). It is true that for classical music it is a bit more
complex, and I think the right way to do it is indeed as you did:
>
> @prefix mo: <http://purl.org/ontology/mo/>.
> @prefix keys: <http://purl.org/NET/c4dm/keys.owl#>.
> @prefix foaf: <http://xmlns.com/foaf/0.1/>.
> @prefix time: <http://purl.org/NET/c4dm/time.owl#>.
> @prefix event: <http://purl.org/NET/c4dm/event.owl#>.
> @prefix dc: <http://purl.org/dc/elements/1.1/>.
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
>
>
> :pianoconcertoNo2Comp a mo:Composition;
> event:hasAgent [
> a foaf:Person;
> mo:wikipedia <http://en.wikipedia.org/wiki/Rachmaninov>;
> a mo:MusicArtist;
> foaf:name "Sergei Rachmaninoff".
> ];
> event:hasProduct :pianoconcertoNo2;
> # If I wanted to find a place to record the time of the composition
> # it could/would go here. But I am not really interested by it now..
> .
Yes - exactly, you may even put the place where Rachmaninoff was at this time.
>
> :pianoconcertoNo2 a mo:MusicalWork;
> mo:composer :rachmaninoff;
> dc:title "2nd Piano Concerto";
> mo:opus "Op. 18";
> mo:key keys:CMinor;
> mo:title "Piano Concerto no. 2";
> mo:wikipedia <http://en.wikipedia.org/wiki/Piano_Concerto_No._2_
> %28Rachmaninoff%29>;
> mo:has_movement [
> a mo:Movement; # this is redundant with and RDFS reasoner; it is
> inferred from the range spec.
True, a Movement is a subclass of a Work.
> mo:movementNum "1"^^xsd:integer;
> mo:tempo "Moderato".
> ];
> mo:has_movement [
> a mo:Movement;
> mo:movementNum "2"^^xsd:integer;
> mo:tempo "Adagio sostenuto".
> ];
> mo:has_movement [
> a mo:Movement;
> mo:movementNum "3"^^xsd:integer;
> mo:tempo "Allegro scherzando".
> ];
> .
>
> #######################################################
>
> :gavrilovPerf a mo:Performance;
> event:hasFactor :pianoconcertoNo2.
> event:hasAgent [
> # Hm. The document also has mo:performer. What is the difference
> # between these two? Is mo:performer a subproperty of hasAgent???
Yes, indeed. mo:performer is a subclass of agents. It is just used
here to identify a particular role (well, performing:-) )
> a foaf:Group;
> foaf:member [
> foaf:name "Andrei Gavrilov";
> # we need then a type for 'Performer'
See the section "DL candies" in the ontology: Performer is considered
as a defined class, each agents performing in a a Performance are,
well, Performers. But you can also directly assert "a mo:Performer"
here.
> mo:instrument [ # This property seems to have disappeared!!!!
Here, I think we should use hasFactor on the Performance, or we may
create a subproperty mo:instrument of event:hasFactor, which might be
clearer. Because Andrei Gavrilov may play organ in an other
performance? I think the Nirvana example on the MO page shows such
example. Or do you want to express "this person is usually playing
Keyboard" here?
> a mo:Keyboard;
> # Keyboard is really not fine enough. Either we build up a full
> taxonomy of instruments
> # (that might exist somewhere!), or we use the title below
Agreed - I guess we could dump a taxonomy of instrument, from
wikipedia or somewhere. I am investigating if there is already
something available for this.
> rdfs:label "piano";
> ]
> ];
> foaf:member [
> foaf:name "Ricardo Muti"
> # I need something here to say 'conductor', how do I do that?
You may use "a mo:Conductor".
But yes, I guess you are doing things in such a way that it is
extra-verbose. Subproperties of "hasAgent" identify roles, which is
exactly what you are trying to do here. So you could just do:
perf mo:performer [
.....
Andrei Gavrilov
....
]
perf mo:conductor [
.....
"Ricardo Muti"
....
]
and so on. I think there is no need for a group here - and you save
some statements by doing it this way (and it is also easier to query).
> ];
> foaf:member [
> foaf:name "The Philadelphia Orchestra";
> mo:instrument [
> a mo:Orchestra; #???? This does not exist!
> ]
I don't understand what you are trying to express here. Ricardo Muti
is part of the philadelphia orchestra? then use foaf:member, like
here. And maybe we can create a subclass of MusicalGroup: Orchestra.
But using something like mo:instrument here seems a bit weird.
> ].
> ];
> event:hasFactor :pianoconcertoNo2;
> event:hasProduct :thePerformance;
> .
Well, the performance produces a Sound, directly.
So:
event:hasProduct :sound
> :theRecord a mo:Recording;
> event:hasFactor :thePerformance;
so here event:hasFactor :sound
> event:hasProduct [
> a mo:Signal;
> mo:publishedAs [
> # that is, if I understand it well, the set of all CD-s for
> a mo:Record;
> mo:releaseStatus mo:official.
> ]
> ]
> .
>
Yes, this is right. The recording produces a signal, which can be
published into a MusicalManifestation.
So yes, the code would look like this:
@prefix mo: <http://purl.org/ontology/mo/>.
@prefix keys: <http://purl.org/NET/c4dm/keys.owl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix time: <http://purl.org/NET/c4dm/time.owl#>.
@prefix event: <http://purl.org/NET/c4dm/event.owl#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
:pianoconcertoNo2Comp a mo:Composition;
event:hasAgent [
a foaf:Person;
mo:wikipedia <http://en.wikipedia.org/wiki/Rachmaninov>;
a mo:MusicArtist;
foaf:name "Sergei Rachmaninoff".
];
event:hasProduct :pianoconcertoNo2;
.
#######################################################
mo:performer [
foaf:name "Andrei Gavrilov";
];
#Well, for mo:instrument, refer to my previous comment, I dont know
what you want to express here. the simplest thing is to add: hasFactor
[rdfs:label "keyboard"]
mo:conductor [
foaf:name "Ricardo Muti"
];
foaf:member [
foaf:name "The Philadelphia Orchestra";
a mo:Orchestra
].
];
event:hasFactor :pianoconcertoNo2;
event:hasProduct :theSound;
.
# you can add place/date of the performance here
:theRecord a mo:Recording;
event:hasFactor :theSound;
event:hasProduct [
a mo:Signal;
mo:publishedAs [
a mo:Record;
mo:releaseStatus mo:official.
]
]
.
# You can add the type of microphone being used here, for example
Well, that's how I'd do it. What do you think about it? A similar
example I wrote is the one about the kunst der fuge on the MO page.
Btw, I was thinking that perhaps we should set up an IRC channel for
"live" discussion, as we had lots of chats with Frederick recently on
freenode?
Regards,
Yves
florent
hi
Here is the "instrument taxonomy" currently used by musicbrainz
and here is the "next one" http://wiki.musicbrainz.org/AdvancedInstrumentTree
(it's only simples trees)
which link to several things (didn't have the time to watch deeply) and maybe some of theses info are already in dbpedia
Florent
Yves Raimond
>
> Here is the "instrument taxonomy" currently used by musicbrainz
> http://wiki.musicbrainz.org/InstrumentRelationshipAttribute
> and here is the "next one"
> http://wiki.musicbrainz.org/AdvancedInstrumentTree
I really like this one! I guess it is ok to have simple trees for such
classification, but I may be wrong.
The thing that annoys me a bit is that: do we consider that the
instances themselves refer to the concept of the instrument? In this
case, it is impossible to refer to "this particular piano" for
example.
Or we could just use a simple rdfs class hierarchy, dumped from the
musicbrainz tree or the wikipedia classification, and use [a mo:Piano]
to refer to "a particular piano". Then, if we want, we can attach some
more properties to this particular piano (this is the one that was
"tuned" by John Cage).
Quick summary - should we be able to do:
:perf mo:instrument mo:piano.
or:
:perf mo:instrument [
a mo:Piano;
].
?
Regards,
Yves
Frederick Giasson
Great, seems that everybody agree on that point, so we should revise
the ontology in that way.
Salutations,
Fred
Frederick Giasson
> I will comment it below. The thing is that there is a minimum
> complexity we cannot avoid. And it is better to put this complexity
on
> things that we *know* that actually exists (performances,
> recordings...) instead of things that are arguable (like: what is
> MusicalExpression, and what properties should be linked to such
> things? which is the sort of question everyone will come up with a
> different answer -- and that's normal, due to its vague definition).
> But by sticking to the first level of expressiveness, it is a lot
> simpler than before:-) So yes, you gain simplicity on one point,
> complexity on the other, but at least this complexity is linked to
> more concrete things that are a bit less arguable and subject to
> change. And I think your example is a perfect proof-of-concept for
> this - as I will detail in my comments.
Agree with Yves here, but we should make sure that the level 1 of
expressiveness is intuitive to use (like FOAF for example).
> > - Actually, just for user-friendliness, I wonder whether it would
be
> > possible to rename some of the properties. Outsiders will have a
real
> > hard time using properties like 'hasFactor', 'hasProduct', '
hasAgent',
> > etc. It is not really intuitive for the everyday person who just
want
> > to store his/her CD references...
>
> Yes - but I think most of the people will just use
> MusicalManifestation for this (and maybe Signal, which corresponds
to
> "Tracks" in MusicBrainz -- a Track in MO is "a track on a particular
> record"). It is true that for classical music it is a bit more
> complex, and I think the right way to do it is indeed as you did:
Agree with Ivan here, it would be possible to change/add new
properties only to make sure that the level 1 of expressiveness is as
intuitive as possible.
In fact, would it makes sense to add (duplicate) higher order
propertie to make them more intuitive to use? (example to come bellow)
> > mo:instrument [ # This property seems to
have
> disappeared!!!!
>
> Here, I think we should use hasFactor on the Performance, or we may
> create a subproperty mo:instrument of event:hasFactor, which might
be
> clearer. Because Andrei Gavrilov may play organ in an other
> performance? I think the Nirvana example on the MO page shows such
> example. Or do you want to express "this person is usually playing
> Keyboard" here?
It is where I think that re-introducing mo:instrument could help to
use the ontology (at least at the first level).
Why not reintroducing mo:instrument? It is sure that it would be much
more intuitive than event:hasFactor, and event:hasFactor would remain
in the ontology to give the expressiveness for the level 2 and 3.
We could probably do the same thing for other basic (intuitive)
properties.
> @prefix mo: <http://purl.org/ontology/mo/>.
> @prefix keys: <http://purl.org/NET/c4dm/keys.owl#>.
> @prefix foaf: <http://xmlns.com/foaf/0.1/>.
> @prefix time: <http://purl.org/NET/c4dm/time.owl#>.
> @prefix event: <http://purl.org/NET/c4dm/event.owl#>.
> @prefix dc: <http://purl.org/dc/elements/1.1/>.
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
>
>
> :pianoconcertoNo2Comp a mo:Composition;
> event:hasAgent [
> a foaf:Person;
> mo:wikipedia <http://en.wikipedia.org/wiki/
Rachmaninov>;
Ivan, do you agree with that revised example? If so, I will add it to
the list.
Take care,
Fred
Ivan
It seems that we are pretty much in agreement on the composition/
musical work aspect of my example, so I will remove that part from the
mail (just for clarity). I have only one pending problem on that one
which has nothing to do with the exact class structure, and that is
the value space of 'mo:opus'. At the moment, it is a literal, but that
would make it pretty much unusable for reliable sparql query (is it
'op.18', 'Opus 18', 'Op. 18', etc...). Maybe something like
mo:opus [
mo:denominator 'Op'; # for Mozart, it would be 'K', for Bach, it
would be 'BWV', etc
mo:number "18"^^xsd:integer;
mo:modifier "posthumus". # This is only an example, most of time
this value is not used
].
Let us put this on our 'some day pile'
On Feb 27, 6:17 pm, "Yves Raimond" <yves.raim...@gmail.com> wrote:
> Hi Ivan!
>
[snip]
>
> > #######################################################
>
> > :gavrilovPerf a mo:Performance;
> > event:hasFactor :pianoconcertoNo2.
> > event:hasAgent [
> > # Hm. The document also has mo:performer. What is the difference
> > # between these two? Is mo:performer a subproperty of hasAgent???
>
> Yes, indeed. mo:performer is a subclass of agents. It is just used
> here to identify a particular role (well, performing:-) )
you are talking about 'Performer' as being a subclass of Agent. Right,
that is in the RDF/XML. And, indeed, mo:performer is a subproperty of
hasAgent. This is then all right, except that this relationship does
not appear in the HTML version of the text
http://pingthesemanticweb.com/ontology/mo/#term_performer
this is clearly an editorial issue, but to be settled:-)
>
> > a foaf:Group;
> > foaf:member [
> > foaf:name "Andrei Gavrilov";
> > # we need then a type for 'Performer'
>
> See the section "DL candies" in the ontology: Performer is considered
> as a defined class, each agents performing in a a Performance are,
> well, Performers. But you can also directly assert "a mo:Performer"
> here.
And, oops, I missed that class indeed! My bad.
>
> > mo:instrument [ # This property seems to have disappeared!!!!
>
> Here, I think we should use hasFactor on the Performance, or we may
> create a subproperty mo:instrument of event:hasFactor, which might be
> clearer.
We should indeed (I had this remark in general; the naming of these
properties *is* important for general acceptance!)
> Because Andrei Gavrilov may play organ in an other
> performance? I think the Nirvana example on the MO page shows such
> example. Or do you want to express "this person is usually playing
> Keyboard" here?
ah, o.k. There is indeed an example in the Nirvana stuff. What I would
then have
event:hasFactor mo:piano; # provided we have the taxonoy for our
instruments
or, if we do have the mo:instrument then
mo:instrument mo:piano.
B.t.w.: yes, indeed, the same person can play different instruments
depending on the performance, much like the Nirvana example. That is
*always* denoted on the data for a CD.
[snip]
(got your point about the unnecessary usage of a group)
>
> > foaf:member [
> > foaf:name "The Philadelphia Orchestra";
> > mo:instrument [
> > a mo:Orchestra; #???? This does not exist!
> > ]
>
> I don't understand what you are trying to express here. Ricardo Muti
> is part of the philadelphia orchestra? then use foaf:member, like
> here. And maybe we can create a subclass of MusicalGroup: Orchestra.
> But using something like mo:instrument here seems a bit weird.
Yep, it is weird. However, in many ways, an orchestra very often is
considered as a virtual instrument. And no, Ricardo Muti is *not*
member of the orchestra, it conducts it. And conducting an orchestra
is much like playing a music instrument...
Usually, on the data for a performance, one has the orchestra as a
separate entity listed, and the conductor as a separate entity again.
In some cases (for small chamber orchestra) the list of the persons in
an orchestra is also listed, although rarely. But, in this case, an
orchestra really behaves like a foaf:Group.
I guess, in fact, what we have here is a musical group just like you
use the in the kunst der fuge example for the emerson quartett.
[We may need a separate taxonomy for those, in fact, just like for the
instruments. We do have orchestra, quartett, quintett, trio, chamber
orchestra; all these exist as a group, with a well distinguished
name...]
>
> So yes, the code would look like this:
I changed the part on the preformance a bit
@prefix mo: <http://purl.org/ontology/mo/>.
@prefix keys: <http://purl.org/NET/c4dm/keys.owl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix time: <http://purl.org/NET/c4dm/time.owl#>.
@prefix event: <http://purl.org/NET/c4dm/event.owl#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
:pianoconcertoNo2Comp a mo:Composition;
event:hasAgent [
a foaf:Person;
mo:wikipedia <http://en.wikipedia.org/wiki/
Rachmaninov>;
a mo:MusicArtist;
foaf:name "Sergei Rachmaninoff".
];
event:hasProduct :pianoconcertoNo2;
.
:pianoconcertoNo2 a mo:MusicalWork;
mo:composer :rachmaninoff;
dc:title "2nd Piano Concerto";
mo:opus "Op. 18"; # see my remark above, this may have
to be refined
mo:key keys:CMinor;
mo:title "Piano Concerto no. 2";
mo:wikipedia <http://en.wikipedia.org/wiki/
Piano_Concerto_No._2_
%28Rachmaninoff%29>;
mo:has_movement [
mo:movementNum "1"^^xsd:integer;
mo:tempo "Moderato".
];
mo:has_movement [
mo:movementNum "2"^^xsd:integer;
mo:tempo "Adagio sostenuto".
];
mo:has_movement [
mo:movementNum "3"^^xsd:integer;
mo:tempo "Allegro scherzando".
];
.
#######################################################
:gavrilovPerf a mo:Performance;
event:hasFactor :pianoconcertoNo2.
mo:performer [
foaf:name "Andrei Gavrilov";
mo:instrument mo:Piano;
];
mo:conductor [
foaf:name "Ricardo Muti"
];
# Two possibilities I see here: either
mo:performer [
a foaf:Group;
foaf:name "The Philadelpia Orchestra";
mo:instrument mo:Orchestra; # yes it is weird
.
]
# Or have a dedicated property, suproperty of agent, just like
for conductor
mo:orchestra [
a mo:Orchestra; # could also be chamber orchestra,
# could be a subclass of
musical group, in fact
foaf:name "The Philadelpia Orchestra";
]
event:hasFactor :pianoconcertoNo2;
event:hasProduct :theSound;
.
:theRecord a mo:Recording;
event:hasFactor :theSound;
event:hasProduct [
a mo:Signal;
mo:publishedAs [
a mo:Record;
mo:releaseStatus mo:official.
]
]
.
Yeah. I understand the mechanism, it still looks a bit convoluted for
me. I somehow would like to see the possibility to shortcut this and
say: this and this performance is published as a record. The
intermediate steps of 'producing' a sound, this then producing a
signal which is then published' seems to be, though technically
correct, on such a technical level that most of the user would not
even understand what we are talking about. To push things to extreme,
well, you could start describing that the sound, in fact, is a
combination of many different sounds that different instruments
produce and provide that description; you could start describing the
recording process with a specific instrument playing at a given time
interval and not in other, and describe that process, etc, etc. It is
all possible, but do we really need that? I am still not convinced.
Cheers...
Ivan
Ivan
yep, it is a good start, although....
http://wiki.musicbrainz.org/AdvancedInstrumentTree
(which seems to be very detailed) has some debatable choices (in my
view, but I am not an expert) and also missing.
Example for the first: why would a 'viola da gamba' be the, sort of,
generic term that leads to a 'bass', whereas the cello appears under
violins? It seems to be an arbitrary choice and false (the viola da
gamba has pretty much the same size as the cello but has more chords
and and does not have a pin).
Example for the second: the term piano should have some other sub-
categories (why having a 'toy piano' there beats me, b.t.w.), like a
fortepiano; this instrument is still played on historical recordings
of Mozart or Beethoven, for example. The cemballo seems to be missing
altogether, though this should be (probably) a separate entry for
plucked string instruments...
On the other hands, the taxonomy seems to have put a genuine effort in
adding non-european instruments. That is good, though than I do not
see santoor as a separate instrument, it is just mentioned...
It would be good to see where this comes from. Maybe what we have to
do is to take something like this, skosify it, for example, and
establish a mechanism whereby the community can add new entries to it.
I doubt whether we could settle that single handed...
The wikipedia seems to be a curious mixture, with instruments mixed
with performers. I do not really like that....
Ivan
On Feb 27, 7:58 pm, florent <jahr...@gmail.com> wrote:
> On 2/27/07, Ivan <ivan.her...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 27, 4:41 pm, "Yves Raimond" <yves.raim...@gmail.com> wrote:
> > > I quite like this idea!! I think it could give enough
> > > flexibility/expressiveness for dealing with this concept. We could
> > > create start-points in MO (rock, jazz, ...), and let users build on
> > > top of it, by creating new genres, and relate genres together using
> > > SKOS properties.
>
> > Me too. Actually, I wonder whether we should not do the same with the
> > instruments. I have played with an example just now (I will post what
> > I did in a few minutes) and the instruments really need more work. I
> > wonder whether there is a taxonomy somewhere on instruments that we
> > could convert into a SKOS taxonomy and take it from there...
>
> > Ivan
>
> hi
>
> Here is the "instrument taxonomy" currently used by musicbrainzhttp://wiki.musicbrainz.org/InstrumentRelationshipAttribute
> and here is the "next one"http://wiki.musicbrainz.org/AdvancedInstrumentTree
> (it's only simples trees)
> there is also the wikipedia pagehttp://en.wikipedia.org/wiki/Category:Musical_instruments
florent
Hi Florent,
yep, it is a good start, although....
http://wiki.musicbrainz.org/AdvancedInstrumentTree
(which seems to be very detailed) has some debatable choices (in my
view, but I am not an expert) and also missing.
Example for the first: why would a 'viola da gamba' be the, sort of,
generic term that leads to a 'bass', whereas the cello appears under
violins? It seems to be an arbitrary choice and false (the viola da
gamba has pretty much the same size as the cello but has more chords
and and does not have a pin).
Example for the second: the term piano should have some other sub-
categories (why having a 'toy piano' there beats me, b.t.w.), like a
fortepiano; this instrument is still played on historical recordings
of Mozart or Beethoven, for example. The cemballo seems to be missing
altogether, though this should be (probably) a separate entry for
plucked string instruments...
On the other hands, the taxonomy seems to have put a genuine effort in
adding non-european instruments. That is good, though than I do not
see santoor as a separate instrument, it is just mentioned...
I don't know much about instruments. I personnaly think this list is quite impressive and would be totally unable to emit any criticisms at it :)
Although, I think you should go on MB mailing list to tell them what you think, it's looks interresting and they are pretty open. The advancedTree is still not in production...
It would be good to see where this comes from. Maybe what we have to
do is to take something like this, skosify it, for example, and
establish a mechanism whereby the community can add new entries to it.
I doubt whether we could settle that single handed...
I really think this list could be good for the ontology. As this is MB, their will be data extractable from MB so we could leverage on that...
The wikipedia seems to be a curious mixture, with instruments mixed
with performers. I do not really like that....
Wikipedia seems to be a mixture many times. I repeat, I don't know much about instruments so I can't see where exactly are the problems, but it looks quite messy to me.
I also had a look at their genre definition for the ones I know and it seems to miss quite a lot of things, the granularity of definition looks very variable...(but I know this will eventually change) I'll try to have a look at the web to see if their is others taxonomy available... (maybe some good old music library allready worked on this)
Florent
Yves Raimond
>
> It seems that we are pretty much in agreement on the composition/
> musical work aspect of my example, so I will remove that part from the
> mail (just for clarity). I have only one pending problem on that one
> which has nothing to do with the exact class structure, and that is
> the value space of 'mo:opus'. At the moment, it is a literal, but that
> would make it pretty much unusable for reliable sparql query (is it
> 'op.18', 'Opus 18', 'Op. 18', etc...). Maybe something like
>
Yes - I completely agree that it can create some problems here. Is it
possible to use a property mo:opusNumber here (simple solution)? Or,
yes, we should definitely create some individuals to represent such
opus. Maybe as an external ontology, like the Key one.
[snip]
> you are talking about 'Performer' as being a subclass of Agent. Right,
> that is in the RDF/XML. And, indeed, mo:performer is a subproperty of
> hasAgent. This is then all right, except that this relationship does
> not appear in the HTML version of the text
>
Yes - it was a deliberate choice to not display these (only OWL-DL)
classes. I think it is not really good to identify a "role" like this.
I really prefer to don't really give the choice here, and force to use
a sub-property of hasAgent like mo:performer, mo:conductor, and so on.
If you have a DL reasoner available, you can infer that:
:perf mo:performer :agent ==> :agent a mo:Performer
[snip]
> :gavrilovPerf a mo:Performance;
> event:hasFactor :pianoconcertoNo2.
> mo:performer [
> foaf:name "Andrei Gavrilov";
> mo:instrument mo:Piano;
> ];
> mo:conductor [
> foaf:name "Ricardo Muti"
> ];
> # Two possibilities I see here: either
> mo:performer [
> a foaf:Group;
> foaf:name "The Philadelpia Orchestra";
> mo:instrument mo:Orchestra; # yes it is weird
> .
> ]
> # Or have a dedicated property, suproperty of agent, just like
> for conductor
> mo:orchestra [
> a mo:Orchestra; # could also be chamber orchestra,
> # could be a subclass of
> musical group, in fact
>
> ]
Mmm, ok. What about:
mo:performer [
a mo:Orchestra; #(which is a sub-Group)
foaf:name "The Philadelpia Orchestra";
]
?
(this is a bit in the middle of your two propositions)
> Yeah. I understand the mechanism, it still looks a bit convoluted for
> me. I somehow would like to see the possibility to shortcut this and
> say: this and this performance is published as a record. The
> intermediate steps of 'producing' a sound, this then producing a
> signal which is then published' seems to be, though technically
> correct, on such a technical level that most of the user would not
> even understand what we are talking about. To push things to extreme,
> well, you could start describing that the sound, in fact, is a
> combination of many different sounds that different instruments
> produce and provide that description;
Yes - I completely understand your point. I would also add that, as
the sound is so far considered as an event, it is actually possible to
decompose a sound into a mixture of different sounds (maybe each of
them coming from a particular sub-performance, a bit like in the
nirvana example) :-)
Well, I think we really have to discuss about it. As I understand it,
you would want to to create a shortcut between a performance and a
record. The point is, if we do this, we are not able to express
anymore things like in the example in which Phil and Mary both go to
the same performance, recorded it using their cell phones, and make
the recording available on their web-page. Indeed, these are two
different recording, and one may want to associate to this recording
"I was next to the drummer" or "I was at the bar" - through two
Recording events. I have really no fixed opinion about where to end
the expressiveness restrictions we add. But I think it is somehow ok
to write four triples (performance ---> sound ---> recording
---->signal---->record) instead of one (performance--->record), then
giving "anchor points" to much much more information.
There are several possible directions from where we are now.
* I think one of the main "simplification" we may want to create
(although I am not sure it is a good thing, as it goes against most of
the best-practice in ontology design, such as OntoClean) could be to
merge a Composition and the MusicalWork itself into a single class
(and maybe using dc:created and geo:location on it). But, once getting
to the Movement, this approach will definitely need some further work,
as it is not easy anymore what a movement is:-)
* We could also create shortcuts from a performance to a record. But
if we do this, we create two "paths" for expressing the same thing.
One solution to that could be to remove sound/recording/signal, but in
this case, as explained earlier, we restrict drastically the
expressiveness, by removing all these "anchor points".
* Or we could imagine some sort of in-the-middle solution, by
removing the "intermediate" objects, and offer the possibility to
directly link together two events. Like:
performance ----isRecordedIn----> recording ----publishedAs---> record
But I have troubles to think about a generic "name" for such
properties. Maybe "productUsedIn"?
However, I think this could be a good intermediate solution (although
it needs some work to create a good definition of such properties) -
what do you think about it?
But well, this approach has surely some issues, one of the first ones
being that it forbids us to described composed sounds (but yes, as far
as we are able to express composed performances (nirvana example) it
is sort of ok). And also that we are unable to express "this signal
was played" (signal --> sound) to describe audio-scrobbler-like data.
I also guess it creates some more issues for the description of
electronic music (see comments about last Fred's blog post).
So the main thing to find is: is the added value (4 triples instead of
1) is worth the loss of expressiveness? I really have no definitive
answer to this.
> you could start describing the
> recording process with a specific instrument playing at a given time
> interval and not in other, and describe that process, etc, etc. It is
> all possible, but do we really need that? I am still not convinced.
>
I think we definitely need that - this is exactly the sort of things
that could be outputted by a music-information-retrieval algorithm:
free and useful data:-) Imagine queries by a DJing system asking for
"give me all sections of a horn playing an E for at least 2 seconds"
in order to include it into a mix, and then outputting a RDF
description of such a mix?
Cheers!
Yves
Yves Raimond
[snip]
>
> It is where I think that re-introducing mo:instrument could help to
> use the ontology (at least at the first level).
>
> Why not reintroducing mo:instrument? It is sure that it would be much
> more intuitive than event:hasFactor, and event:hasFactor would remain
> in the ontology to give the expressiveness for the level 2 and 3.
Yes - I completely agree on introducing more intuitive sub-properties
of hasFactor/hasAgent/hasProduct. There are already a couple of them
(in the case of hasAgent, for performances, as in Ivan's example).
But it is true that it won't help to reduce the number of triples used
to link a performance to a record, in the usual case (like a classical
music performance) --- 4 triples. So we have to decide what the good
trade-off is (I sent a more detailed email earlier this morning). I
will just copy/paste a comment that Samer sent me yesterday night (I
hope this is ok, Samer:-) ):
[...]
I think we need to keep the idea of the signal
as the central object - once you have some signals, you can
compose them into a compilation, mix them, burn them onto
a CD (ie physical manifestation), play them through a speak
(also physical manifestation) and so one. For people with music
on their computers, what they have is signals encoded in files.
When we talk about a CD or album, we often most interested
in the signal on it, not the physical manifestation or how it is
packaged.
[...]
This may suggest another solution, which could be to allow to directly
link a performance to a recording, but keeping the signal as a
distinct object. Thus we have the following workflow (in the usual
case):
performance--recordedIn-->recording---->signal---->record (3 triples).
I still don't know if it is worth the change though.
My only aim is to keep as much "anchor points" for more expressiveness
as we can, while letting the users describe the usual things in just a
few triples. But I am not sure the classical music example is an
"usual thing" (this is typically the sort of things that needs a lot
more things than pop music/CDDB-style information). For pop music, I
think the ALL example is simple enough (I guess it cannot be more
simple:-) ).
Ivan, do you have any more suggestions for this link between a
performance and a record?
Cheers!
Yves