記事一覧

Nuxt 2を用いたMirador 3の使用例を以下のGitHubリポジトリで紹介しています。 https://github.com/nakamura196/nuxt-mirador ただ上記のリポジトリにおいて、production環境において不具合が生じることがわかりました。具体的には、ページ遷移後にMiradorの表示が崩れてしまう不具合です。 送っていただいたissue https://github.com/nakamura196/nuxt-mirador/issues/1 このissueについて、さらに不具合を修正したPull requestも送っていただきました。 https://github.com/nakamura196/nuxt-mirador/pull/2 具体的には、以下に示すように、beforeDestroyでunmountする必要がありました。 https://github.com/nakamura196/nuxt-mirador/pull/2/files 自分では不具合の解消方法が分かりかねたので、大変助かりました。 Nuxt（Vue）におけるMirador 3の使用において、参考になりましたら幸いです。

概要 先日以下の記事およびノートブックを作成しました。 上記の記事執筆時点では、以下の入力形式にのみ対応していました。 Image file mode（-s fで指定） (単体の画像ファイルを入力として与える場合はこちら) ただ、以下の記事での検証により、複数の画像に対して上記のオプションを適用することは、オーバーヘッドが大きいことがわかりました。 そこで、以下の入力形式にも対応できるようにノートブックを修正しました。 Sigle input dir mode（-s sで指定）※デフォルト 以下、上記入力オプションの使い方について説明します。 使い方 「2.設定」の「input_structure」において、「s」を選択してください。従来の「Image file mode」を使用する場合には、「f」を選択してください。 「input_structure」で「s」を選んだ場合、「extensions」の項目は無視されます。 また、入力フォルダの作成方法に注意点があります。以下の入力フォルダのパスを指定する場合を例とします。 /content/drive/MyDrive/ndl_ocr/input/ この時、以下のように、「input」フォルダの下に「img」フォルダを作成し、その下に画像を格納します。 上記の準備および設定を行なった上で実行を行うと、「Sigle input dir mode」によりOCR処理を実行することができます。 まとめ 今回作成したノートブックについて、「f（Image file mode）」を選択した場合、指定した入力フォルダ内の階層構造を特に意識せずに実行することができます。ただしこのモードでは画像ファイル毎にプログラムを実行するため、一部オーバーヘッドが生じます。大量の画像ファイルを対象に実行する場合には、「s（Sigle input dir mode）」を選択することをお勧めします。 誤った理解をしている点があるかもしれませんが、参考になりましたら幸いです。

先日、以下の記事を執筆しました。 今回は、Google Colabを用いたNDLOCRの実行にかかる時間について、かんたんな調査を行なったので、その結果をまとめます。 設定 GPUは以下です。 Fri Apr 29 06:26:29 2022 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 460.32.03 Driver Version: 460.32.03 CUDA Version: 11.2 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Tesla V100-SXM2... Off | 00000000:00:04.0 Off | 0 | | N/A 35C P0 23W / 300W | 0MiB / 16160MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ 以下の画像を用いました。サイズは5000 x 3415 px で、 1.1 MB でした。 ...

Google Colabを用いたジャパンサーチRDFストアに対するSPARQLの実行例を示すノートブックを作成しました。Pythonを用いたRDFストア利用時の参考になりましたら幸いです。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ジャパンサーチのRDFストアを対象したSPARQLチュートリアル.ipynb 他にも以下のような参考サイト・チュートリアルがあります。 https://www.kanzaki.com/works/ld/jpsearch/ https://lab.ndl.go.jp/data_set/tutorial/

概要 ndl-labでは、以下の図表自動抽出プログラムが公開されています。 https://github.com/ndl-lab/tensorflow-deeplab-v3-plus 今回は上記のプログラムについて、Google Driveを用いた画像の入力と結果の保存までの手続きを含むGoogle Colabの使用方法をまとめましたので紹介します。 ノートブック 今回作成したGoogle Colabのノートブックには以下からアクセスいただけます。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ndl_deeplab.ipynb Googleドライブ上に入力画像のフォルダを用意することで、図表の自動抽出処理を実行することができます。 基本的な操作方法は、上記のノートブック内の説明をご確認ください。以下、実行例を紹介します。 本ノートブックでは、（1）入力フォルダを準備する方法と、（2）IIIFマニフェストファイルのURLを入力する方法の2つがあります。それぞれについて説明します。 実行方法：（１）入力フォルダの準備 入力フォルダの準備 まず、Google Drive上に画像ファイルを格納したフォルダを作成します。今回は、以下のように、マイドライブに「ndl_deeplab > input」というフォルダを作成して、その直下に画像ファイルを格納しました。 ノートブックの実行：1.初期セットアップ 先に示した以下のノートブックにアクセスしてください。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ndl_deeplab.ipynb そして、用意されている2つの再生ボタンを押してください。少し時間がかかりますが、必要なライブラリ等をインストールします。また、本作業については、ノートブック立ち上げ後の初回のみ実行します。 ノートブックの実行：2.設定 次に、処理の適用対象を設定します。以下のように、input_dirに先に用意したフォルダへのパスを指定します。またmanifestの値を空にしてください。これにより、input_dirに格納した画像ファイルを対象に処理を実行します。 再生ボタンを押して、設定は完了です。 ノートブックの実行：3.実行 「3.実行」の再生ボタンを押してください。 完了後は、以下のように、指定した出力フォルダに処理の開始時間に基づくフォルダが作成され、その中に認識結果が保存されます。 図表の抽出に失敗してしまう場合もありますが、今回は以下のように、正しく図表を抽出することができました。 実行方法：（2）IIIFマニフェストファイルのURLを入力する ノートブックの実行：1.初期セットアップ これは先ほどのプロセスと同じです。2回目以降はスキップしてください。 ノートブックの実行：2.設定 以下のように、manifestに処理対象とするIIIFマニフェストファイルのURLを入力してください。 またprocess_sizeに処理対象のcanvas数を指定します。-1を入力すると、マニフェストファイルに含まれるすべてのcanvas（画像）に対して処理を実行します。 再生ボタンを押して、設定は完了です。 ノートブックの実行：3.実行 「3.実行」の再生ボタンを押してください。 今回の場合、以下のように、まず画像のダウンロードが行われます。 ### マニフェストが指定されている場合は、画像のダウンロード ### 80%|████████ | 4/5 [00:13<00:03, 3.41s/it] その後、抽出処理が始まります。処理対象の画像が多い場合、完了まで時間がかかります。 抽出処理の完了後、「実行方法：（１）入力フォルダの準備」で示した通り、指定したGoogleドライブ上の出力フォルダに認識結果が保存されるほか、以下のように、認識結果をIIIFマニフェストファイルの形で出力し、それをMiradorビューアで閲覧するためのURLが表示されます。 ### マニフェストが指定されている場合は、認識結果をマニフェストファイルに出力 ### /content/drive/MyDrive/ndl_deeplab/output/20220429095851/manifest.json にマニフェストファイルを保存しました。 また以下のリンクから、認識結果を確認できます。 https://localhost:8000/ 上記のリンクをクリックすると、以下のように、Miradorを用いて認識結果を確認することができます。 まとめ 今回は、NDLラボが公開する図表自動抽出プログラムについて、Google Colabを用いた実行方法の一例を示しました。他の方の参考になりましたら幸いです。 このようなアプリケーションを公開してくださったNDLの関係者の方々に深く感謝いたします。

概要 前回、Google Cloud PlatformのCompute Engineを用いたNDLOCRアプリの実行方法を共有しました。 ただし、上記の方法は手続きが一部面倒で、かつ費用がかかる方法です。本番環境で使用するには適した方法ですが、小規模に、または試験的に使用するにはハードルが高い方法でした。 この課題に対して、 @blue0620 さんがGoogle Colabを用いたNDLOCRアプリの実行方法を作成されました。 https://twitter.com/blue0620/status/1519294332159012864 上記のノートブックを使用することにより、簡単に（「ランタイム」>「すべてのセルを実行」からワンクリックで）、かつ無料でOCRを実行することができます。 今回は、このノートブックを参考にして、Google Driveを用いた画像の入力と結果の保存までの手続きを含むGoogle Colabの使用方法をまとめましたので紹介します。 ノートブック 今回作成したGoogle Colabのノートブックには以下からアクセスいただけます。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ndl_ocr_folder.ipynb Googleドライブ上に入力画像のフォルダを用意するだけで、OCR処理を実行することができます。 基本的な操作方法は、上記のノートブック内の説明をご確認ください。以下、実行例を紹介します。 実行方法 入力フォルダの準備 まず、Google Drive上に画像ファイルを格納したフォルダを作成します。今回は、以下のように、マイドライブに「ndl_ocr > input」というフォルダを作成して、その直下に画像ファイル「image_1.jpg」とフォルダ「dir_1」を作成し、フォルダ「dir1」の中に画像ファイル「image_2.jpeg」を格納しました。 ツリーで見ると、以下のような形です。 今回作成したプログラムでは、指定した入力フォルダに含まれる画像を再帰的に探索します。 ノートブックの実行：1.初期セットアップ 先に示した以下のノートブックにアクセスしてください。 https://colab.research.google.com/github/nakamura196/ndl_ocr/blob/main/ndl_ocr_folder.ipynb そして、以下に示す再生ボタンを押してください。少し時間がかかりますが、必要なライブラリ等をインストールします。また、本作業については、ノートブック立ち上げ後の初回のみ実行します。 再生ボタンを押した後、「このノートブックに Google ドライブのファイルへのアクセスを許可しますか？」と聞かれるので、「Google ドライブに接続」を押して、許可してください。 その後、しばらくの間、再生中のボタンが表示されます。これが完了したら、次のステップに進みます。 ノートブックの実行：2.設定 次に、OCR処理の適用対象を設定します。 入力フォルダ（input_dir）は、上述した「/content/drive/MyDrive/ndl_ocr/input/」としました。 出力フォルダ（output_dir）は、「/content/drive/MyDrive/ndl_ocr/output/」としました。このフォルダは事前に作成しておかなくてもかまいません。 拡張子（extensions）は、今回は拡張子がjpgとjpegの画像を格納したので、これら二つを設定します。 processは、以下を参考にしてください。 https://github.com/ndl-lab/ndlocr_cli#推論処理の実行 ノートブックの実行：3.実行 「3.実行」の再生ボタンを押してください。 再生ボタンを押した後、以下のように、再生中ボタンが表示されます。 完了後は、以下のように、指定した出力フォルダに認識結果が保存されます。入力フォルダの構造を維持する形で出力するようにしています。また、設定において選択したprocessの値をフォルダ名に付与しています。processの値を変えて実行した際、それぞれの出力フォルダが残るようにしています。 以下のように、Googleドライブ上で認識結果の保存と確認が可能です。 まとめ 上記の方法により、Googleドライブ上に格納した画像に対するOCR処理と、その結果の保存を無料で 行うことができます。保存した結果を、さまざまな用途に活用することができます。 Google Colabを利用した実行方法を示してくださった @blue0620 さんに感謝いたします。 追記 2022.05.02 本ノートブックの改良版であるVersion 2を作成しました。以下の記事も参考にしてください。 ...

