Hilde Bøe wrote:
> you disagree with our definition of information
> about witnesses as metadata.
I don't actually. In the sort of situation you describe it undoubtedly is
metadata and seems a prime candidate for documenting in the Source
Description. I was trying to illustrate, in response to your query about why
such material isn't universally consigned to the TeiHeader, that the GL's
have also to cover situations where witness information isn't metadata from
the encoder's frame of reference.
And in response to your further point about the apparent redundancy of a
<witlist> in a <text> where the witnesses had been detailed in a Source
Description, I tried to sketch an analysis that might point to the
incorporation of a <witlist> within a <text> even in such a scenario as
yours. Some degree of information content duplication between material in
the teiHeader and the <text> is quite common in other circumstances as well,
for example where a detailed title page from a print edition is
diplomatically encoded in the front matter. That doesn't eliminate the
justification, in a given encoding scheme, for the presence of both
> You would still have to modify the dtd though, as the Guidelines
> does not allow <witList> directly in <front> (or <back>).
As far as I can see, the only place the GL's actually specifically suggest
for a <witlist> is in the <front>: (P4. 188.8.131.52 :" In the front matter of
the edition, a list of all witnesses may be given if desired, in the form of
a witness list, held within a <witList> element"), though they don't exclude
its location elsewhere.If you mean the *DTD* doesn't allow
<front><witlist></witlist> [more stuff] </front> then you're quite right,
but then why should it? It doesn't allow <front><p></p></front> either. The
answer is not to modify the DTD but to obey it. E.g.
<front><div><witlist></witlist> [ more stuff]</div></front>
> However, we do not think that putting the information about
> witnesses in the TEI header does mean that this information will
> be unavailable to the users of our edition.
Of course is doesn't, but again, who said it did? "Availability" is a
function of the processing application (which may be elaborate software or a
pair of spectacles on the end of a user's nose). The issues you raised were
about document analysis and its reflection in encoding, i.e. about how
certain items are best categorized and what implications that categorization
has for their location in the logical structure of the encoded instance.
There is one further point that impinges upon projects that encompass
multiple texts: the fact that a TEI.2 document can have only one teiHeader,
no matter how many texts it assembles. This could well complicate the
"witness list as metadata" approach, depending on how much divergence or
variation there is among the witness information for specific texts. There
are various ways around this, from wrapping multiple TEI.2s, each with its
own teiHeader, in a teiCorpus.2 that carries a global header, to elaborate
articulation of the contents of a single Source Description.