TEI ODDファイルのカスタマイゼーション:NDL古典籍OCRの事例

はじめに TEI (Text Encoding Initiative) は、人文学研究におけるテキストのデジタル化と共有のための国際標準です。本記事では、NDL古典籍OCR-Liteアプリケーションの出力形式に合わせてTEI ODDファイルをカスタマイズした過程を紹介します。 ODD (One Document Does it all) は、TEIスキーマをカスタマイズするための仕組みで、必要な要素と属性だけを含む独自のスキーマを定義できます。 背景:NDL古典籍OCR-Liteアプリケーションの開発 NDL古典籍OCR-Liteの出力結果をTEI/XMLで出力するアプリケーションを作成しています。このアプリケーションは、日本の古典籍をOCR処理し、その結果を標準的なTEI形式で出力することを目的としています。 出力されるTEI XMLには以下の情報を含めることにしました: テキスト情報 : OCRで認識した文字列 レイアウト情報 : 各行の座標情報(バウンディングボックス) 画像参照 : IIIF (International Image Interoperability Framework) 対応の画像URL メタデータ : 文書タイトル、処理情報など このアプリケーションで使用するスキーマをODDで記述してみました。以下、そのカスタマイゼーション過程を紹介します。 カスタマイゼーションのアプローチ 1. 初期アプローチ:標準モジュールの利用 最初は、TEIの標準モジュールを利用してODDを作成しました: < s / c < < < < < s h m m m m m c e o o o o o h m d d d d d e a u u u u u m S l l l l l a p e e e e e S e R R R R R p c e e e e e e f f f f f c i > d k k k k k e e e e e e n y y y y y t = = = = = = " " " " " " t h c t t n e e o e r d i a r x a l " d e t n _ / e " s s k > r t c o " i r r t n u " e i c c n n l t i _ c u u n o l d r c c u e e l r d = " u " e " d = p i e s " n = t t t c " a e i l f r i t u a t H l d c = e e e s " a = i T d n " m E e a T i I r m E l " e I e f p i r t s r l e e u e e s x r f D p t f i e a x s r b c = c e o e " s d t t p y z e i S " i t t n _ l m e " e t " > S / t l > m b t p p b u b g l r i a c p a h t i i c o " n / S > t m t s o u r c e D e s c " / > include属性の重要性 moduleRef要素のinclude属性は、モジュールから特定の要素のみを選択的に含める重要な機能です: ...

2025年9月5日 · 18 分 · Nakamura

TEI GarageのAPIを使用したODDからRNG/HTMLへの変換

はじめに TEI(Text Encoding Initiative)のODD(One Document Does it all)ファイルから、スキーマ(RNG)やドキュメント(HTML)を生成する作業は、TEIプロジェクトにおいて重要な工程です。本記事では、Roma(TEIのODDエディタ)が内部で使用しているTEI Garage APIの仕組みを解析し、スクリプトから直接APIを呼び出してODDを変換する方法を紹介します。 TEI Garageとは TEI Garageは、TEIコミュニティが提供するWebサービスで、様々なフォーマット間の変換を行うことができます。特にODDファイルの処理において、以下の機能を提供しています: ODD → Compiled ODD への変換 Compiled ODD → RELAX NG スキーマへの変換 ODD → HTML ドキュメントへの変換 その他多数のフォーマット変換 Romaの内部動作を解析 Romaのネットワークトラフィックを観察すると、以下のような変換チェーンを使用していることがわかりました: HTMLドキュメント生成の場合 O D D → O D D C ( C o m p i l e d O D D ) → T E I → x H T M L 実際のAPIエンドポイント: ...

2025年9月3日 · 31 分 · Nakamura

NDL古典籍OCR-lite Next.js版の開発

