DataONE Tasks: Issueshttps://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2020-07-15T18:03:40ZDataONE Tasks
Redmine Infrastructure - Bug #8866 (New): Java client tools should set a custom user agent stringhttps://redmine.dataone.org/issues/88662020-07-15T18:03:40ZBryce Mecummecum@nceas.ucsb.edu
<p>Related to <a href="https://redmine.dataone.org/issues/7047">https://redmine.dataone.org/issues/7047</a></p>
<p>It looks like nowhere in <code>d1_libclient_java</code> do we set a user agent string. Aside from being best practice, it limits our ability to customize our infrastructure around it. For example, OPC is running into HTTP 413s due to overrunning their TLS renegotiation buffer and we can't effectively whitelist their requests, which come from our Java client tools, to allow them to upload large files.</p>
CN REST - Bug #8860 (New): /token endpoint doesn't set a content-type and character encodinghttps://redmine.dataone.org/issues/88602020-02-29T01:00:11ZBryce Mecummecum@nceas.ucsb.edu
<p>On Firefox only, requests to the /portal/token endpoint (i.e., the one MetacatUI and other clients use to fetch their auth tokens, like <a href="https://cn.dataone.org/portal/token">https://cn.dataone.org/portal/token</a>) result in errors in the browser console.</p>
<p>When you access the URL via an XHR request, you see:</p>
<blockquote>
<p>XML Parsing Error: syntax error<br>
Location: <a href="https://cn-stage.test.dataone.org/portal/token">https://cn-stage.test.dataone.org/portal/token</a><br>
Line Number 1, Column 1:</p>
</blockquote>
<p>When you access the URL directly in Firefox:</p>
<blockquote>
<p>The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.</p>
</blockquote>
<p>I had a hunch that this error would go away if the response simply had the <code>Content-Type</code> header set to <code>text/plain; charset=utf-8</code> so I spun up <code>mitmproxy</code>, made that edit to the intercepted response, and saw that the error does go away.</p>
<p>I think we should modify the portal code to set the <code>Content-Type</code> header like above so the error goes away.</p>
Infrastructure - Task #8858 (New): Update CN Apache configs in version control with directives to...https://redmine.dataone.org/issues/88582020-02-05T20:02:12ZBryce Mecummecum@nceas.ucsb.edu
<p>Sitemaps are located on disk in ${tomcat_webapps_dir}/${context}/sitemaps as <code>sitemap_index.xml</code> and <code>sitemap%d.xml</code> (for each sub-sitemap).</p>
<p>The rule we've come up with is:</p>
<p><code>RewriteRule ^/(sitemap.+) /metacat/sitemaps/$1 [R=303]</code></p>
Infrastructure - Bug #8822 (New): Account queries in STAGE-2 failing from web browserhttps://redmine.dataone.org/issues/88222019-06-19T01:44:19ZBryce Mecummecum@nceas.ucsb.edu
<p>Steps to reproduce:</p>
<ol>
<li>Visit <a href="https://search-stage-2.test.dataone.org/">https://search-stage-2.test.dataone.org/</a></li>
<li>Log in</li>
<li>Navigate to <a href="https://search-stage-2.test.dataone.org/data">https://search-stage-2.test.dataone.org/data</a></li>
<li>Observe an HTTP 500 in the Network pane of whichever browser you're using to <a href="https://search-stage-2.test.dataone.org/cn/v2/accounts/?query=%7BYOUR_DN%7D">https://search-stage-2.test.dataone.org/cn/v2/accounts/?query={YOUR_DN}</a></li>
</ol>
<p>Response body:</p>
<pre><?xml version="1.0" encoding="UTF-8"?>
<error detailCode="500" errorCode="500" name="ServiceFailure">
<description>Internal Server Error: The server encountered an unexpected condition which prevented it from fulfilling the request.</description>
</error>
</pre>
<p>Some notes:</p>
<ul>
<li>I notice this in multiple browsers</li>
<li>I notice this only when the request is issued from MetacatUI, not when I visit the URL in my browser or hit it with curl</li>
<li>I don't notice this error on search.dataone.org</li>
<li>MetacatUI on search.dataone.org doesn't even issue this request</li>
<li>MetacatUI on stage-2 is at v2.4.2 and on search is at 2.6.1</li>
</ul>
<p>It seems like a bug to me that we see a service failure but I'm not sure if this is a MetacatUI bug or an issue in the CN stack (i.e., Apache config or something) but I wanted to file it for someone to take a look.</p>
Infrastructure - Bug #8821 (New): Object doi:10.18739/A2610VR7Z fails to index on CNhttps://redmine.dataone.org/issues/88212019-06-18T22:43:38ZBryce Mecummecum@nceas.ucsb.edu
<p>I noticed <a href="https://search.dataone.org/cn/v2/meta/doi:10.18739/A2610VR7Z">https://search.dataone.org/cn/v2/meta/doi:10.18739/A2610VR7Z</a> isn't present in the search index and asked about it on DataONEOrg #ci Slack channel. Chris noted that no no task was in the index queue for the PID. He tried to force a reindex which failed. He couldn't find a log entry indicating why it failed so someone needs to look into what's going on. It occurs to me that whatever bug is affecting this Object may have affected more Objects so a second part of fixing this bug should probably be doing some housekeeping or an audit of some kind to make sure the search index isn't missing more content.</p>
Infrastructure - Task #8817 (New): Configure sitemaps on the CNhttps://redmine.dataone.org/issues/88172019-06-06T23:52:23ZBryce Mecummecum@nceas.ucsb.edu
<p>Support for sitemaps landed last fall in Metacat: <a href="https://github.com/NCEAS/metacat/pull/1283">https://github.com/NCEAS/metacat/pull/1283</a>. Sitemaps are good for users but especially for search engines and DataONE's Search Catalog could benefit from having sitemaps enabled. A sitemap could help crawlers discover all of the datasets in DataONE. The CNs already run Metacat and should use Metacat's sitemaps ability to generate sitemaps for all content.</p>
<p>To enable sitemaps on the CNs, a few things seem to be needed. I'm not very familiar with how the CNs get built so I may be wrong or be missing things:</p>
<ul>
<li>Sitemaps rely on two properties in Metacat's <code>metacat.properties</code> file, which should have values: <code>sitemap.location.base=https://search.dataone.org/</code> and <code>sitemap.entry.base=https://search.dataone.org/view</code></li>
<li>The Apache config the CNs are built with need to serve the <code>sitemap_index.xml</code> and individual sitemaps from the Tomcat webapps dir. Metacat generates sitemaps in the <code>sitemaps</code> subfolder (e.g., <code>/usr/lib/tomcat8/webapps/metacat/sitemaps</code>). A <code>Directory</code> directive should work so long as filesystem permissions are set up for Apache to see the files.</li>
<li>We need a robots.txt that points at the sitemap index file at search.dataone.org which provides the entrypoint to <code>sitemap_index.xml</code></li>
<li>Metacat generates sitemaps with a recurring job mechanism that's internal to Metacat. AFAIK this job isn't turned on when Tomcat loads Metacat and a request has to get sent to the admin API which turns this job on as a side-effect. We might want to change this to reduce maintenance burden or chance of having stale sitemaps</li>
</ul>
<p>Dave nominated Jing for this work and has targeted this for the next CCI release. I'm not sure which that is so please select whichever one is appropriate.</p>
<p>Note this relates to <a href="https://redmine.dataone.org/issues/8693">https://redmine.dataone.org/issues/8693</a> which we've delayed because Google's crawler infrastructure has changed and DataONE is now visible by Google. Google staff have indicated we only need to send them a robots.txt that points to our sitemaps for them to begin crawling.</p>
Infrastructure - Bug #8815 (New): Investigate and fix failed sync/harvest of doi:10.18739/A2CH48https://redmine.dataone.org/issues/88152019-06-04T23:26:43ZBryce Mecummecum@nceas.ucsb.edu
<p>I noticed this while doing something unrelated. There isn't a copy of the sysmeta for <a href="https://arcticdata.io/metacat/d1/mn/v2/meta/doi:10.18739/A2CH48">https://arcticdata.io/metacat/d1/mn/v2/meta/doi:10.18739/A2CH48</a> on the CN:</p>
<p>At: <a href="http://cn.dataone.org/cn/v2/meta/doi:10.18739/A2CH48">http://cn.dataone.org/cn/v2/meta/doi:10.18739/A2CH48</a></p>
<pre><code class="xml syntaxhl"><span class="CodeRay"><span class="preprocessor"><?xml version="1.0" encoding="UTF-8"?></span><span class="tag"><error</span> <span class="attribute-name">detailCode</span>=<span class="string"><span class="delimiter">"</span><span class="content">1420</span><span class="delimiter">"</span></span> <span class="attribute-name">errorCode</span>=<span class="string"><span class="delimiter">"</span><span class="content">404</span><span class="delimiter">"</span></span> <span class="attribute-name">name</span>=<span class="string"><span class="delimiter">"</span><span class="content">NotFound</span><span class="delimiter">"</span></span><span class="tag">></span>
<span class="tag"><description></span>No system metadata could be found for given PID: doi:10.18739/A2CH48<span class="tag"></description></span>
<span class="tag"></error></span>
</span></code></pre>
<p>CNs are in readonly mode at the moment so I'm filing this here so someone can a look later on.</p>
Infrastructure - Decision #8774 (New): Add new CN format for MPEG-2 or update video/mpeg format t...https://redmine.dataone.org/issues/87742019-03-08T02:04:18ZBryce Mecummecum@nceas.ucsb.edu
<p>We already have this format:</p>
<pre><objectFormat>
<formatId>video/mpeg</formatId>
<formatName>MPEG-1 Video</formatName>
<formatType>DATA</formatType>
<mediaType name="video/mpeg"/>
<extension>mpg</extension>
</objectFormat>
</pre>
<p>It clearly says MPEG-1 Video but there is also an MPEG-2 format. It'd be useful to have a proper format ID to use for MPEG-2 video. The info for MPEG-2 is largely the same as for MPEG-1 (format type, mediaType, extension). Should we add a new format or just update the description of the existing one? We also have an MP4 format type so maybe that'd be a reason to just add another to cover MPEG-2.</p>
Infrastructure - Task #8755 (New): Expand EML indexing support for EML 2.2https://redmine.dataone.org/issues/87552018-12-19T00:55:12ZBryce Mecummecum@nceas.ucsb.eduInfrastructure - Task #8754 (New): Add EML 2.2 to CN formats listhttps://redmine.dataone.org/issues/87542018-12-19T00:54:05ZBryce Mecummecum@nceas.ucsb.eduInfrastructure - Task #8753 (New): Add support for EML 2.2 (indexing, view)https://redmine.dataone.org/issues/87532018-12-19T00:43:52ZBryce Mecummecum@nceas.ucsb.edu
<p>EML 2.2 is nearly released and, with it, comes changes to indexing and the view service. The key points are that EML now supports Markdown and semantic annotations but some more stuff was added too. See the in-progress What's New in EML 2.2.0 page <a href="https://github.com/NCEAS/eml/blob/BRANCH_EML_2_2/docs/eml-220info.md">https://github.com/NCEAS/eml/blob/BRANCH_EML_2_2/docs/eml-220info.md</a> for details.</p>
<p>I'll track these with sub-tasks but here's an overview:</p>
<p><strong>Formats</strong></p>
<p>We need to expand the list of formats to include EML 2.2.</p>
<p><strong>Indexing</strong></p>
<p>EML 2.2 requires adding new fields and changes to some existing fields. For example, abstracts in EML can now also include a <code>markdown</code> child element which we'll also want to store in Solr. We also want to add in support for semantic annotations and probably structured funding information since that's been requested so much.</p>
<p>Support for semantic annotations will likely use the same approach as our previous work on semantic search where incoming annotations were subject to materialization during the indexing process. To explain what that means, the idea is that, when an annotation for term X comes in, the index processor loads the relevant ontology, materializes the superclass hierarchy for the term, and stores the entire hierarchy in Solr. For EML records with multiple annotations, only the unique set needs to be stored.</p>
<p><strong>View service</strong></p>
<p>As mentioned above, EML 2.2 changes how some existing elements (e.g., abstract) work and adds some new ones (e.g., annotations. The existing EML 2 stylesheets will work for EML 2.2 because 2.2 is backwards compatible but we'll want to extend them to support what's new and changed in EML 2.2</p>
<p>Of note: EML now supports storing Markdown where previously only EML TextType (basically DocBook) was allowed. Our plan on Metacat/MetacatUI to support this is to render the Markdown on the client side which does involve some security concerns (see <a href="https://github.com/NCEAS/metacatui/issues/860">https://github.com/NCEAS/metacatui/issues/860</a> for tracking).</p>
Infrastructure - Decision #8601 (New): Decide on a URI space for DataONE resourceshttps://redmine.dataone.org/issues/86012018-06-05T00:39:42ZBryce Mecummecum@nceas.ucsb.edu
<a name="Summary"></a>
<h2 >Summary<a href="#Summary" class="wiki-anchor">¶</a></h2>
<p>In the past, we've needed to represent DataONE resources (e.g., Objects, "datasets", etc.) in Linked Open Data contexts. Currently, these resources don't have have canonical URIs.</p>
<p>For example, take a dataset on search.dataone.org with the following URL:</p>
<pre>https://search.dataone.org/#view/doi:10.18739/A28K74W2F
</pre>
<p>Candiate URIs for this resource include:</p>
<ol>
<li><a href="https://search.dataone.org/#view/doi:10.18739/A28K74W2F:">https://search.dataone.org/#view/doi:10.18739/A28K74W2F:</a> Depends on implementation details in MetacatUI's router, uses fragment URLs in the URL which we're deprecating soon anyhow</li>
<li><a href="https://cn.dataone.org/cn/v2/resolve/doi:10.18739/A28K74W2F:">https://cn.dataone.org/cn/v2/resolve/doi:10.18739/A28K74W2F:</a> Depends on implementation details of the DataONE API and is tied to a specific version of the DataONE API. e.g., When API version 3 is release, will ../v2/resolve/doi:10.18739/A28K74W2F and ../v3/resolve/doi:10.18739/A28K74W2F refer to the same resource?</li>
</ol>
<a name="Proposal"></a>
<h2 >Proposal<a href="#Proposal" class="wiki-anchor">¶</a></h2>
<p>Create a URI space that all services can integrate against. This space follows the convention of:</p>
<p><a href="https://dataone.org/%7Bresource_type%7D/%7Bresource_identifier%7D">https://dataone.org/{resource_type}/{resource_identifier}</a></p>
<p>where <code>{resource_type}</code> is a singular name of a top level DataONE resource such as "dataset", "person", or "object" and <code>{resource_identifier}</code> is a type-appropriate identifier (e.g., PID of a science metadata Object for the dataset type, DN for the person type, etc.). The collection of top level resources (e.g., datasets), follows the form <a href="https://dataone.org/%7Bresource_type_plural%7D">https://dataone.org/{resource_type_plural}</a> (e.g., "datasets").</p>
<p>Examples:</p>
<ul>
<li>Dataset: <a href="https://dataone.org/dataset/doi%3A10.18739%2FA28K74W2F">https://dataone.org/dataset/doi%3A10.18739%2FA28K74W2F</a></li>
<li>Person: <a href="https://dataone.org/person/https%3A%2F%2Forcid.org%2F0000-0002-0381-3766">https://dataone.org/person/https%3A%2F%2Forcid.org%2F0000-0002-0381-3766</a></li>
<li>Object: <a href="https://dataone.org/object/urn%3Auuid%3A3c80e9d6-277c-4a32-bc7a-d85c499f370f">https://dataone.org/object/urn%3Auuid%3A3c80e9d6-277c-4a32-bc7a-d85c499f370f</a></li>
<li>All datasets on DataONE: <a href="https://dataone.org/datasets">https://dataone.org/datasets</a></li>
</ul>
<a name="Expected-outcomes"></a>
<h2 >Expected outcomes<a href="#Expected-outcomes" class="wiki-anchor">¶</a></h2>
<ul>
<li>A normative document describing the URI space will be added to the DataONE documentation (<a href="https://releases.dataone.org/online/api-documentation-v2.0/">https://releases.dataone.org/online/api-documentation-v2.0/</a>)</li>
<li>Other project will make use of these URIs</li>
</ul>
<a name="Affected-projects"></a>
<h2 >Affected projects<a href="#Affected-projects" class="wiki-anchor">¶</a></h2>
<ul>
<li>Metacat (sitemap functionality will make use of these URIs)</li>
<li>MetacatUI (Google Structured Data integration via JSON-LD will use these URIs for resources)</li>
<li>GeoLink (DataONE LOD graph will use these URIs for resources)</li>
</ul>
<a name="Future-work"></a>
<h2 >Future work<a href="#Future-work" class="wiki-anchor">¶</a></h2>
<p>With the URI space decided, we can start working on a unified, content-negotating DataONE resolve service (different from the CN/MNStorage.resolve API method). See <a href="https://hpad.dataone.org/GYJgjAJgpgHMwFoBGBWALItBjGMEE4kBDAZgKzSWBSS2ADYoSg==#detail-object-content-negotiation-for-objects">https://hpad.dataone.org/GYJgjAJgpgHMwFoBGBWALItBjGMEE4kBDAZgKzSWBSS2ADYoSg==#detail-object-content-negotiation-for-objects</a>. How this works is not being decided in this Redmine ticket.</p>
<a name="Previous-work-discussions-chronological-order"></a>
<h2 >Previous work / discussions (chronological order):<a href="#Previous-work-discussions-chronological-order" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://docs.google.com/document/d/1yU-d-aFdtiSB91Wk0sFj1xthW8skBPof9qKwx00bjxE/edit?usp=sharing">https://docs.google.com/document/d/1yU-d-aFdtiSB91Wk0sFj1xthW8skBPof9qKwx00bjxE/edit?usp=sharing</a></li>
<li><a href="https://hpad.dataone.org/GYJgjAJgpgHMwFoBGBWALItBjGMEE4kBDAZgKzSWBSS2ADYoSg==">https://hpad.dataone.org/GYJgjAJgpgHMwFoBGBWALItBjGMEE4kBDAZgKzSWBSS2ADYoSg==</a></li>
</ul>
Infrastructure - Bug #8043 (New): The origin field for EML documents isn't properly extracted whe...https://redmine.dataone.org/issues/80432017-03-10T21:36:25ZBryce Mecummecum@nceas.ucsb.edu
<p>We just ran into this with the following EML record: <a href="https://knb.ecoinformatics.org/#view/doi:10.5063/F15B00CC">https://knb.ecoinformatics.org/#view/doi:10.5063/F15B00CC</a></p>
<p>The EML has six creators (Kiesecker, Fargione, Baruch-Mordo, Trainor, Ryan, Patterson) but the origin field in the Solr index has two (Ryan, Patterson). After some digging, we realized this was likely because the indexing component responsible for EML doesn't respect EML references. The XML for the relevant section is:</p>
<p><code><br>
<creator scope="document"><br>
<references>1484778487589</references><br>
</creator><br>
<creator scope="document"><br>
<references>1484778426939</references><br>
</creator><br>
<creator scope="document"><br>
<references>1484778028081</references><br>
</creator><br>
<creator scope="document"><br>
<references>1484778171131</references><br>
</creator><br>
<creator id="1485385283277" scope="document"><br>
<individualName><br>
<salutation>Dr.</salutation><br>
<givenName>Joe</givenName><br>
<surName>Ryan</surName><br>
</individualName><br>
<organizationName>University of Colorado Boulder</organizationName><br>
<positionName>Professor</positionName><br>
<electronicMailAddress>joseph.ryan@colorado.edu</electronicMailAddress><br>
</creator><br>
<creator id="1484777776976" scope="document"><br>
<individualName><br>
<salutation>Dr.</salutation><br>
<givenName>Lauren</givenName><br>
<surName>Patterson</surName><br>
</individualName><br>
<organizationName>Duke University</organizationName><br>
<positionName>Water Policy Associate</positionName><br>
<address scope="document"><br>
<deliveryPoint>Nicholas Institute for Environmental Policy Solutions, Duke University</deliveryPoint><br>
<city>Durham</city><br>
<administrativeArea>NC</administrativeArea><br>
<postalCode>27708</postalCode><br>
<country>USA</country><br>
</address><br>
<electronicMailAddress>lauren.patterson@duke.edu</electronicMailAddress><br>
</creator><br>
</code></p>
<p>It would be really nice if the origin field got populated with all those referenced creators.</p>
DataONE API - Bug #7684 (New): Call to MNStorage.update() via REST API returns java.lang.StackOve...https://redmine.dataone.org/issues/76842016-03-21T23:07:39ZBryce Mecummecum@nceas.ucsb.edu
<p>I was trying to update an object via the REST API via cURL and forgot to enter the correct URL. The cURL command I used and response is:</p>
<p>$ curl -X PUT -H "Authorization: Bearer $TOKEN" -F "pid=resourceMap_doi:10.5065/D6G44NFV" -F "object=@object.xml" -F "sysmeta=@sysmeta.xml" -F "newPid=resourceMap_doi:10.5065/D6G44NFV_v3" $URL<br>
<?xml version="1.0" encoding="UTF-8"?><br>
java.lang.StackOverflowError<br>
</p>
<p>Where $URL was '<a href="https://arcticdata.io/metacat/d1/mn/v2/object">https://arcticdata.io/metacat/d1/mn/v2/object</a>' instead of '<a href="https://arcticdata.io/metacat/d1/mn/v2/object/resourceMap_doi:10.5065/D6G44NFV">https://arcticdata.io/metacat/d1/mn/v2/object/resourceMap_doi:10.5065/D6G44NFV</a>'</p>
<p>I expected to receive some sort of warning/error that I had forgotten to specify the URL properly for this call but instead saw a StackOverflowError.</p>
DataONE API - Bug #7578 (New): Fix 404 link to d1_instance_generator folder in documentationhttps://redmine.dataone.org/issues/75782016-01-08T22:01:20ZBryce Mecummecum@nceas.ucsb.edu
<p>In the MN API documentation for MNStorage.create (<a href="https://jenkins-ucsb-1.dataone.org/job/API%20Documentation%20-%20trunk/ws/api-documentation/build/html//apis/MN_APIs.html#MNStorage.create">https://jenkins-ucsb-1.dataone.org/job/API%20Documentation%20-%20trunk/ws/api-documentation/build/html//apis/MN_APIs.html#MNStorage.create</a>), I found a the following paragraph contains a broken link to d1_instance_generator:</p>
<blockquote>
<p>"The system metadata included with the create call must contain values for the elements required to be set by clients (see System Metadata). The system metadata document can be crafted by hand or preferably with a tool such as generate_sysmeta.py which is available in the d1_instance_generator Python package. See documentation included with that package for more information on its operation."</p>
</blockquote>
<p>The link to d1_instance_generator was to the SVN folder <a href="https://repository.dataone.org/software/cicore/trunk/d1_instance_generator">https://repository.dataone.org/software/cicore/trunk/d1_instance_generator</a> which is currently a 404. I think the folder moved to /d1_test_utilities_python/src/d1_test/instance_generator.</p>