[MEI-L] Antw.: More "precise" <app>s

Thu Jul 26 09:00:13 CEST 2012

Hi Johannes,
thanks for elaborating. I am with you for most of it, although I don't 
see why @corresp should not be used? It's supposed to be used to point 
to elements corresponding to the current one in a "generic fashion" 
(whatever that be). Although from the "analytical" domain, I did not 
understand att.common.anl to be exclusively for music analysis (correct 
me if I'm wrong). I think analysis starts with examination of the 
subject matter.
If I understood Thomas' original intention right (@Thomas please correct 
me), the idea was that on an early stage of encoding one might just like 
to mark correlation of two <app>s, then use a script to generate an 
apparatus, that would already have the correct @plist on its <annot>s. 
And in this case (having no other variants in this percise spot), the 
result should not be two <annot>s but a single one having measures one 
and two from two sources in its @plist.
Let's say the phenomenon one would like to point out was a displacement 
of a line of notes in one staff (more or less the first note being wron, 
the rest just consecutive faults) it is good to indicate the connection 
straight away when encoding like Thomas did in his second version.

For a solution:
Although it is not possible to mark the correspondence directly on the 
<app> (I think this is no problem) the attributes we were talking about 
(@pre, @next, @corresp, and many more) together with @source (@Andrew: 
thx for pointing to it in the first place) can be used on <lem> or 
<rdg>. Which is even more accurate than putting it on the <app> as it is 
the readings from on source that correspond, not the apparatus in whole, 
which might contain even more <rdg>s unconnected to that very 
phenomenon. In the end you should be able to do what you intendended in 
the first place, @Thomas.
Anyway I'd be very curious how the script might figure out the kind of 
correspondence and details of the <annot> to generate.
In the end, best option might be to straight away put an <annot> (Go 
@Perry, go!)  into (one of?) the <rdg>s with it's @plist pointing to the 
corresponding <rdg>s. Your scipt could then check for preexisting 
<annot>s deciding what to do whith <app>s/<rdg>s containing one or not.

I think solutions for encoding the problem in general might be there in 
the firsthand (@Johannes: with slight possibilities of improvement), 
when thinking of intelligently machine processable connections the 
problem seems to have another scope in means of quantificating and 
qualificating the intellectual aspects.

Have fun!
Benni

Benjamin Wolff Bohl

***********************************************************
Edirom - Projekt "Digitale Musikedition"
Musikwissenschaftliches Seminar Detmold/Paderborn
Gartenstraße 20
D – 32756 Detmold

Tel. +49 (0) 5231 / 975-669
Fax: +49 (0) 5231 / 975-668

http://www.edirom.de
***********************************************************

Am 24.07.2012 22:35, schrieb TW:
> Hi Johannes,
>
> thanks for your elaboration, this is all very well reasoned.  Using
> <annot> with a specific @type and @plist indeed seems like a good
> intermediary solution that can later be migrated to a proper solution.
>
> If such a proper solution would be able to group <app>s in a way that
> makes clear they are to be understood as a single logical <app>
> containing a continuous strand of events (like @prev and @next would),
> then we could close issue 88 as WontFix and supersede it by a new
> issue.  If nobody objects against this, I'll formulate such a new
> issue.
>
> Thomas
>
>
> 2012/7/24 Johannes Kepper <kepper at edirom.de>:
>> Hi all,
>>
>> as others have argued before, I don't like @next / @prev on <app>. It seems like there is no order of differences between sources. There is only a list of differences, which might be ordered following some criteria, but there is no natural order of variants. Using @next to indicate that a separate <app> deals with the _same_ situation seems absolutely awkward. @sameas would require an inconsistent usage, as Thomas already pointed out. @corresp is a generic attribute that should be left open for analytical purposes. If we give it a specific meaning on <app>, we're adding another exception to MEI (the otherwise generic @label has a specific meaning on <staffDef> already…).
>>
>> For me, this situation is another argument to a feature request I've been talking about quite a while. In my opinion, MEI will need a generic <grp> (group) element to address issues like this. This new element would have a @plist to point to a set of other elements which are to be regarded as one conceptual unit for some reason. A hint to this reason could be provided using @type. More specific variations of this element could be used for specific purposes: A <damageGrp> would point to <damage> elements which may spread across all levels of hierarchy etc. TEI uses *Span elements for this (<addSpan>), but TEI normally relies on a linear encoding of a base text, which is just interrupted by additional, "strippable" markup. A similar solution seems not possible for MEI.
>>
>> Perry has often argued that <annot> does exactly this: It allows to group a set of other elements using @plist, and to provide additional information about this group using text inside the <annot>. This is definitely an option, and works out of the box with the current schema. However, I think this approach is too generic, especially since it encourages the use of <annot> for each and everything in MEI. Maybe I'm not convinced because <annot> has a very specific meaning for me (which might lead to a feature request for <annotStruct> in the future), but I would like to see a more specific solution for problems like this. Otherwise we would recommend the use of extremely powerful elements. In my eyes, doing so would significantly increase the risk of different encoding styles for the same problem, leading to incompatibility etc.
>>
>> However, I don't see all this for the upcoming release. The problem is definitely more fundamental than just a missing connection between related <app>s, and I would like to avoid rushing into a quick solution too hastily. I would suggest to not add anything to <app> right now, but instead to rely on the existing <annot> for the moment (yes, I still remember my arguments…). This is nothing we're able to cope with for the upcoming release, but it's definitely something we should discuss for the next release (scheduled for 2013). Until then, I'd prefer to live with the existing compromises instead of adding new ones (which we'd have to clean up later…).
>>
>> Just my two cents,
>> Johannes
>>
>>
>>
>>
>>
>> Am 23.07.2012 um 13:14 schrieb TW:
>>
>>> 2012/7/23 Benjamin W. Bohl <bohl at edirom.de>:
>>>> Hi evbdy!
>>>> Discussing the lacking possibility to aggregate multiple app elements by
>>>> means of an attribute, which could be very handy indeed, I'd like to put
>>>> into consideration that @prev and @next imply an order. This might exactly
>>>> be what One is looking for, especially when thinking of genetic editions,
>>>> but something like @corresp might be more applicable in other situations.
>>>>
>>> @corresp would be covered by my suggestion to allow att.common.anl on
>>> <app> and <choice>.  However, @corresp always felt a bit vague to me.
>>> I guess it could legitimately be used to point to an independent <app>
>>> element, meaning something like "Look, this is the same *kind* of
>>> difference" rather than "This belongs to one virtual entity that has
>>> been split because we can't break the hierarchy".  @prev and @next are
>>> a bit more definite, implying a "user-defined collection".
>>>
>>> @sameas (also in att.common.anl) "sounds" like the most precise way of
>>> saying everything belongs to the same logical <app>, but I see that
>>> this meaning would be inconsistent with other uses of @sameas.
>>>
>>> Other options I can think of:
>>> - Having @plist on a "master" <app>, pointing to the subordinate
>>> <app>s.  This is very clear, but it's rather arbitrary what becomes
>>> the master <app>.  At first sight, a subordinate <app> can not be
>>> distinguished from a standalone <app>.
>>> - Some kind of stand-off markup?
>>>
>>> In any case, I think having att.common.anl would already be a really
>>> useful improvement.
>>>
>>> Thomas
>>>
>>> _______________________________________________
>>> 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