zotero-cita
zotero-cita copied to clipboard
diegodlh
Support fetching citations from the OpenAlex API
They have citations like crossref
and also concepts that in some cases are linked to WD already, making it dead simple to add P921
Might it makes sense to specify and implement an API for fetching from external datasources first and then do the implementation of specific datasources ("adapters"), preferrably via separate plugins which then can be integrated in the core whenever they are production-ready? I would expect that this would speed up things considerably. The API specification/implementation can be done much quicker than any "adapter" and CITA wouldn't have to commit to any specific implementation. Also, this API could cover lookups and extraction services alike.
The API would probably have to provide the following methods:
- adapter -> cita: register an adapter, which then become available in the GUI;
- cita -> adapter: send the citing item metadata (if it is a lookup service) or a File (for citation extraction services) to do the lookup/extraction together with the key
- adapter -> cita: return the citation data when it is ready, which might be quick (lookup) or take a while (extraction)
Come to think of it, isn't this more or less the purpose of Zotero translators? Would it be possible to make custom translators that also return the references for an item in a nice format for ingestion into Cita?
If not we could specify our own interface like you mention.
I remember seeing code somewhere that abstracted the list of possible data providers - I think in the UI. But in general a more robust solution than adding new APIs ad hoc every time would be nice I think.
Come to think of it, isn't this more or less the purpose of Zotero translators? Would it be possible to make custom translators that also return the references for an item in a nice format for ingestion into Cita?
If not we could specify our own interface like you mention.
I remember seeing code somewhere that abstracted the list of possible data providers - I think in the UI. But in general a more robust solution than adding new APIs ad hoc every time would be nice I think.
I second this. Today, many publishers' websites offer a list of references and even citations in addition to the basic metadata of papers. So custom translators could be developed to extract this information.
Sure, translators might be the zotero'ish way to do that. But you would still need CITA to iterate over the list of tranlators, select those which can import references, and display them in the UI. Because it wouldn't make sense for you to have to open the API website of an item in, say, openalex or semantic scholar to then click the zotero button to import the references. If an item has a DOI, CITA can directly query the API of various services and import the JSON response without the user having to manually navigate somewhere - that's what the APIs are for, after all.
I will have (ruby) code ready soon to import CSL-.JSON data from semanticscholar, openalex and crossref that would be trivial to port to JavaScript but I need an infrastructure to put the code into; something that is called by CITA and expects CSL-JSON (or Zotero native format) back.
Yeah, something that takes an identifier (DOI, OpenAlex ID, ...) or list of them and returns a list of Zotero Items would be perfect.
There's a rather complicated implementation for Crossref here. Annoyingly it's a bit integrated with the Cita progress messages. I'm still a bit on the fence whether the nice progress updates are worth sacrificing the standalone nature of the reference fetching code.
But definitely, we can make it so the various translators are only enabled when an item has the approach identifier. This should work at the moment for DOIs at least.
Do I understand correctly that using translator would be kind of "misusing" the translator infrastructure as a distribution system for citation importers? Because they wouldn't really work on website to import something, they would simply contain code that can be installed as a translator but would not be scraping websites but instead do API calls based on parameters passed to them from CITA. So the translator code would contain functions that do this that have nothing do do with the tranlator functions interface. Or did I miss something here?
I like progress indicators alot and use then all the time in CLI scripts, they give meaning to the time spent waiting for a task to finish :-) They could be supported by passing the Progress object to the importing function which then could decide how to provide progress feedback (or not).