Books and Book Sections: Avoiding Input of Duplicate Info

It would be great if there was some way to avoid the input of duplicate information when adding a "book section" of a book that is already in your library. Also, I'd love it if books with associated book sections were expandable, like items with notes are. As it is, I'm manually reentering publication information each time I add a book section, and manually indicating that they are related.

Perhaps a UI element that allows you to add a book section for the currently viewed book. Also, perhaps Zotero could detect when the "publication" field of a book section matches the "title" field of a book, and offer to fill in everything else for you.

Otherwise I'm really enjoying Zotero so far and I look forward to following its development!
  • I enthusiastically second this request. More generally, it would save a lot of work and duplication if we were able to establish various kinds of relations between items: e.g., translation of X; revised edition of Y; reprint of Z; etc. It would also be nice to be able to draw upon these connections (and the kind of connection) in producing, say, bibliography style guides.
  • edited October 23, 2006
    I think the Zotero team made a design decision (in my view a mistake) that makes this a little awkward.

    In a normalized design, a chapter would be linked to the book it is part of, much like an article is linked to a periodical, a book to a series, and so forth.

    However, the Zotero data model is more flat; a publication is just a field. There's thus no way from the database perspective to avoid duplication.

    That said, as jverber suggests, absent fixing the database design (unlikely), they could do something clever at the GUI level like when a user enters a chapter, the publication title auto-completes. If the user selects an existing title, then, perhaps the rest of the relevant fields get populated.

    I agree this is a frontier that would be really nice to handle. I just stored a bunch of edited books for putting together a syllabus for a seminar next term, and I'd really like if Zotero could somehow automatically break out all 36 chapters from the 4 books, rather than me having to manually do this (a royal PITA).
  • I also second the other relations suggestion from n9bauer, BTW. But I wish this got handled at the database level. This is exactly the sort of thing relational databases (and RDF) are designed for.
  • Well, let's hope we see this in the future OpenOffice bibliographic app... :)
  • bdarcus:
    The way I see it, there are really two issues here: duplication of data entry and duplication of data in the database. Duplication of data entry is, I think, more important in the end because it more directly affects users. However, avoiding duplication of data in the DB could be part of the solution to avoiding duplicate data entry.

    I'm not too familiar with how the dev team has set up the DB, but couldn't a simple change--that is, the addition of a "parent_id" field--make it easier to link chapters to books, etc? Insert a little logic that checks for "parent_id": if it's set, get additional publication info from that publication; if not, get the info from the book chapter, etc. Of course, some additional logic would be needed as well: if a parent publication was going to be deleted, Zotero would have to either a) prompt if children should be deleted as well, b) copy "book" publication data to each "book section" that have that book as a parent, or c) both.

    All that being said, I'm not sure whether there's enough of an advantage to be gained from changing the DB in that way to make it all worth it. Maybe simply doing something "clever at the GUI level" makes sense. In additional to automagically completing form fields of book chapters, Zotero could also check for changes that should be propagated throughout the DB; if I change the publication date of a book, book sections with the same publication title/publisher/pub. date could be updated as well (with or without a prompt.)

    I guess as a (spare-time) coder, I lean towards the DB-side solution, but as a user, if it "just works" I'll be happy.
  • jverber is correct -- there's nothing inherent in the current database design that prevents there from being dependencies/relations and automatically incorporating parent fields in dependent items without duplicating data. Normalizing publications out to a separate table might make a few things easier (and other things more convoluted), but it doesn't avoid any of the issues that make this difficult. You still need a way to select a parent/publication from within another item, still need to prompt the user for what to do on deletes, still need to determine whether the change to publication data in one item changes it in the parent, etc. And you need a mechanism for relating items in complex ways regardless of whether publication data exists independently. Further normalization of publication data might have some benefits down the line, but it doesn't really help much with this--it's the UI issues that are tricky.

    The suggestions for more descriptive relations are good ones, however, and we'll try to incorporate those soon. Further ideas for what other sorts of relations you'd like to see and any special characteristics/behaviors they might have are welcome.
  • Good point Dan; the UI issues are indeed key. OTOH, it sounds like you've pretty well figured them out ;-)

    On the relations, an important one is version relations, which encompass all of jverber's examples. I want to store the 2004 version of Marx's Capital, say, but also need to include the original publisher and publication date (and perhaps title in the original language). Same with any generic kind of translation.

    Reprints are another kind of version relation (a work first published as a journal article and then later in an edited book), though they're less critical because that metadata is seldom if ever included in citation formatting (not so with the other examples).

    Beyond that, the only other relation that might make some sense to recognize is that between an item and an event: a paper presented at a conference, testimony presented at a hearing or trial, and so forth.
  • Sections and versions (incl. translations and reprints) are obvious and make sense. As for the other examples, those seem a little different since I doubt there would actually be a "parent" record of just the conference, but rather just a bunch of paper presentation records which all have the same data. That doesn't mean it's not worth setting up relations between them, though, or having some logic/UI for propagating changes to common data. If things do go in that direction, I might add series to the list.

    The latter type of relationship seems to be "sets": a set of papers presented at a particular conference, a set of testimonies at a particular trial, a set of books from a particular series.

    Anyway, I just have to say, the most frustrating thing for me about EndNote is its stagnation... and unlike OpenOffice's tool, I can use Zotero now... so everyone keep up the good work/suggestions/discussions...
  • Yes, series seems like a good idea as well. It would be nice if Zotero had a set of stock relationships, but also allowed the user to add his or her own, where necessary. My sense is that the rise of internet-based scholarship (e.g., academic blogs) is shaking up (or will shake up) some of the standard formats, so bibliographic software should be flexible enough to accommodate these changes.

    Finally, I hope my reference to OpenOffice wasn't taken as a dig at Zotero. It's already a beautiful piece of software, and I'm sure it'll only continue to improve.
  • I really don't see the relationship between the OOo bibliographic project and Zotero as at all competitive. We're all after the same thing: better, more open, tools. And in fact, success will only come from collective effort. There's way too much weight of inertia behind Endnote (and Word) otherwise. The fact that we're collaborating on the citation style language and RDF stuff is a perfect example.

    In fact, if I had my druthers, we'd just remove the bibliographic support from OOo and make it drop-dead easy for tools like Zotero to serve as data sources for it. It ought to be possible, in fact, to have a common API to integrate these apps into not only OOo, but also any other word processor/editor, including Word. In that case, the part that is specific to document formats and editors is the citation encoding, and maybe the (real-time) formatting of the citations and bibliographies. I was just talking to the KWord lead about this very issue.

    Going back to the RDF, the structure of the format I've been working on (which Zotero partly borrows from) is all based on this sort of flexible modeling. So there are a set of standard properties, including the most important relations, as well a hierarchical class system. Creating new kinds of "types" is really just a question of putting together the pieces in different ways. But, for example, a conference paper gets modeled as a "Paper" presentedAt a "Conference." More flexible, and more robust.
  • Interesting discussion of duplicates, but here's a more immediate practical issue: I'm taking notes on several chapters in an edited volume. In Endnotes, I'd copy / paste one of the chapters, duplicating it, and then edited the information to reflect a different author and title for a different chapter. I don't see any way to create duplicates in Zotero, which would mean having to re-enter everything by hand. Is there a solution?
  • From a users point of view the first and simplest change would be the ability to copy and paste entrys. This would allow to type less when adding another part of a book or another article of a journal.

    Second it would be nice if these pasted entrys would automagically be related.

    And last I second the wish for a relational or hierarchical databank design. I wished for this when I used endnote. Therefore Zotero needs record templates for journals (not only articles), series (not only books) and so forth.
  • Yep, we need copy and paste to duplicate - I know there's a big discussion of hierarchies going on at the moment, but copy and paste to duplicate an item would be incredibly useful in the meantime and for other uses as well. For example, a user might want to experiment on changing an item type without the risk of losing their original data: better to do it on a duplicate.
  • There's an open ticket for duplicating items. I don't know if we'll get to it for 1.0 Final, but we'll try.

    Cartesian: The next beta will give you much better feedback when switching between item types and tell you exactly which fields would be lost, and it'll also preserve more of the equivalent fields (e.g. 'network' to 'studio,' since they're both essentially 'publisher').
  • Not sure if this is still live or whether it ever got implemented. I would strongly endorse the need to relate books and book-chapters. Not just for avoiding duplicating typing, but to ensure consistency of reference (details tend to appear slightly differently when captured from different sources, and it would look sloppy for the same book to be referred to differently when it appeared as part of the citation of one article from how it appeared in the citation of another).

    Also, it is customary in Philosophy (my discipline) when using Name-Date referencing to have the book (published collection of articles, say) only once in the bibliography, and for the individual articles / chapters to appear in the bibliography as
    Bloggs (1998) "Article Title" in ed. Smith (2006).
    i.e. cross-referencing the book, not duplicating all the citation info for it.

    The ability to cross-reference can be important where an article originally appeared in one place, but is reprinted in another, and where the author's page references are to the latter.

    LaTeX with BibTeX can do all of this, simply by including a citation for the book in the citation for the chapter/article. This makes it very flexible (in that respect).

    I really do think there should be some functionality like this built in.
  • This has been discussed as "hierarchical items" - if you search for that you'll find more recent discussions. It's definitely still planned.
  • edited October 23, 2009
    I'm posting again on this thread because I am not much bothered about hierarchical item types. I am concerned, though, about being able to easily generate "book section" items from "book" items. And I think this is such a common requirement, it should be fixed yesterday. To clarify, here's my current workflow to get an item for a chapter in an anthology:

    1) Go to my library web site, find the book, download the book item to Zotero.

    2) Click on the new item in Zotero. Click on item type, select "book section"

    3) Click on title, hit ctrl-x, select book title, hit ctrl-v

    4) Change current "contributor"('s) or "author"('s) to "editor"('s) (is this something only my library does, listing almost everyone as a generic "contributor"?)

    5) Add new field for author, and fill it in

    6) Fill in (now empty) title

    7) Modify page numbers

    It is steps three and four that I want a UI function to cut out, or at least simplify. How about a shift-click when changing from book to book section that will move the title for you, and turn any listed author or contributor into an editor? Come to think of it, how about simply making this the default behavior (does anybody commonly confuse books and book sections, and need to switch between them for a reason other than the one I'm describing?!)
  • Here's how I do it, at least for chapters from edited volumes:
    1. Save the book (container) from some repository, e.g. Worldcat, Google Scholar, or Library of Congress Catalog. (Check whether editors are listed as editors, &c. — for the library of congress they currently get saved as contributors.)
    2. Right-click on the item, 'Duplicate selected item'
    3. Copy Title into 'Book title' field. Insert chapter title in Title field.
    4. Add chapter authors (editors remain)
    5. Add page numbers.

    If I've got a whole lot of chapters from the same book, I first create a 'template' book section item with all common information filled out, and I generate individual chapters from that. I also make sure that the first duplicate is related to the container volume (the book), so that all subsequent duplicates also neatly appear on the 'Related tab' of the container volume.
  • edited October 25, 2009
    I want to support and emphasise the need to implement jverber's request for an easy and time saving way to connect book chapters with books without having to manually re-enter the bibliographical data. The suggestion was put forward 2 years ago. It's time to get this sorted.
    Compliments to all Zotero developers for there excellent work despite this missing must-have feature.
  • Mark, thanks, but my main point remains: Why is your step 3 necessary? If you change a book into a book section, Zotero should at the very least automatically move the old "Title" to the "Book Title" field.
  • Totally agree. That would make perfect sense. Should not be too difficult to implement, too. Let's hope a developer comes by and enlightens us.
  • IINAD but just want to highlight there are two separate issues here.

    (1) supporting book sections properly, in the data model via hierarchical items. This feature has apparently been planned for a long time but I don't know when it might be implemented.

    (2) making it easier to work around this by duplicating a book and changing it to a book section. One way to do this would be, when changing book to book section, move title to book title.

    Number 2 would be better than nothing.
  • After 3 months of using Zotero this is the only significant flaw I have found in it - but it's a biggie.

    (At least the only one to affect me - I am starting from scratch. If I was importing data I think a quick and easy way of eliminating duplicates would also be rather desirable)
  • Just to +1 this suggestion. A good solution would be to right click an edited book, then an entry in the context menu that said 'Add chapter...'. Adding details by hand is quite a shock.
  • while this is up - another +1 for implementing the quick fix as suggested by cartesian and alexuw's 2.) soon.
  • One minor issue-- the short title should be dropped when converting a book into a book section, since it should refer to a short title of the section; it appears that revision 5526 will leave the short title intact.
  • awesome, thanks
  • I'm just +1-ing the request for a more elegant way to store all the chapters in an edited collection--it's not even so much that I mind making 16 separate entries (although it would be nice not to have to do that), as that zotero doesn't realize that they're all from the same book, so it tries to stick them all in the bibliography.

    Anyway, I gather this is somehow in the pipeline, but just in case anyone out there is making a list of "things people are asking for" I figured you could add another vote to the list for prioritizing this one.
Sign In or Register to comment.