- Indic-texts - lists.tei-c.org

string holes
by Peter Mukunda Pasedach 09 Oct '19

09 Oct '19

Dear all, how do you represent string holes in TEI transcripts of palm-leaf manuscripts? Best, Peter

7 13

TEI Conference Graz, September 2019?
by Patrick McAllister 12 Jun '19

12 Jun '19

Dear list members, a question: is anyone going to the TEI 2019 meeting/conference? Please let me know if you’re planning to come, I’d set up a meeting of our Indic-Texts SIG. See https://graz-2019.tei-c.org/ for details on the conference. With best wishes, -- Patrick McAllister long-term email: pma(a)rdorte.org

1 0

Prakrit lexicons
by Andrew Ollett 10 Jun '19

10 Jun '19

Dear all, I was inspired by Dr. Dhaval Patel's recent efforts to make digital versions of important Sanskrit lexicons available ( https://github.com/sanskrit-kosha/kosha) to do something similar for the two Prakrit lexicons that I have had on my computer for a while: https://github.com/aso2101/prakrit_lexicons This includes Dhanapāla’s Pāiyalacchī (in plain text form) and Hēmacandra’s Dēśīnāmamālā (in TEI form). I had planned to publish them only when I had created dictionary data from each, but others will be able to do this more expeditiously than I would be. (The TEI data for Hēmacandra should make the extraction of lemmata and definitions relatively straightforward.) Any feedback would be greatly appreciately. Andrew

3 2

indic-texts back in service
by Andrew Ollett 22 May '19

22 May '19

Dear Indic-texts subcribers, The mailing list for this SIG was down for a while, but the TEI has informed us that it should be back up again. Apologies for the inconvenience. Andrew

2 1

Sanskrit names for division types
by Patrick McAllister 03 Nov '18

03 Nov '18

