Re: [Indic-texts] standards for Sky mss. markup

Picking up on Camillo’s offer, I have been meaning to compare the Sanskrit Library’s TEI catalogue entry structure with Epidoc for some time to see whether we could benefit from some of its standard tools. I would welcome discussion with you all about standards for Sanskrit mss. markup so that we can pool resources. On Wed, Oct 9, 2019 at 22:01 Camillo Formigatti < camillo.formigatti@bodleian.ox.ac.uk> wrote:

Dear all,

I completely agree with the remarks by Patrick, Daniel, and Peter – even when they are contradicting – and I'd like to give my two cents about this issue, possibly together with a broader consideration.

As Peter remarked, encoding choices should be met according to the purpose of the description and this is why we adopted a twofold approach. In short, we decided to describe the presence of a string hole both in <msContent> as well as in <physDesc>. Since we provided diplomatic transcriptions of some textual parts, we decided to encode as many features as possible, precisely for the reasons explained by Daniel. In this case, our approach was rather practical and we did not bother to try and find the most suitable element to encode the space for the string hole, we simply went for a <g> element, i.e. <g>%</g>. Our main purpose was just to represent graphically the position of the string hole in the online display of the diplomatic transcription. We used the % symbol consistently because we were thinking of possibly replacing all occurrences with a different encoding at a later time, after having agreed a shared approach with other colleagues. (We applied a similar reasoning in some other cases as well.)

We provided a proper description of the string hole within the <layoutDesc/> element. It goes without saying that we discussed for a long time whether to include this description within the <bindingDesc> element instead, which would be its natural place. However, we decided against this solution because of the fact that relatively often the space for a string hole has only a decorative function -- most notably in Jaina paper manuscripts, but occasionally also in other traditions, for instance in Nepalese and Tibetan manuscripts. This is the encoding for the description of a functional string hole in a palm-leaf manuscript:

<stringHole type="true" quantity="1"> One string hole.

<dimensions type="string hole spaces" scope="most" unit="cm">

<height quantity="2">2</height>

<width quantity="2.5">2.5</width>

</dimensions>

</stringHole>

Our suggested values for the @type are true, false, decorated. Please note that the clunky value "string hole spaces" was a forced choice, as the transformation sheet prepared by the IT colleagues in the CUL simply extracted the value for displaying in the online record. (This is also the reason of some other odd terminological choices we made for attribute values.) Our goal was to describe as many features of the layout as possible in order to be able to exploit them in a database, which unfortunately never materialized.

My general consideration is that if we want to suggest to the TEI board to add new elements to the TEI guidelines, I believe we ought to coordinate our efforts in a more systematic way. Most of us already use the Epidoc guidelines as reference, but in my opinion many discussions on this list have demonstrated that we need to take more coordinated decisions. I suggest therefore that we try and meet regularly to create a tool similar to the Epidoc guidelines. I don't know how many of you know the Fihrist catalogue https://www.fihrist.org.uk/about, sometimes I attended their board meetings and even with all the complications of the case, their centralized way of controlling the cataloguing standard is proving efficient and resilient. I've talked with my line manager in the Bodleian, suggesting that we organize a first meeting of a TEI Indic Texts Group in Oxford and she welcomed the idea warmly – we were even talking about how to raise some funds for it. In the beginning, we may host a yearly meeting and adopt a rotating pattern to choose the hosting institution. It's just an idea I'm throwing in the list, but I believe that in this way we would be able to coordinate our efforts much more efficiently.

Best wishes,

Camillo

------------------------------

Dr Camillo A. Formigatti

John Clay Sanskrit Librarian

Bodleian Libraries

The Weston Library

Broad Street, Oxford

OX1 3BG

Email: camillo.formigatti@bodleian.ox.ac.uk

Tel. (office): 01865 (2)77208 www.bodleian.ox.ac.uk

*GROW YOUR MIND*

in Oxford University’s

Gardens, Libraries and Museums

www.mindgrowing.org

*From:* Indic-texts *On Behalf Of *Peter Scharf *Sent:* 09 October 2019 10:41 *To:* Dániel Balogh *Cc:* indic-texts@lists.tei-c.org *Subject:* Re: [Indic-texts] string holes

Dear All,

With the concession that encoding should always be balanced against envisioned purposes or possible purposes, I fully agree with Daniel’s remarks. So if one envisions the possibility that the encoding will be used for a diplomatic edition, by all means use the space with binding-hole type. Certainly spaces in mss. or inscriptions that normally have continuous text would desire a space element where an unusual interword space is found.

Thanks for the list of space element type values

Yours,

Peter

******************************

Peter M. Scharf, President

The Sanskrit Library

scharf@sanskritlibrary.org

https://sanskritlibrary.org

******************************

On 9 Oct 2019, at 1:44 PM, Dániel Balogh wrote:

Hello again,

