Tech

概要 IIIF (International Image Interoperability Framework) Presentation API v3のマニフェストに含まれるアノテーション座標（xywh形式）を、Leaflet-IIIFを使用したマップビューアー上で正確に表示する方法について解説します。 この問題は一見シンプルに見えますが、Leaflet-IIIFの内部動作を理解しないと正確な座標変換ができません。 問題の背景 IIIFマニフェストのアノテーション形式 IIIF Presentation API v3では、アノテーションの対象領域は以下のようなxywh形式で指定されます： { } " " " " } " i t m b , t d y o o " " " a " p t d t v l r : e i y y a a g " v " p l n e " : a : e u g t h t " e u " t " i { : " a : t A o : g p n n " e " s n " T " " h : : e 雅 : t t x 屯 t / a " t 河 " p e t c u " j s x i o a , a : a o m l " / m n m B / p " e o e l , n d x e t y a . i " m o n , p r g l g " e / , . i o i r i g f / / i c i a i n f v / a c s a / n 1 v / a a s n / n 1 o # t x a y t w i h o = n 4 / 1 1 0 " 1 , 2 , 8 1 , 1 1 5 , 4 9 " このxywh=41012,81,115,49は： ...

はじめに 本記事では、Docker ComposeでセットアップされたOmeka-S環境を、volumeデータを含めて別のサーバーに移行する手順を解説します。データの整合性を保ちながら、安全に移行作業を進めることができます。 環境 移行元サーバー : Ubuntu 22.04 移行先サーバー : Ubuntu 22.04（新規セットアップ） 構成 : Omeka-S + MariaDB + phpMyAdmin + Traefik + Mailpit 移行の流れ 移行元サーバーでのバックアップ ローカルマシンへのダウンロード 移行先サーバーのDocker環境セットアップ データの復元と起動 ステップ1: 移行元サーバーでのバックアップ 1.1 現在の環境確認 # d # d o o 実 c D c 行 k o k 中 e c e の r k r コ e ン p r テ s ボ o ナ リ l を ュ u 確 ー m 認 ム e を 確 l 認 s 出力例： ...

はじめに RDF（Resource Description Framework）でデータを扱う際、「RDFS（RDF Schema）」と「SHACL（Shapes Constraint Language）」という2つの仕組みが出てきます。どちらもプロパティやクラスの制約を定義できますが、目的も動作も全く異なります 。 この記事では、特に混乱しやすい以下の疑問に答えます： rdfs:domain / rdfs:range と SHACL の sh:class / sh:datatype は何が違うのか？ RDFS の range と異なる SHACL 制約を設定してもいいのか？ range がクラス（foaf:Person）なのに SHACL でデータ型（xsd:string）を指定するのは問題ないか？ 1. RDFSとSHACLの根本的な違い RDFS：推論（Inference）のため RDFS は**「もしこのプロパティが使われたら、こういう知識が導き出せる」**という宣言です。 # e x R : D a F u S t h ス o キ r ー マ r r 定 d d 義 f f s s : : d r o a m n a g i e n e e x x : : P B e o r o s k o n ; . 意味 : ...

はじめに 本記事では、GakuNin RDM（Research Data Management）とDydra RDFデータベースを連携させた、研究データのメタデータ管理システムの開発について解説します。このシステムは、研究プロジェクトのファイル管理とDublin Coreメタデータの登録・検索を統合的に扱うことができます。 システム概要 アーキテクチャ ┌ │ │ └ ┌ │ │ │ └ ─ ─ ─ G ─ ─ ─ ─ a ─ ─ ─ ─ k R A ─ ─ N ( ─ ┌ │ ▼ u D P ─ ─ e A ─ ─ ─ N M I ─ ─ x p ─ ─ ─ i ─ ─ t p ─ ─ ─ n ─ ─ . ─ ─ ┐ │ │ │ ┘ ─ j R ┬ │ ┴ ─ s o ─ ─ ┌ │ │ │ └ ─ u ─ ─ ─ ─ ─ 1 t ─ ─ ─ D ─ ─ 4 e ─ ─ ▼ y R ─ ─ r ─ ┐ │ ─ d D D ─ ─ ) ─ ─ r F B ─ ─ ─ ─ a ─ ─ ─ ─ ─ ┐ │ │ ┘ ─ ─ ┐ │ │ │ ┘ 主要技術スタック: ...

はじめに Odeuropa Explorer は、ヨーロッパの嗅覚遺産をデジタル化した興味深いプロジェクトです。EU の Horizon 2020 研究プログラムの助成を受け、歴史的な匂いの体験を横断的に検索・探索できるプラットフォームを提供しています。 このプロジェクトでは、匂いに関連する情報を以下の3つの主要なカテゴリで分類しています： Smell sources : 匂いを発する物体や物質 Fragrant Spaces : 匂いに関連する場所や空間 Gestures and Allegories : 匂いに関する身振りや寓意的表現 本記事では、これらの語彙がどのような階層構造を持っているのか、Odeuropa vocabularies リポジトリで公開されている SKOS（Simple Knowledge Organization System）形式のデータを調査した結果を報告します。 調査方法 SKOS階層の可視化スクリプト 語彙の階層構造を理解するために、Node.js で SKOS Turtle ファイルを解析するスクリプトを作成しました。 i i c a } m m o s p p n y c c $ c c c c f } f } c f } t o o s n o o r o o o o o u o o o r r t c n n d n $ S n n n r c c i } c i } n i v c c c c } n r i } p t t s s f G s r K B s s s o o f o f P c f i o o o h ) F s f L S f t t . e t d O u t t t ( n n c n c b i } n r t s n n n i c c p ; i t ( t e $ f K u p t f S i c s G s ( o G s ( o r f a i i i s s s l o o r n c ( o v r s O n s d a c . ( l b n c o t e t l n e t b n o n r n o v t t t o d n n i d t o ! p e d S c t a r a o s ' d r a o n t a c t r s a ( a r t n i e l r s s n o n b L l f f t o t s l n y C o r n s s l b e b o t d ! r o s d l c e e t t t a p s r e C r = i r a e l c m o m a r c t u p a e p b r a e n r w h p i . a h . n H n L t o v o f o o e ( e ( n a d o e b r b l t r o d b r a o e i r t a b i l . i p i d e a e n r m $ n = d c p ' c p e w p c j e e s L o a e r M r w r e i e d e l o f s r e v c d l c o r = a o t h e s r e t o e f l . a a d r o a r e M r n d d l d g o L e r d e o e C e m ' d v f t n s t p M r L n c L s l b d e s a p o r a a t . ( r ( r a f a i l n r o p f f i $ s a c t t f a M a c t a e e e r . d . w M p r H h c = e ` E s i r s C c M n t ' s . s r . , e = p ' o p a b e b = n l r s l e s e a . c i a o n $ a t x c p o e a c s r ' N u d r p : ) r p e p = e g s e r e r p g h e s n c { c h l n p p e . d ; a a f e s t s / ) = l t l s t . c = n t M . e y r ( c o = i h = = y a c t . p f f m l . a t s t ; b = s c t h s o g = ( a s t a c e n n ( ( y e h t o l e i g d o w r n o o o e n s t s p e ( r r o p c n d ( i i c p o a s r i s z r F r r w o e n = f n r > t c t h b u . t b e c n t e a e c n s h t t f s . E b p e a i e e w a w e c e ( e o r b h ( r c h c U p r n h d L i o s ( p a ' a H p l , . . d w n c e . 0 s p r > o j a b o u y e r t r t i e a l p c c u c ; c i h e m w e M e o p m ) u t e a e s r a r ( p i L o } l x s d - = o o s h e e ( S ' a 3 r a M w n t a b s . 0 d c ( o d s c t ) a w $ d t , l n n h ( ( r ) y h t . / p a c . t { j m ) e t b a e i o U ; b e { , = e [ c c ( c ' a ; n t c o n ( p M e s c e a r . r d r v n r e r l = ? i v ] e e c o h r c t h r a ) ( a p u h c t { s v o e ) e c i l M a i = n e ; p p o n t c ( p ( g r ; ) p t b ( t c [ a a r . l e ) s a b n ' d l t t n c t h t : n / r ; ( s j s . h 0 l d , p y p ) . p e d c └ e s . c e p y t / u 1 o ) ) e u v ( ] u e u t g . l e h ─ n c ) s e p : ( l / l 9 w ; c b a s . e r [ s U r e g } x i ─ t o u p t / t F e l 9 e { t j l u o , ) ] h r e t e ` ) l n { b t / t i x , 9 r ; e u b b ) ) ( i t ( t ) d ' + c j . = w l l a / c e j j b ; s , u c ( ; = r e e s > w F e m 0 r t , e e r { u r o c > e : p p c u w i , p 2 e , c c o b i n n o n r t t b p . l l / l l t t a j n ; c n { . ' e s . j r w e ' e 2 a S a , . d e d e c l ├ f v e i 3 ) u . 2 t K b v e c e p e e ─ i a c n . t o - i O e S a r t n t p n ─ x l t t o { f r r o S l K l ) . t U t g , u . H r 8 g d n ( s O u ; v r U t ' e v i g ' / f s ' [ S e a = i r h ; n ) a e / ) ' - h p 0 ( ; l ) i e ) l r 2 ; , s i r ] ' u ; ) - w u a 0 y p e . b e ' { e r 0 ' n s f o r ) , 1 S ) c 4 t t L b o ; ; e ; h / e a a j a v t y 0 x x b e d i [ ( ( 2 t - e c e s ] v c / / n l t r i ; i o s t s ' . ' t s n k u # ) v ) e i c o r t , a , d t e s t y l e p / l p n u n = d t c e e u e u ) ) o ' ' l ) l n ) ) r ) ) l ; l e ; ; e ; , ) ) w # ; ; ' S ) e ; t ( ) ) { このスクリプトの主要な処理： ...

はじめに Dydraは、クラウドベースのRDFデータベースサービスで、SPARQL endpointとREST APIを提供しています。本記事では、Dydra APIを使用してプログラマティックにRDFデータを登録する方法を解説します。 前提条件 Dydraアカウント APIキー Node.js環境（v16以上推奨、Node.js使用時） 注意: 本記事のコード例では、サンプルとして以下を使用しています： アカウント名: your-account リポジトリ名: your-repository APIキー: your_api_key_here 実際に使用する際は、ご自身のDydraアカウント情報に置き換えてください。 APIの基本情報 エンドポイント構成 ベ 例 S S S ー : P P t ス A A a U h R R t R t Q Q e L t L L m : p e s Q U n h : u p t t / e d s t / r a : p d y t s y : e / : d : s / r / t / a s / a d . p s t y c a p e d o r a m r m q r e a / l q n . y l t c o ( s o u G ( m r E P ( / - T O P { a ) S O a c T S c c ) T c o / o u G u n E n t T t / / } y D / o E { u L r r E e - T p r E o e ) s p i o t s o i r t y o } r y 認証 DydraではBearerトークン認証を使用します： ...

はじめに 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 > 主な要素: ...

概要 Mirador viewerの表示方向（viewingDirection）をURLパラメータから動的に指定する実装について解説します。この機能により、同じマニフェストを左から右（left-to-right）または右から左（right-to-left）で表示することができます。 実装方法 1. URLパラメータの取得 URLからviewingDirectionパラメータを取得し、デフォルト値を設定します： c c o o n n U s s R t t L パ u v ラ r i メ l e ー P w タ a i か r n ら a g 表 m D 示 s i 方 r 向 = e を c 取 n t 得 e i w o n U R = L S u e r a l r P c a h r P a a m r s a . m g s e ( t w ( i ' n v d i o e w w . i l n o g c D a i t r i e o c n t . i s o e n a ' r ) c h ; ' r i g h t - t o - l e f t ' ; この実装では、パラメータが指定されていない場合は'right-to-left'（右から左）がデフォルトとして使用されます。 ...

はじめに Odeuropa（オデウロパ）は、ヨーロッパの歴史的文献から「匂い」に関する記述を抽出し、Linked Dataとして構造化したユニークなプロジェクトです。本記事では、SPARQLエンドポイントを通じて実際のデータを探索し、その構造と設計思想を明らかにしていきます。 Odeuropaとは プロジェクト名 : Odeuropa（Odeurs d’Europe = ヨーロッパの匂い） データベースURL : https://data.odeuropa.eu/ SPARQLエンドポイント : https://data.odeuropa.eu/repositories/odeuropa Webインターフェース : https://explorer.odeuropa.eu/ データモデルの全体像 OdeuropaはCIDOC-CRM（文化遺産のための概念参照モデル）をベースに、匂いに特化した拡張オントロジーを使用しています。 主要な概念と関係性 S F o r u ↓ a ↓ ├ │ │ ├ └ r g ─ ─ ─ c P m P e 1 e 6 E S E 0 n 7 m m x ( 6 t _ i ├ └ e p └ 文 _ r s ─ ─ l e ─ 献 i ( e s l r ) s テ f i F F i F _ キ e o 3 1 ( e 2 c ス r n _ _ 匂 n _ o ト s h g い c p m 断 _ ( a e ) e e p 片 t 放 d n r o ) o 出 _ e ( c s イ s r 体 e e ベ o a 験 i d ン u t イ v _ ト r e ベ e o ) c d ン d f e ト ← → ) → ─ → ─ S S O m m 中 b e e 心 j l l 的 e l l な c ハ t ( ( ブ 匂 匂 ( い い 発 ) ) 生 源 ) 重要なポイント: ...

はじめに Omeka-Sは強力なデジタルアーカイブシステムですが、デフォルトでは日本語の全文検索がほとんど機能しません 。本記事では、MroongaSearchモジュールを導入することで、日本語全文検索を実現する方法を解説します。 重要：なぜMroongaSearchモジュールが必要なのか Omeka-Sの標準検索の問題点 Omeka-Sの標準フルテキスト検索（FullTextSearchモジュール）は、InnoDBエンジンを使用しており、以下の致命的な問題があります： 日本語単語検索の例 ： デ 検 結 ー 索 果 タ 語 : : : ❌ 「 「 東 人 ヒ 京 工 ッ 大 知 ト 学 能 し で 」 な 人 い 工 知 能 を 研 究 す る 」 InnoDBのフルテキスト検索は英語のようなスペース区切り言語を前提としているため、日本語では： 単語検索が不可能 : 文字列全体が1つの単語として扱われる 部分一致も機能しない : FULLTEXTインデックスが日本語を正しく処理できない 検索結果がゼロ : ユーザーは何も見つけられない MroongaSearchモジュールの解決策 MroongaSearchモジュール は、この問題を2段階で解決します： 1. フォールバック機能（モジュール導入直後から有効） 重要 : MroongaSearchモジュールをインストールするだけで、特別な設定なし で日本語検索が動作するようになります。 ...

概要 Microsoft Azureが提供する2つのOCRサービス（Azure OpenAI GPT-4 VisionとAzure Document Intelligence）を使用して、日本語の縦書き原稿用紙のOCR処理を実施し、その結果を詳細に比較検証しました。 検証対象画像 画像ソース : Canvaテンプレート（400字詰め原稿用紙） URL : https://www.canva.com/ja_jp/templates/EAFbqUoH7P8/ 画像の特徴 : 20×20の400字詰め原稿用紙 縦書きレイアウト 薄いグリッド線（マス目） タイトル欄と本文欄の区別 正解データ（Ground Truth） 原 佐 原 こ 稿 藤 稿 の の ち 用 テ タ あ 紙 キ イ き に ス ト 書 ト ル く を テ 使 キ 用 ス す ト る が 場 入 合 り は ま 、 す 日 。 本 作 語 文 の や 全 小 角 論 を 文 使 を う 作 こ っ と た で り マ 、 ス 小 に 説 あ を っ 書 た い 文 た 字 り を な 打 ど つ に こ ご と 活 が 用 で く き だ ま さ す い 。 。 手 書 き で 使 用 し た い 場 合 は 、 こ の テ キ ス ト を 削 除 し 、 印 刷 し て ご 使 用 く だ さ い 。 1. Azure OpenAI GPT-4.1 による認識結果 認識されたテキスト 原 佐 原 こ 稿 藤 稿 の の 用 テ タ ち 紙 キ イ あ に ス ト き 書 ト ル く を テ 使 キ 用 ス す ト る が 場 入 合 り は ま 、 す 日 。 本 作 語 文 の や 全 小 角 論 を 文 使 を う 作 こ っ と た で り マ 、 ス 小 に 説 あ を っ 書 た い 文 た 字 り を な 打 ど つ に こ ご と 活 が 用 で く き だ ま さ す い 。 。 手 書 き で 使 用 し た い 場 合 は 、 こ の テ キ ス ト を 削 除 し 、 印 刷 し て ご 使 用 く だ さ い 。 評価 GPT-4.1は縦書きの原稿用紙に対して以下の特徴を示しました： ...

はじめに 本記事では、実際の原稿用紙画像を用いて 主要LLMモデルのOCR性能を比較検証しました。多くのOCRベンチマークが印刷文書や横書きテキストを対象とする中、日本独自の縦書き原稿用紙という特殊なフォーマット での認識精度を評価することで、各モデルの日本語文書理解能力をより実践的に検証しています。 本検証の特徴 原稿用紙という日本固有のフォーマットを使用 ：マス目に収められた文字、縦書きレイアウト、特有の余白構成など、複雑な要素を含む画像での検証 実用シーンを想定 ：作文、小説、論文など、実際の執筆場面で使用される原稿用紙での性能評価 最新モデルの網羅的比較 ：GPT-5、GPT-4.1、Gemini 2.5 Pro、Claude Opus 4.1、Claude Sonnet 4という最新モデルを同一条件で比較 検証概要 使用画像 画像ソース : Canvaテンプレート（400字詰め原稿用紙） URL : https://www.canva.com/ja_jp/templates/EAFbqUoH7P8/ 画像の特徴 : 20×20の400字詰め原稿用紙 縦書きレイアウト 薄いグリッド線（マス目） タイトル欄と本文欄の区別 検証条件 使用プロンプト : 「OCRして」（全モデル共通） パラメータ : 各モデルのデフォルト設定 実行時期 : 2025年9月 正解テキスト 原 佐 原 こ 稿 藤 稿 の の 用 テ タ ち 紙 キ イ あ に ス ト き 書 ト ル く を テ 使 キ 用 ス す ト る が 場 入 合 り は ま 、 す 日 。 本 作 語 文 の や 全 小 角 論 を 文 使 を う 作 こ っ と た で り マ 、 ス 小 に 説 あ を っ 書 た い 文 た 字 り を な 打 ど つ に こ ご と 活 が 用 で く き だ ま さ す い 。 。 手 書 き で 使 用 し た い 場 合 は 、 こ の テ キ ス ト を 削 除 し 、 印 刷 し て ご 使 用 く だ さ い 。 評価方法 本記事の精度スコアは、文字認識の正確性、レイアウト理解、文章構造の保持などを総合的に評価した主観的なスコア です。実用的な観点から、各モデルの強みと課題を分かりやすく数値化しています。 ...

はじめに PDFファイルから透明テキストレイヤーを抽出する際、「テキストの順序が元のPDFと異なってしまう」という問題に直面しました。本記事では、この問題の原因と、JavaScriptとPythonそれぞれでの解決策について解説します。誤っている点もあるかもしれませんが、参考になりましたら幸いです。 PDFの透明テキストとは PDFの透明テキストレイヤーは、PDFファイル内に埋め込まれた検索可能なテキスト情報です。OCR処理されたPDFや、デジタル生成されたPDFには、この透明テキストレイヤーが含まれており、以下のような機能を実現しています： テキスト検索 コピー＆ペースト スクリーンリーダーによる読み上げ 機械翻訳 問題：テキストの順序が乱れる理由 PDFの内部構造 PDFファイルは、テキストを「コンテンツストリーム」という形式で保存しています。このストリームには、テキストとその位置情報が含まれていますが、必ずしも読む順序で格納されているわけではありません。 例 [ [ [ ： 位 位 位 P 置 置 置 D : : : F コ x x x ン = = = テ 1 3 1 ン 0 0 0 ツ 0 0 0 ス , , , ト リ y y y ー = = = ム 2 4 3 の 0 0 0 概 0 0 0 念 , , , 図 テ テ テ キ キ キ ス ス ス ト ト ト = = = " " " 見 脚 本 出 注 文 し " " " ] ] ] 一般的な抽出方法の問題点 多くのPDF処理ライブラリは、以下のような手順でテキストを抽出します： ...

はじめに この記事では、TEI（Text Encoding Initiative）形式のXMLファイルをGitHubにアップロードし、誰でも参照できるURLを作成する手順を説明します。 TEI/XMLは、歴史文献や文学作品などのテキストを構造的に記述するための国際標準形式です。GitHubを使うことで、あなたの研究データを世界中の研究者と共有できるようになります。 必要なもの パソコン（Windows、Mac、Linuxのいずれか） インターネット接続 TEI/XMLファイル（すでにお持ちのもの） メールアドレス（GitHubアカウント作成用） サンプルファイルについて TEI/XMLファイルをお持ちでない方は、以下の『校異源氏物語』のTEI/XMLファイルを練習用として使用できます： サンプルファイルURL : h t t p s : / / r a w . g i t h u b u s e r c o n t e n t . c o m / k o u i g e n j i m o n o g a t a r i / 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 / m a s t e r / t e i / 0 1 . x m l このファイルをダウンロードする方法： ...

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

⚠️ 重要な利用上の注意 本記事で紹介するシステムは、外部サーバーに負荷をかける可能性があります。利用時は十分ご注意ください。 サーバー負荷 : 並列リクエストは対象サーバーに負荷を与えます DoS攻撃のリスク : 大量の同時アクセスはDoS攻撃と誤解される可能性があります 推奨アプローチ : 事前に画像をローカルにダウンロードし、OCR処理のみを並列実行することを推奨します 利用規約の確認 : 対象サーバーの利用規約を必ず確認し、必要に応じて事前許可を取得してください 適切なレート制限 : 実運用では慎重な並列数設定（5-10並列程度）を強く推奨します 責任ある利用 : サーバー管理者や他の利用者への配慮を忘れずに 本記事は技術的な実証実験の記録です。読者の皆様には責任を持った利用をお願いします。 はじめに 本記事では、国立国会図書館（NDL）が開発したNDL古典籍OCR Liteを活用し、Azure Container AppsでスケーラブルなOCR処理システムを構築した事例を紹介します。クラウドネイティブなアーキテクチャにより、従量課金とオートスケーリングを実現したシステムの設計と実装について解説します。 システム概要 アーキテクチャ I I I F 画 像 → A オ ( z ー 0 u ト - r ス 3 e ケ 0 ↓ ー レ C リ プ o ン リ n グ カ t ) a i n e r A p p s → N D L 古 典 籍 O C R → T E I X M L 出 力 主要コンポーネント OCRエンジン : NDL古典籍OCR Lite（日本古典籍特化） インフラ : Azure Container Apps（サーバーレスコンテナ） API設計 : REST API（画像URL → OCR結果） 出力形式 : TEI P5準拠XML スケーリング : 需要に応じた自動スケーリング NDL古典籍OCR Liteの特徴 日本古典籍に最適化されたOCR 縦書きレイアウト対応 : 古典籍特有の縦書き文書構造 読み順序最適化 : 右から左、上から下の日本語読み順 古典文字認識 : くずし字や変体仮名への対応 軽量実装 : Docker化によりクラウドデプロイ対応 Azure Container Appsの選択理由 サーバーレスコンテナの利点 # s c ス a m m c ケ l i a o ー e n x o リ : R R l ン e e d グ p p o 設 l l w 定 i i n 例 c c P a a e s s r : : i o 0 3 d 0 : 3 0 0 # # # ア 需 5 イ 要 分 ド 時 で ル : ス 時 ケ : 自 ー 動 ル コ 拡 ダ ス 張 ウ ト ン 0 コスト最適化 従量課金 : 使用した分のみ課金 0レプリカ : アイドル時は完全にコスト0 自動スケーリング : 需要に応じたリソース調整 システム実装 サーバーサイド実装 # f f f a a @ c r r r p p a l F o o o p i p a l m m m i s a = = . s d s f f s r e k l l i F A o I f a a m l p u m + s s p a i t a g i # r r k k l s ( e g e m e e N _ e k a ( e t a N s t D i r _ ( p ' O ( g D u u L m e o _ p / C s e L l r p s c _ , a R e _ t n O o t r n p ( l u O C r x _ a d i R f r C = r R t s m o / e ) l R e 統 i e e c i s : で o s 合 F m r _ = m o = 画 c u l p v _ ' a u 像 r l a o i ) / g r r 処 _ t s r c d e c e 理 s k t e o ' e q e , c ) ) u r A i s : e v r p m / s i e i p ' t c q , o ) . e u r a . e R t r p s e g r t s O s o , o C . c u R g e j r S e s s c e t s o e r ( _ n v ' s i i i i f c m n y e a g g l e e _ _ u i r m l a ' g ) e ( i m a g e _ u r l ) 読み順序アルゴリズム d e f s " r o " e r " t t 日 u _ 本 r - l j 古 n l i a 典 i n p 籍 s n e a の o e [ n 読 r [ " e み t " b s 順 e b b e 序 d b o _ ソ ( o x r ー l x " e ト i " ] a " n ] [ d " e [ 1 i " s 0 ] n , ] g , _ k o e r y # # d = e l x y r a 座 座 ( m 標 標 l b 降 昇 i d 順 順 n a （ （ e 右 上 s l → → ) i 左 下 : n ） ） e : ( TEI XML出力 < < ? T / x E < < < T m I t / f / t / E l e < t a < f e < t I x i f / e c s / a x b / e > v m H i < < f i s u < s c t o < b x e l e l t / r / i H i r z u s > d d / o t r n a e i < t e < < r l e m f o r i y i < < い d d > s s d D t t i s r n / e e a i a n f m > v p l づ i y i = e e l i t p e a N n s D d l c e a i b b れ v > o " r s e t l S s m D a p e e e e c l t の > n h > c S l e t p e L m S s r > x l e e y n n 御 = t > t e S m > 古 e t c > x m r > > p = = 時 " t m > t t A r 典 > m > m l x e " " に 1 p t 桐 m > u e 籍 t l : = = 1 1 か . : > 壺 t t f O > : i " " " . 0 / < > o = C i d 3 t 1 " / / m " R d = 7 r f " w t a h = " 2 a a e w i t t L " z 7 n c c n w t e t i s o " s s o c . l d p t u n c = r o t e s e r e l r " r d e > T : f - r i # e i i r / a 1 y p s s n - a / c - = t u p g c n g e 1 " i r = = . s i - " 2 o f " " o c t 1 9 n a # U r r h " u 2 " c z T g i u > l 4 > e o F / p b x " - n - n t . = 1 e 8 s i c " c " - " / o o 3 e / 1 ? 1 n m 3 r > - > . < 9 t 1 0 n 1 = " " r d " " > e l 0 c s - u . e p l l 7 r > a y 9 t b = 9 = / " " " n 1 / h d 1 > i l 4 g k 1 h o " " t / e > n o c r - l i t e " > 処理結果事例 小規模テスト処理（桐壺） 対象 : 東京大学所蔵「桐壺」 ページ数 : 32ページ 処理時間 : 約30秒 成功率 : 100% 並列数 : 10並列 コスト : 約$0.05 パフォーマンス特性 処 コ ス 理 ス ケ 時 ト ー 間 効 リ 率 ン = グ = 約 = 1 $ 秒 1 数 / . 秒 ペ 5 で ー 〜 0 ジ 2 → （ . 2 並 0 0 列 / レ 処 1 プ 理 0 リ 時 0 カ ） 0 ペ ー ジ システムの技術的特徴 1. コールドスタート対応 a s y n c " f " o d " r e コ f ー a t e ル t r x p ド t y c r ス e : e o タ m i r p i c ー p f e t f e ト t t s 時 a u ( a s の i t w a r H t r _ 自 n t a w n T t a w 動 e i a T e i i リ r m t i a P m s t ト a p _ t w E p e h ラ n t t a r t _ イ g i a i r e r " e > m s t o = e " ( e y r = t " m 0 n o , r a : = c c m y x i r T a ( _ 2 o _ i x i r . r m _ m e s e e r a t l q o e g r e u u t e i ( e e t r _ e a p s E i u s t ( t r e r t w ( r s l + e a i o : , m i m r 1 p t a ) m ) t _ g a : t e a x - i _ s _ m u r 1 e r e e ) ) l : t ) r i e s = 3 ) : 2. 設定の外部化 # O D D D C E E E 環 R F F F 境 _ A A A 変 A U U U 数 P L L L に I T T T よ _ _ _ _ る U M C O 設 R A O U 定 L X N T = _ F P h C I U t O D T t N E _ p C N F s U C O : R E R / R _ M / E T A y N H T o T R = u = E x r 1 S m - 0 H l o O c L r D - = s 0 e . r 3 v i c e . a z u r e c o n t a i n e r a p p s . i o 3. Swagger UI統合 # a p A i P I = v t d d 仕 e i e o 様 A r t s c の p s l c = 自 i i e r ' 動 ( o = i / 生 a n ' p d 成 p = N t o p ' D i c , 1 L o s . 古 n / 0 典 = ' ' 籍 ' , O 日 C 本 R 古 典 A 籍 P 専 I 用 ' O , C R 処 理 A P I ' , デプロイメント Azure Container Appsデプロイ # a z コ ン c - - - - - - - - - - テ o n r e i t i m m c m ナ n a e n m a n i a p e ア t m s v a r g n x u m プ a e o i g g r - - o リ i u r e e e r r 2 r 作 n o r o t s e e . y 成 e c c n r - s p p 0 r r e m e p l l 4 a - - e g o e i i \ G p s g n i r x c c i p e r t s t t a a r o t e s s c v u c r 8 r r i p o y 0 n 0 3 e c n . a 0 a e r t a l t g a z e - i u \ n r \ c e e r r c - r \ e . n i v o / o c r - a p p : l a t e s t \ Docker化 # s c ス a m m c ケ l i a o ー e n x o リ : R R l ン e e d グ p p o 設 l l w 定 i i n 例 c c P a a e s s r : : i o 0 3 d 0 : 3 0 0 # # # ア 需 5 イ 要 分 ド 時 で ル : ス 時 ケ : 自 ー 動 ル コ 拡 ダ ス 張 ウ ト ン 0 0 ...

はじめに Omeka Sでデジタルアーカイブを構築する際、メタデータの記述に標準的な語彙を使用することで、データの相互運用性が向上します。今回は、W3Cが策定したPROV-O（PROV Ontology）をOmeka Sに登録する手順を解説します。 PROV-Oは、データやデジタルオブジェクトの来歴（プロヴェナンス）情報を記述するためのオントロジーで、「誰が」「いつ」「どのように」データを作成・変更したかを構造化して記録できます。 前提条件 Omeka S（バージョン3.0以降）がインストール済み 管理者権限でログイン可能 インターネット接続環境（外部URLからのインポートに必要） 登録手順 1. 語彙管理画面へのアクセス Omeka S管理画面にログイン 左側メニューから「語彙の一覧」をクリック 右上の「新しい語彙を追加」ボタンをクリック 2. 基本情報の入力 語彙の基本情報を以下のように入力します： 項目 入力値 ラベル PROV-Oオントロジー コメント W3C PROV-O (PROV Ontology) - データの来歴情報を記述するための標準オントロジー 名前空間URI http://www.w3.org/ns/prov# 名前空間の接頭語 prov 重要 : 名前空間URIの末尾に#（ハッシュ）が必要です。これを忘れるとプロパティが正しく認識されません。 3. ファイルのインポート設定 Import typeの選択 「URL」を選択します（デフォルトで選択されているはずです）。 File URLの入力 以下のURLを入力します： h t t p s : / / w w w . w 3 . o r g / n s / p r o v - o このURLは内容交渉（Content Negotiation）に対応しており、Omeka Sが自動的に適切な形式（Turtle）で取得します。 ...

概要 以下の記事で、IIIFの機能を簡単に試すことを目的とした「画像コレクション管理」ツールについて紹介しました。 今回は、このツールの裏側で使われている技術について紹介します。 はじめに 画像コレクション管理ツールは、画像コレクションを国際標準規格であるIIIF（International Image Interoperability Framework）形式で管理・公開するためのWebアプリケーションです。本記事では、このツールの技術的な実装について、特にIIIF仕様の実装と地理空間情報の扱いに焦点を当てて解説します。 技術スタック フロントエンド : Next.js 14 (App Router), React, TypeScript バックエンド : Next.js API Routes データストレージ : AWS S3互換オブジェクトストレージ（Cloudflare R2） 認証 : NextAuth.js 地図表示 : Leaflet, MapLibre GL JS IIIF ビューア : Mirador 3, OpenSeadragon IIIF実装の詳細 1. IIIF Presentation API v2/v3の両方をサポート 本ツールは、IIIF Presentation APIのバージョン2とバージョン3の両方に対応しています。これにより、様々なIIIFビューアとの互換性を確保しています。 v2とv3の主な違い { } { } " " " " " } " " " " " I @ @ @ l s ] I @ i t l i I c i t a e " " I c d y a t I o d y b q @ c I o " p b e F n " p e u t a F n : e e m t : e l e y n t " l s v e " " n p v v e " : " " 2 x " : : c e a 3 x h : : の t h e " s の t t " 構 " t " " s : e 構 " t M { [ 造 : t s タ " s 造 : p a . p c イ : " " s n " . " s : ト s : " : i j . h : M ル [ c h / f a ] t / a " { : [ t / e " t / n , S . t e s : p e i e . p x t : x f q . : a " [ / a e u ] / m , " c / m s e / p タ a i p t n i l イ n i l " c i e ト v i e , e i . ル a f . " f c " s . c , . o ] の i o i m 配 o m o } 列 / / m , a m a a p a p n i n i i / i / f p f p e r e r s e s e t s t s " e " e , n , n t t a a t t i i o o n n / / 2 3 / / c c o o n n t t e e x x t t . . j j s s o o n n " " , , 2. マルチ言語対応 v3では、ラベルや説明文を言語別に管理できます： ...

本記事はAIが作成し、人間が追記しました。 概要 IIIF Georeference ViewerにおけるマップコンポーネントをLeafletからMapLibre GLへ移行し、複数の機能改善を実施しました。本記事では、実装した主要な機能とその技術的詳細について説明します。 https://nakamura196.github.io/iiif_geo/ 主要な改善点 1. 画像の自動回転機能 IIIF画像を地図上に正しい向きで表示するため、コントロールポイント（対応点）から自動的に回転角度を計算する機能を実装しました。 機能概要 画像座標と地理座標の対応点から、画像を北が上になるように回転させる角度を自動計算 2点間または3点以上の分布パターンから最適な回転角度を決定 URLパラメータによる回転角度の保存と復元 実装のポイント e } x p c ) c c c r u o ; o o o e t r n f n n n t i t 最 s . 画 s s 北 s u l も t p 像 t t を t r s f 離 r 座 基 n / u れ v o 標 i g 準 r c n た a p 系 m e と o n a c 2 l e で g o し t o l t 点 i r の V V た a r c i を d t ベ e e 角 t m u o 見 F i ク c c 度 i a l n つ e e ト t t の o l a け a s ル o o 差 n i t c る t ? と r r を D z e a （ u . 地 計 e e I l よ r r 理 = = 算 g A m c り e e 座 n a u 正 s s 標 { { = g g l 確 o 系 l e a な = u で x x g e R t 角 r の : : e ( o e 度 f c ベ o r t I 計 e e ク i g A o a m 算 a C ト m e n t t a の t o ル g o g a i g た u o か 2 2 l t o e め r r ら . . e i n R ） e d 回 x l F o . o s s 転 n r n t t . 角 - g o D s a f & 度 m e t i & を i - N g i l 計 m o ) o t f 算 g g r ; n e . 1 e t ( r g . o h f ( e x 1 D e ( o , . e a f m l g t ) e y n u t : g - r = r , e > y i i s ? m y m : . g : g c 2 A F o . g n e o y e g a r o l t d - 2 e u i . D r n i l e e a m a g [ t g t ; ] e 1 ) s . - : y g R } e o ; o t 1 a . t l i a o t n C } a ; l c u l a t i o n R e s u l t | n u l l { UI実装 自動回転ボタン（🔧アイコン）をOSDビューアーに配置 rotationパラメータが未指定の場合は自動的に回転角度を計算 手動での角度調整用スライダーも提供 2. LeafletからMapLibre GLへの移行 移行の背景 パフォーマンス向上 : MapLibre GLはWebGLベースのレンダリングにより、大量のマーカー表示時のパフォーマンスが向上 スムーズなアニメーション : 地図の移動やズーム時のアニメーションがより滑らかに ベクタータイルのサポート : ラスタータイルに加えてベクタータイルの表示が可能 実装のポイント i i c m } m m o a ) p p n p c s c z a ; o o s M I o t e o t r r t a n n y n o t t t p s t l t m r m L t a e e : i { " a i a i : r b m p b n n : z u M a I r c e m o t a p n e e r a i o i p l s . : p n m o , i t G v S i _ n b a L a m t t . C N r n 初 l a y i v o a e c 期 u p l a a n v - e 化 e C e l l t i g o s C u r g l = = n . e e o a / t v n , l t d r n a a t : i i e e i l e o s f w n u r f n t < e e , a C M M r [ l m a a . 0 s n a p p v ] e t p ( a . r l | { l s o i u t l b n e y , r u ! l e l , e M - l , a g > r l ( k . n e c u r s l , s l " ) P ; ; o p u p } f r o m " m a p l i b r e - g l " ; 3. 現在地表示機能 ブラウザのGeolocation APIを使用して、ユーザーの現在地を地図上に表示する機能を実装しました。 ...