Archivematica における非DCメタデータの登録検証 ── source-metadata.csv を使ったEADの組み込み

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

背景と目的

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つのカラムで構成されます。

filename,metadata,type
objects,ead.xml,EAD
objects,mods.xml,MODS
objects/dir/file.pdf,file_metadata.xml,CustomType

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

Transfer のディレクトリ構成

my-transfer/
├── objects/
│   └── test-document.txt      ← 保存対象のデジタルオブジェクト
└── metadata/
    ├── source-metadata.csv    ← メタデータとオブジェクトのマッピング定義
    ├── ead.xml                ← EADメタデータ
    └── mods.xml               ← MODSメタデータ

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

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

filename,metadata,type
objects,ead.xml,EAD
objects,mods.xml,MODS

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

処理の流れ

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

XML Validation 機能

概要

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

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

ARCHIVEMATICA_MCPCLIENT_MCPCLIENT_METADATA_XML_VALIDATION_ENABLED=true
METADATA_XML_VALIDATION_SETTINGS_FILE=/path/to/xml_validation.py

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

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

from pathlib import Path

__DIR = Path(__file__).parents[0] / "schemas"

XML_VALIDATION = {
    "http://www.openarchives.org/OAI/2.0/oai_dc/": (__DIR / "oai_dc.xsd").as_posix(),
    "http://www.lido-schema.org": (__DIR / "lido-v1.1.xsd").as_posix(),
    "http://www.loc.gov/MARC21/slim": (__DIR / "MARC21slim.xsd").as_posix(),
    "http://www.loc.gov/mods/v3": (__DIR / "mods.xsd").as_posix(),
    "http://slubarchiv.slub-dresden.de/rights1": (__DIR / "rights1.xsd").as_posix(),
    "alto": (__DIR / "alto-v2.0.xsd").as_posix(),
    "metadata": None,
    "bag-info": None,
}
XML_VALIDATION_FAIL_ON_ERROR = False

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

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

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

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

名前空間 / キー	メタデータ種別	バリデーション
`http://www.openarchives.org/OAI/2.0/oai_dc/`	Dublin Core (OAI-PMH)	XSD
`http://www.lido-schema.org`	LIDO	XSD
`http://www.loc.gov/MARC21/slim`	MARC21	XSD
`http://www.loc.gov/mods/v3`	MODS	XSD
`http://slubarchiv.slub-dresden.de/rights1`	SLUB Rights	XSD
`alto`	ALTO (OCR)	XSD
`metadata`	汎用メタデータ	スキップ
`bag-info`	BagIt 情報	スキップ

注意 : 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 パッケージを作成します。

metadata-test/
├── objects/
│   └── test-document.txt
└── metadata/
    ├── source-metadata.csv
    ├── ead.xml
    └── mods.xml

source-metadata.csv:

filename,metadata,type
objects,ead.xml,EAD
objects,mods.xml,MODS

mods.xml:

xml version="1.0" encoding="UTF-8"?>
mods xmlns="http://www.loc.gov/mods/v3" version="3.6">
  titleInfo>
    title>Test Document for Metadata Validationtitle>
  titleInfo>
  name type="corporate">
    namePart>Nakamura Test OrganizationnamePart>
    role>
      roleTerm type="text">creatorroleTerm>
    role>
  name>
  typeOfResource>texttypeOfResource>
  language>
    languageTerm type="code" authority="iso639-2b">jpnlanguageTerm>
  language>
  abstract>Test document for verifying MODS metadata registration.abstract>
mods>

API による Transfer の実行

curl -X POST http://127.0.0.1:62080/api/v2beta/package/ \
  -H "Authorization: ApiKey test:test" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "metadata-test",
    "type": "standard",
    "path": "",
    "processing_config": "automated",
    "auto_approve": true
  }'

結果

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

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

mets:dmdSec ID="dmdSec_2" CREATED="2026-02-17T01:51:41" STATUS="original">
  mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="MODS">
    mets:xmlData>
      mods xmlns="http://www.loc.gov/mods/v3" version="3.6">
        
      mods>
    mets:xmlData>
  mets:mdWrap>
mets:dmdSec>

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

XML validation schema not found for keys: ['urn:isbn:1-931666-22-9', 'ead']

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

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

XML Validation 設定の修正

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

XML_VALIDATION = {
    # ... 既存の設定 ...
    "urn:isbn:1-931666-22-9": None,  # EAD: バリデーションなしで dmdSec に格納
}

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（標準）

mets:dmdSec ID="dmdSec_1" CREATED="2026-02-17T01:57:54" STATUS="original">
  mets:mdWrap MDTYPE="PREMIS:OBJECT">
    mets:xmlData>
      premis:object xsi:type="premis:intellectualEntity">
        premis:objectIdentifier>
          premis:objectIdentifierValue>7e26ac5e-ef3b-4f17-8717-f5239bbe355fpremis:objectIdentifierValue>
        premis:objectIdentifier>
      premis:object>
    mets:xmlData>
  mets:mdWrap>
