# [C13] 静的デジタルアーカイブジェネレータ DAKit を 用いたメタデータ流通のワークフローに関する検討

阿達藍留 ${ }^{11}$, 大向一輝 1)

1) 東京大学, $\overline{1} 113-0013$ 東京都文京区本郷 7-3-1

E-mail: adachi@l.u-tokyo.ac.jp
## A Proposal of Workflow for Metadata Distribution using Static Digital Archive Generator

ADACHI Airu ${ }^{1)}$, OHMUKAI Ikki¹)

1) The University of Tokyo, 7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-0013 Japan

## 【発表概要】

近年、デジタルアーカイブの役割はデータの共有だけでなく外部のアグリゲータや大規模アー カイブとの連携へと拡大しており、こうした付加機能への要求が増えることで、維持管理のコストが増加している。本研究では、資料に関わる当事者が手軽にデジタルアーカイブを構築・提供するための静的サイト生成ツールである DAKit に対して、外部連携機能を追加しメタデータ流通の基盤とすることを検討した。具体的には、JPCOAR スキーマに準拠した構造化データの出力や、ResourceSync を利用したハーベスティングに対応する。この仕組みは、他のメタデータスキーマにも容易に適用可能である。

## 1. はじめに

近年、デジタルアーカイブの役割は単にデ一タの保存と共有にとどまらず、外部のアグリゲータや大規模アーカイブとの連携へと拡大している。こうした付加機能への要求が増えることで、維持管理のコストが増加し、小規模な主体がデジタルアーカイブを構築することへの障壁となり得る。その解決策として本研究では、著者らが開発を行っている、資料に関わる当事者が手軽にデジタルアーカイブを構築・提供するための静的サイト生成ツ一ルである DAKit に対して、外部連携機能を追加しメタデータ流通の基盤とすることを検討した。

## 2. DAKit の設計方針と実装

## 2. 1 DAKit $の$ 目的

研究データの管理と利活用が注目される中、従来それらが重要視されてきた自然科学の分野にとどまらず、人文学分野においても資料共有に対する学術的・社会的要請が高まっている。他方、既存のデジタルアーカイブの構築手法には情報技術の知識、維持のためのコスト負担を前提としたものが多く、データ公開を妨げる要因となってきた[1]。

小規模な組織やコミュニティによるデジタ
ルアーカイブの構築を可能にするための議論として、福島[2]が提案した「スリムモデル」 がある。このモデルでは、デジタルアーカイブが充たすべき最小限の要件を絞り込んだものとして、利用規約の明示、機械可読性の担保、環境に依存しないデータ移行性の担保、 アクセシビリティの確保が挙げられているが、 その要件を満たす具体的な実装事例は少ない。 そこで、資料に関わる当事者が手軽にデジタルアーカイブを提供できるようにすべく開発を開始した静的サイト生成ツールが DAKit である。

## 2. 2 DAKit v1 の実装

2022 年 12 月に公開した DAKit v1 は、表形式で記述されたメタデータと資料画像の一覧から資料アイテムごとの個別ぺージと横断検索用のページを含む Web ページ群を生成する Pythonスクリプトである。横断検索はメタデータを記述したタブ区切りテキスト（TSV） ファイルを読み込み、JavaScript の配列に格納して、クライアントサイドで完結するよう実装した（図1）。

技術選定と設計にあたっては、処理内容がブラックボックスにならないことを大前提とした。また、従来型のレンタルサーバだけでなく、GitHub Pages (https://pages.github.
com）に代表される静的 Web サイトのホスティングサービスでも動作することを目指した。

DAKitv1 は 1 つのアイテムごとに閲覧用の Web ページを生成するもので、メタデータや画像の閲覧といった最低限の機能を持たせることには成功した。一方で、「可読性の高い表と HTML ファイルをアップロードするだけで機能する」という当初のコンセプトに合わせて検索用のデータをTSVファイルで保存していたことから、JavaScript による処理に適しておらず、結果として絞り込み検索の機能に不足が残った。また、DAKit はクラウド上の Python 実行環境である Google Colaboratory 上で動作させることを想定していたが、スクリプト処理内容の単純さに比して実行環境の立ち上げや動作に必要なライブラリのダウンロードなど利用可能になるまでの時間が長く、手軽に利用してもらうことが困難だった。さらにサーバやホスティングサービスへの設置はユーザが手動で行う必要があり、手間が削減されていないという課題も残った。

## 2. 3 DAKit v2 の設計方針と実装

図 1 DAKit により生成される検索ページの例

前述の課題を踏ま光、DAKit v2 の開発においては、JavaScript の処理を効率化するため、検索等に用いるデータは JSON 形式で出力することとした。

データ形式として JSON を採用するにあたり、多数の HTML ファイルをあらかじめ生成する Multi Page Application （MPA）の構造に代わり、アイテムごとの JSON ファイルを生成し、単一の HTML ファイル内で JavaScript を用いて各アイテムのメタデータ
を取得して表示させる Single Page Application（SPA）のアプローチを検討した。

Python スクリプトによる HTML ファイルの生成は、テンプレートエンジンとして採用している Jinja の書式が必ずしも直感的でないこと、 マークアップの整理・正規化のためのライブラリが充実していないことから理想的ではなく、JSON ファイルの処理のみを担当させたほうがより効率化に寄与する可能性がある。 また、昨今の主流のプログラミング環境における純粋な機械可読性を考えると、データの二次利用自体には JSON ファイルのほうが取り扱いやすいと考元られる。

しかしながら、メタデータ流通の観点から見ると状況は異なる。現在、メタデータの記述のデファクトスタンダードはXML形式である。JSON ファイルから JavaScript で XML を自動生成することは技術的に可能なものの、 ハーベスティングのためのクローラーが JavaScript を解釈するとは考えにくいことから、メタデータを記述した XMLファイルはあらかじめ生成しておく必要がある。これを考えると、HTML ファイルを事前生成しないことのメリットは少ないと言える。

また、デジタルアーカイブを環境に依存せず低コストで長期間提供するという当初の方針に照らして、可能な限り JavaScript という特定技術への依存度を下げるという点からも SPA のアプローチは取らないこととした。

これらの検討の結果、DAKit v2 の開発においても引き続きMPAのアプローチを採用し、検索用の JSON ファイル、個別アイテムの HTML ファイル、個別アイテムのメタデータを記述した XMLファイルを生成する。DAKit v2 では、Python スクリプトによる Web ペー ジ群の生成という基本的な設計を維持しつつ、 Web アプリケーション開発用の JavaScript フレームワークである Svelte を採用して検索・閲覧機能の充実を図った。Python スクリプトについては、不要なコードやライブラリを取り除いてリファクタリングを行い、実行環境が整うま

での時間を短縮して試用を容易にした。

## 3.メタデータ流通への対応

デジタルアーカイブにおいて取り扱われる資料は多種多様であり、資料の状態を表現するメタデータの形式も多種多様になり得る。 これらをどうメタデータ流通の土俵に乗せるかが重要な問題となる。

今回は、国内の学術情報流通において広く用いられている JPCOAR スキーマ[3] と、その派生として人文社会系データのために作られた JDCatメタデータスキーマ[4]を活用し、

提供者側で同スキーマへの適切なマッピングを行えるようツールの側で支援することとした。JPCOAR スキーマではスキーマが定める要素に当てはまらない追加情報を記述するための要素が定められており、マッピングが困難な資料独自のデータを記述することにも柔軟な対応が可能である。

これらのメタデータのアクセス先を外部のアグリゲータに提示するため、ResourceSy $\mathrm{nc}[5]$ に対応し、データの公開までをサポー トするよう設計した。

## 4. URI の永続的な維持

メタデータ流通において、記述されたメタデータ自体と並んで重要なのが、データの在処を指し示す Uniform Resource Identifier （URI）である。デジタルアーカイブの提供方法や環境が変わっても URI は維持される必要があり、これはデジタルアーカイブ自体のデータ移行性とは別に検討しなければならない課題である。

電子データの国際的な識別子として Digital Object Identifier (DOI) がよく知られている。 DOI を取得すればリンクの維持の確実性は高くなるが、取得にはDOI 登録機関への会員登録が必要となり、個人や小規模主体にとっては現実的ではない場合もある。

その他、よく知られている固定 URI サービスとして、Internet Archive が提供する PURL  や、World
Wide Web Consortium Permanent Identifier Working Group が提供する W3ID がある。実際の取得手続きやリンクの維持は提供者自身による対応が必要となるが、DAKit ではリンクを維持しやすいファイル構造を採用しており、これらの取得を支援することは可能である。

## 5. 課題と展望

本研究では、DAKit に外部連携機能を追加し、メタデータ流通の基盤とすることを検討した。DAKit は

https://github.com/utokyodh/dakit にて公開している。

具体的には、メタデータの構造化やハーべスティングへの対応には道筋を付けることができたが、公開やリンクの維持に知識とコストが必要である点が解決できていない。この点を踏まえ、DAKit については、デジタルア一カイブの「ノーコード」での構築が可能となるツールを目指して今後も開発を続けていきたいと考えている。

実装については、Web ページ群の生成に現在は Python スクリプトを利用しているが、 Web ブラウザ上でさまざまな処理を高速で安全に実現する WebAssembly[6]などの技術を活用し、Web ブラウザ上で完結させられるようになれば、より手軽でセキュアなワークフローが実現できるであろう。

また、DAKit は専ら静的 Web サイトの構築を主眼としているため、現在のデジタルアー カイブにおける画像公開の手段として主流になっている International Image Interoperability Framework (IIIF) への対応が十分ではない。事前に画像タイルを生成することでImage API Level 0 に準拠した画像の配信は可能だが[7]、任意の領域の切り抜きをはじめとする動的な機能の提供はできず、結果として IIIF に準拠した画像配信のメリットの多くが損なわれる。この点について、ジヤパンサーチの簡易 IIIF API 提供機能のような外部的な解決策 $[8]$ に限らず、本研究が志向する静的 Web サイトによるデジタルアーカイ

ブの構築と動的機能への要求との整合性をいかに図るかについては、いっそうの検討を要する。

最後に、本研究は現時点での Web アーキテクチャに基づく最適解を求めたものに過ぎないことを注記しておく。一例として、 Amazon Web Services 9 AWS Lambda  Cloudflare の Cloudflare Workers (https://www.cloudflare.com/ja-jp/developerplatform/workers）など、コンテンツ配信元のサーバを意識する必要がないサーバレスコンピューティングの技術が定着すれば、サイ卜生成自体も不要となり、単一のメタデータと画像データをクラウド上に置くだけでデジタルアーカイブが公開できるようになる可能性がある。今後も、小規模主体が持続可能なデジタルアーカイブを提供するうえで活用できる技術については、その動向を注意深く調査していきたい。

## 参考文献

[1] 阿達藍留, 山田俊幸, 大向一輝. DAKit: 低コストなデータ共有のための静的デジタルア一カイブジェネレータの提案. 情報知識学会誌. 2022, vol. 32, no. 4, p. 406-409.

[2] 福島幸宏. デジタルアーカイブと図書館年一ビスの新段階. https://www.lib.pref.fukuoka.jp/hp/works/20

21/kityokoen.pdf (参照 2023-09-19).

[3] オープンアクセスリポジトリ推進協会.

JPCOAR スキーマガイドライン.

https://schema.irdb.nii.ac.jp/ja（参照 202309-19).

[4] 日本学術振興会. “データの検索・分析 (JDCat) ”. 人文学・社会科学データインフラストラクチャー構築推進事業.

https://www.jsps.go.jp/j-di/search.html (参照 2023-09-19).

[5] Open Archives Initiative. "ResourceSync Framework Specification (ANSI/NISO Z39.99-2017)".

http://www.openarchives.org/rs/1.1/resource sync (参照 2023-09-19).

[6] "WebAssembly". MDN Web Docs.

https://developer.mozilla.org/ja/docs/WebAss embly (参照 2023-09-24).

[7] International Image Interoperability Framework. "Image API Compliance, Version 3.0.0".

https://iiif.io/api/image/3.0/compliance/ (参照 2023-09-24).

[8] “ジャパンサーチのメタデータ連携について”.ジャパンサーチ.

https://jpsearch.go.jp/static/pdf/cooperation/j ps_manual_202010.pdf (参照 2023-09-24).

この記事の著作権は著者に属します。この記事は Creative Commons 4.0 に基づきライセンスされます(http://creativecommons.org/licenses/by/4.0/)。出典を表示することを主な条件とし、複製、改変はもちろん、営利目的での二次利用も許可されています。