-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOI #1
Comments
There are likely to be more item types that are assigned DOIs in practice. It would be helpful to identify these, so documented examples are welcome. See also http://en.wikipedia.org/wiki/Digital_object_identifier#Applications |
How about adding it to every item type? Even the non-published types (manuscript) could be assigned a DOI by an ambitious archive with online repositories. |
+1. |
The types that are already identified by URIs (webPage, forumPost, blogPost, podcast) should probably never have a DOI, and I'd like to keep the field out of there. I'm also not sure if this is useful for legal types, patents, etc., but I could be convinced. |
I can abide keeping it out of webPage, forumPost, blogPost, podcast, and the legal types for now. The next direction to go with identifiers is something more flexible, with defined identifier classes and multiple identifiers per item (a la creators), so those types can get DOIs at that point if necessary. Although note that WebCite does encourage publishers to assign DOIs to archived versions of web content:
|
In light of this, I think it would be okay to the web items as well, although it creates a bit of a mess when one URI refers to a live page and another refers to an archived page. |
I've edited the description to reflect that DOI would be added to all item types. This may be over-aggressive, since we still don't have evidence that this could appear for patents and legal cases (except if WebCite is used to archive them). |
The DOI should certainly be added for Reports. Government Reports will have a DOI. |
the ticket is for all item types. |
@adam3smith, still think the DOI should be available to all item types? I'm e.g. not aware of any patents with DOIs. I guess this decision might also depend on whether Zotero will allow fields to be rearranged/hidden. |
I think we should go with all item types -- currently no DOIs for patents, but it'd be really nice if there were... so maybe someone will go ahead and do that. |
Just to bump this. It seems as though DOIs are being added for many things now, and that an item having both a DOI and URL can be sensible. |
No reason to bump this; I don't think there's any disagreement, there just haven't been any field/item changes in Zotero for other reasons. |
Sorry, wasn't meaning to be rude. I just figured since there's been no comments on this thread since 2016 it may have been forgotten about. |
nothing to apologize for. But for most of these tickets, lack of activity doesn't mean they won't get addressed. Generally, anything with the 5.1 milestone is almost certain to be included in the next Zotero version that does handle field updates. |
I want to add just a small idea on that, don't know if it makes a lot of sense technically (after reading this): maybe it is an idea to make it analogously to the authors fields (which allow to be multiple of different types):
This would allow for adding multiple RefIDs of different type(s) to an item and be open for future extensibility while at the same time consolidate those into a hierarchy. |
I would like to add here also a strong support of allowing a doi for all types of references. As research gets more and more digital, so are items that get a doi. ResearchGate automatically assigns doi's to items, and also datasets (Zenodo) and figures (Figshare) work with doi's. |
- Add DOI to all item types (closes zotero/zotero-bits#1) - Add `citationKey` to all item types (closes zotero/zotero-bits#24) - Add `date` to `podcast` (closes zotero/zotero-bits#2) - Add `ISSN` to additional types (closes zotero/zotero-bits#4) - Add `section` to `journalArticle` (closes zotero/zotero-bits#5) - Add `PMID`, `PMCID`, and `arXiv ID` to `journalArticle` (closes zotero/zotero-bits#10) - Add `originalPlace`, `originalPublisher`, and `originalDate` to `book` and `bookSection` (closes zotero/zotero-bits#13) - Add `priorityDate` to `patent`, mapped to `originalDate` (closes zotero/zotero-bits#76) - Add `partNumber` and `partTitle` to `journalArticle` (closes zotero/zotero-bits#12) - Move `shortTitle` and `language` near the bottom, since most people either won't use them or will use them purely as a technical measure to adjust citation output - Move `libraryCatalog` and `callNumber` to the bottom, above rights, since they never made that much conceptual sense in Zotero (and `libraryCatalog` is mostly just used for the translator name these days)
- Add DOI to all item types (closes zotero/zotero-bits#1) - Add `citationKey` to all item types (closes zotero/zotero-bits#24) - Add `date` to `podcast` (closes zotero/zotero-bits#2) - Add `ISSN` to additional types (closes zotero/zotero-bits#4) - Add `section` to `journalArticle` (closes zotero/zotero-bits#5) - Add `PMID`, `PMCID`, and `arXiv ID` to `journalArticle` (closes zotero/zotero-bits#10) - Add `originalPlace`, `originalPublisher`, and `originalDate` to `book` and `bookSection` (closes zotero/zotero-bits#13) - Add `priorityDate` to `patent`, mapped to `originalDate` (closes zotero/zotero-bits#76) - Add `partNumber` and `partTitle` to `journalArticle` (closes zotero/zotero-bits#12) - Move `shortTitle` and `language` near the bottom, since most people either won't use them or will use them purely as a technical measure to adjust citation output - Move `libraryCatalog` and `callNumber` to the bottom, above rights, since they never made that much conceptual sense in Zotero (and `libraryCatalog` is mostly just used for the translator name these days)
The "DOI" (DOI) field (mapped to DOI in CSL), currently available for journalArticle and conferencePaper, should be added to all remaining item types.
https://www.zotero.org/trac/ticket/1716
The text was updated successfully, but these errors were encountered: