At its heart, CTS is an ontology of text. Text as a tree structure, work as versions. BPT can be used in a CTS compliant way. This means that the ontology is expressed in BPT. Here is how:
CTS structure is expressed with hashes.
| siglum | explanation |
|---|---|
# |
textgroup |
## |
work |
### |
textpart |
#### |
CTS version |
There is another siglum, #####, but it denotes a header and plays no rule in the text structure.
There are three work versions in CTS, indicated with a fixed terminology:
| flavour | siglum |
|---|---|
| edition | #### edition: |
| translation | #### translation: |
| commentary | #### commentary: |
- Textgroup metadata sit in a
settings.ymlor atexgroup.md. this is inconsistent. Why not use YAML here too? - Work metadata sit in a Pandoc-style YAML block at the top of a work.
- Textpart metadata sit in a regular style YAML block at the top of a textpart.
For other metadata (at lower level than text parts), use stand-off annotation.
We have yet to devise a way to indicate mandatory and optional metadata fields.
The structure of the CTS folder is described elsewhere. Basically a folder per textgroup; within it a folder per work and an .xml per version. (BTW, textgroup and work have the crazy CTS xml file with metadata. These are converted from the BPT).
BPT can simply follow this: a folder per textgroup; within it a folder per work and an .md per version.
Likewise, CTS has requirements for file names, BPT can simply follow them.