Menu
▾
▴
#437 Allow relatedItem in biblFull
closed-fixed
5
2013-04-22
2013-02-21
No
relatedItem is allowed in biblStruct and bibl, but not biblFull. I posted a query about this today but no responses. It seems to me like an oversight. I am working on new project which would benefit from this change. For now, we will add it to the ODD.
Sorry for the lack of response. I do agree that it's odd that <relatedItem> is not available in <biblFull>. It's interesting that the reverse is the case, though (<relatedItem> can contain <biblFull>). The content model for <biblFull> looks quite limited. I know Kevin has a thorough knowledge of <biblFull>, so perhaps he can comment.
I need to be reminded by biblFull even exists. It used to be because it allowed you to model exactly the structure of the <fileDesc>, but in that case why not just make <fileDesc> a member of model.biblLike?
As I said on the thread, it depends what kind of resource you are modelling. I don't think you really want relatedItem inside biblFull but inside one of the elements that biblFull contains. So if the relatedItem is really related to the source of the file, not this electronic file, then it goes inside sourceDesc/bibl. The problem comes when you want to say that this current electronic file, not its source, is related to some other thing. I don't believe the TEI copes with that very well but adding relatedItem to biblFull I don't believe is the answer partly because this leaves fileDesc itself without such a mechanism and if creating such a mechanism then I think there should be a structured place for it which allows other sorts of non-bibliographic relations rather than just having it directly in fileDesc.
The options as I see them:
a) Add relatedItem* (or a class) to the content model of fileDesc and biblFull
b) Create a new element X allowed in the content model of fileDesc and biblFull which is intended as a location to put many different types of relatedItem as well as pointers and references to other items such as graphics or non-bibliographic works which somehow 'relate' to this work. (e.g. <surrogates> might also be usefully embedded in element X?)
c) Add any of these items which might go in the hypothesised element X directly into biblFull and fileDesc.
d) Don't do anything
Of these I'm most in favour of B as you might have guessed, but would want greater input from librarians like Kevin and Michelle to see if we were doing the right thing and how other standards model having a place to store relations to other works (bibliographic and non-bibliographic).
I don't think we want to just allow fileDesc anywhere biblFull is currently allowed because I think that just leads to greater entropy and confusion. The two elements are not identical btw. while biblFull enables you to embed a fileDesc (e.g. of a TEI work you are cateloguing) content it has additional attributes which fileDesc does not have. e.g.: att.declarable.attributes, att.sortable.attributes, att.docStatus.attributes. fileDesc, only appearing in the teiHeader doesn't need to be 'declarable' or 'sortable'. However, what this does make me consider is that I'd quite like att.docStatus.attributes (@status) added to fileDesc. :-)
-James
Thanks for laying out the options, James.
I agree with James that we don't want to do what Lou suggests -- make <fileDesc> a member of model.biblLike -- because it would allow <fileDesc>s to appear anywhere that <bibl>, <biblStruct>, and <biblFull> can appear, such as in a <listBibl> or <cit> that might appear somewhere in the body of a document.
I find (a) a sufficient resolution to this problem; unlike James, I don't see any reason not to allow
biblFull/relatedItem
if the related item relates to the item described by
biblFull
not the item described by
biblFull/sourceDesc
Still, options (b) and (c) are intriguing. I don't yet have a sense of what other "non-bibliographic relations" we want to be able to associate with a bibliographic entity besides <relatedItem> and <surrogates>. Could you expand on that?
I suggest creating a separate ticket on adding att.docStatus.attributes to <fileDesc>. I think it's a separate question.
OK, I agree that adding fileDesc to model.biblLike is maybe not such a smart idea. But I'd still like to be reminded exactly WHY we have biblFull at all.
In COBI I read " This element is provided as a means of embedding the file description of one existing digital text within that of another (see further section 2.2 The File Description); however, its use is not confined to digital texts, and it may be used in the same way as any other bibliographic element ... which rather begs the question. If "its use is not confined to digital texts" (I assume this means "not confined to describing digital texts") in what circumstances would I use it rather than one of the alternatives? I had always assumed that we have it for the very specific use case where we want to describe a pre-existing digital resource that has a TEI header. That makes sense. If we're going to use it to describe any old bibliographic item, just as a change from using bibl or biblStruct then I want to know how I decide which one to use.
Why do we have biblFull at all? I have no idea. It goes back to at least P3, without any more explanation as to why a user might use it instead of <biblStruct> (or <bibl>).
I see two options:
1) Think up a use case for <biblFull> and add this to the Guidelines so people know.
2) Deprecate <biblFull>.
If we go with (1), we still need to go with one of James's options -- (a) through (d). If we go with (2), then James's options are moot.
The original justification for having biblFull (which is quite explicit in P3) was to be able to handle pre-existing TEI-encoded files in a simple way. At some point post P3 someone decided it would be smart to extend its application beyond that. I think that may have been a mistake. I agree with Kevin that if we can't come up with a use case distinguishing it from the other two biblLike elements we should either abolish it or revert to its original definition.
Maybe Michelle could tell us why she's using
<biblFull>rather than either<bibl>or<biblStruct>?A use case was given at http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1303&L=TEI-L&D=0&P=121488 . To meet this need, we only need to allow biblFull in sourceDesc and not everywhere else that the model.biblLike elements can appear. But I don't see any advantage to removing it from the other locations as long as we make the use case explicit in the Guidelines.
Unless I misunderstand, the use case you cite on TEI-L was for the use of biblFull specifically for encoding documents born digital, i.e. the P3 definition. Call that biblFull inside sourceDesc if you like. What we are still missing is an explanation of why you might want biblFull anywhere else (or alternatively, why you couldn't use bibl or biblStruict to do the biblFull job insider sourceDesc)
Right. I happen to know that Michelle is very busy over the next week, but I hope she'll tell us why they chose biblFull over biblStruct and bibl for their project.
In the course of implementing one of the tickets that arose out of http://wiki.tei-c.org/index.php/Ad-hoc_committee_on_encoding_of_bibliographic_citations (I forget which one), I suggested some text explaining a possible use of biblFull elsewhere. This text now appears in the paragraph just before 3.11.1. It's a hypothetical use that in the end is not much more useful than just using bibl.
Last edit: Kevin Hawkins 2013-04-06
Even without Michelle weighing on on why she chose biblFull for her bibliographic descriptions, the Council breakout group feels that there is no good reason not to add relatedItem as a child of biblFull. People generally think of biblFull as providing the most functionality of the three "bibl*" elements, it's odd for it to be lacking in this one area.
LB will make relatedItem a child of notesStmt and make it repeatable.
Added as per council decision