no DOI field for books?

I added a book to my Zotero library, but it seems like I can't add a DOI for the book, even though it has one (http://dx.doi.org/10.1007/978-0-387-68852-7 if you're curious). Can this field be enabled for books? Am I missing something?

(A more general problem is, how to store DOIs for individual chapters? I don't have any need for that right now, but I'd like to see Zotero work on supporting that.)
  • A DOI is not unheard of for books (as you say), but neither is it too common & I'm not aware of it ever being cited. Might be useful to be able to store it, though.
    A more general problem is, how to store DOIs for individual chapters?
    Presumably if the 'book' type was amended, the 'book section' type could also be amended. Note that 'conference paper' already includes a DOI (this is the resource not from a periodical that is most likely to have a DOI).
  • igw
    edited September 23, 2009
    The new APA style manual, 6th edition, now also includes DOIs for books and book chapters (for online editions)

    For example:
    American Psychiatric Association. (2000). Diagnostic and statistical manual of mental disorders (4th ed., text rev.). doi:10.1176/appi.books.9780890423349
  • On a related note, I've just downloaded a report having ISSN (even though the report states it is only available online - http://www.umweltdaten.de/publikationen/fpdf-l/3845.pdf ).

    My suggestion would be
  • .. sorry, a wrong click.

    Now, my suggestion would be to allow user to add any field to items of any type - though by default show only those fields, "belonging" to that type of item.

    If the user want to add, say, "patent number" to an "interview" item - let it be his responsibility.
  • ISSN is the International Standard Serial Number. It applies regardless of publishing medium, but usually only on periodicals. That ISSN applies to all UBA reports of the German Federal Environmental Agency.

    There are a few problems with allowing any field on all types:
    • could confuse users who inadvertently added fields
    • could confuse other users who obtained the reference from a zotero group or export
    • data export would either have to omit these or would mindlessly dump them, confusing other programs
    • some fields just don't make sense & will never be used in citations for some types
  • @ noksagt

    Thus, ISSN may apply to a report. DOI may apply to a book (or to report). These cases are not typical, therefore not included (yet, at least) - but they make sense.

    To your objections.
    could confuse users who inadvertently added fields
    You can't protect any user from inadvertently adding whatever rubbish. And it's really easy in Zotero to inadvertently add some improper reference to a wrong library. On the other side, even if there would appear some "wrong" field in a reference, and the user didn't know what it's good for - he/she would just left it empty. You could also add a warning dialogue before adding a field.
    could confuse other users who obtained the reference from a zotero group or export
    Would DOI on a book or ISSN on a report really confuse other users? Normally, if somebody would add a non-standard field, then in a case making sense to him - and probably, to others as well.
    data export would either have to omit these or would mindlessly dump them, confusing other programs
    Well, it's a legitimate argument. Probably, leaving these non-standard data out on export is the easiest solution.
    some fields just don't make sense & will never be used in citations for some types
    Sure. So no problems - they will be probably never used. But others could be used in less-then-typical situation.

    And therefore my suggestion - do not try to foresee every possible situation, but include a default set of fields for every citation type - and let the user add more in few special cases, if necessary.
  • A patent number assigned to an interview would, I think, confuse most other users. Perhaps it would make sense (in some convoluted way) to a person who added it (well, it was an interview about this patent....)

    If you can structure an argument for why we'd ever want a patent number on the interview type, you'd probably have the most compelling argument for allowing any field to be assigned to any type. But "let it be his responsibility" is less compelling than the arguments for a simple interface.
    Probably, leaving these non-standard data out on export is the easiest solution.
    But then some users would, doubtlessly, complain. Why let people input what will NEVER be output?

    Allowing all fields on all types is not even good at solving a majority of the kinds of edge cases that you hope to fix. It seems more common to have some other tidbit of information that is not recorded for ANY type that people want to keep track of that is useful for a source. This is why other programs often have more-than-one "extra" or user-defined field (not that this is an ideal solution either).
  • The discussed issue is not particularly important to me, and IMO a minor one generally. Still, a few more considerations:

    I like the easy to use but flexible user interface of the Mac OS X Address Book. There are two modi there. In the "View" mode, only those fields are shown which do contain some information. In the "Edit" mode, the standard fields are shown according to the template. The user can add more fields for any dataset separately if necessary, or he can change the template.

    In the current Zotero state, either the developers would add e.g. the "DOI" field for books, which would stay unused in (100-o)% of cases and just take place away. Or they may decide to omit it, with the loss of functionality for those who need it. Similar decisions must be made with "ISSN" for reports (as discussed), "ISSN" and "Publication" for conference papers (which are often published as special issues of regular journals), and presumably in many other cases. "DOI", "ISSN", "Patent number" have or may have an action associated with it (wouldn't it be nice to get on a single click everything about this patent from the repository of your choice?). They may be needed in some specialized styles, now or in the future. Therefore it's preferable to use specialized fields if they apply instead of the "Extra" field.

    On the other side, every Zotero item type has the field "Rights" which many users will never use (actually I don't know what it's meant for - nor do I want to know). So, it just takes place away, and place is scarce there. If I could, I would just hide it in my personal Zotero settings.

    -------

    You asked me to construct some case for using "Patent number" field for the "Interview" item type. OK

    Let's imagine a company specializing in patent commercialization. The people there sift through vast quantity of information of any kind - scientific, technical, social, financial. Zotero is a great tool for such tasks.

    The people there would exchange information to each other, but not using Zotero groups for information security reasons. The would just share Zotero RDF files.

    A large part of the publications the gather deals in one way or another with - you guess, patents. One way to link a publication to a patent would be a Zotero "Related" link. But they are not exportable (are they?). Filling in the "Patent number" field would be the natural solution then.

    -------
    BTW, the people working in such a company aren't going to publish a lot - they may only produce some internal reports, without any need for a specialized reference formatting. For them, for me, for a lot of people in (industrial) R&D, Zotero is a really great tool - but it's ability to produce a bibliography for a publication is but a nice ancillary feature.
  • Probably, leaving these non-standard data out on export is the easiest solution.
    But then some users would, doubtlessly, complain. Why let people input what will NEVER be output?
    Just to clarify: I've meant omitting these data on export to "other" formats. Zotero native RDF and Zotero Groups should of cause include these non-standard fields (I don't think there may be technical problems with it).
  • I would add to the voices expressing the need for DOI for book and book section (or for more flexibility about fields in general, which I personally would prefer). The Cambridge University Press makes the full text of all Cambridge Companions available through a subscription to Cambridge Collections Online in PDF format. As a practical matter, these individual documents are all of the Book Section data type. Each section is assigned a DOI. I figure as publishers embrace online availability this sort of thing will only increase, and Zotero really ought to allow us to record the DOI -- both so we can keep our data straight, and so we can be prepared as more citation styles adopt this.
  • I agree, but a problem with DOI in my opinion is that it can point to material that is not open to access for anyone. That makes it in my opinion kind of useless.
  • beogl - read the thread: Many - and an increasing number of - styles require DOIs, including the APA style, one of the 4 or 5 most widely used styles in academia. That's all that matter for the purpose of Zotero.
  • Thanks Adam, yes you are right. That is all that matters here. (Though I still think that it is problem that it points to non open access material.)
  • I don't think there is a ticket for this yet so I opened one. Looks like encyclopedia articles are increasingly getting DOIs as well so I added those to the ticket too.

    https://www.zotero.org/trac/ticket/1716
  • This was listed for 2.1 on the ticket but it doesn't look like it got through.

    Any update about the status? Is it particularly difficult or tricky to implement?
  • no, not at all tricky - no field updates were done for 2.1 - see the thread on top of the forum - it's been moved to 2.2.
  • We couldn't reach agreement on the pending changes quickly enough to get this into Zotero 2.1 -- see https://github.com/ajlyon/zotero-bits/issues for the status of all active proposals.

    The Zotero team is committed to making these changes happen, but they have to be done right, since -- IIRC -- it may cause sync incompatibility; Zotero 2.2 clients might not be able to sync with Zotero 2.1 clients. That is obviously a situation that we want to cause only rarely.
  • edited April 29, 2013
    Was anything ever decided on this? I am running into an increasing number of online book chapters with DOIs, and it would be nice to be able to use them. Chicago style also makes provision for using them with items other than journal articles: see 14.167 and 14.248.
  • yeah, this is a definite yes. For technical reasons, any field updates will have to wait until Zotero 4.2
  • I posted this in another thread:

    At support.mendeley.com/customer/portal/articles/723677-adding-new-variables-to-my-citation-style the problem of unsupported fields in Mendeley Desktop is addressed.

    The workaround explained there also works for Zotero: Add a DOI to a Zotero item of the type "book", for instance, by putting the line
    {:DOI:10.1037/11019-008}
    somewhere in the "extra" field. It will then beautifully make its way into the citation of the item.
  • A note for people who come by this thread.

    The entry above can now be written in the Extra field like this:

    DOI: 10.1037/11019-008
  • Cross linking to this discussion on field types:
    https://forums.zotero.org/discussion/15636/changes-to-fields-and-item-types-for-zotero-5-1/

    Given that the DOI is used by Zotero for retrieving metadata, and given that a DOI is an object identifier for any digital object, shouldn't all Zotero items have DOIs?

    (https://forums.zotero.org/discussion/comment/302543,
    https://forums.zotero.org/discussion/comment/302591)
  • Same answer we've given on a couple of these threads:
    yes, all items should have DOIs; yes, all items will get DOIs; no, it's not easy to do because it changes the database and thus affects sync. This is expected for the next major version, i.e. 5.1 (which corresponds to 4.2 above -- the naming just changed around a bit).

    The DOI in the extra field works, though, is recognized by citation styles, and will be migrated once the field exists. Items with metadata retrieved by DOI (and an increasing number of other translators) will use that same syntax.

    DOIs, btw., are digital identifiers for _any_ object; the object needn't be digital.
  • Thanks, for the response - good to hear, and thanks for correction as well!
  • So extra works. We have Zotero 5.0.58, which is above 4.2. Still no DOI?
  • It’s just a change in the numbering—“4.1” became “5.0”, so “4.2” became “5.1”. Extra is the officially supported method until the next major Zotero update—DOIs can be cited from Extra and will be placed there by Zotero’s web translators.
Sign In or Register to comment.