Tech

概要 以下の記事で、CSVファイルを用いたメタデータと画像の一括登録を行うためのモジュール「BulkImport」について紹介しました。 nakamura196.hatenablog.com こちらの記事では、CSVファイルを作成して登録する方法を紹介していますが、macOSでは問題ないものの、WindowsでCSVファイルを作成し、Omeka Sに登録した際、以下のエラーが生じる報告がありました。 File “media_template.csv” has media type “application/vnd.ms-excel”, not “text/csv”. これに対して、ODSファイルで登録することにより、本エラーが解消されました。 以下、本件についての詳細について説明します。 不具合1 CSVファイルでは上記のエラーが発生しましたが、TSVファイルでも以下のエラーが生じました。 File “media_template.tsv” has media type “application/octet-stream”, not “text/tab-separated-values”. 解決策1 この事象に対して、GitHubに以下のIssueがありました。フランス語なので、各種翻訳ツールを利用しながらご確認ください。 github.com 上記では、ODS（OpenDocument Spreadsheet）をお勧めします、と書かれています。なので、ODSファイルで登録してみたところ、エラーが表示されなくなりました。 なお、ODSファイルは、Microsoft ExcelやGoogle スプレッドシートの保存・出力形式の一つとして選択できます。 Bulk ImportモジュールでのODSファイルを用いた登録については、以下の図で示すオプションを選んでください。その後の設定などについては、CSVファイルを用いる場合と同様です。 不具合2 ODSファイルで登録することにより、エラーメッセージは表示されなくなりましたが、WindowsのMicrosoft ExcelでODSファイルを作成した際、一部の（特に）日本語の文字列が抜け落ちてしまう事象が確認されました。 詳細な原因はわかっておらず、またすべてのWindows端末で生じる不具合かは確認できていませんが、Omeka Sを使用している複数のプロジェクトで同様の事象が報告されました。 解決策2 この課題に対する暫定的な対応策として、Google スプレッドシートを用いてデータを作成し、ODSファイル形式でダウンロードしたファイルを使用することにより、上記の一部文字列が抜け落ちてしまう不具合が解消されました。 最善の解決策かはわかりませんが、同様の事象でお困りの方がいらっしゃれば、この方法をお試しいただけますと幸いです。 まとめ 本記事では、WindowsでBulkImportモジュールを使用する際の不具合と暫定的な解決策について紹介しました。 今回ご紹介した方法で、「うまくいった」「うまくいかなかった」ということがあれば、情報共有いただけますと幸いです。 また、他によい方法などがありましたら、お知らせいただけますと幸いです。

概要 最新のOmeka Sでは、Omeka Sへのアイテム新規登録時において、サイト毎に自動的にリソースとして登録するか否かを設定できるようになっています。 公式のマニュアルでは、以下に記載があります。 https://omeka.org/s/docs/user-manual/sites/site_settings/#general-settings これはOmeka Sが複数のサイトを管理できる設計となっているため、そのサイト毎に検索対象とするアイテム（リソース）を変更できるようになっています。 ただし、Omeka Sを用いて一つのサイトのみを管理する場合、Omeka Sへのアイテム登録にあわせて、サイトへもアイテムが検索対象として自動登録されるほうが効率的です。 本記事では、この設定について説明します。 設定方法 具体的には、以下のサイト毎の設定画面において、「Auto-assign new items」で設定を行います。こちらに有効化すると、自動的に新規アイテムが当該サイトの検索対象として追加されるようになります。 参考 なお、以下の画面のように、アイテム毎に追加したいサイトを設定することも可能です。 また、各サイトのリソース一覧から、登録条件を指定した一括登録も可能です。 まとめ Omeka Sにアイテムを新規登録したにもかかわらず、サイトにアイテムが登録されない、ということでお困りの方に対して、本記事が参考になりましたら幸いです。

概要 特定のプロパティを数値データとして設定できるようにするモジュール「Numeric Data Types」について説明します。プロパティは、日付と時刻（ISO）、または数値として指定できます。 特に、日付データに対する範囲検索を実現できる点などがポイントです。 github.com 公式のマニュアルは以下です。 omeka.org 上記のマニュアルを参考に、本モジュールの使い方を説明します。 リソーステンプレートの作成または編集 本モジュールを利用するには、リソーステンプレートを作成または編集して、特定のプロパティを数値データ型として設定する必要があります。リソーステンプレートの使い方は、以下に記載がありますが、いずれ紹介記事を作成したいと思います。 omeka.org 今回は、動画に関するリソーステンプレートとして「動画」を作成してみます。以下に示すように、「動画」というリソーステンプレートを作成し、その編集画面を開きます。 本モジュールでは、以下のData typesが追加されます。 Timestamp（xsd:date） 整数（o-module-numeric-xsd:integer） 期間（xsd:duration） 間隔 そのため、リソーステンプレートにおいて、これらの型を持つプロパティを作成します。具体的には、以下のように設定しました。 公開日（ex:date）：Timestamp バージョン（ex:version）：整数 再生時間（ex:duraion）：期間 準備時間（ex:prepare）：間隔 なお、独自の語彙「ex」の作成については、以下の記事を参考にしてください。 nakamura196.hatenablog.com プロパティのData types（型）の設定方法について説明します。リソーステンプレートの編集画面を開き、型を設定したいプロパティの「鉛筆」アイコンをクリックします。画面右部に表示されるパネルの「その他のオプション」 > 「Data types」において、「数字」 > 「Timestamp」を選択します。 結果として、今回は以下のリソーステンプレートを使用します。 ここで設定した各プロパティについて、入力フォーム、保存されるデータを以下で説明します。 データ登録 今回は、下図のようなデータを作成します。2021年3月11日に公開された動画について、再生時間、バージョン、準備期間、などを入力します。 アイテムの登録または編集画面において、リソーステンプレートの選択フォームで、先に作成した「動画」を選択します。 それにより、先に設定した各プロパティについて、Data types（型）に応じた入力フォームが表示されます。 例えば、Timestampを設定したプロパティ「公開日」は、下図のように日付（および時刻）の入力に特化したフォームが表示されます。 検索 上記の設定により、管理者画面および公開サイトに検索フォームが追加されます。 例えば、下図のように、プロパティ「公開日」について、「2021-03」以降の値を検索する、といった使い方が可能となります。 その他 API REST APIを通じて、登録したデータ（JSON-LD）を以下で確認できます。下図のように、型がRDFによっても記述されていること（xsd:date, xsd:duration, など）を確認できます。 https://diyhistory.org/nakamura196/api/items/13 モジュール「Bulk Import」を用いた一括登録 別のモジュール「Bulk Import」を用いることで、ここで説明した型を持つデータの一括登録を行うことができます。「Bulk Import」の使い方については、以下の記事を参考にしてください。 nakamura196.hatenablog.com 具体的には、以下に示すようなCSVファイルを用意します。ポイントとして、ヘッダー行に「^^numeric:timestamp」を与えることで、Data types（型）を指定した上での一括登録が可能です。 https://github.com/omeka-j/Omeka-S-module-BulkImport-Sample-Data/blob/main/item_with_datatype.csv まとめ 今回は、特定のプロパティを数値データとして設定できるようにするモジュール「Numeric Data Types」について説明しました。 ...

概要 Nuxt.jsでvis.jsを使用する方法を紹介するGitHubリポジトリを作成しました。 github.com 以下のページから、デモサイトをご確認いただけます。 https://nuxt-visjs.netlify.app/ 詳細 Nuxt.jsはVue.jsをより効果的に使えるフレームワークです。 またvis.jsは、ネットワーク図やタイムラインを作成することができる可視化ライブラリです。 visjs.org 今回、Nuxt.jsでvis.jsを使用する方法を紹介するGitHubリポジトリを作成しました。 「Timeline」「Network」「Graph2d」による基本的な可視化例を掲載しています。 Nuxt.jsを用いたvis.jsの利用に際して、お役にたてば幸いです。

