Update notes for 2017-03-05

This commit is contained in:
Alan Orth 2017-03-05 15:30:36 +02:00
parent 22f2d07eca
commit aa83af57b2
Signed by: alanorth
GPG Key ID: 0FB860CC9C45B1B9
6 changed files with 260 additions and 7 deletions

View File

@ -59,6 +59,12 @@ $ identify -format '%r\n' Africa\ group\ of\ negotiators.pdf\[0\]
DirectClass sRGB Alpha
```
## 2017-03-04
- Spent more time looking at the ImageMagick CMYK issue
- The `default_cmyk.icc` and `default_rgb.icc` files are both part of the Ghostscript GPL distribution, but according to DSpace's `LICENSES_THIRD_PARTY` file, DSpace doesn't allow distribution of dependencies that are licensed solely under the GPL
- So this issue is kinda pointless now, as the ICC profiles are absolutely necessary to make a meaningful CMYK→sRGB conversion
## 2017-03-05
- Look into helping developers from landportal.info with a query for items related to LAND on the REST API
@ -70,3 +76,42 @@ $ curl -s -H "accept: application/json" -H "Content-Type: application/json" -X P
```
- But there are hundreds of combinations of fields and values (like `dc.subject` and all the center subjects), and we can't use wildcards in REST!
- Reading about enabling multiple handle prefixes in DSpace
- There is a mailing list thread from 2011 about it: http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html
- And a comment from Atmire's Bram about it on the DSpace wiki: https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296
- Bram mentions an undocumented configuration option `handle.plugin.checknameauthority`, but I noticed another one in `dspace.cfg`:
```
# List any additional prefixes that need to be managed by this handle server
# (as for examle handle prefix coming from old dspace repository merged in
# that repository)
# handle.additional.prefixes = prefix1[, prefix2]
```
- Because of this I noticed that our Handle server's `config.dct` was potentially misconfigured!
- We had some default values still present:
```
"300:0.NA/YOUR_NAMING_AUTHORITY"
```
- I've changed them to the following and restarted the handle server:
```
"300:0.NA/10568"
```
- In looking at all the configs I just noticed that we are not providing a DOI in the Google-specific metadata crosswalk
- From `dspace/config/crosswalks/google-metadata.properties`:
```
google.citation_doi = cg.identifier.doi
```
- This works, and makes DSpace output the following metadata on the item view page:
```
<meta content="https://dx.doi.org/10.1186/s13059-017-1153-y" name="citation_doi">
```
- Submitted and merged pull request for this: https://github.com/ilri/DSpace/pull/305

View File

@ -37,7 +37,7 @@ $ identify ~/Desktop/alc_contrastes_desafios.jpg
<meta property="article:published_time" content="2017-03-01T17:08:52&#43;02:00"/>
<meta property="article:modified_time" content="2017-03-04T01:15:47&#43;02:00"/>
<meta property="article:modified_time" content="2017-03-05T12:39:09&#43;02:00"/>
@ -94,13 +94,13 @@ $ identify ~/Desktop/alc_contrastes_desafios.jpg
"headline": "March, 2017",
"url": "https://alanorth.github.io/cgspace-notes/2017-03/",
"wordCount": "465",
"wordCount": "692",
"datePublished": "2017-03-01T17:08:52&#43;02:00",
"dateModified": "2017-03-04T01:15:47&#43;02:00",
"dateModified": "2017-03-05T12:39:09&#43;02:00",
"author": {
@ -232,6 +232,14 @@ $ identify -format '%r\n' Africa\ group\ of\ negotiators.pdf\[0\]
DirectClass sRGB Alpha
</code></pre>
<h2 id="2017-03-04">2017-03-04</h2>
<ul>
<li>Spent more time looking at the ImageMagick CMYK issue</li>
<li>The <code>default_cmyk.icc</code> and <code>default_rgb.icc</code> files are both part of the Ghostscript GPL distribution, but according to DSpace&rsquo;s <code>LICENSES_THIRD_PARTY</code> file, DSpace doesn&rsquo;t allow distribution of dependencies that are licensed solely under the GPL</li>
<li>So this issue is kinda pointless now, as the ICC profiles are absolutely necessary to make a meaningful CMYK→sRGB conversion</li>
</ul>
<h2 id="2017-03-05">2017-03-05</h2>
<ul>
@ -245,6 +253,50 @@ DirectClass sRGB Alpha
<ul>
<li>But there are hundreds of combinations of fields and values (like <code>dc.subject</code> and all the center subjects), and we can&rsquo;t use wildcards in REST!</li>
<li>Reading about enabling multiple handle prefixes in DSpace</li>
<li>There is a mailing list thread from 2011 about it: <a href="http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html">http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html</a></li>
<li>And a comment from Atmire&rsquo;s Bram about it on the DSpace wiki: <a href="https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296">https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296</a></li>
<li>Bram mentions an undocumented configuration option <code>handle.plugin.checknameauthority</code>, but I noticed another one in <code>dspace.cfg</code>:</li>
</ul>
<pre><code># List any additional prefixes that need to be managed by this handle server
# (as for examle handle prefix coming from old dspace repository merged in
# that repository)
# handle.additional.prefixes = prefix1[, prefix2]
</code></pre>
<ul>
<li>Because of this I noticed that our Handle server&rsquo;s <code>config.dct</code> was potentially misconfigured!</li>
<li>We had some default values still present:</li>
</ul>
<pre><code>&quot;300:0.NA/YOUR_NAMING_AUTHORITY&quot;
</code></pre>
<ul>
<li>I&rsquo;ve changed them to the following and restarted the handle server:</li>
</ul>
<pre><code>&quot;300:0.NA/10568&quot;
</code></pre>
<ul>
<li>In looking at all the configs I just noticed that we are not providing a DOI in the Google-specific metadata crosswalk</li>
<li>From <code>dspace/config/crosswalks/google-metadata.properties</code>:</li>
</ul>
<pre><code>google.citation_doi = cg.identifier.doi
</code></pre>
<ul>
<li>This works, and makes DSpace output the following metadata on the item view page:</li>
</ul>
<pre><code>&lt;meta content=&quot;https://dx.doi.org/10.1186/s13059-017-1153-y&quot; name=&quot;citation_doi&quot;&gt;
</code></pre>
<ul>
<li>Submitted and merged pull request for this: <a href="https://github.com/ilri/DSpace/pull/305">https://github.com/ilri/DSpace/pull/305</a></li>
</ul>

View File

@ -78,6 +78,14 @@ $ identify -format &#39;%r\n&#39; Africa\ group\ of\ negotiators.pdf\[0\]
DirectClass sRGB Alpha
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id=&#34;2017-03-04&#34;&gt;2017-03-04&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Spent more time looking at the ImageMagick CMYK issue&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;default_cmyk.icc&lt;/code&gt; and &lt;code&gt;default_rgb.icc&lt;/code&gt; files are both part of the Ghostscript GPL distribution, but according to DSpace&amp;rsquo;s &lt;code&gt;LICENSES_THIRD_PARTY&lt;/code&gt; file, DSpace doesn&amp;rsquo;t allow distribution of dependencies that are licensed solely under the GPL&lt;/li&gt;
&lt;li&gt;So this issue is kinda pointless now, as the ICC profiles are absolutely necessary to make a meaningful CMYK→sRGB conversion&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;2017-03-05&#34;&gt;2017-03-05&lt;/h2&gt;
&lt;ul&gt;
@ -91,6 +99,50 @@ DirectClass sRGB Alpha
&lt;ul&gt;
&lt;li&gt;But there are hundreds of combinations of fields and values (like &lt;code&gt;dc.subject&lt;/code&gt; and all the center subjects), and we can&amp;rsquo;t use wildcards in REST!&lt;/li&gt;
&lt;li&gt;Reading about enabling multiple handle prefixes in DSpace&lt;/li&gt;
&lt;li&gt;There is a mailing list thread from 2011 about it: &lt;a href=&#34;http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html&#34;&gt;http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;And a comment from Atmire&amp;rsquo;s Bram about it on the DSpace wiki: &lt;a href=&#34;https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296&#34;&gt;https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Bram mentions an undocumented configuration option &lt;code&gt;handle.plugin.checknameauthority&lt;/code&gt;, but I noticed another one in &lt;code&gt;dspace.cfg&lt;/code&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;# List any additional prefixes that need to be managed by this handle server
# (as for examle handle prefix coming from old dspace repository merged in
# that repository)
# handle.additional.prefixes = prefix1[, prefix2]
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Because of this I noticed that our Handle server&amp;rsquo;s &lt;code&gt;config.dct&lt;/code&gt; was potentially misconfigured!&lt;/li&gt;
&lt;li&gt;We had some default values still present:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;quot;300:0.NA/YOUR_NAMING_AUTHORITY&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;I&amp;rsquo;ve changed them to the following and restarted the handle server:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;quot;300:0.NA/10568&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;In looking at all the configs I just noticed that we are not providing a DOI in the Google-specific metadata crosswalk&lt;/li&gt;
&lt;li&gt;From &lt;code&gt;dspace/config/crosswalks/google-metadata.properties&lt;/code&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;google.citation_doi = cg.identifier.doi
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;This works, and makes DSpace output the following metadata on the item view page:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;lt;meta content=&amp;quot;https://dx.doi.org/10.1186/s13059-017-1153-y&amp;quot; name=&amp;quot;citation_doi&amp;quot;&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Submitted and merged pull request for this: &lt;a href=&#34;https://github.com/ilri/DSpace/pull/305&#34;&gt;https://github.com/ilri/DSpace/pull/305&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description>
</item>

View File

@ -78,6 +78,14 @@ $ identify -format &#39;%r\n&#39; Africa\ group\ of\ negotiators.pdf\[0\]
DirectClass sRGB Alpha
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id=&#34;2017-03-04&#34;&gt;2017-03-04&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Spent more time looking at the ImageMagick CMYK issue&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;default_cmyk.icc&lt;/code&gt; and &lt;code&gt;default_rgb.icc&lt;/code&gt; files are both part of the Ghostscript GPL distribution, but according to DSpace&amp;rsquo;s &lt;code&gt;LICENSES_THIRD_PARTY&lt;/code&gt; file, DSpace doesn&amp;rsquo;t allow distribution of dependencies that are licensed solely under the GPL&lt;/li&gt;
&lt;li&gt;So this issue is kinda pointless now, as the ICC profiles are absolutely necessary to make a meaningful CMYK→sRGB conversion&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;2017-03-05&#34;&gt;2017-03-05&lt;/h2&gt;
&lt;ul&gt;
@ -91,6 +99,50 @@ DirectClass sRGB Alpha
&lt;ul&gt;
&lt;li&gt;But there are hundreds of combinations of fields and values (like &lt;code&gt;dc.subject&lt;/code&gt; and all the center subjects), and we can&amp;rsquo;t use wildcards in REST!&lt;/li&gt;
&lt;li&gt;Reading about enabling multiple handle prefixes in DSpace&lt;/li&gt;
&lt;li&gt;There is a mailing list thread from 2011 about it: &lt;a href=&#34;http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html&#34;&gt;http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;And a comment from Atmire&amp;rsquo;s Bram about it on the DSpace wiki: &lt;a href=&#34;https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296&#34;&gt;https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Bram mentions an undocumented configuration option &lt;code&gt;handle.plugin.checknameauthority&lt;/code&gt;, but I noticed another one in &lt;code&gt;dspace.cfg&lt;/code&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;# List any additional prefixes that need to be managed by this handle server
# (as for examle handle prefix coming from old dspace repository merged in
# that repository)
# handle.additional.prefixes = prefix1[, prefix2]
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Because of this I noticed that our Handle server&amp;rsquo;s &lt;code&gt;config.dct&lt;/code&gt; was potentially misconfigured!&lt;/li&gt;
&lt;li&gt;We had some default values still present:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;quot;300:0.NA/YOUR_NAMING_AUTHORITY&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;I&amp;rsquo;ve changed them to the following and restarted the handle server:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;quot;300:0.NA/10568&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;In looking at all the configs I just noticed that we are not providing a DOI in the Google-specific metadata crosswalk&lt;/li&gt;
&lt;li&gt;From &lt;code&gt;dspace/config/crosswalks/google-metadata.properties&lt;/code&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;google.citation_doi = cg.identifier.doi
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;This works, and makes DSpace output the following metadata on the item view page:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;lt;meta content=&amp;quot;https://dx.doi.org/10.1186/s13059-017-1153-y&amp;quot; name=&amp;quot;citation_doi&amp;quot;&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Submitted and merged pull request for this: &lt;a href=&#34;https://github.com/ilri/DSpace/pull/305&#34;&gt;https://github.com/ilri/DSpace/pull/305&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description>
</item>

View File

@ -3,7 +3,7 @@
<url>
<loc>https://alanorth.github.io/cgspace-notes/2017-03/</loc>
<lastmod>2017-03-04T01:15:47+02:00</lastmod>
<lastmod>2017-03-05T12:39:09+02:00</lastmod>
</url>
<url>
@ -88,19 +88,19 @@
<url>
<loc>https://alanorth.github.io/cgspace-notes/</loc>
<lastmod>2017-03-04T01:15:47+02:00</lastmod>
<lastmod>2017-03-05T12:39:09+02:00</lastmod>
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/tags/notes/</loc>
<lastmod>2017-03-04T01:15:47+02:00</lastmod>
<lastmod>2017-03-05T12:39:09+02:00</lastmod>
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/post/</loc>
<lastmod>2017-03-04T01:15:47+02:00</lastmod>
<lastmod>2017-03-05T12:39:09+02:00</lastmod>
<priority>0</priority>
</url>

View File

@ -77,6 +77,14 @@ $ identify -format &#39;%r\n&#39; Africa\ group\ of\ negotiators.pdf\[0\]
DirectClass sRGB Alpha
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id=&#34;2017-03-04&#34;&gt;2017-03-04&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Spent more time looking at the ImageMagick CMYK issue&lt;/li&gt;
&lt;li&gt;The &lt;code&gt;default_cmyk.icc&lt;/code&gt; and &lt;code&gt;default_rgb.icc&lt;/code&gt; files are both part of the Ghostscript GPL distribution, but according to DSpace&amp;rsquo;s &lt;code&gt;LICENSES_THIRD_PARTY&lt;/code&gt; file, DSpace doesn&amp;rsquo;t allow distribution of dependencies that are licensed solely under the GPL&lt;/li&gt;
&lt;li&gt;So this issue is kinda pointless now, as the ICC profiles are absolutely necessary to make a meaningful CMYK→sRGB conversion&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;2017-03-05&#34;&gt;2017-03-05&lt;/h2&gt;
&lt;ul&gt;
@ -90,6 +98,50 @@ DirectClass sRGB Alpha
&lt;ul&gt;
&lt;li&gt;But there are hundreds of combinations of fields and values (like &lt;code&gt;dc.subject&lt;/code&gt; and all the center subjects), and we can&amp;rsquo;t use wildcards in REST!&lt;/li&gt;
&lt;li&gt;Reading about enabling multiple handle prefixes in DSpace&lt;/li&gt;
&lt;li&gt;There is a mailing list thread from 2011 about it: &lt;a href=&#34;http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html&#34;&gt;http://dspace.2283337.n4.nabble.com/Multiple-handle-prefixes-merged-DSpace-instances-td3427192.html&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;And a comment from Atmire&amp;rsquo;s Bram about it on the DSpace wiki: &lt;a href=&#34;https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296&#34;&gt;https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace?focusedCommentId=78163296#comment-78163296&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Bram mentions an undocumented configuration option &lt;code&gt;handle.plugin.checknameauthority&lt;/code&gt;, but I noticed another one in &lt;code&gt;dspace.cfg&lt;/code&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;# List any additional prefixes that need to be managed by this handle server
# (as for examle handle prefix coming from old dspace repository merged in
# that repository)
# handle.additional.prefixes = prefix1[, prefix2]
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Because of this I noticed that our Handle server&amp;rsquo;s &lt;code&gt;config.dct&lt;/code&gt; was potentially misconfigured!&lt;/li&gt;
&lt;li&gt;We had some default values still present:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;quot;300:0.NA/YOUR_NAMING_AUTHORITY&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;I&amp;rsquo;ve changed them to the following and restarted the handle server:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;quot;300:0.NA/10568&amp;quot;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;In looking at all the configs I just noticed that we are not providing a DOI in the Google-specific metadata crosswalk&lt;/li&gt;
&lt;li&gt;From &lt;code&gt;dspace/config/crosswalks/google-metadata.properties&lt;/code&gt;:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;google.citation_doi = cg.identifier.doi
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;This works, and makes DSpace output the following metadata on the item view page:&lt;/li&gt;
&lt;/ul&gt;
&lt;pre&gt;&lt;code&gt;&amp;lt;meta content=&amp;quot;https://dx.doi.org/10.1186/s13059-017-1153-y&amp;quot; name=&amp;quot;citation_doi&amp;quot;&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;ul&gt;
&lt;li&gt;Submitted and merged pull request for this: &lt;a href=&#34;https://github.com/ilri/DSpace/pull/305&#34;&gt;https://github.com/ilri/DSpace/pull/305&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;</description>
</item>