[MEI-L] Connection/relation of multiple parts
Raffaele Viglianti
raffaeleviglianti at gmail.com
Tue Oct 30 12:58:33 CET 2012
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, 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.
Nonetheless, @prev and @next may be a quick and perfectly valid solution to
this problem.
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/>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121030/40943841/attachment.html>
More information about the mei-l
mailing list