Print

Print


Many thanks for this helpful solution, which, however, raises some further
questions in my mind, both about the particular case and the discussion of
lists and
tables in the Guidelines.

I'm not sure whether "witnesses" is the "label" in this and other cases of
the type

a}
b} X
c}

where the three braces in this email stand for a single brace. It seems to
me that there are three key-value pairs where the keys map to a single
value. This is quite common in the TCP texts. A good example is William
Penn's letter about laying out Philadelphia (Wing P1319, image 8), where
the names of property owners are mapped to street addresses.

It is odd that in the Guidelines the paradigmatic example of a "simple
two-column table"  is the "Œglossary listš, which should be marked by the
tag <list type="gloss">". This is a very ancient, but also quite
specialized and philological case. The 'label' in that case is a 'lemma'
in OED sense b) as "the heading or theme of a scholium, annotation, or
gloss."  If this ancient genre is the paradigm you have an explanation for
the
asymmetrical and intrinsically left-right structure of <list
type="gloss">.  The lemma or 'label' is always simple and short, while the
gloss or 'item' is likely to be longer and more complex.

So I'm not sure whether <list type="gloss"> is really a good way of
thinking about these very simple two-column tables.  From an analytical
perspective there is no difference between

a}
b}  X
c}

and

   {a
 X {b
   {c

The second represents key-value pairs in value-key form. The second may be
more common in cast lists.

I looked around in the Guidelines and kept in mind the recent thread about
introductory materials.  The Guidelines do not say a whole lot about the
theory and practice of representing textual phenomena as lists or tables.
The report card on Ernest Pontifex is given in <list type="gloss"> form in
Section 3.7 and as a table in Section 14.1, with a brief comment on the
differences. A newcomer would probably benefit from a fuller discussions
of the 'when', 'why', and 'how' of choosing between tables and lists for
representing phenomena that could be done either way.  And tables of
content might be worth a section in their own right with special emphasis
on problems in older books.

From a newcomer's perspective, and I suspect not only from a newcomer's
perspective, it would also be extraordinarily helpful in a future version
of the Guidelines to show page images of the examples.
 
 


On 8/28/11 7:03 AM, "Lou Burnard" <[log in to unmask]> wrote:

>Several interesting points here...
>
>Firstly,  surely this is the wrong way round? If we're doing functional
>markup, then the word "Witnesses" is a label, associated with an item,
>which contains a list, containing the two names.
>
>
><list type="gloss" rend="braced-right">
><item><list><item><name>Duncan Campbell</name>,</item>
><item><name>Iohn Thom</name>,</item></list></item>
><label>Witnesses.</label>
></list>
>
>BTW, <list rend="braced"> is a frequently discussed item on TEI-L; for
>some lively examples see
>http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind9710&L=TEI-L&P=R1315;
>http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0802&L=TEI-L&P=R8776;
> 
>http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0701&L=TEI-L&P=R8957
>and the magisterial
>http://www.lib.umich.edu/tcp/docs/dox/instruct2.html#braces)
>
>However:
>
>P5 requires that in the model for <list type="gloss">, the <label>
>should precede the <item>. There's no good reason for this (except that
>the content model is already quite a headache to parse) so you could
>plausibly raise that as a feature request. Or you could just accept that
>the sequence of the components in your encoding isn't identical to that
>in which one might expect the eye to read the page.
>
>P5 also requires that all model.divBot class elements (<signed> <closer>
>etc.)  should be phrase level elements, as should their contents. The
>former restriction is necessary to avoid ambiguous content models; the
>latter may be debatable.
>
>Fortunately, there's a much simpler way of encoding this! Just treat the
>whole thing as a list :
>
><list type="closer">
><item><signed>ARGYLE.</signed></item>
><item>
>   <list type="gloss" rend="braced-right">
>   <label>Witnesses.</label>
>   <item>
>     <list>
>       <item><name>Duncan Campbell</name>,</item>
>       <item><name>Iohn Thom</name>,</item>
>     </list>
>   </item>
>   </list>
></item>
></list>
>
>which is valid against TEI Lite. And, I contend, does at least as good a
>job of representing the structure and meaning of the page as any of the
>other options!
>
>
>On 28/08/11 05:02, Martin Mueller wrote:
>> I have been playing around with wrestling the EEBO dtd into a pure
>> version of P5. I'd be grateful for some help with the following
>> fragment, which is certainly /multum//in parvo. /Just in case the email
>> messes with the image below, you can read this post also at
>> http://ariadne.northwestern.edu/mmueller/label-list.htm.
>>
>> Actually, the original version of this post was rejected by the listserv
>> because it is configured to reject attachments of the type image/png.
>> This seems to me to be a mistake. When I look at an encoding problem in
>> a TEI text (typically a TCP text) and am puzzled, I typically find that
>> seeing the bit of the page image from which a particular encoding was
>> derived is a good way of "seeing" the problem. So I think the listserv
>> should encourage discussions where snippets of page images illuminate
>> the problem and point to a solution.
>>
>> //
>>
>> In Wing C1066, a 17th century legal case, there is a letter of attorney
>> by the Earl of Argyle, the end of which reads as follows:
>>
>> [here would have been the image that the listserv rejected and that you
>> can see at the URL above]
>>
>> A human reader has no trouble seeing that "ARGYLE" represents a
>> signature that is witnessed by men who sign their names.
>>
>> The TCP SGML representation of this goes as follows:
>>
>> <CLOSER>
>>
>> <SIGNED>ARGYLE.</SIGNED>
>>
>> <SIGNED>
>>
>> <LIST>
>>
>> <LABEL>
>>
>> <LIST>
>>
>> <ITEM>,</ITEM>
>>
>> <ITEM></ITEM>
>>
>> </LIST>
>>
>> </LABEL>
>>
>> <ITEM>Witnesses.</ITEM>
>>
>> </LIST>
>>
>> </SIGNED>
>>
>> </CLOSER>
>>
>> The following goes on here:
>>
>> 1.All the signatures are wrapped in a closer.
>>
>> 2.The Earl signs by himself.
>>
>> 3.The signatures of the witnesses are a list .
>>
>> 4.Because there is a many-to-one relation in the two names and the one
>> designation 'witnesses' the label-item relationship is complicated by
>> representing the two names as a list child of label.
>>
>> It all makes sense but makes you marvel at the ways in which human
>> readers make sense of the sparse symbols on the printed page.
>>
>> It turns out to be surprisingly difficult to model these relationships
>> in P5. If you don't like the EEBO label/list option (and I'm not sure I
>> do) you could use a table structure with a @rows attribute, as in
>>
>> <table>
>>
>> <row>
>>
>> <cell>Duncan Campbell,</cell><cell rows="2">Witnesses</cell>
>>
>> </row>
>>
>> <row>
>>
>> <cell>John Thom,</cell>
>>
>> </row>
>>
>> </table>
>>
>> But you can't put that either inside or after <closer>. The closest I
>> can come in P5 is something like
>>
>> <ab type="signed">Argyle</ab>
>>
>> <ab type="signed">
>>
>> <table>
>>
>> <row><cell>Duncan Campbell,</cell><cell cols="2">Witnesses</cell></row>
>>
>> <row><cell>John Thom,</cell></row>
>>
>> </table>
>>
>> </ab>
>>
>> But I wouldn't say anything in favour of this except for the fact that
>> it is valid. It may be that more flexibility in structure and placement
>> of signatures is required to allow for the representation of what are
>> quite common phenomena in legal or official documents.
>>
>> The "list child of label" phenomenon occurs in other contexts in EEBO
>> texts. It is not very common (I count about 250 occurrences in 40 out of
>> 28,000 files, and I may be way off), but it responds to a real need. You
>> see it quite a bit in cast lists where several names are mapped to one
>> role description via braces, as in the example above. Is there a
>> preferred way of dealing with this in P5 ‹ preferable in a Pythonic or
>> Birnbaumian spirit of DOING THE SAME THING IN THE SAME WAY, as long as
>> it really is THESAME THING (more or less)?