<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 12, 2013 at 2:10 PM, Roland, Perry (pdr4h) <span dir="ltr"><<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>So, recording those details necessitates a <grpSym> child of <staffGrp> with its own attributes.  Those attributes can then be used to describe the symbol in greater detail or point to a precise rendition stored elsewhere.  <br>


</blockquote><div><br></div><div>I would keep the options as limited as possible. Micah is right: we should introduce a new symbol only if it translates to a different function, otherwise MEI should not bother: we are not doing typesetting (even while we acknowledge it as a 4th, hovering, dimension).<br>


</div><div><br></div><div>Wouldn't it be best having other standards pointing at a semantic MEI elements to provide a rendition, rather than adding a pointing mechanisms from MEI?</div><div><br></div><div>Example</div>

<div>
MEI: these staves are grouped. This group has and id "grp1"</div><div>Other system: the class "stave brackets" has to be rendered according to this routine. Apply it to MEI element #grp1. Also, #grp1 is a special case, so tweak this parameter a bit.</div>


<div><br></div><div>I feel strongly that MEI ought to be fully agnostic of the "other system" in the example.</div><div><br></div><div>Raf</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div><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>
</div><a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a> (w)<br>
<div>pdr4h (at) virginia (dot) edu<br>
________________________________________<br>
</div>From: mei-l [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>] on behalf of Byrd,  Donald A. [<a href="mailto:donbyrd@indiana.edu" target="_blank">donbyrd@indiana.edu</a>]<br>


Sent: Thursday, December 12, 2013 1:21 PM<br>
To: <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<div><div>Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
<br>
Leaving aside nesting and details like thinness, as far as I know, the<br>
_only_ symbols ever used to connect staves or groups of staves in CWMN<br>
are (1) curly braces, (2) square brackets, and (3) a thin line -- the<br>
last being used only to connect all the staves of a system. If there<br>
are others, I'd love to see an example.<br>
<br>
--Don<br>
<br>
<br>
On Thu, 12 Dec 2013 12:51:53 +0000, Andrew Hankinson<br>
<<a href="mailto:andrew.hankinson@mail.mcgill.ca" target="_blank">andrew.hankinson@mail.mcgill.ca</a>> wrote:<br>
<br>
> Hi Zoltan,<br>
><br>
> There is no limit to the number of nested staff groups. However, if<br>
> you have more than four nested staff groups, each with its own<br>
> bracket style, your engraver should be fired! :)<br>
><br>
> @symbol is simply meant to indicate that there is a ?generic?<br>
> bracket, brace, or line present. This is to give a visual hint, but<br>
> not a visual definition, to any software parsing the MEI file. Do you<br>
> have any examples of connecting symbols that are not one of these?<br>
> (Beyond those previously discussed by Laurent?)<br>
><br>
> -Andrew<br>
><br>
> On Dec 12, 2013, at 4:30 AM, K?míves Zoltán<br>
> <<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a><mailto:<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>>> wrote:<br>
><br>
> Hi Perry,<br>
><br>
> It makes sense to separately encode the visual characteristics in a<br>
> child element, such as <grpSym>. Forgive me for my ignorance about<br>
> the existence of this element!<br>
><br>
> However, I contemplate the problem of having too few values for @symbol.<br>
><br>
> Consider the following statement: "there are N different symbols used<br>
> in the score that connect groups of staves". How would you encode the<br>
> staff groups if N>=4?<br>
><br>
> Thanks<br>
> Zoltan<br>
><br>
><br>
> 2013/12/11 Roland, Perry (pdr4h)<br>
> <<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a><mailto:<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>>><br>