更新履歴 2022/09/08 スクリプトの記述を最新化しました。 概要 Amazon Lightsailは以下のような説明がなされています。 Amazon Lightsail は、コンテナなどのクラウドリソースを予測可能な低価格で簡単に管理できる、使いやすい仮想プライベートサーバー (VPS) です。 今回は、このAmazon Lightsailを用いたOmeka Sの構築方法を紹介します。合わせて、データベースの公開にあたり一般的に求められる「独自ドメイン」「SSL」設定についても扱います。 Amazon Lightsail インスタンスの作成 以下のページにアクセスします。 https://lightsail.aws.amazon.com/ls/webapp/home/instances そして、以下の「Create Instance」ボタンをクリックします。 「Select a blueprint」において、「LAMP (PHP 7)」を選択します。 「Choose your instance plan」において、インスタンスプランを選択します。今回は最も低価格のプランを選びました。 起動したら、以下のインスタンスのページにアクセスして、「Connect using SSH」ボタンを押します。 以下の画面が表示されます。 Linux ip-172-26-5-202 4.19.0-19-cloud-amd64 #1 SMP Debian 4.19.232-1 (2022-03-07) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. ___ _ _ _ | _ |_) |_ _ _ __ _ _ __ (_) | _ \ | _| ' \/ _` | ' \| | |___/_|\__|_|_|\__,_|_|_|_|_| *** Welcome to the LAMP packaged by Bitnami 7.4.28-14 *** *** Documentation: https://docs.bitnami.com/aws/infrastructure/lamp/ *** *** https://docs.bitnami.com/aws/ *** *** Bitnami Forums: https://community.bitnami.com/ *** bitnami@ip-172-26-5-202:~$ インスタンス内での作業 ファイルの移動 まず、必要なファイルのダウンロードや移動を行います。 ...

概要 NDLが公開したNDLOCRアプリケーションについて、GCP（Google Cloud Platform）の仮想マシンを用いて実行してみましたので、その備忘録です。本アプリケーションの詳細については、以下のリポジトリをご確認ください。 https://github.com/ndl-lab/ndlocr_cli VMインスタンスの作成 GCPのCompute Engineにアクセスして、画面上部の「インスタンスを作成」ボタンをクリックします。 「マシンの構成」の「マシンファミリー」について、「GPU」を選択します。そして「GPUのタイプ」において、今回は最も安価な「NVIDIA T4」を選択します。「GPUの数」は1に設定しました。 「シリーズ」については、「n1-standard-2」を選択します。 「n1-standard-1」では、以下のようにMemoryErrorが発生してしまいました。 次に、「ブートディスク」において、「イメージの切り替え」を選択します。そして推奨された「Deep Learning on Linux」を選択します。 この時の注意点として、「サイズ」をデフォルトの50GBから、100GBに変更しました。50GBの場合、no space leftが発生しました。 以下は、環境構築が済んだ後の情報ですが、40GB強が使用済みとなるため、余裕を持った「サイズ」にしておくことをお勧めします。 u_nakamura_satoru@instance-4:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 7.4G 0 7.4G 0% /dev tmpfs 1.5G 8.4M 1.5G 1% /run /dev/sda1 492G 41G 432G 9% / tmpfs 7.4G 0 7.4G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup /dev/sda15 124M 5.7M 119M 5% /boot/efi tmpfs 1.5G 0 1.5G 0% /run/user/1001 その後、画面下部の「作成」ボタンを押してVMインスタンスの作成を完了します。 ...

概要 The New York Public Libraryでは、Digital Collections APIを提供しています。 http://api.repo.nypl.org/ 本記事では、このAPIの使い方の一例について説明します。 サインアップ まず以下のリンクをクリックして、サインアップを行います。 以下のようなフォームが表示されますので、必要な情報を入力します。 入力後、 Welcome to NYPL API という件名のメールが届きます。このメールの中に、 Authentication Token が記載されています。 メタデータの抽出 The New York Public Library Digital Collections APIではさまざまなendpointが提供されています。今回は以下のendpointを利用して、各アイテムのメタデータを抽出してみます。 http://api.repo.nypl.org/api/v1/items/item_details/[:id] 具体的には、以下のアイテムを例としてます。 https://digitalcollections.nypl.org/items/510d47e1-d3b0-a3d9-e040-e00a18064a99 そして、以下に示したメタデータの抽出を試みます。 以下のGoogle Colabにメタデータの抽出サンプルプログラムを作成しました。参考になりましたら幸いです。 https://colab.research.google.com/drive/1sO9plTqraPwdBF61sArlD6k6pZRpfJL8?usp=sharing 上記プログラムを実行すると、例えば以下のようなメタデータが得られます。 { "title": "Genji monogatari: Sakaki no maki|The Tale of Genji", "collection": " > Genji monogatari : Sakaki no maki", "dateIssued": "1650 (start)|1700 (end)", "place": "Kyoto", "identifier": "Hades Collection Guide ID (legacy): 443|Hades struc ID (legacy): 747877|Universal Unique Identifier (UUID): ce4bcd90-c60d-012f-9d19-58d385a7bc34" } まとめ APIを利用したデータ活用の参考になりましたら幸いです。 ...

概要 researchmapの業績について、CSVファイルを用いた新規登録・更新・削除を行いました。本記事では、その方法と使用したデータを共有します。 今回使用したサンプルデータ https://github.com/ldasjp8/researchmap 新規登録 まず「インポート」ボタンをクリックします。 インポートダイアログが表示されるため、新規登録用のcsvファイルを選択して、「整合性チェック」ボタンを押します。 登録するcsvファイルの例を以下に格納しました。「published_papers」へ新規登録を行う例です。 https://github.com/ldasjp8/researchmap/blob/main/create.csv 公式の「CSV項目定義書」やCSVファイルのサンプルは以下で取得できます。 https://researchmap.jp/public/other-document/specification 結果、「処理待ち」のタスクが登録されます。 少し待って「更新」ボタンを押すと、以下のように整合性チェックが終了します。「こちらよりチェック結果を確認」リンクをクリックします。 以下の画面に遷移後、「インポート」ボタンを押します。 再び「処理待ち」のタスクが登録されます。 少し待って「更新」ボタンを押すと、以下のようにインポートが終了します。 「論文」の一覧ページでも、新規に登録されていることを確認できます。 なお、以降の「更新」「削除」においては、登録した業績のIDが必要になります。今回登録した業績のIDは36765885でした。このIDは、登録した個々の業績のURLなどから確認することができます。 また、既に登録済みの業績のIDを一括取得する場合は、「エクスポート」機能などを用います。 更新 新規登録と同様、「インポート」機能を用いて、更新用のCSVファイルを登録します。 更新用のcsvファイルの例を以下に格納しました。 https://github.com/ldasjp8/researchmap/blob/main/update.csv ポイントとして、アクションタイプに「similar_merge」、類似業績マージ優先度に「input_data」、IDに先ほど取得した業績のIDを入力しています。 これらを行いたいことに対して適切に設定しないと、類似業績などによって整合性チェックでエラーが発生する可能性があります。 以下のCSV項目定義書のページが参考になります。 https://researchmap.jp/outline/v2api/v2CSV.pdf#page=7 以下のようにタスクが登録されます。 少し待って「更新」ボタンを押すと、以下のように整合性チェックが終了します。「こちらよりチェック結果を確認」リンクをクリックします。 以下の画面に遷移後、「インポート」ボタンを押します。 少し待って「更新」ボタンを押すと、以下のようにインポートが終了します。 以下のように、先ほど登録した業績の情報が更新されます。 削除 これまでと同様、「インポート」機能を用いて、削除用のCSVファイルを登録します。削除用のcsvファイルの例を以下に格納しました。 https://github.com/ldasjp8/researchmap/blob/main/delete.csv CSVファイルの登録後、少し待って「更新」ボタンを押すと、以下のように整合性チェックが終了します。「こちらよりチェック結果を確認」リンクをクリックします。 以下の画面に遷移後、「インポート」ボタンを押します。 少し待って「更新」ボタンを押すと、以下のようにインポートが終了します。 業績のページにアクセスしてみることで、業績が正しく削除されていることを確認できます。 まとめ researchmapの業績に対する一括登録や更新、削除を行う際の参考になりましたら幸いです。

国立国会図書館「次世代デジタルライブラリー」で公開されているOCR結果をIIIFビューアで閲覧するアプリについて、OCR結果をTEI/XML形式でダウンロードする機能を追加しました。 https://static.ldas.jp/ndl-ocr-iiif/ 本アプリについては、以下の記事も参考にしてください。 本機能の追加にあたり、UIを更新しました。結果を「ビューア」と「データ」に分けています。 「ビューア」については、従来から提供していた「Mirador」と「Curation Viewer」に加えて、「Universal Viewer」、「Image Annotator」を追加しました。また、「次世代デジタルライブラリー」へのリンクと、TEI/XMLファイルの簡易ビューアとして「TEI Viewer」というページを実装して追加しています。 「データ」については、「マニフェストファイル」「キュレーションリスト」「TEI/XML」の3種類を提供します。 用途に応じてご活用いただけますと幸いです。

概要 以下の記事で、AWSサーバーレスアプリケーションによるIIIF Image Serverの構築方法について説明しました。 今回は、サイズが比較的大きい画像を登録し、タイル画像の配信が可能かを確認します。 対象 今回は、『鉱山借区図』（東京大学駒場図書館所蔵）を対象とします。 https://iiif.dl.itc.u-tokyo.ac.jp/repo/s/ichiko/document/4120a330-2f1c-4e2c-5d48-21aed4d42704 元画像は 300 MB弱のtif画像です。 pyramidal tiled tiffの作成 以下のサイトを参考に、VIPSとImageMagickの両方を試してみました。 https://github.com/samvera-labs/serverless-iiif#creating-tiled-tiffs Using VIPS vips tiffsave source_image.tif output_image.tif --tile --pyramid --compression jpeg --tile-width 256 --tile-height 256 Using ImageMagick convert source_image.tif -define tiff:tile-geometry=256x256 -compress jpeg 'ptif:output_image.tif' 結果、VIPSの場合は 35.6 MB、ImageMagickの場合は 107.4 MB になりました。 IIIF画像URL それぞれのIIIF画像URLは以下です。 VIPS https://iiif3.a-ldas.com/iiif/2/kakezu_v/info.json ImageMagick https://iiif3.a-ldas.com/iiif/2/kakezu/info.json Image Viewerでの表示 今回は、IIIF画像URLを読み込むことができるImage Annotator（神崎正英氏作成）を利用しました。 VIPS https://www.kanzaki.com/works/2016/pub/image-annotator?u=https%3A%2F%2Fiiif3.a-ldas.com%2Fiiif%2F2%2Fkakezu_v%2Finfo.json ImageMagick https://www.kanzaki.com/works/2016/pub/image-annotator?u=https%3A%2F%2Fiiif3.a-ldas.com%2Fiiif%2F2%2Fkakezu%2Finfo.json 結果 上記いずれの場合においても、（一部読み込みに時間がかかるケースがありますが、）無事に表示することができました。 本実験結果が参考になりましたら幸いです。

LeafletのVue3での使用例（座標範囲の取得を含む）を紹介するリポジトリを作成しました。 以下が動作例です。 https://static.ldas.jp/vue3-leaflet/ ソースコードは以下です。 https://github.com/ldasjp8/vue3-leaflet Vue3初学者のため、誤りなどがあるかもしれませんが、参考になりましたら幸いです。

Vue3でOpenSeadragonを使用するサンプルリポジトリを作成しました。 以下が動作例です。 https://static.ldas.jp/vue3-osd/ ソースコードは以下です。 https://github.com/ldasjp8/vue3-osd Vue3初学者のため、誤りなどがあるかもしれませんが、参考になりましたら幸いです。

Omeka SのIIIF Serverモジュールについて、デフォルト設定では、以下のようなURLでIIIFマニフェストファイルにアクセスすることができます。 <インストールしたパス>/iiif/<presentation apiのバージョン>/<omekaの内部ID>/manifest 例（version 2の場合）： https://shared.ldas.jp/omeka-s/iiif/2/1267/manifest 例（version 3）： https://shared.ldas.jp/omeka-s/iiif/3/1267/manifest ただ、このままではOmekaの内部IDが使用されてしまうため、独自の識別子の利用を推奨します。 対応方法としては、Clean Urlモジュールを追加でインストールし、以下に示すIIIF Serverモジュールの設定画面において、Use the identifiers from Clean Urlを有効にします。 これにより、例えば、先のサイテムに99999という識別子を与えた場合、以下のURLでも同じマニフェストファイルにアクセスすることができます。 https://shared.ldas.jp/omeka-s/iiif/2/99999/manifest 今回は数字の識別子を与えましたが、abcやabc1234など、英数字などでも問題ありません。 IIIF Serverモジュールを利用される際の参考になりましたら幸いです。

Omeka SのIIIF Serverモジュールでは、様々な設定を行うことができます。その一つとして、attributionの設定があります。 以下に示すように、Default attributionに入力した値が、IIIFマニフェストファイルなどのattribution項目に表示されます。組織名など、適切な値に変更することをお勧めします。 または、上記で示した項目の一つ上にあるように、attributionの値を入力するプロパティを指定することで、アイテム毎にattributionの値を変更することもできます。 IIIF Serverモジュールを利用される際の参考になりましたら幸いです。

Node.js で XSLT を実行するサンプルリポジトリを作成しました。 https://github.com/ldasjp8/nodejs-xslt TEI/XMLファイルなどをNode.jsで処理する際の参考になりましたら幸いです。

以下が参考になりました。 https://stackoverflow.com/questions/59407003/set-focus-text-field-inside-dialog-when-dialog-opened 以下のように、ダイアログを開いてから少し時間を置いてから、$refsにアクセスするとうまくいきました。 watch: { dialog: function(value) { if (value) { setTimeout(() => { this.$refs.name.focus(); }, 200); } } }

以下に説明がありました。 https://develop365.gitlab.io/nuxtjs-2.8.X-doc/ja/api/configuration-watch/ export default { ..., generate: { fallback: true, }, watch: ['static'], } 上記のように、nuxt.config.jsファイルでwatchを与えることで、対象ディレクトリも監視対象になりました。

概要 先日、以下の記事に書いた通り、IIIFのマニフェストファイルの配信と、IIIF Content Search APIを提供するアプリを開発しました。 https://zenn.dev/nakamura196/articles/76bdc86b1b7524 ただそれぞれ、APIに準拠しない記述をしていた部分がありました。 本記事では、その修正内容を共有するとともに、バリデーションを行うPresentation API Validatorの使用方法について、実例とともに紹介します。 https://presentation-validator.iiif.io/ マニフェストファイルの修正 上記のPresentation API Validatorのサイトにアクセスし、URL of Manifest to ValidateにマニフェストファイルのURLを入力し、対応したAPIのバージョン（今回は3.0）を選択します。 その結果、以下のように、エラーがある場合には、その内容が表示されます。 冒頭で紹介した私が開発したアプリが配信するマニフェストファイルは、そのサイズが大きいため、そのまま本バリデータにURLを入力すると、検証結果が表示されるまで時間がかかります。 そのため、マニフェストファイルの1canvas目のデータのみを残したマニフェストファイルを別途作成しました。それをバリデータにかけた結果、59件のエラーメッセージが表示されました。 以下、それぞれのエラー内容への対応方法を記述します。 Error 1 of 59. Message: ['https://ocr.aws.ldas.jp/v1/manifest/3437686.json'] is not of type 'string' before { "id": [ "https://ocr.aws.ldas.jp/v1/manifest/3437686.json" ] } 誤って、マニフェストファイルのidを配列の形で与えていました。以下のように修正しました。 after { "id": "https://ocr.aws.ldas.jp/v1/manifest/3437686.json" } Error 2 of 59. Message: 'Persistent ID' is not of type 'object' before { "metadata": [ { "label": "Persistent ID", "value": "info:ndljp/pid/3437686" } ] } この類のエラーは、2-23、26-59まで共通でした。（主に、metadataの記述箇所） 以下のような形で、言語（ここではnone）を指定し、値は配列として与える必要がありました。必要に応じて、jaやenといった言語を与えることができます。 ...