Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#18 Two new elements for bibliograhic entries

Syd Bauman

The group that has been working on bibliographic
entries for TEI
makes the following proposal. Please see the attached
text file.


  • Full Description

  • Lou Burnard
    Lou Burnard

    • labels: --> TEI: New or Changed Element
  • Lou Burnard
    Lou Burnard

    Logged In: YES

    This is a proposal to revise the content model for biblStruct
    to facilitate better automatic processing and management of
    citations. It needs closer attention by the Council, but I think
    it is basically a good idea.

  • Lou Burnard
    Lou Burnard

    • priority: 5 --> 7
  • Syd Bauman
    Syd Bauman

    Logged In: YES

    In order to facilitate discussion on this issue within the
    TEI Council, I have converted the text file included with
    the original proposal into TEI Lite, and posted it and an
    HTML version at http://www.tei-c.org/Council/sfw01.xml and
    http://www.tei-c.org/Council/sfw01.html, respectively. I
    made a few minor corrections and reworded a few things
    slightly, but made no substantive changes.

  • Syd Bauman
    Syd Bauman

    Logged In: YES

    A TEI Councilor posted to the council's list; his comments
    are prefixed by >, my responses interspersed.
    > - I have a strong intuition that the proposal based on
    biblItem is
    > a good direction to go (a lot of things are made clearer)

    I think I agree, but I'm not at all clear on how structured the
    content of <biblItem> is supposed to be, and thus one whether it
    should replace the current <biblStruct>, and if so should it be
    called <biblItem> or <biblStruct>.

    > - I do not see why there is a need for relatedBiblItem,
    where a
    > recursive biblItem (together with the attributes that are
    > contemplated) would do the trick, it seems.

    Even in those situations where the <relatedBiblItem> is not
    within the <biblItem> to which it's related, isn't the target=
    attribute (which perhaps should be called related=) on
    sufficient to show this relationship?

    > My main arguments are:
    > * design simplicity: why two objects with nearly the same
    > should be so much differentiated

    > * practicality and coherence: if the relatedBiblItem
    objects are
    > described elsewhere in the same or another document,
    then they
    > are likely to be described as biblItem. They would thus
    > nature depending on whether a reference to them is made
    in an
    > inline way (relatedBiblItem) or stand-off way (biblItem)

  • Logged In: YES

    As the writer of the proposal, let me address the issues
    raised by the council:

    1. Structure of <biblItem>.

    The structure should resemble that of <biblStruct>, WITHOUT
    the <monograph>, <analytical>, and <series> elements, since
    these three items are too vague and are replaced by either
    the <biblItem> or <relatedBliblItem>. We felt we needed a
    completely new element to reflect a completely new approach.

    If the content model of <biblStruct> were revised so that it
    no longer allowed the three unnecessary elements; and if
    <biblStruct> could allow <biblStruct> as a child; and if
    <biblStruct> would allow the same attributes as we proposed
    for <biblItem>; then <biblStruct> would work fine.

    In other words, if you allow the changes I outline above,
    you have the content model we propose for <biblItem>

    2. Is <relatedBiblItem> needed?

    I have to agree that a nested <biblItem> would serve as well
    as a <relatedBiblItem>, perhaps making the <relatedBiblitem>
    unnecessary. It was others who proposed the
    <relatedBiblItem> element. If they responded, perhaps they
    could make the reason for <relatedBiblItem> clearer.

    For myself, I can't think of any good reasons why a
    <biblItem> won't do for a <relatedBiblitem>. By its parent
    elements, as well as the attributes we proposed, a
    <biblItem> should never have an ambiuous relationship.

  • Syd Bauman
    Syd Bauman

    • assigned_to: nobody --> sbauman
    • status: open --> closed