Skip to content

Credits, crowdsourcing and audit trail

After bagning my head for hours, see below the schema modification and workflow for credits and crowdsourcing

Requirements, in priority order:

1) Store and process information about proposed changes to metadata, textual data and bibliographic data

Admin directly make changes to the database. We want to open the system to process suggestions from a larger audience. Since those users don't have privilege to add / update / delete data, we need to store their changes until an admin can vet them and decide if the changes should be applied or not.

2) Audit trail of the metadata, extending the suggestion system

Since we will be importing data in a flat format, both in FM and on the Web interface, also through the API, we can extend this implementation to provide an audit trail (of the metadata in particular). We already have a version history for inscriptions data while this and this has been lacking for catalogue data.

Tables and workflow

update_events

Each add or edit of an artifact (catalogue data) and inscription and for each add of a publication of multiple entries of one of these, an update event is created. The table stores user name of the person uploading the data or submitting the form, date & time, project name (optional) attached to the credits and comments about the submission, eg why these changes are proposed or added. If the update is an inscription, it is possible to be more precise about the credits that will be attached as to if it relates to transliteration, transcription, translation or annotations. This field is optional.

authors_update_events

This table stores credits attached to an update event. This makes possible to give credits to multiple people for an update.

inscriptions, publications and artifacts_updates

Changes or additions are added to these tables, with the update_event_id. If submitted by an admin, the submission is automatically accepted, thus the entries are flagged as "accepted" and the accepted_by is filled by the admin's user id.

inscriptions

When a new inscription or change to an inscription is accepted, it is flagged as "is latest".

publications

Admin can submit additions and editions which will be accepted automatically.
Users can only submit additions, which can be accepted by admins.

artifacts_updates

First the data is validated to make sure it could be added to the database. Then the proposed changes are stored in the flat format they are submitted in. This table only stores changes, not the whole entry from the artifacts table. This table can be used to submit changes or adds of artifacts and their association with publications. Once the changes are accepted or if the submitter is an admin, the artifacts entry is updated in the artifacts table.

Workflow for crowdsourcing through the interface

All visitors

  • visitors can access a view listing pending proposed changes by logged-in users. changes are sorted by date and under their "update event", with update event and associated credits info at the top
  • data to be added the artifacts_shadow table are not visible

Logged-in users

  • user can submit data through form with file upload for bulk, or form with fields for one item
  • when a user submits data, the content is processed to make sure all the fields contain appropriate data that could be converted to a real entry or to modify an existing entry (if it doesn't validate, error is shown to the user, which field and what problem)
  • only fields that contain information will be considered to update entry.
  • to clear a field or association, the user will employ the keyword "NULL".
  • when the data validates, an entry is created in update_events, in authors_update_events if there are credits, and also in one of the three: artifacts_updates or inscriptions or publications.
  • Association of publications with artifacts is done through the artifacts form / artifacts file submission

Admins

  • view to see list of pending proposed changes by logged-in users with "accept" and "reject" links
  • update_events of bulk changes can be accepted or rejected in bulk
  • when an entry is rejected, accepted field turns to 0 and accepted_by is filled with admin user_id
  • when entry is accepted, accepted field turns to 1 and accepted_by is filled with admin user_id. In the case of artifacts data, the data is converted and the entry in artifacts is created or updated. In the case of inscriptions, the flag 'is latest' is set to 1 and any other inscription for that artifact should be flagged 0.

To get credits

Check update_events_id, then fetch update_event entry and associated authors_update_events entries. In the case of inscriptions, the type of inscription is stored in update_events.

Edited by Émilie Pagé-Perron