<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Eleanor, Perry and Raffaele,<br>
thanks a lot for this helpful discussion (or the beginning of a
discussion for release 2013/05 ?)<br>
<quote resp="Perry">"Enough to think about for the
weekend?"</quote><br>
Perry, you see that this was for more than one weekend <span
class="moz-smiley-s3"><span> ;-) </span></span>, and please
excuse the late answer. <br>
<br>
1. First I think that for the first we can live with your proposal
of using <choice> together with orig/reg or abbr/expan.<br>
For a longer term we should, maybe, prefer to have your
<ggsapih> ("go-get-something-and-put-it-here") or something
generic - not <copyOf> but something in Raffaele's sense:
<goCopy> (go and copy the measure below).<br>
Concerning <reg> and <expan> I normally understand them
as giving the "resolved abbreviation" in the form a "today's user"
is used to, e.g. a fully expanded form of a half note with a stroke
through the stem (as a mark for repetition of four eighth-notes).
But in the context of the manuscript "//" as a colla-parte-sign may
signal that you "go and copy the measure below" and that measure may
consist of two half notes with strokes through the stem - and this
has nothing to do with expansion or regularization. Thus I think
that the solution is ok for the next release but not a fully
satisfying one?<br>
<br>
2. Concerning Raffaele's hint that the double lines // (or something
similar) have to be seen in conjunction with the "c.B." <quote
resp:"Raffaele">"if col Basso ... means 'play the current measure
at the Basso staff' ..., the same meaning will be repeated by // in
the following measure</quote> struck me at the first reading
as a totally convincing interpretation of the "//" signs. But
returning to the manuscript I begin to be a doubting Thomas again.
Please haave a lookt at:
<a class="moz-txt-link-freetext" href="http://digital.staatsbibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0064">http://digital.staatsbibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0064</a><br>
There you find "col Tenore" and "col Basso" (bottom-middle) and the
strokes // are beneath these words - so they are not a repetition
sign here. And differing from the measure-repeats in the last bars
of this page in violins and violas (staff 7-9 from top) we find the
next hints in the chorus staffs (no. 2-3 from bottom) as double
lines // crossing the bar line (that is continued on the next page).
And as a further motive we have the "unis:[ono] in line 5 from top
(middle)", again with a //-sign. (Besides: the // in b. 3/4 of the
flute - staff 1 from top - are a repetition sign for bars 1/2 on
this page) - so the "//" has very different meanings here, but
always have something to to with "repetion".<br>
In the case of "colla parte", "in 8va", "col Basso", "unisono" etc.
it is not necessary that this verbal "prescription" is explicit:
Look at:<br>
bibliothek-berlin.de/dms/werkansicht/?PPN=PPN65499935X&PHYSID=PHYS_0025&USE=800<br>
In the cello-staff there is only "//" without any "c.B." (and I
think that Eleanor hinted at the fact that this form is often to be
found with other composers - but you know that I am only acquainted
with this strange Weber.... <span class="moz-smiley-s6"><span> :-[
</span></span>). So we really have to be careful what we define in
the header as the symbols used combined with their "meaning". <br>
<br>
3. As soon as we connect "//" with any form of meaning we are
interpreting the signs (and behave as editors - even if we add "col
Basso" where we only find //). And Eleanor's examples show that in
many cases there is a lot of wiggle-room here! But if we continue
the work of encoding the manuscript of the Freischuetz-overture I
think we should differentiate at least between a <symboldef>
of "//" that denotes pure measure (or half-measure) repeats (and are
normally used quite strictly: as repetition signs in each measure or
at least on the bar-lines if meant for a 2-measure-unit) and those
which show a "freer distribution", but at least in Weber's case are
preferably used as sign "on a bar-line" for the
<goCopy>-mechanism?<br>
<br>
Nevertheless a generic element with the function of "go and bring
something from another bar here in this place" would really be of
some advantage!?<br>
<br>
I hope that this makes the discussion not too confusing - but that
seems to be my special part at the moment <span
class="moz-smiley-s3"><span> ;-) </span></span>.<br>
Best greetings,<br>
Joachim<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Am 03.09.11 18:56, schrieb Raffaele Viglianti:
<blockquote
cite="mid:CAMyHAnP+GNa+-UeoBTTCEcjLN2p22cBCvStMqTzuR2q_6J57NQ@mail.gmail.com"
type="cite">Hi Perry,
<div><br>
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
</div>
isn't "making more explicit" the meaning of something
exactly what correcting, regularizing and expanding do?
For instance, if I mark "P.R." as an abbreviation and
"Perry Roland" as its expansion, am I not making the
meaning of "P.R." more explicit?<br>
<br>
</blockquote>
<div><br>
</div>
<div>I think that in this case, the act of "making explicit"
is suggesting a textual replacement:</div>
<div>P.R. --> Perry Roland</div>
<div><br>
</div>
<div>and this is true for all the paired choices of
sic/corr, orig/reg, etc. This is an editorial intervention
that directly influences the symbols that make the text.</div>
<div><br>
</div>
<div>In the case of col Basso, the act of "making explicit"
is defining a function:</div>
<div>"col Basso" --> go and copy the measure below</div>
<div><br>
</div>
<div>This is why I don't think that there is any editorial
intervention here, it is a matter of explaining what this
symbol "is". (Let's set aside the fact that arguably, when
doing a transcription, everything is editorial
interpretation; even using <note>) </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
</div>
the words "col Basso" (or the wiggly line, whatever)
remain separate from the realization encoding. To do
otherwise, would wreak havoc upon the distinction between
events and control events that's built into MEI. Unless
someone WANTS to start over from scratch. :)<br>
</blockquote>
<div><br>
</div>
<div>Ok, I understand and agree, sorry if I jumped to
suggesting a new element too fast! :) Still, I think that
the direction "col Basso" itself is functioning as
a hypothetical "copyOf" element rather than its editorial
expansion. But if the direction and its function must be
kept separated to follow the event / control event
distinction, then fine. What I think should be evident
from the encoding, though, is that this falls out of
editorial interventions, and falls into the category of
saying what some text "is", which is what happens with a
lot of MEI elements (this is a note, this is a direction,
...).</div>
<div><br>
</div>
<div>Best,</div>
<div>Raffaele</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
BUT, what the content of <expan> or <reg>
should be is a different question. In the examples above
and in the examples in the TEI guidelines, the content is
explicitly stated; that is, every misspelling of the same
word carries the same regularization.<br>
<br>
For those situations where the regularization exists
elsewhere in the encoding, we could create a generic,
"go-get-something-and-put-it-here" element. I only
suggested the name "colla" as a discussion-starter. I
believe it probably needs a more generic name, perhaps
"copyOf", that would allow it to function in cases other
than just colla parte. Eleanor's point about references
occuring just about anywhere is correct, although there's
only so far we can go and maintain explicit markup.
Followed to the extreme, the markup becomes entirely
procedural, not a good thing. Already, the <copyOf>
element introduces the same problems @copyof, namely,
which parts of the target should actually be copied --
certainly not the target's @xml:id and probably not it's
@n either.<br>
<br>
For the time being, I'd prefer solutions such as those
above that use existing elements / attributes in order not
to delay the next release. We can take up the question of
a "copyOf" element and the philosophical issues related to
what a regularization "really" is later.<br>
<div class="im"><br>
--<br>
p.<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a moz-do-not-send="true" href="tel:434-982-2702"
value="+14349822702">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
<br>
<br>
<br>
</div>
From: <a moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>
[<a moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>]
on behalf of Raffaele Viglianti [<a moz-do-not-send="true"
href="mailto:raffaeleviglianti@gmail.com">raffaeleviglianti@gmail.com</a>]<br>
Sent: Saturday, September 03, 2011 6:58 AM<br>
To: Music Encoding Initiative<br>
Subject: Re: [MEI-L] Colla parte<br>
<div>
<div class="h5"><br>
<br>
Dear Joachim and all,<br>
<br>
<br>
Having had the opportunity to look at other parts of
der Freischuetz manuscript, I think one might look at
this situation in another way: the symbols // or
.//., etc. actually indicate to look back at the
previous measure.<br>
Also in the case that described, I am inclined to
think that // actually means a repetition of the
instruction col basso to be found in the previous
measure.<br>
<br>
<br>
Given this interpretation, it is sufficient to define
what "col Basso" does, and the repetition symbols will
just copy over the same meaning.<br>
Basically, if col Basso in this context means "play
the current measure at the Basso staff" (which is
different from "play the measure with xml:id='foo'"),
the same meaning will be repeated by // in the
following measure.<br>
<br>
<br>
To define what col Basso does, an element like the one
suggested by Perry might be useful. Perhaps <colla
target="#STAFFid">col Basso</colla> or
similar.<br>
<br>
<br>
Regarding <supplied>, I think we need to clarify
better its role and align it with TEI as much as
possible. Perry's use seems a bit incorrect to me,
because the element should be used to supply text that
cannot be read or is not there at all and should be.
In this case the symbol is there, the editor makes its
meaning explicit. An element like <colla> that
would somehow include the objections of the people at
the back of the room, might be sufficient to make
explicit the meaning of the symbol in question.<br>
<br>
<br>
Using sic / corr or orig / reg or abbr / expan seems a
bit odd to me as well, because it's not a matter of
replacing one (or many) symbol(s) with another (or
many others) for the purpose of correcting,
regularizing or expanding, but it's a matter of making
more explicit the meaning of a less-standard sign.<br>
<br>
<br>
Hope this helps!<br>
<br>
<br>
Raffaele<br>
<br>
<br>
On Fri, Sep 2, 2011 at 11:58 PM, Roland, Perry (pdr4h)
<<a moz-do-not-send="true"
href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>>
wrote:<br>
<br>
Hi Joachim,<br>
<br>
Let me re-state the issue to see if I understand it
correctly --<br>
<br>
1. Weber (is there any other composer worth talking
about?) draws some version of a slash-symbol-thing to
indicate that the current measure should be filled in
with material from another instrument.<br>
<br>
2. You want to record the original version (with the
slash symbol) and give its "expansion" (as it were)?<br>
<br>
First, are you sure this problem can't be resolved
using <orig> and <supplied> (or perhaps
<reg>)? For example, each measure of the flute
part might be encoded --<br>
<br>
<measure><br>
<staff n="1"><br>
<layer><br>
<choice><br>
<orig> <!-- some repetition sign(s)
here --> </orig><br>
<supplied> <!-- a copy of the content
of the vln. part --> </supplied><br>
</choice><br>
</layer><br>
</staff><br>
<dir staff="1" tstamp="1">colla parte
...</dir><br>
<!-- instead of the words there might be a
<line> --><br>
</measure><br>
<br>
This seems like a good solution to me because it is
explict.<br>
<br>
I'm using <supplied> because the actual
substitution doesn't take place in the score, there's
only an indication that it "ought" to happen. Actually
making it happen is up to the editor -- the human
being, not the software.<br>
<br>
Of course, what's missing is a link between the
<supplied> element and the words "colla ..." (or
a "wiggly" line), which I presume is in the flute
part). At present, the editorial intervention can only
be explained in the editorialDecl. But, if we put our
heads together, we might be able to think of another
method of linking these. (Perhaps with an
<annotation>, which has pointers to the
"participants"; that is, the <supplied> and
<dir> elements, and a type attribute value of
"collaparte"?)<br>
<br>
I don't know if you remember, but MEI originally had a
different definition for <mRpt>. It didn't
necessarily indicate the repetition of the preceding
measure, but rather the repetition *of any other
measure*, "repetition" being defined somewhat loosely,
of course. This definition went the way of the dodo
bird when the editorial elements (add, del, orig, reg,
etc.) were added since the attribute (don't remember
what it was called off the top of my head) pointing to
the source measure duplicated these editorial
elements' function.<br>
<br>
However, I recognize that there's currently no good
way of implementing a reference to content given
elsewhere in the document. So, perhaps we should
consider adding such a specialized element. In the
example above, the content of <supplied> would
be the <colla> (or some such name) element.<br>
<br>
<measure n="1"><br>
<staff><br>
<layer><br>
<choice><br>
<orig> <!-- some repetition sign(s)
here --> </orig><br>
<supplied> <colla/>
</supplied><br>
</choice><br>
</layer><br>
</staff><br>
</measure><br>
<br>
Of course, it would need an attribute pointing to the
content of the vln. part. In a way, this element
would be similar to <ref>, although <ref>
is intended for navigation, while <colla>
indicates "go get the content and put it here." This
is also not unlike internal parsed entities. This
element would also need to be related to the
<dir> or <line> elements. We could think
about using its generic corresp attribute or give it a
new, specialized attribute.<br>
<br>
(I can already hear some noises in the back of the
room about some attribute or attributes for describing
whatever transformation must be applied to the source,
such as "transposed up a 5th", "inverted and
retrograde", etc. I'm not ready to go there yet!
There be dragons!)<br>
<br>
It might also need a more generic name than "colla".
Then it could be used for other situations where
content given in one location needs to be referenced
in some other. Can't think of a good name off the top
of my head, too late in the day.<br>
<br>
Just in case someone asks, I don't think XInclude can
point to a location in the current document.<br>
<br>
Enough to think about for the weekend? :)<br>
<br>
--<br>
p.<br>
<br>
__________________________<br>
Perry Roland<br>
Music Library<br>
University of Virginia<br>
P. O. Box 400175<br>
Charlottesville, VA 22904<br>
<a moz-do-not-send="true" href="tel:434-982-2702"
value="+14349822702">434-982-2702</a> (w)<br>
pdr4h (at) virginia (dot) edu<br>
________________________________________<br>
From: <a moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>
[<a moz-do-not-send="true"
href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.uni-paderborn.de</a>]
on behalf of Joachim Veit [<a moz-do-not-send="true"
href="mailto:veit@weber-gesamtausgabe.de">veit@weber-gesamtausgabe.de</a>]<br>
Sent: Friday, September 02, 2011 3:43 PM<br>
To: <a moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
Subject: [MEI-L] Colla parte<br>
<br>
<br>
Dear MEI-L-Readers,<br>
<br>
when encoding manuscripts MEI has the possibility to
encode<br>
measure-repeats or half-measure-repeats which are
found in the original<br>
manuscripts in a form similar to: // or .//. (two
strokes through the<br>
barlines or something similar) with <mrpt> or
<halfmrpt>. This has<br>
always a clear reference to the bar (or half-bar)
before.<br>
<br>
The same symbols are used in manuscripts in
combination with the "col<br>
Basso" or other "colla-parte"-instructions.<br>
Again in Weber's Freischuetz-Overture (we never do
something other...)<br>
we have a contrabbasso with <staff n="16"> and
above this the<br>
violoncello with <staff n="15>. Weber notates
the contrabbasso in a<br>
normal way and in the cello-staff we find only "c. B."
(= bar 1) and<br>
afterwards // // // etc.<br>
For a modern edition we could label the layer of the
contrabbasso with<br>
an xml:id="2011" and put in the layer of staff 15:
<layer n="1"<br>
copyof="2011"/>.<br>
<br>
But in this case we want to encode the "original"
situation! So we first<br>
have to define in the scoredef:<br>
<scoredef>....<br>
<symboltable><br>
<symboldef xml:id="symCollaParte"/> <!-- here
we describe the symbol(s)<br>
Weber and others use in this case --><br>
</symboltable><br>
</scoredef><br>
<br>
and within our staff 15:<br>
<staff n="15"><br>
<layer n="1"><br>
<symbol ref="symCollaParte"/><br>
</layer><br>
</staff><br>
In this case the reference is not always clear: it
might go to the staff<br>
below (as in this case) or the staff above (if the
cello is written out<br>
and the cb-staff is pointing to the cello) or even
from a flute to the<br>
first violin 5 systems below. So there should be some
mechanism to make<br>
clear where the model is situated. And second: We
should have the<br>
possibility to use "c. B." (or something similar) as a
symbol-phrase<br>
(which at the same time "defines" the model) and for
the following bars<br>
simply use "//" (or something similar) (maybe even one
symbol for 2-3<br>
bars together??).<br>
Is this case already considered in the future
guidelines?<br>
<br>
Best greetings and a happy weekend,<br>
Joachim<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a moz-do-not-send="true"
href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l"
target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
_______________________________________________<br>
mei-l mailing list<br>
<a moz-do-not-send="true"
href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a moz-do-not-send="true"
href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l"
target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mei-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>
<a class="moz-txt-link-freetext" href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a>
</pre>
</blockquote>
<br>
</body>
</html>