TEI |

persNamer 1.2: एक VIAF नंबर, नौ प्रामाणिक नाम-सूचियाँ

Mon, 07 Sep 2026 00:00:00 +0000

शुरू में एक छोटी-सी सुविधा भर था: VIAF नंबर दीजिए, TEI की एक <person> प्रविष्टि पाइए, साथ में पाठ में लगाने के लिए <persName> टैग। बस इतना ही — और जो प्रविष्टि बनती थी वह भी दुबली-पतली: एक नाम, दो तिथियाँ, एक पहचानकर्ता। आज जारी हुआ संस्करण 1.2 अब भी वही एक काम करता है, पर इस बार जो प्रविष्टि निकलती है वह सँभालकर रखने लायक है।

व्यक्ति-प्रविष्टि में अब क्या-क्या है

पहले नाम की बात। VIAF के क्लस्टर में हर सहयोगी पुस्तकालय अपना-अपना नाम-रूप लेकर आता है, और पुराना persNamer जो लेबल पहले हाथ लगे वही उठा लेता था। उससे वोल्तेयर (Voltaire) के बारे में पूछिए तो जवाब मिलता « فولتير، » — यानी नाम का अरबी रूप, और वह भी पीछे लटके अल्पविराम सहित — ऊपर से एक खाली xml:id मुफ़्त में। अब औज़ार पूरे क्लस्टर में नाम-रूपों की गिनती करके वही रखता है जिस पर स्रोत रिकॉर्ड एकमत हों; बाक़ी रूप <persName type="variant"> बनकर पीछे-पीछे आते हैं, जो सबसे प्रचलित हो वह सबसे आगे। तिथियाँ मानकीकृत होकर (1572-08-00 से 1572-08) दो बार दर्ज होती हैं — एक बार पाठ के रूप में, एक बार @when विशेषता में — और तिथियाँ समझने वाली कोई भी प्रोसेसिंग असल में इसी दूसरी को पढ़ती है। लिंग और विवरण भी आते हैं, जहाँ VIAF उन्हें देता है।

और अब वह हिस्सा जिसका मुझे सबसे ज़्यादा इंतज़ार था। VIAF जिस-जिस पहचानकर्ता को इस व्यक्ति से जोड़ता है — चाहे schema:sameAs के ज़रिए, चाहे अपने स्रोत-आईडी के ज़रिए — वह सब अब अलग-अलग <idno> में दर्ज हो जाता है: BnF, GND, लाइब्रेरी ऑफ़ कांग्रेस, SUDOC, Wikidata, ISNI, BNE, LIBRIS, NDL। एक नंबर अंदर गया, नौ कैटलॉग बाहर आए। किसी व्यक्ति-सूची (personography) के लिए नामों की कोरी फ़ेहरिस्त और प्रामाणिक डेटा के जाल की एक गाँठ में जो फ़र्क़ है, वह यही है।

<person xml:id="pers-teligny-c">
 <persName>Charles de Téligny</persName>
 <birth when="1535">1535</birth>
 <death when="1572-08-24">1572-08-24</death>
 <sex value="M">M</sex>
 <idno type="VIAF">314802260</idno>
 <idno type="BNF">16133360</idno>
 <idno type="Wikidata">Q1868249</idno>
 <idno type="ISNI">0000000071126808</idno>
</person>

टुकड़ों से व्यक्ति-सूची तक

एक आदमी के लिए टर्मिनल पर XML छाप लेना ठीक है; पर एक संपादित ग्रंथ में तो सैकड़ों लोग होते हैं। इसलिए persNamer अब एक साथ कई VIAF नंबर लेता है, दो अनुरोधों के बीच VIAF को साँस लेने की मोहलत देता है, जो कुछ लाया है उसे कैश में रख लेता है ताकि दोबारा न माँगना पड़े, और --merge मिलते ही नई प्रविष्टियाँ सीधे मौजूदा TEI फ़ाइल के <listPerson> में बिठा देता है। जो लोग फ़ाइल में पहले से हैं, वे अपने VIAF नंबर से पहचान लिए जाते हैं और उनका xml:id ज्यों का त्यों रहता है; नए आईडी फ़ाइल से मिलाए जाते हैं और कहीं टकराव हो तो पीछे प्रत्यय (-2, -3) लग जाता है; अंत में पूरी फ़ाइल के इंडेंट फिर से सँवार दिए जाते हैं — हाँ, उससे पहले एक .bak प्रति अलग रख ली जाती है।

persnamer --merge edition.xml 314802260 36925746

एक बदलाव ज़रूर ध्यान में रखिए: कुलनाम से पहले आने वाला कण (particle) अब डिफ़ॉल्ट रूप से आईडी में नहीं रहता, इसलिए Charles de Téligny पहले के pers-deteligny-c की जगह अब pers-teligny-c हो गया है। आपकी परियोजना पुराने रूप की आदी हो चुकी हो तो --keep-particle उसे वापस ले आता है; और नामों के भरोसे रहना ही न हो तो --id-format viaf से pers-viaf-314802260 मिल जाता है।

साफ़-सफ़ाई

स्क्रिप्ट अब बाक़ायदा एक पैकेज बन गई है, अपनी persnamer कमांड के साथ: uv tool install या pipx से एक लाइन में इंस्टॉल कीजिए, या बिना इंस्टॉल किए बस एक बार आज़माना हो तो uvx से चला लीजिए। छब्बीस टेस्ट VIAF की रिकॉर्ड की हुई प्रतिक्रियाओं पर चलते हैं, इसलिए टेस्ट-सूट को नेटवर्क की कोई ज़रूरत नहीं; CI उन्हीं को Python 3.9 से 3.13 तक दोहराता है, और आउटपुट TEI P5 के मुताबिक़ जाँचा जाता है। लाइसेंस पहले की तरह Apache 2.0 ही है।

जो यह अब भी नहीं बता सकता, वह है कि कोई कहाँ पैदा हुआ और रोज़ी-रोटी के लिए क्या करता था: VIAF के क्लस्टर RDF में न जगहें हैं, न पेशे। पर जिन BnF और GND रिकॉर्डों से यह जुड़ा है, उनमें दोनों हैं — और उनके नंबर अब आपके हाथ में हैं।

कोड और दस्तावेज़ पर।

tei-mcp v0.3: स्रोत को दोबारा लिखे बिना TEI एनकोडिंग

Tue, 05 May 2026 00:00:00 +0000

जब मैंने , तो मक़सद था एआई असिस्टेंटों को TEI मार्कअप गढ़ने से रोकना। स्कीमा-आधार ने समस्या का एक हिस्सा सुलझा दिया: P5 विनिर्देश तक सीधी, उपकरण-आधारित पहुँच मिल जाने पर मॉडल को अब यह अनुमान नहीं लगाना पड़ता कि किसी एलिमेंट का मतलब क्या है या वह कौन-से एट्रिब्यूट स्वीकार करता है। आउटपुट वैध निकलता है।

लेकिन TEI एनकोडिंग में मतिभ्रम के दो चेहरे हैं, और स्कीमा उनमें से सिर्फ़ एक को पकड़ती है। विनिर्देश पर परखने से इतना पता चलता है कि मार्कअप सही बना है। उस पाठ के बारे में यह कुछ नहीं कहती, जिसे वह मार्कअप लपेटे हुए है। और यहीं – पाठ में ही – ज़्यादा घातक मतिभ्रम बसते हैं। v0.3 की प्रमुख सुविधा, स्पैन-लॉक्ड कंपोज़िशन, ख़ास तौर पर इन्हीं को रोकने के लिए बनाई गई है।

सामग्री तालिका

वह मतिभ्रम जिसे स्कीमा नहीं पकड़ सकती

