<div dir="ltr">David, I agree with your ideas. Having a REST endpoint handling records would be awesome improvement. I'll hapilly sign or QA those patches.<div><br></div><div>Regards</div></div><br><div class="gmail_quote"><div dir="ltr">El mié., 21 sept. 2016 a las 22:00, David Cook (<<a href="mailto:dcook@prosentient.com.au">dcook@prosentient.com.au</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-AU" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal">Hi all,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I want to improve the API(s) for importing (bibliographic) records.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">But I’m not 100% sure how to go about what criteria to use to gauge “improvement”. Here are some ideas:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p style="margin-left:108.0pt"><u></u><span style="font-family:Wingdings"><span>§<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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. <u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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).<u></u><u></u></p><p><u></u> <u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>The import source and the type of import would be stored (ie <a href="http://oai-server.com" target="_blank">http://oai-server.com</a> and “oai-pmh”, <a href="http://lx2.loc.gov" target="_blank">lx2.loc.gov</a> and “z3950”, <insert relevant source> and “oclc connexion”, etc.). <u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>I think this would be helpful for managing/processing a certain type of import, perhaps also in terms of matching records. <u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Storing some sort of identifier would be good<u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>OAI-PMH records have unique identifiers for the records<u></u><u></u></p><p style="margin-left:72.0pt"><u></u><span style="font-family:"Courier New""><span>o<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Anyway, these are just some ideas I’ve been having. They’re not fully formed by any stretch of the imagination. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span>David Cook<u></u><u></u></span></p><p class="MsoNormal"><span>Systems Librarian<u></u><u></u></span></p><p class="MsoNormal"><span>Prosentient Systems<u></u><u></u></span></p><p class="MsoNormal"><span>72/330 Wattle St<u></u><u></u></span></p><p class="MsoNormal"><span>Ultimo, NSW 2007<u></u><u></u></span></p><p class="MsoNormal"><span>Australia<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>Office: 02 9212 0899<u></u><u></u></span></p><p class="MsoNormal"><span>Direct: 02 8005 0595<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p></div></div>_______________________________________________<br>
Koha-devel mailing list<br>
<a href="mailto:Koha-devel@lists.koha-community.org" target="_blank">Koha-devel@lists.koha-community.org</a><br>
<a href="http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel" rel="noreferrer" target="_blank">http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel</a><br>
website : <a href="http://www.koha-community.org/" rel="noreferrer" target="_blank">http://www.koha-community.org/</a><br>
git : <a href="http://git.koha-community.org/" rel="noreferrer" target="_blank">http://git.koha-community.org/</a><br>
bugs : <a href="http://bugs.koha-community.org/" rel="noreferrer" target="_blank">http://bugs.koha-community.org/</a></blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(117,117,117);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:12.8px">Tomás Cohen Arazi</div><div style="color:rgb(117,117,117);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:12.8px">Theke Solutions (<a href="http://theke.io/">https://theke.io</a>)<br>✆ +54 9351 3513384<br>GPG: B2F3C15F</div></div></div>