La Syntaxe du Codex

Describing the stratigraphy following La Syntaxe du Codex. Essai de codicologie structurale Andrist, Canart, and Maniaci 2013 requires reading the methodology outlined in the book. It is not just an extraordinary book, it is also well written and made clear by examples fully spelt out.

The Beta maṣāḥǝft application tries to support this methodology with tabular visualizations based also on RDF data which are exemplified by Vatican City, Biblioteca Apostolica Vaticana, Biblioteca Apostolica Vaticana Cerulli 37 and especially in its syntaxe view. The workings of these are out of the scope of these guidelines and here only the way in which the information is encoded in the TEI will be described. An article by Pietro Liuzzo, Linked Open Data based on La Syntaxe du Codex for Manuscripts in Beta maṣāḥǝft, has been submitted for the forthcoming Linked Ancient Word Data Cookbook, ed. by Paul Dilley, Sarah Bond e Ryan Horne (ISAW papers).

The ontology used in the encoding can be found here and can be viewed clicking on the ontology button in these guidelines.

Some of the values, especially properties, are also reproduced for convenience in the Schema.

The tabular visualizations are based on two aspects of the encoding. The first is the assignation of identifiers to the relevant parts of the TEI description. The schema enforces the presence of @xml:id. The second part is the use of <relation> to make statements which work like stand off annotations about the stratigraphy.

Both these practices are documented in these guidelines elsewhere and here we will focus on how to encode a statement about the stratigraphy using <relation>.

Production units added later

In this example, from Oxford, Bodleian Library, Bodleian Aeth. e. 8, we want to say that <msPart>s p1 and p2 were added later to the manuscript. From the catalogue information we can deduce that this can be a transformation (this is the term used in the book, which I will not define here) of type A1 (Andrist, Canart, and Maniaci 2013, 63).

We can then rely on the @xml:ids of the description to describe this sitution in a series of <relation> elements.


<listRelation>
          <relation active="BDLaethe8#p3" name="sdc:constituteUnit" passive="BDLaethe8#UniCirc1"></relation>
            <relation active="BDLaethe8#UniCirc1" name="sdc:undergoesTransformation" passive="BDLaethe8#tr1"></relation>
            <relation active="BDLaethe8#tr1" name="sdc:hasTransformationModel" passive="sdc:A1"></relation>
            <relation active="BDLaethe8#tr1" name="sdc:produces" passive="BDLaethe8#p1"></relation>
            <relation active="BDLaethe8#tr1" name="sdc:produces" passive="BDLaethe8#p2"></relation>
            <relation active="BDLaethe8#tr1" name="sdc:resultsIn" passive="BDLaethe8#UniCirc2"></relation>
            <relation active="BDLaethe8#p1" name="sdc:constituteUnit" passive="BDLaethe8#UniCirc2"></relation>
            <relation active="BDLaethe8#p2" name="sdc:constituteUnit" passive="BDLaethe8#UniCirc2"></relation>
            <relation active="BDLaethe8#UniCirc2" name="dcterms:hasPart" passive="BDLaethe8#p1"></relation>
            <relation active="BDLaethe8#UniCirc2" name="dcterms:hasPart" passive="BDLaethe8#p2"></relation>
            <relation active="BDLaethe8#UniCirc2" name="dcterms:hasPart" passive="BDLaethe8#p3"></relation>
            <relation active="BDLaethe8#UniCirc1" name="dcterms:hasPart" passive="BDLaethe8#p3"></relation>
            <relation active="BDLaethe8#UniCirc2" name="skos:exactMatch" passive="BDLaethe8"></relation>
</listRelation>

                    

Example 1

Here we start defining only the part 3 as UniCirc, by assigning to it the ID ‘UniCirc1’ using the property sdc:constituteUnit from the ontology. We continue saying that part 3 (UniCirc1) has undergone a transformation (property sdc:undergoesTransformation). We are defining a transformation with ID ‘tr1’ and we want to say that we know that this transformation is an addition of material and content, thus a transformation of type A1, and we do so using the property sdc:hasTransformationModel.

During this process of transformation part 1 and part 2 were produced (sdc:produces) by this transformation, which resulted (sdc:resultsIn) the UniCirc2. Now that the two parts have come into the game, we can also explicitly assign them to the UniCirc2 with the property sdc:constituteUnit. We can then also repeat the dcterms:hasPart nodes for each UniCirc.

