[MEI-L] Encoding staff positions

[Raffaele Viglianti]

Dear all,

The genetic encoding group within the Manuscript SIG of the TEI faced
similar issues. They came up with a new TEI module that takes a documentary
approach before a semantic one. It suggests to use the element ge:document
as an alternative to tei:text, the element that contains the semantic
tagging. They extend the model of tei:zone and introduce new elements like
ge:page (a non-empty element) and ge:line (non-empty), which simply marks a
line of text, regardless of its orientation. Attribute like @rotate and the
integration of SVG allow for the encoding of complex manuscript material.
Here is their current proposal:
http://www.tei-c.org/SIG/Manuscripts/genetic.html

<http://www.tei-c.org/SIG/Manuscripts/genetic.html>I think MEI could be
looking at using some of the concepts introduced here and possibly include
some of this TEI elements (possibly with their namespace) into a
document-oriented customization. Something like ge:line might not make sense
for MEI, though it might be used to model a mei:system.

Having a look at the work done by this group might shed some light on some
of the topics of this discussion.

Best wishes,
Raffaele

On Mon, Feb 7, 2011 at 8:52 PM, Johannes Kepper <kepper at edirom.de> wrote:

> Perry,
>
> >
> > - <zone> has no type attribute, but it already has @n, which can be used
> for the same effect.
> >
>
> I think a @type is something different than @n. Using @n as replacement for
> a missing @type seems to be "attribute abuse". Either there's a reason why
> there is no @type (in which case using @n is obviously wrong), or we should
> introduce it (in which case using @n is unnecessary). Btw: Anyone else who
> thinks that @n should be xs:string instead of xs:NMTOKEN? Think of <mdiv
> n="Allegro moderato"/>…
>
> > - I'm not sure what the advantage of nesting <zone> elements is and I'm
> afraid it may create more problems than it alleviates as users attempt to
> replicate the visual layout of the page using hierarchically-structured
> zones (better to leave the zones as a list where the coordinates of any
> zones may overlap).
> >
>
> You're probably right, although it might be interesting to group zones
> somehow. Question is if a parent-zone must be a bounding box for all
> child-zones, or maybe if it even has to have coordinates? But I'm just
> thinking loud, I'm not yet convinced of anything. Any other arguments,
> wishes, opinions out there?
>
> Johannes
> _______________________________________________
> 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/20110207/eed4ec02/attachment.htm>