The way I see hierarchical item types you would have
Edited Book (includes publisher, year, editor, no. of pages, ISBN) ----Chapter 1 in Book (author, title, page range) ----Chapter 2 in Book etc.
Same logic for conference proceedings
Proceedings Book/Volume (incl. publisher, year, editors, conference date&locationg) -----Paper 1 published in Proceedings (author, title, page range -----Paper 2 published in Proceedings (author, title, page range etc.
My general point being that we would want parent item types for systematic and data storage purposes anyway with hierarchical item types. Without them, such an item type has much less of a purpose.
But in this case, we would still need to add a separate item type for "Proceedings Book/Volume".
I had thought of implementing hierarchical items simply as pseudo-items, where, if you enter a published conference paper for example, it automatically nests it under a conference proceedings "item" (but that wouldn't be citable directly or exportable on its own. Sort of for display and batch editing purposes only). But seeing how such an item (as we seem to have concluded) needs to also be citable, there must then be an independent conference proceedings item.
Edit: I guess my point is that whether hierarchical item types are coming sooner or later doesn't really matter, because this item type would still have to exist.
On the CSL side we don't need an item type. We can just treat this as a book and add event place and date when it exists in the data.
Which leaves us with the representation of this in Zotero....
I haven't been following the thread closely, but there will be an implementation issue with adding event-place to the book type. In Zotero, event-place and publisher-place are both derived from a database "place" variable, and are treated as equivalent when data is shipped to the CSL processor. The relevant code is here (at lines 56 and 74).
The limitation can be overcome easily enough with a migration to separate internal DB values, but the migration would be needed before adding the field to the book type.
thanks Frank - yes I'm aware of the place mapping mess, adding those to book items was intended to be conditional on my earlier
oh, we'll definitely want to do this. Conference Paper needs two locations and two dates (see also https://github.com/ajlyon/zotero-bits/issues/6 ) CSL already has event-place and event-date.
yeah, but bibtex doesn't have the same constraints as Zotero. If you're a GUI-less format, you can just add a field and/or item type for whatever you need--BibLaTeX has taken that to the extreme. Certainly has its advantages, but we can't really use it as a model. (Also, bibtex does have hierarchical item types, which is something I'd really like, but isn't going to happen in Zotero even in the medium run).
Upgrade Storage
Edited Book (includes publisher, year, editor, no. of pages, ISBN)
----Chapter 1 in Book (author, title, page range)
----Chapter 2 in Book
etc.
Same logic for conference proceedings
Proceedings Book/Volume (incl. publisher, year, editors, conference date&locationg)
-----Paper 1 published in Proceedings (author, title, page range
-----Paper 2 published in Proceedings (author, title, page range
etc.
My general point being that we would want parent item types for systematic and data storage purposes anyway with hierarchical item types. Without them, such an item type has much less of a purpose.
I had thought of implementing hierarchical items simply as pseudo-items, where, if you enter a published conference paper for example, it automatically nests it under a conference proceedings "item" (but that wouldn't be citable directly or exportable on its own. Sort of for display and batch editing purposes only). But seeing how such an item (as we seem to have concluded) needs to also be citable, there must then be an independent conference proceedings item.
Edit: I guess my point is that whether hierarchical item types are coming sooner or later doesn't really matter, because this item type would still have to exist.
The limitation can be overcome easily enough with a migration to separate internal DB values, but the migration would be needed before adding the field to the book type.
https://github.com/willsALMANJ/Zutilo/issues/27#issuecomment-67166649
this page was cited:
http://tex.stackexchange.com/questions/123252/how-to-manage-conference-proceedings-in-bibtex/123254#123254
Zotero has no @proceedings, correct?
added a ticket to track this: https://github.com/avram/zotero-bits/issues/67