"Find available PDF" - look at url in metadata and attachment urls?
Hello,
it would be amazing if "Find available PDF" also looked at the url in metadata and attachment urls. We imported a large RIS library, some with DOI, some without. But many items have a (freely available) PDF, that is either in the url in metadata and attachment urls. While it's not difficult to get the items, we still have to click the item (or copy to wget) and then click again (or drag) to get to Zotero. It would be so much neater if it was just one click.
We have ~2,000 items. So one right click "Find available PDF" vs. 2,000 3-step actions makes a big difference... (Especially when the PDFs are accessible without paywall and we have the direct URLs already ...)
(Of course, workaround is to get the local files from the RIS, and then re-import the RIS - but this means we have to decide up-front, and might be adding a lot of never-used-PDFs to the library. So we'd rather be able to get the PDFs in chunks, as we need them, distributed across different users - it's a shared library.)
Thanks!
Bjoern
it would be amazing if "Find available PDF" also looked at the url in metadata and attachment urls. We imported a large RIS library, some with DOI, some without. But many items have a (freely available) PDF, that is either in the url in metadata and attachment urls. While it's not difficult to get the items, we still have to click the item (or copy to wget) and then click again (or drag) to get to Zotero. It would be so much neater if it was just one click.
We have ~2,000 items. So one right click "Find available PDF" vs. 2,000 3-step actions makes a big difference... (Especially when the PDFs are accessible without paywall and we have the direct URLs already ...)
(Of course, workaround is to get the local files from the RIS, and then re-import the RIS - but this means we have to decide up-front, and might be adding a lot of never-used-PDFs to the library. So we'd rather be able to get the PDFs in chunks, as we need them, distributed across different users - it's a shared library.)
Thanks!
Bjoern
I don't know if you can have a production release and a beta release installed on same PC, but I'd never ever try to do "real" work with a beta release. Just seen to many programs blow up.
I haven’t tried this, but according to the he beta page it would seem possible to switch between the standard version and the beta version without problems!
@bjohas: I'm not sure I'm understanding you. Can you provide an example RIS entry that shows what you're describing? "Find Available PDF" will already follow the URL in the URL field, if that's what you mean, and either look for a PDF it can translate from there or, if it's a direct link to an ungated PDF, download that PDF and add it as an attachment (even though the PDF URL itself generally isn't supposed to be in the URL field).
TY - JOUR
TI - Reforming Instruction, Curriculum, Assessment, and Structure to Teach Vocational and 21st Century Skills
AU - A Blom, X Cao, H Andriamihamina
UR - http://documents.worldbank.org/curated/en/297731506359700310/pdf/119989-WP-P159532-PUBLIC-wbBotswanaetcpublication.pdf
ER -
As a follow-up question: Are URLs in attachments also checked, i.e. if the URL in the metadata was unsuccessful, will Find Av PDF proceed to url-type attachments? (Edit: Basically, I wonder whether this behaviour is implemented: If a smart search identifies the item has having a PDF attachment, and assuming that this PDF isn't behind a paywall, will Find Av PDF retrieve it?)
It doesn't have to work this way, but we do it because 1) the feature was designed primarily around Unpaywall data, which in many cases still has an HTTP URL when the HTTPS URL works fine, 2) this is a mostly automated function, and we don't want to expose details of potentially thousands of saved items to anyone who might be watching traffic, and 3) the future is HTTPS (e.g., with browsers already marking HTTP sites as "Not Secure"), and with certificates now freely available there's really no excuse for a site not to support HTTPS. No. If there's already a PDF file attachment, the file should exist either locally or in the online library and shouldn't need to be retrieved again. Link attachments aren't checked, because they don't have any particular semantic meaning, and there's no way to know that a link attachment points to the primary PDF or a page with one.
I fully appreciate that there is no way for the Zotero development team to do testing with every set of products that users could configure. For example there are only about 5000 favorite browsers. :-)
Many thanks for the help with this - very much appreciated!