Is there a way to add book sections more quickly?
Hello,
I'm not sure if this is a feature request or something I just haven't figured out yet.
I'm working with an edited collection that (unfortunately) does not have DOI's for each chapter. I want to add several chapters of the book as entries to my library that can be cited separately.
Is there a faster way to add individual chapters than to first add the entire book (or any section in it) and then copy/paste each field individually while adding a new item? Is there some way to "spawn" (for lack of a better term) a book section from an edited collection or encyclopedia or to create a book section as a child item, or something like that?
Apologies if I'm dense, or this is a perennial request, etc.
Also...When I click the green arrow to add an item, I can't find the option for a web page. Is the only way to do that really to either import it from Chrome (Ugh, I hate Chrome), or add a different source category and then change it?
Finally, I want to say that switching from Mendeley to Zotero has been a life-saver, and despite these questions and requests, I LOVE the program and am so grateful for it.
Thanks!
I'm not sure if this is a feature request or something I just haven't figured out yet.
I'm working with an edited collection that (unfortunately) does not have DOI's for each chapter. I want to add several chapters of the book as entries to my library that can be cited separately.
Is there a faster way to add individual chapters than to first add the entire book (or any section in it) and then copy/paste each field individually while adding a new item? Is there some way to "spawn" (for lack of a better term) a book section from an edited collection or encyclopedia or to create a book section as a child item, or something like that?
Apologies if I'm dense, or this is a perennial request, etc.
Also...When I click the green arrow to add an item, I can't find the option for a web page. Is the only way to do that really to either import it from Chrome (Ugh, I hate Chrome), or add a different source category and then change it?
Finally, I want to say that switching from Mendeley to Zotero has been a life-saver, and despite these questions and requests, I LOVE the program and am so grateful for it.
Thanks!
I’d be open to adding a “Create Book Section” option above “Duplicate Item” for Book items if we think this is something that people are doing enough for it to be worth the extra clutter.
I think adding some version of this to Zotero is worth considering, both because it does save a step and for discoverability
Author --> Book Author
but this isn't as 100% obvious as it may seem (if people are citing chapters from single author books as is sometimes done, they'd probably be better as authors).
Otherwise (just to make this explicit & help think it through) the things you'd regularly do are:
Move title --> book title (already happening)
Add page range -- can't be automated
Add title -- I like opening the field for editing
Add chapter authors -- again, not much we can do
Possibly: change DOI --> This is the most complicated one, especially ones DOIs for books & chapter fully exist/work. Books do have DOIs, but for most edited books with DOIs, so do their individual chapters, so keeping their DOI is tricky, but removing it is also not great: often chapter DOIs just have the chapter number tagged on (like .03). So just fixing the book DOI is quick when it's left it. (This is a [not terribly good] practice by some publisher, not something we can rely on )
The relation thing isn't really a bug, and our implementation currently does the same. It's just that this operation starts by duplicating the parent item, duplicate items include relations, and related-item relations are bidirectional. So:
1) You have book A, and you create book section B, so you have A ↔ B.
2) You then create book section C from A. A is duplicated, which means the relation to B is duplicated, which means C starts with C ↔ B, and then A ↔ C is added. So if you look at B, you'll see both B ↔ A and B ↔ C.
To avoid this, this function would need to ignore related-item relations to either all book sections or to book sections where the title matches the book title. (The reason to do the latter would be to allow book sections to inherit relations to other book sections that the parent item is related to.)
I do think that there is a difference between chapters in an edited volume (which are typically non-interdependent) and the contents of a single-author book where citing individual chapters is more of an exercise in higher-level indexing.
If it is the book-section (rather than the book) that is replicated for second and subsequent chapters then a relationship mesh is avoided.
Last week I added couple of book sections from books and that would have help.
True that the gain in terms of click is not huge but still is nice to have it ready under the mouse :)
So to say what I see, when I create a booksection from a book I will then be on the new item title field so I can enter whatever tittle I want for the chapter. Plus it relates items together.
A note passing by, I had trouble entering authors of the chapters when different from the book : troubles ordering first name with last name, decide to set one or two fields. But this is another issue I suppose.
Thanks!
A number of questions come to mind:
1/ Could this functionality be extended to other Item Types, please? Probably to anything that has chapters, e.g. Theses.
2/ Could a PDF that is associated with the top-level item be automatically associated with the section entr(y/ies)? If not, is there (or could there be) a way of automatically dragging a PDF from one item to another that does not dis-associate it from the first one, which seems to be the current practice?
3/ Would it be at all possible for the relevant number of related sections to be automatically determined and generated by reference to the index of a top-level PDF and, additionally, for the Title fields to be auto-filled? No idea whether this is Utopian, or not.
I agree with @ajb59 & @gpatten : having too many unstructured related items is not really practical.
It would still be useful to be able to see quickly all book chapters of a book from any chapter. But this information probably should not be implemented as a direct relationship. This should be done at a higher level, with only the direct relations book to book chapter really needed.
This could be achieved by a more general feature: showing the second degree related items rather than only the direct relations. In this way, the book chapter will see the book as first degree relation, and then all book chapters connected to the main book would naturally appear as second degree connections. Connecting all book chapters directly will probably lead to a lot of unnecessary cluttering, with a strong probability of missing some of the connections at some point.
Ideally, there should be a dedicated directional relation between a book and its book chapters. But I don't know what is the status on developing different types of relations, hierarchical relations, directional relations, semantic relations, ...?
I'd propose to remove the initial item relations after duplicating the book item:
1. Book: item1 [related1, related2]
2. Duplicate it: item2 [related1, related2]
3. Remove related items: item2
4. Relate book and new book section: item1 [related1, related2, item2], item2 [item1]
The items [related1, related2] could also be journal article items that are related to the book, but which aren't necessarily related to all the book sections. You could add a URI attachment to the book section item with a zotero://open-pdf link to a specific page in the book, see here.
Wow.. Right now wanted ask about the relations!!!
Thanks!
Sincerely,
Andrey
Also, is the an a way to note a (most often independent) Section Author?
Thanks
Edit: I just found this https://www.zotero.org/trac/ticket/210 and did a bit more searching. It seems that nesting is really a database structure issue and quite a significant technical challenge - one that's been on the radar for some time. I interpret, "related" as the fallback for now with the implementation of nesting not currently scheduled. Would that be correct @dstillman? Thanks