#221 Enhancements to model.respLike and <biblStruct>

AMBER
closed-wont-fix
nobody
5
2011-04-27
2010-03-25
No

<bibl> has several potentially useful elements available to it,
which don't seem to be available in <biblStruct>:

<sponsor>
<funder>
<distributor>
<principal>

These are certainly needed when citing projects, or multimedia publications which have distributors. <distributor> is a member of model.imprintPart, but that is not really useful if the document being cited is an online publication. I propose that:

<distributor be added to model.respLike, which already contains <principal>, <funder> and <sponsor>; and
model.respLike be added to <analytic>, <monogr> and <series>, so that these elements are available in <biblStruct> citations.

Discussion

  • Martin Holmes

    Martin Holmes - 2010-03-25

    Note: this does NOT break backward compatibility.

     
  • Lou Burnard

    Lou Burnard - 2010-07-06
    • milestone: --> AMBER
     
  • Lou Burnard

    Lou Burnard - 2010-07-06

    See #2987832 on use of model.imprintPart for digital pubs. Do librarians recognise principal, funder, sponsor as significantly different kinds of responsibility statement I wonder? I assume that model.respLike isn't currently in biblStruct because this is information that your old skool catalogue record either wouldn't include or would include as a note.

     
  • Nobody/Anonymous

    Not sure what the import of your comment is here, Lou, but my main points are that 1) these elements are needed and useful in the context of <biblStruct>, and 2) since they're already in <bibl>, there's a confusing asymmetry between the two methods of marking up biblio references. If you were to posit a rationale for excluding these elements from <biblStruct> (and/or <analytic>, <monogr> and <series>), what would it be?

     
  • Lou Burnard

    Lou Burnard - 2010-09-13

    On reflection, my rationale would be that <distributor> is a variation on <publisher>, and shouldn't be in model.respLike,(which has to do with *intellectual* responsibility) at all. See the notes on <funder> (which arguably shouldnt be there either) and on <sponsor>. I agree that consistency between bibl and biblStruct is desirable, but they shouldnt be indistinguishable. In particular, while it does make sense to provide publication details for a <monogr> (and that's why <imprint> is there) it makes less sense to do so for an analytic or a title, which are unpublished abstractions. Or so I believe.

    I think a better change would be to replace the explicit references to author | editor | respStmt in the content model of biblStruct into a reference to the model.respLike class. This ought to ensure that the elements you want not only appear, but appear in places where it makes sense for them to do so.

     
  • Martin Holmes

    Martin Holmes - 2010-09-13

    Agreed. We should run this by Laurent and Kevin, and if they agree, we can make this change part of the overall reworking of the bibliography elements and attributes, and the content of the Guidelines.

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-09-13

    I agree that removing <distributor> and <funder> from model.respLike makes sense, but since it has the potential to break backwards compatibility, it might need to be saved for a future revision of the Guidelines.

    I agree that, in the TEI bibliographic model, an <analytic> only exists as part of a <monogr>, so the publication info goes with <monogr>. However, this brings us back to the pending question of how to record page ranges for a journal article (<analytic>) part of a journal issue (<monogr>): there's some sense in putting the page numbers in <analytic>. I would prefer to set aside the question of <imprint> in <analytic> for now pending further revisions to <bibl> and <biblStruct>.

    Replacing explicit references to author | editor | respStmt in the content model of biblStruct with a
    reference to the model.respLike class seems sensible to me.

    ***

    For the record, Anglo-American catalogers record responsible parties in three ways:

    a) They transcribe from the title page or its digital equivalent "a statement [. . .] relating to persons responsible for the intellectual or artistic content of the item, to corporate bodies from which the content emanates, or to persons or corporate bodies responsible for the performance of the content of the item". Certain words are abbreviated, and if many parties are listed, you can omit some of the names and insert an ellipsis instead. No attempt is made to delimit the various parties listed or categorize them by role, so the way the TEI distinguishes <author>, <editor>, <meeting>, <principal>, <respStmt>, and <sponsor> doesn't map to this information.

    b) They record certain responsible parties in standardized name forms (in forms such as "Shakespeare, William, 1564-1616") to allow you to find all works by a given author in a catalog. Given many parties listed, there are rules to determine which entities are important enough to warrant this kind of treatment. Such responsible parties are distinguished as personal names, corporate names (a university, a business, an anarchist group), or the name of a meeting. These don't map well to <author>, <editor>, and <meeting> -- not only because of the form of the name has things like dates in it but also because the ontology is a bit different.

    c) They transcribe from the title page (or its digital equivalent) all information about the name(s) of publishing, distributing, releasing, and issuing activities. No attempt is made to delimit the various parties listed or categorize them by role, so the way the TEI distinguishes <publisher> and <distributor> dosen't map to this information.

    I believe that a funder, if recorded on a title page in a way that makes it clear that that funder was not responsible for the intellectual content, is unlikely to be recorded in a catalog record at all.

    Other national cataloging codes are similar.

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-10-19

    I forgot to say that even though I think we should remove <distributor> and <funder> from model.respLike in the long run, I'm not opposed to adding <distributor> to the content model of <bibl>.

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-10-19

    Oops, <distributor> is already allowed in <bibl>. I would prefer to add <distributor> to the content model of some part of <biblStruct> rather than to model.respLike.

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-10-19

    I've changed my mind on model.respLike. Since <funder>, <sponsor>, etc. are already part of model.respLike, let's just add <distributor> and postpone the messy cleanup work of refining the content model of model.respLike. At least we'll be starting from a point of consistency at that time.

     
  • Martin Holmes

    Martin Holmes - 2010-10-20

    OK, I think the biblio gang (MH, KH and LB) now have a consensus, and we can recommend this to the committee:

    1. Add <distributor> to model.respLike, for consistency with <principal>, <funder> and <sponsor>.

    1. Replace explicit references to author | editor | respStmt in the content model of biblStruct with a reference to the model.respLike class, so that <distributor>, <funder>, <sponsor> and <principal> are available where <author>, <editor> and <respStmt> currently are.

     
  • Martin Holmes

    Martin Holmes - 2010-10-20

    Of course the second point should be #2, not another instance of #1...

     
  • Lou Burnard

    Lou Burnard - 2010-10-26

    I assume that "LB" is a typo for "LR", since I am not convinced that it would be a good idea to further confound the mess which is the membership of model.respLike. I would rather stick with the status quo, and work towards two classes, one for "distribution-like responsibilities" and one for "intellectual responsibilities".

     
  • Martin Holmes

    Martin Holmes - 2010-10-26

    Lou, I thought the idea was that we make a recommendation and that the council vote on it. We've made the recommendation; I assume you'll be voting against, but I think everyone else should get to vote, don't you?

     
  • Martin Holmes

    Martin Holmes - 2011-04-21

    Acting on the decision of the Council at the April 2011 meeting, I've added <distributor> to model.respLike. However, I have not acted on the second recommendation from my October 2010 comment:

    Replace explicit references to author | editor | respStmt in the
    content model of biblStruct with a reference to the model.respLike class,
    so that <distributor>, <funder>, <sponsor> and <principal> are available
    where <author>, <editor> and <respStmt> currently are.

    The committee initially approved this, but on further investigation there are some complexities that require more investigation before anything can be done here:

    By <biblStruct>, we really mean <analytic>, <monogr> and <series>. <analytic> is straightforward; we simply replace this:

    <rng:ref name="author"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>

    with this:

    <rng:ref name="model.respLike"/>

    in the existing content model:

    <content>
    <rng:zeroOrMore xmlns:rng="http://relaxng.org/ns/structure/1.0">
    <rng:choice>
    <rng:ref name="author"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    <rng:ref name="title"/>
    <rng:ref name="ref"/>
    <rng:ref name="date"/>
    </rng:choice>
    </rng:zeroOrMore>
    </content>

    <series> is slightly more complicated, in that it has this for its content model:

    <content>
    <rng:zeroOrMore xmlns:rng="http://relaxng.org/ns/structure/1.0">
    <rng:choice>
    <rng:text/>
    <rng:ref name="model.gLike"/>
    <rng:ref name="title"/>
    <rng:ref name="ref"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    <rng:ref name="biblScope"/>
    <rng:ref name="model.global"/>
    </rng:choice>
    </rng:zeroOrMore>
    </content>

    <author> is not there, of course; replacing <editor> and <respStmt> with model.respLike would have the side-effect of adding <author> as well as the other intended items (<sponsor> etc.).

    <monogr> is the most complicated of all. Here we have a rather rigidly-controlled sequence and structure for the content model:

    <content>
    <rng:group xmlns:rng="http://relaxng.org/ns/structure/1.0">
    <rng:optional>
    <rng:choice>
    <rng:group>
    <rng:choice>
    <rng:ref name="author"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    </rng:choice>
    <rng:zeroOrMore>
    <rng:choice>
    <rng:ref name="author"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    </rng:choice>
    </rng:zeroOrMore>
    <rng:oneOrMore>
    <rng:ref name="title"/>
    </rng:oneOrMore>
    <rng:zeroOrMore>
    <rng:choice>
    <rng:ref name="idno"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    </rng:choice>
    </rng:zeroOrMore>
    </rng:group>
    <rng:group>
    <rng:oneOrMore>
    <rng:choice>
    <rng:ref name="title"/>
    <rng:ref name="ref"/>
    </rng:choice>
    </rng:oneOrMore>
    <rng:zeroOrMore>
    <rng:choice>
    <rng:ref name="idno"/>
    <rng:ref name="author"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    </rng:choice>
    </rng:zeroOrMore>
    </rng:group>
    </rng:choice>
    </rng:optional>
    <rng:zeroOrMore>
    <rng:choice>
    <rng:ref name="model.noteLike"/>
    <rng:ref name="meeting"/>
    </rng:choice>
    </rng:zeroOrMore>
    <rng:zeroOrMore>
    <rng:ref name="edition"/>
    <rng:zeroOrMore>
    <rng:choice>
    <rng:ref name="idno"/>
    <rng:ref name="editor"/>
    <rng:ref name="respStmt"/>
    </rng:choice>
    </rng:zeroOrMore>
    </rng:zeroOrMore>
    <rng:ref name="imprint"/>
    <rng:zeroOrMore>
    <rng:choice>
    <rng:ref name="imprint"/>
    <rng:ref name="extent"/>
    <rng:ref name="biblScope"/>
    </rng:choice>
    </rng:zeroOrMore>
    </rng:group>
    </content>

    The simplest way to proceed would be to replace every instance of editor and/or author and/or respStmt with model.respLike; this, again, would introduce <author> in a couple of contexts where it's currently excluded (where <idno> shares a block with <editor> and <respStmt>). We also have an explicit instance of <meeting>, which is also a member of model.respLike.

    The committee will revisit this in the future, so the ticket remains open.

     
  • Martin Holmes

    Martin Holmes - 2011-04-21

    The change noted in the previous comment resulted in an error in TEIP5-Test, which I can't figure out (yet), so I've reverted it temporarily.

     
  • Martin Holmes

    Martin Holmes - 2011-04-27

    I attempted to follow the council's recommendation (adding <distributor> to model.respLike), only to have numerous tests fail because <distributor> then ends up in the content model of various elements through two distinct routes.

    I've since spent a lot of time trying to figure out a simple way to implement the desired change, and I don't see any easy way to do it. I also notice that the actual change we agreed to (add <distributor> to model.respLike) was actually only a preliminary step in a proposed method of making the following elements:

    <principal>
    <funder>
    <sponsor>

    available in <analytic>, <monogr> and <series>. However, the second step in the proposal on the ticket, that "model.respLike be added to <analytic>, <monogr> and <series>, so that these elements are available in <biblStruct> citations", was not agreed to by council in any case.

    So I think we're in a bit of a mess, all in all. I think the following things:

    1. <distributor> does belong in model.respLike, along with <principal> et al., but there's no way to get it there without making significant structural changes. (Meanwhile, Kevin believes that neither <distributor> nor <funder> should be in model.respLike anyway.)

    2. model.respLike does belong in <analytic> et al., but council doesn't think so, and in any case this would be hard to achieve.

    3. The content model of <biblStruct> and its children is a big mess, largely due to historical factors and subsequent tinkering, and the only way to deal with it will be to start from scratch, with a more logical set of model classes. This would inevitably break the Birnbaum doctrine.

    So I am closing this ticket without action, since I opened it in the first place, and only Kevin, Lou and I seem to care about it.

     
  • Martin Holmes

    Martin Holmes - 2011-04-27
    • status: open --> closed-wont-fix
     

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks