#375 Improve guidance and restrict usage of biblScope

GREEN
closed
5
2014-08-23
2012-08-07
No

There are a few problems with section 3.11.2.3 and the content models of associated elements:

1) Not much guidance is given on when to put <biblScope> in which parent element.

2) When guidance is given, it's for journal articles (to put volume and issue number in <biblScope>s <imprint>), but the information there doesn't "relat[e] to the publication or distribution of a bibliographic item", as <imprint> is currently defined.

To address (1), we propose to explain more explicitly in the Guidelines that <biblScope> be used to constrain the scope (within the parent element of the biblScope) of the item cited in the next lowermost "level", where "level" is used as in section 3.11.2.1. Take this example:

<biblStruct>
<analytic>
<author>Albert Schachter</author>
<title>Iolaos</title>
</analytic>
<monogr>
<title>Herakles to Poseidon</title>
<imprint><date>1986</date></imprint>
<biblScope type="pp">64-70</biblScope>
</monogr>
<monogr>
<title>Cults of Boiotia</title>
<imprint><pubPlace>London</pubPlace></imprint>
<extent>4 vols.</extent>
<biblScope type="part">2</biblScope>
</monogr>
<series>
<title>Bulletin of the Institute of Classical Studies
Supplements</title>
<biblScope type="vol">38</biblScope>
</series>
</biblStruct>

There are four "levels": the lowest "level" is the <analytic>, the next is the first <monogr>, then the second <monogr>, and finally the highest "level" is <series>. The article "Iolaos" appears on pp. 64-70 of *Herakles to Poseidon*, which is part 2 of *Cults of Boiotia*, which is vol. 38 of *BICS Supplements*.

Each <biblScope> describes where (within its parent element) to find the thing in the previous level.

To address (2), we would remove the current recommendation in 3.11.2.3 to use monogr/imprint/biblScope for journal articles and instead say to encode information like volume, issue, and date of a given journal issue as a child of <monogr>. We would modify examples accordingly, and we would deprecate use of <biblScope> inside of <imprint>.

There would be no change to the definition or examples of <extent>: it would still be used not for mentions of particular pages or volumes but for a statement like "4 vols." and "325 pages".

Discussion

  • Kevin Hawkins

    Kevin Hawkins - 2012-09-09

    Regarding (1), note a similar ticket about ambiguity on placement of <idno> within <biblStruct>: http://purl.org/TEI/FR/3565878 .

     
  • Lou Burnard

    Lou Burnard - 2012-09-16

    Nice example, and helpful clarification of how to use <biblScope>.

     
  • Lou Burnard

    Lou Burnard - 2012-09-16
    • milestone: --> GREEN
     
  • James Cummings

    James Cummings - 2012-09-19
    • assigned_to: nobody --> louburnard
     
  • John P. McCaskey

    The request reads:

    The article "Iolaos" appears on pp. 64-70 of *Herakles to Poseidon*, which is part 2 of *Cults of Boiotia*, which is vol. 38 of *BICS Supplements*.

    Does this say that a monograph titled *Herakles to Poseidon* is a part (viz., part 2) of a monograph titled *Cults of Boiotia*?

    With 3.11.2.1, I read the encoding as saying part 2 of *Cults of Boiotia* is an article titled "Iolaos" and this article also appeared on pp. 64-70 of some other monograph, one titled *Herakles to Poseidon*.

     
  • Lou Burnard

    Lou Burnard - 2012-11-03

    To answer John's question first: the way this should be read according to the current P5 is that the two <monogr>s are parallel, not that one is contained by the other. The article features both as a component of "Cults of Boetia" and of "Herakles to Poseidon". The proposed changes imply a hierarchy, so that it's tempting to regard "C of B" as a component of "HtoP" rather than a sibling of it, but this is not warranted. Indeed, it may actually be wrong: the presence of two <imprint>s may just imply that the article in question has been published twice. This case is indeed the first one cited in the present Guidelines.

    The relation between a <monogr> and a sibling <series> is a special case, explicitly addressed in the current Guidelines, but it would also (theoretically) at least fall foul of the same problem, if for example "C of B" were included in more than one series.

    I think the sentence "Each <biblScope> describes where (within its parent element) to find the thing in the previous level" is correct, but only if you understand the word "level" as "preceding sibling of a different bibliographic level"

     
  • Kevin Hawkins

    Kevin Hawkins - 2012-11-12

    This was partially implemented at http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Guidelines/en/CO-CoreElements.xml?r1=11111&r2=11110&pathrev=11111 , with this example added and the sentence about putting <biblScope> inside <imprint> for journal articles has been removced.

    However, further discussion has been taking place on the tei-council list about whether the four levels posited by Gabby are really appropriate.

    In College Station, Lou and I took a moment to discuss this ticket and seemed to reach consensus on the way out. My memory is unfortunately already hazy, but here is my attempt to recall what we decided.

    While <biblScope> introduces quite a bit of internal structure in a citation, the relationship among <analytic>, <monogr>, and <series> elements in the Guidelines now isn't quite as described by Gabby, and his proposal for how they should relate (to the "previous level") doesn't account for the case given in the most recent comment on the ticket. That is, right now the Guidelines say that if you have one <analytic> and multiple <monogr>, it means that the analytic item appears in both of these <monogr>s, and if you have a <series>, then it relates only to the "most recently preceding" <monogr>.

    So Lou suggested that we make no further modifications. That seems fine to me.

     
  • Lou Burnard

    Lou Burnard - 2013-01-04

    Closing this as we seem to have taken it as far as we can,,,

     
  • Lou Burnard

    Lou Burnard - 2013-01-04
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks