You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the OAI content is a set of xml files that are mounted into the container at deployment time.
The editor of those files has to maintain the timestamps (OAI datestamp and VOResource updated attr) manually and make new versions live at about the same time as the manually entered timestamps.
There is currently no back end database and for most uses that would be an unnecessary dependency/burden.
The text was updated successfully, but these errors were encountered:
Simple quick and dirty proposal: add support for an authorized user to update a record through the REST API. The workflow would be roughly:
GET /reg/oai?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://example.net/record
manually edit the OAI-PMH document
PUT /reg/oai
The PutAction would check authorization, validate the input document, set the OAI-PMH datestamp and the VOResource updated attribute to the current time, and write the record back to the underlying filesystem. PUT could both create new and overwrite existing records.
aside: Tools to help with (2) edit could be created, but the value-to-effort ration seems low to me...
For a persistent registry, the deployer is responsible for mounting a writable external filesystem into the container; if they deploy multiple instances the fs has to be shared between all instances.
This feature would be enabled by an optional configuration of an admin user with permission to put records. If an admin is not configured, the content is immutable (as it is now).
Currently, the OAI content is a set of xml files that are mounted into the container at deployment time.
The editor of those files has to maintain the timestamps (OAI datestamp and VOResource updated attr) manually and make new versions live at about the same time as the manually entered timestamps.
There is currently no back end database and for most uses that would be an unnecessary dependency/burden.
The text was updated successfully, but these errors were encountered: