ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
OpenITI mARkdownからTEI XMLへの自動変換ツール「oitei」を試す

OpenITI mARkdownからTEI XMLへの自動変換ツール「oitei」を試す

はじめに イスラーム圏の歴史テキストを扱う OpenITI(Open Islamicate Texts Initiative) プロジェクトでは、TEI/XMLの代わりに mARkdown という軽量記法でテキストをタグ付けできます。 TEI/XMLは構造化の国際規格として強力ですが、特にアラビア語のような右から左に書く言語(RTL)では、XMLタグとの混在でエディタ上の表示が乱れるという問題があります。mARkdownはこの課題を解決する記法です。 本記事では、mARkdownで書かれたテキストを TEI XMLに自動変換 するPythonツール oitei を実際に動かしてみます。 oiteiとは OpenITI mARkdown → TEI XML の変換ライブラリ(Python) OpenITI TEI Schema に準拠したXMLを出力 PyPIで公開されており pip install で導入可能 依存ライブラリ: oimdp(mARkdownパーサー)、lxml https://github.com/OpenITI/oitei インストール pip install oitei Python 3.8以上が必要です。oimdp(OpenITI mARkdown Parser)と lxml が依存関係として自動インストールされます。 OpenITI mARkdownの記法 mARkdownファイルは以下の3部構成です。 マジックバリュー (1行目): ######OpenITI# メタデータ : #META# で始まる行 本文 : #META#Header#End# の後に記述 主なタグ 記法 意味 `### ` `### ### $ 伝記エントリ # 段落の開始 @P02 名前 人物名(後続2語を含む) @T11 地名 地名(後続1語を含む) @YB732 誕生年(ヒジュラ暦732年) @YD808 没年(ヒジュラ暦808年) %~% 詩行(hemistich)の区切り 固有表現タグ(@P, @T 等)の後ろの 2桁の数字 は、1桁目がエンティティ番号、2桁目が「後続する何単語を名前に含むか」を指定します。例えば @P02 Ibn Khaldun は「後続2語(Ibn Khaldun)を人名として含む」という意味です。 ...

DHConvalidatorにおける'ref'に関する不具合への対応

DHConvalidatorにおける'ref'に関する不具合への対応

本記事は、一部AIが執筆しました。 概要 DHConvalidatorは、デジタル人文学(DH)会議の抄録を一貫したTEI(Text Encoding Initiative)テキストベースに変換するためのツールです。 https://github.com/ADHO/dhconvalidator このツールの利用において、Microsoft Word形式(DOCX)からTEI XML形式への変換処理中に以下のようなエラーが発生するケースがありました: ERROR: nu.xom.ParsingException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'ref' この原因と対処方法について共有します。 原因の特定 調査の結果、問題の原因はWord文書内に埋め込まれた INCLUDEPICTUREフィールドコード であることが判明しました。 具体的には、Googleドキュメントから画像をコピー&ペーストした際に、以下のようなフィールドコードが文書内に残存していました: INCLUDEPICTURE "https://lh7-rt.googleusercontent.com/docsz/..." \* MERGEFORMATINET これらの外部画像参照リンクがTEI変換プロセスで適切に処理されず、XML検証エラーを引き起こしていました。 解決方法 この問題を解決するため、DOCXファイル内の問題のあるフィールドコードを自動的に除去するPythonスクリプトを開発しました。 スクリプトの特徴 安全な処理 : 画像コンテンツ自体は保持し、フィールドコード部分のみを削除 ZIP形式対応 : DOCXファイルの内部構造(ZIP + XML)を適切に処理 名前空間対応 : Word文書のXML名前空間を考慮した正確な要素検索 主要な処理ロジック DOCXファイルを一時ディレクトリに展開 word/document.xml内のフィールドコード構造を解析 INCLUDEPICTUREを含むフィールドを特定 フィールド制御要素(begin/separate/end)のみを削除し、画像要素は保持 修正されたXMLで新しいDOCXファイルを生成 実装のポイント フィールドコード判定 def is_includepicture_field(field_runs, ns): for run in field_runs: instr_text = run.find('.//w:instrText', ns) if instr_text is not None and instr_text.text: if 'INCLUDEPICTURE' in instr_text.text: return True return False 削除対象の選別 def should_remove_run(run, ns): # フィールド制御要素を持つか確認 has_field_control = (run.find('.//w:fldChar', ns) is not None or run.find('.//w:instrText', ns) is not None) # 実際の画像コンテンツを持つか確認 has_image_content = (run.find('.//w:drawing', ns) is not None or run.find('.//w:pict', ns) is not None) # フィールド制御要素があり、画像コンテンツがない要素を削除 return has_field_control and not has_image_content 結果 このスクリプトにより、問題のあるフィールドコードが除去され、TEI変換プロセスが正常に完了するようになりました。画像は適切に文書内に埋め込まれた状態で保持されます。 ...

tropy-plugin-iiifを試す

tropy-plugin-iiifを試す

概要 tropy-plugin-iiifを試す機会がありましたので、備忘録です。 https://github.com/tropy/tropy-plugin-iiif tropy-plugin-iiifは以下のように説明されています。 Tropy plugin to import IIIF manifests 準備 Tropyをインストールします。 https://tropy.org/ 次に、以下のリンク先から、最新のzipファイルをダウンロードします。 https://github.com/tropy/tropy-plugin-iiif/releases/latest 設定 > プラグイン で以下を開きます。 「プラグインをインストール」ボタンをクリックして、ダウンロードしたzipファイルを選択し、「有効にする」をクリックします。 これでインストールは完了です。 IIIFマニフェストのインポート ファイル > インポート から、tropy-plugin-iiifを選択します。 別途ダウンロードしたIIIFマニフェストファイル(jsonファイル)を選択します。 以下のように、IIIFマニフェストの情報をインポートできました。 ダウンロードされた画像は、プロジェクトごとに作成される.tropyフォルダのassetsに格納されていました。 参考:PDFエクスポート 以下のようなフォーマットのPDFが作成されました。 ページごとに、アイテムや画像のメタデータが表示され、使いやすいように思いました。 まとめ 今回はIIIFマニフェストのインポート機能について紹介しましたが、現在、IIIFコレクションでのエクスポートを行うプラグインが開発されているとのことでした。 https://iiif.io/event/2024/los-angeles/schedule/#107 Tropyを使用することで、今後データの作成と公開の両方を担うことができそうです。 参考になりましたら幸いです。