[tei-council] bibliog doc

Kevin Hawkins kevin.s.hawkins at ultraslavonic.info
Wed May 19 15:26:30 EDT 2010

The proposal we presented to Council makes exactly such an argument for
preferring bibl over biblStruct not only in the examples but also in the
prose.  In fact, it is the part of the prose making this argument which
Lou is taking issue with.  I believe he objects because we make the
assertions in the brief introduction without immediately giving evidence.

Martin and I have now summarized the argument a few ways by email, and I
believe the proposed revisions to P5 also gives some of the rationale
further down in the prose.  Lou, are you able to rework the assertions to
include the evidence that Martin and I have attempted to give?

> Hi Martin,
> My only problem with this is using the examples to sneak in what is in
> essence an argument for preferred or preferred vs. deprecated status
> (and didn't we decide that in the case of bibliographic stuff, we
> couldn't deprecate anyway, because the source material simply might not
> allow our non-deprecated methods?). Really, if we mean something is
> preferred, we should say so explicitly. If we don't mean it, then we
> really need examples for various ways of doing things: we can't just
> think of new or standard users of the Guidelines, IMO.
> On 10-05-19 09:02 AM, Martin Holmes wrote:
>> Hi all,
>>>> 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>
>>> 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.
>> That's exactly my point, expressed more clearly than I've managed to
>> express it so far myself. My worry is that we push people into using
>> <biblStruct>  when<bibl>  would actually be more suitable, simply
>> because
>> of the weight of examples of<biblStruct>  and the absence of any
>> encouragement to think about<bibl>  as a more practical alternative.
>>>> 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.
>> This issue is similar to the one above: if we assume (and my experience
>> suggests this is true) that most users, at least in the early stages of
>> using TEI, will tend to copy-paste examples from the Guidelines and
>> adapt them, then we ought to avoid providing examples which will not
>> work very well for them in real projects. A<biblStruct>  whose name
>> components are not marked up is not very useful for its intended purpose
>> -- automated processing and interchange.
>> I'd suggest that we add a section on "Name encoding in bibliographical
>> references", fairly early in the chapter, to clarify this. Does that
>> make sense?
>> Cheers,
>> Martin
> --
> Daniel Paul O'Donnell
> Professor of English
> University of Lethbridge
> Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
> Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America
> President-elect (English), Society for Digital Humanities/Société pour
> l'étude des médias interactifs (http://sdh-semi.org/)
> Founding Director (2003-2009), Digital Medievalist Project
> (http://www.digitalmedievalist.org/)
> Vox: +1 403 329-2377
> Fax: +1 403 382-7191 (non-confidential)
> Home Page: http://people.uleth.ca/~daniel.odonnell/
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

More information about the tei-council mailing list