PubMed import partially broken
This is an old discussion that has not been active in a long time. Before commenting here, you should strongly consider starting a new discussion instead. If you think the content of this discussion is still relevant, you can link to it from your new discussion.
Can someone else confirm that this is not working?
But why not place it in the old place? I see no reason to just leave it empty. That just makes it harder for those looking at it. Please make the DOI clickable instead.
Also, when you import the item from PubMed, the Library Catalog field should say "NCBI PubMed".
I still think the change is a very, very bad idea. And I see other translators that does save the URL too.
Going to the DOI is just a bad idea if you just want to have a look at the abstract. Pubmed is just more readable. It is two very different kind of links.
Please revert this change. I have read the thread but I can see no clear logic for the change. If there is one then perhaps it can be written down in a sentence or two so we can discuss the logic? ;-)
"URLs should only be included for items that include the full text of a work (such as journal publishers, google books, but also full-text databases like Proquest and JSTOR), not for catalogs like PubMed or Library Catalogs, that only contain bibliographic information."
There are good bibliographic reasons for that: A URL which is in the URL field may be cited (either if there is no page range, or if the "include URL" box is checked). That means you accessed the article on Pubmed, which isn't true --> your citation is wrong.
(This will solve itself in the medium run - we'll get a PMID field in Zotero which then can be made clickable just like the DOI field is now).
With this logic you can of course not include the URL for a book unless it is an electronic book, or? ;-)
More troublesome is that if you include the link to the full text of an article with restricted access many people can not see even the abstract without trouble. All you do is actually giving the publisher a link for free. From the readers point of view it is a bad decision.
The bibliographic reason seems useless. You create bibliographic references from within Zotero and that reference does not depend on if the Pubmed URL is in the entry in Zotero or not.
So again: Please revert this change! When the PMID field is clickable both in the web interface and in the Zotero standalone interface it could be introduced as an option - perhaps. (Though I still can see no good usage of that option. Unless people really, really want to got directly to the DOI page instead of to Pubmed first.)
It just seems like you're misunderstanding the distinction here: The URL field _only_ matters for bibliographic purposes. For everything else, the attached link has the exact same use. I don't know why that's not working for you, but that's an entirely separate issue that should probably be moved to a new thread.
Yes, I know there is no link attached for example when I save from a Google Books page. And that is quite troublesome. It means the users of the library where I save this will have a lot of trouble finding the books. They are not librarians. They are professionals who needs the book. So I think it is a bad decision too.
If the URL field is used for bibliographic information then the URL has to be stored somewhere else because users often need the URL from where the information was saved to Zotero. So please add the URL somewhere else before removing it from Pubmed! (And it to to Google Books for example the same way.)
Most references I save are to paywalled sources. Most professional users reading the references do not have access to the sources. So again that is why the URL used for saving is important.
A bit of history: When Pubmed was created it was a public secret among those interested in the access to the abstract that Pubmed actually was not allowed to save even the abstracts. I know because we did not dare to use the abstracts in internal databases. Now this is history (because of Google and other search engines) so anyone have access to the abstract in an indexed form.
"Or you can enable PDF attachments in Preferences -> General -> Automatically attach associated PDFs and other files when saving items"
Now it works for both Pubmed and Google Books, i.e. a link with the URL is attached. (It did not work last time I tested. Or did I do something wrong then? Hm, there is not very much I could do wrong...) That is nice. ;-)
However I am unable to test this in the web interface because the new entries does not show up there even after clearing the cache in Google Chrome (and syncing Zotero). I will check again later.
Thanks for the help. It seems like this could be a good solution then. (If the web interface works too, since most users will use that.)
As far as "the critical importance of the URLs in citations" goes, I believe DOIs provide a much better alternative.
I wouldn't hold my breath waiting for PubMed URLs to make it back into the URL field. It's unlikely to happen.
Rather than stating that in some "not super-distant" future there will be a good work-around for the users affected by this change, why not back out the change until the work-around is actually available.
I understand the importance for many Zotero users of being able to include url's pointed to PubMed (we want to do this), and why they would be upset at the removal of this long time feature for what are apparently theoretical reasons (I did not see any mention of large numbers of user complaints about the way it was working before).
One of the advantages of open source environments is the ability to quickly respond to user concerns.
When you make a change that upsets many users and disrupts their use of the product, why not be open to backing it out until you have a good solution for the affected users ?
And it is clear that a good solution means an easy way to include a clickable url for PubMed.
I believe that this is a win-win approach, and will build community rather than divide it.
The advantage of open source is not really that we can respond more quickly to users than proprietary software (why would that be the case?), but that you (or anyone else interested with the necessary (in this case not very significant) skills) can change/adjust things in the code that you don't like (and then share her/his solution.
If you're interested we can give you some pointers on what to do.
I'd also like to point out that the "many users" you're referring to have been four so far (you included), of which one (beogl) was satisfied once the new solution was working for him correctly.
Actually, I did propose a viable solution.
I proposed deferring the PubMed import change until the dedicated PMID field was added to Zotero. That seems pretty viable to me. You can still make the change since you feel so strongly about it, but we are asking you to wait until a work around is available.
You are changing an aspect of Zotero that has been present for six years, so it is not clear what the rush is.
I am proposing a compromise where the import change still gets made, but is deferred until a good work around is available.
I also think that calling clickable links to PubMed "wrong data" is a bit extreme. PubMed abstracts are a key and reputable tool for medical science. It is clear to me (and many others) that PubMed links in citations are very useful for practicing physicians and busy researchers.
We are aware of other users who have been adversely affected by the change so I believe that this forum is a "tip of the iceberg" as far as the impact.
Our group have been considering contributing code to Zotero development, but if your tone is representative of the community attitude, it does not feel very welcoming.
As we've said repeatedly here, that's not something we consider a viable solution, not even intermittently.
I've offered to help you with a workaround, so I'm not sure why you consider my tone unwelcoming to people interested in contributing to Zotero, that's certainly not my intention.
Thank you for your note on another possible solution.
I am not familiar with hidden Zotero preferences.
Is there some documentation that you can point us to which discusses hidden preferences and how to create code for them ?
You can look for instances of Zotero.Prefs.get() in the code. Default prefs are stored in defaults/preferences/zotero.js. (Prefs don't need to be defined there, but if put there they'll show up in about:config, which makes changing them easier.)