This repository has been archived by the owner on Mar 14, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 7
Data Expectations of TACO
Christina Harlow edited this page May 3, 2018
·
2 revisions
- Old Version is set to permissions where only super-admins can edit (in Argo or Admin system); argo users can view; and public access systems cannot view or edit. Field for
followingVersion
is added to the metadata, pointing to UUID for the newly created version's record.
I think we were limited by data model previously - all objects had to have an APO, therefore APOs had to have an APO, etc. (recursion as you say). The only caution about relaxing that is that I've been tracking new ETDs that were submitted to SDR without an APO, so we just need to be rigorous in our screening of such objects. In the current model - "items" must require an APO, "collections" should require an APO, but presumably workflows, APOs and other administrative objects probably don't.
Requirements:
- Objects require an APO / governance
- Collections require an APO / governance
- Filesets & Files require this as well, derived from Object?
To be written up: APO relationship to Agreement and how that maps to SDR3 governance.
- TACO API & Service Design
- Development Guide
- TACO Internal Steps
- Identifier schema
- Data Modeling & MAPs
- Data Expectations of TACO
- Auth & Permissions
- Benchmarking Goals & Scenarios
- Workflows & Robots Replacement Analysis