Odd

要素の属性を特定のものだけに制限する TEIのデフォルトでは、要素は多くの属性クラス（att.global、att.datableなど）を継承しており、多数の属性が使用可能です。特定の属性のみを許可したい場合は、以下のように設定します。 例: persNameでxml:idとcorrespのみを許可 < e / l < < e e c / a / l m l < < < < < < < c t < < a e e a ! m m m m m m l t a / a / t m n s - e e e e e e a L t < < a t < < a t e t s - m m m m m m s i t d d / t t d d / t L n S e b b b b b b s s D e a < d t D e a < d t i t p s 属 e e e e e e e t e s t d a D e s t d a D s S e 性 r r r r r r s > f c a a t e f c a a t e t p c m ク O O O O O O > > t t a f > t t a f > e o ラ f f f f f f i 要 y a t > i 関 y a t > c i d ス d 素 p R y d 連 p R y > d e を k k k k k k e の e e p e す e e p e = 削 e e e e e e n 一 > f e n る > f e n " 除 y y y y y y t 意 > t 人 > t c （ = = = = = = = な n = 物 k = h モ " " " " " " " 識 a " 情 e " a デ a a a a a a x 別 m c 報 y p n ル t t t t t t m 子 e o へ = e g ク t t t t t t l < = r の " r e ラ . . . . . . : / " r リ t s " ス g c d e p t i d I e ン e N > は l m a d e y d e D s ク i a 維 o c t i r p " s " p < d m 持 b " a t s e c / " / a e ） a b L o d m > > d t " l m l i n " o m e a " o e k a d o s . m d " e l m e d c p o m e " " o = e > o d o = m d " = i e d " o m m e a " n = e d d o o = d a t " = e e d d " d d e c " l = e e d " d r h d e " = = e " " a e t d " " l u / n l e e d d e s u > g e " l e e t a s e t / e l l e g a " e > t e e " e g > " e t t / = e / " e e > " = > / " " o " > / / p o > > t p " t > " > ポイント <classes mode="change">を使用: mode="replace"で空にすると、モデルクラスも削除され要素自体が使えなくなる 属性クラスを個別に削除 : <memberOf key="att.xxx" mode="delete"/>で不要な属性クラスを削除 必要な属性を追加 : <attDef ident="xxx" mode="add">で許可したい属性を定義 注意点 要素がどの属性クラスに属しているかは、TEI Guidelinesで確認できる att.globalを削除するとxml:id、xml:langなども使えなくなるため、必要に応じて個別に追加する 要素に属性を追加する 既存の属性クラスを維持したまま、新しい属性を追加する場合： ...

はじめに TEI（Text Encoding Initiative）でデジタル画像のメタデータを記述する際、facsimile要素を使用します。特にIIIF（International Image Interoperability Framework）対応のデジタルアーカイブでは、マニフェストやキャンバス、Image APIへの参照を適切に記述することが重要です。 本記事では、ODD（One Document Does it all）を使用して、ファクシミリ記述に必要な制約をスキーマとして定義する方法を紹介します。 準拠するガイドライン 本ODDは、日本語TEIガイドラインで紹介されている「IIIF画像とのリンク」仕様をベースにしています： IIIF画像とのリンク（2024年度版）- TEI-EAJ このガイドラインに準拠したデータを作成することで、TEI Viewer for EAJでの画像表示が可能になります。TEI Viewerは、TEIテキストとIIIF画像を連携して表示できるビューアであり、facsimile要素の情報を利用してテキストと画像の対応付けを行います。 設計目標 以下の要件を満たすスキーマを設計しました： 必須情報の明確化 : 画像の座標情報や識別子など、最低限必要な情報を必須属性として定義 IIIF対応 : マニフェスト、キャンバス、Image APIへの参照をオプショナルに記述可能 再利用性 : 独立したODDファイルとして、複数プロジェクトで共有可能 ビューア互換性 : TEI Viewer for EAJでの表示に必要な情報を確実に記録 最小限の記述例 < f / a f c a s < c i s / s m u s i i r u m l f < r i e a g f l c r a e s e a c > a p e m u h > e l i A x c s = = " s " 0 a h " m t e t u A p l s s y = : = " / " h / 0 t e " t x p a l s m r : p x / l = / e " e . 5 x o 6 a r 0 m g 0 p / " l i e i l . i r o f y r / = g m " / a 4 i n 0 m i 0 a f 0 g e " e s / t x 0 . m 0 j l 1 s : . o i t n d i " = f > " " p / 1 > " > 完全な記述例（IIIF参照を含む） < f / a f c a s < c i s / s m u s i i r u m l f < r i e a g f l c r a e s e a c > a p e m u s h > e l a i A x m c s = e = " A u s " 0 s r a h " = l m t " = e t u h " A p l t h s s y t t = : = p t " / " s p h / 0 : s t e " / : t x / / p a l e / s m r x e : p x a x / l = m a / e " p m e . 5 l p x o 6 e l a r 0 . e m g 0 o . p / " r o l i g r e i l / g . i r c o f y a i r / = n m g m " v a / a 4 a g i n 0 s e m i 0 / / a f 0 p 0 g e " 1 0 e s " 1 t . 0 . x t 0 j m i 1 s l f . o : t n i f i " d u f > = l " " l p 1 f " u > l l / 0 / d e f a u l t . j p g " ODD定義の解説 1. facsimile要素 < e / l < < < < e e d c c / a / l m e l o < c t < a e e s a n e o t a / t m n c s t l n L t < < a t e t > s e e t i t d d / t L n S フ e n m e s D e a < d t i t p ァ s t e n t e s t d a D s S e ク > n t f c a a t e t p c シ m t > m > t t a f > e ミ o R o i I y a t > c i リ d e d d I p R y > d 画 e f e e I e e p e 像 = = n F > f e n 情 " k " t マ > t 報 r e r = ニ k = 。 e y e " フ e " I p = p s ェ y f I l " l a ス = a I a s a m ト " c F c u c e へ t s マ e r e A の e i ニ " f " s 参 i m フ / a > " 照 d i ェ > c U a l ス e m R t e ト " o L a " へ d < . の m e / p m 参 i = d o o 照 n " e i d を O r s n e 含 c e c t = む c p > e " 。 u l r c < r a " h / s c / a d = e > n e " " g s 1 e c " u " > s > m a a g x e O = c " c o u p r t s " = > " u n b o u n d e d " / > ポイント : ...

