[tei-council] PB reading reminder

Dot Porter dporter at uky.edu
Wed Aug 2 17:04:12 EDT 2006


Hi Council,

I've had a good read through the PB draft and I have several comments.
First, I should say that I'm not as comfortable with collation
formulae as I'd like to be (need to read Bowers Chapter 5 again) but
with that caveat here I go:

<collationFormula>

Generally, I think there are too many elements here. I could see
several of them becoming attributes instead.

Draft example:

            <gatheringRange signed="no">
                <start>A</start>
                <end>A</end>
                <leaves>4</leaves>
            </gatheringRange>

I would make this:

<gatheringRange signed="no" start="A" end="A" leaves="4"/>

Draft also has <added>, <cancelled>, and <missing> as possible child
elements of gatheringRange; perhaps these would be better as
recommended values for @type.

totalLeaves is described as a sibling of <gatherings>, and
signatureAlphabet is a child of <gatherings>; perhaps both of these
might be better as attributes of <gatherings> rather than as separate
elements.

The element <format> is in the example (child of <collation>) but
isn't described in the draft. It describes the format of the codex;
better as an attribute on <collation>?

I do need to read Bowers before commenting on signatureLeaves and anomSignature.

<pagination>: as above, I'd like to see some of these elements as
attributes instead, specifically the child elements of <pageRange>

Draft example:

            <pageRange type="front matter" numbered="no">
                <start>1</start>
                <end>8</end>
            </pageRange>

I'd make:

<pageRange type="front matter" numbered="no" start="1" end="8"/>

<pagination> is to list the ranges of consecutive numbering within the
codex; <foliation> (from MS Description) is "to indicate the scheme,
medium or location of folio, page, column, or line numbers written in
the manuscript, frequently including a statement about when and, if
known, by whom, the numbering was done" - basically, the evidence for
the pagination. Would it be possible (or wise) to combine these
somehow?

Along the same lines, the 1997 document by Lou, Richard Gartner, and
Peter Kidd (http://users.ox.ac.uk/~lou/wip/MS/msodd.htm#MSCOLL)
includes a method for describing the evidence for collation (physical
placement of signature markings/numbers). I'd like to see something
similar here.


<codexStructure>

I rather like this section as it is. There are quite a lot of idrefs,
but it seems to do a nice job of describing the relationships among
the different bits of the codex. One minor point - can <page> use
global @n instead of a new attribute @no?


"Milestone" tags for book-structure

I don't like the idea of replacing lb/, pb/, and cb/ with different
elements that serve essentially the same purpose. When we put in a
page break, we're saying that we're starting a new page. However, I
would like to have milestones for marking the start of new gatherings
and leaves.


Standoff markup using milestone tags

Linking markup in the text to markup in the header is a great idea,
but again I don't think we need a new attribute (@pageID) to do it. If
the linking module is included, @corresp is on lb/, pb/ and cb/.


Physical structure as the primary hierarchy

I'm not sure how I feel about these. It would be good to have a way to
encode physical structure beyond milestone tags, but I don't think
that regular, content containing tags are the way to go. These tags,
plus any basic textual markup (div, s, seg, even w) are bound to cause
serious overlapping and result in non-well-formed XML. I'd rather see,
as an alternative to (not a replacement for) lb/ pb/ and cb/,
something similar to the *Span elements (lineSpan, pageSpan,
colSpan?). Stepping back, just because a hierarchy is formed from
milestone elements (either stand-alone or linked pseudo-containers)
does not mean that it can't be primary in the encoding.

To sum up: too many elements that would be better as attributes, too
many recommended elements and attributes that are already covered by
existing ones. The basic idea is good, though, and I especially like
the bits on standoff markup and physical structure. Hope my comments
are useful.

Dot


On 8/1/06, Syd Bauman <Syd_Bauman at brown.edu> wrote:
> A reminder that each member of Council should read the physical
> bibliography document at
>   http://www.ucalgary.ca/~mmcgilli/PB/PBdraft%2014%20July.htm
> and now also at
>   http://www.tei-c.org/Activities/PB/draft-0714.html
> and post *some* comment of some sort.
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>


-- 
***************************************
Dot Porter, University of Kentucky
#####
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
#####
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu
***************************************



More information about the tei-council mailing list