किसी मॉडल से सोलहवीं सदी का एक फ़्रांसीसी पत्र एनकोड करने को कहिए, और अक्सर आपको एक ऐसा TEI दस्तावेज़ मिलेगा जो देखने में बेदाग़ लगेगा। हेडर भरा हुआ है, <persName> टैग सही जगह पर हैं, <dateline> ठीक बना है। उसे validate_document से गुज़ारिए, और वह पास हो जाता है।

फिर उसके मूल पाठ का स्रोत से मिलान कीजिए।

mesme बनकर même हो गया है। एक अल्पविराम अपनी जगह से खिसक गया है। luy चुपचाप आधुनिक होकर lui बन गया है। पांडुलिपि में जो वाक्यांश पढ़ने में कठिन था, उसे “सुधारकर” कुछ ज़्यादा साफ़-सुथरा बना दिया गया है। इनमें से कोई बदलाव माँगा नहीं गया था। कोई चिह्नित नहीं है। दस्तावेज़ स्कीमा के हिसाब से वैध है, और चुपचाप ग़लत।

अभिलेखीय वर्कफ़्लो में – जहाँ एनकोड किया गया पाठ वह स्थायी अभिलेख बन जाता है जिस पर आगे के पाठक, खोज-अनुक्रमणिकाएँ और उद्धरण टिके होते हैं – यही वह विफलता है जो सबसे ज़्यादा मायने रखती है। एक बिगड़ा हुआ टैग खीज पैदा करता है। एक आधुनिक की गई वर्तनी, जिस पर पाँच साल तक किसी की नज़र न पड़े, पाठ का भ्रष्ट हो जाना है।

स्पैन-लॉक्ड कंपोज़िशन

नया रिलीज़ (v0.3) मतिभ्रम रोकने की एक ऐसी व्यवस्था लेकर आया है, जिसका निशाना ठीक यही विफलता है। डिज़ाइन का लक्ष्य: मूल पाठ के मतिभ्रम को केवल असंभाव्य नहीं, बल्कि बनावट से ही असंभव बना देना।

विचार सीधा-सा है: मॉडल मूल पाठ कभी टाइप नहीं करता।

इसके बजाय वर्कफ़्लो यों चलता है:

मॉडल get_source("letter_001") बुलाता है और उसे स्रोत का सादा पाठ एक अपरिवर्तनीय स्ट्रिंग के रूप में मिलता है।
जो भी टैग वह लगाना चाहता है, उसके लिए वह tag_span("letter_001", start, end, element_path, attrs) बुलाता है – यानी स्रोत की एक वर्ण-सीमा पर एक TEI एलिमेंट दर्ज करता है।
काम पूरा होने पर वह compose("letter_001") बुलाता है। सर्वर दर्ज किए गए टैगों को मूल सादे पाठ में पिरोता है, अंतिम TEI तैयार करता है, और फिर बाइट-दर-बाइट जाँचता है कि तैयार दस्तावेज़ का सपाट पाठ स्रोत के बराबर है या नहीं।

बाइट मिल गए, तो दस्तावेज़ लौट आता है। नहीं मिले – अगर मॉडल के टैगों से किसी तरह ऐसा मूल पाठ निकलता है जो स्रोत से एक भी वर्ण में भिन्न हो – तो compose() भ्रष्ट दस्तावेज़ लौटाने के बजाय त्रुटि उठा देता है।

इस वर्कफ़्लो में कोई ऐसा रास्ता नहीं जिससे मॉडल एक ऐसा TEI दस्तावेज़ बना सके जिसका मूल पाठ स्रोत से भिन्न हो। यह अपरिवर्तनीय शर्त यांत्रिक है, व्यवहार पर टिकी नहीं। आपको यह भरोसा नहीं करना कि मॉडल मतिभ्रम नहीं करेगा; आपको बस दो बाइट-स्ट्रिंगों के बीच एक == जाँच पर भरोसा करना है।

यह क्या है, और क्या नहीं

स्पैन-लॉक्ड कंपोज़िशन स्कीमा-आधार की पूरक है, उसका विकल्प नहीं। स्कीमा-आधार के उपकरण (validate_document, lookup_element, valid_children और मूल सोलह में से बाक़ी) मॉडल को वैध TEI बनाने में मदद करते हैं। स्पैन-लॉक्ड कंपोज़िशन इसकी गारंटी देती है कि उस TEI के भीतर का मूल पाठ स्रोत के प्रति वफ़ादार है। काम में लाने लायक़ एनकोडिंग वर्कफ़्लो को दोनों कसौटियों पर खरा उतरना होता है, और अब दोनों एक ही सर्वर से सधती हैं।

यह हर मर्ज़ की दवा भी नहीं है। compose() अभी यह नहीं जाँचता कि दर्ज किए गए टैग किसी लोड किए गए ODD अनुकूलन के अनुसार स्वीकार्य हैं या नहीं – यह अगला क़दम है। दर्ज किए गए टैग प्रोसेस की मेमोरी में रहते हैं और रीस्टार्ट के बाद नहीं बचते। और स्रोत फ़ाइलें वहाँ से पढ़ने योग्य होनी चाहिए जहाँ सर्वर चल रहा है। ये सब सुलझाए जा सकते हैं; इनमें से कोई भी मूल अपरिवर्तनीय शर्त को कमज़ोर नहीं करता।

TEI से आगे यह क्यों मायने रखता है

यह पैटर्न सामान्यीकृत होता है। जब भी किसी मॉडल से किसी पाठ पर टिप्पणी करने, उसे रूपांतरित करने या लपेटने को कहा जाए – और जब भी मूल पाठ की अखंडता मॉडल की “सुधारने” की क्षमता से ज़्यादा मायने रखे – तो इसी आकार का समाधान लागू होता है। मॉडल से पाठ दोबारा टाइप करने को मत कहिए। उससे पाठ पर निर्देश बनवाइए, और एक नियतात्मक कंपोज़र को समानता की अपरिवर्तनीय शर्त के तहत उन्हें लागू करने दीजिए।

ख़ास तौर पर डिजिटल संस्करणों के लिए इससे यह बदल जाता है कि आप ज़िम्मेदारी के साथ किसी मॉडल से क्या करवा सकते हैं। एनकोडिंग अचानक ऐसा काम बन जाती है जिसे आप हर आउटपुट का स्रोत से हाथ से मिलान किए बिना सौंप सकते हैं। मशीन उबाऊ रास्ता चलती है; संपादक मार्कअप की समीक्षा करता है, वर्तनी की नहीं।

अपडेट कैसे पाएँ

अगर tei-mcp पहले से इंस्टॉल है:

uvx tei-mcp@latest

या नए सिरे से:

pip install tei-mcp

स्पैन-लॉक्ड कंपोज़िशन इस्तेमाल करने के लिए सर्वर को स्रोत की सादा-पाठ फ़ाइलों की किसी डायरेक्टरी की ओर मोड़िए:

export TEI_MCP_SPAN_SOURCE_ROOT=/path/to/sources
uvx tei-mcp

हर फ़ाइल का मूल नाम उसका दस्तावेज़ ID बन जाता है (letter_001.txt → letter_001)।

स्रोत कोड, पूरा दस्तावेज़ीकरण और अपरिवर्तनीय शर्त के डिज़ाइन-नोट:

tei-mcp

Sun, 15 Mar 2026 00:00:00 +0000

tei-mcp: एआई एजेंटों के लिए TEI P5

tei-mcp एक ओपन-सोर्स सर्वर है, जो एआई कोडिंग असिस्टेंटों को विनिर्देश तक सीधी पहुँच देता है। प्रशिक्षण-डेटा की धुँधली याद के भरोसे रहने के बजाय – जिससे अक्सर देखने में ठीक-ठाक पर ग़लत मार्कअप निकलता है – एआई विनिर्देश से सीधे, उसी वक़्त पूछ सकता है।

विशेषताएँ

सर्वर TEI P5 के ODD को पार्स करता है और 16 उपकरण उपलब्ध कराता है:

किसी भी एलिमेंट, क्लास, मैक्रो या मॉड्यूल की खोज नाम से – बड़े-छोटे अक्षर का भेद किए बिना, और टाइपिंग की ग़लती पर सुझाव के साथ
पूरी TEI क्लास-श्रेणी में एट्रिब्यूट का निर्धारण (स्थानीय + विरासत में मिले)
क्लास और मैक्रो को खोलते हुए कंटेंट मॉडल का विस्तार संरचित वृक्ष के रूप में
नेस्टिंग की जाँच – सीधा अभिभावक-संतान संबंध या पथ के साथ पुनरावर्ती पहुँच
TEI P5 के विरुद्ध दस्तावेज़ की वैधता-जाँच: कंटेंट मॉडल, एट्रिब्यूट, बंद मान-सूचियाँ, संदर्भों की अखंडता और अप्रचलन की चेतावनियाँ
क्रमिक संपादन के लिए एकल एलिमेंट की वैधता-जाँच
स्कीमा को किसी परियोजना-विशेष उपसमुच्चय तक सीमित करने के लिए ODD अनुकूलन लोड करना
रेगुलर एक्सप्रेशन से सभी प्रकार की इकाइयों में खोज

इंस्टॉलेशन

pip install tei-mcp

या सीधे चलाइए:

uvx tei-mcp

उपयोग

किसी भी MCP-संगत क्लाइंट (Claude, Cursor, Windsurf आदि) में जोड़िए:

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

स्रोत कोड और दस्तावेज़ीकरण पर उपलब्ध हैं।

tei-mcp: एआई एजेंटों के लिए TEI P5

Sun, 15 Mar 2026 00:00:00 +0000

अगर आपने कभी किसी एआई कोडिंग असिस्टेंट से TEI XML लिखवाया है, तो ग़ौर किया होगा कि वह गड़बड़ कर बैठता है। एलिमेंट वहाँ आ जाते हैं जहाँ उन्हें नहीं होना चाहिए। एट्रिब्यूट गढ़ लिए जाते हैं। नेस्टिंग के नियम अनदेखे रह जाते हैं। मॉडल को मोटा-मोटी अंदाज़ा है कि TEI कैसी दिखती है, पर विनिर्देश का कोई भरोसेमंद ज्ञान नहीं।

tei-mcp इसका हल है: यह एआई एजेंटों को TEI P5 दिशानिर्देशों तक सीधी, उपकरण-आधारित पहुँच देता है।

सामग्री तालिका

MCP क्या है?

(MCP) एक खुला मानक है, जो एआई ऐप्लिकेशनों को बाहरी डेटा-स्रोतों और उपकरणों से जोड़ने देता है। इसे एआई का USB पोर्ट समझिए: एक ही प्रोटोकॉल, जिससे कोई भी संगत क्लाइंट – Claude, Cursor, Windsurf और अन्य – विशेष सेवाओं में प्लग हो सकता है।

एक MCP सर्वर ऐसे उपकरण उपलब्ध कराता है, जिन्हें एआई बातचीत के दौरान बुला सकता है। रटे हुए प्रशिक्षण-डेटा के भरोसे रहने के बजाय मॉडल किसी जीवंत, प्रामाणिक स्रोत से पूछ सकता है।

tei-mcp क्या करता है

tei-mcp TEI P5 के ODD विनिर्देश को पार्स करता है और 16 उपकरण उपलब्ध कराता है, जो किसी संपादक या एनकोडर के सबसे आम सवालों का जवाब देते हैं:

यह एलिमेंट क्या है? किसी भी एलिमेंट, क्लास, मैक्रो या मॉड्यूल को नाम से खोजिए – बड़े-छोटे अक्षर का भेद किए बिना, और टाइपिंग की ग़लती पर सुझाव के साथ।
यह कौन-से एट्रिब्यूट लेता है? पूरी क्लास-श्रेणी में एट्रिब्यूट का निर्धारण – पहले स्थानीय, फिर क्रम से विरासत में मिले।
इसके भीतर क्या आ सकता है? कंटेंट मॉडल को संरचित वृक्ष के रूप में खोलिए, या वैध संतानों की सपाट सूची पाइए।
क्या यह एलिमेंट यहाँ आ सकता है? अभिभावक-संतान नेस्टिंग की जाँच कीजिए, या पूरी एलिमेंट-श्रेणी में पहुँच का पता लगाइए।
क्या मेरा दस्तावेज़ वैध है? किसी TEI XML फ़ाइल को विनिर्देश पर परखिए: कंटेंट मॉडल, एट्रिब्यूट के मान, बंद मान-सूचियाँ, संदर्भों की अखंडता और अप्रचलन की चेतावनियाँ।
और मेरी परियोजना की स्कीमा? ODD अनुकूलन फ़ाइल लोड कीजिए, ताकि ऊपर का सब कुछ आपकी परियोजना के TEI उपसमुच्चय तक सीमित रहे।

यह क्यों मायने रखता है

TEI एनकोडिंग में दिशानिर्देशों को बार-बार देखना पड़ता है। अनुभवी एनकोडर सबसे आम पैटर्न आत्मसात कर लेते हैं, लेकिन कम परिचित एलिमेंटों या जटिल कंटेंट मॉडलों के लिए उन्हें भी विनिर्देश खोलना पड़ता है। एआई असिस्टेंटों के पास ऐसा कोई आत्मसात ज्ञान नहीं होता, इसलिए उनकी समस्या और गंभीर है: वे देखने में ठीक-ठाक पर ग़लत मार्कअप गढ़ लेते हैं।

tei-mcp के साथ एआई को अनुमान लगाने की ज़रूरत नहीं। पहला कोण-कोष्ठक लिखने से पहले वह विनिर्देश में जवाब देख सकता है। नतीजा: ऐसा मार्कअप जो TEI P5 के – या आपकी परियोजना के ODD अनुकूलन के – अनुरूप हो।

शुरुआत कैसे करें

PyPI से इंस्टॉल कीजिए:

pip install tei-mcp

फिर इसे अपने MCP क्लाइंट की कॉन्फ़िगरेशन में जोड़िए:

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

सर्वर पहली बार चलने पर TEI विनिर्देश डाउनलोड करता है और किसी भी MCP-संगत क्लाइंट के साथ काम करता है।

स्रोत कोड और पूरा दस्तावेज़ीकरण:

Multi-Saxon

Fri, 28 Mar 2025 00:00:00 +0000

Multi-Saxon: बड़े TEI कॉर्पस के लिए समानांतर XSLT प्रोसेसिंग

XML प्रोसेसिंग के औज़ारों में एक बड़ी कमी रही है: LXML (Python की लोकप्रिय XML लाइब्रेरी) XSLT 2.0 और 3.0 के रूपांतरण नहीं सँभाल पाती। Multi-Saxon इसी कमी को पूरा करता है और ऐसे रूपांतरणों को समानांतर चलाने की सुविधा देता है। यह ख़ास तौर पर XML TEI दस्तावेज़ों के बड़े संग्रहों के लिए बनाया गया है, और समानांतर निष्पादन से प्रोसेसिंग का समय काफ़ी घटा देता है।

मुख्य विशेषताएँ

