LISTSERV mailing list manager LISTSERV 16.5

Help for TEI-MS-SIG Archives


TEI-MS-SIG Archives

TEI-MS-SIG Archives


TEI-MS-SIG@LISTSERV.BROWN.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

TEI-MS-SIG Home

TEI-MS-SIG Home

TEI-MS-SIG  March 2004

TEI-MS-SIG March 2004

Subject:

Hello

From:

Tim Finney <[log in to unmask]>

Reply-To:

Tim Finney <[log in to unmask]>

Date:

Mon, 1 Mar 2004 13:34:54 +0800

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (76 lines)

Dear TEI-MS-SIG

Hello Everybody! (How many are here?)

I am trying to work out how to encode papyrus manuscripts using TEI.
This is part of the Pinax project which seeks to put the Oxyrhynchus
Papyri online (see http://purl.org/pinax).

So far I have created a skeleton that has the usual header information
and a body that follows what the EpiDoc people did: having divs for the
editor's introduction, a translation and a bibliography. But now I have
entered a slough of despond with respect to representing the text of a
papyrus itself.

I would like to include in the basic architecture the ability to
reference parallels. Eventually, I want to be able to compare every
instance of a canonical work. E.g., there might be ten MSS of some
chapter of a biblical text that I want to look at all at once. It seems
to me that in order to do this, I need to incorporate a means to
consistently name parts of MSS that refer to the same canonical
reference (e.g. Matt 5:9). This is where I slipped into the slough.

It is the old competing hierarchies problem, aggravated by a desire to
have a pragmatic encoding specification that can be used by those whose
mother tongue is not TEI.

The competing hierarchies problem is this. The manuscripts are encoded
as lines of text from a column of a roll or from a folio of a codex.
Typically, the text is taken from a printed edition that uses the Leiden
conventions to represent things such as [gaps], d.o.u.b.t.f.u.l. text
and {editorial}changes. Papyrologists are so used to this way of
representing texts that I must be able to reproduce it using stylesheets
applied to the TEI XML version. The fundamental hierarchy is lines
within a column or folio. If the work that the text represents happens
to be recognisable then there is a need to be able to align its parts
with other instances of the same work. (E.g. other MSS of the Gospel of
Matthew.) What is more, I want to be able to look at what the scribe
wrote (let's call this the scribal view) or at an orthographically
levelled version (let's call this the substantive view). To complicate
matters, other scribes and correctors may have worked on the same MS.

In addition, I want a translation. This can be handled as a separate
div, although one could argue that it is just another view of the
canonical text, and might as well be included alongside the substantive
view.

Furthermore, I want to point to pictures of the MS.

My present thinking is that it is too hard to encode all of this into
one thing. (I have tried and it does not look pretty. Your average
encoder would immediately begin seeking another position.) Rather, I
think that it is necessary to separate the Leiden part (lines of text
with markup identifying gaps, doubtful letters, editorial activity) from
the canonical part (lines of normalised text arranged in a canonical
hierarchy). Accordingly, I need to have a div (which one might call
"conventional") for the Leiden part and another div (which one might
call "canonical") that uses the traditional canonical hierarchy (e.g.
book, chapter, verse). But there is a downside--everything in the
conventional div will need to be redone in the canonical div, including
the activity of scribes, correctors and modern editors.

What do you think? When thinking about this, I try to keep in mind that
the person who actually ends up doing the encoding may not be very good
at thinking in TEI. This poor blighter will need a straightforward way
of handling the greater part of what you might expect to encounter in a MS.

(I am purposely not using sic/corr and similar tags that require the
alternative to be placed into an attribute value. I prefer the
app/rdg approach which allows alternatives to contain markup. I
would like to see choice/option elements incorporated into P5, as they
will help to deal with multiple views of the text within one hierarchy.)

Best

Tim Finney

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.BROWN.EDU

CataList Email List Search Powered by the LISTSERV Email List Manager