Doug Reside wrote:
> So what if I'm using it essentially as a finding aid. In other words,
> I'm writing text descriptions and adding dates; there is no analog
> original for the text.
I would argue that the TEI isn't just about digital versions of
analog texts... it is also about born-digital texts. Your finding
aid, to me, is a perfectly valid text all of its very own. :-)
> However, I will be linking to mets records which
> in turn will point to digital surrogates of analog objects, each
> connected to the event I am describing. There is a many to many
> relationship between events and items. Should I just put the list in
> the TEXT tag, and list myself as both encoder and author in the header?
That is exactly what I would do. The teiHeader documents the
digital text. The digital text in this case is a born digital
object which will be used as a record and pivot between
relationships with other born digital documents in other formats.
Seems completely reasonable to me. I often use TEI as a
transitory format in the midst of a pipeline of conversion, but
even though ephemeral that doesn't stop those texts being any
less real or valid. (e.g. xquery an eXist database, return
results as a TEI file, XSLT transformation to xhtml for display.
Slightly less efficient than direct to xhtml, but allows exposing
the underlying data as TEI.) (Is this the modern ephemera or the
equivalent of a printer's forme?)
However, be aware that by choosing listEvent as a standalone
element you are predicating a certain interpretation or use of
the data. This is not a bad thing and is true whatever method you
choose. In this case, for example, you aren't embedding events
inside descriptions of places. (While it is a truism that events
happen at places (sometimes many places simultaneously), places
themselves also move and change...which are events in themselves.)
Dr James Cummings, Research Technologies Service
OUCS, University of Oxford