The order of the encoded elements is irrelevant, we are just following the logic in the argument. We can additionally say that it is this one UniCirc with ID ‘UniCirc2’ which corresponds to the manuscript we have in our hands. We cannot make any further statement about UniProd or about the pertinence of the parts 1 and 2 to another UniCirc and we do not do so.

Added text in another hand

In Saint Petersburg, Institut Vostočnyh Rukopisej Rossijskoj Akademii Nauk, Orlov20 there are two cases, where according to Turaev’s description, some text was presumably added later in another hand. These added portions should be regarded as additions, because they are written in another hand, presumably later. And these texts might also be regarded as complete without this added information, so it was not about the completion of the text, rather adding new information. (this paragraph is an adaptation of the explanation given by Daria Elagina here)

In the following example I reproduce the encoding I have made of this. (<listRelation> is allowed anywhere in the Beta Masaheft schema).


<msItem xml:id="p1_i14">
    <locus target="#9v"></locus>
    <title ref="LIT4952History" cert="medium"></title>
    <textLang mainLang="gez"></textLang>
    <msItem xml:id="p1_i14.1">
        <title type="incomplete" ref="LIT4952History"></title>
        <note>Extends till <persName ref="PRS5616IyasuI"></persName></note>
    </msItem>
    <msItem xml:id="p1_i14.2" corresp="#h5">
        <title type="incomplete" ref="LIT4952History"></title>
        <note>Starting from <persName ref="PRS10303Yekunno"></persName> till
        <persName ref="PRS5616IyasuI"></persName> the text is written in another hand.
        </note>
    </msItem>
    <listRelation>
         <relation active="IVorlov20#UniProd1" name="sdc:undergoesTransformation" passive="IVorlov20#tr2"></relation>
         <relation active="IVorlov20#tr2" name="sdc:produces" passive="IVorlov20#UniProd3"></relation>
         <relation active="IVorlov20#tr2" name="sdc:resultsIn" passive="IVorlov20#UniCirc2"></relation>
         <relation active="IVorlov20#tr2" name="sdc:hasTransformationModel" passive="sdc:A2"></relation>
         <relation active="IVorlov20#UniProd3" name="skos:exactMatch" passive="IVorlov20#p1_i14.2"></relation>
         <relation active="IVorlov20#UniProd3" name="sdc:constituteUnit" passive="IVorlov20#UniCont5"></relation>
         <relation active="IVorlov20#UniProd3" name="sdc:constituteUnit" passive="IVorlov20#UniMain5"></relation>
    </listRelation>
</msItem>
                      

Example 2

The encoder had already structured the information about the content of the manuscript in a series of nested <msItem>s and the information given by the cataloguer is in a <note>. This would be already sufficient and serve well enough the users.

In this example, since we do not know the order in which the two additions of contents without material support of which the cataloguer and the encoder speak, occurred, I have not stated an explicit equation with the main identifier of the manuscript, as we would normally do, to say that the final UniCirc (circulation unit) corresponds to that final stage. This is to say that we know that the manuscript being described is the latest available unit of circulation, but we do not know in which relation it is with the units of circulation resulting from each transformation. We also do not know if the two additions in question are part of a same action, so we have to consider them distinct for the moment.

I made instead two statements about the resulting UniCirc with each addition, one of which can be seen in the example above at line 23. The URI of the manuscript, as well as the UniCirc2 and UniCirc1 URIs defined in these sets of triples will be all in the class of circulation units, but we are not stating which one come first and which one come after since we do not yet know. The numeric part of the UniCirc identifier has no sequential value and is totally arbitrary, although it should be of course unique. In the same way the UniProd anchors are set there and will become URIs in the RDF, but are here defined for the first time.

Now that most probably nothing of this made sense to you, go read the book (that is important!), then you can probably figure out much better who the ontology does not change much compared to that and you can use its values here.

Once you have an idea of the stratigraphy of your manuscript than it can most certainly be translated into a series of statements of the kind above and be formally described in this way.

In this case, the visualizations in the website are supposed to help you also in the process, by offering the table visualization and some graphs.

So, try it out! and if you are not sure, drop an issue in the repository and we will be all happy to help.

This page is referred to in the following pages

Revisions of this page

  • Pietro Maria Liuzzo on 2019-03-07: Example extraced from article for issue #35