Archivematica では、Dublin Core（DC）以外のメタデータスキーマもAIPのMETS.xmlに組み込むことができます。本ガイドでは、source-metadata.csv を使って EAD や MODS などの非DCメタデータをTransferに含め、AIPに正しく格納されるかをAPI経由で検証します。

目次

  1. 背景と目的
  2. source-metadata.csv の仕組み
  3. XML Validation 機能
  4. 検証1: MODS単独でのメタデータ登録
  5. 検証2: EAD + MODS の同時登録
  6. METS.xml における非DCメタデータの格納形式
  7. 検証3: Reingest によるメタデータ追加
  8. まとめ

背景と目的

Archivematica の標準的な Transfer では、metadata/metadata.csv に記述した Dublin Core メタデータが METS.xml に <dmdSec> として格納されます。しかし、実際のデジタルアーカイブ運用では、以下のようなユースケースで DC 以外のメタデータスキーマを扱う必要があります。

  • EAD（Encoded Archival Description） : アーカイブズの階層記述で広く使われる標準
  • MODS（Metadata Object Description Schema） : 図書館資料の詳細記述に使われるスキーマ
  • LIDO : 博物館・美術館資料の記述標準
  • MARC21 : 図書館の目録データフォーマット

Archivematica は source-metadata.csv というCSVファイルを通じて、任意の XML メタデータを Transfer に紐付け、AIP の METS.xml に <dmdSec> として格納する機能を提供しています。本ガイドでは、この機能を API 経由で実際に検証します。

source-metadata.csv の仕組み

CSVフォーマット

source-metadata.csv は Transfer の metadata/ ディレクトリに配置するCSVファイルで、3つのカラムで構成されます。

foooibbbljjjeeeencccatttmssse,,/,emdmaoieddrt.sax.fdmxialmlt,leaE,.,AMptDOdyDfpS,efile_metadata.xml,CustomType
カラム説明
filenameメタデータの対象となるファイルまたはディレクトリの相対パス（objects/ から始まる）
metadataXMLメタデータファイルへのパス（metadata/ ディレクトリからの相対パス）
typeメタデータの種別識別子。METS.xml の OTHERMDTYPE 属性に使用される

Transfer のディレクトリ構成

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

同一ファイルへの複数メタデータの紐付け

source-metadata.csv では、同一の filename に対して異なる type のメタデータを複数行で紐付けることができます。

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

この例では、objects ディレクトリ（配下の全ファイル）に対して EAD と MODS の両方が関連付けられ、それぞれ独立した <dmdSec> として METS.xml に格納されます。

処理の流れ

  1. Transfer 時に source-metadata.csv が読み込まれる
  2. metadata カラムで指定された XML ファイルがパースされる
  3. XML Validation が有効な場合、スキーマに対するバリデーションが実行される
  4. バリデーションに成功した XML が <dmdSec> として METS.xml に埋め込まれる

XML Validation 機能

概要

Archivematica には、source-metadata.csv で指定された XML メタデータをスキーマに対してバリデーションする機能があります。この機能はデフォルトでは無効 であり、実験的機能 として位置付けられています。

有効にするには、MCP Client の環境変数を設定します。

AMRECTHAIDVAETMAA_TXIMCLA__VMACLPICDLAITEINOTN__MSCEPTCTLIINEGNST__FMIELTEA=D/ApTaAt_hX/MtLo_/VxAmLlI_DvAaTlIiOdNa_tEiNoAnB.LpEyD=true

バリデーション設定ファイル

バリデーション設定は Python ファイルで記述します。以下は Archivematica のテスト環境で使われている設定例です。

fX}Xr_MMoDLLmI__RV""""""""VpAhhhhhambAa=LtttttleaLtItttttttgIhPDpppppoa-DlaA:::::"diAitT/:anTbhI/tfI(OwwwwsaoOi_Nwwwwl""Nm_wwwwu_::_pf=....bDFoiolllaINNArl{pioorRooIteedcccnnL_no..h/ee_P_a-ggi,,Oa)rsoov"Nt.ccv.a_hphh/slEaieMmltRrvmAouoReeaRdb-Ons.Cs-vRt.o2/d2sor1r.=[rg/3e00g"s"s.F]/:l:dxaOiesl/AmndsI"."e"/_:_d)s2DDe.c.IIah0RRrse/_i_mo/D/gpaaIhosi"R"ts"_lmsidi/o1xcdd"(/o"s:)"-M.,:vAx1Rs.Cd_12"D_.1)IDxs.RIslaRdis/"m_/).p".xor"assiosdiga_"xhip)(t_o.)sdsa,1cis..x_xx(pss)odd,s""i))x..(aa)ss,__ppoossiixx(()),,

XML_VALIDATION ディクショナリのキーは、以下の順序で XML ドキュメントとマッチングされます。

  1. xsi:noNamespaceSchemaLocation 属性の値
  2. xsi:schemaLocation 属性の最後の値
  3. ルート要素の名前空間 URI
  4. ルート要素のローカル名

キーに対する値が None の場合、バリデーションはスキップされますが、<dmdSec> への格納は行われます。キーがディクショナリに存在しない場合、そのメタデータはサイレントにスキップ され、<dmdSec> にも格納されません。

テスト環境のサポート済みスキーマ

名前空間 / キーメタデータ種別バリデーション
http://www.openarchives.org/OAI/2.0/oai_dc/Dublin Core (OAI-PMH)XSD
http://www.lido-schema.orgLIDOXSD
http://www.loc.gov/MARC21/slimMARC21XSD
http://www.loc.gov/mods/v3MODSXSD
http://slubarchiv.slub-dresden.de/rights1SLUB RightsXSD
altoALTO (OCR)XSD
metadata汎用メタデータスキップ
bag-infoBagIt 情報スキップ

注意 : EAD（urn:isbn:1-931666-22-9）はテスト環境のデフォルト設定に含まれていません。EAD を使用する場合は、設定ファイルにエントリを追加する必要があります。

検証1: MODS単独でのメタデータ登録

Administration > Processing configuration 画面 ── Transfer 投入時に使用する処理プロファイル（default / automated / backlog）を管理する

検証環境

  • Archivematica 1.19（Docker 環境）
  • Dashboard: http://127.0.0.1:62080
  • Storage Service: http://127.0.0.1:62081
  • XML Validation: 有効（テスト環境のデフォルト設定）

Transfer パッケージの作成

以下の構成で Transfer パッケージを作成します。

m├│└e──t──ado└m├├└ab─e───tj─t───aea-ctdsemtteaoaoesstudds/tar.st-/cx./demxo-lmcmluemteandta.ttax.tcsv

source-metadata.csv:

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

mods.xml:

<<?m/xo<<<<<mmdt/n/tl/aolsi<ta<<nya<lbdttimnr/apnlassvxliteao<rmegant>emetlmlroeOungrrlIleteeol>faguasnneIyP>leRguacisf>npae>eeagto=oTferTs>ge>n">eo=teoe>T=hs>">ruTe"ttcNmres1toacrt.pDrktem0:opay>d"/comptto/urueeycewmar=xpunweta"temcwnet<=eo.t"Te/"ndl>extctiofstyoncot"pdfg.r>eeo=gOcO"r"oMrrfUvegeRavT/taaeueFmantstr-odioohi8dazruof"sta<rry?/at/cii>viretn3Voo>yg"anl=l<e"Mvi/TiOednesDraaroSstmm6iie>3mooP9enna-t=<r2a"/tbd3t>"a.i>t6tja"lp>enr><e/gliasntgruaatgieoTne.r<m/>abstract>

API による Transfer の実行

