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 cataloguehttps://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.ukmailto:camillo.formigatti@bodleian.ox.ac.uk
Tel. (office): 01865 (2)77208
www.bodleian.ox.ac.ukhttp://www.bodleian.ox.ac.uk/
GROW YOUR MIND
in Oxford University’s
Gardens, Libraries and Museums
www.mindgrowing.orghttp://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.orgmailto:scharf@sanskritlibrary.org
https://sanskritlibrary.org
******************************
On 9 Oct 2019, at 1:44 PM, Dániel Balogh mailto:danbalogh@gmail.com> 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 mailto:scharf@sanskritlibrary.org> 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.orgmailto:scharf@sanskritlibrary.org
https://sanskritlibrary.orghttps://sanskritlibrary.org/
******************************
On 9 Oct 2019, at 1:51 AM, Patrick McAllister mailto:pma@rdorte.org> 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 mailto:arlo.griffiths@efeo.net> 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 mailto:danbalogh@gmail.com> 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 mailto:andrew.ollett@gmail.com>
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.commailto: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.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto: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.orgmailto:Indic-texts@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts
--
Patrick McAllister
long-term email: pma@rdorte.orgmailto:pma@rdorte.org
_______________________________________________
Indic-texts mailing list
Indic-texts@lists.tei-c.orgmailto: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.orgmailto:Indic-texts@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts
