<li>Run all system updates on CGSpace and reboot it</li>
<li>I exported CGSpace to CSV to check for any missing Initiative collection mappings
<ul>
<li>I also did a check for missing country/region mappings with csv-metadata-quality</li>
</ul>
</li>
<li>Start a harvest on AReS</li>
</ul>
<ul>
<li>I’m starting to get annoyed at my shell script for doing ImageMagick tests and looking to re-write it in something object oriented like Python
<ul>
<li>There doesn’t seem to be an official ImageMagick Python binding on pypi.org, perhaps I can use <ahref="https://docs.wand-py.org">Wand</a>?</li>
<li>I spent more time re-working my thumbnail scripts to compare the resized images and other minor changes
<ul>
<li>I am realizing that doing the thumbnails directly from the source improves the ssimulacra2 score by 1-3% points compared to DSpace’s method of creating a lossy supersample followed by a lossy resized thumbnail</li>
</ul>
</li>
</ul>
<h2id="2023-04-03">2023-04-03</h2>
<ul>
<li>The harvest on AReS that I started yesterday never finished, and actually seems to have died…
<ul>
<li>Also, Fabio and Patrizio from Alliance emailed me to ask if there is something wrong with the REST API because they are having problems</li>
<li>I stopped the harvest and started the plugins to get the remaining items via the sitemap…</li>
</ul>
</li>
</ul>
<h2id="2023-04-04">2023-04-04</h2>
<ul>
<li>Presentation about CGSpace metadata, controlled vocabularies, and curation to Pooja’s communications and development team at UNEP
<ul>
<li>I uploaded the presentation to CGSpace here: <ahref="https://hdl.handle.net/10568/129896">https://hdl.handle.net/10568/129896</a></li>
</ul>
</li>
<li>Someone from the system organization contacted me to ask how to download a few thousand PDFs from a spreadsheet with DOIs and Handles</li>
<li>Then I used the <code>get_dspace_pdfs.py</code> script to download them</li>
</ul>
<h2id="2023-04-05">2023-04-05</h2>
<ul>
<li>After some cleanup on Donald’s DOIs I started the <code>get_scihub_pdfs.py</code> script</li>
</ul>
<h2id="2023-04-06">2023-04-06</h2>
<ul>
<li>I did some more work to cleanup and streamline my next generation of DSpace thumbnail testing scripts
<ul>
<li>I think I found a bug in ImageMagick 7.1.1.5 where CMYK to sRGB conversion fails if we use image operations like <code>-density</code> or <code>-define</code> before reading the input file</li>
<li>I started <ahref="https://github.com/ImageMagick/ImageMagick/discussions/6234">a discussion on the ImageMagick GitHub</a> to ask</li>
</ul>
</li>
<li>Yesterday I started downloading the rest of the PDFs from Donald, those that had DOIs
<ul>
<li>As a measure of caution, I extracted the list of DOIs and used my <code>crossref_doi_lookup.py</code> script to get their licenses from Crossref:</li>
<li>Then I did some CSV manipulation to extract the DOIs that were Creative Commons licensed, excluding any that were “No Derivatives”, and re-formatting the DOIs:</li>
<li>From those I filtered for the DOIs for which I had downloaded PDFs, in the <code>filename</code> column of the Sci-Hub script and copied them to a separate directory:</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>$ <spanstyle="color:#66d9ef">for</span> file in <spanstyle="color:#66d9ef">$(</span>csvjoin -c doi /tmp/donald-doi-pdfs.csv /tmp/donald-open-dois.csv | csvgrep -c filename -i -r <spanstyle="color:#e6db74">'^$'</span> | csvcut -c filename | sed 1d<spanstyle="color:#66d9ef">)</span>; <spanstyle="color:#66d9ef">do</span> cp --reflink<spanstyle="color:#f92672">=</span>always <spanstyle="color:#e6db74">"</span>$file<spanstyle="color:#e6db74">"</span><spanstyle="color:#e6db74">"creative-commons-licensed/</span>$file<spanstyle="color:#e6db74">"</span>; <spanstyle="color:#66d9ef">done</span>
</span></span></code></pre></div><ul>
<li>I used BTRFS copy-on-write via reflinks to make sure I didn’t duplicate the files :-D</li>
<li>I ran out of time and had to stop the process around 3,127 PDFs
<ul>
<li>I zipped them up and sent them to the others, along with a CSV of the DOIs, PDF filenames, and licenses</li>
</ul>
</li>
</ul>
<h2id="2023-04-17">2023-04-17</h2>
<ul>
<li>Abenet noticed a weird issue with <ahref="https://cgspace.cgiar.org/handle/10568/75611">this item</a>
<ul>
<li>The item has metadata, but the page is blank</li>
<li>When I try to edit the item’s authorization policies in XMLUI I get a nullPointerException:</li>
<li>I’m also running a <code>dspace cleanup -v</code>, but it doesn’t seem to be finishing
<ul>
<li>I recall something like there being errors in the logs rather than on the command line in DSpace 6…</li>
<li>I found it in the DSpace log:</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>2023-04-17 21:09:46,004 ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper @ ERROR: update or delete on table "bitstream" violates foreign key constraint "bundle_primary_bitstream_id_fkey" on table "bundle"
</span></span><spanstyle="display:flex;"><span> Detail: Key (uuid)=(a7ddf477-1c04-4de0-9c7a-4d3c84a875bc) is still referenced from table "bundle".
</span></span></code></pre></div><ul>
<li>If I mark the primary bitstream as null manually the cleanup script continues until it finds a few more
<ul>
<li>I ended up with a long list of UUIDs to fix before the script would complete:</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 -d dspace -c <spanstyle="color:#e6db74">"update bundle set primary_bitstream_id=NULL where primary_bitstream_id in ('a7ddf477-1c04-4de0-9c7a-4d3c84a875bc', '9582b661-9c2d-4c86-be22-c3b0942b646a', '210a4d5d-3af9-46f0-84cc-682dd1431762', '51115f07-0a60-4988-8536-b9ebd2a5e15e', '0fc5021d-3264-413a-b2e2-74bda38a394e', '4704fa62-b8ab-4dfe-b7aa-0e4905f8412a')"</span>
</span></span></code></pre></div><ul>
<li>This process ended up taking a few days because each iteration ran for over four hours before failing on the next UUID, sighhhhh</li>
</ul>
<h2id="2023-04-18">2023-04-18</h2>
<ul>
<li>Regarding the item Abenet noticed yesterday that has a blank page and a nullPointerException
<ul>
<li>It appears OK on DSpace Test! <ahref="https://dspacetest.cgiar.org/handle/10568/75611">https://dspacetest.cgiar.org/handle/10568/75611</a></li>
<li>And according to the REST API on CGSpace the item was modified on 2023-04-11, so last week…</li>
<li>According to the DSpace logs it was Francesca who edited the item last week, so I asked her for more information before I troubleshoot more</li>
</ul>
</li>
</ul>
<h2id="2023-04-19">2023-04-19</h2>
<ul>
<li>I fixed the Bioversity item by deleting the <code>9781138781276.jpg</code> bitstream via the REST API
<ul>
<li>I <em>think</em> Francesca might have changed the “format” of it?</li>
<li>Anyway, this item has a PDF so we have a proper thumbnail and don’t need that other journal cover one</li>
</ul>
</li>
<li>I noticed a URL for this <ahref="https://hdl.handle.net/10568/89049">Bioversity item</a> redirects incorrectly
<ul>
<li>I had mentioned this to Maria and Francesca a few months ago but it seems to never have been resolved</li>
</ul>
</li>
<li>The <code>dspace cleanup -v</code> finally finished after a few days of running and stopping…</li>
<li>I decided to update the thumbnails in the Bioversity books collection because I saw a few old ones suffering from the CropBox issue</li>
<li>Also, all day there’s been a high load on CGSpace, with lots of locks in PostgreSQL
<ul>
<li>I had been waiting until the bitstream cleanup finished… now I might need to restart PostgreSQL to kill some old locks as something needs to give</li>
<li>I restarted PostgreSQL, but DSpace was still hanging on simple XMLUI options so I ended up restarting Tomcat</li>
</ul>
</li>
<li>Tag 544 ORCID identifiers with my script</li>
<li>I updated my <code>generation-loss.sh</code> and <code>improved-dspace-thumbnails</code> scripts to include thirty-five PDFs from CGSpace (up from twenty-four) to get a larger sample
<ul>
<li>Now starting to get some numbers comparing JPEG, WebP, and AVIF</li>
<li>First, out of curiousity, I checked the average ssimulacra2 scores at Q75, Q80, and Q92 for each format:</li>
</ul>
</li>
</ul>
<table>
<thead>
<tr>
<th></th>
<th>Q75</th>
<th>Q80</th>
<th>Q92</th>
</tr>
</thead>
<tbody>
<tr>
<td>JPEG</td>
<td>71</td>
<td>74</td>
<td>88</td>
</tr>
<tr>
<td>WebP</td>
<td>74</td>
<td>77</td>
<td>82</td>
</tr>
<tr>
<td>AVIF</td>
<td>82</td>
<td>83</td>
<td>86</td>
</tr>
</tbody>
</table>
<ul>
<li>Then I checked the quality and file size (bytes) needed to hit an average ssimulacra2 score of 80 with each format:
<ul>
<li><strong>JPEG</strong>: Q89, 124923 bytes</li>
<li><strong>WebP</strong>: Q86, 84662 bytes (33% smaller than JPEG size)</li>
<li><strong>AVIF</strong>: Q65, 67597 bytes (56% smaller than JPEG size)</li>
</ul>
</li>
<li><ahref="https://developers.google.com/speed/webp/docs/webp_study">Google’s original WebP study</a> uses this technique to compare WebP to JPEG too
<ul>
<li>As the quality settings are not comparable between formats, we need to compare the formats at matching perceptual scores (ssimulacra2 in this case)</li>
<li>I used a ssimulacra2 score of 80 because that’s the about the highest score I see with WebP using my samples, though JPEG and AVIF do go higher</li>
<li>Also, according to current ssimulacra2 (v2.1), a score of 70 is “high quality” and a score of 90 is “very high quality”, so 80 should be reasonably high enough…</li>
</ul>
</li>
<li>Here is a plot of the qualities and ssimulacra2 scores:</li>
</ul>
<p><imgsrc="/cgspace-notes/2023/04/quality-vs-score-ssimulacra-v2.1.png"alt="Quality vs Score"></p>
<ul>
<li>Export CGSpace to check for missing Initiatives mappings</li>
</ul>
<h2id="2023-04-22">2023-04-22</h2>
<ul>
<li>Export the Initiatives collection to run it through csv-metadata-quality
<ul>
<li>I wanted to make sure all the Initiatives items had correct regions</li>
<li>I had to manually fix a few license identifiers and ISSNs</li>
<li>Also, I found a few items submitted by MEL that had dates in DD/MM/YYYY format, so I sent them to Salem for him to investigate</li>
</ul>
</li>
<li>Start a harvest on AReS</li>
</ul>
<h2id="2023-04-26">2023-04-26</h2>
<ul>
<li>Begin working on the list of non-AGROVOC CGSpace subjects for FAO
<ul>
<li>The last time I did this was in 2022-06</li>
<li>I used the following SQL query to dump values from all subject fields, lower case them, and group by counts:</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/dspacetest= ☘ \COPY (SELECT DISTINCT(lower(text_value)) AS "subject", count(*) FROM metadatavalue WHERE dspace_object_id in (SELECT dspace_object_id FROM item) AND metadata_field_id IN (187, 120, 210, 122, 215, 127, 208, 124, 128, 123, 125, 135, 203, 236, 238, 119) GROUP BY "subject" ORDER BY count DESC) to /tmp/2023-04-26-cgspace-subjects.csv WITH CSV HEADER;
<li>The AGROVOC lookup from yesterday finished, so I extracted all terms that did not match and joined them with the original CSV so I can see the counts:
<ul>
<li>(I also note that the <code>agrovoc_lookup.py</code> script didn’t seem to be caching properly, as it had to look up everything again the next time I ran it despite the requests cache being 174MB!)</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>csvgrep -c 'number of matches' -r '^0$' /tmp/2023-04-26-cgspace-subjects-results.csv \
<li>I filtered for only those terms that had counts larger than fifty
<ul>
<li>I also removed terms like “forages”, “policy”, “pests and diseases” because those exist as singular or separate terms in AGROVOC</li>
<li>I also removed ambiguous terms like “cocoa”, “diversity”, “resistance” etc because there are various other preferred terms for those in AGROVOC</li>
<li>I also removed spelling mistakes like “modeling” and “savanas” because those exist in their correct form in AGROVOC</li>
<li>I also removed internal CGIAR terms like “tac”, “crp”, “internal review” etc (note: these are mostly from CGIAR System Office’s subjects… perhaps I exclude those next time?)</li>
</ul>
</li>
<li>I note that many of <em>our</em> terms would match if they were singular, plural, or split up into separate terms, so perhaps we should pair this with an excercise to review our own terms</li>
<li>I couldn’t finish the work locally yet so I uploaded my list to Google Docs to continue later</li>
</ul>
<h2id="2023-04-28">2023-04-28</h2>
<ul>
<li>The ImageMagick CMYK issue is bothering me still
<ul>
<li>I am on a plane currently, but I have a Docker image of ImageMagick 7.1.1-3 and I compared the output of all CMYK PDFs using the same command on my local machine</li>
<li>The images from the Docker environment are correct with <em>only</em><code>-colorspace sRGB</code> (no profiles!) as the commenters on GitHub said</li>
<li>This leads me to believe something wrong in my own environment, perhaps Ghostscript…?</li>
<li>The container has Ghostscript 9.53.3~dfsg-7+deb11u2 from Debian 11, while my Arch Linux system has Ghostscript 10.01.1-1</li>
