Zennfes2025free

はじめに Odeuropaは、ヨーロッパの香りの歴史を研究するプロジェクトで、絵画、文学、その他の歴史的資料に描かれた香りの表現を収集・分析しています。本記事では、OdeuropaのSPARQLエンドポイントを活用し、SKOS（Simple Knowledge Organization System）語彙体系に基づいた香りデータの可視化Webアプリケーションの実装について紹介します。 https://odeuropa-seven.vercel.app/ja/ プロジェクト概要 技術スタック フロントエンド : Next.js 15 (App Router) UI : Material-UI v5 国際化 : next-intl データ取得 : SPARQLクエリ (Odeuropa SPARQLエンドポイント) 言語 : TypeScript ホスティング : 静的サイト生成（SSG） 主な機能 1. 香り検索 (/odeuropa-sources) アプリケーションの中核となる機能で、Odeuropaプロジェクトが収集した香りの知覚イベント（smell perception events）を検索・閲覧できます。 主な特徴： 複雑なSPARQLクエリによるデータ取得 香り放出イベント（emission）、香りオブジェクト、ソース（絵画・文学作品など）、テキスト断片を結合 CRMベースのオントロジー（ecrm:P67_refers_to, od:F1_generatedなど）を活用 多軸フィルタリング SKOS語彙による香りの源でフィルタ（?xパラメータ） ソースタイプフィルタ（視覚的アイテム E36_Visual_Item / 言語オブジェクト E33_Linguistic_Object） リッチな情報表示 香りのラベル、ソース情報（タイトル、画像、URI） テキスト断片の引用 嗅覚体験の質的情報（Olfactory Experience） ページネーション - 20件ずつの効率的な表示 SPARQLクエリ例： S W } E H L E E R C E ? ? # { } } T e e { m m ソ U D i i ー N I s s ス ? ? ? I ? S s s と f f s O s T i i の r r o N o I o o 関 a a u u N n n 連 g g r { r C （ m m c c T o o フ e e e e d d ラ n n ? ? : : グ t t e e s e F F メ c c o m 3 1 ン e r r r u i _ _ ト c d m m r s h g 経 r f : : c s a e 由 m : P P e i d n ま : v 1 6 o _ e た P a 6 7 ? n s r は 6 l 5 _ s o a 直 7 u _ r o ? u t 接 _ e i e u s r e ） r n f r m c d e ? c e c e e f f o r e l ? e r r s _ l ? s r a p _ t x m s g o t i ? e _ m r o t s . l t e a l m l o n t ? e e t e e l . ? _ s m ? l e v i f _ m a ? s r l i l f s a a s u r i g b s e a o m e i g n e l o . m n n e . t ? n s . t ? o f u . r r a c g e m _ e i n m t a _ g v e a l u e 2. 香り詳細ページ (/odeuropa-sources/item) 個別の香りに関する詳細情報を表示するページです。 ...

はじめに 美術館や図書館のデジタルアーカイブでよく見られる課題として、「作品と作者の関係を適切に管理したい」というニーズがあります。特に、一人の作者が複数の作品を制作している場合や、複数の作者が共同で一つの作品を制作している場合、その関係性を明確に表現し、検索可能にすることが重要です。 この記事では、Omeka Sで作者データベースを独立して構築し、作品とリンクさせる方法について解説します。 課題の要点 独立した作者データベースの構築 : 作品データベースとは別に、作者（執筆者）のデータベースを作成し、両者をリンクさせることは可能か？ 複数作者への対応 : 一つの論文やデザインに複数の作者がいる場合、どのように表現すればよいか？ 解決方法 1. 作者を独立したアイテムとして登録する Omeka Sでは、作者を独立した「アイテム」として登録することで、作者データベースを構築できます。 手順： ステップ1: 作者用のアイテムセットを作成 「アイテムセット」から「新規アイテムセット」を作成 タイトルを「作者一覧」などとする このアイテムセットに全ての作者アイテムを収納 ステップ2: 作者アイテムを登録 「アイテム」→「新規アイテム」 クラスは foaf:Person を選択（推奨） 作者情報を入力： dcterms:title（作者名） foaf:firstName（名） foaf:familyName（姓） dcterms:description（経歴や専門分野） その他、所属機関など必要な情報 作成した「作者一覧」アイテムセットに追加 2. 作品から作者へリンクを設定する 作品アイテムの dcterms:creator（作成者）プロパティで、作者アイテムへの参照を設定します。 手順： ステップ1: 作品アイテムを編集 作品アイテムの編集画面を開く dcterms:creatorプロパティを見つける 「値を追加」→「Omekaリソース」を選択 ステップ2: 作者アイテムをリンク 「選択リソース無し」ボタンをクリック サイドバーが開き、アイテム検索が可能になる 作成済みの作者アイテムを検索 該当する作者を選択して「追加」 これにより、作品アイテムと作者アイテムが関連付けられます。 3. 複数作者への対応 Omeka Sでは、同一プロパティに複数の値を追加できます。 手順： 作品アイテムの dcterms:creator フィールドで、「値を追加」ボタンを再度クリック 2人目、3人目の作者アイテムを同様に選択して追加 必要な人数分だけ繰り返す 重要なポイント： Dublin Coreの dcterms:creator は、複数の値を持つことが想定されています 同じプロパティに複数の作者アイテムをリンクすることで、共著論文やコラボレーション作品を適切に表現できます 4. 作者の作品一覧を表示する 作者アイテムのページから、その作者が制作した全作品を一覧表示できます。 ...

概要 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モジュールをインストールするだけで、特別な設定なし で日本語検索が動作するようになります。 ...