PISCO/LTER revision history with SBC documents
Margaret O'Brien has pointed out some unexpected documents ("duplicates") showing up in the ONEMercury index.
It seems that many of her SBC data packages began on the PISCO node at an early revision and then they decided to move ownership (in the legacy Metacat replication sense) from the PISCO Metacat to the LTER Metacat.
As I understand it, this was a manual SQL update that switched the serverid value in the xml_documents/revision table from PISCO to LTER (replication of the documents had already taken place).
If this were done properly, the following (obsolete) object should not be included in the index and should probably me marked with SystemMetadata.archived=true. Moreover, it probably should have been included in the serverid switch so that it was not considered part of PISCO's holdings. But it looks like PISCO generated a DOI for the 7.1 revision and then generated SystemMetadata for it.
On the PISCO MN (note only SM for 7.1, not 7.2 which to me indicates that SystemMetadata was only generated for 7.1 because it was "owned" by the PISCO node whereas 7.2 is likely owned by LTER):
You can see the revision graph on LTER for these documents starting with 7.2 (there is no rev 1 SystemMetadata, but note that it is in the Metacat catalog, likely as a replica from PISCO):
So, we should craft an SQL query and update statement that correctly marks these 'archived' objects as appropriate. My hunch is that PISCO does not have 7.x in it's xml_documents table and therefore should not have contributed it as unarchived. We will have to coordinate with Mike and Mark to see exactly what each node has in it's Metacat tables. For this example docid, the KNB thinks that versions 1-4 all came from LTER. I'm curious to see what the PISCO node has.
#1 Updated by Ben Leinfelder over 9 years ago
- Status changed from New to In Progress
Added a bit of script to find (and update) records on an MN that should be marked as archived but are not (and have not been obsoleted_by another pid).