Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#427 Minor change to chapter 3

AMBER
closed-rejected
Martin Holmes
5
2013-03-23
2013-01-28
Martin Holmes
No

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

Discussion

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

     
  • Martin Holmes
    Martin Holmes
    2013-01-28

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

     
  • "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.

     
  • Martin Holmes
    Martin Holmes
    2013-01-28

    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.

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

     
  • Martin Holmes
    Martin Holmes
    2013-01-28

    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.

     
  • Martin Holmes
    Martin Holmes
    2013-03-17

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

     
  • Martin Holmes
    Martin Holmes
    2013-03-23

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