Handling recensions of a single document

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Handling recensions of a single document

Ian Scott
Hi. This is my first post on TEI-L, and let me say thanks in advance for any help. I'm involved with a project creating and publishing critical editions of ancient non-canonical Jewish literature. We are migrating from a custom XML schema to TEI and finding that generally our markup needs are met very well. But I'm unsure about about how to handle one feature of our documents.

For a given document we will often have multiple ancient language traditions (Greek, Aramaic, Ethiopic, Syriac, etc.). We want to encode all of these various traditions together in one document, recording textual variants separately for each language. In our custom schema we had each document in a root <book/> entity, which contained multiple <version/> entities. The closest to this structure I've found in the TEI guidelines is using <teiCorpus/> as our root entity and encoding each language tradition in its own <TEI/> sub-entity. But I'm not sure whether this is an abuse of the <teiCorpus/> structure.

We also need to encode one or more modern translations alongside the ancient textual evidence. It seems like we could simply add these as further <TEI/> sub-entities in a corpus structure. But, again, I'm not sure whether this is "legit." We want to do things in as canonical a way as possible, partly so that we can share any tools we develop.

Thanks,

Ian

Ian W. Scott
Associate Professor of New Testament
Tyndale Seminary, Toronto, Canada
Paul's Way of Knowing: Story Experience and the Spirit (Baker Academic [Mohr Siebeck], 2006)
The Online Critical Pseudepigrapha (SBL, 2006-; pseudepigrapha.org)
Sent from Mailspring, the best free email app for work
Reply | Threaded
Open this post in threaded view
|

Re: Handling recensions of a single document

Syd Bauman-10
Welcome aboard, professor Scott!

Personally, I like to think the definition of "corpus" is very loose.
E.g., in one project we have hundreds of pages that were sufficiently
damaged that re-constructing the correct page order is only partially
possible. Thus I think of this collection as a "corpus" of pages,
rather than a monograph. Once encoded, each TEI document will
represent a single leaf (recto and verso), complete with metadata for
that page. The various possible page orders will each be represented
by a <teiCorpus> which will XInclude the pages (<TEI> documents) in
its own order.

While probably not what the designers of the <teiCorpus> element had
in mind, it seems to fit the formal definition:

  contains the whole of a TEI encoded corpus, comprising a single
  corpus header and one or more TEI elements ...


So my instinct is to think this is not an abuse of the <teiCorpus>
structure, but you should make sure to document the heck out of what
you're doing.


> Hi. This is my first post on TEI-L, and let me say thanks in
> advance for any help. I'm involved with a project creating and
> publishing critical editions of ancient non-canonical Jewish
> literature. We are migrating from a custom XML schema to TEI and
> finding that generally our markup needs are met very well. But I'm
> unsure about about how to handle one feature of our documents.
>
> For a given document we will often have multiple ancient language
> traditions (Greek, Aramaic, Ethiopic, Syriac, etc.). We want to
> encode all of these various traditions together in one document,
> recording textual variants separately for each language. In our
> custom schema we had each document in a root <book/> entity, which
> contained multiple <version/> entities. The closest to this
> structure I've found in the TEI guidelines is using <teiCorpus/> as
> our root entity and encoding each language tradition in its own
> <TEI/> sub-entity. But I'm not sure whether this is an abuse of the
> <teiCorpus/> structure. We also need to encode one or more modern
> translations alongside the ancient textual evidence. It seems like
> we could simply add these as further <TEI/> sub-entities in a
> corpus structure. But, again, I'm not sure whether this is "legit."
> We want to do things in as canonical a way as possible, partly so
> that we can share any tools we develop.