Very cool. This would have saved me tons of time in college.
One minor usability issue, clicking the different style after generating the citation doesn't have any result until you generate a new citation. That is a little unintuitive. I would either switch to the different style immediately or put some separation in the UI between the returned citation and the components that are used to generate a new citation.
Thanks for the feedback. Originally, clicking the style pill button refreshed the citation (in the selected style), which I think is the behavior you're describing. It sounds like I should go back to that behavior.
Have the server respond with the necessary info but generate the style client side instead of server side. There doesn't appear to be any need to make trips back to the server to change styles.
You're right - I could just pass the variables as JS to the client, then assemble the final citation there. Great idea! Regarding the trailing slash, that's a regex problem, and I will solve it! Nice catch.
I've updated the app to go ahead and generate a new citation when you change styles. This happens pretty quickly, and this saves the user a click. Thanks for the feedback!
Sciencemag.org uses a special metatag for authors (citation_author). I'm not sure how common this is, but I will add logic to check these. Then SpeedCite would properly cite the author.
From the ISBN alone, it's difficult to differentiate between an electronic book (such as one retrieved by Google Books) and a physical one. Would it be helpful to add a switch allowing you to specify whether you want electronic book citations or print book citations?
My academic life became a lot simpler when I learnt this - now I only need to maintain a database of {cite key: DOI} pairs, rather than a bibtex monster. Yes, I have tried Mendeley et al. and yes, I do prefer scripts that do what I tell them to.
This works great! I looked into doi.org before but I wasn't sure what their ratelimit is. I'm currently using phantomJS and google scholar for DOIs, and I think I might have hit their rate limit already, so I will take a second look at this!
p.s. I found I had to use 'data.crossref.org' instead of 'dx.doi.org' when I scripted it (python + requests). Not sure why exactly (doi was redirecting to crossref anyway).
How to do it in python in case anyone is wondering:
import requests
import json
url = 'http://data.crossref.org/10.1017/S0022112061000019'
headers = {'Accept': 'application/citeproc+json'}
r = requests.get(url, headers=headers)
meta = json.loads(r.content)
# meta is a dictionary of metadata, e.g. meta['DOI']
For CS I did it almost like that: Typically you write papers in LaTeX which means you need a correct Bibtex entry, and correct means its better be curated by someone else. Since most of the relevant CS publications are in DBLP [1] I wrote a small script that scans missing citation keys in your LaTeX file for actual DBLP keys and automatically builds this into a bibtex file that you can use [2]. If you integrate this command in your regular build cycle for LaTeX using for example latexmk manually maintaining bibtex files is a thing from the past.
Do you know where I can find the documentation for this API? I got MLA style working, but I can't get Chicago/Turabian style working. Once I get this working, I plan to switch to this method for DOIs. Thanks!
Sorry to hijack this reply; for your URL citations, you may want to integrate with the Internet Archive (archive.org) to get/store the snapshot of the URL/URI you're citing.
To clarify, this is using Content Negotiation on the DOI API (i.e. sending 'Accepts' headers). These DOIs are CrossRef's, so requesting those formats via content negotiation is getting metadata from CrossRef.
EasyBib has a ton of features and aims to be as comprehensive as possible, and grants you more low-level control over the end citation. SpeedCite optimizes for speed and simplicity.
I'm amazed Wikipedia doesn't have a first-party tool for this. I can look into it. I'm trying to keep SpeedCite as simple as possible. If there is demand, I could maybe build a stand-alone app for this?
OK, I've fixed both of these ISBN issues and pushed them to production. So both 014242417X and 978-0142424179, and similar ISBNs, should be no problem.
I think it's interesting the URL citation does not actually include the URL. It seems like the title of the article and the domain. Why is the exact URL of the resource is not important?
I could certainly include it, but doing so is not usually required for MLA, APA or Chicago citations, and it would in many cases, make the citation really long.
I think that the reference makes sense as far as longevity. How often do links to a specific page change? Very often. How often do domains change? Not as often. MLA and other style guides are generally written with print in mind, not links directly to content being cited.
Sites that want their content linked, reused and cited should use some sort of permalinking strategy. I don't think we should have a unverifiable citation because a publication does not follow sound link generation strategies. Provenance of the information is what we seek, citing a journal who doesn't provide a time proof way to access the resource should not be cited.
Looks nice, but it doesn't retrieve results for many of the DOIs I tried, e.g. 10.1155/2014/863625 and 10.4103/0970-2113.129901, and gave an incorrect result for this one: 10.1073/pnas.1324197111
Feature suggestions: would be nice if it accepted PubMed ids, and supported other popular citation styles like Hardvard and Vancouver (or alternatively, permitted some customisation of the citation format).
Thanks for your feedback! Posting on HN seems to have caused speedcite to exceed Google Scholar's rate limit, so I'll be switching to crossref.org for DOIs. Using the new logic (which I'm about to push), I was able to get the first two DOIs you mentioned, but I couldn't get 10.1073/pnas.1324197111 working on crossref.org or on Google Scholar. Where did you find this DOI? I'd like to figure out a way to support it and its kind.
It doesn't. I'll see if I can find out what's wrong.
If you have any questions you can email labs@crossref.org
EDIT: Looking at the Guest Query, http://www.crossref.org/guestquery/ it looks like this was deposited recently. There may be a delay in propagation through our systems.
Cool, I didn't realize CrossRef had an API. That will be helpful in troubleshooting DOIs that fail to resolve for me. Thanks for your offer. I'll definitely reach out once I've accumulated some more questions for you.
How does CrossRef relate to the DOI Foundation? In particular I am curious as to how the DOI data is shared - for example what caused that DOI to be resolvable on dx.doi.org but not doi.crossref.org?
The DOI foundation is responsible for "making sure DOIs work" (I'm sure there's a better definition than that!). Like DNS, there are a number of Registration Agencies (RAs) who are responsible for registering DOIs. An organisation such as CrossRef (or DataCite) RA will say "we want to become an RA". They join, and can then register their own DOIs.
DOIs are persistent identifiers, and the main reason you want those is so you can have a persistent link from one thing to another. A normal hyperlink is subject to link-rot, which is an especially bad problem when you've got printed journals or online 'printed journals'. A DOI is a link that goes via the DOI to redirect to wherever the link is meant to point at this point in history. RAs are responsible for registering DOIs and updating the link redirect data whenever the thing being pointed to moves.
RAs exist for different purposes. CrossRef exists to enable linking between scholarly publications, so we register DOIs for scholarly publications (journal articles, books, etc). DataCite exists to enable linking to objects like datasets.
CrossRef isn't just an DOI RA, but DOIs are a big part of what we do. In addition to this we store metadata from publishers and then let anyone use our APIs to get that data.
The DOI foundation maintains a load of DOI resolution servers. They all do the same job: you click on a link, you're load-balanced to one of the machines, and it replies with the relevant redirect.
Normally when you click on a DOI in a browser, you are redirected to the appropriate URL. We introduced 'Content Negotiation' for DOIs, which means you can supply an 'Accepts' header and get more bibliographic information about a DOI. This works with a redirect.
This is a CrossRef server and it knows all the publication metadata. This then serves all the bibliographic data.
So TL;DR:
1 - The DOI foundation runs the DOI system
2 - CrossRef is an RA for DOIs
3 - Every RA runs its own resolution servers to spread the load
4 - Every resolution server can answer any DOI registered by any RA
5 - If you ask for bibliographic content negotiation on a CrossRef DOI, you'll be redirected to the data.crossref.org server which will give you what you asked for
And that DOI that worked on dx.doi.org but not data.CrossRef.org might be because it can take a day for the data to propagate to various systems.
Wow, I didn't realize IEEE had their own citation format.
Amazon has the ISBN 9781405347587. The only other google result for this is your comment, which Google seems to have already indexed :)
Since Google Books doesn't have that ISBN, I would need 1) fail gracefully instead of giving a citation for the wrong book and 2) have a fallback API. I'm working on both of these. Thanks!
75 comments
[ 2.8 ms ] story [ 139 ms ] threadOne minor usability issue, clicking the different style after generating the citation doesn't have any result until you generate a new citation. That is a little unintuitive. I would either switch to the different style immediately or put some separation in the UI between the returned citation and the components that are used to generate a new citation.
Also, "http://google.com" complains about robots.txt, but "http://google.com/" (trailing slash) does not.
Any questions email, us at labs@crossref.org
*which are the kinds of DOI you're likely to be citing, but other Registration Agencies and types of DOIs exist
[1] http://www.dblp.org/search/
[2] https://github.com/grundprinzip/dblp
EDIT: aha, you have to remove dashes for it to work. It should probably do this automatically.
https://en.wikipedia.org/wiki/Wikipedia:Citation_templates
The Fault in Our Stars Paperback by John Green: http://www.amazon.com/The-Fault-Stars-John-Green/dp/01424241...
The subject line gets cut much too short, and the URL gets trimmed to the root level of the domain.
The MLA format cite comes out as:
"Show HN: One." Ycombinator.com. N.p. Web. 30 Apr. 2014. <https://news.ycombinator.com/>
The APA format cite comes out as:
Show HN: One. Ycombinator.com. Retrieved Apr 30, 2014, from https://news.ycombinator.com.
The Chicago formate cite comes out as:
"Show HN: One." Ycombinator.com. https://news.ycombinator.com/.
Show HN: One-click citations for your essays (speedcite.com)
Feature suggestions: would be nice if it accepted PubMed ids, and supported other popular citation styles like Hardvard and Vancouver (or alternatively, permitted some customisation of the citation format).
The only two services I've found that accept it are http://hdl.handle.net/ and http://dx.doi.org/, and I think they're querying the same database.
That DOI is newly deposited, as I said in other comments, it may take a while to propagate.
You can check the Registration Agency with CrossRef to see who's responsible for it:
http://doi.crossref.org/ra/10.1073/pnas.1324197111
In this case, it is CrossRef. So this should work: http://api.crossref.org/works/10.1073/pnas.1324197111
It doesn't. I'll see if I can find out what's wrong.
If you have any questions you can email labs@crossref.org
EDIT: Looking at the Guest Query, http://www.crossref.org/guestquery/ it looks like this was deposited recently. There may be a delay in propagation through our systems.
DOIs are persistent identifiers, and the main reason you want those is so you can have a persistent link from one thing to another. A normal hyperlink is subject to link-rot, which is an especially bad problem when you've got printed journals or online 'printed journals'. A DOI is a link that goes via the DOI to redirect to wherever the link is meant to point at this point in history. RAs are responsible for registering DOIs and updating the link redirect data whenever the thing being pointed to moves.
RAs exist for different purposes. CrossRef exists to enable linking between scholarly publications, so we register DOIs for scholarly publications (journal articles, books, etc). DataCite exists to enable linking to objects like datasets.
CrossRef isn't just an DOI RA, but DOIs are a big part of what we do. In addition to this we store metadata from publishers and then let anyone use our APIs to get that data.
The DOI foundation maintains a load of DOI resolution servers. They all do the same job: you click on a link, you're load-balanced to one of the machines, and it replies with the relevant redirect.
Normally when you click on a DOI in a browser, you are redirected to the appropriate URL. We introduced 'Content Negotiation' for DOIs, which means you can supply an 'Accepts' header and get more bibliographic information about a DOI. This works with a redirect.
Here's an example:
curl -L -iH "Accept: text/turtle" http://dx.doi.org/10.5555/515151
That query is answered by one of the DOI servers. It doesn't matter which.
You see you're redirected to Location: http://data.crossref.org/10.5555%2F515151
This is a CrossRef server and it knows all the publication metadata. This then serves all the bibliographic data.
So TL;DR:
1 - The DOI foundation runs the DOI system
2 - CrossRef is an RA for DOIs
3 - Every RA runs its own resolution servers to spread the load
4 - Every resolution server can answer any DOI registered by any RA
5 - If you ask for bibliographic content negotiation on a CrossRef DOI, you'll be redirected to the data.crossref.org server which will give you what you asked for
And that DOI that worked on dx.doi.org but not data.CrossRef.org might be because it can take a day for the data to propagate to various systems.
Any questions, labs@crossref.org
I don't think the ISBN lookup works correctly. Typing in 9781405347587 or 978-1405347587 returns a book with ISBN 0-9690745-2-2
I'd be looking forward to upgraded version with IEEE but I just graduated, ha!
Amazon has the ISBN 9781405347587. The only other google result for this is your comment, which Google seems to have already indexed :)
Since Google Books doesn't have that ISBN, I would need 1) fail gracefully instead of giving a citation for the wrong book and 2) have a fallback API. I'm working on both of these. Thanks!