DOREMUS-ANR / doremus-ontology

Describing music catalogs
http://data.doremus.org/ontology/
Creative Commons Attribution 4.0 International
19 stars 8 forks source link

How multiple or alternate casting should be modeled? #12

Closed pasqLisena closed 8 years ago

pasqLisena commented 8 years ago

Currently we have the U25_alternate_casting symmetric property for connecting two castings.

Questions:

  1. Can we say that there is an "official" casting and an alternate one? If yes, how can we distinguish the two in the data that needs to be converted in RDF?
  2. Is U25 not redundant? The two casting are in fact connected to the same expression.
schermata 2016-08-25 alle 18 46 19
rtroncy commented 8 years ago

I have edited @pasqLisena original issue description to make it slightly clearer. There are indeed two sub-questions:

pierrechoffe commented 8 years ago

@pasqLisena @rtroncy before answering the questions, let's see the big picture :

A piece of music can be written for piano but other versions may exist, either by the same composer or by other composers. In the case of other composers, we are talking about derivative works, so this is another story. Now, in the case of various versions of a composition by the same composer, there are 2 possibilities :

  1. the composer decided that he would give a specific opus number to each. In this case, there are 2 different F22_Self_Contained_Expression (with only one M6_casting in each). We treat these cases as if they were 2 different works, but we may add a relation between them (e.g. the F28_Expression_Creation of the 2nd F22 p16_used_specific_object the first F22).
  2. the composer did not indicate any specific opus number to each version. The piece is clearly written for (casting 1) or (casting 2), for example a piece "for 2 pianos or 4-hand piano", with no declared preference for either one or the other.

Let's come back to your questions :

Can we really distinguish between multiple castings the role they supposedly have between main and alternate? I meant, from the original MARC data!

Since we are in case nr 2, there is clearly no main or alternate casting. They were born equal. So the property should be symmetric. The MARC data may enter one version as the "main" and another as a "variant" but this is a limitation of the system which we should not reproduce.

If this distinction matters, then adding a symmetric property named "alternate casting" between the two is obviously a bad modeling decision.

The distinction does not matter. And to be clear, the notion of alternate casting only exists in case nr 2. The property is not relevant in any other case, because the semantics would be modeled differently (e.g. using F28 p16 F22). Furthermore, we should not have the MARC limitation in the other cases, because by definition we would only have one casting for each.

pasqLisena commented 8 years ago

Thanks @pierrechoffe, for sure doubt n.1 is solved (all castings have the same importance). And yes, as you say, we should only consider castings declared by the same composer, if not, we fall in the derivation case.

Given that, I try to reformulate the n.2. We have these two facts:

Which information U25 is adding respect to the first fact? I am just pointing out that we should evaluate if keep or remove U25.

rtroncy commented 8 years ago

Thanks @pierrechoffe for clearly explaining what multiple castings means, and indeed, let's see in other issues how we will model relationships between works (and expressions). The reformulation of @pasqLisena is correct: given what you're saying, the bare existence of u25 is completely useless. The alternate casting exists already by the virtue of having more than one occurrence of u13 attached to the F22. Adding a u25 adds nothing but confusion, since it gives dominance to one particular casting over the other which is exactly what you want to avoid.

Proposal: remove u25 from the ontology (and from the model)

pierrechoffe commented 8 years ago

@pasqLisena @rtroncy ok, removed from the list of properties (https://docs.google.com/spreadsheets/d/1RNhHnp4fWEhG8G4acx8FPi-nu9fUWNhc8JNf3SQwUFE/edit#gid=1401336326) To be removed from protégé in next update ?

pasqLisena commented 8 years ago

Yes please :)

rtroncy commented 8 years ago

Done with commit https://github.com/DOREMUS-ANR/doremus-ontology/commit/31f3118f7ece3604716bf09441e75525782deb99