Bug #6895
Complete obsolescence chain is being displayed for LTER content in ONEMercury
0%
Description
ONEMercury displays all data packages (as denoted by ORE maps) within a single obsolescence chain for LTER objects synchronized through PASTA-GMN (https://gmn.lternet.edu/mn) - for example, see this search: https://cn.dataone.org/onemercury/send/facetsQuerry2?filterForDataHidden=true&term1=text+%3A+Sharma+&term1attribute=text&op1=&term3attribute=overlaps&term3=%2C%2C%2C&op3=&term8=either&pageSize=10&start=0&sortattribute=default&facetattribute=datasource&facet=urn%3Anode%3ALTER&facetattribute=author&facet=Sapna%20Sharma.
System metadata for each of the three packages in the above example search contain, what appears to be, correct "obsoletes" and "obsoletedBy" elements (see attachment).
knb-lter-ntl.1001.obsChain.txt 
(3.79 KB)
Related issues
History
#1 Updated by Mark Servilla about 9 years ago
- Related to Task #4295: address discovered content issues in the index added
#2 Updated by Mark Servilla about 9 years ago
- Related to Task #3109: PISCO/LTER revision history with SBC documents added
#3 Updated by Chris Jones about 9 years ago
While the resource maps look to have a correct obsolescence chain, the science metadata don't. I would expect the EML doc version 2 to obsolete version 1 and to be obsoleted by version 3, but I'm not seeing that:
To test this, perhaps call CN.setObsoletes() to update the system metadata, and see if ONEMercury displays the versions correctly after that.
#4 Updated by Dave Vieglais almost 5 years ago
- Status changed from New to Rejected
Closing with deprecation of ONEMercury
