I think a sane proofing workflow in OpenRefine is to apply the custom text facets for check/delete/remove and illegal characters that I developed in March, 2018
I think a sane proofing workflow in OpenRefine is to apply the custom text facets for check/delete/remove and illegal characters that I developed in March, 2018
<li>Test the <ahref="https://tracker.atmire.com/tickets-cgiar-ilri/view-ticket?id=560">DSpace 5.8 module upgrades from Atmire</a> (<ahref="https://github.com/ilri/DSpace/pull/378">#378</a>)
<ul>
<li>There seems to be a problem with the CUA and L&R versions in <code>pom.xml</code> because they are using SNAPSHOT and it doesn’t build</li>
</ul></li>
<li>I added the new CCAFS Phase II Project Tag <code>PII-FP1_PACCA2</code> and merged it into the <code>5_x-prod</code> branch (<ahref="https://github.com/ilri/DSpace/pull/379">#379</a>)</li>
<li>I proofed and tested the ILRI author corrections that Peter sent back to me this week:</li>
<li>I think a sane proofing workflow in OpenRefine is to apply the custom text facets for check/delete/remove and illegal characters that I developed in <ahref="/cgspace-notes/2018-03/">March, 2018</a></li>
<li>It turns out that I needed to add a server block for <code>atmire.com-snapshots</code> to my Maven settings, so now the Atmire code builds</li>
<li>Now Maven and Ant run properly, but I’m getting SQL migration errors in <code>dspace.log</code> after starting Tomcat</li>
<li>I’ve updated my ticket on Atmire’s bug tracker: <ahref="https://tracker.atmire.com/tickets-cgiar-ilri/view-ticket?id=560">https://tracker.atmire.com/tickets-cgiar-ilri/view-ticket?id=560</a></li>
<li>Proofing 200 IITA records on DSpace Test for Sisay: <ahref="https://dspacetest.cgiar.org/handle/10568/95391">IITA_Junel_06 (<sup>10568</sup>⁄<sub>95391</sub>)</a>
<ul>
<li>Mispelled authorship type: CGAIR single center should be: CGIAR single centre</li>
<li>I see some encoding errors in author affiliations, for example:</li>
<li>Universidade de SÆo Paulo</li>
<li>Institut National des Recherches Agricoles du B nin</li>
<li>Centre de Coop ration Internationale en Recherche Agronomique pour le D veloppement</li>
<li>Institut des Recherches Agricoles du B nin</li>
<li>Institut des Savannes, C te d’ Ivoire</li>
<li>Institut f r Pflanzenpathologie und Pflanzenschutz der Universit t, Germany</li>
<li>Projet de Gestion des Ressources Naturelles, B nin</li>
<li>Universit t Hannover</li>
<li>Universit F lix Houphouet-Boigny</li>
</ul></li>
<li>I uploaded fixes for all those now, but I will continue with the rest of the data later</li>
<li>Gabriela from CIP got back to me about the author names we were correcting on CGSpace</li>
<li>I did a quick sanity check on them and then did a test import with my <ahref="https://gist.github.com/alanorth/df92cbfb54d762ba21b28f7cd83b6897"><code>fix-metadata-value.py</code></a> script:</li>
<li>I spent some time removing the Atmire Metadata Quality Module (MQM) from the proposed DSpace 5.8 changes</li>
<li>After removing all code mentioning MQM, mqm, metadata-quality, batchedit, duplicatechecker, etc, I think I got most of it removed, but there is a Spring error during Tomcat startup:</li>
</ul>
<pre><code> INFO [org.dspace.servicemanager.DSpaceServiceManager] Shutdown DSpace core service manager
Failed to startup the DSpace Service Manager: failure starting up spring service manager: Error creating bean with name 'org.dspace.servicemanager.spring.DSpaceBeanPostProcessor#0' defined in class path resource [spring/spring-dspace-applicationContext.xml]: Unsatisfied dependency expressed through constructor argument with index 0 of type [org.dspace.servicemanager.config.DSpaceConfigurationService]: : Cannot find class [com.atmire.dspace.discovery.ItemCollectionPlugin] for bean with name 'itemCollectionPlugin' defined in file [/home/aorth/dspace/config/spring/api/discovery.xml];
</code></pre>
<ul>
<li>I can fix this by commenting out the <code>ItemCollectionPlugin</code> line of <code>discovery.xml</code>, but from looking at the git log I’m not actually sure if that is related to MQM or not</li>
<li>I continued to look at Sisay’s IITA records from last week
<ul>
<li>I normalized all DOIs to use HTTPS and “doi.org” instead of “dx.doi.org”</li>
<li>I cleaned up white space in <code>cg.subject.iita</code> and <code>dc.subject</code></li>
<li>Even a bunch of IITA and AGROVOC subjects are missing accents, ie “FERTILIT DU SOL”</li>
<li>More organization names in <code>dc.description.sponsorship</code> are incorrect (ie, missing accents) or inconsistent (ie, CGIAR centers should be spelled in English or multiple spellings of the same one, like “Rockefeller Foundation” and “Rockefeller foundation”)</li>
<li>A few dozen items have abstracts with character encoding errors, ie:</li>
<li>33.7øC</li>
<li>MgSO4ú7H2O</li>
<li>ha??1&/sup;</li>
<li>En gen6ral</li>
<li>dÕpassÕ</li>
<li>Also the abstracts have missing accents, ie “recherche sur le d veloppement”</li>
</ul></li>
<li>I will have to tell IITA people to redo these entirely I think…</li>
<li>Sisay sent a new version of the last IITA records that he created from the original CSV from IITA</li>
<li>The 200 records are in the <ahref="https://dspacetest.cgiar.org/handle/10568/95870">IITA_Junel_11 (<sup>10568</sup>⁄<sub>95870</sub>)</a> collection</li>
<li>Many errors:
<ul>
<li>Authorship types: “CGIAR ans advanced research institute”, “CGAIR and advanced research institute”, “CGIAR and advanced research institutes”, “CGAIR single center”</li>
<li>Lots of inconsistencies and mispellings in author affiliations:</li>
<li>“Institut des Recherches Agricoles du Bénin” and “Institut National des Recherche Agricoles du Benin” and “National Agricultural Research Institute, Benin”</li>
<li>International Insitute of Tropical Agriculture</li>
<li>Centro Internacional de Agricultura Tropical</li>
<li>“Rivers State University of Science and Technology” and “Rivers State University”</li>
<li>“Institut de la Recherche Agronomique, Cameroon” and “Institut de Recherche Agronomique, Cameroon”</li>
<li>Inconsistency in countries: “COTE D’IVOIRE” and “COTE D’IVOIRE”</li>
<li>A few DOIs with spaces or invalid characters</li>
<li>Inconsistency in IITA subjects, for example “PRODUCTION VEGETALE” and “PRODUCTION VÉGÉTALE” and several others</li>
<li>I ran <code>value.unescape('javascript')</code> on the abstract and citation fields because it looks like this data came from a SQL database and some stuff was escaped</li>
</ul></li>
<li>It turns out that Abenet actually did a lot of small corrections on this data so when Sisay uses Bosede’s original file it doesn’t have all those corrections</li>
<li>So I told Sisay to re-create the collection using Abenet’s XLS from last week (<code>Mercy1805_AY.xls</code>)</li>
<li>I was curious to see if I could create a GREL for use with a custom text facet in Open Refine to find cells with two or more consecutive spaces</li>
<li>I always use the built-in trim and collapse transformations anyways, but this seems to work to find the offending cells: <code>isNotNull(value.match(/.*?\s{2,}.*?/))</code></li>
<li>I wonder if I should start checking for “smart” quotes like ’ (hex 2019)</li>
<li>Udana from IWMI asked about the OAI base URL for their community on CGSpace</li>
<li>I think it should be this: <ahref="https://cgspace.cgiar.org/oai/request?verb=ListRecords&metadataPrefix=oai_dc&set=com_10568_16814">https://cgspace.cgiar.org/oai/request?verb=ListRecords&metadataPrefix=oai_dc&set=com_10568_16814</a></li>
<li>The style sheet obfuscates the data, but if you look at the source it is all there, including information about pagination of results</li>
<li>Regarding Udana’s Book Chapters and Reports on DSpace Test last week, Abenet told him to fix some character encoding and CRP issues, then I told him I’d check them after that</li>
<li>The latest batch of IITA’s 200 records (based on Abenet’s version <code>Mercy1805_AY.xls</code>) are now in the <ahref="https://dspacetest.cgiar.org/handle/10568/96071">IITA_Jan_9_II_Ab</a> collection</li>
<li>So here are some corrections:
<ul>
<li>use of Unicode smart quote (hex 2019) in countries and affiliations, for example “COTE D’IVOIRE” and “Institut d’Economic Rurale, Mali”</li>
<li>inconsistencies in <code>cg.contributor.affiliation</code>:</li>
<li>“Centro Internacional de Agricultura Tropical” and “Centro International de Agricultura Tropical” should use the English name of CIAT (International Center for Tropical Agriculture)</li>
<li>“Institut International d’Agriculture Tropicale” should use the English name of IITA (International Institute of Tropical Agriculture)</li>
<li>“East and Southern Africa Regional Center” and “Eastern and Southern Africa Regional Centre”</li>
<li>“Institut de la Recherche Agronomique, Cameroon” and “Institut de Recherche Agronomique, Cameroon”</li>
<li>“Institut des Recherches Agricoles du Bénin” and “Institut National des Recherche Agricoles du Benin” and “National Agricultural Research Institute, Benin”</li>
<li>“Institute of Agronomic Research, Cameroon” and “Institute of Agronomy Research, Cameroon”</li>
<li>“Rivers State University” and “Rivers State University of Science and Technology”</li>
<li>“Universität Hannover” and “University of Hannover”</li>
<li>inconsistencies in <code>cg.subject.iita</code>:</li>
<li>“AMELIORATION DES PLANTES” and “AMÉLIORATION DES PLANTES”</li>
<li>“PRODUCTION VEGETALE” and “PRODUCTION VÉGÉTALE”</li>
<li>“CONTRÔLE DE MALADIES” and “CONTROLE DES MALADIES”</li>
<li>“HANDLING, TRANSPORT, STORAGE AND PROTECTION OF AGRICULTURAL PRODUCT” and “HANDLING, TRANSPORT, STORAGE AND PROTECTION OF AGRICULTURAL PRODUCTS”</li>
<li>“RAVAGEURS DE PLANTES” and “RAVAGEURS DES PLANTES”</li>
<li>“SANTE DES PLANTES” and “SANTÉ DES PLANTES”</li>
<li>“SOCIOECONOMIE” and “SOCIOECONOMY”</li>
<li>inconsistencies in <code>dc.description.sponsorship</code>:</li>
<li>“Belgian Corporation” and “Belgium Corporation”</li>
<li>inconsistencies in <code>dc.subject</code>:</li>
<li>“AFRICAN CASSAVA MOSAIC” and “AFRICAN CASSAVA MOSAIC DISEASE”</li>
<li>“ASPERGILLU FLAVUS” and “ASPERGILLUS FLAVUS”</li>
<li>“BIOTECHNOLOGIES” and “BIOTECHNOLOGY”</li>
<li>“CASSAVA MOSAIC DISEASE” and “CASSAVA MOSAIC DISEASES” and “CASSAVA MOSAIC VIRUS”</li>
<li>“CASSAVA PROCESSING” and “CASSAVA PROCESSING TECHNOLOGY”</li>
<li>“CROPPING SYSTEM” and “CROPPING SYSTEMS”</li>
<li>“DRY SEASON” and “DRY-SEASON”</li>
<li>“FERTILIZER” and “FERTILIZERS”</li>
<li>“LEGUME” and “LEGUMES”</li>
<li>“LEGUMINOSAE” and “LEGUMINOUS”</li>
<li>“LEGUMINOUS COVER CROP” and “LEGUMINOUS COVER CROPS”</li>
<li>“MATÉRIEL DE PLANTATION” and “MATÉRIELS DE PLANTATION”</li>
<li>I noticed that some records do have encoding errors in the <code>dc.description.abstract</code> field, but only four of them so probably not from Abenet’s handling of the XLS file</li>
<li>Based on manually eyeballing the text I used a custom text facet with this GREL to identify the records:</li>
</ul></li>
</ul>
<pre><code>or(
value.contains('€'),
value.contains('6g'),
value.contains('6m'),
value.contains('6d'),
value.contains('6e')
)
</code></pre>
<ul>
<li>So IITA should double check the abstracts for these:
<li>Elizabeth from CIAT contacted me to ask if I could add ORCID identifiers to all of Robin Buruchara’s items</li>
<li>I used my <ahref="https://gist.githubusercontent.com/alanorth/a49d85cd9c5dea89cddbe809813a7050/raw/f67b6e45a9a940732882ae4bb26897a9b245ef31/add-orcid-identifiers-csv.py">add-orcid-identifiers-csv.py</a> script:</li>
<li>Check through Udana’s IWMI records from last week on DSpace Test</li>
<li>There were only some minor whitespace and one or two syntax errors, but they look very good otherwise</li>
<li>I uploaded the twenty-four reports to the IWMI Reports collection: <ahref="https://cgspace.cgiar.org/handle/10568/36188">https://cgspace.cgiar.org/handle/10568/36188</a></li>
<li>I uploaded the seventy-six book chapters to the IWMI Book Chapters collection: <ahref="https://cgspace.cgiar.org/handle/10568/36178">https://cgspace.cgiar.org/handle/10568/36178</a></li>
<li>I was restoring a PostgreSQL dump on my test machine and found a way to restore the CGSpace dump as the <code>postgres</code> user, but have the owner of the schema be the <code>dspacetest</code> user:</li>
<li>The <code>-O</code> option to <code>pg_restore</code> makes the import process ignore ownership specified in the dump itself, and instead makes the schema owned by the user doing the restore</li>
<li>I always prefer to use the <code>postgres</code> user locally because it’s just easier than remembering the <code>dspacetest</code> user’s password, but then I couldn’t figure out why the resulting schema was owned by <code>postgres</code></li>
<li>So with this you connect as the <code>postgres</code> superuser and then switch roles to <code>dspacetest</code> (also, make sure this user has <code>superuser</code> privileges before the restore)</li>
