#372 Add idno as child to biblFull

GREEN
closed-rejected
Kevin Hawkins
5
2012-09-19
2012-08-01
Peter Stadler
No

<idno> is not available within <biblFull>, while it is in <bibl> and <biblStruct>. Although <idno> is possible as child of <publicationStmt> and hence the resource identifier could be recorded there, it would be nice to align those content models.
Cf. http://tei-l.970651.n3.nabble.com/Linking-TEI-elements-to-authority-records-idno-and-bibliographic-descriptions-tp4022370.html

Discussion

  • James Cummings
    James Cummings
    2012-08-09

    assigning to kevin for review and report to council at next face2face.

    My ill-informed opinion is that, on the face of it, it seems like <idno> is available inside necessary elements inside <biblFull>... i.e. if you are talking about the idno of the published work, it is available in <publicationStmt>, if it is about the author, it is available in <author>. Part of the point of <biblFull> is that it is structured the same way as the fileDesc so it breaks up information which is grouped all together in <bibl>. But maybe I'm missing something here, so do comment more on the ticket to explain to me!

    -James

     
  • James Cummings
    James Cummings
    2012-08-09

    • assigned_to: nobody --> kshawkin
     
  • Peter Stadler
    Peter Stadler
    2012-08-09

    James, you are rephrasing some of the issues Kevin raised in his post (see TEI-L link above).

    Adding to it, I wonder if biblFull/publicationStmt/idno is necessarily identical to biblFull/idno? Speaking in FRBR terms, the former will probably only refer to manifestations or items while the latter could refer to works or expressions as well?! (Just thinking out loud ...)

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-08-10

    James: I think that Peter and I would propose to allow <idno> as a child not only of <biblFull> (to align this element's content model with <biblStruct> and <bibl>) but also to <fileDesc> (in order to keep its content model parallel to that of <biblFull>). We would then need to offer guidance to users on the difference between fileDesc/idno and fileDesc/publicationStmt/idno. I don't think this would be too hard: while an ISBN is related to the act of publication, it's not clear that a digital identifier assigned to a TEI document is also related to publication. I could flesh out something more bibliographically sound.

    Peter, does my summary of your proposal above make sense?

    Peter: I understand what you are getting at with the FRBR analysis, but I don't think it's fair to say that <publicationStmt> provides information about a FRBR manifestation or item whereas the information in <fileDesc> as a whole describes the work or expression. The TEI, just like most library cataloging practice, conflates various aspects of works, expressions, manifestations, and items. (I explored this topic briefly a few years ago: see http://www.ultraslavonic.info/preprints/20081102.pdf .)

     
  • Peter Stadler
    Peter Stadler
    2012-08-10

    Kevin, thanks for helping me out ;-)
    I must admit that I have not thought about this issue for long but proposed this fr just after Florence's notion about the disparate treatment of <idno> in <bibl>, <biblFull> and <bibStruct>. I'm always fond of aligning content models ...
    So, you're right in adding <fileDesc> to this list since it's virtually the blueprint for <biblFull>.

    Now, for the semantic sugar, the difference between biblFull/publicationStmt/idno and biblFull/idno (or fileDesc instead of biblFull), I'm again very thankfull if you could provide something more sound than my FRBRish gaggle. Thanks for the link to your paper which gave me some deeper insights into this topic. Well, actually I don't think we are that far away since I didn't want to propose a clear distinction between those aspects; I simply took <publicationStmt> by its name which suggests to me some sort of embodiment of a text like it is implied for FRBR manifestations or items.

     
  • James Cummings
    James Cummings
    2012-08-10

    Kevin: I see that adding it to fileDesc as well gives a syntactic parity across bibl/biblStruct/biblFull and fileDesc. I'm just not sure I really and clearly understand the difference between
    fileDesc/idno and fileDesc/publicationStmt/idno. (and thus likewise biblFull/idno). You say that ISBN has to do with publication, whereas DOI doesn't. I'm not sure I'm convinced by that since to me a DOI is an identifier of a digitally published work. The publishing is still there. (Do people get DOI's for things which they do not publish in some loose sense?)

    As always, I'm more than happy to cede to your bibliographic and library knowledge, I just want to make sure I understand when I would use one vs the other. In principle I'm not against the idea as I often feel the temptation to align content models as Peter does. (However, we need to make sure we don't lose riches embedded in existing hierachies, or in this case provide possibly-unnecessary duplication.)

    -J

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-08-10

    James may be using "DOI" in the narrower sense as defined by the International DOI Foundation, but I simply meant it as an identifier for a digital object of some sort -- something like a record key. I agree with James that, in aligning content models, we don't want to create unnecessary confusion about fileDesc/idno vs. fileDesc/publicationStmt/idno (and biblFull/idno vs. biblFull/publicationStmt/idno). So we would need to decide on one of the following:

    a) that there is an actual distinction to be made here and therefore <idno> should be allowed in both places

    b) that the TEI was completely wrong in putting <idno> inside <publicationStmt> that we need to allow it in the other place to correct this past mistake, possibly also deprecating use of <idno> in <publicationStmt>

    On TEI-L I offered a quck statement in support of ISBN harmonization but hadn't through through whether this means (a) or (b). Below I started arguing for (a), but I also need to think about this a bit more. Basically, I need to think about this all some more and write a short background paper on the current inconsistencies in the TEI model, on the ISBD structure, and on various identifiers that you might want to associate with different things. Thinking it through might help me to decide on (a) vs. (b). In advance of the Council meeting, I'll post what I come up with here and invite comments from those reading this ticket.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-09-08

    Even though I initially supported greater alignment of TEI with ISBD and lent support to the proposal behind this ticket when it was raised on TEI-L, after some consideration I've decided that this change would be so disruptive to past encoding practice that I we should not break backwards compatibility just to align TEI and ISBD. In other words, while an alignment would be elegant, it has little practical value. That is, I no longer support (b).

    As for (a), while I wrote in a previous comment on this ticket that there might be a justification for this, I think the proposed distinction is complicated for users, not reflected elsewhere in the content model of <fileDesc> and <biblFull>, and doesn't really serve a purpose. So I no longer support (a) either.

    So, with apologies for changing my mind so much, I no longer support implementing the proposal in this ticket. :( More detail below for those interested.

    I propose we give Peter and others a few weeks to respond before closing the ticket without implementing.

    == Background ==

    The ISBD was developed as an international standard for the structure of library catalog records. By using standard punctuation marks to separate various components of a bibliographic citation, a librarian could read a citation even if they do not understand the language of the work or even the script it is written in. Furthermore, such descriptions could be read by users in any country.

    ISBD catalog records generally describe a FRBR manifestation (all identical copies of a particular edition), but for rare books the record describes a FRBR item (a particular copy). However, in either case there may be parts of the record that describe the FRBR work ("Hamlet"). Furthermore, since a published manifestation often include information related to other manifestations of the same FRBR expression (such as the edited text used in both the 1962 paperback and hardback editions of Hamlet from Oxford University Press), the catalog record also contains information related to the manifestation. However, these four FRBR entities are not explicitly distinguished in the catalog record.

    In library practice, the object of cataloging is a whole monograph or serial publication even when published or bound in multiple volumes. In certain cases a single volume in a monograph, a special issue in a serial, or even an article in a serial will be "analyzed" on its own, yielding its own catalog record that refers to the object containing it, much like a TEI <biblStruct> can have an <analytic> or <series> in addition to a <monogr>.

    Both <fileDesc> and <biblFull> are based on ISBD, which is organized as follows (adapted from Wikipedia):

    1: title and statement of responsibility area, with the contents of:
    1.1 Title proper
    1.2 General material designation. (GMDs are generic terms describing the medium of the item.)
    1.3 Parallel title
    1.4 Other title information
    1.5 Statements of responsibility (authorship, editorship, etc.)
    2: edition area
    3: material or type of resource specific area (for example, the scale of a map or the numbering of a periodical)
    4: publication, production, distribution, etc., area
    5: physical description area (for example: number of pages in a book or number of CDs issued as a unit)
    6: series area
    7: notes area
    8: resource identifier (e.g. ISBN, ISSN) and terms of availability area

    As explained in the chapter before section 3.11.1 of the Guidelines, "The order of child elements in both <biblFull> and <fileDesc> corresponds to the order of bibliographic desription ‘areas’ in ISBD with two minor exceptions. First, the <extent> 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, <biblFull> and <fileDesc> use the child element <publicationStmt> to cover not only the publication, production, distribution, etc. area but also the resource identifier and terms of availability area associated with that publication."

    == The problem ==

    If you want to include an identifier *for a bibliographic item* in a <biblStruct> or <biblFull>, it's not clear how to do it, and the content models of these elements seem less aligned than you might expect.

    For a discussion of the problems with <biblStruct>, see http://purl.org/TEI/FR/3565878.

    Currently there is only one plausible location for an identifier for a bibliographic item in <biblFull>:

    biblFull/publicationStmt/idno

    This ticket asks to allow:

    biblFull/idno

    There are two arguments for implementing this ticket:

    A) It would align the content model of <biblFull> with that of <bibl> and <biblStruct> so that <idno> is allowed as a child of any of them. This is a weak argument since very little about the content models of <bibl>, <biblStruct>, and <biblFull> is parallel.

    B) By allowing <idno> as the last child of <biblFull> and <fileDesc>, we could make TEI follow ISBD's order and hierarchy of components. While there's a certain elegance to that, it then raises the question whether we would deprecate use of <idno> inside <publicationStmt> altogether in order to conform to the ISBD model. This would be a major break of backwards compatibility, and I feel that the elegance of aligning TEI and ISBD doesn't warrant this.

    Another possibility would be to allow <idno> in both places but to make a distinction in how to interpret the markup depending on its location. We might say that an identifier related to the act of publication (or assigned for purposes of publication) -- that is, assigned to a FRBR manifestation -- would go in <publicationStmt> whereas an identifier assigned to a FRBR work or FRBR expression would go in an <idno> that is a sibling of <publicationStmt>. However, the distinction between these FRBR entities is already difficult for most users, and it's not used elsewhere in TEI or ISBD. There is already considerably confusion about which components of an ISBD record refer to which FRBR entities (as explained in the background section above) and which components of a TEI header refer to which FRBR entities (see http://www.ultraslavonic.info/preprints/20081102.pdf ), and this one change won't fix that.

     
  • Lou Burnard
    Lou Burnard
    2012-09-16

    If you want to add an identifier at the topmost level of the hierarchy, of course, you also have the option of supplying a value for xml:id on <biblFull> ,.,

     
  • Lou Burnard
    Lou Burnard
    2012-09-16

    • milestone: --> GREEN
     
  • Kevin Hawkins
    Kevin Hawkins
    2012-09-18

    But as Laurent notes on a related ticket ( https://sourceforge.net/tracker/?func=detail&atid=644065&aid=3565878&group_id=106328 ), @xml:id is meant for an identifier for an XML object, not for the thing described by that XML object. And since it can't be typed or repeated, its utility is further constrained. So this is a problematic option.

     
  • Kevin Hawkins
    Kevin Hawkins
    2012-09-19

    • status: open --> closed-rejected
     
  • Kevin Hawkins
    Kevin Hawkins
    2012-09-19

    Closing this ticket.