Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362017-10-11T18:42:38ZEcoinformatics Redmine
Redmine Bug #7217 (New): Report on metadata creation date in metadata quality summarieshttps://projects.ecoinformatics.org/ecoinfo/issues/72172017-10-11T18:42:38ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>Indexing fields for metadata quality reports do not include the upload date of the metadata they are reporting on. Therefor, summaries that are created, i.e. mean score for a user over time, currently show the time of the creation of the quality report, not the metadata.</p>
<p>Add the field 'mdq.metadata.timestamp' to application-context-mdq.xml to hold the metadata creation or update time.</p>
<p>Each quality suite will be responsible for making this information available in the quality report, so that MDQClient.saveRun<br />can record it.</p> Bug #7216 (New): MDQClient.saveRun doesn't obsolete existing quality documentshttps://projects.ecoinformatics.org/ecoinfo/issues/72162017-10-11T17:30:14ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>MDQClient.saveRun is called to upload a newly created quality document, in response to a metadata quality document being uploaded or updated.</p>
<p>When MDQClient.saveRun is called by MNodeService.update, it does not check if a quality document has already been created<br />for the metadata document. saveRun should check if a previous quality document has been created for the metadata, and obsolete it<br />with the new quality document. This will ensure that quality statistics are accurate, as obsoleted quality reports will not be<br />included in statistical calculations, as they are essentially duplicates.</p> Bug #7212 (New): metacat-index missing metadata quality fieldshttps://projects.ecoinformatics.org/ecoinfo/issues/72122017-10-03T18:59:38ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>The Spring context file ./metacat-index/src/main/resources/application-context-mdq.xml doesn't contain a bean definition for the quality check types 'congruency' or 'dataFormats',<br />although these are check types that we should record results for. There is a bean for check type 'other', but this isn't sufficient.</p> Feature #7198 (New): Format solr engine description outputhttps://projects.ecoinformatics.org/ecoinfo/issues/71982017-06-02T17:30:11ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>The solr engine description information from DataONE has XSLT formatted output that includes a description of each field: <a class="external" href="https://cn.dataone.org/cn/v2/query/solr">https://cn.dataone.org/cn/v2/query/solr</a>. The corresponding metacat index output does not: <a class="external" href="https://knb.ecoinformatics.org/knb/d1/mn/v2/query/solr">https://knb.ecoinformatics.org/knb/d1/mn/v2/query/solr</a>. It would be very useful to provide users with this info to help them use/learn solr and our index.<br />I wasn't able to find the .xsl file in metacat repo or the DataONE repo, so am not sure how to include this into metacat-index</p> Bug #7181 (New): Verify completeness of unit test MetacatRdfXmlSubprocessorTesthttps://projects.ecoinformatics.org/ecoinfo/issues/71812017-04-11T23:41:43ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>Verify that all prov relationships that are indexed via src/main/resources/application-context-prov-base.xml are inspected by the unit test MetacatRdfXmlSubprocessorTest.java which reads src/test/resources/rdfxml-example.xml.</p> Bug #7176 (Closed): Metacat-index RDF/XML subprocessor not populating prov_hasDerivations fieldhttps://projects.ecoinformatics.org/ecoinfo/issues/71762017-03-23T22:09:14ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>The package <a class="external" href="https://dev.nceas.ucsb.edu/#view/urn:uuid:c7cda366-5658-4350-ba5a-8d2b84829f5d">https://dev.nceas.ucsb.edu/#view/urn:uuid:c7cda366-5658-4350-ba5a-8d2b84829f5d</a> has one prov relationship 'urn:uuid:94cb9677-be83-4873-aa7c-6691e32229a3 <a class="external" href="http://www.w3.org/ns/prov#wasDerivedFrom">http://www.w3.org/ns/prov#wasDerivedFrom</a> urn:uuid:146239cd-2f41-4312-8f90-75c8cad09a48'</p>
<p>From this prov relationship, the Solr index 'prov_hasDerivations' field for urn:uuid:146239cd-2f41-4312-8f90-75c8cad09a48 should be set to urn:uuid:94cb9677-be83-4873-aa7c-6691e32229a3.<br />See <a class="external" href="https://dev.nceas.ucsb.edu/knb/d1/mn/v1/query/solr/?q=id:%22urn:uuid:146239cd-2f41-4312-8f90-75c8cad09a48%22">https://dev.nceas.ucsb.edu/knb/d1/mn/v1/query/solr/?q=id:%22urn:uuid:146239cd-2f41-4312-8f90-75c8cad09a48%22</a></p>
<p>However, the prov_wasDerived from field (the reciprocal relationship) is set for the derivation: <a class="external" href="https://dev.nceas.ucsb.edu/knb/d1/mn/v1/query/solr/?q=id:%22urn:uuid:94cb9677-be83-4873-aa7c-6691e32229a3%22">https://dev.nceas.ucsb.edu/knb/d1/mn/v1/query/solr/?q=id:%22urn:uuid:94cb9677-be83-4873-aa7c-6691e32229a3%22</a></p>
<p>The problem may be related to the 'prov_hasDerivations' SPARQL query in metacat-index/src/main/resources/application-context-prov-base.xml:<br /> <bean id="prov20150115.hasDerivations" class="org.dataone.cn.indexer.annotation.SparqlField"><br />...<br /> SELECT (str(?pidValue) as ?pid) (str(?derivedDataPidValue) as ?prov_hasDerivations)<br /> FROM <$GRAPH_NAME><br /> WHERE {<br /> ?derived_data prov:wasDerivedFrom ?source_data .<br /> ?source_data cito:documentedBy ?source_metadata .<br /> ?source_metadata dcterms:identifier ?pidValue .<br /> ?derived_data dcterms:identifier ?derivedDataPidValue .<br /> }</p>
<p>Not sure why the 'source_metadata' is included in this query. Also, this query is not the<br />reciprocal of the 'prov_wasDerivedFrom' query:</p>
<pre><code>&lt;bean id="prov20150115.wasDerivedFrom" class="org.dataone.cn.indexer.annotation.SparqlField"&gt;<br />...<br /> SELECT (str(?pidValue) as ?pid) (str(?wasDerivedFromValue) as ?prov_wasDerivedFrom)<br /> FROM <$GRAPH_NAME><br /> WHERE { <br /> ?derived_data prov:wasDerivedFrom ?primary_data .<br /> ?derived_data dcterms:identifier ?pidValue . <br /> ?primary_data dcterms:identifier ?wasDerivedFromValue .<br /> }</code></pre>
<p>Note that this will also be a problem for the CN DataONE d1_cn_index_processor component.</p>
<p>The resource map for this package has been included.</p> Bug #7161 (Resolved): Uploading a resource map with provenance data causes an NPE during indexinghttps://projects.ecoinformatics.org/ecoinfo/issues/71612016-11-22T23:21:58ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>When uploading a resource map with provenance relationships included, indexing exits with an NPE during processing of RdfXmlSubprocessor:</p>
<p>Java.lang.NullPointerException<br /> at org.dataone.cn.indexer.annotation.RdfXmlSubprocessor.getSolrDocs(RdfXmlSubprocessor.java:278)<br /> at org.dataone.cn.indexer.annotation.RdfXmlSubprocessor.process(RdfXmlSubprocessor.java:265)<br /> at org.dataone.cn.indexer.annotation.RdfXmlSubprocessor.processDocument(RdfXmlSubprocessor.java:119)<br />...</p>
<p>The problem appears to be caused by RdfXmlSubprocessor.getSolrDocs() calling httpService, which causes the NPE because an http solr server<br />is not run on metacat member node instances, which rely on the embedded solr server instead.</p>
<p>The included files are the resource map that was uploaded that caused the NPE, and a portion of the tomcat log file that includes<br />indexer TRACE info and the NPE.</p> Bug #7156 (Resolved): Solr index still keep the obsoletedBy field even though it was removed from...https://projects.ecoinformatics.org/ecoinfo/issues/71562016-11-10T23:14:30ZJing Taotao@nceas.ucsb.edu
<p>Chris reported the issue:<br />we’re trying to reindex a pid in Metacat, and can’t seem to get it to drop the `obsoletedBy` attr. I changed the system metadata in hazelcast to remove that field (and confirmed it in postgres). After logging in and issuing `action=reindex&pid=urn:uuid:f22d78a2-719a-4704-856b-cc02fa803290`, I see the reindex happen in catalina.out. But then when checking it, `obsoletedBy` is still there. Do we have a way to remove the entry from Solr and start from scratch?</p>
<p>or is there a setting in the indexer that’s just merging, and not deleting attrs?</p>
<p>this is on arcticdata.io</p> Bug #7150 (New): Do not populate the "documents" Solr index field with a metadata object's own id...https://projects.ecoinformatics.org/ecoinfo/issues/71502016-11-03T21:35:14ZLauren Walkerwalker@nceas.ucsb.edu
<p>If a resource map has a cito:documents relationship that states that a metadata doc cito:documents itself, that should be ignored in the Solr discovery index. We have metadata documents in the Arctic Data Center that now are indexed as documenting themselves, which causes issues with the "Only results with data" filter in Metacat UI.</p>
<p>Here is an example of a metadata doc that documents itself: <a class="external" href="https://arcticdata.io/metacat/d1/mn/v2/query/solr/?q=id:%22urn:uuid:dfb9b407-086d-4270-b872-b43504d5e94a%22&fl=id,documents">https://arcticdata.io/metacat/d1/mn/v2/query/solr/?q=id:%22urn:uuid:dfb9b407-086d-4270-b872-b43504d5e94a%22&fl=id,documents</a></p> Bug #7149 (Resolved): Private metadata is indexed as isPublic=truehttps://projects.ecoinformatics.org/ecoinfo/issues/71492016-10-28T19:22:20ZBryce Mecummecum@nceas.ucsb.edu
<p>Jesse just pointed out this strange behavior to me. With Chrome, I get a "Failed -- Needs authorization" error in my download toolbar when I click the Download button on this metadata doc. I expected to be able to download the file this way and not to receive an error.</p>
<p>To reproduce:</p>
<p>- Log in to <a class="external" href="https://arcticdata.io/catalog">https://arcticdata.io/catalog</a><br />- Browse to <a class="external" href="https://arcticdata.io/catalog/#view/arctic-data.1580.1">https://arcticdata.io/catalog/#view/arctic-data.1580.1</a><br />- Click the "Download" button in the row for "Metadata: Passive acoustic data from A2 in the Bering Strait" <br />- Observe the download fails and that, at least in Chrome, you see a "Failed - Needs authorization" error</p>
<p>To check that this was a problem with MetacatUI instead of something else, I used my token and the R client to get sysmeta on the object (successful) and bytes (successful). So something's up.</p> Bug #7093 (New): Metacat-index is not indexing all package members correctlyhttps://projects.ecoinformatics.org/ecoinfo/issues/70932016-08-26T17:04:55ZChris Jonescjones@nceas.ucsb.edu
<p>Shirley pointed out that for the <code>urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6</code> package on arcticdata.io:</p>
<p><a class="external" href="https://arcticdata.io/catalog/#view/urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6">https://arcticdata.io/catalog/#view/urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6</a></p>
<p>Notice that the resource map aggregates the following 29 objects:</p>
<pre>
$ curl -s -o - \
"https://arcticdata.io/metacat/d1/mn/v2/object/resource_map_urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6" | \
xmlstarlet sel -t -v "//ore:aggregates/@rdf:resource" -n | \
cut -d "/" -f7
urn%3Auuid%3A1841cbef-f024-4099-ba2b-ccf89e65d295
urn%3Auuid%3A8fe1169b-5c39-4793-bdc3-a3ced4e321ad
urn%3Auuid%3A355e25c7-9637-42e6-85ea-6d642c02a454
urn%3Auuid%3Ac9d4d530-aafb-4d3b-bef9-9eb9bf4dfba3
urn%3Auuid%3A6ce5b2bd-fcf9-4a4f-bbf4-63337ea0ad16
arctic-data.9492.1
arctic-data.9468.1
urn%3Auuid%3Af6c12e96-95c0-423f-83a0-36c3c0c6abf4
urn%3Auuid%3Ada0f723b-bb38-4437-bee5-56b0b4efcb5d
urn%3Auuid%3A58ba459e-c508-4b74-9f2e-db569cf9d737
urn%3Auuid%3A09a0749e-82dd-48d8-8be2-23a7993db65b
urn%3Auuid%3A7cda7813-1d23-4e57-b0cb-59980bd2dbde
urn%3Auuid%3A9b2d3c3c-d775-4e20-b9e6-896f2e102f0f
urn%3Auuid%3Ab9218df4-5a34-4ddc-8d35-6f7824049b89
urn%3Auuid%3Ac385222e-caf8-4ae4-b3bf-463f2fba3968
urn%3Auuid%3A9a9077ee-011c-44de-8b77-b16280998250
urn%3Auuid%3Ad933a025-8dc0-4933-91af-5b49e1e48079
urn%3Auuid%3Ae2ba7348-1c64-405b-9840-68dc8d776e5c
urn%3Auuid%3Add5925d8-a9a1-48df-9623-3b75b48d0460
urn%3Auuid%3Abb885aa0-6e31-4de4-adaa-b842eaf3a9fa
urn%3Auuid%3Ac1d2ab68-e653-488a-9942-fd1045a7aad6
arctic-data.9469.1
urn%3Auuid%3Ab70e055d-593d-4b3a-8aaf-04574e377e46
urn%3Auuid%3Aa0e2e791-0a07-4213-b53e-ed5f9a16178e
urn%3Auuid%3Aa0769215-4c17-4935-87ed-442d761a4269
urn%3Auuid%3A17c1009b-5e1f-4d2d-b040-b21a6366adda
urn%3Auuid%3A760cc12e-e263-48cd-b337-eeb2f6336702
urn%3Auuid%3A96dc7150-0e19-4647-ae77-d5dda1abedda
urn%3Auuid%3A09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6
</pre>
<p>However, looking at the index, only 26 are listed with a <code>resourceMap</code> field of <code>resource_map_urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6</code>:</p>
<pre>
$ curl -s -o - 'https://arcticdata.io/metacat/d1/mn/v2/query/solr/q=resourceMap:"resource_map_urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6"&fl=id&rows=50&wt=csv'
id
urn:uuid:09fd1d96-c6b0-442d-b1cb-e2c4a2e476b6
urn:uuid:96dc7150-0e19-4647-ae77-d5dda1abedda
urn:uuid:6ce5b2bd-fcf9-4a4f-bbf4-63337ea0ad16
urn:uuid:8fe1169b-5c39-4793-bdc3-a3ced4e321ad
urn:uuid:f6c12e96-95c0-423f-83a0-36c3c0c6abf4
urn:uuid:58ba459e-c508-4b74-9f2e-db569cf9d737
urn:uuid:c9d4d530-aafb-4d3b-bef9-9eb9bf4dfba3
urn:uuid:da0f723b-bb38-4437-bee5-56b0b4efcb5d
urn:uuid:355e25c7-9637-42e6-85ea-6d642c02a454
arctic-data.9492.1
arctic-data.9468.1
urn:uuid:17c1009b-5e1f-4d2d-b040-b21a6366adda
urn:uuid:c1d2ab68-e653-488a-9942-fd1045a7aad6
urn:uuid:bb885aa0-6e31-4de4-adaa-b842eaf3a9fa
urn:uuid:b70e055d-593d-4b3a-8aaf-04574e377e46
urn:uuid:a0769215-4c17-4935-87ed-442d761a4269
arctic-data.9469.1
urn:uuid:09a0749e-82dd-48d8-8be2-23a7993db65b
urn:uuid:d933a025-8dc0-4933-91af-5b49e1e48079
urn:uuid:9b2d3c3c-d775-4e20-b9e6-896f2e102f0f
urn:uuid:e2ba7348-1c64-405b-9840-68dc8d776e5c
urn:uuid:b9218df4-5a34-4ddc-8d35-6f7824049b89
urn:uuid:7cda7813-1d23-4e57-b0cb-59980bd2dbde
urn:uuid:9a9077ee-011c-44de-8b77-b16280998250
urn:uuid:c385222e-caf8-4ae4-b3bf-463f2fba3968
urn:uuid:1841cbef-f024-4099-ba2b-ccf89e65d295
</pre>
<p>The following three data objects are missing:</p>
<pre>
urn:uuid:760cc12e-e263-48cd-b337-eeb2f6336702 2016-co2.csv
urn:uuid:dd5925d8-a9a1-48df-9623-3b75b48d0460 2016-gps.csv
urn:uuid:a0e2e791-0a07-4213-b53e-ed5f9a16178e 2016-met.csv
</pre>
<p>I've tried reindexing all of the pids associated with the package, and the package itself, with no luck. I've turned on DEBUG level logging in <code>/var/lib/tomcat7/webapps/metacat/WEB-INF/lib/classes/log4j.properties</code> to get more logging information from metacat-index into catalina.out. I restarted Tomcat to enable the logging changes.</p>
<p>We need to check to see why these members aren't being indexed correctly. It's also affecting many other packages according to the graduate interns on the data team.</p> Bug #7083 (Closed): Metadata/data objects which have obsoletedBy field ignore the resource map in...https://projects.ecoinformatics.org/ecoinfo/issues/70832016-08-08T21:17:39ZJing Taotao@nceas.ucsb.edu
<p>Hi Bryce:</p>
<p>I looked at the index of the 16 objects and found 5 of them don't have the value of resource_map_urn:uuid:2e3c8c4c-e606-4710-b321-8edc4d506b0a at the resourceMap element:</p>
<p>urn%3Auuid%3A0f64673d-d270-411f-a5ed-98351d3d9450<br />urn%3Auuid%3A12c0ab6a-5eb3-43de-a16c-e71acaeb9817<br />urn%3Auuid%3A45ee065f-746e-4780-872b-d98cabeb0ad7<br />urn%3Auuid%3Aae90efa8-3cf5-4ff9-9637-c7be28b06541<br />urn%3Auuid%3Accebed0b-6bdb-4853-ba2a-6e88321ea4d5</p>
<p>So this is the reason you only get 11 documents when you query this resource map value.</p>
<p>And all of the five objects have the field "obsoletedBy" and the other 11 object don't have the field.</p>
<p>The reason why I looked at the field "obsoletedBy" is I recently found that there was a bug in the d1_cn_index_processor component - when you index a resource map, the component in the resource map will ignore the resource map if it has the "obsoletedBy" field. So this issue sounds like the reflection of this bug.</p>
<p>I will look at the metacat index code to make sure.</p>
<p>Thanks,</p>
<p>Jing</p>
<p>On 8/8/16 12:13 PM, Bryce Mecum wrote:</p>
<blockquote>
<p>So @scng got a hold of me to ask about strange behavior where there package table on two dataset pages are not showing the right number of files. This is a write up of what she told me and what I found so that someone else, <a class="user active" href="https://projects.ecoinformatics.org/ecoinfo/users/293">Jessica Couture</a> or <a class="user active" href="https://projects.ecoinformatics.org/ecoinfo/users/8">Chris Jones</a> can see about addressing it. This is a blocker on Bill Simpson's ticket RT12930.</p>
<p>This applies to two packages:</p>
<p>O-Buoy 8 (needs link)<br />O-Buoy 15</p>
<p>These two packages were recently updated to make them editable (adding otherEntity elements to the EML) by @scng using the R package.</p>
<p>If you look at O-Buoy 15, you'll see ten data objects in the package. However, the R @scng wrote intended to add 15 data objects to the package. If you look at the resource map, resource_map_urn:uuid:2e3c8c4c-e606-4710-b321-8edc4d506b0a, you'll see it aggregates+documents 16 PIDs (metadata + 15 data):</p>
<p>Here's an invalid and abridged section from the resource map, converted to Turtle format before pasting here:<br />...<br />ore:aggregates <<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A0f64673d-d270-411f-a5ed-98351d3d9450">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A0f64673d-d270-411f-a5ed-98351d3d9450</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A12c0ab6a-5eb3-43de-a16c-e71acaeb9817">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A12c0ab6a-5eb3-43de-a16c-e71acaeb9817</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A1584c53e-3d5c-4b70-9bf6-1033de8e2fd1">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A1584c53e-3d5c-4b70-9bf6-1033de8e2fd1</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A1c2d1c50-4d79-4fe5-b650-024e63818336">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A1c2d1c50-4d79-4fe5-b650-024e63818336</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A2e3c8c4c-e606-4710-b321-8edc4d506b0a">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A2e3c8c4c-e606-4710-b321-8edc4d506b0a</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A30a3a76c-c965-4594-8cfd-c652d46ebbe5">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A30a3a76c-c965-4594-8cfd-c652d46ebbe5</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A40d6e8e4-83eb-4579-8b00-90bf28282769">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A40d6e8e4-83eb-4579-8b00-90bf28282769</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A45ee065f-746e-4780-872b-d98cabeb0ad7">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A45ee065f-746e-4780-872b-d98cabeb0ad7</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A4eb92d77-19f4-4a3a-8468-4022926ea4e2">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A4eb92d77-19f4-4a3a-8468-4022926ea4e2</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A6d57e765-32a0-4a3e-ba12-5e681f92b7e5">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A6d57e765-32a0-4a3e-ba12-5e681f92b7e5</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A73926857-7d7c-4a6e-bce3-1556bd98df01">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A73926857-7d7c-4a6e-bce3-1556bd98df01</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A770eb22d-88bb-4c6f-9016-283f4ff7a518">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A770eb22d-88bb-4c6f-9016-283f4ff7a518</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A8539eac4-21f5-4a3a-8c0a-5ad7249cf38c">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3A8539eac4-21f5-4a3a-8c0a-5ad7249cf38c</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3Aae90efa8-3cf5-4ff9-9637-c7be28b06541">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3Aae90efa8-3cf5-4ff9-9637-c7be28b06541</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3Accebed0b-6bdb-4853-ba2a-6e88321ea4d5">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3Accebed0b-6bdb-4853-ba2a-6e88321ea4d5</a>><br /><<a class="external" href="https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3Ad54c9d42-99ce-415b-ac7c-a2b3498eb7af">https://cn.dataone.org/cn/v2/resolve/urn%3Auuid%3Ad54c9d42-99ce-415b-ac7c-a2b3498eb7af</a>> ;<br />...</p>
<p>So it looks like the Resource Map is correct which makes sense because it was generated using the R package.</p>
<p>The package view uses the Solr query resourceMap:{RESOURCE_MAP} to fill in the table. If you run this query you see the 11 objects, not 16. This explains the table view not showing all the files.</p>
<p>If you look at the documents section of the metadata object's Solr doc, you'll see the 16 objects it documents (itself + 15 data objects.</p>
<p>So what's going on here? Am I wrong to think that it's just the index that is showing the wrong information?</p>
<p>I have forced a reindex with no change<br />I have not checked the arctica logs for any errors</p>
</blockquote> Bug #6828 (Rejected): A jar file can't be found when the metacat-index is buildinghttps://projects.ecoinformatics.org/ecoinfo/issues/68282015-08-10T22:19:30ZJing Taotao@nceas.ucsb.edu
<p>[INFO] BUILD FAILURE<br />[INFO] ------------------------------------------------------------------------<br />[INFO] Total time: 4.710 s<br />[INFO] Finished at: 2015-08-10T15:15:59-07:00<br />[INFO] Final Memory: 12M/245M<br />[INFO] ------------------------------------------------------------------------<br />[ERROR] Failed to execute goal on project metacat-index: Could not resolve dependencies for project edu.ucsb.nceas.metacat.index:metacat-index:war:2.5.0-SNAPSHOT: Could not find artifact javax.sql:jdbc-stdext:jar:2.0 in dataone.org (<a class="external" href="http://maven.dataone.org">http://maven.dataone.org</a>), try downloading from <a class="external" href="http://java.sun.com/products/jdbc/download.html">http://java.sun.com/products/jdbc/download.html</a> -> [Help 1]</p> Task #6586 (Resolved): Index PROV relationshipshttps://projects.ecoinformatics.org/ecoinfo/issues/65862014-08-15T20:26:57ZLauren Walkerwalker@nceas.ucsb.eduBug #6579 (Resolved): resourceMap field is not indexed after uploading a package via the online r...https://projects.ecoinformatics.org/ecoinfo/issues/65792014-07-21T17:25:56ZLauren Walkerwalker@nceas.ucsb.edu
<p>After uploading a metadata and data file on dev.nceas.ucsb.edu using the online registry, the resourceMap field for the metadata and data objects is not populated. But after some period of time it eventually is.</p>
<p>Jessica Couture and Matt Jones experienced this last week where a metadata and image was uploaded but in the Metadata View of the UI, the image was not displaying in the metadata or the package contents table. But when I looked at those packages at least 24 hours later, the resourceMap field was indexed so the image and package contents table were displaying correctly.</p>
<p>Jessica's example:<br /> <a class="external" href="https://dev.nceas.ucsb.edu/knb/d1/mn/v1/object/knb.489.1">https://dev.nceas.ucsb.edu/knb/d1/mn/v1/object/knb.489.1</a></p>
<p>Mine, which doesn't have the resourceMap field yet:<br /><a class="external" href="https://dev.nceas.ucsb.edu/knb/d1/mn/v1/object/knb.491.1">https://dev.nceas.ucsb.edu/knb/d1/mn/v1/object/knb.491.1</a></p>