[MEI-L] Connection/relation of multiple parts

Tue Oct 30 15:48:06 CET 2012

Hi evbdy,

Am 30.10.2012 um 12:58 schrieb Raffaele Viglianti:

> Well, although I agree in principle, there can be substantial information in the header upon which the body depends. Think of source description and their essential role in making sense of @source attributes across the document,

This is true, although even without the resolution of the IDREFs in @source a proper logical tree following a certain source can be generated, as the corresponding source element only supplies meta information on the source, not on the actual music content in body.

> or rendition elements in TEI for @rend, etc. In this context, I don't see a problem with encoding the relations between parts in the header similarly to how one would encode the relations between sources.

Neither in the case of rendition elements you add information concerning the logical structure of the body, rather it is visualization/rendition info. The case with the mei:mdivs would be comparable to add a sort of TOC in the header which then would be used to bring "unordered" mei:part elements into the order of the intended output, being for example the complete violin part of a work. Applied to the TEI example that would imply a sort of stand-off TOC in to order your chapters (div elements) resp. sub-chapters?
Leading back to Daniels question:
>>> By the way, why is <mdiv> surrounding <scrore> or <parts>? Wouldn't it be much more intuitive, at least if you use <mdiv> as containers for movements together with parts, to switch this the other way round? 

This brings up an interesting question:
With a score-element-encoding you could "line up" all measures in document order and would become a perfectly ordered continuous score resembling the source. Whilst when encoding parts, a similar mechanism stacking all parts would lead to a score as well and not to part extracts resembling a collection of performance parts. But isn't the parts element intended for encoding such parts in the source? If so, I would support Daniel's idea of switching hierarchies in <parts> to part/mdiv/measure.

> I agree with Raffaele that <perfMedium> doesn't seem to be the right place. At least if you think from a document centric perspective and I would argue that having parts in an MEI encoding is most of the time because of a document centric approach (and I'm pretty sure some of you find examples against this argumentation ;-) ).
Using the already proposed @decls to point to the header, I don't understand why you would not use the children of perfMedium? The nested instrumentation/instrVoice elements could then provide a standardized label for the part and its staves.

> 
> Nonetheless, @prev and @next may be a quick and perfectly valid solution to this problem.

Seems plausible, quick and valid, although the presence of theses attributes should then be best practice MEI in case you have more than one mdiv element. When processing the MEI you nevertheless would need to check every (following::) part element for their IDs until you find the matching one, which could be nested deep inside other mdivs.

> 
> Best,
> Raffaele
> 
> On Tue, Oct 30, 2012 at 8:59 AM, Daniel Röwenstrunk <roewenstrunk at edirom.de> wrote:
> Hi,
> 
> from my point of view the header should be some kind of *meta* data to the data itself. In my understanding this means that the data (inside body) should be self-consistent, even if the header is missing. I thought that is way we have staffDef and scoreDef for example inside the data part of MEI.
> 
> I agree with Raffaele that <perfMedium> doesn't seem to be the right place. At least if you think from a document centric perspective and I would argue that having parts in an MEI encoding is most of the time because of a document centric approach (and I'm pretty sure some of you find examples against this argumentation ;-) ).
> 
> The idea of using @sameas (which is possible on <part>) doesn't convince me, either. The two Violin 1 <part> elements are not the same, the second is the continuation of the first, right? So maybe using @next and @prev are a better choice here. Comments on that?
> 
> Cheers, Daniel
> 
> 
> 
> Am 29.10.2012 um 22:12 schrieb Raffaele Viglianti <raffaeleviglianti at gmail.com>:
> 
>> Hello,
>> 
>> I agree with Johannes, the place for encodining this is in the header, using @decls to point back to the text. I struggle to find the right place were to do that though. To me perfMedium steps into a different domain, so I'm not sure about it.
>> 
>> This is a very interesting problem and I'm curious to read other suggestions.
>> 
>> Best,
>> Raffaele
>> 
>> On Monday, October 29, 2012, Johannes Kepper wrote:
>> Hi Daniel,
>> 
>> without access to the schema / guidelines, I'd suggest to describe the performing forces in the header (using <perfMedium>), and then use the @decls attribute to point there from each part / staffDef (or @data in the other direction). Probably not the most convenient way, but right now there is no @sameas or @corresp on staffDef…
>> 
>> Just my first idea, maybe others will come up with other / better suggestions. 
>> 
>> Best, Jo 
>> 
>> Am 29.10.2012 um 17:22 schrieb Daniel Röwenstrunk <roewenstrunk at edirom.de>:
>> 
>>> Hi all,
>>> 
>>> I'm looking for a good approach to describe the relationship between <part> elements in different movements. In my actual encoding of the piece (see a very simplified example below) the only possibility to guess the relationship between the Violin 1 in the first ("mdiv1_part1") and second ("mdiv2_part1") movement is by comparing their label attributes. And that is not really a thing I want to rely on when I programmatically read MEI files. 
>>> 
>>> Is there a better and/or more precise way of encoding the relationship?
>>> 
>>> 
>>> By the way, why is <mdiv> surrounding <scrore> or <parts>? Wouldn't it be much more intuitive, at least if you use <mdiv> as containers for movements together with parts, to switch this the other way round? 
>>> 
>>> Cheers and thanks,
>>> Daniel
>>> 
>>> 
>>> Encoding example:
>>> 
>>> <body>
>>>    <mdiv xml:id="mdiv1" label="Allegro">
>>>       <parts>
>>>          <part xml:id="mdiv1_part1" label="Violin 1">
>>>             …
>>>          </part>
>>>          <part xml:id="mdiv1_part2" label="Violin 2">
>>>             …
>>>          </part>
>>>       </parts>
>>>    </mdiv>
>>>    <mdiv xml:id="mdiv2" label="Allegretto">
>>>       <parts>
>>>          <part xml:id="mdiv2_part1" label="Violin 1">
>>>             …
>>>          </part>
>>>          <part xml:id="mdiv2_part2" label="Violin 2">
>>>             …
>>>          </part>
>>>       </parts>
>>>    </mdiv>
>>> </body>
>>> 
>>> 
>>> 
>>> --
>>> Dipl. Wirt. Inf. Daniel Röwenstrunk
>>> Project manager
>>> BMBF-Project "Freischütz Digital"
>>> 
>>> Musikwiss. Seminar Detmold/Paderborn
>>> Gartenstr. 20
>>> D-32756 Detmold
>>> 
>>> Tel.: +49 5231 975665
>>> Mail: roewenstrunk at edirom.de
>>> URL: http://www.freischuetz-digital.de
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
> 
> 
> _______________________________________________
> 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/20121030/cb76f420/attachment.html>