概要 今回は、Omeka Sのアイテム詳細画面に対して、同じメタデータを持つアイテムの検索を可能とするリンクを付与するモジュール「Metadata Browse」について紹介します。 omeka.org 例えば、以下のようなことが可能となります。アイテム詳細画面の「キーワード／Subject」の値に「この値の全てのアイテム一覧を表示」リンクが付与され、そのリンクをクリックすると、当該メタデータを持つ検索結果のページに遷移します。 設定 本モジュールのインストール後、またはモジュールの設定画面から、以下の設定画面が表示されます。 この設定画面については、基本的にはそのままで問題ありません。 本モジュールを初めて使用する場合にはわかりにくい説明になりますが、「管理者側でグローバル設定を使用する」については、こちらにチェックを入れない場合、管理画面では、個々のサイトで設定された検索可能なプロパティ（の集合）が使用されます。一方、チェックを入れると、本設定画面でしていたプロパティが検索プロパティとなります。プロパティの指定方法としては、画面右部のパネルから、必要なものを選択します。 Direct Linksは、チェックを入れない場合、検索可能として設定したプロパティの値の下に「この値の全てのアイテム一覧を表示」というリンクが表示されますが、チェックを入れた場合、値に直接リンクが付与されます。以下は、チェックを入れた場合の例です。 図の中にも記述していますが、Direct Linksを有効にした場合、URIとして設定した値と、Metdata Browseで検索可能にした項目の区別がつきにくいため、基本的にはDirect Linksを無効にすることをおすすめします。 サイトにおける設定 サイト毎に検索可能なプロパティ（メタデータ）を指定できます。「サイト一覧」から設定したいサイトを選び、画面左部のメニューから「メタデータを見る（Browse）」を選びます。 上記の画面において、画面右部のパネルから、必要なプロパティ（メタデータ）を選択します。 まとめ 本モジュールにより、以下のアイテム詳細ページのように、同じメタデータを持つアイテムの検索を可能とするリンクを付与することができます。 diyhistory.org 本モジュールは、東京大学工学・情報理工学図書館の工学史料キュレーションデータベースで使用されています。 curation.library.t.u-tokyo.ac.jp Omeka Sで構築するサイトの利便性の向上につながれば幸いです。

ここでは、Omeka SのOaiPmhRepositoryのカスタマイズ例として、DC-NDL（Simple）にマッピングしてメタデータを公開する方法について説明します。 以下のGitLabリポジトリを適宜参考にしてください。 gitlab.com ※ 別途、OaiPmhRepositoryの紹介記事を執筆予定です。 ファイルの修正 以下のコミットを参考にしてください。 https://gitlab.com/nakamura196/Omeka-S-module-OaiPmhRepository/-/commit/702f1c693a62ae21ef03da495e3b4efd6060c561#d57ba0f1ebb8e2008538c451770f3fe535e1c2ca 具体的には、以下のファイルに対する修正を行います。 OaiPmhRepository/config/module.config.php 追加する語彙の情報を追加します。 OaiPmhRepository/src/OaiPmh/Metadata/DCNDLSimple.php 本ファイルにおいて、Omeka Sのプロパティと出力する項目とのマッピングを行います。上記のコミットの例は、あくまで当該リポジトリにおけるマッピングルールです。Omeka Sの導入機関におけるメタデータの記述ルールに基づき、適宜変更する必要があります。 結果 以下のようなOAI-PMHレコードを取得することができます。 ListRecords https://diyhistory.org/nakamura196/oai?verb=ListRecords&metadataPrefix=dcndl_simple GetRecord https://diyhistory.org/nakamura196/oai?verb=GetRecord&metadataPrefix=dcndl_simple&identifier=oai:diyhistory.org:3

以下、GitHubのREADME.mdの一部和訳です。 github.com CollectiveAccessについて CollectiveAccessは、博物館、アーカイブ、および研究のコンテキストで複雑なデジタルおよび物理コレクションを管理、説明、および発見するためのフレームワークを提供するWebベースのアプリケーションスイートです。これは2つのアプリケーションで構成されています。Providenceは、CollectiveAccessの「バックエンド」カタログコンポーネントです。高度に構成可能であり、さまざまなメタデータ標準、データ型、およびメディア形式をサポートします。Pawtucket2は、CollectiveAccessの汎用パブリックアクセス公開ツールです。プロビデンスで管理されているデータを中心にWebサイトを作成する簡単な方法を提供します。（Pawtucket2の詳細については、https://github.com/collectiveaccess/pawtucket2をご覧ください） CollectiveAccessは、オープンソースのGNU PublicLicenseバージョン3で無料で入手できます。

概要 Omeka SではRDF（Resource Description Framework）を用いてリソース（アイテム、アイテムセット、メディア、etc…）の情報を記述します。そのため、RDFのクラスやプロパティのコレクションである語彙をインポートする必要があります。この記事では、この既存の語彙のインポート方法について説明します。なお、公式マニュアルでは以下に記載があります。 omeka.org 具体的には、国立国会図書館が提供する国立国会図書館ダブリンコアメタデータ記述（DC-NDL）とSchema.org、ジャパンサーチの利活用スキーマの登録を例とします。 なお、代表的な語彙としてDublicon Core Terms（dcterms:）が挙げられます。Omeka Sのインストール直後のデフォルト設定では、Dublin Coreに加えて、Dublin Core タイプ（dctype:）、書誌オントロジー / Bibliographic Ontology（bibo:）、FOAF / Friend of a Friend（foaf:）が登録されています。 既存の語彙を可能限り使用することで、データの共有が容易となります。一方、独自の語彙を使用したい場合には、Custom Ontologyモジュールが使用できます。この使用方法については、以下の記事で紹介しています。 nakamura196.hatenablog.com RDFスキーマファイルの取得 語彙の登録にあたり、各語彙のRDFスキーマファイルを取得する必要があります。 DC-NDL 以下から取得することができます。 https://www.ndl.go.jp/jp/dlib/standards/meta/2020/12/ndl-terms.rdf 以下のページに掲載されています。 www.ndl.go.jp なお、接頭語は「dcndl」、名前空間のURIは「 http://ndl.go.jp/dcndl/terms/」です。 Schema.org 以下から取得できます。 https://schema.org/version/latest/schemaorg-current-https.rdf 以下のページに掲載されており、フォーマット（JSON-LD、RDF/XML、Turtleなど）を指定できます。 schema.org なお、接頭語は「schema」、名前空間のURIは「 https://schema.org/」です。 ジャパンサーチの利活用スキーマ ジャパンサーチの利活用スキーマ関連の語彙の例として、以下が挙げられます。 jps: https://jpsearch.go.jp/term/property# type: https://jpsearch.go.jp/term/type/ chname: https://jpsearch.go.jp/entity/chname/ ここでは、上記の接頭語「jps」の語彙を対象とします。本語彙は以下から取得できます。 https://jpsearch.go.jp/term/property Omeka Sへのインポート 画面左部のメニュー「語彙の一覧」にアクセスし、画面右上のボタンをクリックしてください。なお、2021年7月時点で、本ボタンの日本語訳に間違いがありますので、いずれ修正したいと思います。 その後、以下のような入力フォームが表示されますので、基本情報や登録するファイルの情報を入力します。ファイルについては、ファイルのアップロードまたはURL指定による読み込みが可能です。以下は「ジャパンサーチ利活用スキーマ」を登録した例です。 この方法で、「DC-NDL」「Schema.org」も合わせて登録した結果が、以下の「語彙の一覧」画面で確認できます。 Schema.org は膨大な数のクラスとプロパティが定義されていることがわかります。 なお、各語彙で定義されているクラスおよびプロパティ一覧の列の数字をクリックすると、当該語彙のクラスまたはプロパティの一覧画面に遷移します。また、ラベルの横にある省略アイコンをクリックすると、以下の図のように、そのクラスまたはプロパティの詳細な説明が表示され、さらに当該クラスまたはプロパティが使用されているアイテムの一覧を確認することができます。以下の例では、「dcterms:title」が2つのアイテムで使用されていることを確認できます。 更新 語彙の更新は、「語彙の一覧」ページに表示される鉛筆アイコンをクリックして編集画面に入ります。そして、新しい語彙のファイルまたはURLを指定して画面右上の「保存」をクリックします。 その後、以下のような更新前後の変更を確認する画面が表示されます。ここでは、「Schema.org」の「schema:highPrice」というプロパティのラベルを、試験的に変更した例です。問題ない場合には、画面右上の「変更を承認」をクリックして、更新作業を完了させます。 なお、2021年7月時点においては、クラスおよびプロパティの追加と変更のみが可能で、特定のクラスまたはプロパティの削除は非対応のようです。 削除 語彙の削除は、「語彙の一覧」ページに表示されるゴミ箱アイコンをクリックします。画面右部に確認パネルが表示されるので、「削除を確定」を押して作業を完了させます。 まとめ 以上、既存の語彙を追加、更新、削除する方法を説明しました。 ...

