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.

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.

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.

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.

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.

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?

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.

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.

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?!)

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.

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.

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)

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