Its aim is to provide documents, commentaries and data in general concerning the genesis of the Austrian Bundes-Verfassungsgesetzes in the 1920s.

1. documents are getting scanned and images are being uploaded to goobi
2. metadata for documents are collected in baserow
3. The import-workflow triggers the import of documents from goobi to Transkribus and triggers the automated transcription. This workflow is however just updating the metadata and then remotely triggering another dedicated import workflow.
4. Documents are proof red in a basic manner inside Transkribus.
5. Transkribus-Export workflow periodically exports the documents from the repo. It only does so if the baserow-metadata of the document contain the Transkribus ids of document. Otherwise it is being ignored. The resulting TEI-Xmls are saved it a dedicated directory.
6. The generated TEI-Xmls are corrected manually using the framework and the xml-schema generated and provided via a dedicated repo, containing some automated distribution workflows and a pages instance to make schema, docu & framework accessible via https. To provide a strict separation of manually corrected files and automatically generated files, the latter are copied manually from the source directory into a repo only containing the manually corrected files.
7. The resulting data get published via a dedicated repo. All files from the automated Transkribus export are getting published, but if the corresponding file is already present in the repo only containing the manually corrected files the latter is used as source assuming it provides the better data quality.

General texts such as introductions etc. are written in docx format, uploaded to google-docs, transformed to xml and then published on the page via a dedicated repo.

Editors' commentaries providing insights into document genesis, historical significance and juristic implications are going to be written as docx and transformed to xml via a dedicated repository.

All the data and most of the workflows are in the according repository. However some of the values in the dropdowns of author-mode (ids etc.) are provided via the schema (closed value lists for attributes). There is a workflow in bv-entities to fetch the current metadata from baserow and trigger the generation of the schema (and thus update the closed value lists) with these new data. Everything concerning

1. Schema
2. Documentation for the framework-users
3. The framework

If the framework is changed a new version is automatically generated an distributed via gh-pages. If users have issue accessing the update, it can be triggered manually, via the help-submenu in Oxygen.

There is a small repo, containing a bunch of scripts to build and deploy a Noske container to provide the data as corpus a Noske instance. There is a forked repo managing the container-delpoyment in the cluster. It shouldn't be necessary to touch it in any way.

This repo only provides this README for the project page.