Dear list members, I’m currently thinking about the encoding of sections (mainly tei:div elements) for the documents in the SARIT collection. Many of those documents are outside my field of expertise, and so I’m having a hard time with this. We have quite a large variety of section @types that either directly use Sanskrit terminology or use terminology that might (IMO) be based on it. They are: adhikaraṇa adhikāra adhyāya canto closing commentary commentary1 commentary2 conclusion kārika kārikā pariccheda prakāśa pāda samuddeśa sutra sūtra sūtra_with_bhāṣya It’s obviously a bit of a mess. I was wondering if anyone has a principled approach to these naming schemes in general? I at least have only very limited knowledge of the traditional sectioning of texts in Sanskrit literature as a whole, and am not sure what the aim should be here. Currently the SARIT guidelines (https://github.com/sarit/SARIT-corpus/blob/a355567b5bc61032e1d7fa39392f5e06…) are rather cautious about the usage of these terms: ###### Sections of the text ════════════════════ There are many Sanskrit words for sections of a text: sarga, adhyāya, aṅka, pariccheda, ucchvāsa, etc. The encoding of these sections should meet several requirements: • the XML document itself should be valid; • the structure of the XML document reflects the logical structure of the text; • a standard reference system should be able to use the structure of the XML document as a proxy for the structure of the text; • texts in the corpus are broadly consistent in the encoding strategy used for these sections. These considerations lead us to recommend the use of div for all "parts," "sections," and "divisions" in the text, whatever their Sanskrit name is, and at whatever depth they occur. Do /not/ use the numbered divisions available in earlier versions of the TEI Guidelines (`<div1 xmlns="http://www.tei-c.org/ns/Examples"/>', `<div2 xmlns="http://www.tei-c.org/ns/Examples"/>', etc.). Before encoding a text, you should figure out a strategy for representing all of the relevant levels of the text as div elements. Some Mīmāṃsā texts, for example, are organized according to the hierarchical organization of the Mīmāṃsā Sūtras into adhyāyas, pādas, and adhikaraṇas. The first div beneath the body element (body/div) will thus correspond to an adhyāya, the first div below this to a pāda (body/div/div), and the first div below this (body/div/div/div) to an adhikaraṇa. If this schema is applied consistently, there is no need for assigning a type to the div elements themselves (e.g., `<div xmlns="http://www.tei-c.org/ns/Examples" type="adhyāya"/>', `<div xmlns="http://www.tei-c.org/ns/Examples" type="pāda"/>', `<div xmlns="http://www.tei-c.org/ns/Examples" type="adhikaraṇa"/>'), but these type attributes may be included in order to make the XML easier to read. The strategy followed in the text can be, and should be, documented in the reference declaration (refsDecl), which is part of the encoding description (encodingDesc) in the TEI Header (see above). 1 Labelling sections ──────────────────── Sections of the text should be /identifiable/. In order to be identifiable to humans, sections generally carry a heading and/or a trailer (see below). In order to be identifiable to machines, sections carry a numeric /label/ that is represented by the n attribute of the corresponding div element. The value of n will usually be the serial number of the section: `<div xmlns="http://www.tei-c.org/ns/Examples" n="2"/>' represents the second division (adhyāya, pāda, adhikaraṇa, etc.), even if it's not actually the second div element within its parent element. For division that comprises more than one such section, we simply put all of the corresponding numbers in the n attribute: `<div xmlns="http://www.tei-c.org/ns/Examples" n="2 3 4"/>'. Divisions (divs) are block-level elements, and they constitute the text hierarchy, together with other block-level elements like paragraphs (p), verses (lg), and the “anonymous blocks” used for sūtras and the like (ab). The overall reference system of the text will therefore usually include the numbering of div elements at the upper levels and the numbering of lg or ab elements at the lower levels. ###### I can at least say that for most practical purposes the @type on the div is ignored, at the moment: the level of any given div is inferred from the number of parent div-s, and the typesetting/display on the various platforms of SARIT depends on several factors about a div’s content rather than on the @type. But my question is more theoretical: should we generally encourage the use of Sanskrit technical terms for types of a text’s division or not? And if you think we should encourage them, would it make sense (or even be possible) to somehow specify guidelines for their usage that would apply to many texts? In SARIT at least, there are some cases where we decided against the use of Sanskrit terms, mainly because their meaning is actually not so clear, e.g., in the markup of tei:quote with @type="lemma" instead of something like @type="pratīka". Hoping for some help, -- Patrick McAllister long-term email: pma(a)rdorte.org

5 6

question about transformation scheme
by Arlo Griffiths 01 Oct '18

01 Oct '18

Dear colleagues, I wish to read the text in the attached xml file with students in Paris this Thursday, and I need to be able to do so in an at least moderately reader-friendly manner. I have tried the TEI P5 XHTLM transformation scheme built into Oxygen and get the result also attached. I don’t understand why none of the @resp and @source values get picked up in the apparatus, why the value of @wit gets printed in bold only in note 8 (lemma samatā), and why note numbers are created in the text but not in the apparatus. It would also be nice if @type values on <lem> and <rdg> (‘em’ and ‘norm’) were displayed in the apparatus, but since these are user-specific I realize I won’t be able to use a prefabricated scheme for this. Would you be able to recommend (and/or share) a scheme that would do better at displaying this xml code, or that would do well as displaying it if I made some small modifications to the xml code? Unfortunately I am still xslt-illiterate, so unable to create a usable scheme of my own. Thanks for your help. Best wishes, Arlo Griffiths

3 2

encoding pratīkas in commentary
by Arlo Griffiths 24 Sep '18

24 Sep '18

Dear colleagues, I am trying to encode a text from Bali built up around Sanskrit stanzas, which are followed by Old Javanese glosses. The glosses themselves are interspersed with Sanskrit elements, generally (but not always) chunks from the root text. Here’s an example from e-text that’s going to be TEI encoded. <KMN21s-ab> na te 'tra vimatiḥ kāryā nirviśaṅkena cetasā <KMN21s-cd> prakāśaya mahātulaṁ mantracaryānayam param ||21|| c. Speijer notes that the reading mahātulaṁ is unmetrical. <KMN21j> ka: hayva kita vicikitsa, NIRVIŚAṄKENA CETASĀ, ikaṅ nissandeha atah ambĕka[ka]nta, PRAKĀŚAYA MAHĀTULAṀ [msA-a17] MANTRACĀRYYANAYAM PARAṀ, at pintonakna ike, saṅ hyaṅ mantranaya mahāyāna. How would you propose to encode a chunk like NIRVIŚAṄKENA CETASĀ? Options I have thought of (with Andrew Ollett) are: (1) <quote type="pratīka">nirviśaṅkena cetasā<quote> (2) <term>nirviśaṅkena cetasā<term> In the second solution, I could also add <gloss> to the string ikaṅ nissandeha atah ambĕka[ka]nta. But I am hoping that this is not mandatory. Neither of the two solutions immediately helps if I wanted to have a mechnism that links the pratīka with the corresponding words in the mūla. Very similar if not identical phenomena also need to be encoded in Indian texts, so it would probably be useful to come of with a collective recommendation. Looking forward to receiving your suggestions. Arlo Griffiths

4 3

UML Diagrams for msIdentifier
by Amir Simantov 17 Aug '18

17 Aug '18

Hello. I am looking for either a UML class diagram or an object relation diagram (ORD) of either: 1. The "Manuscript Description" http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html Or, at least, to: 2. "The Manuscript Identifier" section inside it http://www.tei-c.org/release/doc/tei-p5-doc/en/html/MS.html#msid Can anybody help here? Thanks, Amir (Pandit Project webmaster0

2 2

Re: [Indic-texts] Pandit Project - Behavior change - Extract entity type
by Dominik Wujastyk 29 Jun '18

29 Jun '18

Thank you very much for this update, and for your continued work on this wonderful tool. Dominik -- Professor Dominik Wujastyk <http://ualberta.academia.edu/DominikWujastyk> , Singhmar Chair in Classical Indian Society and Polity , Department of History and Classics <http://historyandclassics.ualberta.ca/> , University of Alberta, Canada . South Asia at the U of A: sas.ualberta.ca On Thu, 28 Jun 2018 at 11:58, Amir Simantov <wawina(a)gmail.com> wrote: > Dear contributors, > > I write to you all as you are the active manuscript extracts contributors. > > The first months of your hard work helped us understand how we can improve > the behavior of the data entering. No need spotted for structure changes, > though. > > The behavior changes are: > > 1. You can add more than one extract of each kind for a manuscript. > The prompting link to add a new extract from within a manuscript is one: > "Add an extract". > 2. You can change the extract kind after creation. No need to > unpublish an extract and add another one instead. Thanks Jonathan Peterson > who helped us understand that this change is needed. > 3. You can add an extract for a manuscript that is *not* related to a > specific work. Use it when the extract text is manuscript-specific and not > to a work that is written in the manuscript. Thanks to Dominik Wujastyk for > his advice on this issue. > 4. You have to choose the work from the select list in the editing > form of the extract entity. If the extract is not specific for one work > then tick the checkbox "Not work-specific". > > Note there is no need to edit and change existing extracts; this email is > just to share with you what we did. > > Please report on any behavior you suspect to be a bug! > > We may also improve the *presentation* of the extracts in the manuscript > page if we get creative input on it from you :) > > Thanks, > Amir > (Pandit programmer) >

1 0

Google OCR for Sanskrit
by Andrew Ollett 17 Jun '18

17 Jun '18

Dear colleagues, After noticing results in Google Books from Dēvanāgarī editions of Sanskrit texts, I suspected that Google had some OCR technology for Dēvanāgarī. It turns out that they have had it for some time, but only relatively recently has an API been available to use it. Here is a comparison of Google OCR with Oliver Hellwig's SanskritOCR: https://sanskrit-coders.github.io/site/posts/ocr-comparison.html I think the conclusion is that SanskritOCR is slightly better in terms of quality, but Google OCR is faster and easier to use programmatically. I have tried out Google OCR and managed to get relatively good results: http://www.prakrit.info/blog/google-ocr-for-sanskrit/ I think this could be quite promising. If we manage to write a couple of tools for processing PDFs into txt files (and thence onto TEI if desired), then we could go from scanned document to machine-readable text in minutes. Of course things would need to be checked, and Google OCR seems to have particularly nasty problems with notes and smaller size text. My setup is a few local Python scripts that interact with the resources in a Google Cloud Storage "bucket" (where they need to be in order for Google OCR to work). Maybe others could come up with a more streamlined setup. Or maybe we could even create an app that allows users to upload PDF documents and get text data in return. Thoughts? Andrew

2 1