I agree with Peter Scharf that details of binding holes belong in the MS description. I do, however, think that encoding the actual position of binding holes vis-à-vis the text may be relevant for diplomatic editions; for instance they are occasionally the reason behind unusual sandhi or eyeskip, and even when they are not, it could be argued that they ought to be represented for the sake of accuracy. Further, I do not share Patrick's concern with TEI definitions. I am of course aware that the original purpose for which the <space/> element was introduced was to represent spaces left blank for subsequent filling but ultimately not filled for some reason or another. However, the base definition in the guidelines is "a significant space in the text", which leaves us much more freedom to use the element for another purpose; and the definition in the element description page says space is to be "used wherever it is desired to record an unusual space in the source text, e.g. space left for a word to be filled in later, for later rubrication, etc." The initial part of this phrase is very permissive, and the "etc." at the end, in my view, explicitly invites additional uses for <space/>.

Finally, I should point out that those of us who use EpiDoc (and I guess this must be true for users of other TEI flavours as well) are already well used to co-opting certain TEI elements and attributes for purposes that were not intended by the authors of TEI. For instance, would any of you object to using <space/> to encode an interword space in an Indic epigraph or manuscript that normally uses scripto continua? TEI guidelines explicitly say <space/> "is not intended to be used to mark normal inter-word space or the like" - but don't we all agree that such spaces are not "normal inter-word space" and definitely qualify as "significant space"?

For your information, the DHARMA Encoding guide (currently an unfinished draft; it will be public when the first release version is finalised) at the moment uses the following values for @type in <space/>:

vacat - for the classical case of space left blank for later filling

defect - left blank because of a defect in the surface

binding-hole - as agreed here

descender - space skipped because of a low-hanging character in the line above

ascender - skipped because of a high-rising character in the line below (added for symmetry, but these will be very rare)

without type: all other significant spaces, e.g. spacing of words, stanzas or smaller verse components, or semantic units of the text.

The very best,

Daniel

On Wed, 9 Oct 2019 at 07:59, Peter Scharf wrote:

Dear all,

We did not use a space element to indicate space for a binding hole because of exactly the considerations that Patrick just pointed out. We describe the binding in the binding element once for the whole ms. There is no need to repeat it everywhere a binding hole separates some continuous text.

Yours,

Peter

******************************

Peter M. Scharf, President

The Sanskrit Library

scharf@sanskritlibrary.org

https://sanskritlibrary.org

******************************

On 9 Oct 2019, at 1:51 AM, Patrick McAllister wrote:

Dear list members,

tei:space is syntactically not quite what you want there, I think. While its short description is simply that it “indicates the location of a significant space in the text”, if you look further in the Guidelines (https://tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHSP) you’ll find that they say:

“The author or scribe may have left space for a word, or for an initial capital, and for some reason the word or capital was never supplied and the space left empty. The presence of significant space in the text being transcribed may be indicated by the space element.”

To me this means that “tei:space” should be used for those spaces where some text is missing. That’s not the case for the binding holes and their surrounding spaces. They are like margins in bound volumes: they were left empty because the (later?) binding would have made anything written there hard to read. That said, I’m also using tei:space with @type="binding-hole" at the moment.

I like the idea of proposing a dedicated element that can be used for this kind of thing. What attributes do you currently use when you use tei:space for binding holes? I suppose indicating the type of binding could be useful, and perhaps some way of indicating the shape and dimension of the hole and the space surrounding it. Might be interesting to search by types/peculiarities of binding holes.

All the best,

On Tue, Oct 08 2019, Dániel Balogh wrote:

Dear All, binding-hole it is then. But I'm also curious to hear further details from Camillo. Best, Daniel

On Tue, 8 Oct 2019 at 07:36, Arlo Griffiths wrote:

The use of <space type="binding-hole"/> is also used in EIAD. The term binding-hole is sufficiently broad to be applicable both to inscriptions and to manuscripts. I recommend keeping it in lieu of simply <space type="hole"/> because anyone may forget at any time that there is also <space type="defect">, and so, in my view, <space type="hole"/> is too ambiguous.

Best wishes,

Arlo

Le 7 oct. 2019 à 19:44, Dániel Balogh a écrit :

Dear Peter and Andrew, the current draft of the DHARMA encoding guide says <space type="hole"> which is also the way I handled copperplate binding holes in the Siddham corpus. I prefer the simpler "hole" to the more cumbersome "binding-hole" but if you, Andrew, have already used "binding-hole" a lot and would prefer this more accurate term, please convince me to adopt it for use in DHARMA. (Fyi, I our guide prescribes <space type="defect"> for all spaces left blank due to physical defects in the surface, so "hole" is not in my opinion ambiguous.) Best, Dan

On Mon, 7 Oct 2019 at 19:14, Andrew Ollett wrote:

I use <space type="binding-hole"/>. I am not sure what the current recommendation in major projects (e.g. DHARMA).

On Mon, Oct 7, 2019 at 12:12 PM Peter Mukunda Pasedach < peter.pasedach@googlemail.com> wrote:

Dear all,

how do you represent string holes in TEI transcripts of palm-leaf manuscripts?

Best,

Peter _______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

_______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

_______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

_______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

_______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

-- Patrick McAllister long-term email: pma@rdorte.org _______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

_______________________________________________ Indic-texts mailing list Indic-texts@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/indic-texts

-- ***************************************** Peter M. Scharf, President The Sanskrit Library sanskritlibrary.org http://www.sanskritlibrary.org *****************************************