mets:dmdSec>

dmdSec_2: EAD

mets:dmdSec ID="dmdSec_2" CREATED="2026-02-17T01:57:54" STATUS="original">
  mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="EAD">
    mets:xmlData>
      ead xmlns="urn:isbn:1-931666-22-9">
        eadheader>
          eadid>metadata-test-002eadid>
          filedesc>
            titlestmt>
              titleproper>Test Collection for EAD Metadata Validationtitleproper>
            titlestmt>
          filedesc>
        eadheader>
        archdesc level="collection">
          did>
            unittitle>Test Collection for EAD Metadata Validationunittitle>
            unitdate type="inclusive" normal="2024/2025">2024-2025unitdate>
            unitid>META-TEST-002unitid>
          did>
        archdesc>
      ead>
    mets:xmlData>
  mets:mdWrap>
mets:dmdSec>

dmdSec_3: MODS

mets:dmdSec ID="dmdSec_3" CREATED="2026-02-17T01:57:54" STATUS="original">
  mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="MODS">
    mets:xmlData>
      mods xmlns="http://www.loc.gov/mods/v3" version="3.6">
        titleInfo>
          title>Test Document for MODS Metadata Validationtitle>
        titleInfo>
        
      mods>
    mets:xmlData>
  mets:mdWrap>
mets:dmdSec>

structMap での関連付け

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

mets:structMap TYPE="physical" ID="structMap_1" LABEL="Archivematica default">
  mets:div TYPE="Directory" LABEL="metadata-test2-..." DMDID="dmdSec_1">
    mets:div TYPE="Directory" LABEL="objects" DMDID="dmdSec_2 dmdSec_3">
      
      mets:div TYPE="Item" LABEL="test-document.txt">
        mets:fptr FILEID="file-..."/>
      mets:div>
    mets:div>
  mets:div>
mets:structMap>

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

MDTYPE 属性の扱い

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

mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="EAD">

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

fsentry.add_dmdsec(
    tree.getroot(),
    "OTHER",
    othermdtype=xml_type,
    status="update" if "REIN" in sip_type else "original",
)

これは 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 内にもファイルとして保存されます。

data/objects/metadata/transfers/-/ead.xml
data/objects/metadata/transfers/-/mods.xml
data/objects/metadata/transfers/-/source-metadata.csv

検証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 を開始します。

curl -X POST "http://127.0.0.1:62081/api/v2/file//reingest/" \
  -H "Authorization: ApiKey test:test" \
  -H "Content-Type: application/json" \
  -d '{
    "pipeline": "",
    "reingest_type": "metadata"
  }'

{
  "error": false,
  "message": "Package 7e26ac5e-... sent to pipeline ... for re-ingest",
  "reingest_uuid": "7e26ac5e-...",
  "status_code": 202
}

メタデータの追加

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

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

data/objects/metadata/
├── source-metadata.csv    ← Reingest 用のマッピングファイル（新規作成）
├── mods-updated.xml       ← 更新された MODS（新規作成）
├── dc-reingest.xml        ← 新規追加の DC メタデータ（新規作成）
└── transfers/             ← 初回 Ingest 時のメタデータ（既存、変更しない）
    └── metadata-test2-/
        ├── ead.xml
        ├── mods.xml
        └── source-metadata.csv

source-metadata.csv（Reingest 用）:

filename,metadata,type
objects,dc-reingest.xml,DC-CUSTOM
objects,mods-updated.xml,MODS

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

Reingest の承認と処理

# Reingest の承認
curl -X POST "http://127.0.0.1:62080/api/ingest/reingest/approve/" \
  -H "Authorization: ApiKey test:test" \
  -d "uuid="

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

結果: Reingest 後の METS.xml

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

dmdSec	STATUS	TYPE	説明
dmdSec_1	`original`	PREMIS:OBJECT	SIP 識別情報（変更なし）
dmdSec_2	`original`	OTHER(EAD)	初回 Ingest の EAD（変更なし）
dmdSec_3	`original-superseded`	OTHER(MODS)	初回 Ingest の MODS（superseded に変更）
dmdSec_4	`update`	OTHER(MODS)	Reingest で追加された更新 MODS

dmdSec_3（旧 MODS → superseded）:

mets:dmdSec ID="dmdSec_3" CREATED="2026-02-17T01:57:54" STATUS="original-superseded">
  mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="MODS">
    mets:xmlData>
      mods xmlns="http://www.loc.gov/mods/v3" version="3.6">
        titleInfo>
          title>Test Document for MODS Metadata Validationtitle>
        titleInfo>
        
      mods>
    mets:xmlData>
  mets:mdWrap>
mets:dmdSec>

dmdSec_4（新 MODS → update）:

mets:dmdSec ID="dmdSec_4" CREATED="2026-02-17T02:15:22" STATUS="update">
  mets:mdWrap MDTYPE="OTHER" OTHERMDTYPE="MODS">
    mets:xmlData>
      mods xmlns="http://www.loc.gov/mods/v3" version="3.6">
        titleInfo>
          title>Test Document - MODS Updated via Reingesttitle>
        titleInfo>
        originInfo>
          dateCreated encoding="w3cdtf">2025-01-15dateCreated>
          dateModified encoding="w3cdtf">2025-06-01dateModified>
        originInfo>
        note>This MODS record was updated via metadata reingest.note>
      mods>
    mets:xmlData>
  mets:mdWrap>
mets:dmdSec>

structMap の変化

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

mets:div TYPE="Directory" LABEL="objects" DMDID="dmdSec_2 dmdSec_3 dmdSec_4">

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

mets:div TYPE="Directory" LABEL="metadata">
  
  mets:div TYPE="Directory" LABEL="transfers">...mets:div>
  
  mets:div TYPE="Item" LABEL="dc-reingest.xml">...mets:div>
  mets:div TYPE="Item" LABEL="mods-updated.xml">...mets:div>
  mets:div TYPE="Item" LABEL="source-metadata.csv">...mets:div>
mets:div>

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

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

XML validation schema not found for keys: ['http://purl.org/dc/terms/', 'dcterms']

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 設定に未登録）

注意点

XML Validation 設定 : XML Validation が有効な環境では、使用するメタデータスキーマの名前空間をバリデーション設定ファイルに登録する必要があります。未登録の場合、メタデータはサイレントにスキップされます。エラーはログにのみ記録され、Ingest / Re-ingest の処理自体は続行されます。
MDTYPE の扱い : source-metadata.csv 経由のメタデータは常に MDTYPE="OTHER" で格納されます。MDTYPE="MODS" や MDTYPE="EAD" のように METS 標準の MDTYPE 値として格納されるわけではありません。
Reingest 時の source-metadata.csv の配置場所 : 初回 Ingest では metadata/transfers/<transfer-name>/source-metadata.csv が使用されますが、Reingest では metadata/source-metadata.csv（ルートレベル）のみが処理されます。
type カラムによるメタデータの版管理 : source-metadata.csv の type カラムは、Reingest 時のメタデータ更新の識別子として機能します。同じ type 値を使用すると既存の dmdSec が superseded となり、新しい type 値を使用すると新規の dmdSec が追加されます。
名前空間ベースの登録 : 同じメタデータ標準（例: Dublin Core）でも、使用する名前空間 URI が異なれば、それぞれを XML Validation 設定に登録する必要があります。

Archivematica における非DCメタデータの登録検証 ── source-metadata.csv を使ったEADの組み込み

目次

背景と目的

source-metadata.csv の仕組み

CSVフォーマット

Transfer のディレクトリ構成

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

処理の流れ

XML Validation 機能

概要

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

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

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

検証環境

Transfer パッケージの作成

API による Transfer の実行

結果

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

XML Validation 設定の修正

API による Transfer の実行

結果: METS.xml の dmdSec

structMap での関連付け

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

MDTYPE 属性の扱い

STATUS 属性

XML ファイルの保存先

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

検証の目的

Reingest の開始

メタデータの追加

Reingest の承認と処理

結果: Reingest 後の METS.xml

structMap の変化

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

まとめ

検証結果の要約

注意点

参考リンク

目次#

背景と目的#

source-metadata.csv の仕組み#

CSVフォーマット#

Transfer のディレクトリ構成#

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

処理の流れ#

XML Validation 機能#

概要#

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

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

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

検証環境#

Transfer パッケージの作成#

API による Transfer の実行#

結果#

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

XML Validation 設定の修正#

API による Transfer の実行#

結果: METS.xml の dmdSec#

structMap での関連付け#

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

MDTYPE 属性の扱い#

STATUS 属性#

XML ファイルの保存先#

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

検証の目的#

Reingest の開始#

メタデータの追加#

Reingest の承認と処理#

結果: Reingest 後の METS.xml#

structMap の変化#

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

まとめ#

検証結果の要約#

注意点#

参考リンク#

目次

背景と目的

source-metadata.csv の仕組み

CSVフォーマット

Transfer のディレクトリ構成

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

処理の流れ

XML Validation 機能

概要

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

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

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

検証環境

Transfer パッケージの作成

API による Transfer の実行

結果

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

XML Validation 設定の修正

API による Transfer の実行

結果: METS.xml の dmdSec

structMap での関連付け

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

MDTYPE 属性の扱い

STATUS 属性

XML ファイルの保存先

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

検証の目的

Reingest の開始

メタデータの追加

Reingest の承認と処理

結果: Reingest 後の METS.xml

structMap の変化

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

まとめ

検証結果の要約

注意点

参考リンク