Torsten,
Thank you.  Sorry for the delayed response, but I wanted time to
digest your comments.

> this seems important to me: I think it might be better not to store the
> information you collect *by folium* but by *kind of information*, using
> the elements TEI offers.
>
> textual description = msContens/msItem
> physical description = descendants of physDesc
> decoration = physDesc/decoDesc/decoNote, etc.
>
> Each of these elements may contain a <locus> element which refers to the
> folium *itself*.

I had assumed there was a need to give each imaged part of an MS its
own element, an element that was distinct from a graphic or surface;
so that if, for example, you removed the references to all the images,
you'd still have an independent list of the manuscript's components.

I did not recognize that this list depends on the images and may have
little meaning without them.  For example, we have "Inside Upper
Bounding Board" and "Inside Upper Bounding Board flap open."  Clearly,
these are not manuscript components; they're images.

Even looking at folios, I don't think that the model I was proposing
is that useful.  Following Lou's suggestion, I was thinking of doing
something like the following.

...
<div n="1a" xml:id="..." />
<div n="1b" xml:id="..." />
...

As far as I can tell this method adds only @xml:id.  And while the ID
is useful for making references, locus will work fine for identifying
folios and other objects within the content type.

> Via identity of any two attributes (<locus from="1a"> = <graphic
> n="1a">) you represent the connection between the <locus> and the
> <graphic/surface> elements. For sure, the linking making use of @xml:id
> is even stronger but has some limitation according to the rules how
> xml:ids have to be built.

I think this method, linking locus to graphic by attribute, would be
sufficient.  Though I do like the idea of using @xml:id, as I've said,
we can do without it.

>
> Why would you want to organize it folio-wise, especially as you are not
> working on a representation of the collation? (OT: I am thinking about a

We simply want to be able to present the imaged manuscript components
in order and to communicate that order.  The facsimile elements will
allow us to do that.

>
> If you think your cataloguer is not familiar enough with the TEI, you
> might have a look at a template I prepared for manuscript descriptions
> done by our cataloguers (who btw haven't been familiar with TEI -and
> XML- either):
>
> http://www.hab.de/bibliothek/wdb/master/mss/template.xml
> (It has some "local" components, like our version of the schema, a local
> stylesheet for publication and some other stuff you can identfiy easily.)

Thank you for the sample.  We have built our tool, but something like
this will come in handy for a more technically capable group of users.

>
> You are right, I think TEI is lacking here something, but even you
> proposal using @prev/@next will not do the trick all alone considering
> you might want to show your descriptions as well in systems that offer
> both islamic (i.e. rtl) and "western" (i.e. ltr) manuscripts.

I've just started thinking about this, but I don't know what changes
would need to be made to the TEI to handle different manuscript
directions.  Would it suffice to merely mark a manuscript as running
RTL or LTR?

Thanks, again, to all of you for your comments and suggestions.

Best,
Doug