><br>
> Hi Zoltan,<br>
><br>
><br>
><br>
> Some elements (but not <staffGrp>) already allow @altsym, which<br>
> contains a pointer to a <symbolDef> element that, in turn, contains<br>
> instructions on how to "draw" the symbol.  This area of the schema<br>
> has not been exercised much and could therefore use a lot of work.<br>
> However, I think <symbolDef> could be extended to contain SVG,<br>
> PostScript, etc.<br>
><br>
><br>
><br>
> Turning to how this would work with <staffGrp>, the @altsym attribute<br>
> doesn't actually belong on <staffGrp>.  It's the visual<br>
> characteristics of <grpSym> we're trying to capture, not those of<br>
> <staffGrp>.  I believe this is what Andrew's comment was intended to<br>
> mean.  So, instead of <staffGrp>, <grpSym>, which can be a child of<br>
> <staffGrp>, should bear @altsym, e.g.,<br>
><br>
><br>
><br>
> <staffGrp xml:id="P2" label="Piano" barthru="true"><br>
><br>
>  <grpSym symbol="brace" altsym="#myBrace"/><br>
><br>
>  <staffDef ...<br>
><br>
> </staffGrp><br>
><br>
><br>
><br>
> Although sometimes it can't be avoided, it's generally bad practice<br>
> to use attributes to describe other attributes.  The usual way to<br>
> handle this is to "promote" an attribute to element status and then<br>
> give it its own attributes.  That's what <grpSym> is doing.<br>
><br>
><br>
><br>
> The <grpSym> element, however, still has the @symbol attribute with<br>
> the same values as when it's used on <staffGrp>.  In effect,<br>
><br>
><br>
><br>
> <staffGrp symbol="brace"><br>
><br>
><br>
><br>
> is short-hand for<br>
><br>
><br>
><br>
> <staffGrp><grpSym symbol="brace"/>.<br>
><br>
><br>
><br>
> In other words, as in several places in MEI, it's possible to use<br>
> attributes for less-detail-oriented encodings (for example, when you<br>
> don't care what the brace looks like), but use elements when you do.<br>
><br>
><br>
><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 href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a><tel:<a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a>> (w)<br>
> pdr4h (at) virginia (dot) edu<br>
> ________________________________<br>
> From: mei-l<br>
> [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>>] on behalf of Zoltán<br>



> K?míves<br>
> [<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a><mailto:<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>>]<br>
> Sent: Wednesday, December 11, 2013 5:10 PM<br>
><br>
> To: Music Encoding Initiative<br>
> Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
><br>
> Hi Andrew,<br>
><br>
> The grouping of staves is captured by the staffGrp elements without<br>
> specifying @symbol. @symbol captures additional information. I talk<br>
> about this additional content.<br>
><br>
> Zoltan<br>
> ________________________________<br>
> From: Andrew Hankinson<mailto:<a href="mailto:andrew.hankinson@mail.mcgill.ca" target="_blank">andrew.hankinson@mail.mcgill.ca</a>><br>
> Sent: <a href="tel:2013.12.11.%2020" value="+12013121120" target="_blank">2013.12.11. 20</a>:45<br>
> To: Music Encoding Initiative<mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
> Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
><br>
> The intellectual content (?logical domain?) is the groups of staves,<br>
> not the symbol.<br>
><br>
> On Dec 11, 2013, at 2:06 PM, K?míves Zoltán<br>
> <<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a><mailto:<a href="mailto:zolaemil@gmail.com" target="_blank">zolaemil@gmail.com</a>>> wrote:<br>
><br>
> Hello,<br>
><br>
> Would you mind to read my crazy thoughts about this issue? I'm just<br>
> curious what you people think of my thinking.<br>
><br>
> I think the "intellectual content" in this case isn't so much how the<br>
> connecting symbols look, but the fact that the symbols are<br>
> *different*.<br>
><br>
> The current values of @symbol already bear some sort of graphical<br>
> information, I think. The problem arose now, because it seems that<br>
> the current set of values don't provide a *complete" classification<br>
> (that is, in some cases there's no value which describes the symbol's<br>
> graphical shape appropriately). But of course, it's impossible to<br>
> provide a complete classification without degrading the markup to SVG.<br>
><br>
> If we accept that the intellectual content is the *difference*<br>
> between the connecting symbols, then the proper separation of the<br>
> "intellectual content" from it's graphical representation would be to<br>
> use a set of values something like this:<br>
><br>
> "symbol1",<br>
> "symbol2",<br>
> "symbol3",<br>
> etc.<br>
><br>
> If one wanted to capture more info about their "look and feel", one<br>
> could use some pointing mechanism to point to a different element<br>
> that records the graphical info (possibly even pointing to an<br>
> external SVG...)<br>
><br>
> I know, it's a crazy abstraction. And it may be way too abstract<br>
> compared to its practical use, and we could be better off adding a<br>
> handful of carefully defined values.<br>
><br>
> Zoltan<br>
><br>
><br>
><br>
><br>
><br>
> 2013/12/11 Laurent Pugin<br>
> <<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a><mailto:<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>>><br>
> It seems to me that adding "bracketsq" as a possible value would be<br>
> an appropriate addition. I don't think this particular case should<br>
> necessary open up a discussion on what is just typesetting or not.<br>
><br>
> Laurent<br>
><br>
><br>
> On Wed, Dec 11, 2013 at 4:13 PM, Roland, Perry (pdr4h)<br>
> <<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a><mailto:<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>>><br>


> wrote:<br>
> Yes, caution is advised.<br>
><br>
><br>
> --<br>
> p.<br>
><br>
><br>
> __________________________<br>
> Perry Roland<br>
> Music Library<br>
> University of Virginia<br>
> P. O. Box 400175<br>
> Charlottesville, VA 22904<br>
> <a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a><tel:<a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a>> (w)<br>
> pdr4h (at) virginia (dot) edu<br>
> ________________________________________<br>
> From: mei-l<br>
> [mei-l-bounces+pdr4h=<a href="mailto:virginia.edu@lists.uni-paderborn.de" target="_blank">virginia.edu@lists.uni-paderborn.de</a><mailto:<a href="mailto:virginia.edu@lists.uni-paderborn.de" target="_blank">virginia.edu@lists.uni-paderborn.de</a>>] on behalf of Johannes<br>



> Kepper<br>
> [<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a><mailto:<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>>]<br>
> Sent: Wednesday, December 11, 2013 10:02 AM<br>
><br>
> To: Music Encoding Initiative<br>
> Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
><br>
> While there is certainly no harm in adding a well-defined set of<br>
> additional attribute values, the risk I see is that the distinction<br>
> between these values gets harder every time, eventually watering down<br>
> their expressiveness in terms of interchange. I'm not saying we're<br>
> reaching that point here, I'm just saying that we should be careful?<br>
><br>
><br>
><br>
> Am 11.12.2013 um 15:58 schrieb Roland, Perry (pdr4h)<br>
> <<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a><mailto:<a href="mailto:pdr4h@eservices.virginia.edu" target="_blank">pdr4h@eservices.virginia.edu</a>>>:<br>


><br>
>> The "land of music typesetting" is always nearby, not unlike a 4th<br>
>> dimension hovering around us and within us.  :-)   Intellectual<br>
>> content and presentation are always difficult to separate.  But try<br>
>> we must.<br>
>><br>
>> There are already issues in the tracker related to @symbol -- nos.<br>
>> 180 & 182.<br>
>><br>
>> From issue #180 -- "The top and bottom components of a bracket can<br>
>> be rendered as curved (similar to Unicode #x1D115) or straight<br>
>> (similar to Unicode #x0005B). The simplest method of dealing with<br>
>> this distinction is to add "bracketsq" (bracket square) to the<br>
>> values allowed by @symbol.  "bracket" will continue to be used for<br>
>> the usual, curved musical bracket. The documentation should be<br>
>> edited to make the distinction clear."<br>
>><br>
>> I won't attempt to reproduce #182 here, but it covers the selection<br>
>> of a value for @symbol that captures a line (often fairly wide) used<br>
>> to group systems instead of a brace or bracket.  There's an image in<br>
>> #182 that illustrates various grouping symbols.<br>
>><br>
>> Neither the so-called square bracket nor the<br>
>> wide-line-grouping-symbol can be encoded using @symbol="line" since<br>
>> that value is already reserved for the line connecting the staves at<br>
>> their left edge.  I'm partial to the value "rule", but I'm open to<br>
>> suggestions.<br>
>><br>
>> I see no harm in adding generic values like this to MEI because they<br>
>> are what I like to call "rendering hints" for the intellectual<br>
>> content -- in this case the staff group.  But obviously this<br>
>> mechanism is not optimal for capturing all the visual details of the<br>
>> symbol, such as line width, color, position, etc.  I am somewhat<br>
>> trepidatious about going too far down that road, at the end of which<br>
>> MEI becomes a re-definition of SVG.  :-)<br>
>><br>
>> Yes, there are still things to add to MEI.  And, yes, this is an<br>
>> opportunity to do so.  Now, if there were only more hours in the day<br>
>> ...<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 href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a><tel:<a href="tel:434-982-2702" value="+14349822702" target="_blank">434-982-2702</a>> (w)<br>
>> pdr4h (at) virginia (dot) edu<br>
>> ________________________________________<br>
>> From: mei-l<br>
>> [<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de" target="_blank">mei-l-bounces@lists.uni-paderborn.de</a>>] on behalf of Johannes<br>



>> Kepper<br>
>> [<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a><mailto:<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>>]<br>
>> Sent: Wednesday, December 11, 2013 8:47 AM<br>
>> To: Music Encoding Initiative<br>
>> Subject: Re: [MEI-L] Thin brackets in orchestral scores<br>
>><br>
>> The reason why I feel slightly uneasy with this all is that it seems<br>
>> that we seem to enter the land of a music typesetting program here.<br>
>> In my ignorance about such details, I would probably encode that as<br>
>> a line, and ignore the fact that it is connected on both ends. In<br>
>> manuscripts, there would probably be no difference between this and<br>
>> either brackets or lines. But maybe you're right, and we should<br>
>> include the additional value. @Perry, do I remember correctly that<br>
>> you spotted some values in MusicXML not currently supported by MEI<br>
>> anyway? Is this an opportunity to revise them?<br>
>><br>
>> jo<br>
>><br>
>><br>
>><br>
>> Am 11.12.2013 um 14:39 schrieb Laurent Pugin<br>
>> <<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a><mailto:<a href="mailto:laurent@music.mcgill.ca" target="_blank">laurent@music.mcgill.ca</a>>>:<br>
>><br>
>>> You are right, I think it is missing.<br>
>>><br>
>>> There are actually a few of them in the examples, at least there is<br>
>>> this one (however with no representation in the encoding)<br>
>>> <a href="http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf" target="_blank">http://www.music-encoding.org/sampleCollection/encodings/Berlioz_Symphony_op25.pdf</a><br>
>>><br>
>>> Laurent<br>
>>><br>
>>><br>
>>><br>
>>> On Wed, Dec 11, 2013 at 1:21 PM, TW<br>
>>> <<a href="mailto:zupftom@googlemail.com" target="_blank">zupftom@googlemail.com</a><mailto:<a href="mailto:zupftom@googlemail.com" target="_blank">zupftom@googlemail.com</a>>> wrote:<br>
>>> Laurent's post made me wonder whether we might be missing an<br>
>>> additional value for staffGrp/@symbol for the thin bracket that is<br>
>>> used for sub-groups in orchestral scores[1].  Looking at some PDFs in<br>
>>> the sample collection I didn't see anything like that (I didn't look<br>
>>> through all of them).<br>
>>><br>
>>> Thomas<br>
>>><br>
>>><br>
>>> [1] see e.g. <a href="http://notengrafik.com/pdf/examples/Tchaikovsky.pdf" target="_blank">http://notengrafik.com/pdf/examples/Tchaikovsky.pdf</a><br>
>>><br>
>>> _______________________________________________<br>
>>> mei-l mailing list<br>
>>> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>


>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> mei-l mailing list<br>
>>> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>


>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
>><br>
>> Dr. Johannes Kepper<br>
>> BMBF-Projekt "Freischütz Digital"<br>
>><br>
>> Musikwiss. Seminar Detmold / Paderborn<br>
>> Gartenstraße 20<br>
>> 32756 Detmold<br>
>><br>
>> Tel. <a href="tel:%2B49%205231%20975669" value="+495231975669" target="_blank">+49 5231 975669</a><tel:%2B49%205231%20975669><br>
>> Mail: <a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a><mailto:<a href="mailto:kepper@edirom.de" target="_blank">kepper@edirom.de</a>><br>
>> _______________________________________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
>> <a 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 href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
> _______________________________________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><mailto:<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a>><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
><br>
><br>
<br>
<br>
<br>
--<br>
Donald Byrd<br>
Woodrow Wilson Indiana Teaching Fellow<br>
Adjunct Associate Professor of Informatics<br>
Visiting Scientist, Research Technologies<br>
Indiana University Bloomington<br>
<br>
<br>
_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a 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 href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a 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>