The issue of import
The issue of import can be seen as the elephant in the room when it comes to a record keeping API. It challenges the authenticity and, as such, the value of records. It has been discussed in an MR. I am adding this issue here to document that this is something that should receive attention.
This has been discussed numerous times on the IRC channel over the years and never been dealt with. It has been left 'hanging'. Recently, it was discussed that it is better to use the same API for everything. That way, you increase the value of the API. The opposite is true, an API that prevents you from getting data into a record keeping core is kinda limited, and you will quickly look at other approaches, a different API or direct connections to the database. It is an issue that should be addressed, but the home for the issue is in the API spec repo.
The possibility of using an OAuth 'import' claim approach is a nice way of handling this. Login to the core with a claim for an import role and POST request with such a token can bypass the normal mechanisms for setting the createdDate and createdBy fields. However, this action must be logged to ensure that it is clear that this has happened. It should also be clear in any later payload returned by the software that imported data has in fact been imported and is not something that has been curated in the system.
It's a feature of Noark that this issue has never been dealt with, let alone discussed publicly. Furthermore, it is a feature, as the standard only requires that functionality for import/mass import is available, and the standard has no metadata requirement to ensure that data is marked as imported. The Noark XSD files have no way of indicating that material was imported, so we have no way to distinguish between records curated according to a best practice and records that have not been under system control. We have no way to check the provenance and stability of imported records and have to trust the client.