Cultural Japanプロジェクトの一環で開発したアプリケーション「IIIF Pocket」に関するご紹介です。 pocket.cultural.jp 本アプリケーションの説明は、以下のGoogleドキュメントにまとめています。 docs.google.com IIIFリソースの管理と活用にお役に立てば幸いです。

Omeka Sのマニュアル和訳です。以下の「リソース」>「アイテム」ページです。 omeka.org アイテム アイテムは、Omekaシステムの構成要素です。 Omeka Sでは、システム管理者からアイテムを利用できるようにしたり、自分のサイトにアイテムを追加したりできます。 アイテムは、管理ダッシュボードの左側のナビゲーションにある[アイテム]タブ（1つのボックスアイコン）に一覧表示されます。 各アイテムは行として表示され、次の列があります。 タイトル 編集 （鉛筆）、 削除 （ゴミ箱）、または 詳細の表示 （省略記号） する アイコン クラス アイテムの 所有者 アイテムが 作成され た日付。 アイテムをナビゲートおよび作成するためのオプションは、アイテムのテーブルの上に表示されます。 [アイテム]ウィンドウの右上には、[新しいアイテム の 追加]ボタンがあります。 左側には、アイテムのページ数が表示され、前後の矢印が表示されます。現在のページ番号は編集可能なフィールドです。有効なページ番号を入力し、キーボードのReturn / Enterキーを押して、そのページに移動します。 中央上部には、高度な検索用のボタンがあります。 右側のテーブルのすぐ上には、アイテムのテーブルを並べ替えるためのオプションがあり、2つのドロップダウンメニューがあります。1つ目は、 Title 、 Identifier 、 Class 、 Owner、 および （Date）Createdから 選択できます。2つ目は、昇順または降順で並べ替えることができます。適用するには、 並べ替え ボタンをクリックします。 これらとテーブルの間の左側には、選択した編集、すべて編集、選択したすべての削除、すべて削除などのバッチアクションのドロップダウンがあります。 （以下、今後追加予定。）

メタデータの言語設定の方法について紹介します。公式のマニュアルでは、以下に記載があります。 omeka.org 以下のメタデータ編集画面において、地球儀のアイコンをクリックすると、入力フォームが現れます。こちらにjaやenなどを入力することで、メタデータの言語属性を与えることができます。 この言語属性は公開サイトで表示されるほか、Omeka SのAPIで提供されるJSON-LDでもご確認いただけます。 https://diyhistory.org/nakamura196/api/item_sets/2 多言語の情報管理、サイト構築のお役に立てば幸いです。

