I exported the CCAFS and IITA communities, extracted just the country and region columns, then ran them through csv-metadata-quality to fix the regions
Add a few more authors to my CSV with author names and ORCID identifiers and tag 283 items!
Replace “East Asia” with “Eastern Asia” region on CGSpace (UN M.49 region)
I exported the CCAFS and IITA communities, extracted just the country and region columns, then ran them through csv-metadata-quality to fix the regions
Add a few more authors to my CSV with author names and ORCID identifiers and tag 283 items!
Replace “East Asia” with “Eastern Asia” region on CGSpace (UN M.49 region)
<li>I exported the CCAFS and IITA communities, extracted just the country and region columns, then ran them through csv-metadata-quality to fix the regions</li>
</ul>
</li>
<li>Add a few more authors to my CSV with author names and ORCID identifiers and tag 283 items!</li>
<li>Replace “East Asia” with “Eastern Asia” region on CGSpace (UN M.49 region)</li>
</ul>
<ul>
<li>CGSpace and PRMS information session with Enrico and a bunch of researchers</li>
<li>I noticed some minor issues with SPDX licenses and AGROVOC terms in items submitted by TIP so I sent a message to Daniel from Alliance</li>
<li>I startd a harvest on AReS since we’ve updated so much metadata recently</li>
</ul>
<h2id="2022-12-02">2022-12-02</h2>
<ul>
<li>File some issues related to metadata on the MEL issue tracker
<ul>
<li><ahref="https://github.com/CodeObia/MEL/issues/11066">Only use “Open Access” or “Limited Access” access rights when publishing items on CGSpace</a></li>
<li><ahref="https://github.com/CodeObia/MEL/issues/11067">Set the description when submitting bitstreams to CGSpace</a></li>
<li><ahref="https://github.com/CodeObia/MEL/issues/11068">Some items have a Creative Commons license, but are Limited Access and bitstreams are locked</a></li>
</ul>
</li>
</ul>
<h2id="2022-12-03">2022-12-03</h2>
<ul>
<li>I downloaded a fresh copy of CLARISA’s institutions list as well as ROR’s latest dump from 2022-12-01 to check how many are matching:</li>
<li>Out of the box they match 26.4%, but there are many institutions with multiple languages in the text value, as well as countries in parentheses so I think it could be higher</li>
<li>If I replace the slashes and remove the countries at the end there are slightly more matches, around 29%:</li>
<li>I checked CGSpace’s top 1,000 affiliations too, first exporting from PostgreSQL:</li>
</ul>
<divclass="highlight"><pretabindex="0"style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><codeclass="language-console"data-lang="console"><spanstyle="display:flex;"><span>localhost/dspacetest= ☘ \COPY (SELECT DISTINCT text_value as "cg.contributor.affiliation", count(*) FROM metadatavalue WHERE dspace_object_id IN (SELECT uuid FROM item) AND metadata_field_id = 211 GROUP BY text_value ORDER BY count DESC LIMIT 1000) to /tmp/2022-11-22-affiliations.csv;
</span></span></code></pre></div><ul>
<li>Then cutting (tab is the default delimeter):</li>
<li>So we likely match a bunch more than 50%…</li>
<li>I exported a list of affiliations and donors from CGSpace for Peter to look over and send corrections</li>
</ul>
<h2id="2022-12-05">2022-12-05</h2>
<ul>
<li>First day of PRMS technical workshop in Rome</li>
<li>Last night I submitted a CSV import with changes to 1,500 Alliance items (adding regions) and it hadn’t completed after twenty-four hours so I canceled it
<ul>
<li>Not sure if there is some rollback that will happen or what state the database will be in, so I will wait a few hours to see what happens before trying to modify those items again</li>
<li>I started it again a few hours later with a subset of the items and 4GB of RAM instead of 2</li>
<li>It completed successfully…</li>
</ul>
</li>
</ul>
<h2id="2022-12-07">2022-12-07</h2>
<ul>
<li>I found a bug in my csv-metadata-quality script regarding the regions
<ul>
<li>I was accidentally checking <code>cg.coverage.subregion</code> due to a sloppy regex</li>
<li>This means I’ve added a few thousand UN M.49 regions to the <code>cg.coverage.subregion</code> field in the last few days</li>
<li>I had to extract them from CGSpace and delete them using <code>delete-metadata-values.py</code></li>
</ul>
</li>
<li>My <ahref="https://github.com/DSpace/DSpace/pull/8550">DSpace 7.x pull request to tell ImageMagick about the PDF CropBox</a> was merged</li>
<li>Start a harvest on AReS</li>
</ul>
<h2id="2022-12-08">2022-12-08</h2>
<ul>
<li>While on the plane I decided to fix some ORCID identifiers, as I had seen some poorly formatted ones
<ul>
<li>I couldn’t remember the XPath syntax so this was kinda ghetto:</li>
<li>After that there were still some poorly formatted ones that my script didn’t fix, so perhaps these are new ones not in our list
<ul>
<li>I dumped them and combined with the existing ones to resolve later:</li>
</ul>
</li>
</ul>
<divclass="highlight"><pretabindex="0"style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><codeclass="language-console"data-lang="console"><spanstyle="display:flex;"><span>localhost/dspace= ☘ \COPY (SELECT dspace_object_id,text_value FROM metadatavalue WHERE metadata_field_id=247 AND text_value LIKE '%http%') to /tmp/orcid-formatting.txt;
<li>Maria mentioned that she was getting a lot more items in her daily subscription emails
<ul>
<li>I had a hunch it was related to me updating the <code>last_modified</code> timestamp after updating a bunch of countries, regions, etc in items</li>
<li>Then today I noticed this option in <code>dspace.cfg</code>: <code>eperson.subscription.onlynew</code></li>
<li>By default DSpace sends notifications for modified items too! I’ve disabled it now…</li>
</ul>
</li>
<li>I applied 498 fixes and two deletions to affiliations sent by Peter</li>
<li>I applied 206 fixes and eighty-one deletions to donors sent by Peter</li>
<li>I tried to figure out how to authenticate to the DSpace 7 REST API
<ul>
<li>First <ahref="https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md">you need a CSRF token</a>, before you can even try to authenticate</li>
<li>Then you can authenticate, but I can’t get it to work:</li>
</span></span><spanstyle="display:flex;"><span>$ curl -v -X POST --data <spanstyle="color:#e6db74">"user=aorth@omg.com&password=myPassword"</span><spanstyle="color:#e6db74">"https://dspace7test.ilri.org/server/authn/login"</span> -H <spanstyle="color:#e6db74">"X-XSRF-TOKEN: 0b7861fb-9c8a-4eea-be70-b3be3bd0a0b4"</span>
</span></span></code></pre></div><ul>
<li>Start a harvest on AReS</li>
</ul>
<h2id="2022-12-09">2022-12-09</h2>
<ul>
<li>I found a way to check the owner of a Handle prefix
<ul>
<li>You query the admin Handle for the prefix, ie: <ahref="https://hdl.handle.net/0.na/10568">https://hdl.handle.net/0.na/10568</a></li>
</ul>
</li>
</ul>
<h2id="2022-12-11">2022-12-11</h2>
<ul>
<li>I got LDAP authentication working on DSpace 7</li>
</ul>
<h2id="2022-12-12">2022-12-12</h2>
<ul>
<li>Submit some issues to MEL GitHub:
<ul>
<li><ahref="https://github.com/CodeObia/MEL/issues/11081">Links to https://mel.cgiar.org/dspace/limited for Limited Access items on CGSpace</a></li>
<li><ahref="https://github.com/CodeObia/MEL/issues/11083">Items submitted to CGSpace without Initiative</a></li>
</ul>
</li>
<li>PRMS planning meeting before tomorrow’s meeting with researchers and submitters</li>
</ul>
<h2id="2022-12-13">2022-12-13</h2>
<ul>
<li>I made some minor changes to csv-metadata-quality
<ul>
<li>I switched to using the SPDX license data as a JSON directly from SPDX, instead of via the now-deprecated spdx-license-list package on pypi</li>
</ul>
</li>
<li>I exported the Initiatives collection to tag missing regions</li>
<li>I submitted an issue to MEL GitHub:
<ul>
<li><ahref="https://github.com/CodeObia/MEL/issues/11084">Set the description of bitstreams in the THUMBNAIL bundle to “IM Thumbnail” when submitting to CGSpace</a></li>
</ul>
</li>
<li>Submit a pull request to <ahref="https://github.com/citizenlab/test-lists/pull/1199">fix the Handle link in the Citizen Lab test URLs for Iran</a>
<ul>
<li>I had originally submitted this in 2018, but it seems someone updated the URL in 2020… hmmm</li>
</ul>
</li>
<li>I normalized the <code>text_lang</code> values on CGSpace again:</li>
</ul>
<divclass="highlight"><pretabindex="0"style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><codeclass="language-console"data-lang="console"><spanstyle="display:flex;"><span>dspace=# SELECT DISTINCT text_lang, count(text_lang) FROM metadatavalue WHERE dspace_object_id IN (SELECT uuid FROM item) GROUP BY text_lang ORDER BY count DESC;
</span></span><spanstyle="display:flex;"><span>dspace=# UPDATE metadatavalue SET text_lang='en_US' WHERE dspace_object_id IN (SELECT uuid FROM item) AND text_lang IN ('en', '', NULL);
<li>I wrote an initial version of a script to map CGSpace items to Initiative collections based on their <code>cg.contributor.initiative</code> metadata
<ul>
<li>I am still considering if I want to add a mode to <em>un-map</em> items that are mapped to collections, but do not have the corresponding metadata tag</li>
</ul>
</li>
</ul>
<h2id="2022-12-14">2022-12-14</h2>
<ul>
<li>Lots of work on PRMS related metadata issues with CGSpace
<ul>
<li>We noticed that PRMS uses <code>cg.identifier.dataurl</code> for the FAIR score, but not <code>cg.identifier.url</code></li>
<li>We don’t use these consistently for datasets in CGSpace so I decided to move them to the dataurl field, but we will also ask the PRMS team to consider the normal URL field, as there are commonly other external resources related to the knowledge product there</li>
</ul>
</li>
<li>I updated the <code>move-metadata-values.py</code> script to use the latest best practices from my other scripts and some of the helper functions from <code>util.py</code>
<ul>
<li>Then I exported a list of text values pointing to Dataverse instances from <code>cg.identifier.url</code>:</li>
</ul>
</li>
</ul>
<divclass="highlight"><pretabindex="0"style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><codeclass="language-console"data-lang="console"><spanstyle="display:flex;"><span>localhost/dspace= ☘ \COPY (SELECT text_value FROM metadatavalue WHERE dspace_object_id IN (SELECT uuid FROM item) AND metadata_field_id=219 AND (text_value LIKE '%persistentId%' OR text_value LIKE '%20.500.11766.1/%')) to /tmp/data.txt;
<li>I still need to add a note to the CGSpace submission form to inform submitters about the correct field for dataset URLs</li>
<li>I finalized work on my new <code>fix-initiative-mappings.py</code> script
<ul>
<li>It has two modes:
<ol>
<li>Check item metadata to see which Initiatives are tagged and then map the item if it is not yet mapped to the corresponding Initiative collection</li>
<li>Check item collections to see which Initiatives are mapped and then unmap the item if the corresponding Initiative metadata is missing</li>
</ol>
</li>
<li>The second one is disabled by default until I can get more feedback from Abenet, Michael, and others</li>
</ul>
</li>
<li>After I applied a handful of collection mappings I started a harvest on AReS</li>
</ul>
<h2id="2022-12-15">2022-12-15</h2>
<ul>
<li>I did some metadata quality checks on the Initiatives collection, adding some missing regions and removing a few duplicate ones</li>
</ul>
<h2id="2022-12-18">2022-12-18</h2>
<ul>
<li>Load on the server is a bit high
<ul>
<li>Looking at the nginx logs I see someone from the University of Chicago (128.135.98.29) is using RStudio Desktop to query and scrape CGSpace</li>
<li>RStudio is already in the ILRI bot overrides for DSpace so it shouldn’t be causing any extra hits, but I’ll put an HTTP 403 in the nginx config to tell the user to use the REST API</li>
<li>Start a harvest on AReS</li>
</ul>
<h2id="2022-12-21">2022-12-21</h2>
<ul>
<li>I saw that load on CGSpace was over 20.0 for several hours
<ul>
<li>I saw there were some stuck locks in PostgreSQL:</li>
</ul>
</li>
</ul>
<divclass="highlight"><pretabindex="0"style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;"><codeclass="language-console"data-lang="console"><spanstyle="display:flex;"><span>$ psql -c <spanstyle="color:#e6db74">'SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid;'</span> | grep -o -E <spanstyle="color:#e6db74">'(dspaceWeb|dspaceApi|dspaceCli)'</span> | sort | uniq -c
</span></span><spanstyle="display:flex;"><span>WHERE pid IN (
</span></span><spanstyle="display:flex;"><span> SELECT pl.pid FROM pg_locks pl LEFT JOIN pg_stat_activity psa ON pl.pid = psa.pid WHERE psa.application_name = 'dspaceCli'
</span></span><spanstyle="display:flex;"><span>);
</span></span></code></pre></div><ul>
<li>For these fifty-eight locks there are only six queries running
<ul>
<li>Interestingly, they all started at either 04:00 or 05:00 this morning…</li>
</ul>
</li>
<li>I canceled one using <code>SELECT pg_cancel_backend(1098749);</code> and then two of the other PIDs died, perhaps they were dependent?
<ul>
<li>Then I canceled the next one and the remaining ones died also</li>
</ul>
</li>
<li>I exported the entire CGSpace and then ran the <code>fix-initiative-mappings.py</code> script, which found 124 items to be mapped
<ul>
<li>Getting only the items that have new mappings from the output file is currently tricky because you have to change the file to unix encoding, capture the diff output from the original, and re-add the column headers, but at least this makes the DSpace batch import have to check WAY fewer items</li>
<li>For the record, I used grep to get only the new lines:</li>
<li>Then I imported to CGSpace, and will start an AReS harvest once its done
<ul>
<li>The import process was quick but it triggered a lot of Solr updates and I see locks rising from dspaceCli again</li>
<li>After five hours the Solr updating from the metadata import wasn’t finished, so I cancelled it, and I see that the items were <em>not</em> mapped…</li>
<li>I split the CSV into multiple files, each with ten items, and the first one imported, but the second went on to do Solr updating stuff forever…</li>
<li>All twelve files worked except the second one, so it must be something with one of those items…</li>
</ul>
</li>
<li>Now I started a harvest on AReS</li>
</ul>
<h2id="2022-12-28">2022-12-28</h2>
<ul>
<li>I got a notice from UptimeRobot that CGSpace was down
<ul>
<li>I look at the server and the load is only 3 or 4.x and looking at Munin I don’t see any system statistics that are alarming</li>
<li>PostgreSQL locks look fine, memory and DSpace sessions look fine…</li>
<li>There were a strangely high number of tuple accesses half an hour ago, and high CPU going up to then</li>
<li>And I can access the website just fine, so I guess everything is OK</li>
<li>I exported the Initiatives collection to tag missing regions…</li>
</ul>
<h2id="2022-12-29">2022-12-29</h2>
<ul>
<li>I exported the Initiatives collection again and I’m wondering why we have so many items with <code>text_lang</code> set to NULL and others when I have been periodically resetting them
<ul>
<li>It turns out that doing <code>... text_lang IN ('en', '', NULL)</code> doesn’t properly check for values with NULL</li>
<li>I don’t see any other system statistics that look out of order…
<ul>
<li>DSpace sessions, network throughput, CPU, etc all seem sane…</li>
<li>And then all of a sudden, I didn’t do anything, but all the locks disappeared and I was able to access the website… WTF</li>
</ul>
</li>
</ul>
<h2id="2022-12-30">2022-12-30</h2>
<ul>
<li>Start a harvest on AReS</li>
</ul>
<h2id="2022-12-31">2022-12-31</h2>
<ul>
<li>I found a bunch of items on AReS that have issue dates in 2023 which made me curious
<ul>
<li>Looking closer, I think all of these have been tagged incorrectly because they were published online already in 2022</li>
<li>I sent a mail to Abenet and Bizu to ask, but for sure I know that PRMS will be considering first published date as first published date, no matter if that is online or in print</li>
<li>I also added some ORCID identifiers to our list and generated thumbnails for some journal articles that were Creative Commons</li>
