Data Access Objects

Datasets group records, define their access policy and provide explicit, citable publication versions. Datasets may contain Measurements, Individuals, Vouchers and Media Files.

Projects are just groups of Datasets and Users, representing coohorts of users with common accessibility to datasets whose privacy are set to be controlled by a Project.

BioCollections - This model serves to create a reusable list of acronyms of Biological Collections to record Vouchers. However, you can optionally manage a collection of Vouchers and their Individuals, in parallel to the access control provided by Datasets. Control is only for editing and entering Voucher records. In this case, the BioCollection is managed by the system.

Projects and BioCollections must have at least one User defined as administrator, who has total control over the dataset or project, including granting the following roles to other users: administrator, collaborator or viewer:

• Collaborators are able to insert and edit objects, but are not able to delete records nor change the dataset or project configuration.
• Viewers have read-only access to the data that are not of open access.
• Only Full Users and SuperAdmins may be assigned as administrators or collaborators. Thus, if a user who was administrator or collaborator of a dataset is demoted to “Registered User”, she or he will become a viewer.
• Only Super-admins can enable a BioCollection to be administered by the system.

Biocollections

Biocollections identify where Vouchers are deposited and may represent herbaria, museums, tissue collections, or other formal and informal collections. Search the acronym before creating one. For a herbarium in Index Herbariorum, use the official acronym and lookup action, then verify the returned institution and irn. Register non-herbarium collections manually rather than accepting an approximate herbarium match. Index Herbariorum identifies herbaria; it does not validate Taxons. Index Fungorum is used in the fungal taxonomic workflow.

A Biocollection may also be managed by the installation. Its staff then control editing of deposited Vouchers and their Individuals, process requests to register Vouchers for material users wish to deposit, and process loans of already deposited material. Measurements and Media retain their own Dataset permissions. See Collection workflows. Only a super administrator can enable this mode and must assign at least one collection administrator.

The Biocollection object also interacts with the Person model. When a Person is linked to an Biocollection it will be listed as a taxonomic specialist.

Data access - Full users may register Biocollections, but only super administrators may make one managed. A collection can be removed only if it is unmanaged and has no Vouchers. Administrators manage staff and administrative operations; collaborators process requests and edit records but cannot delete them. Datasets continue to define visibility and authorship while the managed Biocollection controls editing of its Vouchers and Individuals.

Datasets

Datasets are managed groups of Measurements, Individuals, Vouchers and Media Files. Their users may be administrators, collaborators or viewers. Administrators select the dataset visibility and policy; the effective visibility of a record also depends on dataset membership and the applicable publication policy. OpenDataBio applies the current policy when listing, mapping, exporting and serving records.

Datasets may also have many Bibliographic References, which together with policy, authorship and metadata fields annotate the dataset for sharing: * Link any publication that have used the dataset and optionally indicate that they are of mandatory citation when using the data; * Define a specific data policy when using the data in addition to the a CreativeCommons.org public license; * Detail any relevant metadata in addition to those that are automatically retrieved from the database like the definitions of the Traits measured.

Dataset versions and publication

A Dataset Version is an explicit snapshot, not merely the date of the latest edit. A published version receives its own stable UUID and public page. Its derived item indexes make the version discoverable without changing the snapshot when live records are later edited.

Version downloads are persisted archives. The main archive contains data plus machine-readable field metadata and a README; a separate media archive may be available. Downloads can require acceptance of the dataset agreement and are logged for dataset usage reporting. Download counters and access logs describe access to published material; they do not grant permission to restricted data.

Dataset metadata may include a canonical data policy, license, required citations, creators/authors with ordered roles, and summaries of related datasets. A dataset can also allow its taxon list to be shared. Review these fields before publishing a version because they form part of the interpretation and attribution of the archive.

Use the version UUID when citing or linking a fixed publication. Use the Dataset page when referring to the evolving managed collection.

Projects

Projects are just groups of Datasets and interacts with Users, having administrators, collaborators or viewers. These users may control all datasets within the Project having a restricted to project users access policy.

Users

The Users table stores information about the database users and administrators. Each User may be associated with a default Person. When this user enters new data, this person is used as the default person in forms. The person can only be associated to a single user.

There are three possible access levels for a user: * Registered User (the lowest level) - have very few permissions * Full User - may be assigned as administrators or collaborators to Projects and Datasets; * SuperAdmin (the highest level). - superadmins have have access to all objects, regardless of project or dataset configuration and is the system administrator.

Self-registration creates a registered user. A super administrator may promote that account to Full User or SuperAdmin and may authorize a full user to manage access. A delegated access manager may promote registered users to full users and reverse that promotion, but cannot alter super administrators, other access managers, or delegate the permission. Only super administrators delete accounts.

Every registered user is created along with a restricted Project and Dataset, which are referred to as her user Workspace. This allows users to import individual and voucher data before incorporating them into a larger project. [TO IMPLEMENT: export batches of objects from one project to another].

Data Access:users are created upon registration. Only administrators can update and delete user records.

User Jobs

The UserJob model records background tasks such as imports, exports and maintenance operations independently from Laravel’s internal queue row. It stores progress and logs and can store structured, ordered results for each processed record. Results distinguish successes, warnings and errors and may include the affected object’s identifier. A completed job can therefore contain row-level warnings or failures.

Users may inspect their jobs and results, download affected identifiers, cancel running jobs, and resume operations that explicitly support resumption. Deleting a UserJob removes the user’s job history; it must not be used as a substitute for canceling work that is still running.

Data Access: Each registered user can see, edit and remove their own UserJobs.