概要 Item Sets Treeはアイテムセットの階層構造を設定できるモジュールです。 本モジュールの使い方についてご紹介します。 omeka.org 概要 インストール データ 機能紹介 親アイテムセットの設定 階層構造の確認 各アイテムセットのアイテム一覧画面における子孫のアイテムの表示 サイトでの表示 まとめ インストール モジュールのインストール後、以下の設定画面が表示されます。こちらはあるアイテムセットのアイテムを表示した際、その子孫のアイテムセットのアイテムも表示するかを指定するオプションです。後ほど違いを確認します。 データ 今回は「いらすとや」で公開されている画像を使用します。 www.irasutoya.com 「いらすとや」では「人物」＞「赤ちゃん」＞「子守唄のイラスト」といった形で階層構造を持っています。そこで、「人物」と「赤ちゃん」をアイテムセットとして、「子守唄のイラスト」や「タオルを使ってうつ伏せになる赤ちゃんのイラスト」などをアイテムとして扱います。 Omeka Sの画面では以下の通りです。 アイテムセットの一覧画面 アイテムセット「赤ちゃん」のアイテム一覧画面 アイテムセットとして「人物」「赤ちゃん」があり、アイテムセット「赤ちゃん」の中に、2つのイラストが格納されています。 機能紹介 親アイテムセットの設定 本モジュールをインストールすることにより、各アイテムセットの編集画面に「Item Sets Tree」というタブが表示されます。こちらで、親とするアイテムセットを指定することができます。 階層構造の確認 画面サブのメニューの「モジュール」 > 「Item Sets Tree」から、設定したアイテムセットの階層構造を確認できます。違いをわかりやすくするために、アイテムセット「人物」に加えて、「イベント」「祝日・行事」も追加しています。 各アイテムセットのアイテム一覧画面における子孫のアイテムの表示 上のインストールのところで述べた「Item sets include descendants」を有効化すると、各アイテムセットのアイテム一覧画面において、子孫のアイテムを表示することができます。 以下の例で示されたアイテムは、アイテムセット「人物」に含まれていませんが、「人物」の子アイテムセット「赤ちゃん」を介して表示されています。 サイトでの表示 アイテムセットの階層構造をサイトで表示する方法として、カスタムリンクを追加する方法と、サイトページにItem Sets Treeのブロックを埋め込む方法の2種類があります。 前者は、以下のナビゲーションメニューから追加できます。特にカスタマイズ等を行わない場合には、この方法が簡単です。 後者の場合は、サイトページの編集画面において、画面右部の「新規ブロックを追加」パネルから、Item Sets Treeを追加します。この方法の場合、ページのタイトル変更や、各アイテムセットの説明、そのアイテムセットに含まれるアイテム数を表示するかなどを設定できます。 後者の方法で作成したサイトページの例は以下です。 https://diyhistory.org/nakamura196/s/main/page/item-sets-tree まとめ 以上、アイテムセットの階層構造を設定できるItem Sets Treeモジュールについて説明しました。階層構造を持ったコレクションの管理などにおいて、参考になりましたら幸いです。

Omeka SのIIIF関連モジュールである「IIIF Server」「Image Server」「Universal Viewer」の説明およびインストール手順を以下で紹介しています。 youtu.be Omeka SでのIIIF配信において、参考になりましたら幸いです。

Omeka Sの導入方法およびモジュールの追加方法を以下でまとめています。Omeka Sの導入にあたり、参考になりましたら幸いです。 youtube.com

Cultural Japanで集約したIIIFマニフェストについて、それらをまとめたIIIFコレクションを以下からご確認いただけます。 https://www.kanzaki.com/works/2016/pub/image-annotator?u=https://app.cultural.jp/iiif-collection/collection.json なお、各々のIIIFマニフェストの利用にあたっては、各収録DBの利用条件を確認してください。 本コレクションには、Cultural Japan側で動的に生成したIIIFマニフェストを含みます。上記のコレクション一覧において、【動的生成】という表記で識別することができます。この動的生成にあたっては、AWS Lambdaを利用しており、リクエスト毎にJapan SearchのRDFストア、およびCultural JapanのRDFストアに問い合わせを行い、JSONデータを生成しています。なお、本動的生成IIIFマニフェストを作成する条件は、高精細画像（jps:accessInfo/schema:associatedMedia）を持つアイテムとしています。 動的生成マニフェストの場合、必ずしも提供元アイテムのすべての画像を含めることができていない（jps:accessInfo/schema:associatedMedia で指定された画像のみを使っている）点で不完全ではありますが、IIIFマニフェストを読み込むSelf Museumやその他のIIIF対応ビューアに取り組むことが可能となるといった利点もあります。 self-museum.cultural.jp 世界中で発信される日本文化に関するIIIFリソースを概観するとともに、IIIFを用いたアプリケーション開発の素材としてお役に立てば幸いです。

Mirador 3をVueで使用する方法を紹介するリポジトリを作成しました。Vueを使ったアプリケーション開発の参考になれば幸いです。 github.com 本リポジトリの作成にあたっては、以下を参考にさせていただきました。 github.com なお、別のより簡単な方法として、UMD（Universal Module Definition）ビルドを利用する方法もあります。単純にMirador 3を利用したい場合には、以下の方法をおすすめします。 github.com 上記サイトでは、（今回紹介するリポジトリで示したように）「パッケージマネージャーを通じたインストールは、より柔軟なカスタマイズを可能とします。」と記載されています。 Installing through a package manager can give you more flexibility for customization.

