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

[Johannes Kepper]

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