preformer vs. composer in classical works

[Kurt J]

Hi All,

What is the perferred way to treat composers v. performers re: a
classical music work?

Do i need to model the mo:Composition event? can i just model the MusicalWork?

:SicilianoBWV a mo:MusicalWork;
foaf:maker :Bach;
mo:manifestation :ScilianoBWV_track .

:ScilianoMWV_track a mo:Track ;
foaf:maker :FelipeSarro
mo:available_as :SomeMP3 .

Is the above ok? am i misusing mo:manifestation from FRBR perspective???

-Kurt J

[Kurt J]

Hi,

In response to myself,

> :SicilianoBWV a mo:MusicalWork;
>  foaf:maker :Bach;
>  mo:manifestation :ScilianoBWV_track .
>
> :ScilianoMWV_track a mo:Track ;
>  foaf:maker :FelipeSarro
>  mo:available_as :SomeMP3 .

perhaps this is more appropriate:

:SicilianoBWV a mo:Score;

foaf:maker :Bach;
mo:manifestation :ScilianoBWV_track .

:ScilianoMWV_track a mo:Track ;
foaf:maker :FelipeSarro
mo:available_as :SomeMP3 .

i think this obeys all domains/ranges...

[Yves Raimond]

Hello!

>
> What is the perferred way to treat composers v. performers re: a
> classical music work?
>
> Do i need to model the mo:Composition event?  can i just model the MusicalWork?
>
> :SicilianoBWV a mo:MusicalWork;
>  foaf:maker :Bach;
>  mo:manifestation :ScilianoBWV_track .

That's one way of associating a composer with a work. If you want to
add more information about the composition event itself (time, place,
influences, etc.), use a mo:Composition event. mo:manifestations is
quite ambiguous here (see below).

>
> :ScilianoMWV_track a mo:Track ;
>  foaf:maker :FelipeSarro
>  mo:available_as :SomeMP3 .
>

Here, it is quite ambiguous - you're just stating that Felipe Sarro
"made" that track, so it is unclear whether he is the producer, a
performer, the sound engineer...
It is best to use a mo:Performance in that case. So it would look like:

:SicilianoBWV a mo:MusicalWork;
foaf:maker :Bach;

mo:performed_in :performance .

:performance a mo:Performance;
mo:performer :FelipeSarro;
mo:recorded_as [ mo:published_as :ScilianoMWV_track ].

(where :ScilianoMWV_track is the track on a particular record).

Cheers,
y

[Kurt J]

Hello Again,

Re: this thread, I would like to politely suggest we consider the
creation of some, shall we say, ID3-like properties.

Consider querying the example below:

> :SicilianoBWV a mo:MusicalWork;
>  foaf:maker :Bach;
>  mo:performed_in :performance .
>
> :performance a mo:Performance;
> mo:performer :FelipeSarro;
> mo:recorded_as [ mo:published_as :ScilianoMWV_track ].
>
> (where :ScilianoMWV_track is the track on a particular record).

while this models the reality very well and is not ambiguous, it is
kind of complicated. so i've done this modelling and now i want to
write a query that returns the composer of a particular audio file.
it would look like this:

select ?composer where
{
?t mo:available_as <audio_file_uri> .
?rec mo:track ?t .
?sig mo:published_as ?rec .
?perf mo:recorded_as ?sig .
?mw mo:performed_in ?perf .
?mw foaf:maker ?composer .
}

after not looking at this for a few days, it took me a good 10 minutes
to work out what i needed to do (maybe i'm slow ;-)

do we break the FRBRness if we add a property like mo:composer with
domain mo:MusicalManifestation and mo:MusicalWork ??? and do a
similar thing for mo:performer (or perhaps create a new property) ???
maybe additional properties are needed to more easily provide
attributions to manifestations ?

any thoughts?

-Kurt J

[Yves Raimond]

Old discussion over and over again :-)

The main arguments against that are:
1) You have different ways of expressing the same information. You
need some rule support to get from one to the other.
2) If we extend that model, why not applying mo:composer to
everything? The performance, the canonical track, the track itself,
etc.
3) You break extensibility - for example, in that case, you disallow
others to express things about the performance.
4) You encode lots of implicit semantics in a single mo:composer
statement (this is a recording of someone performing this person's
work)
5) (slightly biased) flatness is bad...

The main arguments for are:
1) Easier to query (you get from 6 to 4 triple patterns in your query example)
2) Closer to item-centric metadata formats such as ID3, so more intuitive

Of course, an ontology defines a particular model of things. I would
suggest that such ID3-inspired terms live in another namespace as it
is quite far from the MO model. And it should ultimately be published
alongside the corresponding denormalisation rules.

y

>
> any thoughts?
>
> -Kurt J
>
> >
>

[Kurt J]

I thought you'd be quick to respond :-)

you're right something like this would have to be in a different namespace.

i suppose my point was could we lower the 'learning curve' w/o messing
things up. and the answer is clearly "not really, we've thought about
it"

[Yves Raimond]

>> Of course, an ontology defines a particular model of things. I would
>> suggest that such ID3-inspired terms live in another namespace as it
>> is quite far from the MO model. And it should ultimately be published
>> alongside the corresponding denormalisation rules.
>>
>
> I thought you'd be quick to respond :-)
>
> you're right something like this would have to be in a different namespace.
>
> i suppose my point was could we lower the 'learning curve' w/o messing
> things up.  and the answer is clearly "not really, we've thought about
> it"

I think it is a trade-off between extensibility (being able to cover
as much of the music domain as possible) and usability (having as
little building blocks as possible). An ID3-like flat schema will
clearly be very usable, but not very extensible. CIDOC-CRM, on the
other hand, is very extensible, but difficult to use :-) I hope MO is
not too bad at trying to be both extensible and usable... For just
pure RDFisation of the most commonly used ID3 tags, you basically just
have to deal with mo:Record, mo:Track and mo:MusicArtist.