概要 Omeka SのIIIF Serverモジュールについて、Image APIを使用しない設定を追加する機能開発を行いました。これにより、レンタルサーバなどのリソースが限られた環境において、IIIFマニフェストなどの配信が容易となります。デジタルアーカイブシステムの持続性と利活用性の向上にむけて、本機能がお役にたてば幸いです。 背景 Omeka SのIIIF Serverモジュールは、Omeka Sに登録されたメタデータから、IIIFマニフェストファイルなどを生成するモジュールです。Omekaの様々なモジュールを開発されているDaniel-KM氏が主に開発されています。 github.com 画像については、Image Serverが必要となります。Awesome IIIFに挙げられているようなIIIF ServerをOmeka Sとは別に導入するか、Omeka SのImage Serverモジュールを使用することができます。後者については、Omeka Sのみで実現することができるため、LAMP環境が構築されたレンタルサーバを利用して、IIIF準拠の画像やマニフェストファイルなどの配信が可能となります。レンタルサーバはCPUやメモリといったリソースが限定されますが、メンテナンスコストが低い点が利点として挙げられます。 一方、レンタルサーバなどのリソースが限られた環境に、上述のOmeka SのImage Serverモジュールを導入するには課題があります。Image Serverモジュールが動的にタイル画像を配信する際、この処理に時間がかかり、タイル画像の表示が遅れる事象が確認されました。((なお、事前にタイル画像を生成するオプションも提供されています。これにより、リクエストがある度にタイル画像を生成する処理は不要となりますが、ディスク使用量の増加といったデメリットもあります。)) 解決策 IIIFマニフェストにおいて、必ずしもIIIF Image APIに準拠する必要はなく、単純にJPEG画像等を参照することもできます。((なお、これにより画像の動的なリサイズや回転、切り出し等ができなくなるため、機能が限定されるデメリットもあります。)) www.kanzaki.com そこで、レンタルサーバなどのリソースが限られた環境において、Omeka Sを用いたIIIFマニフェストの配信を行うための新たなオプションとして、このImage APIを使用せずに、Omeka Sに登録されたJPEG画像等をそのまま使用する設定をIIIF Serverモジュールに追加しました。以下のversion 3.6.4.3から本機能が利用できます。 github.com 具体的には、IIIF Serverモジュールの以下の設定画面で有効化できます。 本モジュールは、東京大学工学・情報理工学図書館の工学史料キュレーションデータベースで使用されています。 curation.library.t.u-tokyo.ac.jp 先述した通り、本設定の有効化により、IIIFで利用できる機能が一部制限されるため、最善の手段ということではありませんが、リソースが限られたサーバ上でのIIIFマニフェストの配信手段のオプションとして、本機能がお役にたてば幸いです。

概要 「起絵図」のIIIF実装を行いました。東京大学駒場図書館所蔵「大日本海志編纂資料」に含まれる越絵図を対象にしています。 https://utda.github.io/kaishi/ 以下の動画から概要をご確認ください。 「起絵図」のIIIF実装 作成したアプリケーション 東京国立博物館による「越絵図」の説明は以下です。 「起絵図（おこしえず）」は、平面図を描いた台紙に、壁面や天井の図を貼り付け、建物の立体的な構造を再現する折畳式の簡易模型です。とくに小さな空間に複雑な立体構造を持つ茶室の再現に適した図法として活用されました。（東京国立博物館 - 展示 日本美術（本館） 日本の博物学シリーズ 起絵図より） この越絵図の表現を、IIIFの「代替資源の選択」を用いて実装しました。また、ビューア「Mirador 2」をカスタマイズし、越絵図の動きをアニメーションで表現できるようにしました。ビューアを開き、画面上部の「Play」ボタンを押してください。 作成方法 IIIFマニフェストファイルの作成 IIIFの「代替資源の選択」を参考に、以下のようなIIIFマニフェストファイルを作成します。 https://github.com/utda/kaishi/blob/master/docs/iiif/7-2-47/manifest.json itemの配列に対して、重ねて表示したい画像の情報を追加します。この時、onに指定するカンバスのURIについて、重ねたい画像の表示箇所を指定します。以下の例は、元の画像（重ねられる画像）のサイズで作成したカンバスに対して、開始位置（2560,512）から幅（3072,4096）までの範囲に画像を重ねるための記述です。 https://github.com/utda/kaishi/blob/master/docs/iiif/7-2-47/manifest.json#L111 この範囲の指定が最もコストがかかる部分ですが、今回は以下のように、重ねる画像の位置情報が記述されたxmlファイルがすでに存在しました。 https://github.com/utda/kaishi/blob/master/src/data/xmls_layered/7-2-47.xml このxmlファイルに記載された情報から上記のitemsの配列を自動作成しました。 Mirador 2のカスタマイズ Mirador 2のカスタマイズ方法はこちらに記載があります。この記載を参考に、以下のような記述を追加しました。 https://github.com/utda/kaishi/blob/master/docs/mirador/index.html#L95 「Play」「Stop」「Check All」「Clear」ボタンを追加し、それぞれのボタンをクリックした際に実行される関数を追加しています。まず、Miradorのレイヤータブにあるチェックボックスの一覧を取得します。次にsetIntervalを使って、一定間隔毎にチェックボックスをクリックします。 まとめ 以上、起絵図をお楽しみいただくとともに、IIIFのレイヤー機能を使ったアプリケーション作成の参考になりましたら幸いです。

概要 「透過光画像を使ったIIIFアプリケーション」を作成しました。東京大学総合図書館所蔵の「シェリー書簡」を対象にしています。 utda.github.io 作成したアプリケーション 本アプリケーションではIIIFの「代替資源の選択」を用いて、オリジナル画像と透過光画像を比較する環境を提供します。 4つの方法で比較環境を提供しており、「IMAGE COMPARISON WITH A SLIDER 」「MIRADOR」「IIIF CURATION VIEWER」「IMAGE ANNOTATOR」を用いています。 IMAGE COMPARISON WITH A SLIDER Digiratiが開発した画像比較ビューアを使用しています。画面中央のスライダーを動かして、画像を比較することができます。 MIRADOR Miradorのレイヤー機能を用いて比較します。画面左部のレイヤータブをクリックし、opacityを変更してみてください。 IIIF CURATION VIEWER CODH（Center for Open Data in the Humanities）が開発しているIIIF Curation Viewer Embeddedを用いて表示します。画面右上のラジオボックスで表示画像を切り替えることができます。 Image Annotator 神崎正英氏が開発しているビューアで表示します。画面右上のchoiceで表示内容を切り替えてください。…を行うと、アノテーションを付与している箇所のみ、透過光画像を表示することができます。 作成方法 Level 0 IIIF Image APIに準拠した画像の作成 Digirati社製のビューアについては、IIIFマニフェストは不要で、IIIF Image APIに準拠した画像が必要になります。そこで、今回はIIIF対応のImage Serverを必要としないIIIF Image APIのレベル0に準拠した画像生成を行いました。この利点として、Image Serverが不要となることで、GitHub PagesやAmazon S3といった静的ファイルのホスティングサービスのみでの画像公開が可能となり、運用コストやセキュリティリスクを軽減することができます。一方のデメリットとしては、事前に作成したタイル画像を配信するため、任意の範囲の画像切り出しに対応していない点があげられます。この点はカンバスに対して領域を指定するアノテーションやキュレーションでは問題になりませんが、その領域の切り出し画像そのものがほしいといったニーズには答えられないことが多いです。 今回は特定の領域の画像そのものが必要ではなかったため、IIIF Image APIのレベル0を採用することにしました。なお、Mirador等のビューアを使った画像比較では、IIIF Image APIを使用しない方法もあります。しかし、今回はDigirati製のビューアで本APIが必要だったため、Image APIのレベル0を使ったIIIFマニフェストファイルを作成することにしました。 IIIF Image APIのレベル0に対応した画像生成にはこちらのスクリプトを参考にしました。また、Excelファイルでまとめた情報を入力として、本スクリプトを実行可能な環境も用意しました。お役に立てば幸いです。 上記リポジトリの例にあるように、今回はGitHub Pagesでタイル画像を公開しました。 github.com IIIFマニフェストファイルの作成 IIIFの「代替資源の選択」を参考に、以下のようなIIIFマニフェストファイルを作成します。 代替資源を使ったIIIFマニフェストファイルの作成については、こちらの記事を参考にしてください。 ...