A very common analagous situation arises when a *piece* of a work is
quoted in such a way as to reproduce its original structure, e.g.
for purposes of commentary or rebuttal or abuse. At least, I think
it is analagous, since unless someone can offer a better option,
a quoted (say) preface, or perhaps only the head or opener of the
preface, often seems best treated with <q><text><front>..., since only
this really represents its role, but the rest of the text is not there (or is
perhaps only quoted in a later chapter). Since half the books in
the seventeenth century reproduce chunks of the other half in order
to hold them up to derision, this sort of thing is depressingly
commonplace:
<p>Mr. Smith cannot seem to tell the truth even in his epistle of
dedication,
<q><text><front><div1 type="dedication">
<head>A Humble Submission.</head>
<byline>By John Jones, Esq;</byline>
<opener><salute>To the Lord Bishops of England, greeting.</salute>
</opener>
<p>I have ever loved you, my lords</p>
</div1>
</front>
</text>
</q>
since his name is not Jones, he is anything but humble, and "love"
is a strange word for his implacable enmity, as of darkness for
the sun. And then he heaps deceit upon mendacity by signing himself,
<q><text><front><div1 type="dedication">
<closer>
<dateline>Brasenose College, Oxon., <date>31 June 1645 novo
stylo</date>
</dateline>
<signed>Your ever loyal servant, <name>J. Jones</name></signed>
</closer>
</div></front></text></q>
since everyone knows he is a Cambridge man! (and June has only
thirty days)</p>
We allow some things that canonical TEI doesn't, but even so, in such
circumstances, I have found myself driven to 'fake' things that aren't
there, e.g. an empty <p> to follow a quoted <head>, or an empty
<body> to follow a fragmentary <front>. In this case, <gap> doesn't
seem quite right. Or does it? What do you do?
pfs
--------------------------------------------------------------------
Paul Schaffner | [log in to unmask] | http://www.umich.edu/~pfs/
316-C Hatcher Library N, Univ. of Michigan, Ann Arbor MI 48109-1205
--------------------------------------------------------------------
On Tue, 30 Jan 2007, Lou Burnard wrote:
>
> Seems to me that the only pure and honest way of dealing with this situation
> is to do something like
>
> <front>fragmentary front elements</front>
> <body><gap><desc>Only the front matter survives</desc></gap>
> </body>
>
> If part of what you want to encode about a fragmentary title page is that it
> is in some sense "front matter" then putting it into the <body> simply isn't
> on. As Michael SpMcQ used to say "if there is a choice between an expedient
> lie and a difficult truth, always prefer truth". If it's "front matter",
> then there has to be something for it to be in front of -- and in a
> fragmentary manuscript, what it's in front of is a gap!
>
> Lou
>
>
>
>
> On Tue, 30 Jan 2007, Hilde Bøe wrote:
>
>> Thanks Brett,
>> this is clearly similar to our problem.
>> I think it would have helped (I would certainly have appreciated it) if
>> e.g. either the chapter on "Default Text Structure" or the chapter on
>> "Transcription of Primary Sources", could include a section on encoding
>> fragments, where the discussion included examples on fragments consisting
>> of only front and back matter. At present the TEI Guidelines does not
>> allow documents consisting of only <front> or <back> (and that's alright
>> with me), but moving front and back matter into the <body> isn't an easy
>> solution, as far as I can see.
>> All the best, Hilde
>>
>> On Tue, January 30, 2007 18:54, Brett Barney wrote:
>>>
>>>
>>> Hilde,
>>>
>>> On the Whitman project, we encountered a similar problem a couple of years
>>> back: We were encoding a manuscript title page with a list of possible
>>> titles. Unlike <castList>, <titlePage> can occur only within <back> or
>>> <front>, though. We ended up going down the first of the paths you chart,
>>> encoding the variant titles within <body> (in a <div> with a type
>>> attribute). Even though this was a few years back, I'm still not
>>> completely
>>> at ease with the issue: the first choice seems intuitively right from both
>>> a commonsense and a TEI-theory purist perspective, but the second choice
>>> has a pretty strong pragmatic appeal--it's easier to work with document
>>> components across a collection when they are marked up the same.
>>>
>>> Unfortunately, none of this does much to enlighten your particular
>>> conundrum, I'm afraid. But maybe it's useful as a related problem of
>>> manuscript encoding?
>>>
>>> Best regards,
>>> Brett Barney
>>> --------------------
>>> Walt Whitman Archive
>>> www.whitmanarchive.org
>>> (402) 472-4547
>>>
>>>
>>> Hilde Bøe <[log in to unmask]>
>>> Sent by: "TEI (Text Encoding Initiative) public discussion list"
>>> <[log in to unmask]>
>>> 01/30/2007 09:11 AM
>>> Please respond to
>>> [log in to unmask]
>>>
>>> To
>>> [log in to unmask]
>>> cc
>>>
>>> Subject
>>> <castList> and <set> in <front> and <body>
>>>
>>>
>>>
>>>
>>>
>>> In the TEI P4 guidelines ("Default Text Structure") the overall structure
>>> of a unitary text is defined as including front, body and back.
>>> We've had a discussion on wether a document can consist of <front> only
>>> (although the encoding isn't valid unless one adds <body> inside <text>).
>>> The background for the discussion is a manuscript containing only a cast
>>> list.
>>> Some of us argue that the cast list ought to be encoded in <body> because
>>> it is the body of the text it represents:
>>>
>>> <body>
>>> <castList>
>>> <castItem/>
>>> <castItem/>
>>> <castItem/>
>>> <castItem/>
>>> </castList>
>>> </body>
>>>
>>> Others argue that since the cast list is usually interpreted as front
>>> matter, it should always be encoded within <front>. Encoding it within
>>> <front> makes it necessary to add <body>/<div>/<p> to get valid encoding:
>>>
>>> <front>
>>> <castList>
>>> <castItem/>
>>> <castItem/>
>>> <castItem/>
>>> <castItem/>
>>> </castList>
>>> </front>
>>> <body>
>>> <div>
>>> <p/>
>>> </div>
>>> </body>
>>>
>>> We would like to hear from others on the list who might have had similar
>>> problems. What have you done?
>>>
>>> Henrik Ibsen's cast lists nearly always include settings, and so does the
>>> one in the manuscript mentioned above. Alongside the choice between
>>> encoding <castList> within <front> or <body>, we have encountered a
>>> problem concerning the setting. Encoding a cast list in <front> lets the
>>> encoder use <set> for the setting (see 10.1.1 The Set Element in 10 Base
>>> Tag Set for Drama):
>>>
>>> <front>
>>> <castList>
>>> <castItem/>
>>> </castList>
>>> <set>
>>> <p/>
>>> </set>
>>> </front>
>>>
>>> <castList> can go nearly everywhere: <front>, <body>, all kinds of <div>s,
>>> <back> and so on. <set> on the other side is only allowed in <front> and
>>> <back>. Thus we can't use <set> when encoding the <castList> in <body>.
>>> <performance> is defined as "a section of front or back matter describing
>>> how a dramatic piece is to be performed in general", and could thus
>>> include the setting, had it not been that <performance> also is only
>>> allowed in <front> and <back>.
>>> We're therefore, it seems, left with the choice between <stage> and <p>,
>>> but neither of them seem to be more than an emergency solution since we
>>> can't use <set> (preferably) or <performance>.
>>> Our question is thus: what's the reason for this difference? If you can
>>> have a cast list in the body of a text (as some of us believe we have in
>>> one of Ibsen's manuscripts), why can't you have a setting as well? Are we
>>> forced to encode the setting in <back>?
>>>
>>> <body>
>>> <castList>
>>> <castItem/>
>>> <castItem/>
>>> <castItem/>
>>> <castItem/>
>>> </castList>
>>> </body>
>>> <back>
>>> <set>
>>> <p/>
>>> </set>
>>> </back>
>>>
>>> We are using P4 and are therefore not familiar with P5. Is the encoding of
>>> cast lists and settings changed in P5?
>>>
>>> On behalf of Henrik Ibsen's Writings, Hilde Bøe
>>>
>>> --
>>> Hilde Bøe
>>> Ass. Editor
>>> [log in to unmask]
>>> Henrik Ibsens skrifter, Postboks 1166 Blindern, 0316 OSLO
>>> Tlf. +47 228 591 52/fax +47 228 59 169
>>> URL: http://www.ibsen.uio.no/
>>>
>