[tei-council] bibliog doc
kevin.s.hawkins at ultraslavonic.info
Tue May 18 22:31:41 EDT 2010
Hi all, apologies for the delay in responding. Was in transit and am
Lou Burnard wrote:
> As relaxation from grappling with implementing the proposed ODD changes,
> I thought I'd work through the document on bibliographic issues which
> Kevin circulated earlier.
> I have three reactions so far (and some comments below) ...
> 1. Following the gloss list in "Notes for library cataloguers" I have now
> revised the proposed new text as follows:
[. . .]
> <!-- item>There is no place in a TEI header to
> specify main or added entries for the catalogue record.</item-->
> <!-- I dont understand what this means : could you give an example of
> the kind of info that the TEI header does not allow you to provide. -->
First, some background. Catalog records include both information
transcribed from the title page and official forms of names from an
authority file, allowing users to find all works by an author who
published under variants of their name.
Let's take this example:
The text that follows the slash ("edited, with an introduction and notes,
[. . .]") is what is transcribed from the title page. However, the
cataloger determined that the party most responsible for the content of
the work is a person whose official name is constructed as:
Shakespeare, William, 1564-1616.
even though this string of text almost certainly never appeared in the
original document, even on the title page. This is the "main entry".
Furthermore, the cataloger determined that two other parties were also
These are added entries. Both types of entries use names from the
In the TEI, however, it's not clear whether the content of <author>,
<editor>, and <respStmt> should contain the name as transcribed, the
official form of a name, or some combination (such as through use of
@key). Furthermore, if you want to indicate in your TEI header that a
certain <author> is the main entry according to cataloging rules and
another is an added entry, there's no given way to do this.
> 2. I revised the additional material proposed for the end of section
> 3.? as follows:
> <p>The most commonly used elements in the model.biblLike class are
> <gi>biblStruct</gi> and <gi>bibl</gi>. <gi>biblStruct</gi> will
> usually be easier to process mechanically than <gi>bibl</gi> because
> its structure is more constrained and predictable. It is suited to
> situations in which the objective is to represent bibliographic
> information for machine processing directly by other
> systems or after conversion to some other bibliographic markup formats
> such as BibTeXML or MODS. Punctuation delimiting the components of a
> print citation is not permitted directly within a <gi>biblStruct</gi>
> element; instead, the presence and order of child elements must be used to
> reconstruct the punctuation required by a particular style.
> <!--While <gi>biblStruct</gi> offers enough
> flexibility for encoding bibliographic references to simple print
> works, for many documents, especially electronic ones, it proves
> problematic.--> <!-- no problems presented -->
> <p>By contrast, <gi>bibl</gi> allows for considerable flexibility in
> that it can include both delimiting punctuation and unmarked-up text;
> and its constituents can also be ordered in any way. This makes it
> suitable for marking up bibliographies in existing documents, where it
> is considered important to preserve the form of references in the
> original document, while also distinguishing important pieces of
> information such as authors, dates, publishers, and so
> on. <gi>bibl</gi> may also be useful when encoding <soCalled>born
> digital</soCalled> documents which require use of a specific style
> guide when rendering the content <!-- why is this true of born digital
> dox in particular? -->; its flexibility makes it easier to provide all
> the information for a reference in the exact sequence required by the
> target rendering, including any necessary punctuation and linking
> words, rather than using an XSLT stylesheet or similar to reorder and
> punctuate the data. <!-- tough if you later want it in a different
> form for another rendering engine of course --> </p>
Lou wants a clearer rationale here.
Martin's done a good job of explaining his rationale, but let me try
stating this in different terms just in case it alleviates confusion over
Martin's use of "electronic" documents and "born-digital" ones.
I believe Martin envisions two approaches to encoding bibliographic
citations given in a source document:
a) You want to represent the source document as it is, even if it has
inconsistencies in it.
b) You want to impose structure on the citations to catch errors and allow
you to format the citations according to various style guides (MLA,
Chicago, APA, etc.) automatically by displaying the content of various
bibl/biblStruct/biblFull child elements in different orders. This is the
born-digital case in the second paragraph: you're creating a new TEI
document for which there's no print source to be represented.
If you're doing (a), you basically have to use <bibl>.
If you're doing (b), people are generally inclined to use biblStruct, but
Martin argues in this document (and at the symposium in Dublin) that it's
more practical to use bibl. As described in the first paragraph, he has
found that citations to electronic works are often quite complicated in
structure and that if you try to use biblStruct, it will be quite
difficult to format according to the rules of MLA, Chicago, APA, etc.
Martin, chime in if I got this wrong.
> <p> The third element in the model.biblLike class, <gi>biblFull</gi>,
> has a content model based on the <gi>fileDesc</gi> element of the TEI
> header. Both are based on the International Standard for Bibliographic
> Description (ISBD), which forms the basis of several national
> standards for bibliographic citations. The order of child elements in
> both <gi>biblFull</gi> and <gi>fileDesc</gi> corresponds to the order
> of bibliographic desription <soCalled>areas</soCalled> in ISBD with
> two minor exceptions. First, the <gi>extent</gi> element,
> corresponding to the physical description area in ISBD, appears just
> after the publication, production, distribution, etc. area in ISBD,
> not before it as in TEI. Second, <gi>biblFull</gi> and
> <gi>fileDesc</gi> use the child element <gi>publicationStmt</gi> to
> cover not only the publication, production, distribution, etc. area
> but also the resource identifier and terms of availability area
> associated with that publication. <!-- how else would you show that
> something was published by X with one identifier and by Y with a
> different one? --> Despite these inconsistencies, users encoding
> citations and attempting to format them according to a standard that
> closely adheres to ISBD may find that <gi>biblFull</gi>, used with its
> child elements and without delimiting punctuation, provides an
> appropriate granularity of encoding with elements that can easily
> rendered for the reader. However, it is important to note that some
> ISBD-derived citation formats (such as ANSI/NISO Z39.29 and
> 7.1) are not entirely conformant to ISBD either, since they may begin
> with a statement of authorship that does not map to the ISBD statement
> of responsibility. <!-- and which, therefore, cannot be encoded
> anywhere inside of a <gi>biblFull</gi> (or <gi>fileDesc</gi>). -->
> <!-- not so: you can use respStmt with an appropriate @type surely?
> --> </p>
There are two questions hidden in this paragraph:
a) Lou wondered why I noted that in fileDesc and biblFull, idno and
availability are children of publicationStmt. I understand why the TEI
put them there, but I note it because the ISBD model, these are something
akin to a sibling element to the publication statement. See
So, as I say earlier in that paragraph, the order doesn't quite match.
b) Lou said you could handle the Z39.29 statement of authorship (my term!)
which is separate from the statement of responsibility (an ISBD term) by
using different values of @type on respStmt. This is true. My only point
is that Z39.29 citations have a component that's not in ISBD, so if
someone was going to produce citations according to Z39.29, they should
understand that if they chose biblFull, there would an additional wrinkle
in addition to the two minor exceptions I gave earlier in the paragraph.
> 3. Use of persName inside biblStruct
> <!-- Name markup is essential for proper
> indexing and other forms of processing. It
> seems advisable that all biblStruct examples
> use it, since the purpose of biblStruct is to
> provide a highly-structured reference. -->
> While this may be true, it presents us with quite a problem in terms
> of house style. Usually we try not to use elements from one module in
> examples appearing in a chapter which describes another. In the few
> rare exceptions, we make quite a song and dance about the need to
> include the other module etc. But biblStruct and friends are
> described in the core module, whereas the <persName> etc. elements
> are described in names and dates. (That incidentally is why the <name>
> element was originally used in some of these examples -- name is
> available in the core). So, while I am perfectly to change some of the
> examples to indicate what you propose as appropriate use of the
> naming elements, I don't think it should be done uniformly. I fear
> this needs more mulling over.
Yes indeed. In the summary of our proposal to Council, Martin, Laurent,
and I asserted in principle 1 that if you use biblStruct, you really
should use the Names and Dates module. Council agreed to this. If we
don't change all of the examples to reflect this, it needs to be as clear
as possible to readers why this is the case.
More information about the tei-council