[tei-council] bibliog doc

[Lou Burnard]

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:

-----------
<p>Since the TEI file description elements are based on the ISBD
areas, it should be possible to use the content of file description as
the basis for a catalog record for a TEI document. However,
cataloguers should be aware that the permissive nature of the TEI
Guidelines may lead to divergences between practice in using the TEI
file description and the comparatively strict recommendations of
AACR2. Such divergences as the following may preclude automatic
generation of catalogue records from TEI headers: <list>

<item>The TEI title statement may not categorise constituent titles in
the same way as recommended by AACR2.</item>

<item>The TEI title statement contains authors, editors, and other
responsible parties in separate elements, with names which may not
have been normalized; it does not necessarily contain a single
statement of responsibility from the chief source of
information.</item>
<!--item>The components of the TEI file
description do not prescribe that data be transcribed according to
AACR2 rules.</item--><!-- removed as already stated above-->
<!-- 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. -->
<item>The TEI header does not require use of a particular vocabulary
for subject headings or mandate the use of subject headings.</item>
</list></p>

-----------------------

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>

<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>

<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>

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.