BPT

BPT and CTS

Background

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:

Structure

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.

Versions

There are three work versions in CTS, indicated with a fixed terminology:

flavour	siglum
edition	`#### edition:`
translation	`#### translation:`
commentary	`#### commentary:`

metadata

Textgroup metadata sit in a settings.yml or a texgroup.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.

files and folder

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.

BPT