उन्नत XSLT समर्थन: LXML की सीमा से आगे जाकर XSLT 2.0 और 3.0 के रूपांतरण
समानांतर प्रोसेसिंग: बड़े दस्तावेज़-संग्रहों के रूपांतरण का समय समानांतरीकरण से नाटकीय रूप से कम
TEI के लिए अनुकूलित: विशेष रूप से Text Encoding Initiative (TEI) के XML दस्तावेज़ों के लिए बनाया गया
बढ़ते आकार पर भी प्रदर्शन: सैकड़ों से हज़ारों दस्तावेज़ों तक के कॉर्पस को कुशलता से सँभालता है
क्रॉस-प्लेटफ़ॉर्म: अलग-अलग ऑपरेटिंग सिस्टम और परिवेशों में चलता है

Multi-Saxon किस समस्या का हल है

TEI के साथ काम करने वाले डिजिटल मानविकी के शोधकर्ता अक्सर दो बड़ी अड़चनों से जूझते हैं:

LXML (Python की आम XML प्रोसेसिंग लाइब्रेरी) केवल XSLT 1.0 का समर्थन करती है, जिससे XSLT 2.0/3.0 की उन्नत सुविधाओं का इस्तेमाल असंभव हो जाता है
TEI दस्तावेज़ों का बड़ा कॉर्पस एक-एक करके प्रोसेस करने में इतना समय लग सकता है कि काम ही अव्यावहारिक हो जाए

Multi-Saxon दोनों समस्याओं को हल करता है: यह Saxon की उन्नत XSLT क्षमताओं का लाभ उठाता है और प्रोसेसिंग को कई कोर पर बाँटकर प्रदर्शन में बड़ी बढ़त देता है।

कार्यान्वयन

Multi-Saxon Python को Java के Saxon प्रोसेसर से जोड़कर एक तेज़ रूपांतरण-पाइपलाइन बनाता है:

मज़बूत XSLT 2.0/3.0 प्रोसेसिंग के लिए Java की Saxon लाइब्रेरी का उपयोग
उपलब्ध CPU कोर पर रूपांतरण बाँटने के लिए मल्टीप्रोसेसिंग
अधिकतम थ्रूपुट के लिए प्रोसेसर-पूल का कुशल प्रबंधन
TEI दस्तावेज़ों की बैच-प्रोसेसिंग के लिए सीधा-सादा इंटरफ़ेस

उपयोग का उदाहरण

from multi_saxon import MultiSaxon

# Initialize with your XSLT stylesheet
transformer = MultiSaxon("transform.xsl")

# Transform a single document
transformer.transform("input.xml", "output.xml")

# Transform an entire directory in parallel
transformer.transform_directory("input_dir", "output_dir")

डिजिटल मानविकी के लिए महत्व

TEI दस्तावेज़ों के बड़े संग्रहों से जूझ रही डिजिटल मानविकी परियोजनाओं के लिए Multi-Saxon संभव बनाता है:

पूरे कॉर्पस पर ऐसे जटिल रूपांतरण, जो LXML से असंभव होते
प्रोसेसिंग समय में नाटकीय कमी (मल्टी-कोर सिस्टम पर अक्सर 5–10 गुना)
XSLT 2.0/3.0 की उन्नत सुविधाओं से और परिष्कृत विश्लेषण
पूरे दस्तावेज़-संग्रह को प्रोसेस करने का सरल वर्कफ़्लो

स्रोत कोड और दस्तावेज़ीकरण पर उपलब्ध हैं।

persNamer

Fri, 28 Mar 2025 00:00:00 +0000

persNamer: TEI को Virtual International Authority File से जोड़ना

persNamer एक विशेष Python उपकरण है, जो VIAF (Virtual International Authority File) के प्रामाणिक व्यक्ति-डेटा को TEI XML दस्तावेज़ों में जोड़ने का काम सरल बनाता है। VIAF पहचानकर्ता को तैयार TEI मार्कअप में बदलकर persNamer डिजिटल विद्वत्तापूर्ण संस्करणों के लिए संरचित व्यक्ति-प्रविष्टियाँ बनाने की हाथ की मेहनत काफ़ी घटा देता है।

TEI में प्रामाणिक नाम-सूची की चुनौती

