Thoughts on the music ontology
Yves Raimond
Here are some more detailed comments and thoughts about the music
ontology. Sorry about the length of this email, but, well, I had lots
of things to say:-)
--------------------
I think one of the main issues I want to raise comes from the fact
that the ontology wants, at the same time, to be very general and very
restrictive, thus leading to several weird definitions and an overall
unclearness (is that an English word? :-) )
For example, the definition of a track seems a bit weird to me. The
track "records" a MusicalExpression, fair enough. But what are the
links between a track and MusicalItem or MusicalManifestation?
In fact, I think FRBR is really good as a grounding for libraries in
which we do not consider the inner structure of objects.
Another tricky thing comes from the fact that the music ontology
considers MusicalItem as being a subclass of a MusicalManifestation.
MusicalItem are particular instanciations of particular instanciations
of MusicalManifestations, as I understand it. My "Loco Live" CD is a
particular instance of the class of all "Loco Live" CDs, the latter
being an instanciation of MusicalManifestation. I agree that we should
definitely not consider as feasable such instance hierarchies, but we
should also try to keep the meaning of subClassOf intact:-)
Yet another tricky thing: we consider almost everything (performances,
recordings, arrangements, transcriptions) as MusicalManifestation.
This leads to problems, such as the one Ivan just pointed out,
concerning arrangements. How can we express that a particular
arrangement (so far expressed as a MusicalExpression) was used in a
particular MusicalManifestation? Many problems arise when we consider
more complex "workflows":
composition/arrangement/re-arrangement/transcription/performance/cover/...,
which are really common for a whole lot of music.
I have nothing against this simplification, but, as I was explaining
in my previous email, I think that we should leave some sort of a
choice here. We might want to get into more "workflow" details (and I
also think that it is more handy for users to talk about
"performances", "recordings",... than "MusicalExpression", which is
obviously less concrete...)
----------------
Now, I will try to explain what I think we should do:
First, I think we should link the music ontology to both FRBR and an
event/time ontology (either [1], [2], [3] or [4]) in order to express
the inner temporal (abstract, or "physical") structure of a
MusicalExpression. In the following examples, I will use the
ontologies [3], [4] and [9], which have been developed in my lab (see
[5]) over the last two years - in order to design a flexible music
production ontology framework. Its "killer feature" is the support for
multiple timelines, providing a backbone for temporal objects (thus,
we can consider the timeline corresponding to a score, for example, or
a video, a performance,...).
MusicalExpression
----------------------
Now, the painful bit: we have to figure out that in the music
ontology, so far, a MusicalExpression is the expression itself (score,
sound, signal...) and *also* the process leading to it (arrangement,
performance, recording...). So there is obviously a problem: a score
has not the same temporal structure as an arrangement event! A signal
has not the same temporal structure as a recording event! They are two
different things, and they do not share the same properties! I doubt
the MusicalExpression concept can pass the OntoClean process [10] !
So what I think is that we should *clearly* divide the expression
itself and the process leading to it (as it is done in most of the
FRBR-based ontology, I guess).
I will now use "mu" for "http://purl.org/NET/c4dm/music.owl#"
"event" for "http://purl.org/NET/c4dm/event.owl#"
Thus, we could first create several subclasses of ME:
<rdfs:Class rdf:about="http://purl.org/NET/c4dm/music.owl#Score">
<rdfs:subClassOf
rdf:resource="http://pingthesemanticweb.com/ontology/mo/MusicalExpression"/>
</rdfs:Class>
<!--here i am not talking about the actual piece of paper, but the
product of an arrangement process-->
<rdfs:Class rdf:about="http://purl.org/NET/c4dm/music.owl#Sound">
<rdfs:subClassOf
rdf:resource="http://pingthesemanticweb.com/ontology/mo/MusicalExpression"/>
</rdfs:Class>
<rdfs:Class rdf:about="http://purl.org/NET/c4dm/music.owl#Signal">
<rdfs:subClassOf
rdf:resource="http://pingthesemanticweb.com/ontology/mo/MusicalExpression"/>
</rdfs:Class>
Thus limiting ME to be *only* the actual expressions! And not having
an ontological clash with the things happening to *get to* these
expressions! It is also more "concrete", and can help the user to know
what he is dealing with...
Now, let's link to the things pertaining to the creation of these
expressions. That can be done through something like:
<mu:Performance rdf:about="#glenngouldtoronto74">
<event:hasProduct rdf:resource="#snd"/>
<event:hasAgent rdf:resource="#glenngould"/>
<event:time rdf:resource="#time"/>
</mu:Performance>
<mu:Sound rdf:about="#snd"/>
(thus #snd is also a MusicalExpression)
<time:TimeInterval rdf:about="#time">
<time:onTimeLine
rdf:resource="http://purl.org/NET/c4dm/time.owl#physicaltimeline"/>
<time:during rdf:resource="http://placetime.com/interval/gregorian/1974-06-15T19:31:00Z/P1D"/>
</time:TimeInterval>
(We see now the difference between a composer and a performer, btw: a
composer takes part into a composition event, and a performer takes
part into a performance. It seems like a fair assumption:-) )
Then:
* a mu:Performance gives a mu:Sound, which is a ME
* a mu:Recording gives a mu:Signal, which is a ME
* a mu:Arrangement gives a mu:Score, which is a ME
Obviously, a Performance might have several other factors, such as
tempo (or precise BPM), a particular score, a key...
MusicalWork
-------------------------
Ok, now, let's extend this model to MusicalWork. In the current
version of the music ontology, a MusicalWork is both the composition
event, and the work itself, which is also weird. It is sorted out if
we say that a MusicalWork is *only* the work itself, and that a
mu:Composition gives a MusicalWork. Then, if we keep on the previous
example:
<mu:Performance rdf:about="#glenngouldtoronto74">
<event:hasFactor rdf:resource="#kunstderfuge"/>
</mu:Performance>
<mo:MusicalWork rdf:about="#kunstderfuge"/>
<mu:Composition rdf:about="#kunstderfugecomp"/>
<event:hasProduct rdf:resource="#kunstderfuge"/>
<event:hasAgent rdf:resource="#bach"/>
</mu:Composition>
Expressiveness
---------------------------
By just clarifying the actual "product" and the events pertaining to
its creation, we can now express really complex "workflows":
"this person composed this piece at this date. this piece was
performed by himself a few days after in this particular place.
someone in the audience transcribed it. years after, someone did an
arrangement of it, producing a score. this score has been used in 25
recorded performances. there are also 10 un-recorded performances,
about which we just know the names of the performers and the dates" --
I am in the process of putting such examples on a wiki, I will send
the address on the mailing list when it is done.
I am also claiming that it is not far much verbose than the music
ontology as it is now, and it is really more intuitive (and it is
already widely used, in projects such as EASAIER [6], OMRAS2 [7], or
the Knowledge Machine framework [8]). I had far less troubles
explaining to people interested in the subject what a mu:Performance
was than explaining what a mo:MusicalExpression was!
MusicalManifestation
---------------------------
Well, I planned to deal with the "track" problem in this section, and
also with the ontological troubles concerning MusicalItem and
MusicalManifestation, but I am far less sure of how to deal with this
than in the previous sections:-)
Maybe, for the track problem, we should do something like:
<mo:MusicalManifestation
rdf:about="http://pingthesemanticweb.com/ontology/mo/Album"/>
<mo:MusicalManifestation
rdf:about="http://pingthesemanticweb.com/ontology/mo/Track"/>
<rdf:Property rdf:about="http://pingthesemanticweb.com/ontology/mo/has_track">
<rdfs:domain rdf:resource="http://pingthesemanticweb.com/ontology/mo/Album"/>
<rdfs:range rdf:resource="http://pingthesemanticweb.com/ontology/mo/Track"/>
</rdf:Property>
as I just noticed is done in one of the examples (and not in the RDF
source), and leave out this weird "record" property.
Moreover, I am not sure I want to talk about MusicalItem at all. As my
main concern is to describe digital materials - do we need to be able
to describe a particular CD or a particular score in my "physical"
collection? If so, I would suggest to link the MusicalManifestation to
the MusicalItem through a property, but not through subClassOf.
Moreover, a MusicalManifestation is the product of some sort of
archiving/edition process of a particular signal, a particular
arrangement, well, a MusicalExpression... Thus, I would suggest a
generic property to link it to the MusicalExpression:
<rdf:Property rdf:about="http://pingthesemanticweb.com/ontology/mo/isArchivedAs>
<rdfs:domain rdf:resource="http://pingthesemanticweb.com/ontology/mo/MusicalExpression"/>
<rdfs:range rdf:resource="http://pingthesemanticweb.com/ontology/mo/MusicalManifestation"/>
</rdf:Property>
(this is not a really good name though:-) )
--------------------------
Well, well, well... I think it covers most of the things I had to say.
I will just summarise it into a few points:
* Weird trade-off between the general purpose of the ontology and its
lack of expressiveness
* Lack of expressiveness concerning temporal information
* Terms often confusing
* Ontological troubles, due to the confusion between a
MusicalWork/Expression itself, and the process pertaining to its
creation
* Weird "records" property
* MusicalItem/MusicalManifestation troubles
Basically, a summary of all my comments relies in the following equation:
Musical universe =
People and their relationships +
Time +
Space +
Events +
Signals +
Part/whole relationships +
Temporal composition (including segmentation) +
Semiotics (relationship between concepts/information and physical
objects) +
Music specific stuff
In fact, I would love to see a sort of "hybrid" ontology coming out of
our efforts, including previous works on the topic. My main goal is to
have an ontology which is highly expressive about
performance/production information (and includes temporal
information). Indeed, I am working in a Music Information Retrieval
lab, and one of my goals is to succeed to express what can be done by
our algorithms (instrument classification, key extraction, structural
segmentation, beat tracking, ...) in such an ontology. And these
algorithms, as you can see, mainly consist in "reverse-engineering"
this production process!
I am up for suggestions for changing the music production ontology at
http://purl.org/NET/c4dm/music.owl as well, to make it "compatible"
with the music ontology! (First thing to do, change mu:Opus to
mo:MusicalWork :-) )
Just let me know if you think these comments are worth exploring. If
so, I volunteer to create an updated version of the current music
ontology, and examples!
Many thanks!
Yves
<http://moustaki.org/foaf.rdf#moustaki>
References:
[1] http://www.isi.edu/~pan/OWL-Time.html
[2] http://www.loa-cnr.it/DOLCE.html
[3] http://purl.org/NET/c4dm/time.owl
[4] http://purl.org/NET/c4dm/event.owl
[5] http://www.acemedia.org/aceMedia/files/multimedia_ontology/cfr/cmof-prop.pdf
[6] http://www.easaier.org
[7] http://omras2.doc.gold.ac.uk/
[8] http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/KnowledgeMachine
[9] http://purl.org/NET/c4dm/music.owl
[10] http://www.ontoclean.org/
Frederick Giasson
> Here are some more detailed comments and thoughts about the music
> ontology. Sorry about the length of this email, but, well, I had
lots
> of things to say:-)
Good :)
> I think one of the main issues I want to raise comes from the fact
> that the ontology wants, at the same time, to be very general and
very
> restrictive, thus leading to several weird definitions and an
overall
> unclearness (is that an English word? :-) )
Well I agree. In fact we have to do tradeoffs and this is what we are
doing on that mailing list, so yes we have to check how to make them
:)
> For example, the definition of a track seems a bit weird to me. The
> track "records" a MusicalExpression, fair enough. But what are the
> links between a track and MusicalItem or MusicalManifestation?
> In fact, I think FRBR is really good as a grounding for libraries in
> which we do not consider the inner structure of objects.
>
> Another tricky thing comes from the fact that the music ontology
> considers MusicalItem as being a subclass of a MusicalManifestation.
> MusicalItem are particular instanciations of particular
instanciations
> of MusicalManifestations, as I understand it. My "Loco Live" CD is a
> particular instance of the class of all "Loco Live" CDs, the latter
> being an instanciation of MusicalManifestation. I agree that we
should
> definitely not consider as feasable such instance hierarchies, but
we
> should also try to keep the meaning of subClassOf intact:-)
True.
> Yet another tricky thing: we consider almost everything
(performances,
> recordings, arrangements, transcriptions) as MusicalManifestation.
> This leads to problems, such as the one Ivan just pointed out,
> concerning arrangements. How can we express that a particular
> arrangement (so far expressed as a MusicalExpression) was used in a
> particular MusicalManifestation? Many problems arise when we
consider
> more complex "workflows":
> composition/arrangement/re-arrangement/transcription/performance/
cover/...,
> which are really common for a whole lot of music.
Well, as we already discussed, there is no limit in the thing we can
add to make it more expressive. However we should making sure that we
keep the ontology as simple as possible (not sure we reached that
state yet :P) and behing as expressive as possible. We shouldn't
forget the public for that ontology: web developers at large. So we
should try to make it as clear (not yet) and simple (not sure yet) as
possible.
We should't forget that most users will use the ontology to say
things like: there is 10 tracks on that album, there are the tracks,
there is the title, some reviews, the name of the group that composed
it, etc.
So we should make that evident (trought examples, etc).
But it is sure that we have the make it as expressive as possible
(and clear).
> I have nothing against this simplification, but, as I was explaining
> in my previous email, I think that we should leave some sort of a
> choice here. We might want to get into more "workflow" details (and
I
> also think that it is more handy for users to talk about
> "performances", "recordings",... than "MusicalExpression", which is
> obviously less concrete...)
This is how you will sell your points to me: making it more handy.
Yeah, the idea of restricting MusicalExpression is quite good, and it
leaves the possibility to users to extend it if they want to based on
the MusicalExpression class.
> Now, let's link to the things pertaining to the creation of these
> expressions. That can be done through something like:
>
> <mu:Performance rdf:about="#glenngouldtoronto74">
> <event:hasProduct rdf:resource="#snd"/>
> <event:hasAgent rdf:resource="#glenngould"/>
> <event:time rdf:resource="#time"/>
> </mu:Performance>
> <mu:Sound rdf:about="#snd"/>
> (thus #snd is also a MusicalExpression)
> <time:TimeInterval rdf:about="#time">
> <time:onTimeLine
> rdf:resource="http://purl.org/NET/c4dm/time.owl#physicaltimeline"/>
> <time:during
> rdf:resource="http://placetime.com/interval/gregorian/1974-06-15T19:
31:00Z/P1D"/>
> </time:TimeInterval>
>
> (We see now the difference between a composer and a performer, btw:
a
> composer takes part into a composition event, and a performer takes
> part into a performance. It seems like a fair assumption:-) )
Well yeah I agree that it is cleaner, but it seems quite complex to
query in 1 terra tripples...
The idea, I think, is to have an ontology which whom I can express
important musical expressions with few triples (useful in an open
environment such as the Web) and having the possibility to make it
much more expressive (more triples) for a closed system.
What would be useful is to re-write the examples I put in the MO
documentation with the changes you are proposing.
> Then:
> * a mu:Performance gives a mu:Sound, which is a ME
> * a mu:Recording gives a mu:Signal, which is a ME
> * a mu:Arrangement gives a mu:Score, which is a ME
>
> Obviously, a Performance might have several other factors, such as
> tempo (or precise BPM), a particular score, a key...
Yeah, since it is a subclass of ME...
>
> MusicalWork
> -------------------------
>
> Ok, now, let's extend this model to MusicalWork. In the current
> version of the music ontology, a MusicalWork is both the composition
> event, and the work itself, which is also weird. It is sorted out if
> we say that a MusicalWork is *only* the work itself, and that a
> mu:Composition gives a MusicalWork. Then, if we keep on the previous
> example:
>
>
> <mu:Performance rdf:about="#glenngouldtoronto74">
> <event:hasFactor rdf:resource="#kunstderfuge"/>
> </mu:Performance>
> <mo:MusicalWork rdf:about="#kunstderfuge"/>
> <mu:Composition rdf:about="#kunstderfugecomp"/>
> <event:hasProduct rdf:resource="#kunstderfuge"/>
> <event:hasAgent rdf:resource="#bach"/>
> </mu:Composition>
>
Clearer in a sense, but I am not sure about the simplicity (remember
the audience? :) )
> Expressiveness
> ---------------------------
>
> By just clarifying the actual "product" and the events pertaining to
> its creation, we can now express really complex "workflows":
> "this person composed this piece at this date. this piece was
> performed by himself a few days after in this particular place.
> someone in the audience transcribed it. years after, someone did an
> arrangement of it, producing a score. this score has been used in 25
> recorded performances. there are also 10 un-recorded performances,
> about which we just know the names of the performers and the dates"
This is wonderful! But really, I have doubts that normal people will
eventually describe things in such details.
But it brings us at the same point: how to modify this ontology to:
1- Make it clearer
2- Make it more expressive
3- Leave it as simple as possible.
But right now, what I am thinking about (based on the examples you
wrote so far) is if it would be possible to change the ontology to
handle these cases, but to document it in an "advanced expressivenes
document" (or call it whatever you like). In so far,
--
> I am in the process of putting such examples on a wiki, I will send
> the address on the mailing list when it is done.
Yeah I am looking forward them since I would like more example to
make my mind in your propositions. I want to see what the queries
would look like, and what would be the complexity to find/display
information encoded using that (new) ontology.
> I am also claiming that it is not far much verbose than the music
> ontology as it is now, and it is really more intuitive (and it is
> already widely used, in projects such as EASAIER [6], OMRAS2 [7], or
> the Knowledge Machine framework [8]). I had far less troubles
> explaining to people interested in the subject what a mu:Performance
> was than explaining what a mo:MusicalExpression was!
Well I agree with that point :) I am looking to give to users the
possibility to express such things, but it would be important that
they could express what they want (at a first level) with a single
ontology (MO), so they wouldn't have to have to learn 3 ontologies to
describe an album. (something that doesn't seem possible with your
examples).
> MusicalManifestation
> ---------------------------
>
> Well, I planned to deal with the "track" problem in this section,
and
> also with the ontological troubles concerning MusicalItem and
> MusicalManifestation, but I am far less sure of how to deal with
this
> than in the previous sections:-)
> Maybe, for the track problem, we should do something like:
>
> <mo:MusicalManifestation
> rdf:about="http://pingthesemanticweb.com/ontology/mo/Album"/>
> <mo:MusicalManifestation
> rdf:about="http://pingthesemanticweb.com/ontology/mo/Track"/>
>
> <rdf:Property
> rdf:about="http://pingthesemanticweb.com/ontology/mo/has_track">
> <rdfs:domain
> rdf:resource="http://pingthesemanticweb.com/ontology/mo/Album"/>
> <rdfs:range
> rdf:resource="http://pingthesemanticweb.com/ontology/mo/Track"/>
> </rdf:Property>
>
> as I just noticed is done in one of the examples (and not in the RDF
> source), and leave out this weird "record" property.
Well, but the problem is that we re-introduce the Album, Single, etc.
problems we talked about a couple of months ago.
> Moreover, I am not sure I want to talk about MusicalItem at all. As
my
> main concern is to describe digital materials - do we need to be
able
> to describe a particular CD or a particular score in my "physical"
> collection? If so, I would suggest to link the MusicalManifestation
to
> the MusicalItem through a property, but not through subClassOf.
True. The basic idea was to re-use the frbr:Item class. And then I
developed the possessions properties so that people could use the
ontology to exchange and sell individual instantiation of a musical
manifestation (so a musica item). It could seems out of the scope of
the ontology, but I think it is not.
> Moreover, a MusicalManifestation is the product of some sort of
> archiving/edition process of a particular signal, a particular
> arrangement, well, a MusicalExpression... Thus, I would suggest a
> generic property to link it to the MusicalExpression:
>
> <rdf:Property
> rdf:about="http://pingthesemanticweb.com/ontology/mo/isArchivedAs>
> <rdfs:domain
> rdf:resource="http://pingthesemanticweb.com/ontology/mo/
MusicalExpression"/>
> <rdfs:range
> rdf:resource="http://pingthesemanticweb.com/ontology/mo/
MusicalManifestation"/>
> </rdf:Property>
> (this is not a really good name though:-) )
>
Well we should think about it, but the idea of the record property
was to express the fact that a musical manifestation is the record of
a musical expression.
> --------------------------
>
>
> Well, well, well... I think it covers most of the things I had to
say.
> I will just summarise it into a few points:
>
> * Weird trade-off between the general purpose of the ontology and
its
> lack of expressiveness
Agree
> * Lack of expressiveness concerning temporal information
Well yes, but we should take care here.
Well we agree here, but I wouldn't make the temporal description at
the core of the ontology, it should be an option I think.
> lab, and one of my goals is to succeed to express what can be done
by
> our algorithms (instrument classification, key extraction,
structural
> segmentation, beat tracking, ...) in such an ontology. And these
> algorithms, as you can see, mainly consist in "reverse-engineering"
> this production process!
>
> I am up for suggestions for changing the music production ontology
at
> http://purl.org/NET/c4dm/music.owl as well, to make it "compatible"
> with the music ontology! (First thing to do, change mu:Opus to
> mo:MusicalWork :-) )
>
> Just let me know if you think these comments are worth exploring. If
> so, I volunteer to create an updated version of the current music
> ontology, and examples!
Well.... sure these comments are worth exploring! Would be quite
appreciated if you would have the time to update the current version
of the ontology according to your comments. But the first thing to do
I think would be to create some examples (basics, as currently
described into the document, and more complex as you would like them
to be (event, timeframe, etc).
> Many thanks!
Many thanks to you! I will go sleep now, since I will need more time
to make my mind on the suggestions you are making (quite tire now).
So some rest will be helpful in this case ;)
Otherwise, what are the thoughts of other people here?
thanks and take care!
Salutations,
Fred
Yves Raimond
> We should't forget that most users will use the ontology to say
> things like: there is 10 tracks on that album, there are the tracks,
> there is the title, some reviews, the name of the group that composed
> it, etc.
Yes - and I am not forgetting this point: here you only need to deal
with MusicalManifestation, right? So, apart from the few points I
raised about MusicalManifestation, I have nothing to say, and it
should stay mostly as it is now.
> Yeah, since it is a subclass of ME...
No, that is actually my point! A Performance *IS NOT* a subclass of
MusicalExpression! There is a difference between the expression itself
(sound, score...) and the process leading to it, these are two
*really* different things! A tempo, an instrument, whatever, are
factors of the process, not of the expression itself!
> But right now, what I am thinking about (based on the examples you
> wrote so far) is if it would be possible to change the ontology to
> handle these cases, but to document it in an "advanced expressivenes
> document" (or call it whatever you like). In so far,
Agreed:-) But the point is that, in order to be able to build "on top"
of the current music ontology and reach such an expressiveness, we
should at least clearly separate the process from the actual
expression -- this is were the modularity stands. There is a minimum
complexity we cannot avoid!
> Yeah I am looking forward them since I would like more example to
> make my mind in your propositions. I want to see what the queries
> would look like, and what would be the complexity to find/display
> information encoded using that (new) ontology.
>
I am working on it right now:-)
> Well I agree with that point :) I am looking to give to users the
> possibility to express such things, but it would be important that
> they could express what they want (at a first level) with a single
> ontology (MO), so they wouldn't have to have to learn 3 ontologies to
> describe an album. (something that doesn't seem possible with your
> examples).
Well I don't really agree on this point. So far, they have to learn 2
ontologies (FOAF and MO). And one of them is really not easy to
understand. I am still convinced that it is easier to think about a
"Performance" or a "Sound" than a MusicalExpression! And it is easier
to link a Performance to a Score, conceptually, than a
MusicalExpression to another MusicalExpression, actually not
describing the same thing!
I quite like the idea of this sort of "cascade" of ontologies,
allowing to do deeper and deeper in complexity:
1 - I just like to express album/tracks: MusicalManifestation (MO)
2 - I want to describe instrument involved, particular arrangement
involved... : Performance (MU)
3 - I want to describe precise timing of things happening during the
performance: TimeObject (Time)
Web developers may just stay at 1, while more "expert" users can go up to 3.
> True. The basic idea was to re-use the frbr:Item class. And then I
> developed the possessions properties so that people could use the
> ontology to exchange and sell individual instantiation of a musical
> manifestation (so a musica item). It could seems out of the scope of
> the ontology, but I think it is not.
Ok:-)
> Well we should think about it, but the idea of the record property
> was to express the fact that a musical manifestation is the record of
> a musical expression.
I think that, so far, "record" has just as a domain "Track", which
seems a bit weird. And track is not defined as a MusicalManifestation.
Apart from that, ok. But the point is that a Track "records" a Sound,
an edited Score "records" an Arrangement, so we may define a more
generic property, or a sort of "Archiving" class, as I was referring
to in my previous email.
Thanks!
Yves
Yves Raimond
> Well, but the problem is that we re-introduce the Album, Single, etc.
> problems we talked about a couple of months ago.
I do not understand the problem here: a single may also be in the
domain of has_track? It is just an album with less tracks (usually 2),
where the 1st one is actually the "title" track?
An album and a single can both refer to the same track?
Cheers,
Yves
Frederick Giasson
> > We should't forget that most users will use the ontology to say
> > things like: there is 10 tracks on that album, there are the
tracks,
> > there is the title, some reviews, the name of the group that
composed
> > it, etc.
>
> Yes - and I am not forgetting this point: here you only need to deal
> with MusicalManifestation, right? So, apart from the few points I
> raised about MusicalManifestation, I have nothing to say, and it
> should stay mostly as it is now.
Right
> > But right now, what I am thinking about (based on the examples you
> > wrote so far) is if it would be possible to change the ontology to
> > handle these cases, but to document it in an "advanced
expressivenes
> > document" (or call it whatever you like). In so far,
>
>
> Agreed:-) But the point is that, in order to be able to build "on
top"
> of the current music ontology and reach such an expressiveness, we
> should at least clearly separate the process from the actual
> expression -- this is were the modularity stands. There is a minimum
> complexity we cannot avoid!
Yeah I understand that point and I agree with you, however I "fear"
this additional complexity for users adoption :)
But I think that I can't really comment and make my mind without
seeing your examples.
> > Yeah I am looking forward them since I would like more example to
> > make my mind in your propositions. I want to see what the queries
> > would look like, and what would be the complexity to find/display
> > information encoded using that (new) ontology.
> >
>
> I am working on it right now:-)
Good, send a link as soon as you have something done :)
> > Well I agree with that point :) I am looking to give to users the
> > possibility to express such things, but it would be important that
> > they could express what they want (at a first level) with a single
> > ontology (MO), so they wouldn't have to have to learn 3
ontologies to
> > describe an album. (something that doesn't seem possible with your
> > examples).
>
> Well I don't really agree on this point. So far, they have to learn
2
> ontologies (FOAF and MO). And one of them is really not easy to
> understand. I am still convinced that it is easier to think about a
> "Performance" or a "Sound" than a MusicalExpression! And it is
easier
> to link a Performance to a Score, conceptually, than a
> MusicalExpression to another MusicalExpression, actually not
> describing the same thing!
> I quite like the idea of this sort of "cascade" of ontologies,
> allowing to do deeper and deeper in complexity:
>
> 1 - I just like to express album/tracks: MusicalManifestation (MO)
> 2 - I want to describe instrument involved, particular arrangement
> involved... : Performance (MU)
> 3 - I want to describe precise timing of things happening during the
> performance: TimeObject (Time)
I agree that we have difficulty to explain the difference between
MusicalExpression and Musical Work... :)
I think that well documented with good and easy to understand
examples, these modifications could be benefical to the ontology.
However, we should really take the time to explain the relation
between all these ontologies, why we are suggesting to use them, etc.
Another problem I see is that there is no documentation for mu and
event. So would it be possible for you to create some for the classes
and properties used?
Finally, I am thinking about documenting the classes and properties
of other ontologies used in MO (them we are suggesting to use). So
users will have all the information they need in the same document. I
think it would help users to really understand the relations between
these ontologies.
> Web developers may just stay at 1, while more "expert" users can go
up to 3.
This is what we need! But 1 should be as simple as possible ;)
> > Well we should think about it, but the idea of the record property
> > was to express the fact that a musical manifestation is the
record of
> > a musical expression.
>
>
> I think that, so far, "record" has just as a domain "Track", which
> seems a bit weird. And track is not defined as a
MusicalManifestation.
> Apart from that, ok. But the point is that a Track "records" a
Sound,
> an edited Score "records" an Arrangement, so we may define a more
> generic property, or a sort of "Archiving" class, as I was referring
> to in my previous email.
Well I re-read your suggestion (after some rest) and it makes sense,
but I will really make my mind with example ;) (I am quite visual so.
.. :) )
Thanks!
Take care,
Fred
Michael Smethurst
kitchen like an unwanted party guest for a couple of weeks ~ so if this
is off-topic...
The BBC are currently working to improve their online music "offering"
[apologies]. To this end we've been working with Robert Kaye of
musicbrainz fame on a number of small projects.
As I'm sure you're all too well aware brainz is currently fairly product
centric. Robert has plans to implement a new schema that will make
brainz more descriptive of music and less of saleable_items. We'd like
to work with him towards this end.
Many of our concerns seem to map pretty closely to yours: songs as
distinct from tracks, works, movements etc. Basically the stuff that
will enable us to better support unique bbc content: proms, electric
proms, glastonbury, desert island discs etc etc etc. Much of our
distinctive output is live perfomance so we're interested more in
describing the platonic ideal of a song than a particular track (altho
tracks are good too). So...
...I'm really not sure where this email is going. I do know that we'll
be conducting user tests on some basic stuff sometime soon so if you're
interested...
Also not sure if any of you are in London but if so maybe a meetup to
discuss this over beers might be good?
Sorry to take up your time
Cheers
Michael
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
Yves Raimond
> Also not sure if any of you are in London but if so maybe a meetup to
> discuss this over beers might be good?
I am always up for beers! :-D Who else here is in London, btw?
Cheers,
Yves
Frederick Giasson
> First an apology ~ I'm new to this place and have been lurking in the
> kitchen like an unwanted party guest for a couple of weeks ~ so if this
> is off-topic...
This is always great to get new members (so new ideas, suggestions, comments,
etc... all the stuff that keep going the development of this ontology :) ).
> The BBC are currently working to improve their online music "offering"
> [apologies]. To this end we've been working with Robert Kaye of
> musicbrainz fame on a number of small projects.
This is great news and quite interesting to know.
> As I'm sure you're all too well aware brainz is currently fairly product
> centric. Robert has plans to implement a new schema that will make
> brainz more descriptive of music and less of saleable_items. We'd like
> to work with him towards this end.
Well, I think that Yves will be quite happy to know that! In fact it is the
tradeoff that is difficult to do: where should we stop the development of these
schemas... where are the limits?
To answer to these questions, I restructured the ontology according to the FRBR
report hoping to be able to express anything (composition, production,
publication, instantiation (individual musical items), etc.
However, as you found in the last couple of mails, I failed at some point, at
some level, since some concepts were hard to define.
So it is where we are now, hoping to develop that ontology with some levels of
expressiveness depending on what the user need to describe (greatly explained by
Yves Raimond).
Yves is currently working on examples and documentation about that new revision.
> Many of our concerns seem to map pretty closely to yours: songs as
> distinct from tracks, works, movements etc. Basically the stuff that
> will enable us to better support unique bbc content: proms, electric
> proms, glastonbury, desert island discs etc etc etc. Much of our
> distinctive output is live perfomance so we're interested more in
> describing the platonic ideal of a song than a particular track (altho
> tracks are good too). So...
This is great since now we know who could be interested in using that ontology.
In fact, it would be interesting to get more information about what you want to
describe, that way we could check to make MO expressive enought to fill your
needs (so the needs of many people).
> ...I'm really not sure where this email is going. I do know that we'll
> be conducting user tests on some basic stuff sometime soon so if you're
> interested...
Certainly!
> Also not sure if any of you are in London but if so maybe a meetup to
> discuss this over beers might be good?
Well, personally I live in Quebec city so it is a little bit far, but I know
that Yves work in UK, but dunno where (Yves?)
> Sorry to take up your time
Thanks to you so taking the time to write on that mailing list.
Take care,
Fred
Yves Raimond
Here are some examples illustrating my previous email:
http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/OntologyExamples
I also wrote a small "Compatibility Layer" allowing to link the music
"Production" ontology with the Music Ontology:
http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/OntologyCompatibilityLayer
This is still really work-in-progress though! I will add some SPARQL
example really soon.
Basically, the first example describes something by only using the
level 1 of description we were talking about before
(album/artist/tracks). The second example goes up to the level 3
(temporal information).
At some point, if we get good feedback on these examples and this
methodology, we will have to clearly define what should be integrated
in MO, what should stay in the music production ontology, along with
detailed examples for each "level" of description.
I have nothing against merging everything together (up to the event
ontology maybe?) into MO, if it is clearer for the user!
Many thanks,
Yves
Frederick Giasson
> Here are some examples illustrating my previous email:
> http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/OntologyExamples
>
> I also wrote a small "Compatibility Layer" allowing to link the music
> "Production" ontology with the Music Ontology:
>
>
http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/OntologyCompatibilityLayer
>
> This is still really work-in-progress though! I will add some SPARQL
> example really soon.
Really good job, it makes things simpler with examples :)
> Basically, the first example describes something by only using the
> level 1 of description we were talking about before
> (album/artist/tracks). The second example goes up to the level 3
> (temporal information).
>
> At some point, if we get good feedback on these examples and this
> methodology, we will have to clearly define what should be integrated
> in MO, what should stay in the music production ontology, along with
> detailed examples for each "level" of description.
Yup, as we discussed on IRC, we will have to write complete examples for
different level of complexity in both XML and Turtle.
Also, we should add a section to the document to list the classes and properties
used from other ontologies. That way, users will be able to check what they need
directly from the same document (simpler for him).
> I have nothing against merging everything together (up to the event
> ontology maybe?) into MO, if it is clearer for the user!
We should check, but I would try to avoid that (at least for event) since it can
be used for many other things.
Salutations,
Fred
Yves Raimond
> > Here are some examples illustrating my previous email:
> > http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/OntologyExamples
> >
> > I also wrote a small "Compatibility Layer" allowing to link the music
> > "Production" ontology with the Music Ontology:
> >
> >
> http://www.omras2.com/cgi-sys/cgiwrap/musicstr/view/Main/OntologyCompatibilityLayer
> >
> > This is still really work-in-progress though! I will add some SPARQL
> > example really soon.
>
I just added the SPARQL examples. All the examples are "growing" in
expressiveness requirements, and are divided according to the 3 levels
I was talking about earlier in this thread.
> Also, we should add a section to the document to list the classes and properties
> used from other ontologies. That way, users will be able to check what they need
> directly from the same document (simpler for him).
>
Yes - that's a really good idea.
> We should check, but I would try to avoid that (at least for event) since it can
> be used for many other things.
>
I was more thinking about including things such as mu:Sound,
mu:Performance,..., into MO. I agree to leave the events where they
are. Thus we could have one unique vocabulary for all music-specific
stuff.
Thanks!
Yves
Ivan
welcome. Please, no apologies: this group consists partly of people
who are really working on this stuff (Frederick and Yves) and some who
are also lurking and, sometimes, causing trouble with questions (like
me...). Ie, welcome in the club! The BBC is, actually, an extremely
interesting example and, in my view, a typical user target for the
type of ontology Frederick and Yves are trying to define, so please,
continue lurking...
B.t.w.: I am in London on the week of the 14th, giving a talk at a
conference there...
Ivan
On Feb 13, 6:28 pm, "Michael Smethurst" <Michael.Smethu...@bbc.co.uk>
wrote:
danbri
On Feb 13, 6:28 pm, "Michael Smethurst" <Michael.Smethu...@bbc.co.uk>
wrote:
> First an apology ~ I'm new to this place and have been lurking in the
> kitchen like an unwanted party guest for a couple of weeks ~ so if this
> is off-topic...
>
> The BBC are currently working to improve their online music "offering"
> [apologies]. To this end we've been working with Robert Kaye of
> musicbrainz fame on a number of small projects.
Great to see this support for MusicBrainz :)
> As I'm sure you're all too well aware brainz is currently fairly product
> centric. Robert has plans to implement a new schema that will make
> brainz more descriptive of music and less of saleable_items. We'd like
> to work with him towards this end.
This is even greater news...
> Many of our concerns seem to map pretty closely to yours: songs as
> distinct from tracks, works, movements etc. Basically the stuff that
> will enable us to better support unique bbc content: proms, electric
> proms, glastonbury, desert island discs etc etc etc. Much of our
> distinctive output is live perfomance so we're interested more in
> describing the platonic ideal of a song than a particular track (altho
> tracks are good too). So...
I have a related interest here. The CASPAR EU project is looking at
digital preservation issues, and has a testbed effort in the area of
performing arts. So there has been much discussion of how best to
model performances, eg. use of FRBR, FRBR-OO, CIDOC etc. I'm at a
meeting of the project these next few days, will see if there are any
outcomes that might make sense to circulate here.
Relatedly, I'm looking into models for preservation of relational
data, so have begun exploring use of MusicBrainz server with RDF/SQL
mapping tools as a testbed.
> ...I'm really not sure where this email is going. I do know that we'll
> be conducting user tests on some basic stuff sometime soon so if you're
> interested...
>
> Also not sure if any of you are in London but if so maybe a meetup to
> discuss this over beers might be good?
Sounds good to me. I'm circulating between Bristol, Leiden, and Rome
the next few months, ... but London isn't too far from that circuit
and I've plenty of reasons to pass through London. Alberto (cc:'d)
might also be interested.
> Sorry to take up your time
Not at all! Interesting stuff. Can you say any more about your
approach to modelling performances and events? especially, how are
they identified?
cheers,
Dan
Michael Smethurst
Ivan
Do you have any dates with free evenings for your london trip?
Would be good to get a few bbc types and Yves and you together to chat
brainz and ontologies and stuff over a beer or 3...
My main concern: how far can we push the brainz model (to meet our needs
(bbc and ontology group)) without alienating the brainz community?
What's the sweet spot between descriptive enough and over complex?
We're a little frightened of having a perfect model with no data in it
;)
Dan Brickley
>
> Sorry for the delay in replying ~ I've been peaky >:~(0
>
>
> Ivan
> Do you have any dates with free evenings for your london trip?
> Would be good to get a few bbc types and Yves and you together to chat
> brainz and ontologies and stuff over a beer or 3...
>
> My main concern: how far can we push the brainz model (to meet our needs
> (bbc and ontology group)) without alienating the brainz community?
> What's the sweet spot between descriptive enough and over complex?
>
> We're a little frightened of having a perfect model with no data in it
> ;)
Maybe a goal could be to round-trip MusicBrainz data through it? I
started playing this week with using D2RQ to expose RDF view of the MB
SQL store. Well, last night, to be exact. It would be good to make
sure the MB data is clearly and usefully expressible in whatever comes
out of these discussions...
Dan
Frederick Giasson
> Maybe a goal could be to round-trip MusicBrainz data through it? I
> started playing this week with using D2RQ to expose RDF view of the MB
> SQL store. Well, last night, to be exact. It would be good to make
> sure the MB data is clearly and usefully expressible in whatever comes
> out of these discussions...
It was the primary goal when I started to develop that ontology and it has been
the basement of the ontology at that time (because it changed a lot since). But
at the simpler level, MO should be able to express MB data easily enough.
Take care,
Fred