[MEI-L] <instrumentation> within <source>?

[Klaus Rettinghaus]

Hi Axel,

I brooded over this for some time now, and I'm still unable to see the
necessity for allowing <perfMedium> in <source>, neither for edition nor
cataloging purposes.
Whereas a repeated <instrumentation> within an expression seems to make
sense.
In some cases a single source could carry different expressions of a work
by means of instrumentation. Encoding this within <source> may be a
problem, using @source on <instrumentaion> in different <expression> would
be clearer.
Thinking about piano reductions could be quite puzzling. We should think
this over in Florence as you suggested.

Best,
Klaus

2015-03-25 17:29 GMT+01:00 Axel Teich Geertinger <atge at kb.dk>:

>  Hi Perry
>
>
>
> I largely agree with what you say. I have added my comments inline below.
>
> Any other opinions? Klaus, Kristina, ...?
>
>
>
> Best,
>
> Axel
>
>
>
>
>
> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *På vegne af *Roland,
> Perry D. (pdr4h)
> *Sendt:* 23. marts 2015 20:26
> *Til:* Music Encoding Initiative
> *Emne:* Re: [MEI-L] <instrumentation> within <source>?
>
>
>
>
>
> Hi Axel,
>
>
>
> I can certainly see the practicality in this change, but if I may play the
> devil’s advocate for a moment --
>
>
>
> According to basic FRBR tenets, doesn’t a change in medium signal a
> different expression?  If so, then allowing <perfMedium> in <source> and
> treating the differently-instrumented sources as a single expression seems
> to be a contradiction of basic FRBR.
>
>
>
> Yes, indeed. As I have argued elsewhere, however, in some situations there
> is apparently a need for either another level of grouping between FRBR’s
> work and expression levels or a less restrictive definition of the
> expression level. The FRBR recommendation says that
>
>
>
> Inasmuch as the form of *expression* is an inherent characteristic of the
> *expression*, any change in form (e.g., from alpha-numeric notation to
> spoken word) results in a new *expression*. Similarly, changes in the
> intellectual conventions or instruments that are employed to express a
> *work* (e.g., translation from one language to another) result in the
> production of a new *expression*. If a text is revised or modified, the
> resulting *expression* is considered to be a new *expression*. Minor
> changes, such as corrections of spelling and punctuation, etc., may be
> considered as variations within the same *expression*.
>
>
>
> I am aware that grouping a piano reduction and a full score as belonging
> to the same expression clearly violates this recommendation. But my problem
> is that FRBR makes no distinction between changes in medium
> (instrumentation; or language, if dealing with texts) and content; both do
> result in a new expression. However, at least as seen from cataloging point
> of view, there is a need for a hierarchy placing changes in content closer
> to the work level than changes in medium.
>
> An example: A composer’s revision of his work may leave us two versions,
> both of which may exist in full score as well as piano reductions.
> According to FRBR this would generate four expressions, and I see no way of
> grouping these into embodiments of the early version in one group as
> opposed to those of the revised version just by means of the FRBR relations
> I can define between them. Even if I could somehow describe this with
> relations, it would not offer me any obvious place to describe each of the
> two versions as a whole. The same problem would arise with, for instance,
> books in various versions, translated into a number of other languages: All
> versions in the original language and all translations of any of these
> versions would be expressions at exactly the same level, even if there is a
> fundamental difference between different versions of a work within the same
> medium and the translation of a version into a new medium. I tried to
> illustrate this in the paper that Kristina and I presented in Mainz two
> years ago.
>
> My approach is – as always, and you are probably right to criticize it –
> rather pragmatic. I want the encoding to be productive. And I believe that
> in this particular matter FRBR is not, because there is too little room for
> variation at expression level. So what I am after is a way to handle this
> without violating FRBR recommendations more than absolutely necessary.
>
>
>
> Following this “different medium=different expression” idea, the following
> markup seems appropriate. The versions for orchestra are grouped as
> embodiments of the same expression, while the piano reduction is treated as
> a separate expression due to its change of instrumentation --
>
>
>
> <source xml:id=”source1”>
>
>   <!-- full score -->
>
> </source>
>
>
>
> <source xml:id=”source2”>
>
>   <!-- full score v. 2 -->
>
> </source>
>
>
>
> <source xml:id=”source3”>
>
>   <!-- piano reduction -->
>
> </source>
>
>
>
> <expression xml:id=”expression1”>
>
>   <!-- full score instrumentation -->
>
>   <relationList>
>
>     <relation rel="hasEmbodiment" target="#source1"/>
>
>     <relation rel="hasEmbodiment" target="#source2"/>
>
>   </relationList>
>
> </expression>
>
>
>
> <expression xml:id=”expression2”>
>
>   <!-- piano reduction -->
>
>   <relationList>
>
>     <relation rel="hasEmbodiment" target="#source3"/>
>
>   </relationList>
>
> </expression>
>
>
>
> Yes, this would be the “group by medium”-choice. Theoretically possible,
> but not very useful, as I see it: There is no place to describe the
> distinct versions.
>
>
>
> If, however, one believes that a change in *content* (but not enough to be
> considered a new work) signals a change of expression, then the following
> markup could be used.  The (first) version of the full score and its piano
> reduction are grouped as belonging to the same expression and the other
> full score is a different expression (due perhaps to structural, not
> instrumentation changes).
>
>
>
> <source xml:id=”source1”>
>
>   <!-- full score -->
>
> </source>
>
>
>
> <source xml:id=”source2”>
>
>   <!-- full score v. 2 -->
>
> </source>
>
>
>
> <source xml:id=”source3”>
>
>   <!-- piano reduction -->
>
> </source>
>
>
>
> <expression xml:id=”expression1”>
>
>   <!-- full score and piano reduction instrumentation -->
>
>   <relationList>
>
>     <relation rel="hasEmbodiment" target="#source1"/>
>
>     <relation rel="hasEmbodiment" target="#source3"/>
>
>   </relationList>
>
> </expression>
>
>
>
> <expression xml:id=”expression2”>
>
>   <!-- full score v. 2 instrumentation -->
>
>   <relationList>
>
>     <relation rel="hasEmbodiment" target="#source2"/>
>
>   </relationList>
>
> </expression>
>
>
>
> Yes, this is the other possibility: group by version.
>
>
>
> In both cases, the source and the expression markup remain essentially
> unchanged, only the relationships defined within <relationList> are
> modified.  An advantage here is that no data is actually moved.  In other
> words, the performance medium information can always be found in the same
> place.  In the 2nd case, however, I’m not sure how one would describe the
> performing forces without allowing either <perfMedium> or <instrumentation>
> to be repeatable.  I don’t believe that
>
>
>
> <expression>
>
>    <perfMedium>
>
>       <instrumentation>
>
>          <instrVoice source=”source1”>Violino 1</instrVoice>
>
>          <instrVoice source=”source1”>Violino 2</instrVoice>
>
>          ...
>
>          <instrVoice source=”source2”>Pianoforte</instrVoice>
>
>       </instrumentation>
>
>    </perfMedium>
>
> </expression>
>
>
>
> is the best way to go.
>
>
>
> I agree. I may not have been very clear about this: I certainly didn’t
> mean to recommend this; it’s what I tried to avoid.
>
>
>
> The intention of @source on <instrVoice> is to allow one to say that there
> are 2 sources, one of which includes the piano in its orchestration, the
> other of which does not, which this appears to do. For the situation you’re
> describing, I think it’s much clearer to allow <instrumentation> to be
> repeatable and to carry @source, resulting in
>
>
>
> <expression>
>
>    <perfMedium>
>
>       <instrumentation source=”#source1”>
>
>          <instrVoice>Violino 1</instrVoice>
>
>          <instrVoice>Violino 2</instrVoice>
>
>          ...
>
>       </instrumentation>
>
>       <instrumentation source=”#source2”>
>
>          <instrVoice>Pianoforte</instrVoice>
>
>       </instrumentation>
>
>    </perfMedium>
>
> </expression>
>
>
>
> Yes, this is much better. Actually I think that this is the best solution
> so far. It appears to be a more gentle way of widening the definition of
> “expression” than allowing <perfMedium> in <source>, and it also avoids the
> ambiguity of my last example in which some of the sources do indicate an
> instrumentation while others don’t.
>
>
>
> Using Schematron, one could say that <instrumentation> must either a) have
> content or b) use @source, but it should not allow both.  Under these
> circumstances, I could see allowing <perfMedium> within <source>, but this
> means that <perfMedium> could occur either within <source> or within
> <expression>, which sometimes leads to criticism.
>
>
>
> You are right. Things are much harder to handle if the same information
> may appear in different places.
>
>
>
> Sorry for my usual long-winded explanation, but I think it’s important to
> explain the derivation of the markup instead of offering up a solution that
> seems to materialize out of thin air.
>
>
>
> In any case, I recognize that this is a tough problem, so I look forward
> to the formation of the cataloging IG (although I’d recommend calling it
> the “metadata IG”) and its recommendations.
>
>
>
> I see your point. “Metadata IG” is fine with me :-) But let’s discuss that
> in Florence.
>
>
>
> --
>
> p.
>
>
>
>
>
> *From:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de
> <mei-l-bounces at lists.uni-paderborn.de>] *On Behalf Of *Axel Teich
> Geertinger
> *Sent:* Friday, March 13, 2015 7:47 AM
> *To:* Music Encoding Initiative
> *Subject:* Re: [MEI-L] <instrumentation> within <source>?
>
>
>
> Hi Perry
>
>
>
> Sorry for the long response time, but I was hoping for others to step in
> first since we have had some discussion about this already. I am in favor
> of both changes. The latter – allowing <perfMedium> in <source> – would
> make it possible to avoid listing instruments at work or expression level
> which are not part of the general instrumentation of that expression, a
> piano for instance, if a piano reduction exists of an orchestral work. So
> instead of
>
>
>
> <source xml:id=”source1”>
>
>    <!-- full score -->
>
> </source>
>
>
>
> <source xml:id=”source2”>
>
>    <!-- piano score -->
>
> </source>
>
>
>
> <expression>
>
>    <perfMedium>
>
>       <instrumentation>
>
>          <instrVoice source=”source1”>Violino 1</instrVoice>
>
>          <instrVoice source=”source1”>Violino 2</instrVoice>
>
>          ...
>
>          <instrVoice source=”source2”>Pianoforte</instrVoice>
>
>       </instrumentation>
>
>    </perfMedium>
>
> </expression>
>
>
>
> we could do:
>
>
>
> <source xml:id=”source1”>
>
>    <!-- full score -->
>
> </source>
>
>
>
> <source xml:id=”source2”>
>
>    <!-- piano score -->
>
>    <perfMedium>
>
>       <instrumentation>
>
>          <instrVoice>Pianoforte</instrVoice>
>
>       </instrumentation>
>
>    </perfMedium>
>
> </source>
>
>
>
> <expression>
>
>    <perfMedium>
>
>       <instrumentation>
>
>          <instrVoice>Violino 1</instrVoice>
>
>          <instrVoice>Violino 2</instrVoice>
>
>          ...
>
>       </instrumentation>
>
>    </perfMedium>
>
> </expression>
>
>
>
> where the instrumentation in source1 could be either duplicated from
> <expression> or, if not indicated, understood as inherited from
> <expression>. The soon-to-be-established Cataloging Interest Group could
> discuss a recommended practice for this type of information.
>
>
>
> Best,
>
> Axel
>
>
>
>
>
> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de
> <mei-l-bounces at lists.uni-paderborn.de>] *På vegne af *Roland, Perry D.
> (pdr4h)
> *Sendt:* 2. marts 2015 17:43
> *Til:* mei-l at lists.uni-paderborn.de
> *Emne:* [MEI-L] <instrumentation> within <source>?
>
>
>
>
>
> There has recently been some discussion on mei-devel about the markup of
> instrumentation/performance medium information.  To deal with missing,
> incomplete, or contradictory info about instrumentation at the work level
> (the only place this info is currently permitted), the current proposal is
> to make <instrumentation> and its sub-elements (instrVoice, instrVoiceGrp
> and ensemble) members of att.edit.  This will provide @cert, @evidence,
> @resp, and @source.
>
>
>
> The second part of the effort, which may be slightly more controversial,
> centers on allowing <perfMedium> to occur not just within <work>, but also
> at the manifestation level; that is, within <source>.  Currently,
> <perfMedium> is allowed within <expression>, but not <source> in an effort
> to encourage the use of FRBR entities and to make a clear separation
> between expression and manifestation data.  But, a compelling case can be
> made that if <perfMedium> were allowed within <source>, then <expression>
> could take on more of a grouping role in those cases where there are
> multiple manifestations of what is essentially the same expression, for
> instance, when there’s a short score/sketch, a piano reduction (intended
> for rehearsal) and a full score of a symphonic work.  It may be more
> productive to allow each of these sources to carry instrumentation info and
> use <expression> to group them as one *version of the work* as opposed to a
> later revision than to force instrumentation to always be recorded at the
> expression level, resulting in many cases in a one-to-one relationship
> between <source> and <expression> without the possibility of grouping at a
> higher level.
>
>
>
> I’m inclined to make this latter change, but would like to hear from
> others before moving ahead.
>
>
>
> --
>
> p.
>
>
>
> __________________________
> Perry Roland
> Music Library
> University of Virginia
> P. O. Box 400175
> Charlottesville, VA 22904
> 434-982-2702 (w)
> pdr4h (at) virginia (dot) edu
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150415/5889ab99/attachment.html>