डिजिटल विद्वत्तापूर्ण संस्करणों में ऐतिहासिक व्यक्तियों की सटीक पहचान ज़रूरी होती है – मानकीकृत नाम और जन्म-मृत्यु की तिथियों समेत। पूरी परियोजना में प्रामाणिक नाम-सूची को एकरूप रखने के लिए चाहिए:

ऐतिहासिक पाठों में व्यक्तियों की पहचान
उनके बारे में प्रामाणिक डेटा की खोज
सही ढंग से गढ़ी गई TEI प्रविष्टियाँ
पूरी परियोजना में एक जैसे संदर्भ

ये सारे चरण आम तौर पर हाथ से किए जाते हैं, समय खाते हैं और असंगति की गुंजाइश छोड़ते हैं।

persNamer कैसे काम करता है

persNamer इस वर्कफ़्लो को स्वचालित करता है:

VIAF डेटा लाना: VIAF पहचानकर्ता मिलने पर उपकरण HTTP कंटेंट नेगोशिएशन के ज़रिये RDF डेटा प्राप्त करता है
मुख्य जानकारी निकालना: RDF को पार्स करके पसंदीदा नाम, जन्म-तिथि और मृत्यु-तिथि निकालता है
TEI मार्कअप बनाना: दो ज़रूरी XML खंड तैयार करता है:
- एक प्रामाणिक नाम-सूची की प्रविष्टि (<person> एलिमेंट, जिसमें स्वतः बना xml:id, <persName>, <birth>, <death> और <idno type="VIAF"> होते हैं)
- एक अलग टिप्पणी-टैग (<persName>, जिसका ref एट्रिब्यूट नाम-सूची की प्रविष्टि की ओर संकेत करता है)

इस दोहरे आउटपुट से संपादक एक केंद्रीय नाम-सूची रख सकते हैं और साथ ही अपने TEI पाठों में टिप्पणी-टैग आसानी से डाल सकते हैं।

मुख्य विशेषताएँ

मानक ID निर्माण: pers-[familyname]-[givenname initial] के प्रारूप में एकरूप XML ID बनाता है (जैसे pers-deteligny-c)
RDF पार्सिंग: rdflib के ज़रिये विभिन्न RDF प्रॉपर्टियों (जैसे rdfs:label, schema:name, viaf:mainHead) से जानकारी निकालता है
कमांड-लाइन इंटरफ़ेस: बस एक VIAF नंबर देकर चलाइए – और कुछ ज़रूरी नहीं
विस्तृत आउटपुट: अंतिम XML के साथ प्रोसेसिंग का पूरा ब्योरा भी देता है

उपयोग का उदाहरण

python persNamer.py 314802260

यह कमांड देती है:

<person xml:id="pers-deteligny-c">
 <persName>Charles deTéligny</persName>
 <birth>1535</birth>
 <death>1572-08-24</death>
 <idno type="VIAF">314802260</idno>
</person>

<persName ref="#pers-deteligny-c">Charles deTéligny</persName>

डिजिटल मानविकी में उपयोग

persNamer ख़ास तौर पर इनके लिए उपयोगी है:

प्रामाणिक नाम-सूची की ज़रूरत वाले डिजिटल विद्वत्तापूर्ण संस्करण
ऐतिहासिक व्यक्तियों से जुड़ी TEI एनकोडिंग परियोजनाएँ
दस्तावेज़ों को प्रामाणिक अभिलेखों से जोड़ने वाली लिंक्ड डेटा पहलें
बड़े TEI कॉर्पस में एकरूपता बनाए रखना
डिजिटल मानविकी के पाठ्यक्रमों में प्रामाणिक नाम-सूची की अवधारणा पढ़ाना

कार्यान्वयन

persNamer Python में लिखा गया है और इन पर निर्भर है:

HTTP अनुरोधों के लिए requests
RDF पार्सिंग के लिए rdflib
XML सँभालने के लिए lxml

स्रोत कोड और दस्तावेज़ीकरण पर उपलब्ध हैं।