Table of contents

The “albion”

My dissertation explores the practices surrounding the Treatise on the Albion, which describes a computing instrument called “albion”, during the 14th century.

As an instrument, the albion, is composed of multiple parts:

Mother
The mother of the albion is a circular brass plate with two faces, on which the different parts of the instrument are riveted
Limb $ehi$
The edge of the first face of the mother forms a ring $ehi$, whose inside is the circle inscribed in the square inscribed in the disc formed by the mother.
Plate $pgq$
The space available on the first face inside of the limb can be filled by a first removable plate $pgq$. This plate itself has a recto and a verso, and can rotate around the mother's centre. The recto of this plate holds figures required to compute planetary positions, while the back is dedicated to eclipse computations.
Limb $lmn$
The edge of the reverse of the mother is raised with a second ring $lmn$, whose breadth is one third that of the first limb $ehi$.
Plate $ros$
As in the first face, the space available inside the limb $lmn$ can be filled with a removable plate $ros$. The recto from this plate contains a spiral used to compute mean motions, while the verso is used for instruments of spherical astronomy (like an astrolabe or a saphea).
Accessories
Finally, other parts are added to tie every piece together, and to help handling the instrument (sighting pinnules, suspension rings, strings, etc.).

As it is often the case with astrolabes, the central space available on each of the mother's faces when the plates are removed can also be used to engrave more elements, therefore increasing the computational capabilities of the instrument.

Building the albion

It is not easy to study the Treatise on the Albion without access to a physical albion. Indeed, practices associated with this text obviously involve handling this instrument. Luckily, the second part of the text provides the instructions required to build a version of this instrument.

Select the precision of the instrument: 10° 15° 30°

Zodiac 1 2 3 4 5 6 7 8 9 10 11 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 0 1 2 3 4 5 6 7 8 9 10 11 Saturn 1 2 3 4 5 6 7 8 9 10 11 Jupiter 1 2 3 4 5 6 7 8 9 10 11 Mars 1 2 3 4 5 6 7 8 9 10 11 Sun 1 2 3 4 5 6 7 8 9 10 11 Mercury 1 2 3 4 5 6 7 8 9 10 11 Moon 1 2 3 4 5 6 7 8 9 10 11 True Moon 1 2 3 4 5 6 7 8 9 10 11 Zodiac 1 2 3 4 5 6 7 8 9 10 11 0 1 2 3 4 5 6 7 8 9 10 11 Saturn 1 2 3 4 5 6 7 8 9 10 11 12 Jupiter 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Mars 1 2 3 4 5 6 Venus 1 2 3 4 5 6 7 Dragon 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Elongation 1 2 3 4 5 6 7 8 9 10 11 Epact 1 2 3 4 5 6 7 8 9 10 11 12
Mother
Limb $ehi$
Zodiac
Solar year
Altitude
Arc of hours
Orb of Saturn
Orb of Jupiter
Orb of Mars
Orb of the Sun
Orb of Mercury
Orb of the Moon
Orb of the True Moon
Equator of Venus
Equator of Mars
Equator of Mercury
Equator of Jupiter
Equator of the Moon
Equator of Saturn
Plate $pgq$
Equation of time
Mean motion of Saturn
Mean motion of Jupiter
Mean motion of Mars
Mean motion of Venus
Lunar nodes
Elongation
Lunation
Syzygies
Animate

Edition

Limitations of this reconstruction

The reconstruction presented above rests on a “modern” interpretation of the text. Yet, in manuscript, diagrams that accompany the text often don't agree with the proposition made here. The text itself often varies between witnesses, and is furthermore augmented with marginal notes, deletion marks, and so on. These variations teach us that all the albions that were built were not identical. Documenting these variations is crucial to understand which were the practices of the actors and actresses.

A more historically accurate approach would start from source materials, and would stack a critical apparatus next to the proposed reconstructions to better understand what the practices of actors and actresses of the 14th century were when they worked with this text.

This is why I try to work with the diplomatic disposition, etc.

Principle of the edition

The eXtensible Markup Language (XML) is, by definition, an “extensible” format. In practice, this means it can be used to encode a wide range of different information, which can be expressed in different languages (TEI, HTML, SVG, MathML, XSLT, etc.), all in one document.