はじめに TEI (Text Encoding Initiative) は人文学テキストのデジタル化において広く使われている標準規格です。本記事では、TEI P5で導入された Processing Model という機能を使って、TEI XMLから複数のフォーマット（HTML、LaTeX/PDF、EPUB3）への変換を実現した事例を紹介します。 https://www.tei-c.org/Vault/P5/3.0.0/doc/tei-p5-doc/en/html/TD.html#TDPM 対象プロジェクトは「校異源氏物語」で公開されているテキストを例とします。 https://kouigenjimonogatari.github.io/ 背景 これまで、以下の記事で紹介したように、変換処理を個別に行ってきました。 ODD/RNGファイルのカスタマイズによる、使用するタグの限定 XSLTを用いたHTMLへの変換 XSLTを用いたTeX/PDFへの変換 EPUBへの変換 それぞれの取り組みにおいて、個別の変換ルールなどを記載したファイルを作成する必要があり、その煩雑さが課題となっていました。 Processing Modelとは Processing Modelは、TEI要素の変換ルールを宣言的 に記述する仕組みです。従来は各出力フォーマット用に個別のXSLTを書く必要がありましたが、Processing Modelを使うことで: ODDファイル内で変換ルールを定義 できる 複数の出力フォーマット に対応可能（web、latex、epubなど） スキーマと変換ルールを一元管理 できる Processing Modelの構造 < e / l < < e e d m / l m e o < < < < < < m e e s d ! m / ! m / ! m / o m n c e - o < m - o < m - o < m d e t > l - d m / o - d m / o - d m / o e n S P > e o < m d e o < m d e o < m d l t p e H l d o d o e E l d o d o e L l d o d o e > S e r T S e u e d l P S e u e d l a S e u e d l p c s M e l t s e S U e l t s e S T e l t s e S e o L q p c l e B q p c l e e q p c l e c i n u b u > > q 3 u b u > > q X u b u > > q > d a o e e t I u e e t I u e e t C u e l u n h R n e o n h R n e o n h R u e n t c a e l n u c a e l n u c a e s n t n p e v n i c t e v n i c t e v n t c = a u i d n e p i d n e p i d o e " m t o o i e > u o o i e > u o o i m > p e u u t t u u t t u u t e < t r i s t r i s t r i L r / p = o p p = o p p = o a s d u " n a u " n a u " n T N e t i > n t i > n t i > e a s = n s = n s = n \ X m c " l p f " l p f " l p e > w i a o e i a o l i e c " e n n r p n n r a n r o b e < u e < t e s m m " " / p b " / p e " o m o > > o e " > o e x > n a d u r > u r " < n e t s t s > / d = p o p o o " u n u n u f c t t t o h R n R n p r a e a e a u n n m n m t p g d e d e R e e i < i e r " t / t i n s > i d i n d o o e o i n n s n E t > c > P i n > U o a B n m 3 > e < s / < d / e d s e c s > c > 主な要素: ...

はじめに 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属性は、モジュールから特定の要素のみを選択的に含める重要な機能です： ...

はじめに 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エンドポイント： ...

概要 @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の活用にあたり、参考になりましたら幸いです。

概要 以下の記事で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は次のような制約があります： ...