ADMIRAL Databank specification proposal
From ImageWeb
Contents |
Databank specification proposal
Deployment details and status
Copy of notes provided by AR: to be updated
In the current databank API, I am hoping to bring it to a state where all the immediate issues have been fixed.
I am currently in the process of making sure the versions are maintained properly for all actions of POST, PUT and DELETE and have extended the API so that you can get previous versions by appending /version# to the end of the URI for datasets and states (example: http://192.168.23.129:3000/sandbox/datasets/test3/version4 will provide the manifest as in version 4 and http://192.168.23.129:3000/sandbox/states/test3/version4 will give the state information at version4).
test suite for this? - #g
The other outstanding issue I want to do is the version numbering to start from 0 (especially for unpacked datasets). Once these two are done I plan to release databank API as an alpha version.
I note this was a new requirement coming from researcher feedback on demonstrating the submission interface
If you any further thoughts on the voabulary to use for including other metadata files, I could update that to. Sorry, I would have liked to say I am done with all of this, but not yet. I really am trying to make a big push and get things done. Let's see how well I progress this afternoon.
Use rdfs:seeAlso for now; but I'd say that if you do a GET with Accept: application/rdf+xml, then the link should be ignored for the purposes of manifest assembly. This assumes that databank can recognize RDF files in an uploaded dataset./ Maybe need to discuss.
We have the go ahead for using http://ora.ox.ac.uk and the URI for the databank service will be http://databank.ora.ox.ac.uk . We have already started work on setting it up. This will contain the alpha version of the databank API. I am guessing you would still like to retain access to the current location for testing.
Good - when can this be live?
Functionality and API
Based on notes by AR with comments in italics
The databank API will only talk to a web layer above it.
Clarify, please
This layer will deal with:
- Identification / authentication using SSO. Need to use oak-ldap
- Each unit / list of people who can access the service (per silo) will be recorded at the time of creating a silo
- Naming rules for silos
- hierarchies defined here will be converted to a name in the layer below
- Resolver will resolve uris, dataset id and creator in manifest and state information
- Interface with DOI API
- SOLR with API opened to silo administrator to update SOLR config and reindex data
- Audit log
- Have human intervention for lifting of embargoes (discuss requirements here)
- Have option to choose dark / light store
- dark store - nothing will be visible to the user
- light store - Manifest will be visible to all users. Users will have acess to files with no Embargo on them.
Also (existing functions per published API and test cases - http://163.1.127.173/datasets_api.html (could use proper URI for these; also publish link to test suite in API docs?)
Work for Version 2.0 of Databank API itself
- Calculate disk usage per silo and report it in state information of silo. When performing any PUT/POST operation, if beyond quota, return 403 and reason
- For items in the light store, Index ALL records in SOLR. Access to the metadata is not restricted, but acces to files is.
- Deal with deleting / replacing triples in the manifest rather than return 403 (or how do we deal with update / delete)
- Access control should be restricted to the server above
Also, need to discuss embargo handling and associated authorization model'
Issuing DOIs
Current status note from AR
I am yet to hear anything from British Library about the metadata requirements for DOIs and have not yet received a username and password to test their API. I have written to them again. Hopefully I will have this tested before the Christmas break.
We'll need to agree how this will be reflected in the Databank API