cur---}lHHd'"""""-""'ntppaXAC{ayaruuomptotPtneehcoOht"""e_Soe:::saTrnspit"""iphz-ms<nrtaTetbgottytaa_vpipansce:eddeo"n:aa6n:/:tr4f1aad-it2Ap-"egr7ppt,n"u.ilec:e0Kiso.ectd"0ya"ea.t,du1ti-t:eopo6snam2t/ta0:jht8ts>e0eo"d/sn,"at",p"i\v2beta/package/

結果

Transfer タブ ── metadata-test および metadata-test2 の Transfer 処理が完了し、各 Microservice のステータスが表示されている

Transfer → Ingest が完了し、AIP が正常に作成されました。METS.xml の <dmdSec> を確認すると、MODS のみが dmdSec として格納 されていました。

<m/e<mtm/ese<mt:tm/esdse<mt:m:tm/esddmso<mt:mSd:d!osmdeWxs-d:dScrm-sxWealx>mrcIpDmMla>DalODp=MtnDa>"DasStdT>=amY"メ>dPhタSEtデe=tーc"pタ_O:全2T/文"H/EwCRwR"wE.AOlTToEHcDE.=Rg"Mo2Dv0T/2Ym6Po-Ed0=s2"/-Mv1O37D"TS0"v1>e:r5s1i:o4n1=""3S.T6A"T>US="original">

EAD が格納されなかった原因 : MCP Client のログに以下のエラーが記録されていました。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

0

XML Validation 設定ファイルに EAD の名前空間（urn:isbn:1-931666-22-9）が登録されていなかったため、バリデーション処理でスキップされ、<dmdSec> にも格納されませんでした。

検証2: EAD + MODS の同時登録

XML Validation 設定の修正

EAD を扱うため、設定ファイルに EAD の名前空間を追加しました。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

1

None を指定することで、XSD スキーマによるバリデーションは行わず、METS.xml の <dmdSec> への格納のみを行います。

API による Transfer の実行

前回と同様の構成で、新しい Transfer パッケージ（metadata-test2）を API 経由で投入しました。

結果: METS.xml の dmdSec

Archival Storage 一覧 ── metadata-test（検証1）と metadata-test2（検証2）の AIP が正常に保存されている

今回は 3つの dmdSec が生成されました。

dmdSec_1: PREMIS:OBJECT（標準）

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

2

dmdSec_2: EAD

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

3

dmdSec_3: MODS

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

4

structMap での関連付け

structMap では、objects ディレクトリに DMDID="dmdSec_2 dmdSec_3" として EAD と MODS の両方が関連付けられていることが確認できました。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

5

METS.xml における非DCメタデータの格納形式

MDTYPE 属性の扱い

source-metadata.csv の type カラムで指定した値は、METS.xml では以下のように格納されます。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

6

Archivematica のソースコード（archivematicaCreateMETSMetadataXML.py）を確認すると、source-metadata.csv 経由のメタデータは常に MDTYPE="OTHER" として格納され、type カラムの値は OTHERMDTYPE 属性に設定されます。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

7

これは Dublin Core（metadata.csv 経由で MDTYPE="DC" として格納される）とは異なる扱いです。

STATUS 属性

  • 初回 Ingest 時: STATUS="original"
  • Re-ingest 時: STATUS="update"

Re-ingest 時には、同じ type の既存 dmdSec は superseded 扱いとなり、新しい dmdSec が STATUS="update" で追加されます。

XML ファイルの保存先

source-metadata.csv で参照された XML ファイルは、AIP 内にもファイルとして保存されます。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

8

検証3: Reingest によるメタデータ更新

AIP 詳細画面 ── metadata-test2 の UUID、サイズ、保存場所、METS ファイルのダウンロードリンクが確認できる

検証の目的

検証2で作成した AIP（EAD + MODS を含む）に対して Metadata re-ingest を実行し、以下を検証します。

  • 既存の MODS メタデータを更新した場合、旧メタデータが superseded として保持され、新メタデータが update として追加されるか
  • Re-ingest で追加した XML ファイルが AIP 内に保存されるか

Reingest の開始

AIP 詳細画面の Re-ingest タブ ── Reingest type（Metadata / Partial / Full）と Processing config を選択して実行する。今回は API 経由で Metadata re-ingest を実行する

Storage Service API を使って Metadata re-ingest を開始します。

m├│└y──-──tro└m├├└ab─e───nj─t───seafctdsemeteaoaorsstudd//tar.s-/cx.demxo-lmcmluemteandta.ttax.tcsv←←←←保メEM存タAO対デDD象ーメSのタタメデとデタジオーデタブタールジタオェブクジトェのクマトッピング定義

9

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

0

メタデータの追加

Reingest が開始されると、AIP が展開され、Archivematica の Ingest ワークフローに投入されます。「Approve AIP reingest」の承認を行う前に、展開された AIP の data/objects/metadata/ ディレクトリに新しいメタデータファイルを配置します。

重要 : Reingest 時は objects/metadata/source-metadata.csv（ルートレベル）のみが処理されます。objects/metadata/transfers/ 配下の CSV は初回 Ingest 時にのみ読み込まれます。

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

1

source-metadata.csv（Reingest 用）:

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

2

type カラムに既存の dmdSec と同じ値（MODS）を指定すると、既存の dmdSec が superseded となり、新しい dmdSec が update として追加されます。新しい type 値（DC-CUSTOM）を指定した場合は、新規の dmdSec として追加されます。

Reingest の承認と処理

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

3

承認後、Ingest ワークフローが進行します。Metadata re-ingest でも Normalize や Transcribe などの決定ポイントを通過する必要があります（automated 処理コンフィグが適用されない場合は手動で選択します）。

結果: Reingest 後の METS.xml

Reingest 完了後の METS.xml には 4つの dmdSec が含まれていました。

dmdSecSTATUSTYPE説明
dmdSec_1originalPREMIS:OBJECTSIP 識別情報（変更なし）
dmdSec_2originalOTHER(EAD)初回 Ingest の EAD（変更なし）
dmdSec_3original-supersededOTHER(MODS)初回 Ingest の MODS（superseded に変更 ）
dmdSec_4updateOTHER(MODS)Reingest で追加された更新 MODS

dmdSec_3（旧 MODS → superseded）:

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

4

dmdSec_4（新 MODS → update）:

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

5

structMap の変化

Reingest 後の structMap では、objects ディレクトリに superseded を含む全 dmdSec が参照されています。

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

6

また、Reingest で追加したメタデータファイルも AIP 内にファイルとして保存されています。

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

7

DC-CUSTOM が dmdSec に含まれなかった理由

dc-reingest.xml（Dublin Core Terms 形式）は AIP 内にファイルとして保存されましたが、dmdSec には格納されませんでした。MCP Client のログには以下のエラーが記録されていました。

fooibbljjeeenccattmsse,,,emmaoeddt.sax.dmxalmt,laE,,AMtDOyDpSe

8

XML Validation 設定に登録されている Dublin Core は OAI-PMH 形式（http://www.openarchives.org/OAI/2.0/oai_dc/）のみであり、DC Terms 形式（http://purl.org/dc/terms/）は登録されていませんでした。XML Validation の登録ルールは名前空間 URI ベースのため、同じ Dublin Core でも名前空間が異なれば別途登録が必要です。

まとめ

検証結果の要約

検証項目結果
MODS メタデータの dmdSec 格納成功
EAD メタデータの dmdSec 格納成功（XML Validation 設定追加後）
同一オブジェクトへの複数メタデータ紐付け成功（EAD + MODS を同時格納）
structMap での dmdSec 関連付け正常（DMDID="dmdSec_2 dmdSec_3"）
Reingest による MODS メタデータ更新成功（旧: original-superseded、新: update）
Reingest 後の structMap 更新正常（DMDID="dmdSec_2 dmdSec_3 dmdSec_4"）
Reingest で追加したファイルの AIP 内保存成功
未登録名前空間の DC Terms の格納失敗（XML Validation 設定に未登録）

注意点

  1. XML Validation 設定 : XML Validation が有効な環境では、使用するメタデータスキーマの名前空間をバリデーション設定ファイルに登録する必要があります。未登録の場合、メタデータはサイレントにスキップされます。エラーはログにのみ記録され、Ingest / Re-ingest の処理自体は続行されます。

  2. MDTYPE の扱い : source-metadata.csv 経由のメタデータは常に MDTYPE="OTHER" で格納されます。MDTYPE="MODS" や MDTYPE="EAD" のように METS 標準の MDTYPE 値として格納されるわけではありません。

  3. Reingest 時の source-metadata.csv の配置場所 : 初回 Ingest では metadata/transfers/<transfer-name>/source-metadata.csv が使用されますが、Reingest では metadata/source-metadata.csv（ルートレベル）のみが処理されます。

  4. type カラムによるメタデータの版管理 : source-metadata.csv の type カラムは、Reingest 時のメタデータ更新の識別子として機能します。同じ type 値を使用すると既存の dmdSec が superseded となり、新しい type 値を使用すると新規の dmdSec が追加されます。

  5. 名前空間ベースの登録 : 同じメタデータ標準（例: Dublin Core）でも、使用する名前空間 URI が異なれば、それぞれを XML Validation 設定に登録する必要があります。

参考リンク