Shortcuts in the music ontology
Yves Raimond
I am just launching a new thread here, to deal with the stuff we
discussed with Ivan and Fred in the "revision 1.10" thread.
Well, I think I just begin to understand Ivan's concerns about the
growing complexity of the ontology, and, yes, I think we should leave
the door open for more expressiveness, while still making things
really simple for "common" things (just the description of an LP
collection, for example).
So far, the "workflow" for a complete description is:
Composition --> MusicalWork --> Performance --> Sound --> Recording
-->Signal --> Record
To be able to express this complex workflow is indeed a good solution
to create lots of "anchor" points for more knowledge. We could plug a
"cognition" ontology on top of Sound, a "microphone/DAC" ontology on
top of Recording. We can create an AudioScrobbler ontology using
Signal and Sound, and a Playback event between those two. We can also
plug a Mixing ontology, dealing with signals as factors and outputting
a signal as well (Florent, I will detail this later in an answer to
the thread you launched).
All this stuff is really beautiful, but to have 7 triple patterns to
query "I want to know at what time was composed the piece
corresponding to this track", is indeed too much for an end user. So
we need shortcuts in such an usual workflow.
The point is, if we create a shortcut, we implicitly allow two ways of
expressing one thing, and this is clearly not good... However, I will
detail some things I thought of in order to bypass this problem.
Ivan suggested that we should be able to directly link a Performance
to a particular Record.
Well, this is not possible to that extent. Indeed, the concept of a
Track in MBZ is equivalent to our concept of Signal, so we need to
keep it. In MO, a Record is, for example, the track 2 on an album. And
we also need Signal in order to attach fingerprints (trmid, puid) to
it.
-------------First solution (simple)
However, what we can do is to create a relation linking a Performance
to a Signal. Thus we may create a property hasIndirectProduct in the
Event ontology, which relates an Event to a product of a more complex
workflow in which the Event is a starting-point. A subproperty of it
could be "recordedAs" linking a Performance to its indirect product: a
Signal. Thus the new workflow is:
Composition --> Work --> Performance ----recordedAs-----> Signal --> Record
And we can still express things that are important for the annotation
of collections of classical music:
Composition --> Work
Work --> Arrangement --> Score
Score & Work --> Performance --> Signal -->Record
Still, we have a problem: we have two ways of relating a Signal to a
Performance (complete workflow, and recordedAs shortcut).
But we could make the fair assumption that an "expert" user, wanting
to express, for example, the position of a particular microphone
(perhaps by embedding MO in an audio sequencer?) on a guitar amp
creates, along with all this knowledge, also this shortcut.
Thus, the knowledge he produces may still be used by "normal" user.
Expert user will look for the Recording event.
I even think that, if we go this way, we should do two different pages
of doc, one for "normal" use, and one for "expert" use.
This is one solution.
-------------Second solution (a bit more complex, but really beautiful:-) )
The other thing could be to rely entirely on transitive properties to
link all the Events in a workflow together. Thus, I can use the same
property to look for all particular Event occuring during this
workflow.
But, yes, it implies some reasoning.
This could rely on a transitive property productUsedIn (pUI). Then:
Composition -------pUI--------> Performance -------pUI-------->
Recording ---------product----->Signal
Then, when looking for things related to the Performance, I just do
select ?whatever
where
{
?event hasProduct <therecord>. # I get into the workflow here
?perf productUsedIn ?event. # I search into the workflow...
?perf a Performance. # For a performance
?perf ?prop ?whatever. # and I grab the things I want
}
Looking for any information related to other events in the workflow
takes exactly the same number of triples (just replace "a Performance"
by "a Recording", "a Composition" or "a Arrangement"...)
This approach has two main drawbacks:
* We need reasoning over transitive properties to make it really useful.
* We loose Sound, Score, Work, and so on... We just keep the Events
and Signal/Manifestation/Item. Note that it could still be ok, if we
ask people wanting to describe, for example, the inner structure of an
arrangement or the cognition of a Sound, to create also the shortcuts,
as explained earlier. To express that a performance is using a
particular arrangement:
Arrangement & Composition ----pUI----> Performance ---pUI--->
Recording ----product---> Signal ----pUI----> Record
5 triples...
--------------
Well, what do you think about it? Should we use the simple solution,
the more complex one, or try to mix both?
Cheers!
Yves
Frederick Giasson
> I am just launching a new thread here, to deal with the stuff we
> discussed with Ivan and Fred in the "revision 1.10" thread.
Good :)
> Well, I think I just begin to understand Ivan's concerns about the
> growing complexity of the ontology, and, yes, I think we should leave
> the door open for more expressiveness, while still making things
> really simple for "common" things (just the description of an LP
> collection, for example).
Exactly, because the main concern of the ontology now is to stabilize things to
a certain level of expressiveness. Even if the ontology is not able to describe
the physical characteristics of the ear when it process sounds from the external
environment, it doesn't mean that it is not a good music ontology ;)
> So far, the "workflow" for a complete description is:
>
> Composition --> MusicalWork --> Performance --> Sound --> Recording
> -->Signal --> Record
I think it is a good workflow that explain well the steps that lead a
Composition to its published Record.
However, as we know, most people don't want to describe all these steps when
they will want to describe musical things.
So it is why shortcuts are essential in a sense. We need to give the possibility
to express only what they want.
For example, I started to map the musicbrainz RDB to MO. The results is that I
only need Performance, Signal and Record.
In fact, no information is given by MBZ to describe anything for the
Composition, MusicalWork, Sound and Recording classes. So why should I bother to
duplicate them for each Album and Track MBZ have? I think I shouldn't.
> To be able to express this complex workflow is indeed a good solution
> to create lots of "anchor" points for more knowledge. We could plug a
> "cognition" ontology on top of Sound, a "microphone/DAC" ontology on
> top of Recording. We can create an AudioScrobbler ontology using
> Signal and Sound, and a Playback event between those two. We can also
> plug a Mixing ontology, dealing with signals as factors and outputting
> a signal as well (Florent, I will detail this later in an answer to
> the thread you launched).
This is exactly what is interesting with the current music production workflow.
> All this stuff is really beautiful, but to have 7 triple patterns to
> query "I want to know at what time was composed the piece
> corresponding to this track", is indeed too much for an end user. So
> we need shortcuts in such an usual workflow.
Exact. But note to other users: there is already a shortcut used in the first
level of example in the document of MO: dc:creator into the mo:Record resource.
That way, one can can describe a MusicArtist and its Records. This user (level
1) don't have to bother to describe composition, work, performance, etc... they
are implied by the dc:creator properties in the mo:Record.
In fact, a mo:Record can't exist without this workflow... so if it is not
physically described, it should be implied.
> The point is, if we create a shortcut, we implicitly allow two ways of
> expressing one thing, and this is clearly not good... However, I will
> detail some things I thought of in order to bypass this problem.
True, but you have the answer bellow.
> Ivan suggested that we should be able to directly link a Performance
> to a particular Record.
> Well, this is not possible to that extent. Indeed, the concept of a
> Track in MBZ is equivalent to our concept of Signal, so we need to
> keep it. In MO, a Record is, for example, the track 2 on an album. And
> we also need Signal in order to attach fingerprints (trmid, puid) to
> it.
This is really important to have in mind: MBZTrack == MOSignal.
And it makes much sense in my mind. So a signal (with all its characteristic)
could be published on more than one record.
In fact, all its sense is took when we check a Signal as a MusicExpression
(instead of a MusicManifestation for a mo:Record). Remixes, etc. are done at the
signal level, not the Record... in fact, how one could remix a record? he
can't... the only way would be to create a signal from a record, and to create a
new record from this new (remixed signal).
> -------------First solution (simple)
>
> However, what we can do is to create a relation linking a Performance
> to a Signal. Thus we may create a property hasIndirectProduct in the
> Event ontology, which relates an Event to a product of a more complex
> workflow in which the Event is a starting-point. A subproperty of it
> could be "recordedAs" linking a Performance to its indirect product: a
> Signal. Thus the new workflow is:
>
> Composition --> Work --> Performance ----recordedAs-----> Signal --> Record
Like that. Also, could we think about other subProperties of hasIndirectProduct
to link a Composition to a signal for example? Something like
"compositionRecordedAs". If so, we could rename "recordedAs" for
"performanceRecordedas". We could extend the idea even further.
> Still, we have a problem: we have two ways of relating a Signal to a
> Performance (complete workflow, and recordedAs shortcut).
> But we could make the fair assumption that an "expert" user, wanting
> to express, for example, the position of a particular microphone
> (perhaps by embedding MO in an audio sequencer?) on a guitar amp
> creates, along with all this knowledge, also this shortcut.
> Thus, the knowledge he produces may still be used by "normal" user.
> Expert user will look for the Recording event.
>
> I even think that, if we go this way, we should do two different pages
> of doc, one for "normal" use, and one for "expert" use.
As we discussed over IRC (#musicontology on freenode), it is the solution.
Experts would have to explicits these shortcuts, expect, naturally, if the data
is at the intention of a closed system (in that case, they have all the leasure
to do whatever they want).
But as I said above, we already started to use shortcuts with the use of
dc:creator in mo:Record. We only extend the idea here.
Anyway, most users will need to know which artist recorded what. Then, shortcuts
or not in the workflow that lead to records, they will be able to answer these
questions via the dc:creator property in mo:Records.
Well, I think I understand this solution with a couple of re-reading. However I
am not sure that we should go into that direction. We lose some expressiveness
and we add complexity (another time).
Well explained (with schemas that will come soon), the above (solution 1)
workflow is quite simple and intuitive to use. However, am I not convinced that
the solution 2 is that intuitive. It is sure that it would work, but I will need
more time to make my mind on it.
Anybody else has a comment vis-a-vis the solution 2?
Salutations,
Fred
Michael Smethurst
a pretty good place
But...
Stepping aside from the ontology and ignoring rdf (just for second) have
any of you given any thought to how much of this model could be pushed
into brainz?
If you could draw your ideal brainz schema what would it look like?
I'm particularly keen to see a brainz model that expresses your
differentiation between mo:work and mo:expression
I've sketched numerous schemas over time ~ none of which seem to quite
do the job and like you always seem to arrive at a model so complex the
only way to make it workable is to shortcut it
I'd love to see your sketches...
Hi Yves,
Salutations,
Fred
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.
Frederick Giasson
> Don't want to distract any of you ~ specially since you seem to have hit
> a pretty good place
> But...
>
> Stepping aside from the ontology and ignoring rdf (just for second) have
> any of you given any thought to how much of this model could be pushed
> into brainz?
> If you could draw your ideal brainz schema what would it look like?
>
> I'm particularly keen to see a brainz model that expresses your
> differentiation between mo:work and mo:expression
>
> I've sketched numerous schemas over time ~ none of which seem to quite
> do the job and like you always seem to arrive at a model so complex the
> only way to make it workable is to shortcut it
>
> I'd love to see your sketches...
Agree, it is why I prefer solution #1. In fact, my mapping of MBZ is mostly done
and the result is quite interesting.
I will release a RDF VIEW (and I hope at the same time) a RDF dump of this
mapping. I will also write a document that explains what I have done in that
mapping.
Salutations,
Fred
Yves Raimond
> > Stepping aside from the ontology and ignoring rdf (just for second) have
> > any of you given any thought to how much of this model could be pushed
> > into brainz?
> > If you could draw your ideal brainz schema what would it look like?
Well... I think it is quite tricky to try see the brainz schema as
RDF. Indeed, we realised it when trying to map the concept of
Track/Album, where N-ary relations (where N>2) are used
(has_track(album,track,track_number)). But it is true that for more
high-level stuff (frbr, or "workflow" --
Composition/Performance/Recording sort of things), we should
definitely launch some sort of interaction between brainz and MO.
I guess my "ideal" brainz schema should describe this sort of workflow
we are dealing with in MO. It might not be the smallest model, but it
gives a formal way of expressing everything that went on to produce a
particular track, and to plug specific models/taxonomies on top of it.
> >
> > I'm particularly keen to see a brainz model that expresses your
> > differentiation between mo:work and mo:expression
Well, my view is not to rely too much on frbr:expression, as its
definition is indeed *really* vague - at least for music (look at the
frbr documentation: expression is supposed to be a sound in the case
of music, and the line after they said that it is not supposed to
include any aspects of physical form)... That's why we introduced more
meaningful things such as Sound, Signal, Performance, and workflows
linking all this stuff together (this is this last thing we try to
shortcut in "usual" cases).
> >
> > I'd love to see your sketches...
>
I guess Fred's MBZ mapping is on the way. I did a magnatune (creative
commons music) dump, available at http://moustaki.org:2020/ (well,
when my broadband provider doesn't randomly kill my connection:-) ).
This is still in the early stages though, but shows how MO can be used
for simple things (there are not much things in the magnatune sql db
indeed).
Btw, when are we having this beer in London?
:-)
Cheers,
Yves