[Koha-devel] Improving the API for record imports
David Cook
dcook at prosentient.com.au
Thu Sep 22 02:59:49 CEST 2016
Hi all,
I want to improve the API(s) for importing (bibliographic) records.
But I'm not 100% sure how to go about what criteria to use to gauge
"improvement". Here are some ideas:
* I think the REST API offers up one obvious addition and that's
DELETE. It would be great to delete records using the API. I've found this
mostly thanks to OAI-PMH where you get a notice when a record has been
deleted upstream and needs to be deleted from Koha too.
o The difficulty in deleting bibliographic records is items. If there are
items, it blocks the delete. You could auto-delete items, but you can't if
there are holds or if it's currently issued. At best, you could return a
failed delete via the API, I think.
* I keep thinking that "import profiles" could be a good way to go
too. This might include a MARC Modification Template, it might be a XSLT, it
might be a Koha::Filter. It would let you turns your incoming metadata from
format A to format B.
o This would also allow you to POST a minimum amount of data to the API.
You'd have your metadata record and your import profile code.
* The downside of this is the POST wouldn't detail the options for the
import, and those imports would be more obfuscated. Changes to a profile
could also impact subsequent imports unintentionally.
o I'm not sure how batches would work with filtering. You might have
50/100 records filter correctly and import, but that leaves 50 which aren't
imported. Do you undo the whole import, or do you fix your filter, and then
re-import the first 50 alongside the first time import of the last 50?
* The original metadata would be stored regardless of metadata
format (e.g. marcxml, mods, rdf, dc, etc.) for historical purposes or to
allow re-filtering in the event that a filter fails to correctly transform a
record to valid MARCXML (or whatever internal metadata format Koha uses).
* The import source and the type of import would be stored (ie
http://oai-server.com and "oai-pmh", lx2.loc.gov and "z3950", <insert
relevant source> and "oclc connexion", etc.).
o I think this would be helpful for managing/processing a certain type of
import, perhaps also in terms of matching records.
o At the moment, with my work on #10662, I have a separate table
"import_oai" which obviously is for records imported via oai-pmh only. I
don't actually track the origin due to how I currently source the imports,
but I could do it in the future.
* Storing some sort of identifier would be good
o OAI-PMH records have unique identifiers for the records
o Z39.50. that's tougher since it's not a specific metadata format like
the OAI-PMH format. So I don't know about this one.
Anyway, these are just some ideas I've been having. They're not fully formed
by any stretch of the imagination.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia
Office: 02 9212 0899
Direct: 02 8005 0595
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20160922/38e11754/attachment.html>
More information about the Koha-devel
mailing list