Create

If you have editors' rights, you can create a file once logged in the application from the relevant page.

If you are not, ask to be added.

You can always check the data and add in the folder called "new" correct and validating files which adhere to these guidelines, with one exception: Work records can only be created in the application because their IDs become CAe identifiers.

Please follow the instructions given on the application after the creation of a new file with that procedure. After downloading and before committing the new file, always open it in your editor to make sure that it is valid and, if necessary (which it nearly always is!), edit it.

Example workflow

It is not rare that a single unit of work will involve several commits to several branches of different repositories. Here is an example:

1. The contributor starts to edit a manuscript record,
2. she thinks an identifier for a new Textual Unit is needed,
3. she opens an issue, labeled Textual Unit Identification, pings relevant people and makes sure that this new Textual Unit should be created (this also helps contributors who do not have enough permissions to create Textual Units in the app). In the while, there is no need to add a @ref to <title>↗ in <msItem>↗ in the manuscript record, for example, a comment can be left that there is a pending issue about the identification of the Textual Unit.
4. If the result of the discussion is positive and a new record is needed, the editor or some other collaborator creates it in the app (it needs to, is a textual unit!).
5. Because the Textual Unit record has been created in the app, it needs to be synced. Make a Pull Request to Works repository and make sure it is promptly reviewed, corrected and merged. Planning this in the issue where you discussed the creation is a good idea. Please note that it needs to be merged quickly, to keep the app in sync.
6. Anyone can now use the newly created Textual Unit ID in manuscript records.
7. Once the contributor is ready, a Pull Request for the manuscript can be done to the Manuscripts repository.
8. During review it turns out it was not necessary to create a Textual Unit, alas. A collaborator reviewing this Pull Request did not see the discussion and could not intervene before.
9. The editor or any other collaborator can now delete the record in the Works repository and make a Pull Request justified by the review of the manuscript, and eventually needs no review if linked to that. By doing this, the app, where the record was created, gets to know and stays in sync.

A record creation in the app should always be promptly followed by a commit and a Pull Request to align to the database in any case. If the discussion about this operation has already happened, review only needs to focus on typos and contents of the record. The app will have learned about the new files because they were created in there in the first place, but if you do not merge them into master, as a result of a Pull Request and delete them the app will never get to know that the record was deleted because you deleted it somewhere else. That is why we need a commit and a Pull Request, so that repository and database stay in sync.

Doublets

Doublets may be identified. This happens especially when Textual Units are created without enough disambiguation information or when one same manuscript is entered in the system from different sources without prior knowledge and due diligence to identify the already existing record. It is, however, normal and will always happen.

If you identify a doublet, it is wise to deal with it in some way or another and it is often advisable to consult with other editors and collaborators about this, because there may be reasons to have those different records.

If it is clear that a record is superfluous, delete it, properly document this in the commit, make sure the deleted identifier is not used elsewhere, update existing references, but also add a relation in the record which survives, like the following.

                  <relation name="betmas:formerlyAlsoListedAs" active="IDofthesurvivedrecord" passive="IDofthedeletedrecord"></relation>
               

It may be also that in cases of doubt or for other reasons that the editors and collaborators will discuss you want to keep the double record. In this case, you can always use a <relation>↗ with @name skos:exactMatch, skos:broadMatch or skos:closeMatch. It will be even more useful than usual to give a <desc>↗ in your <relation>↗. No redirect will be produced, in this case, when one of the two is requested, the relations will be visualized, and in case of skos:exactMatch this will be with the header.

Delete

If you make a mistake or find a doublet which needs to be cleaned up or need to reorganize Textual Units by making one formerly independent part of another, you will delete a record. Doing so as you do normally, with a commit to the public repositories in GitHub, will add a value to a list of deleted records and if a <relation>↗ with @name betmas:formerlyAlsoListedAs is present in another record of which the deleted one was a double, then requesting the deleted item will redirect to that record.