Upgrade Storageno DOI field for books?
I added a book to my Zotero library, but it seems like I can't add a DOI for the book, even though it has one (http://dx.doi.org/10.1007/978-0-387-68852-7 if you're curious). Can this field be enabled for books? Am I missing something?
(A more general problem is, how to store DOIs for individual chapters? I don't have any need for that right now, but I'd like to see Zotero work on supporting that.)
(A more general problem is, how to store DOIs for individual chapters? I don't have any need for that right now, but I'd like to see Zotero work on supporting that.)
For example:
American Psychiatric Association. (2000). Diagnostic and statistical manual of mental disorders (4th ed., text rev.). doi:10.1176/appi.books.9780890423349
My suggestion would be
Now, my suggestion would be to allow user to add any field to items of any type - though by default show only those fields, "belonging" to that type of item.
If the user want to add, say, "patent number" to an "interview" item - let it be his responsibility.
There are a few problems with allowing any field on all types:
Thus, ISSN may apply to a report. DOI may apply to a book (or to report). These cases are not typical, therefore not included (yet, at least) - but they make sense.
To your objections. You can't protect any user from inadvertently adding whatever rubbish. And it's really easy in Zotero to inadvertently add some improper reference to a wrong library. On the other side, even if there would appear some "wrong" field in a reference, and the user didn't know what it's good for - he/she would just left it empty. You could also add a warning dialogue before adding a field. Would DOI on a book or ISSN on a report really confuse other users? Normally, if somebody would add a non-standard field, then in a case making sense to him - and probably, to others as well. Well, it's a legitimate argument. Probably, leaving these non-standard data out on export is the easiest solution. Sure. So no problems - they will be probably never used. But others could be used in less-then-typical situation.
And therefore my suggestion - do not try to foresee every possible situation, but include a default set of fields for every citation type - and let the user add more in few special cases, if necessary.
If you can structure an argument for why we'd ever want a patent number on the interview type, you'd probably have the most compelling argument for allowing any field to be assigned to any type. But "let it be his responsibility" is less compelling than the arguments for a simple interface.But then some users would, doubtlessly, complain. Why let people input what will NEVER be output?
Allowing all fields on all types is not even good at solving a majority of the kinds of edge cases that you hope to fix. It seems more common to have some other tidbit of information that is not recorded for ANY type that people want to keep track of that is useful for a source. This is why other programs often have more-than-one "extra" or user-defined field (not that this is an ideal solution either).
I like the easy to use but flexible user interface of the Mac OS X Address Book. There are two modi there. In the "View" mode, only those fields are shown which do contain some information. In the "Edit" mode, the standard fields are shown according to the template. The user can add more fields for any dataset separately if necessary, or he can change the template.
In the current Zotero state, either the developers would add e.g. the "DOI" field for books, which would stay unused in (100-o)% of cases and just take place away. Or they may decide to omit it, with the loss of functionality for those who need it. Similar decisions must be made with "ISSN" for reports (as discussed), "ISSN" and "Publication" for conference papers (which are often published as special issues of regular journals), and presumably in many other cases. "DOI", "ISSN", "Patent number" have or may have an action associated with it (wouldn't it be nice to get on a single click everything about this patent from the repository of your choice?). They may be needed in some specialized styles, now or in the future. Therefore it's preferable to use specialized fields if they apply instead of the "Extra" field.
On the other side, every Zotero item type has the field "Rights" which many users will never use (actually I don't know what it's meant for - nor do I want to know). So, it just takes place away, and place is scarce there. If I could, I would just hide it in my personal Zotero settings.
-------
You asked me to construct some case for using "Patent number" field for the "Interview" item type. OK
Let's imagine a company specializing in patent commercialization. The people there sift through vast quantity of information of any kind - scientific, technical, social, financial. Zotero is a great tool for such tasks.
The people there would exchange information to each other, but not using Zotero groups for information security reasons. The would just share Zotero RDF files.
A large part of the publications the gather deals in one way or another with - you guess, patents. One way to link a publication to a patent would be a Zotero "Related" link. But they are not exportable (are they?). Filling in the "Patent number" field would be the natural solution then.
-------
BTW, the people working in such a company aren't going to publish a lot - they may only produce some internal reports, without any need for a specialized reference formatting. For them, for me, for a lot of people in (industrial) R&D, Zotero is a really great tool - but it's ability to produce a bibliography for a publication is but a nice ancillary feature.
https://www.zotero.org/trac/ticket/1716
Any update about the status? Is it particularly difficult or tricky to implement?
The Zotero team is committed to making these changes happen, but they have to be done right, since -- IIRC -- it may cause sync incompatibility; Zotero 2.2 clients might not be able to sync with Zotero 2.1 clients. That is obviously a situation that we want to cause only rarely.
At support.mendeley.com/customer/portal/articles/723677-adding-new-variables-to-my-citation-style the problem of unsupported fields in Mendeley Desktop is addressed.
The workaround explained there also works for Zotero: Add a DOI to a Zotero item of the type "book", for instance, by putting the line
{:DOI:10.1037/11019-008}
somewhere in the "extra" field. It will then beautifully make its way into the citation of the item.
The entry above can now be written in the Extra field like this:
DOI: 10.1037/11019-008
https://forums.zotero.org/discussion/15636/changes-to-fields-and-item-types-for-zotero-5-1/
Given that the DOI is used by Zotero for retrieving metadata, and given that a DOI is an object identifier for any digital object, shouldn't all Zotero items have DOIs?
(https://forums.zotero.org/discussion/comment/302543,
https://forums.zotero.org/discussion/comment/302591)
yes, all items should have DOIs; yes, all items will get DOIs; no, it's not easy to do because it changes the database and thus affects sync. This is expected for the next major version, i.e. 5.1 (which corresponds to 4.2 above -- the naming just changed around a bit).
The DOI in the extra field works, though, is recognized by citation styles, and will be migrated once the field exists. Items with metadata retrieved by DOI (and an increasing number of other translators) will use that same syntax.
DOIs, btw., are digital identifiers for _any_ object; the object needn't be digital.
DOI: 10.1234/567890
When fields are updated in a soon upcoming version of Zotero, these fields will be migrated automatically.