This “extensible” nature of the XML language enables us to produce an edition of the Treatise on the Albion which encodes different kinds of data about the text.

Diplomatic level
One level of information that can be encoded corresponds to a careful description of each manuscript's content. How is the text copied, which abbreviations are used, where does the scribe goes to a new line, what are the page's dimensions, etc.
“Critical” level
An other way to approach textual edition is to go beyond witness-specific graphical information, and to focus on the comparison between “normalized” versions of the texts (where abbreviations are expanded, line breaks are ignored, etc.). The point would be, then, to produce a critical apparatus to document the “significant” variations we observe when comparing the different manuscripts. The @type attribute of the <tei:app> element allows us to specify in which sense a variation is considered “significant”.
Semantic level
The edition can also include more “analytical” information: which syntactic structures are used in the texts, how are the different lexical tokens formed and integrated in these structures, to which mathematical objects do they refer to, etc.

Diagrams as traces of a program

All the transformations by one document

DiagramsFor diagrams in particular, my approach is to consider each diagram traced in a manuscript as the result of one specific execution of a particular construction procedure, which we can reasonably assume to have, somehow, some kind of relationship with the text accompanying it. In my edition of the text in TEI, I therefore try to identify which objects the text refers to, and how these objects are defined or described. Likewise, I try to identify whether these objects are represented in diagrams, and if so, how. The problem of editing diagrams is therefore transformed into how to execute the construction procedure for the different objects represented in the diagram, then to display the result of this procedure in a suitable format. The goal of BOA is to solve this problem using XSLT 1.0 to handle XML (and in particular TEI) documents.

To do this, I decompose the edition of the diagram in multiple steps:

Load the program in memory
The first step to edit a diagram is to identify which elements in the TEI document contribute to the diagram's composition. Each element corresponds to one of the main program's instructions to draw this diagram, and takes the form of an XML node.
Example:
<tei:graphic uri="#II-1-circle-abcd">
  <one:arg param="radius" value="7.2" unit="cm" />
</tei:graphic>
<tei:graphic uri="#II-1-circle-pgq" definition="center-radius-circle">
  <one:arg param="center" value="#II-1-point-g" />
  <one:arg param="radius" value="???" unit="cm" />
</tei:graphic>
<tei:graphic uri="#II-1-ring-ehi">
  <bt:df feature="labels-values" value="h i" />
  <bt:df feature="labels-positions" value="edges-outside" />
  <bt:df feature="labels-positions-origin" value="315" value="deg" />
</tei:graphic>
<tei:graphic uri="#II-2-segment-agc">
  <bt:df feature="labels-positions" value="outside" />
</tei:graphic>
<tei:graphic uri="#II-2-margins-ehi" />

Decode the program instruction
The program execution starts with the first instruction. To manage this instruction, we first need to parse the information available inside the instruction itself in order to prepare for the execution of the appropriate operation, and to update the processor's state according to this information.
Resolve addresses and execute the operation
The information required to execute an instruction is usually not fully contained in the instruction itself. Some of this information may already have been computed as a result of a previously executed instruction. In this case, the processor should find out where this information has been stored. Or, this information may have to be found elsewhere in the text. Then, the processor needs to locate the pieces of text containing the information, and try to decode them. The processor finally needs to make sure that all the parameters required to execute the instruction are indeed available (for instance, to trace a segment between two points requires that the beginning and the end of the line are two points whose position can be computed), before loading a sub-program able to execute the instruction.
Read operands
Once the different parameters of the operation have been identified, the processor loads the objects corresponding to each of these parameters. If necessary, the processor will execute the instructions needed to construct the aforesaid objects, then forward them to the sub-program charged to execute the main instruction.
Write the result
The processor then obtains the result of the sub-program, and stores it in an appropriate location. The different objects constructed will only be displayed in a consumable format (SVG, TikZ, STL, etc.) once the whole procedure has been executed.
Repeat
When an instruction has been executed and his results have been stored, the processor prepares the next instruction, and repeats until all the main program's instructions have been executed.