Status element in OAI-PMH envelope, managed authorities declared by registries, and RegTAP

[Menelaus Perdikeas]

Based on reports we run at ESAVO we've noticed some (few) clashes of managed authorities claimed by different registries and this has led me to investigate some edge cases, hence this email probing for your feedback.

Specifically, I would like to clarify the interplay between the "status" element in the OAI-PMH envelope and the managed authorities declared in a registry resource in connection with RegTAP's requirement that "deleted" and "inactive" resources are not maintained.

Note that there is also the "status" attribute in VOResource which may also take the value "deleted" but I'll try to keep that out of this discussion as it will further complicate things; I am just focusing on the "status" element of the OAI-PMH envelope. Also I'll try to use the term "record" and "repository" when discussing OAI-PMH concepts as opposed to "resource" and "registry" when discussing IVOA concepts.

As you know the "status" element in the OAI-PMH envelope is optional and can, if present, only take one possible value: "deleted". The semantics of that "deleted" according to the OAI-PMH specification are that it "indicates the withdrawal of availability of the specified metadata format for the item". What exactly that means in an IVOA context (given that we diverge a bit from the OAI-PMH view of metadata and "items") may be debatable.

Consider the following scenario: a resource was hosted in a registry A and was later, for some reasons, migrated by its owner to another registry B. In an IVOA context this should presumably also require that the managed authorities of both registries be updated to reflect the migration of the resource(s).

Assuming OAI-PMH support for deletions in repository A, should the repository A now report the migrated record as "deleted" or not?

This has ramifications for RegTAP. When harvesting a repository if I see that a record is "deleted" (in the OAI-PMH envelope sense) then I proceed to also purge it from the RegTAP database (as per RegTAP's requirement that  "deleted" and "inactive" records are not maintained - although that "deleted" refers to the "status" attribute of the VOResource, not the OAI-PMH envelope's "status" element).

However, in the above use case, the record is only deleted in the OAI-PMH repository sense (for that particular repository), not in the IVOA sense as it now simply lives on in another registry. So, upon harvesting an OAI-PMH deleted record should a RegTAP implementation proceed to purge it from the relational schema or not? What we implement is the following:

[1] if a record is deleted (in the OAI-PMH sense) and its identifier falls under one of the managed authorities of the registry it was harvested from, then the record is purged from the relational schema.

[2] If a record is deleted (in the OAI-PMH sense) and its identifier does not fall (or, more appropriately, no longer falls) under one of the managed authorities of that registry then this is simply taken as an indication that the record no longer "lives" there and nothing is changed (for the time being) in the RegTAP relational schema. Eventually, we should expect to harvest the record from another repository (the one in which it now actually lives) and only then would the RegTAP relational schema *possibly* be updated (e.g. if the record was also updated subsequently to its migration).

Does the above make sense? If so, it is important that managed authorities declared by registries are correctly maintained when resources are migrated (a rare event at any rate).

Cheers,
Menelaus.

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.