Minor change to chapter 3

[TEITechnicalCouncil]

This arises out of the long-running biblio work that Kevin, Laurent and I have been doing:

http://wiki.tei-c.org/index.php/Ad-hoc\_committee\_on\_encoding\_of\_bibliographic\_citations

The proposal (dating back to the Dublin meeting) is to extend an existing paragraph in 3.11 from this:

The most commonly used elements in the model.biblLike class are biblStruct and bibl. biblStruct will usually be easier to process mechanically than bibl 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 biblStruct element; instead, the presence and order of child elements must be used to reconstruct the punctuation required by a particular style.

to this:

The two most commonly used elements in the model.biblLike class are <biblStruct> and <bibl>. <biblStruct> will usually be easier to process mechanically than <bibl> because its structure is more constrained and predictable. It is suited to situations in which the objective is to encode bibliographic information in such a way that it is machine‐readable by external systems or can be converted into other bibliographic markup formats such as BibTeXML or MODS. Punctuation delimiting the components of a print citation is typically not included anywhere in a <biblStruct> because the presence and order of child elements can be used to reconstruct this punctuation and because, since biblStruct permits only child elements but not character data as content, there is no place to put the punctuation. While <biblStruct> offers enough flexibility for encoding bibliographic references to simple print works, for many documents, especially electronic ones, it proves problematic.

(In other words, to extend it a bit to add clarification and detail.)

Original comment by: @martindholmes

[TEITechnicalCouncil]

This issue was originally assigned to SF user: martindholmes Current user is: martindholmes

[TEITechnicalCouncil]

the sentence "While <biblStruct> offers enough flexibility for encoding bibliographic references to simple print works, for many documents, especially electronic ones, it proves problematic." is very unhelpful, I think. Saying a thing is "problematic" without giving reasons or suggesting alternatives, is weaselly. Since we (the TEI Guidelines) use biblStruct for our bibliography, including electronic documents, why dont we regard it as problematic? if it cant do many documents, why aren't we fixing or or abandoning it?

semi-recommending unstructured bibliographies strikes me as a sad thing to do....

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

<biblStruct> is problematic because it's remarkably difficult to process into output which conforms with any specific styleguide, whereas <bibl> is easier to process to a target styleguide because you can put the items in the same order as you need them in the output. Additionally, with the option for nested <bibl>s, while <bibl> might appear to be less structured, it may not be so, and it can certainly be as densely and precisely encoded as <biblStruct> can be.

Original comment by: @martindholmes

[TEITechnicalCouncil]

"it's remarkably difficult to process into output which conforms with any specific styleguide" is a strange argument to make about the TEI :-}. I don't think its hard at all. Bang it into the input format for a bibliographical processor (I grok BibTeX, but plenty of others), select the style, and you're done. Yes, with a structured <bibl> its easy too, but an unstructured bibl is a nightmare. The difference is that you can't check an unstructured bibl, cos you have no idea what the character data may be representing.

Try implementing <tree>, I claim thats impossible, not enough information. But we dont dis-recommend it on those grounds.

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

How about this, then:

... While <biblStruct> offers enough flexibility for encoding bibliographic references to simple print works, for many documents, especially electronic ones, it can prove difficult to render into a format that conforms with a specific styleguide. In contrast, <bibl> allows all the components of the citation to be included in the order prescribed by a styleguide, along with the required punctuation, making rendering easier, while at the same time allowing all the distinct components of the citation (author, title, publisher, publication place etc.) to be tagged so that they can be recovered by automated harvesters.

Original comment by: @martindholmes

[TEITechnicalCouncil]

well, sorry, but far worse in my view :-}

i think its chalk and cheese. <bibl> is for marking up a formatted bibliography, <biblStruct> is for making a database record in TEI XML (bit like <person>). They are both good at their job, but don't overlap. If you are doing born-digital documents, you'd be mad to preformat the bibliography to a particular style at source (IMHO), when we have such good bibliographical database tools; and if you're using those, I think biblStruct is a better TEI representation.

we may have had this argument before, though.....

Original comment by: @sebastianrahtz

[TEITechnicalCouncil]

We have had this argument before. I share none of your confidence that existing db tools can format reliably for specific styleguides. But this is a ticket dating back to that original debate beginning in Dublin, and I know that most people don't share my views about biblStruct vs bibl (the structure of the former brings nothing but pain, and the flexibility of the latter nothing but power), so I'm content to retreat if no-one else agrees with what the biblio subcommittee came up with here.

Original comment by: @martindholmes

[TEITechnicalCouncil]

I propose closing this ticket without any further action. I don't think we'll reach a consensus, so we should do nothing.

Original comment by: @martindholmes

[TEITechnicalCouncil]

• status: open --> closed-rejected
• milestone: --> AMBER

Original comment by: @martindholmes