I found that Crossref’s metadata is in the public domain under the CC0 license
One interesting thing is the abstracts, which are copyrighted by the copyright owner, meaning Crossref cannot waive the copyright under the terms of the CC0 license, because it is not theirs to waive
We can be on the safe side by using only abstracts for items that are licensed under Creative Commons
I found that Crossref’s metadata is in the public domain under the CC0 license
One interesting thing is the abstracts, which are copyrighted by the copyright owner, meaning Crossref cannot waive the copyright under the terms of the CC0 license, because it is not theirs to waive
We can be on the safe side by using only abstracts for items that are licensed under Creative Commons
<li>I found that <ahref="https://www.crossref.org/documentation/retrieve-metadata/rest-api/rest-api-metadata-license-information/">Crossref’s metadata is in the public domain under the CC0 license</a></li>
<li>One interesting thing is the abstracts, which are copyrighted by the copyright owner, meaning Crossref cannot waive the copyright under the terms of the CC0 license, because it is not theirs to waive</li>
<li>We can be on the safe side by using only abstracts for items that are licensed under Creative Commons</li>
</ul>
</li>
</ul>
<ul>
<li>This GREL extracts the <em>text</em> content of the <code><jats:p></code> tags (ie, no other JATS XML markup tags like <code><jats:i></code>, <code><jats:sub></code>, etc):</li>
<li>Note that we need to use <code>select("jats|p")</code> instead of <code>select("jats:p")</code> for OpenRefine’s parseXml, and we need to <code>join()</code> on the end</li>
<li>I updated metadata for about 3,000 items using Crossref metadata
<ul>
<li>I stripped trailing periods for titles where they were missing on the Crossref titles</li>
<li>I copied abstracts for about 600 items that were missing them, for items that were Creative Commons</li>
<li>I updated publishers for a few thousand more where ours and Crossref disagreed, checking a handful manually first</li>
</ul>
</li>
<li>I also added subjects to the <code>crossref_doi_lookup.py</code> script to see if they will be useful for us
<ul>
<li>When checking with csv-metadata-quality I can validate those subjects against AGROVOC and add them if they are valid</li>
</ul>
</li>
</ul>
<h2id="2023-10-03">2023-10-03</h2>
<ul>
<li>I added the item type to the collection subscription email on DSpace 6
<ul>
<li>It’s done differently on DSpace 7 so I’ll have to see how to do it there…</li>
</ul>
</li>
<li>Test a patch that fixes a bug with item versioning disabled in DSpace 7
<ul>
<li>I hadn’t realized that DSpace 7 defaulted to versioning being enabled, whereas we never used this in DSpace 6 (yet)</li>
<li>Some discussion this week about issue and online dates for journal articles, with regards to PRMS
<ul>
<li>I looked more closely at the <ahref="https://github.com/CrossRef/rest-api-doc/blob/master/api_format.md">Crossref API docs</a> and realized (again) that their “issue” date is not the same as our issue date—they take the earlier of the print and online dates!</li>
<li>Also, <em>very many</em> items have no print date at all, perhaps due to delays, errors, or simply because the journal is “online only”!</li>
<li>I suggested again that PRMS should consider both, and take the earlier of the two, then make sure whether the date is in the current reporting period</li>
<li>I managed to find 80 items with print publishing dates from 2023 and updated those from Crossref, but for the rest we will have to think about how we handle them</li>
<li>More discussion about dates after looking closely at them yesterday and today
<ul>
<li>Crossref doesn’t always have both issued and online dates—sometimes they have one, sometimes the other, and sometimes both, so we cannot rely on them 100% for that.</li>
<li>In some cases, the item is available online for months (or even a year!), but has not been included in an issue yet, and thus has no “issue” date, for example:
<ul>
<li><ahref="https://doi.org/10.1002/csc2.20914">https://doi.org/10.1002/csc2.20914</a><— published online January 2023!</li>
<li><ahref="https://doi.org/10.1111/mcn.13401">https://doi.org/10.1111/mcn.13401</a><— published online July 2022!</li>
</ul>
</li>
<li>Even journals make mistakes: this journal article was “issued” in 2022, but online in 2023! This is not Crossref’s fault, but the journal’s!
<li>Starting to see some stuck locks on CGSpace this morning
<ul>
<li>I will give notice and restart CGSpace</li>
</ul>
</li>
<li>Work on Python script to harvest DSpace REST API and save to CSV</li>
</ul>
<h2id="2023-10-11">2023-10-11</h2>
<ul>
<li>File an issue on the DSpace issue tracker regarding the MaxMind JSON objects in our Solr statistics: <ahref="https://github.com/DSpace/DSpace/issues/9118">https://github.com/DSpace/DSpace/issues/9118</a></li>
</ul>
<h2id="2023-10-12">2023-10-12</h2>
<ul>
<li>Discuss MODS issues in CGSpace’s OAI-PMH with Stefano and Valentina
<ul>
<li>AGRIS can currently only support MODS 3.7 so they need us to roll our 3.8 work from 2023-06 back down, which requires some minor changes to the crosswalk</li>
</ul>
</li>
</ul>
<h2id="2023-10-13">2023-10-13</h2>
<ul>
<li>I did some more minor work to get the MODS 3.7 changes ready for AGRIS on DSpace Test</li>
<li>Port the MODS 3.7 crosswalk from DSpace 6 to DSpace 7
<ul>
<li>It works fine, we only need to take note that the OAI-PMH endpoint is now relative to the <code>/server</code> path instead of a dedicated OAI path</li>
</ul>
</li>
</ul>
<h2id="2023-10-17">2023-10-17</h2>
<ul>
<li>Export CGSpace to do some cleanups all over on invalid metadata values
<ul>
<li>I found many metadata values in the wrong field, wrong format, etc</li>
<li>This ended up being cleanups for 694 items</li>
</ul>
</li>
</ul>
<h2id="2023-10-20">2023-10-20</h2>
<ul>
<li>Export CGSpace to check for missing Initiative collection mappings</li>
<li>I also did a run of looking up all Initiative outputs with DOIs against Crossref to check for missing dates, publishers, etc
<ul>
<li>I found issued dates for a few, and online dates for over 100</li>
<li>I also fixed some incorrect licenses, access status, and abstracts</li>
</ul>
</li>
</ul>
<h2id="2023-10-23">2023-10-23</h2>
<ul>
<li>Export a list of Internal Documents for Peter to review to see if we can re-classify some
<ul>
<li>Peter sent changes for 740 items so I applied them on CGSpace</li>
</ul>
</li>
<li>Testing the changes for OpenRXV DSpace 7 compatibility</li>
</ul>
<h2id="2023-10-24">2023-10-24</h2>
<ul>
<li>Sync DSpace 7 Test with a fresh CGSpace snapshot</li>
<li>Meeting with FARA to discuss DSpace training and support</li>
<li>Meeting with IFPRI about migrating to CGSpace</li>
</ul>
<h2id="2023-10-25">2023-10-25</h2>
<ul>
<li>Maria was asking about an error deleting an item in the Alliance community
<ul>
<li>The error was “Authorization denied for action OBSOLETE (DELETE) on BITSTREAM:…”</li>
<li>According to my notes this error happened a few times in the past and is some kind of corner case regarding permissions</li>
<li>I deleted the item for her</li>
</ul>
</li>
<li>I deleted a handful of old CRP groups on CGSpace</li>
</ul>
<h2id="2023-10-27">2023-10-27</h2>
<ul>
<li>Peter sent me a list of journal articles from Altmetric that have an ILRI affiliation, but no Handle
<ul>
<li>I used my <code>crossref_doi_lookup.py</code> script to fetch the metadata for them using their DOIs, then did a bunch of cleanup in OpenRefine</li>
