#223 <date> as child of <analytic> and <monogr>

AMBER
closed
nobody
5
2011-01-31
2010-04-15
No

When creating a <biblStruct>, we currently have to include <imprint> in order to get <date>. This is rather silly in the case of such items as podcasts, blog entries, or electronic documents, which have no imprint at all. Also, both analytic- and monographic-level documents may have dates (a blog post is presumably analytic, as part of a larger blog, but has its own date; a website or electronic document may be a monograph, and have a publication or release date).

The content models of <analytic> and <monogr> appear to list elements rather than using classes, so we could simply add <date> to the list in each case.

Discussion

  • Lou Burnard

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

    Lou Burnard - 2010-07-06

    Well, that rather depends what you think "imprint" means. Even for a born digital item, there needs to be a place where you gather together the information about where and when it advertises itself as coming from, which is what <imprint> is for. The name may be badly chosen (it's not necessarily anything to do with printing) but that's its function. If you put <date> as a direct child of <biblStruct>, how do you know whether it means "date consulted" "date last updated" "date I happened to notice it" or what?

     
  • Martin Holmes

    Martin Holmes - 2010-08-13

    Your point seems to be that when <date> is inside <imprint>, then we know what kind of date it is (presumably the date it was "imprinted"), whereas if it were somewhere else, that wouldn't be clear. However, you're also making the point that "imprint" has nothing to do with printing. If we accept that <imprint> has nothing to do with actual printing, then <date> within it is as unspecific as it would be in <analytic> or <monogr>, surely?

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-10-19

    I agree with Lou that information about publication, even of an online document whose provenance is not terribly clear, should be gathered in imprint. Bibliographic and cataloging tradition treat print and digital documents similarly in terms of recording information about its publication, so we can use <imprint> even if we don't think of these documents as having any "imprint".

    I think we should revise the first sentence of COBICOI (section 3.11.2.3) from

    By imprint is meant all the information relating to the publication of a work: the person or organization by whose authority and in whose name a bibliographic entity such as a book is made public or distributed (whether a commercial publisher or some other organization), the place of publication, and a date

    to

    By imprint is meant all the information relating to the publication of a work: the person or organization by whose authority and in whose name a bibliographic entity such as a book is made public or distributed (whether a commercial publisher or some other organization), the place of publication, and the date of publication.

    Then, in a biblStruct, the date of publication would go in imprint/date whereas other relevant dates (such as the date an online source was consulted) would go elsewhere in the citation.

     
  • Martin Holmes

    Martin Holmes - 2010-10-19

    The trouble is that you can't put dates "elsewhere in the citation" -- the only place you can put a <date> is in an <imprint>. That's what I was originally complaining about. The discussion of what <imprint> actually means is a side issue. I still think that <date> should be available elsewhere, because there are aspects of a citation that require a date other than the date that goes in <imprint>.

     
  • Kevin Hawkins

    Kevin Hawkins - 2010-10-19

    Ah, I see now. From the original ticket, I think both Lou and I thought you were just interested in recording a date of publication of a born-digital document.

    It is indeed a deficiency of biblStruct that any dates not relating to publication, such as the date an electronic resource was consulted, cannot be recorded using <date>. (Instead, you need to resort to plain text in a <note> or something like that.) I think Martin's proposal is a good way of solving this problem (in conjunction with use of type= on the various uses of the date element).

    I stand by my suggestion to revise the first sentence of COBICOI.

     
  • Martin Holmes

    Martin Holmes - 2010-10-20

    OK, I propose that we split this into two tickets, creating a new one for this suggestion from Kevin:

    I think we should revise the first sentence of COBICOI (section 3.11.2.3)
    from

    By imprint is meant all the information relating to the publication of a
    work: the person or organization by whose authority and in whose name a
    bibliographic entity such as a book is made public or distributed (whether
    a commercial publisher or some other organization), the place of
    publication, and a date

    to

    By imprint is meant all the information relating to the publication of a
    work: the person or organization by whose authority and in whose name a
    bibliographic entity such as a book is made public or distributed (whether
    a commercial publisher or some other organization), the place of
    publication, and the date of publication.

    I think this will be uncontroversial, because it's simply a clarification. This ticket can then be restricted to my original suggestion:

    <date> should be added as a child of <analytic> and <monogr>, because there are many types of publication date which do not belong naturally in <imprint> (for instance, the publication date of a blog entry, which is an <analytic> inside a larger blog (a <monogr>).

    If you take the stand that all <date>s for <monogr>s belong in <imprint>, then the case is still strong for <date> in <analytic>.

     
  • Martin Holmes

    Martin Holmes - 2010-10-22

    Here is the final recommendation from the biblio gang:

    <date> should be added as a child of <analytic> and <monogr>, because
    there are many types of publication date which do not belong naturally in
    <imprint> (for instance, the publication date of a blog entry, which is an
    <analytic> inside a larger blog (a <monogr>).

    If you take the stand that all <date>s for <monogr>s belong in <imprint>,
    then the case is still strong for <date> in <analytic>.

     
  • Lou Burnard

    Lou Burnard - 2010-10-26

    This sounds good in principle, but needs more clarification. If there is a date inside an analytic how do I know whether it is the date the page was consulted or the date it was last revised or the date it proclaims as part of its title? Presumably these can all be distinguished by the @type attribute, but if that's the intention, should we allow for multiple <date>s inside <analytic>? or put all these additional <date> thingies as direct children of <biblStruct>?

     
  • Martin Holmes

    Martin Holmes - 2011-01-23

    I think the question of multiple <date> elements is a separate issue, and exists also for <date> within <imprint> (as does the question of typology through @type, as Kevin points out). I still think we need <date> within <analytic> and <monogr>, as for the reasons specified in the original request, and these other issues, should there be a need to raise them, ought to be raised in separate tickets.

     
  • Martin Holmes

    Martin Holmes - 2011-01-28

    Laurent asks for "clear semantics for when a date is in imprint and when it is a sibling of imprint". The time I want to use it as a direct child of <monogr> is when there IS no <imprint>, because we're dealing with an item such as a podcast, a blog entry, or an electronic document that has no publication information that belongs in <imprint>.

    However, as I said below, "If you take the stand that all <date>s for <monogr>s belong in <imprint>,
    then the case is still strong for <date> in <analytic>".

     
  • Laurent Romary

    Laurent Romary - 2011-01-28

    OK. The case for date in analytic is cristal clear to me now (feeling slow and dumm at times...). Let us validate this and move along to the next ticket.

     
  • Martin Holmes

    Martin Holmes - 2011-01-31
    • status: open --> closed
     

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks