As stated elsewhere (https://forums.zotero.org/discussion/comment/177040) already, a field (and CSL variable) for the ECLI (European Court Law Identifier) is necessary. It’s an ID for identifying juridic acts, unified for all EU and EU member states’ jurisdictions. It’s an accessory ID and does not supplant the traditional case numbers/docket numbers. However, it’s gaining importance in digital referencing a case. Thus, the ECLI is often recommended to be added to citations. Contrary to a comment in the aforementioned thread, it shouldn’t be entered in the field “docket number” as the citation styles will usually require the human readable docket number to be included as well.
I am late to this thread and as others have said it's difficult to follow where this is, but I'm hoping that this is a small request - would it be possible to rename Manuscript at least in the UI (it can stay as an item type in the code) into something less specific to cover all the grey literature such as press releases etc, such as Papers? Manuscript comes close to what I need other than not having a Number field (which I can work around) but is completely non-intuitive to other users of my group library. Or if we could extend 'Document' to include the fields for Manuscript and Number, that would be even better. Document feels like the obvious place, but it just doesn't have enough fields.
Manuscript is not a good fit for such items. Report or Website would be better. If you need extra fields from what is currently provided until an update, you can add them to the Extra field.
I'm working on a large-scale project that will have a discography section and a videography section. I've used Zotero for years (over a decade now??), and most of my citations live in it. My issue? Zotero does not have a field for what's called the issue number for audio recordings. In MARC tags (library catalogs and OCLC use this), the field is 028 |a (|b is the publisher or label).
I've asked about this some time back, and am asking again for it. I use (and many of my colleagues use) a modified form of CMOS to include the label and issue number because it is crucial in discography -- and in many music publications. Why? The issue number identifies the particular release of that recording. When dealing with LPs from certain labels, that can indicate mono or stereo, and in the case of CDs, it can sometimes help the researcher identify if an item is a reissue from LP to CD.
While the current CSL styles out there don't include the issue number-- at least that I could find, I'd wind up adapting the one for CMOS 17 (and subequent releases) to include the issue number, if it were a field in Zotero.
Any other music scholars and librarians needing the issue number field ???
As you can see, in both cases there are identifiers after the label (50-1102 or CD-ATR1207), both of which have no similarity with "2nd edition", "3rd edition", ...
I mean, format of the citation isn’t the issue. As far as I can see, the identifier for the release would seem to conceptually align with edition, or perhaps with version or number. For styles that need to cite release number, appropriate tests could be added to the macros that call those variables to indicate the format for recordings versus other item types. For styles that don’t generally require release numbers, I think that including it would rarely be problematic, and most users would not enter it into their database anyway.
I've been using Zotero for many years. Here is my take on item types and item fields.
Instead of tediously gatekeeping what types and fields Zotero can handle, with users pleading for feature additions – why not make Zotero ever so slightly extensible?
Apologies if this has already been suggested before:
(a) extensible ========
My suggestion would either be to either use the extra field or add an extension field. Then, settle on a mini syntax to allow Zotero to be extended by how the user wishes.
(1) Example. {extension: Foo as item-type} would alias the item's type and let the user rename the item type to a name that was more natural for them for when they feel the type's fields are okay but the name is slightly off – Zotero could have a custom item type icon.
(2) Example. {extension: original-date as date} would mimic an item's field using the existing field as a template.
(b) hierarchical =========
As has been suggested elsewhere, types should be hierarchical/nested. It is so obvious that book sections nest within books which in turn nest within book series, and articles within issues within journals, and webpages within web-sections within websites, and so on. Frankly it puzzles my why this capability does not yet exist in Zotero. How this nesting mechanism is implemented could be implemented is unclear. Again, you could solve for common and obvious use cases and provide some kind of user customisation, namely: allow items to be related and define some default relationship types but allow the user to add their own relationship types for the use cases the developers have not envisioned.
---
Given the amount of people who bother to go to the trouble to ask either for a certain item type to be added to Zotero (noting that an existing item would be perfect except that the name is wrong) or for a certain item field to be added to Zotero (noting that an existing item is perfect but it's lacking a field) why not admit that the creators of Zotero can't envision all the different things that people would like to keep track off and make Zotero ever so slightly extensible? For every person who makes a feature request how many more have had the thought but not gone to the trouble of going to the forum and making their voice heard?
@igravious: This is a fundamental misunderstanding of the situation.
There's no "gatekeeping", and we're not somehow unaware that the current fields are inadequate. There have been no changes to types or fields at all for many years for extremely complicated technical reasons related to syncing. There's a very long community-curated list of changes that will be implemented as soon as it's technically possible. We've made progress on that recently and hope to have something relatively soon. Additional types and fields have been usable for citation purposes via the Extra field for many years.
Having custom types and fields is an entirely separate issue, and we've said many times over the years that we hope to support that, but it's even more technically complicated than the large agreed-upon list of new types and fields and certainly isn't going to happen until after those are added.
@dstillman : the usage of extra field for additional fields leads to a very cluttered extra field that contains all the necessary modifications. Think as an example the need for an annotated bibliography. Since there is no inbuilt annotation field it will go into the Extra. Maybe that entry also needs other additional fields as well, so they go into the extra. Maybe that entry needs some adjustments to properly export to a .bib file so betterbixtex adjustments go to the extra.
If sometime later you go over your library to locate a relevant entry by quickly browsing the annotations, that annotation is buried with other modifications and that makes the review harder for you.
Once I thought maybe I should use other fields to store my annotations. Yet no other field holds a paragraph value.
For this particular example, an addition of ''annotation'' field to all types would solve the problem.
But as it is clear from the length of this forum title, extensibility of the available fields is a popular request that is somewhat urgent.
I'm a bit late to the discussion ;) In any case, I think there has been a lot of progress in the recent years on how to cite datasets (even if they change over time; the resulting challenges seem to be subject of current research; some people create several DOIs, some add a timestamp in the citation,... -- see also DataCite: https://datacite.org/). For example, Zenodo has a clear distinction between datasets and other resources, it seems to me: https://zenodo.org/
Datasets are well covered by planned updates. There are specific guidelines for how to currently import them (see https://www.zotero.org/support/dev/translators/datasets ), the will merge to their own item type once that exist, and Zotero already supports import of Datacite DOIs as well as direct import from Zenodo, Dryad, and Dataverse among others.
It seems to me that there is a difference in what information people envisage Zotero should be able to manage.
Based on what exists NOW, it seems to follow that there are some categories that are missing, I think we need to be more consistent and inclusive: (1) Images: not "Artwork", but captured images, either digitally, chemically or even hand-drawn sketches
(2) Physical event: by this I mean the actual thing that occurred. Whether it was an assasination, plane flying into a building, meteor striking earth and wiping out dinosaurs etc etc. There might well be a RECORDING of it, and maybe some DISCUSSION, but that's NOT the EVENT.
Let's say you are writing about US Presidents, and you state that a number were assassinated. So how do you reference that? Often you would quote some report that mentioned the details, but why is that the only way? Why can't you make just make a reference to the physical location, and the time? Either a geographical location, or Latitude & Longitude, or GPS co-ordinates. And a time: Year/Month/Day etc etc.
The following might be covered by Presentation: (3) Spoken content (which could be a public speech, or a statement by someone. It shouldn't have to be by TV Broadcast, Radio or Video: I'm talking about the ACTUAL event where the words were said. I see no reason why they need to be RECORDED or TRANSMITTED either. If it was spoken, and people HEARD it, then it's by definition a RECORD. At least in their memories.
(4) Audio/visual Performance: as in a play, poetry reading, ballet, singing etc etc. It might well be a one-off, and not recorded anywhere except in the receiver's memories. But it still has just as much validity as something that's recorded and stored via some electrons in a computer.
And perhaps you could squeeze in "Physical Event" too under Presentation, but it's not really what I mean't.
Thanks very much. And I really appreciate your work on this: I see you are very active in the discussions.
Retraction Related: And sorry if this was discussed, but I didn't see it. There's already a Retraction link, and a related one would be for Specifications/Standards if they are Revised, Replaced, Withdrawn etc etc.
I suspect that would need to be addressed on a case by case basis: for each standards organisation.
But although there are thousands of standards bodies, I think 80% of the ones where knowing that would be really important are issued by a few dozen standards bodies. As in ISO, CEN, ASTM, ANSI, SPI, API etc etc.
@bjohas -- better to take this to a different thread. Code-wise, it's completely unrelated to new item types (i.e., allowing new fields as columns in the middle panel, e.g., can be done at any time, including now) FWIW, Zotero purposefully groups items with different labels but the same role in the database together. E.g. "institution" is just "publisher" with a different name and will show up under that label in the middle panel and is searchable under that label. The indidivual fields of such a term are shown as hover-over in the advanced search and the main field are displayed in parentheses in the field mapping on https://aurimasv.github.io/z2csl/typeMap.xml#map-report
Does this depend on the DOI? I have numerous cases of this problem for older reviews without assigned DOI: although entered as articles, Zotero lists them all in the duplicates folder together with their books, although it does then recognise when I select them that they can’t be combined because they are of different types.
I have come around to the position (argued by @adamsmith in a previous discussion on this topic) that a book review item type would be a suboptimal solution to the problem, since it would preclude me from noting the form in which the review appears. Instead, I use a tag, which has the (for me, decisive) advantages of being (a) highly visible and (b) applicable not only to articles, but also to websites, podcasts and book sections.
Yes, currently it does depend on the DOI, but that's just because of how the duplicate detection code works. I think I've said before that that should improve, but if the only case for a new item type is to prevent duplicates*, I don't think that's a convincing case. That just means duplicate detection needs to get fixed.
*I don't actually think that's the case for book reviews -- some people want a book review item type for other reasons
I have come around to the position (argued by @adamsmith in a previous discussion on this topic) that a book review item type would be a suboptimal solution to the problem, since it would preclude me from noting the form in which the review appears.
How so? If it was designed properly then it would be able to capture all relevant information.
Generally enter book reviews as Journal Article and include the review DOI. Those won’t be marked as duplicates.
Unfortunately, this does not solve the problem for me.
I have three book reviews of the same book. All have the same title, two have a DOI (I have yet to find one for the third article) yet the only way I can stop them from duplicating is to change the title - which is obviously not possible. The two with DOI show as duplicates of each other, and if I place a stable URL in the third it makes no difference.
Even if the DOI was successfully used to prevent duplicates, it is a suboptimal solution. Not all sources have a DOI, I understand that the use of DOI is progressively becoming more common, yet for older resources it continues to be an issue.
I think I've said before that that should improve, but if the only case for a new item type is to prevent duplicates*, I don't think that's a convincing case. That just means duplicate detection needs to get fixed.
I see your point. Although, if a new type fixes the duplicate issue then its worthwhile. This has been a persistent issue without a resolution for some time.
Whilst duplicates are the most irritating issue, it's not the only reason for a dedicated item type for me. I have been using the term 'Book Review' but a more accurate term would be 'Review Article'. In my field, there are a number of articles that review other articles also. Sometimes the title is the same as the original and sometimes they are not. In the case of ther former, this can get very confusing as both the original and review are in a 'Journal Article' format. A dedicated item type can makes this cleaner.
Upgrade Storage
I've asked about this some time back, and am asking again for it. I use (and many of my colleagues use) a modified form of CMOS to include the label and issue number because it is crucial in discography -- and in many music publications. Why? The issue number identifies the particular release of that recording. When dealing with LPs from certain labels, that can indicate mono or stereo, and in the case of CDs, it can sometimes help the researcher identify if an item is a reissue from LP to CD.
While the current CSL styles out there don't include the issue number-- at least that I could find, I'd wind up adapting the one for CMOS 17 (and subequent releases) to include the issue number, if it were a field in Zotero.
Any other music scholars and librarians needing the issue number field ???
Thank you for reading and considering!
Mendelssohn[-Bartholdy, Felix]: Concerto for Violin, Piano &
Strings, String Quintet Nr[.] 2 (Camerata Bern, Antje Weithaas,
Alexander Lonquich), CD, Pully (Switzerland): Claves Records
50-1102, 2010.
Fanfare Ciocarlia: Queens and Kings, CD, Berlin: Asphalt Tango CD-ATR1207, 2007.
As you can see, in both cases there are identifiers after the label (50-1102 or CD-ATR1207), both of which have no similarity with "2nd edition", "3rd edition", ...
Instead of tediously gatekeeping what types and fields Zotero can handle, with users pleading for feature additions – why not make Zotero ever so slightly extensible?
Apologies if this has already been suggested before:
(a) extensible
========
My suggestion would either be to either use the extra field or add an extension field. Then, settle on a mini syntax to allow Zotero to be extended by how the user wishes.
(1) Example. {extension: Foo as item-type} would alias the item's type and let the user rename the item type to a name that was more natural for them for when they feel the type's fields are okay but the name is slightly off – Zotero could have a custom item type icon.
(2) Example. {extension: original-date as date} would mimic an item's field using the existing field as a template.
(b) hierarchical
=========
As has been suggested elsewhere, types should be hierarchical/nested. It is so obvious that book sections nest within books which in turn nest within book series, and articles within issues within journals, and webpages within web-sections within websites, and so on. Frankly it puzzles my why this capability does not yet exist in Zotero. How this nesting mechanism is implemented could be implemented is unclear. Again, you could solve for common and obvious use cases and provide some kind of user customisation, namely: allow items to be related and define some default relationship types but allow the user to add their own relationship types for the use cases the developers have not envisioned.
---
Given the amount of people who bother to go to the trouble to ask either for a certain item type to be added to Zotero (noting that an existing item would be perfect except that the name is wrong) or for a certain item field to be added to Zotero (noting that an existing item is perfect but it's lacking a field) why not admit that the creators of Zotero can't envision all the different things that people would like to keep track off and make Zotero ever so slightly extensible? For every person who makes a feature request how many more have had the thought but not gone to the trouble of going to the forum and making their voice heard?
There's no "gatekeeping", and we're not somehow unaware that the current fields are inadequate. There have been no changes to types or fields at all for many years for extremely complicated technical reasons related to syncing. There's a very long community-curated list of changes that will be implemented as soon as it's technically possible. We've made progress on that recently and hope to have something relatively soon. Additional types and fields have been usable for citation purposes via the Extra field for many years.
Having custom types and fields is an entirely separate issue, and we've said many times over the years that we hope to support that, but it's even more technically complicated than the large agreed-upon list of new types and fields and certainly isn't going to happen until after those are added.
If sometime later you go over your library to locate a relevant entry by quickly browsing the annotations, that annotation is buried with other modifications and that makes the review harder for you.
Once I thought maybe I should use other fields to store my annotations. Yet no other field holds a paragraph value.
For this particular example, an addition of ''annotation'' field to all types would solve the problem.
But as it is clear from the length of this forum title, extensibility of the available fields is a popular request that is somewhat urgent.
In any case, I think there has been a lot of progress in the recent years on how to cite datasets (even if they change over time; the resulting challenges seem to be subject of current research; some people create several DOIs, some add a timestamp in the citation,... -- see also DataCite: https://datacite.org/).
For example, Zenodo has a clear distinction between datasets and other resources, it seems to me: https://zenodo.org/
Forget what I said then ;) :)
It seems to me that there is a difference in what information people envisage Zotero should be able to manage.
Based on what exists NOW, it seems to follow that there are some categories that are missing, I think we need to be more consistent and inclusive:
(1) Images: not "Artwork", but captured images, either digitally, chemically or even hand-drawn sketches
(2) Physical event: by this I mean the actual thing that occurred. Whether it was an assasination, plane flying into a building, meteor striking earth and wiping out dinosaurs etc etc. There might well be a RECORDING of it, and maybe some DISCUSSION, but that's NOT the EVENT.
Let's say you are writing about US Presidents, and you state that a number were assassinated. So how do you reference that? Often you would quote some report that mentioned the details, but why is that the only way? Why can't you make just make a reference to the physical location, and the time? Either a geographical location, or Latitude & Longitude, or GPS co-ordinates. And a time: Year/Month/Day etc etc.
The following might be covered by Presentation:
(3) Spoken content (which could be a public speech, or a statement by someone. It shouldn't have to be by TV Broadcast, Radio or Video: I'm talking about the ACTUAL event where the words were said. I see no reason why they need to be RECORDED or TRANSMITTED either. If it was spoken, and people HEARD it, then it's by definition a RECORD. At least in their memories.
(4) Audio/visual Performance: as in a play, poetry reading, ballet, singing etc etc. It might well be a one-off, and not recorded anywhere except in the receiver's memories. But it still has just as much validity as something that's recorded and stored via some electrons in a computer.
And perhaps you could squeeze in "Physical Event" too under Presentation, but it's not really what I mean't.
And I really appreciate your work on this: I see you are very active in the discussions.
Retraction Related:
And sorry if this was discussed, but I didn't see it.
There's already a Retraction link, and a related one would be for Specifications/Standards if they are Revised, Replaced, Withdrawn etc etc.
I suspect that would need to be addressed on a case by case basis: for each standards organisation.
But although there are thousands of standards bodies, I think 80% of the ones where knowing that would be really important are issued by a few dozen standards bodies. As in ISO, CEN, ASTM, ANSI, SPI, API etc etc.
(Rest of comment moved to: https://forums.zotero.org/discussion/88389/listing-of-fields-in-advanced-search-and-middle-column)
FWIW, Zotero purposefully groups items with different labels but the same role in the database together. E.g. "institution" is just "publisher" with a different name and will show up under that label in the middle panel and is searchable under that label. The indidivual fields of such a term are shown as hover-over in the advanced search and the main field are displayed in parentheses in the field mapping on https://aurimasv.github.io/z2csl/typeMap.xml#map-report
I have come around to the position (argued by @adamsmith in a previous discussion on this topic) that a book review item type would be a suboptimal solution to the problem, since it would preclude me from noting the form in which the review appears. Instead, I use a tag, which has the (for me, decisive) advantages of being (a) highly visible and (b) applicable not only to articles, but also to websites, podcasts and book sections.
*I don't actually think that's the case for book reviews -- some people want a book review item type for other reasons
@bwiernik Unfortunately, this does not solve the problem for me.
I have three book reviews of the same book. All have the same title, two have a DOI (I have yet to find one for the third article) yet the only way I can stop them from duplicating is to change the title - which is obviously not possible. The two with DOI show as duplicates of each other, and if I place a stable URL in the third it makes no difference.
Even if the DOI was successfully used to prevent duplicates, it is a suboptimal solution. Not all sources have a DOI, I understand that the use of DOI is progressively becoming more common, yet for older resources it continues to be an issue.
@adamsmith I see your point. Although, if a new type fixes the duplicate issue then its worthwhile. This has been a persistent issue without a resolution for some time.
Whilst duplicates are the most irritating issue, it's not the only reason for a dedicated item type for me. I have been using the term 'Book Review' but a more accurate term would be 'Review Article'. In my field, there are a number of articles that review other articles also. Sometimes the title is the same as the original and sometimes they are not. In the case of ther former, this can get very confusing as both the original and review are in a 'Journal Article' format. A dedicated item type can makes this cleaner.