概要 @yuta1984 さんが「WebAssemblyを使用したNDL古典籍OCR-liteのWeb移植版」を開発されました。 https://github.com/yuta1984/ndlkotenocr-lite-web 今回は、上記のリポジトリを参考にさせていただき、Next.js版を作成しました。 https://nkol.vercel.app/ja/ 加えて、以下の点を追加しています。 IIIFマニフェストファイルの入力フォーム TEI/XMLファイルのダウンロード機能 出力フォーマットに関するODDファイルの作成 使い方 サンプルとして、九州大学附属図書館の源氏物語を利用させていただきます。 https://catalog.lib.kyushu-u.ac.jp/image/manifest/1/820/411193.json マニフェストファイルを入力し、「読み込む」ボタンを押すと、以下のように、画像の一覧が表示されます。 なお、内部的には、@iiif/parserを利用し、v2とv3、どちらのマニフェストファイルにも対応するようにしています。 その後、処理の実行ボタンを押すと、画像ごとにOCR結果のテキストが表示されます。 実行完了後、画面下部に結果のダウンロードボタンが表示されます。 ODDファイルの作成 TEI/XMLでのエクスポートにあたり、どのようなタグや形式が想定されているのか、という質問をいただくことがありました。 そこで、このフォーマットの共有にあたり、ODD(One Document Does it all)ファイルを作成しました。 このODDファイルの作成については、以下の記事も参考にしてください。 さらに、TEIGarageのAPIを利用し、RNGファイルやHTMLファイルを作成しています。この変換については、以下の記事を参考にしてください。 不完全な部分もありますが、このような方法を採ることで、TEIのエコシステムを活用しながら、スキーマを公開・共有することができそうです。 これまでに作成したツールと今後開発予定のツール これまでの開発 NDL古典籍OCR-liteについては、これまでにいくつかのツールを開発してきました。 まず、Gradio Appを作成しました。こちらは公式に提供されている「デスクトップアプリケーション」で代替可能なものでしたが、スマホやタブレットで撮影した画像に対してOCRをかけるといった用途では有用性があると考えられます。 次に、以下の記事で紹介したように、同じくGradioを用いたウェブアプリですが、IIIFマニフェストファイルを入力とし、TEI/XMLファイルを出力とするアプリを作成しました。IIIFとTEIを接続している点で有用性はありましたが、Hugging Faceの無料枠でアプリを公開しているため、多くの人が同時に使用できる環境ではないという課題がありました。 これらの課題に対して、@yuta1984 さんが作成されたウェブ版を参考に、IIIFとTEIの接続機能を維持しながら、ユーザの端末側でOCR処理を実行する環境を今回構築しました。これにより、複数人が同時に処理を実行できるようになりました。 今後の展望 人手でOCRをかける際には、公式のデスクトップアプリケーションを使用するか、@yuta1984 さんのウェブアプリ、あるいは今回開発したNext.js版のウェブアプリを使用することで、多くのニーズに対応できると考えています。 今後の取り組みとして、API等を介して大量の画像に対して一括でOCR処理を行う場合には、複数のサーバで並列にOCR処理を実行することで効率化を図ることができます。例えば、2000枚を超える画像から構成されるIIIFマニフェストファイルを対象とする際には、並列でOCR処理を行うことが、順次実行するよりも効果的です。 このような処理を実現するため、以下の記事で紹介しているように、Azure Container Appsを使用したスケーラブルなOCR処理システムの構築を進めています。 まだ不完全な点や考慮すべき点は多いものの、サーバレスな環境でOCRを提供することで、大規模な画像に対するOCR処理の実現を目指しています。 まとめ NDL古典籍OCR-liteの活用にあたり、参考になりましたら幸いです。

2025年9月1日 · 1 分 · Nakamura

Romaを使ってタグの属性に使用可能な値を限定する

概要 Romaを使ってタグの属性に使用可能な値を限定する方法に関する備忘録です。 背景 以下の記事で、タグに使用可能な属性を限定する方法を記載しました。 例えば、persNameタグには、key属性とtype属性のみを使用可能にする、といった具合です。 本記事では、さらに特定の属性で使用可能な値を限定します。例えば、type属性には、「右傍注」または「左傍注」のいずれかを設定する、といった具合です。 Romaでの設定 以下の記事を参考に、タグの属性の設定を行います。 ここでは、persNameタグにtype属性を設定済みとします。そして、以下のように、鉛筆アイコンをクリックします。 以下のように、属性に関する情報を編集するためのページに遷移します。ここで、「値」という項目において、「右傍注」「左傍注」といった値を登録します。合わせて、必要に応じて「説明」文も追加します。 Oxygen XML Editorでの表示例 rngファイルとしてダウンロードし、それをTEI/XMLからロードすることにより、Oxygen XML Editorでは以下のように表示されました。 LEAF Writerでの表示例 LEAF Writerでは、以下のように、セレクトボックスで選択肢が提示されました。 まとめ TEI/XMLの導入あたり、参考になりましたら幸いです。

2024年10月28日 · 1 分 · Nakamura

Romaを使ってプロジェクトに応じたタグに使用する属性を限定する

概要 Romaを使ってプロジェクトに応じたタグに使用する属性を限定する方法に関する備忘録です。 背景 以下の記事で、Romaを使ってプロジェクトに応じたタグを限定する方法を記載しました。 今回はこの延長で、各タグで使用する属性のカスタマイズを行います。 ユースケース ここでは、一例として、persNameで使用可能な属性を限定してみます。 デフォルト(tei_all.rng)をOxygen XML Editorで用いた際、以下のように、persNameタグで使用可能な属性として、多くの選択肢が提示されていることがわかります。 一方、本記事で説明するカスタマイズしたrngファイルを使用した場合、以下のように、5つの属性のみが利用可能となっていることがわかります。 このようにプロジェクト毎に使用可能なタグや属性を限定することで、入力者の負担軽減や、Validationの効率化が期待できます。 手順 以下の記事を参考に、Romaで新規にODDファイルを作成するか、既存のODDファイルを登録した状態から開始します。 そして、今回対象とするpersNameにチェックが入っていることを確認します。 次に、上記のpersNameのリンクをクリックすると、以下の画面に遷移します。 そして、属性をクリックします。このページにおいて、使用する属性を限定することができます。 以下では、少しわかりにくいですが、key属性は使用するものとして残しており、xml:lang属性は使用しないものとして除外している例です。 その他、新規の属性の作成や、 既存のものからインポート(用語が正しいか自身がありません)することもできました。 このカスタマイズ内容を保存できるように、ダウンロード > 「ODDとしてカスタマイズ」により、oddファイルをダウンロードしておきます。また、「RELAX NGスキーマ」などを選択して、実際にTEI/XMLで使用するファイルをダウンロードします。 詳細は以下を参考にしてください。 参考:説明文のカスタマイズ Roma RELAX NG スキーマ < d e / e l d f < e e i e m / f n l e e i e e < < < n < < < < < < l n m a r p t / r r r r r e e e n e : e a p e e e e e m m > a n d f t x < h a f f f f f p e m t o t m s a / t t n e c n e l c s s t n n n n n y t = n u a r n h x x < c e a a a a a / > " a m m n s : m m s n h r m m m m m > t m e e : r l l c o : n e e e e e e e n = x r u n n h r > = = = = = i = t " m n l s s : t u " " " " " _ " a t l g e : = a e l t t t t t p p t e n = x " s x e e e e e e e e i i s " x i h s t > i i i i i r r o _ = h m = t e u _ _ _ _ _ s s n m " t l " t r a a a a a a N N a h t n h p t l t t t t t a a x c t p s t : t t t t t m m m r t : : t / t s b c . . . . . e e l o p / s p / e y u o c g g g g " " n . : c : w s s t n a l l l l > > s p r h / w t t t n o o o o : h / e = / w = e t e o b b b b a r p l " w . " m h n n a a a a = a u a h w t s s i t i l l l l " s r x t w e t s . c . . . . h e l n t . i r o < a a a l a t S . g p w - i r < / l t t i n t e o . : 3 c n s s . t t n a p q c o / . . g c c c a r r k l : " l r o o - a h h t i i i y / c g p r r l l : : t b b n t . u g g e e n a r u u g i r n r / / n n a s i t t . c e r s l 2 n g d m s b e e a . l g . 0 s t a e e u . . t a a s o 0 / h r / r t x n t t x d t c 1 1 ( s > t e m " r t n s r l / . > . l / i r g d u c X 0 n t k i > b i . l c . I " o o e d u b o / t o n r y " t u r s u r c c m w " e t g c r g l o a h . e / h e u n l i c . n e d d t i c o a s m 1 s e e z h r n / a . d " x e r a c t 0 l t - t e " o r " / = s h s / m o s " p e p > p n i c t a " a " d h e c d / t = e i e a > i " m : ( t b t a * . e i e t [ ) l i r @ r i _ o c ) e t h n a p y i " l g r / _ e t e a d n s n n d 0 e n s a " n o - r > t t p ] e a e " @ d t r > c i s a b o N l y n a e s m n t / e d h 1 - a e . c r 0 a c " l i o > e n n ( n d t p d i e e a c n r r a t s - t o c e o n h s f a e l c o t k n h n - e i a p s m e o e r r e ) s l N m e 日 a o m 本 m r e 語 e e n に - t よ c る o b カ n e ス s l タ t o マ r n イ a g ズ i s で n , す t 。 - r [ u 1 l 4 e . - 2 2 . 3 1 " . > P e r s o n a l N a m e s ] < / a : d o c u m e n t a t i o n > LEAF Writer ...

2024年10月28日 · 5 分 · Nakamura

LEAF Writer:スキーマのカスタマイズ

概要 LEAF Writerのカスタマイズ方法に関する調査記録です。 https://gitlab.com/calincs/cwrc/leaf-writer/leaf-writer 今回はスキーマのカスタマイズ方法に関する備忘録です。以下のように、日本語訳などを表示することを目指します。 以下は、カスタマイズ前の表示です。以下のスキーマに基づき、多くの要素が英語の説明とともに表示されます。 https://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng 方法 以下のように、スキーマファイルを指定します。 https://github.com/kouigenjimonogatari/kouigenjimonogatari.github.io/blob/master/xml/lw/01.xml 具体的には、以下です。 < ? x m l - m o d e l h r e f = " h t t p s : / / k o u i g e n j i m o n o g a t a r i . g i t h u b . i o / l w / t e i _ g e n j i . r n g " t y p e = " a p p l i c a t i o n / x m l " s c h e m a t y p e n s = " h t t p : / / r e l a x n g . o r g / n s / s t r u c t u r e / 1 . 0 " ? > LEAF Writerはこのスキーマファイルを読み込み、validationや使用可能な要素の提示を行うようでした。 ...

2024年6月29日 · 2 分 · Nakamura

TEI ODDから変換可能なスキーマについて:RNG、XSD、DTDなど

概要 以下の記事でODDの作成を試しました。 上記ではRomaというツールを使用していますが、作成したODDについて、以下に示す出力フォーマットがあることがわかります。 具体的には、「RELAX NGスキーマ」「RELAX NGコンパクト」「W3Cスキーマ」「文書型定義」「ISO Schematron制約」が挙げられます。 そこで、これらの違いについて、GPT-4に問い合わせてみたので、その結果を共有します。誤った内容も含まれるかもしれませんが、参考になりましたら幸いです。 Relax NG(RNG)とW3C XMLスキーマの違い Relax NG(RNG)とW3C XMLスキーマは、どちらもXML文書の構造と内容を定義するためのスキーマ言語ですが、いくつかの重要な違いがあります: 表記法 : RNG : 2つの構文を提供します。一つはXMLベースのもので、もう一つはよりコンパクトな非XMLの構文です。 W3C XMLスキーマ : XMLベースの構文のみを提供します。 柔軟性と明瞭性 : RNG : RNGは非常に柔軟で、人が読みやすい設計になっています。パターンベースのアプローチを取り、より直感的なモデリングが可能です。 W3C XMLスキーマ : より厳格で形式的なアプローチを取り、型システムが複雑ですが、これにより強力なデータタイピングが可能になります。 データタイピング : RNG : データタイプはDatatype Libraryを介してサポートされていますが、W3C XMLスキーマほど多様ではありません。 W3C XMLスキーマ : 豊富なビルトインデータタイプを提供し、正確なデータ型制約を設定できます。 拡張性 : RNG : 簡潔さと柔軟性により、スキーマ自体を容易に拡張できます。 W3C XMLスキーマ : 拡張性はありますが、より複雑な構造のため、理解と実装が難しくなる場合があります。 普及度 : RNG : シンプルさと強力なモデリング機能にも関わらず、W3C XMLスキーマほど広くは採用されていません。 W3C XMLスキーマ : より一般的に使用されており、多くのXML処理ツールやライブラリで標準的にサポートされています。 これらの違いにも関わらず、どちらの言語もXML文書の構造を定義し、文書の妥当性を検証するという共通の目的を持っています。選択はしばしば個々のプロジェクトのニーズや開発者の好みに依存します。 DTD(Document Type Definition)との関係は? DTD(Document Type Definition)は、XML文書の構造を定義するための一つの仕様で、W3C XMLスキーマやRelax NG(RNG)よりも歴史が古く、制約を記述する方法が限られています。DTDは非常にシンプルで、XMLの初期から使われている標準的な方法ですが、名前空間やデータ型などのより高度な概念をサポートしていません。 W3C XMLスキーマやRNGに比べて、DTDは次のような制約があります: ...

2023年11月4日 · 1 分 · Nakamura

Romaを使ってプロジェクトに応じたタグを限定し、解説を作成する

概要 以下の記事で、Romaの使い方を説明しました。 今回は、手元にあるTEI/XMLを対象として、TEI ODD (One Document Does-it-all)や解説(HTMLやPDF)の作成に関する一連の流れを説明します。 なお、ODD (One Document Does it all) と RNG (RelaxNG) の違いについて、GPT-4による回答結果を末尾に掲載しています。こちらも参考にしてください。 使用するタグの一覧を取得する まず、プロジェクトで使用するタグの一覧を取得します。 今回、手元にあるTEI/XMLを対象として、使用されているタグの一覧を取得するライブラリおよびチュートリアル用のノートブックを作成しました。 ライブラリ https://nakamura196.github.io/gdb-utils/ チュートリアル用のノートブック https://colab.research.google.com/github/nakamura196/000_tools/blob/main/TEIでタグの使用頻度を分析するチュートリアル.ipynb 例えば、上記のノートブックを実行すると、以下のような結果が得られます。以下は、対象としたTEI/XMLファイル中に含まれるタグとその頻度を取得し、その結果をタグの名前について昇順で取得したものです。 index Tag Count 0 TEI 1 18 addrLine 1 17 address 1 50 app 8 5 author 2 58 back 1 36 bibl 1 47 body 1 56 closer 1 44 correspAction 2 43 correspDesc 1 20 country 1 33 date 6 26 dimensions 1 19 district 1 54 div 1 37 editor 1 40 editorialDecl 1 39 encodingDesc 1 25 extent 2 2 fileDesc 1 29 handDesc 1 30 handNote 1 27 height 1 31 history 1 21 idno 2 16 institution 1 55 lb 13 51 lem 8 59 listPerson 1 12 listWit 1 45 location 1 14 msDesc 1 15 msIdentifier 1 23 objectDesc 1 48 opener 1 32 origin 1 … Romaでタグを限定したODDファイルを作成する 上記で取得したタグに限定したODDファイルを、Romaというツールを用いて作成します。 ...

2023年11月3日 · 8 分 · Nakamura