Thoughts about the concepts of the MO, and mapping ID3 tags to MO data

[zazi]

Hello,

I've thought a little bit about the problems with release and "master
signal". Here are my suggestion (for the beginning just prosa):
1.1 Introduction of an Event RecordingSession to handle a set of
Recordings. This event should have the property recording to use the
decomposition concept.
1.2 The product of such a RecordingSession should be a SignalGroup (I
think this is what you mean with MasterSignal), which holds a set of
Signals. This Expression has the property signal to use the
decomposition concept. The result is an unordered list of signals.
-> Okay, I can also fetch these Signals out of the Recording property
produced_signal, but what should be then the product out of the
RecordingSession?
2.1 Introduction of an Event Release (where is it now? - a
Manifestation is the product of a Release). The input is, of course, a
set of signals from one or more SignalGroups (more e.g. for a
compilation). The product is a Record (to reuse this class, but I'm
not really happy with that - nevertheless it seems to work ;) ) that
means an ordered list of Tracks.
2.2 I think the Release class need therefore also two subclasses:
RecordRelease and TrackRelease. The decomposition of the RecordRelease
event is a set of TrackRelease events. However, this is maybe also
obsolete.
3.1 Record needs the property track_count. A reconstruction of that
concept is therefore necessary. My proposal is: Record as general
superclass and Record in the meaning of a set of Track should be
called RecordGroup. So Track and RecordGroup are subclasses of Record,
which holds the relation to the signals.
3.2 Then Track can get the property album (has_album).

So I hope my suggestions will help a little bit. However, this are my
first steps into real ontology design ;)

Cheers zazi

[George Fazekas]

On Feb 26, 2009, at 12:43 AM, zazi wrote:

>
> Hello,
>
> I've thought a little bit about the problems with release and "master
> signal". Here are my suggestion (for the beginning just prosa):
> 1.1 Introduction of an Event RecordingSession to handle a set of
> Recordings. This event should have the property recording to use the
> decomposition concept.
> 1.2 The product of such a RecordingSession should be a SignalGroup (I
> think this is what you mean with MasterSignal), which holds a set of
> Signals. This Expression has the property signal to use the
> decomposition concept. The result is an unordered list of signals.
> -> Okay, I can also fetch these Signals out of the Recording property
> produced_signal, but what should be then the product out of the
> RecordingSession?

Hello,
I did some work on modelling of studio concepts,
although haven't made the effort to make this public yet (but won't be
too long.)

In the meantime, your suggestion is very interesting indeed.
Have a look at http://purl.org/ontology/studio/multitrack where you
can find some similar concepts
about how to group signals in a multitrack audio editor.
I haven't modelled a RecordingSession yet because a project can span
over several sessions
however you may also make use of a single project in several sessions.

If you can sort this out, that'd be great. My 1st impression is
something like (haven't really thought about this):

mo:ReocrdingSession a owl:Class;
rdfs:subClassOf event:Event.

then some properties for the above cases e.g.:
mo:project a owl:ObjectProperty
rdfs:domain mo:RecordingSession;
rdfs:range mt:MultitrackProject;


I don't really like the concept of MasterSignal, because it doesn't
map well on any real world concept.
There are signals having multiple channels, but these are closely tied
(e.g. multichannel audio)
A master recording however is usually a physical manifestation and
engineers don't talk about master signals.
This is why i used MultitrackProject which maps well on studio
software and DAW concepts too...
However if you want to bypass these concepts, i don't really see a
better way. Maybe SignalGroup is actually less confusing.

(I see that the rest is not really related to this, so sorry if this
is not what you trying to do:-)

cheers,
George

[zazi]

Hi George,

thanks a lot for your work on studio concepts. I think that is a little
bit out of scope of the intent of the ideas I like to present. However
it is in general helpful to expand the music ontology.
My idea of RecordingSession is just the idea to collect a specific
number of Recordings that are maybe included into an album (here
RecordGroup). At each Recording should the time property be set, so a
RecordingSession can hold Recordings of different dates and so maybe
different sessions at a studio. Furthermore I focussed with a Recording
here more to a complete track, not just a sample, which is in general
also possible and maybe the more the intent of your studio concepts.
As I've described the "input" for a Release event - you can take the
Signals out of different SignalGroups. Of course, you are also right, if
you say that a produced Signal (the product of a Recording) exist as
Manifestation that means at last at a Track, but therefore a whole
refactoring of the Release event is necessary. Because the input of a
Release event must be in this case a set of Tracks and not a a set of
Signals as I've proposed. Maybe that makes more sense.
Finally, your concept and my suggestions can be combined, but I think
that my descriptions are more related to the core of the music ontology
and yours are an expansion of it. So they should maybe kept extra.
However, I don't what Yves or other designers of the music ontology
think about that.

Cheers zazi

George Fazekas schrieb:

--
--------------------BEGIN-OF-SIGNATURE--------------------

Bob Ferris

website: http://elbklang.net
e-mail: za...@elbklang.net

--------------------END-OF-SIGNATURE----------------------

[zazi]

On 26 Feb., 20:56, zazi <z...@elbklang.net> wrote:
> Hi George,
>
> thanks a lot for your work on studio concepts. I think that is a little
> bit out of scope of the intent of the ideas I like to present. However
> it is in general helpful to expand the music ontology.
> My idea of RecordingSession is just the idea to collect a specific
> number of Recordings that are maybe included into an album (here
> RecordGroup). At each Recording should the time property be set, so a
> RecordingSession can hold Recordings of different dates and so maybe
> different sessions at a studio. Furthermore I focussed with a Recording
> here more to a complete track, not just a sample, which is in general
> also possible and maybe the more the intent of your studio concepts.
> As I've described the "input" for a Release event - you can take the
> Signals out of different SignalGroups. Of course, you are also right, if
> you say that a produced Signal (the product of a Recording) exist as
> Manifestation that means at last at a Track, but therefore a whole
> refactoring of the Release event is necessary. Because the input of a
> Release event must be in this case a set of Tracks and not a a set of
> Signals as I've proposed. Maybe that makes more sense.

I would revise my suggestion and say one more time that the input of a
Release should be a Signal and not a Track. Of course, it is in
general a Signal of a Track (e.g. of the master tape), however it is
still the audio signal and not the physical track.

Cheers zazi