[MEI-L] <instrumentation> within <source>?
Axel Teich Geertinger
atge at kb.dk
Wed Mar 25 17:29:38 CET 2015
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] 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] På vegne af Roland, Perry D. (pdr4h)
Sendt: 2. marts 2015 17:43
Til: mei-l at lists.uni-paderborn.de<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150325/c4a82a79/attachment.html>
More information about the mei-l
mailing list