EN
ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
ホーム » Tags

Zenn Fes 2025

Zenn Fes 2025 フリーセッション

Odeuropa Visualization: SKOS語彙とSPARQLを活用した香りデータの可視化プラットフォーム

Odeuropa Visualization: SKOS語彙とSPARQLを活用した香りデータの可視化プラットフォーム

はじめに 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クエリ例： SELECT DISTINCT ?source ?source_title ?fragment ?fragment_value ?emission ?smell ?smell_label ?source_image WHERE { ?emission od:F3_had_source ?x . ?emission od:F1_generated ?smell . # ソースとの関連（フラグメント経由または直接） { ?fragment ecrm:P67_refers_to ?emission . ?fragment rdf:value ?fragment_value . ?source ecrm:P165_incorporates ?fragment . } UNION { ?source ecrm:P67_refers_to ?emission . } } 2. 香り詳細ページ (/odeuropa-sources/item) 個別の香りに関する詳細情報を表示するページです。 ...

2025年10月24日 · 更新: 2025年10月24日 · 5 分 · Nakamura
Omeka Sで独立した作者データベースを構築する方法

Omeka Sで独立した作者データベースを構築する方法

はじめに 美術館や図書館のデジタルアーカイブでよく見られる課題として、「作品と作者の関係を適切に管理したい」というニーズがあります。特に、一人の作者が複数の作品を制作している場合や、複数の作者が共同で一つの作品を制作している場合、その関係性を明確に表現し、検索可能にすることが重要です。 この記事では、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. 作者の作品一覧を表示する 作者アイテムのページから、その作者が制作した全作品を一覧表示できます。 ...

2025年10月20日 · 更新: 2025年10月20日 · 1 分 · Nakamura
Leaflet-IIIFでのアノテーション座標変換の完全ガイド

Leaflet-IIIFでのアノテーション座標変換の完全ガイド

概要 IIIF (International Image Interoperability Framework) Presentation API v3のマニフェストに含まれるアノテーション座標（xywh形式）を、Leaflet-IIIFを使用したマップビューアー上で正確に表示する方法について解説します。 この問題は一見シンプルに見えますが、Leaflet-IIIFの内部動作を理解しないと正確な座標変換ができません。 問題の背景 IIIFマニフェストのアノテーション形式 IIIF Presentation API v3では、アノテーションの対象領域は以下のようなxywh形式で指定されます： { "id": "https://example.org/iiif/canvas/1/annotation/1", "type": "Annotation", "motivation": "commenting", "body": { "type": "TextualBody", "value": "雅屯河", "language": "ja" }, "target": "https://example.org/iiif/canvas/1#xywh=41012,81,115,49" } このxywh=41012,81,115,49は： x: 41012（左端のピクセル位置） y: 81（上端のピクセル位置） w: 115（幅） h: 49（高さ） を意味します。これらは元画像のピクセル座標 です。 Leaflet-IIIFの座標系 Leaflet-IIIFは、IIIF Image APIで提供される高解像度画像をタイル形式で表示するLeafletプラグインです。内部的には： CRS.Simple座標参照系を使用 画像を複数のズームレベルで縮小して管理 ズームレベルごとに異なる座標スケールを使用 この複雑な座標系のため、単純にmap.unproject()やpointToLatLng()を使っても正しい位置に配置できません。 試行錯誤の過程 失敗した試み1: map.unproject()の直接使用 // ❌ これは動かない const point = L.point(x, y); const latLng = map.unproject(point, 3); // ズームレベル3を指定 問題点 : unproject()は現在のマップの座標系を前提としており、Leaflet-IIIFが内部で使用している座標系とは異なります。 失敗した試み2: マップ境界からの比例計算 // ❌ これも不正確 const bounds = map.getBounds(); const normX = imgX / imageWidth; const normY = imgY / imageHeight; const lng = bounds.getWest() + (normX * (bounds.getEast() - bounds.getWest())); const lat = bounds.getNorth() - (normY * (bounds.getNorth() - bounds.getSouth())); 問題点 : Leaflet-IIIFは画像のアスペクト比を保持するため、マップ境界と実際の画像境界は異なります。 ...

2025年10月19日 · 更新: 2025年10月19日 · 4 分 · Nakamura
Omeka-S Docker環境を別サーバーに移行する完全ガイド

Omeka-S Docker環境を別サーバーに移行する完全ガイド

はじめに 本記事では、Docker ComposeでセットアップされたOmeka-S環境を、volumeデータを含めて別のサーバーに移行する手順を解説します。データの整合性を保ちながら、安全に移行作業を進めることができます。 環境 移行元サーバー : Ubuntu 22.04 移行先サーバー : Ubuntu 22.04（新規セットアップ） 構成 : Omeka-S + MariaDB + phpMyAdmin + Traefik + Mailpit 移行の流れ 移行元サーバーでのバックアップ ローカルマシンへのダウンロード 移行先サーバーのDocker環境セットアップ データの復元と起動 ステップ1: 移行元サーバーでのバックアップ 1.1 現在の環境確認 # 実行中のコンテナを確認 docker ps # Dockerボリュームを確認 docker volume ls 出力例： DRIVER VOLUME NAME local omeka-s-docker_mariadb local omeka-s-docker_omeka 1.2 バックアップファイルの作成 # /optディレクトリに移動 cd /opt # 設定ファイル等をバックアップ（約60MB） sudo tar -czf omeka-backup-$(date +%Y%m%d).tar.gz omeka-s-docker/ # Dockerボリュームのデータをバックアップ（約1GB） sudo docker run --rm \ -v omeka-s-docker_omeka:/data/omeka \ -v omeka-s-docker_mariadb:/data/mariadb \ -v /opt:/backup \ alpine tar -czf /backup/omeka-volumes-$(date +%Y%m%d).tar.gz -C /data . # バックアップファイルの確認 ls -lh /opt/*.tar.gz 出力例： ...

2025年10月16日 · 更新: 2025年10月16日 · 3 分 · Nakamura
RDFSとSHACLの使い分け：rangeとpropertyShapeの関係を理解する

RDFSとSHACLの使い分け：rangeとpropertyShapeの関係を理解する

はじめに 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 は**「もしこのプロパティが使われたら、こういう知識が導き出せる」**という宣言です。 # RDFS スキーマ定義 ex:author rdfs:domain ex:Book ; rdfs:range ex:Person . 意味 : ex:author が使われたら、主語（subject）は自動的に ex:Book のメンバーと推論される 目的語（object）は自動的に ex:Person のメンバーと推論される # 元のデータ ex:book1 ex:author ex:john . # 推論エンジンが自動的に導き出す知識 ex:book1 a ex:Book . # domain から推論 ex:john a ex:Person . # range から推論 特徴 : ...

2025年10月15日 · 更新: 2025年10月15日 · 5 分 · Nakamura
GakuNin RDMとDydraを連携したRDFメタデータ管理システムの開発

GakuNin RDMとDydraを連携したRDFメタデータ管理システムの開発

はじめに 本記事では、GakuNin RDM（Research Data Management）とDydra RDFデータベースを連携させた、研究データのメタデータ管理システムの開発について解説します。このシステムは、研究プロジェクトのファイル管理とDublin Coreメタデータの登録・検索を統合的に扱うことができます。 システム概要 アーキテクチャ ┌─────────────────┐ │ Next.js 14 │ │ (App Router) │ └────────┬────────┘ │ ┌────┴────┐ │ │ ┌───▼───┐ ┌──▼─────┐ │GakuNin│ │ Dydra │ │ RDM │ │ RDF │ │ API │ │ DB │ └───────┘ └────────┘ 主要技術スタック: Next.js 14 (App Router) NextAuth.js (OAuth 2.0認証) Dydra (RDFデータベース) GakuNin RDM API SPARQL (クエリ言語) 1. GakuNin RDMとの連携 1.1 OAuth 2.0認証の実装 GakuNin RDMはOAuth 2.0による認証をサポートしています。NextAuth.jsを使用してこれを実装しました。 ...

2025年10月14日 · 更新: 2025年10月14日 · 6 分 · Nakamura
Odeuropa Explorer の語彙階層構造を調査する

Odeuropa Explorer の語彙階層構造を調査する

はじめに 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 ファイルを解析するスクリプトを作成しました。 import $rdf from 'rdflib'; import fs from 'fs'; const SKOS = $rdf.Namespace('http://www.w3.org/2004/02/skos/core#'); async function visualizeHierarchy(ttlFile) { const store = $rdf.graph(); const data = fs.readFileSync(ttlFile, 'utf8'); $rdf.parse(data, store, 'http://example.org/', 'text/turtle'); // Get all concepts const concepts = store.match(null, $rdf.sym('http://www.w3.org/1999/02/22-rdf-syntax-ns#type'), SKOS('Concept')); // Build maps for broader/narrower relationships const broaderMap = new Map(); const narrowerMap = new Map(); const conceptLabels = new Map(); for (const concept of concepts) { const subject = concept.subject; // Get prefLabel const labels = store.match(subject, SKOS('prefLabel'), null); if (labels.length > 0) { conceptLabels.set(subject.value, labels[0].object.value); } // Get broader concepts const broaders = store.match(subject, SKOS('broader'), null); if (broaders.length > 0) { const broader = broaders[0].object.value; broaderMap.set(subject.value, broader); if (!narrowerMap.has(broader)) { narrowerMap.set(broader, []); } narrowerMap.get(broader).push(subject.value); } } // Print hierarchy recursively function printHierarchy(conceptUri, indent = '', visited = new Set()) { if (visited.has(conceptUri)) return; visited.add(conceptUri); const label = conceptLabels.get(conceptUri); const children = narrowerMap.get(conceptUri) || []; console.log(`${indent}${label}`); children.forEach((child, index) => { const isLast = index === children.length - 1; const prefix = isLast ? '└── ' : '├── '; printHierarchy(child, indent + prefix, new Set(visited)); }); } // Find and display top-level concepts const topLevelConcepts = []; for (const concept of concepts) { if (!broaderMap.has(concept.subject.value)) { topLevelConcepts.push(concept.subject.value); } } topLevelConcepts.forEach(concept => printHierarchy(concept)); } このスクリプトの主要な処理： ...

2025年10月13日 · 更新: 2025年10月13日 · 9 分 · Nakamura
DydraへのAPI経由でのRDFデータ登録ガイド

DydraへのAPI経由でのRDFデータ登録ガイド

はじめに 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の基本情報 エンドポイント構成 ベースURL: https://dydra.com/{account}/{repository} 例: https://dydra.com/your-account/your-repository SPARQL Query: /sparql (GET) SPARQL Update: /sparql (POST) Statements: /statements (POST/GET/DELETE) 認証 DydraではBearerトークン認証を使用します： Authorization: Bearer YOUR_API_KEY 実装方法 Dydra APIへのアクセスは、curl、Python、Node.jsなど様々な方法で実装できます。それぞれの方法を紹介します。 方法1: curlでの実装（最もシンプル） curlを使えば、プログラミング言語なしで即座にデータ登録が可能です。 基本的な認証 # APIキーを環境変数に設定 export DYDRA_API_KEY="your_api_key_here" export DYDRA_BASE_URL="https://dydra.com/your-account/your-repository" Turtle形式でのデータ登録 # data.ttl ファイルから登録 curl -X POST \ -H "Authorization: Bearer ${DYDRA_API_KEY}" \ -H "Content-Type: text/turtle" \ --data-binary @data.ttl \ "${DYDRA_BASE_URL}/statements" data.ttl の例: ...

2025年10月10日 · 更新: 2025年10月10日 · 5 分 · Nakamura
TEI Processing Modelで実現する宣言的なマルチフォーマット変換

TEI Processing Modelで実現する宣言的なマルチフォーマット変換

はじめに 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の構造 <elementSpec ident="persName" mode="change"> <desc>Personal name</desc> <model> <!-- HTML output --> <modelSequence output="web"> <model behaviour="inline"> <outputRendition>span</outputRendition> <desc>Inline span for person name</desc> </model> </modelSequence> <!-- EPUB3 output --> <modelSequence output="epub"> <model behaviour="inline"> <outputRendition>span</outputRendition> <desc>Inline span for person name in EPUB3</desc> </model> </modelSequence> <!-- LaTeX output --> <modelSequence output="latex"> <model behaviour="inline"> <outputRendition>\person</outputRendition> <desc>Custom LaTeX command for person names</desc> </model> </modelSequence> </model> </elementSpec> 主な要素: ...

2025年10月8日 · 更新: 2025年10月8日 · 3 分 · Nakamura
Miradorの表示方向を外部から制御する方法

Miradorの表示方向を外部から制御する方法

概要 Mirador viewerの表示方向（viewingDirection）をURLパラメータから動的に指定する実装について解説します。この機能により、同じマニフェストを左から右（left-to-right）または右から左（right-to-left）で表示することができます。 実装方法 1. URLパラメータの取得 URLからviewingDirectionパラメータを取得し、デフォルト値を設定します： // URLパラメータから表示方向を取得 const urlParams = new URLSearchParams(window.location.search); const viewingDirection = urlParams.get('viewingDirection') || 'right-to-left'; この実装では、パラメータが指定されていない場合は'right-to-left'（右から左）がデフォルトとして使用されます。 2. Mirador設定への適用 取得したviewingDirectionをMiradorの初期設定に組み込みます： const miradorConfig = { id: "viewer", windows: [{ id: 'known-window-id', loadedManifest: manifestUrl, viewingDirection: viewingDirection, // URLパラメータの値を使用 }], window: { allowClose: false, allowMaximize: false, allowFullscreen: false, hideWindowTitle: true, }, workspaceControlPanel: { enabled: false, }, }; 3. 使用例 右から左表示（デフォルト） https://example.com/viewer.xml または https://example.com/viewer.xml?viewingDirection=right-to-left 左から右表示 https://example.com/viewer.xml?viewingDirection=left-to-right XSLTでの実装 XSLTテンプレート内でこの機能を実装する場合、以下のコードをスクリプトセクションに追加します（mirador.xsl:222-230）: <!-- URLパラメータから表示方向を取得 --> const viewingDirection = urlParams.get('viewingDirection') || 'right-to-left'; // Miradorの初期設定 const miradorConfig = { id: "viewer", windows: [{ id: 'known-window-id', loadedManifest: manifestUrl, viewingDirection: viewingDirection, }], // ... その他の設定 }; 利用可能な値 MiradorのviewingDirectionには以下の値が使用できます： left-to-right - 左から右へページをめくる（欧文書籍など） right-to-left - 右から左へページをめくる（和書、アラビア語書籍など） top-to-bottom - 上から下へ（巻物など） bottom-to-top - 下から上へ 注意点 マニフェストファイル内でviewingDirectionが指定されている場合、マニフェストの設定が優先されます。この方法は主にマニフェストファイル内で表示方向が指定されていない場合に有効です この設定はwindow単位で適用されます URLパラメータはページ読み込み時にのみ評価されます ユーザーがMirador UI上で表示方向を変更した場合、URLパラメータの値は上書きされます 関連ファイル xsl/mirador.xsl - XSLT変換テンプレート（実装箇所）

2025年10月6日 · 更新: 2025年10月6日 · 1 分 · Nakamura
Odeuropa：歴史的文献から匂いを抽出するLinked Dataの世界

Odeuropa：歴史的文献から匂いを抽出するLinked Dataの世界

はじめに 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（文化遺産のための概念参照モデル）をベースに、匂いに特化した拡張オントロジーを使用しています。 主要な概念と関係性 Source (文献) ↓ P106_is_composed_of Fragment (テキスト断片) ↓ P67_refers_to ├─ Emission (放出イベント) ←── 中心的なハブ │ ├─ F3_had_source → Object (発生源) │ └─ F1_generated → Smell (匂い) ├─ Smell (匂い) └─ Experience (体験イベント) └─ F2_perceived → Smell (匂い) 重要なポイント: Fragment は直接的にEmission、Smell、Experienceを参照 Object へはEmission経由でアクセス（Fragment → Emission → Object） Emission がObjectとSmellを因果的に接続する中心的な役割 実例で学ぶデータ構造 1810年にドイツで出版された農業書「Grundsätze der rationellen Landwirthschaft」（合理的農業の原理）を例に、データ構造を見ていきましょう。 ...

2025年10月4日 · 更新: 2025年10月4日 · 3 分 · Nakamura
Omeka-SのMroongaSearchモジュールで日本語全文検索を実現する

Omeka-SのMroongaSearchモジュールで日本語全文検索を実現する

はじめに Omeka-Sは強力なデジタルアーカイブシステムですが、デフォルトでは日本語の全文検索がほとんど機能しません 。本記事では、MroongaSearchモジュールを導入することで、日本語全文検索を実現する方法を解説します。 重要：なぜMroongaSearchモジュールが必要なのか Omeka-Sの標準検索の問題点 Omeka-Sの標準フルテキスト検索（FullTextSearchモジュール）は、InnoDBエンジンを使用しており、以下の致命的な問題があります： 日本語単語検索の例 ： データ: 「東京大学で人工知能を研究する」 検索語: 「人工知能」 結果: ❌ ヒットしない InnoDBのフルテキスト検索は英語のようなスペース区切り言語を前提としているため、日本語では： 単語検索が不可能 : 文字列全体が1つの単語として扱われる 部分一致も機能しない : FULLTEXTインデックスが日本語を正しく処理できない 検索結果がゼロ : ユーザーは何も見つけられない MroongaSearchモジュールの解決策 MroongaSearchモジュール は、この問題を2段階で解決します： 1. フォールバック機能（モジュール導入直後から有効） 重要 : MroongaSearchモジュールをインストールするだけで、特別な設定なし で日本語検索が動作するようになります。 データ: 「東京大学で人工知能を研究する」 検索語: 「人工知能」 【MroongaSearchモジュールなし】 → ❌ 結果ゼロ 【MroongaSearchモジュールあり（Mroonga未設定でも）】 → ✅ LIKE '%人工知能%' にフォールバック → ✅ 検索結果が返る！ MroongaSearchモジュールのフォールバック機能 ： CJK（日本語・中国語・韓国語）の単一語検索を自動検出 LIKE '%term%' 検索に自動的にフォールバック Mroongaが設定されていなくても動作する これがないと、日本語全文検索がそもそもうまくいかない 2. Mroonga+TokenMecabによる高速・高精度検索（推奨） さらに、MariaDBにMroongaプラグインを設定すると： ✅ 形態素解析による精密な単語検索 ✅ 高速な全文検索（LIKEの数百倍高速） ✅ AND/OR検索の厳密な制御 MroongaSearchモジュールとは MroongaSearchは、Omeka-S用の全文検索強化モジュールです。 ...

2025年10月2日 · 更新: 2025年10月2日 · 3 分 · Nakamura