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

[Raffaele Viglianti]

Hi Johannes,

Thanks for these very insightful comments! I agree with your arguments for
a grouping element to help escape hierarchy (given that, one could imagine
a stand-off approach to apparatus entries that might be quite interesting
to work with).

Nonetheless, I still see value in having @next and @prev.

On Tue, Jul 24, 2012 at 10:30 AM, Johannes Kepper <kepper at edirom.de> wrote:


> I don't like @next / @prev on <app>. It seems like there is no order of
> differences between sources.


Is the order of sources defined at app level? The @source attribute on rdg
should allow you to list your rdgs in whatever order; information in the
header dictates the relevance of each source over another.


>  Using @next to indicate that a separate <app> deals with the _same_
> situation seems absolutely awkward.
>

Although I can see why using @corresp or @sameas would be wrong, I don't
see why using @next is awkward. @prev and @next don't indicate a sequence,
but indicate an aggregation, which is what Thomas needed in his example.


> 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. [...] 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.
>

This is true, and as I've said I like this idea. There still is value to
embedded markup, though, particularly for apparatus entries. Still, I can
see how it wouldn't work with damage, add, del, etc. in advanced manuscript
transcription.

Best,
Raffaele



>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120724/1b750574/attachment.html>