Member Nodes

The PISCO member node is having issues with resolving DOIs managed by EZID that point to DataONE objects via the DataONE resolve method. The following is the list of object PIDs:

doi:10.6085/AA/pisco_mussel_fecundity_UCSB.4.6
doi:10.6085/AA/pisco_mussel_fecundity_UCSC.45.5
doi:10.6085/AA/pisco_mussel_growth_UCSC.77.2
doi:10.6085/AA/pisco_smr_synthesis.1.2
doi:10.6085/AA/ELLXXX_015MTBD009R00_20010331.40.1
doi:10.6085/AA/VALXXX_015ADCP015R00_20091110.40.1
doi:10.6085/AA/PELXXX_015ADCP015R00_20090402.40.1
doi:10.6085/AA/pisco_mussel_fecundity_UCSB.4.1
doi:10.6085/AA/pisco_site_descriptions.1.2
doi:10.6085/AA/PROXXX_015ADCP015R00_20100323.40.1
doi:10.6085/AA/SCPXXX_015ADCP015R00_20091109.40.1
doi:10.6085/AA/knb-lter-sbc.4010.1
doi:10.6085/AA/BAYXXX_015ADCP015ROO_20060410.40.1
doi:10.6085/AA/BEAXXX_015ADCP015ROO_20060125.40.1

In summary, there are total of 14 objects that cannot be resolved through the EZID target DOI URL. 6 objects (metadata) are not reachable on the CN, but do exist in the Metacat "systemmetadata" table and have a corresponding autogen file in the Metacat documents directory; 6 objects (data) have a misconfigured EZID DOI target URL string (the actual PIDs have a repeating string fragment: "doi:10.6085/AA/doi:10.6085/AA", while the DOI URLs do not); 1 object that does not exist in the "systemmetadata" table; and 1 object that contains mangled metadata content, which apparently was never successfully synchronized to the CN.

An analysis of issues can be found in the following Google Doc: https://docs.google.com/document/d/1KhCw87tJlHIh5l9n5PEvEJnW9pgwXki8HOiS71Mh1fI/edit?usp=sharing.