みなみの備忘録

とあるライブラリアンの備忘録です。

10/21 "METS: An Overview & Tutorial"試訳

大変久々にブログを活用。METSについて調べ始めたものの、日本語の資料が驚くほどなく、地道にLCのページを翻訳して読み進めることに。まずは導入部分から。

元:

METS: An Overview & Tutorial: Metadata Encoding and Transmission Standard (METS) OfficialWeb Site

====

METS: 概要とチュートリアル

導入

デジタルオブジェクトのライブラリを維持するには、それらのオブジェクトに関するメタデータを維持する必要があります。デジタルオブジェクトの適切な管理と使用に必要なメタデータは、印刷物やその他の物理的な資料のコレクションを管理するために使用されるメタデータよりも広範であり、また異なります。ライブラリがコレクション内の書籍に関する説明的なメタデータを記録する際に、ライブラリが書籍の構成に関する構造メタデータを記録できなかった場合でも、その書籍はページが繋がっていない状態に分解されることはありません;一方で、書籍がリョービオフセット印刷機を使用して作成されたことが記録されていなければ、学者は書籍の価値を評価できなくなります。[しかしながら、]同じ本のデジタル版については、同じ理解が成り立ちません。構造メタデータがなければ、デジタル著作物を構成するページ画像やテキストファイルはほとんど役に立ちません。また、デジタル化プロセスに関する技術メタデータがなければ、学者はデジタル版がどの程度正確にオリジナルを反映しているか確信が持てないかもしれません。内部管理の目的で、ライブラリはデータを定期的に更新して移行し、貴重なリソースの耐久性を確保するために、適切な技術メタデータにアクセスできる必要があります。

Making of America IIプロジェクト (MOA2) は、テキストおよび画像ベースの作品の記述的、管理的、および構造的なメタデータエンコード形式を提供することで、これらの問題に部分的に対処しようとしました。電子図書館連合イニシアチブであるMETS は、MOA2 の成果を基にして、リポジトリ内のデジタルライブラリオブジェクトの管理と、リポジトリ間 (またはリポジトリとそのユーザーの間) におけるオブジェクトの交換の両方に必要なメタデータエンコードするためのXMLドキュメント形式を提供する試みを行っています。METS文書は、用途に応じて、オープンアーカイブ情報システム (OAIS) 参照モデル内の提出情報パッケージ (SIP)、アーカイブ情報パッケージ (AIP)、または普及情報パッケージ (DIP) の役割で使用できます。

 

METS 文書は、次の 7 つの主要なセクションで構成されます。

  1. METS ヘッダー(METS Header)- METS ヘッダーには、作成者、編集者などの情報を含む、METS ドキュメント自体を説明するメタデータが含まれています。
  2. 記述メタデータ(Descriptive Metadata)- 記述メタデータセクションは、METS文書の外部の記述メタデータ (たとえば、OPAC のMARCレコードやWWWサーバー上で維持されるEAD検索補助) を指すこともあれば、内部に埋め込まれた記述メタデータ、あるいはその両方を含むこともあります。外部および内部の両方の記述メタデータの複数のインスタンスが、記述メタデータセクションに含まれる場合があります。
  3. 管理メタデータ(Administrative Metadata) - 管理メタデータセクションは、ファイルがどのように作成および保存されたか、知的財産権、デジタルライブラリオブジェクトの派生元の元のソースオブジェクトに関するメタデータ、およびデジタルライブラリオブジェクトを構成するファイルの出所に関する情報を提供します (つまり、マスター/派生ファイルの関係、および移行/変換情報)。記述メタデータと同様に、管理メタデータは METS 文書の外部に存在することも、内部的にエンコードされることもあります。
  4. ファイルセクション(File Section)- ファイルセクションには、デジタルオブジェクトの電子バージョンを構成するコンテンツを含むすべてのファイルがリストされます。<file> 要素は、オブジェクトのバージョンごとにファイルを細分化するために、<fileGrp> 要素内にグループ化できます。
  5. 構造マップ(Structural Map)- 構造マップはMETS文書の中心です。これは、デジタルライブラリオブジェクトの階層構造の概要を示し、その構造の要素をコンテンツファイルおよび各要素に関連するメタデータにリンクします。
  6. 構造リンク(Structural Links)- METSの構造リンクセクションを使用すると、METS 作成者は、構造マップで概説された階層内のノード間のハイパーリンクの存在を記録できます。これは、METSを使用してWebサイトをアーカイブする場合に特に役立ちます。
  7. 動作(Behavior)- 動作セクションを使用して、実行可能な動作をMETSオブジェクト内のコンテンツに関連付けることができます。動作セクション内の各動作には、特定の動作セクションによって表される一連の動作の抽象定義を表すインターフェイス定義要素があります。各動作には、インターフェイス定義によって抽象的に定義された動作を実装および実行する実行可能コードのモジュールを識別するメカニズム要素もあります。

各セクションとそれらの相互関係について詳しく説明します。

METSヘッダー(METS Header)

METSヘッダー要素を使用すると、METS文書内のMETSオブジェクト自体に関する最小限の説明的なメタデータを記録できます。このメタデータには、METS文書の作成日、最終変更日、METS文書のステータスが含まれます。また、METS 文書に関して何らかの役割を果たした 1 人以上のAgentの名前を記録し、彼らが果たした役割を特定し、その活動に関するメモを追加することもできます。最後に、さまざまな代替識別子を記録することもできます。METS文書は、METSルート要素のOBJID属性に記録された METS文書のプライマリ識別子を補完します。 METSヘッダーの例は次のようになります。

      <metsHdr CREATEDATE="2003-07-04T15:00:00" RECORDSTATUS="Complete">
	<agent ROLE="CREATOR" TYPE="INDIVIDUAL">
	  <name>Jerome McDonough</name>
	</agent>
	<agent ROLE="ARCHIVIST" TYPE="INDIVIDUAL">
	  <name>Ann Butler</name>
	</agent>
      </metsHdr>

この例には、<metsHdr>要素の2つの属性、CREATEDATEとRECORDSTATUSが含まれています。これらは、METSレコードが作成された日時を示し、レコードの処理ステータスを示すために使用されます。このMETSレコード、レコードの作成責任者、元の資料の責任者であるアーキビスト。 <agent> 要素のROLE属性とTYPE属性の両方で、管理された語彙が使用されます。 ROLEに使用できる値は、”アーキビスト”、”作成者”、 " "カストディアン"、"頒布者"、"編集者"、"知的財産権者"、および "その他"です。TYPE属性に指定できる値は、"個人"、"組織"、または "その他" です。

記述メタデータ(Descriptive Metadata)

METS文書の記述メタデータセクションは、1 つ以上の<dmdSec> (記述メタデータセクション) 要素で構成されます。各<dmdSec>要素には、外部メタデータ (<mdRef> 要素)、内部に埋め込まれたメタデータ (<mdWrap> 要素内)、またはその両方へのポインターが含まれる場合があります。

外部記述メタデータ (mdRef): mdRef要素は、外部メタデータの取得に使用できるURIを提供します。たとえば、次のメタデータ参照は、特定のデジタルライブラリオブジェクトの検索補助を指します。

      <dmdSec ID="dmd001">
          <mdRef LOCTYPE="URN" MIMETYPE="application/xml" MDTYPE="EAD" 
          LABEL="Berol Collection Finding Aid">urn:x-nyu:fales1735</mdRef>
      </dmdSec>

この<dmdSec>の<mdRef>要素には4つの属性が含まれています。LOCTYPE属性は、要素の本体に含まれる位置タイプを指定します。LOCTYPE の有効な値には、”URN”、”URL”、”PURL”、”HANDLE”、”DOI”、および”その他”が含まれます。MIMETYPE属性を使用すると、外部記述メタデータMIMEタイプを指定でき、MDTYPEを使用すると、参照されるメタデータの形式を示すことができます。MDTYPE要素の有効な値には、MARC、MODS、EAD、VRA (VRA Core)、DC (Dublin Core)、NISOIMG (デジタル静止画像用の NISO テクニカルメタデータ)、LC-AV (米国議会図書館視聴覚メタデータ)、TEIHDR (TEIヘッダー)、DDI (Data Documentation Initiative)、FGDC (連邦地理データ委員会メタデータ標準 [FGDC-STD-001-1998])、および “その他”が含まれます。LABELは、METS 文書の「目次」表示などのように、METS 文書を閲覧している人にこのメタデータを説明するためのメカニズムを提供します。

 

内部記述メタデータ (mdWrap): mdWrap要素は、METS文書内に埋め込まれたメタデータのラッパーを提供します。このようなメタデータは、次の2つの形式のいずれかになります。1. XML エンコードされたメタデータXML エンコードにより、METSドキュメントの名前空間以外の名前空間に属することが識別されます。または 2. 任意のバイナリ形式またはテキスト形式。ただし、メタデータBase64エンコードされ、mdWrap 要素内の<binData>要素でラップされます。次の例は、mdWrap要素の使用法を示しています。

      <dmdSec ID="dmd002">
	<mdWrap MIMETYPE="text/xml" MDTYPE="DC" LABEL="Dublin Core Metadata">
	  <xmlData>
	    <dc:title>Alice's Adventures in Wonderland</dc:title>
	    <dc:creator>Lewis Carroll</dc:creator>
	    <dc:date>between 1872 and 1890</dc:date>
	    <dc:publisher>McCloughlin Brothers</dc:publisher>
	    <dc:type>text</dc:type>
	  </xmlData>
	</mdWrap>
      </dmdSec>
            
      <dmdSec ID="dmd003">
	<mdWrap MIMETYPE="application/marc" MDTYPE="MARC" LABEL="OPAC Record">
	  <binData>MDI0ODdjam0gIDIyMDA1ODkgYSA0NU0wMDAxMDA...(etc.)
	  </binData>
	</mdWrap>
      </dmdSec>

すべての<dmdSec>要素はID属性を持っている必要があることに注意してください。この属性は、各<dmdSec>要素に一意の内部名を提供します。これを構造マップで使用して、ドキュメント階層の特定の部分を特定の<dmdSec>要素にリンクできます。これにより、記述メタデータの特定のセクションをデジタルオブジェクトの特定の部分にリンクできます。

管理メタデータ(Administrative Metadata)

<amdSec>要素には、デジタルライブラリオブジェクトを構成するファイルに関する管理メタデータと、オブジェクトの作成に使用された元のソースマテリアルに関する管理メタデータが含まれています。METS文書で提供される管理メタデータには主に4つの形式があります: 1. 技術メタデータ (ファイルの作成、形式、および使用特性に関する情報)、2. 知的財産権メタデータ (著作権およびライセンス情報)、3. ソースメタデータ(デジタルライブラリオブジェクトの派生元のアナログソースに関する記述および管理メタデータ)、および 4. デジタル来歴メタデータ (ファイル間のマスター/派生関係、およびファイルで使用される移行/変換に関する情報を含む、ファイル間のソース/宛先関係に関する情報)これら 4つの異なるタイプの管理メタデータのそれぞれには、METS文書の<amdSec>部分内に固有のサブ要素があり、その形式のメタデータを埋め込むことができます: <techMD>、<rightsMD>、<sourceMD>、および<digiprovMD>。これら4つの要素はそれぞれ、METS文書内で複数回出現する可能性があります。

<techMD>、<rightsMD>、<sourceMD>、および<digiprovMD>要素は、<dmdSec>と同じコンテンツモデルを採用しています:これらの要素には、外部管理メタデータを指す <mdRef>要素が含まれる場合、METS文書内に管理メタデータを埋め込む際に使用する <mdWrap>要素が含まれる場合、あるいはその両方があります。これらの要素の複数のインスタンスがMETS文書内で生じる可能性があり、METS文書内の他の要素(構造マップ内の分割や<file>要素など)がそれらを記述する<amdSec>サブ要素にリンクされるように、すべての要素がID属性を持たなければなりません。たとえば、ファイルの準備に関する技術メタデータを含む<techMD>要素があるかもしれません。

      <techMD ID="AMD001">
	<mdWrap MIMETYPE="text/xml" MDTYPE="NISOIMG" LABEL="NISO Img. Data">
	  <xmlData>
	    <niso:MIMEtype>image/tiff</niso:MIMEtype>
	    <niso:Compression>LZW</niso:Compression>
	    <niso:PhotometricInterpretation>8</niso:PhotometricInterpretation>
	    <niso:Orientation>1</niso:Orientation>
	    <niso:ScanningAgency>NYU Press</niso:ScanningAgency>
	  </xmlData>
	</mdWrap>
      </techMD>

<fileGrp>内の<file>要素は、この<techMD>要素を指すADMID属性を使用して、この管理メタデータが識別するファイルに関連するものであることを識別します。

      <file ID="FILE001" ADMID="AMD001">
	<FLocat LOCTYPE="URL">http://dlib.nyu.edu/press/testimg.tif
      </file>

ファイルセクション(File Section)

ファイル セクション (<fileSec>) には、関連ファイルをグループ化するために使用される 1 つ以上の<fileGrp>要素が含まれます。<fileGrp>には、デジタルライブラリオブジェクトの単一のデジタル版を構成するすべてのファイルがリストされます。たとえば、サムネイル、マスターアーカイブのイメージ、PDFバージョン、TEIエンコードされたテキストバージョンなどに対して個別の<fileGrp>要素が存在する場合があります。

次の、オーラルヒストリーのデジタルライブラリオブジェクトのファイルセクションの例を考えてみましょう。このファイルには、TEIでエンコードされたトランスクリプト、WAV形式のマスターオーディオファイル、およびMP3形式の派生オーディオファイルという3つの異なるバージョンがあります。

      <fileSec>
	<fileGrp ID="VERS1">
	  <file ID="FILE001" MIMETYPE="application/xml" SIZE="257537" CREATED="2001-06-10">
	    <FLocat LOCTYPE="URL">http://dlib.nyu.edu/tamwag/beame.xml
	  </file>
	</fileGrp>
	<fileGrp ID="VERS2">
	  <file ID="FILE002" MIMETYPE="audio/wav" SIZE="64232836"
	    CREATED="2001-05-17" GROUPID="AUDIO1">
	    <FLocat LOCTYPE="URL">http://dlib.nyu.edu/tamwag/beame.wav
	  </file>
	</fileGrp>
	<fileGrp ID="VERS3" VERSDATE="2001-05-18">
	  <file ID="FILE003" MIMETYPE="audio/mpeg" SIZE="8238866"
	    CREATED="2001-05-18" GROUPID="AUDIO1">
	    <FLocat LOCTYPE="URL">http://dlib.nyu.edu/tamwag/beame.mp3
	  </file>
	</fileGrp>
      </fileSec>

この場合、<fileSec>には、オブジェクトの異なるバージョンごとに1つずつ、3つの補助的な<fileGrp>要素が含まれています。1 つ目はXMLエンコードされた転写ファイル、2 つ目はWAV形式のマスターオーディオファイル、3つ目はMP3形式の派生オーディオファイルです。このような基本的な例では、オブジェクトのさまざまなバージョンを区別するために<fileGrp>要素は実際には必要ないように見えますが、<fileGrp>は、スキャンされた多数のページ画像で構成されるオブジェクトや、多数のファイルからなる単一のオブジェクトに対しては非常に便利です。このような場合、<file>要素を<fileGrp>に分割できるため、ドキュメントの特定のバージョンに属するファイルを識別する作業が簡単になります。

2 つのオーディオ<file>要素に、同じ値を持つGROUPID属性が存在することに注目してください。これらは、2 つのファイルがオブジェクトの異なるバージョンに属しているにもかかわらず、同じ基本情報を含んでいることを示します (GROUPIDを同じ目的に使用して、スキャンされたページイメージが多数含まれるデジタルライブラリオブジェクト内の同等のページイメージファイルを示すことができます)。

すべての<file>要素には一意のID属性があることにも注意してください。この属性は、ドキュメントの他の部分から参照できるこのファイルの一意の内部名称を提供します。構造マップのセクションを見ると、このタイプの参照が実際に動作していることがわかります。

<file>要素は、<FLocat>要素ではなく<FContent>要素を所有する可能性があることに注意してください。<FContent>要素は、ファイルの実際の内容をMETSドキュメント内に埋め込むために使用されます。これを行う場合、ファイルの内容はXML形式であるか、Base64エンコードされている必要があります。ファイルの埋め込みは、デジタルライブラリオブジェクトをユーザーに表示するために使用するMETSドキュメントを準備するときに通常行うことではありませんが、リポジトリ間でデジタルライブラリオブジェクトを交換したり、デジタルライブラリオブジェクトをオフサイトでアーカイブしたりする場合には貴重な機能となる可能性があります。

構造マップ(Structural Map)

METSドキュメントの構造マップセクションは、デジタルライブラリオブジェクトのユーザーに提示され、ユーザーがオブジェクト内を移動できるようにする階層構造を定義します。<structMap>要素は、この階層をネストされた一連の<div>要素としてエンコードします。各<div>には、どのような種類の分割であるかを指定する属性情報が含まれており、その<div>に対応するコンテンツを識別するための複数のMETSポインタ (<mptr>) およびファイルポインタ (<fptr>) 要素も含まれる場合があります。METSポインタは、別の METSドキュメントを、それを含む<div>の関連ファイル情報を含むも​​のとして指定します。これは、セット内の各METSファイルのサイズを比較的小さく保つために、マテリアルの大規模なコレクション (ジャーナルの実行全体など) をエンコードする場合に役立ちます。ファイルポインタは、現在の<div>によって表される階層内の部分に対応する、現在のMETSドキュメントの<fileSec>セクション内のファイル (場合によってはファイルのグループまたはファイル内の特定の場所) を指定します。

以下に、非常に単純な構造マップの例を示します。

      <structMap TYPE="logical">
	<div ID="div1" LABEL="Oral History: Mayor Abraham Beame"
	  TYPE="oral history">
	  <div ID="div1.1" LABEL="Interviewer Introduction"
	    ORDER="1">
	<fptr FILEID="FILE001">
	  <area FILEID="FILE001" BEGIN="INTVWBG" END="INTVWND"
	    BETYPE="IDREF" />
	</fptr>
	<fptr FILEID="FILE002">
	  <area FILEID="FILE002" BEGIN="00:00:00" END="00:01:47"
	    BETYPE="TIME" />
	</fptr>
	<fptr FILEID="FILE003">
	  <area FILEID="FILE003" BEGIN="00:00:00" END="00:01:47"
	    BETYPE="TIME" />
	</fptr>
      </div>
	<div ID="div1.2" LABEL="Family History" ORDER="2">
	<fptr FILEID="FILE001">
	  <area FILEID="FILE001" BEGIN="FHBG" END="FHND"
	    BETYPE="IDREF" />
	</fptr>
	<fptr FILEID="FILE002">
	  <area FILEID="FILE002" BEGIN="00:01:48"END="00:06:17"
	    BETYPE="TIME" />
	</fptr>
	<fptr FILEID="FILE003">
	  <area FILEID="FILE003" BEGIN="00:01:48" END="00:06:17"
	    BETYPE="TIME" />
	</fptr>
      </div>
	<div ID="div1.3" LABEL="Introduction to Teachers' Union"
	  ORDER="3">
	<fptr FILEID="FILE001">
	  <area FILEID="FILE001" BEGIN="TUBG" END="TUND"
	    BETYPE="IDREF" />
	</fptr>
	<fptr FILEID="FILE002">
	  <area FILEID="FILE002" BEGIN="00:06:18" END="00:10:03"
	    BETYPE="TIME" />
	</fptr>
	<fptr FILEID="FILE003">
	  <area FILEID="FILE003" BEGIN="00:06:18" END="00:10:03"
	    BETYPE="TIME" />
	</fptr>
      </div>
      </div>
      </structMap>

この構造マップは、私たちが(ニューヨーク市のエイブラハム・ビーム市長との)オーラルヒストリーを3つのサブセクションを含んだ形で持っていることを示しています:インタビュアーによる冒頭の紹介、ビーム市長からの家族史、および彼がどのようにしてニューヨーク市に関わるようになったのかについての議論の3つです。これらの各サブセクション/部分は、XMLトランスクリプション、マスターおよび派生オーディオファイルという3つのファイル (以前のファイルグループの例から抜粋) にリンクされています。補助的な<area>要素は各<fptr>で使用され、この部分がリンクファイルの一部のみに対応することを示すとともに、各リンクファイルの正確な部分を識別しています。たとえば、最初の部分 (面接官の紹介) は、ID 属性値が”INTVWBG”と”INTVWND”である文字起こしファイル内の2つのタグの間にある XML 文字起こしファイル (FILE001) の一部にリンクされています。また、2つの異なるオーディオファイルにもリンクされています。このような場合、リンクされたファイル内のID属性値を指定するのではなく、ファイル内のリンクされた資料の開始点と終了点は、HH:MM:SS 形式の単純なタイムコード値によって示されます。したがって、インタビュアーの紹介は、ファイルの時間 00:00:00 から始まり時間 00:01:47 まで続くセグメント内の両方のオーディオファイルにあります。

METS形式の構造リンクセクションは、主要なMETSセクションの中で形式が最も単純で、要素<smLink>が1つだけ含まれています (ただし、その要素は繰り返される場合があります)。 METSの構造リンクセクションは、次のことを目的としています。構造マップ内の項目 (通常は <div> 要素) 間のハイパーリンクの存在を記録します。これは、METSを使用してWebサイトをアーカイブし、そのハイパーテキスト構造の記録を維持したい場合に便利な機能です。サイト自体のHTMLファイルとは別に、サイトを作成します。

例として、別のページにハイパーリンクされている画像を含む WebページのMETSドキュメントの場合を考えてみましょう。<structMap>要素には、2 つのページに対して次のような<divs>が含まれる可能性があります。

    <div ID="P1" TYPE="page" LABEL="Page 1">
      <fptr FILEID="HTMLF1"/>
	<div ID="IMG1" TYPE="image" LABEL="Image Hyperlink to
	  Page 2">
	<fptr FILEID="JPGF1"/>
    </div>

    <div ID="P2" TYPE="page" LABEL="Page 2">
      <fptr FILEID="HTMLF2"/>
    </div>

最初のページ<div>に含まれる<div>内の画像ファイルが2番目のページ<div>のHTMLファイルにハイパーリンクされていることを示したい場合は、<structLink>セクション内に<smLink>要素を含めます。 METSドキュメントの内容は次のとおりです。

      <smLink xlink:from="IMG1" xlink:to="P2" xlink:title="Hyperlink from 
      JPEG Image on Page 1 to Page 2" xlink:show="new"
      xlink:actuate="onRequest" />

上記の<smLink>リンク要素は、XLink構文をわずかに変更した形式を使用しています。すべてのXLink属性が使用されますが、「to」属性と「from」属性は、元のXLink仕様のようにNMTOKENではなくIDREF型として宣言されます。これにより、任意の2つのノード間のリンクの存在を示すことができます。構造マップを作成し、XML処理ツールを使用して、リンクされたノードが実際に存在することを確認します。

動作セクション(Behavior Section)

動作セクションを使用して、実行可能な動作をMETSオブジェクト内のコンテンツに関連付けることができます。動作セクションには 1 つ以上の<behavior>要素が含まれており、各要素には、特定の動作セクションによって表される一連の動作の抽象定義を表すインターフェイス定義要素があります。<behavior>には、インターフェイス定義によって抽象的に定義された動作を実装して実行する、実行可能コードのモジュールを指すために使用される<mechanism>要素もあります。

Mellon Fedoraプロジェクトの次の例のように、デジタルオブジェクトの動作を分散Webサービスへのリンクとして実装できます。

         <METS:behavior ID="DISS1.1" STRUCTID="S1.1" BTYPE="uva-bdef:stdImage"
	  CREATED="2002-05-25T08:32:00" LABEL="UVA Std Image Disseminator"
	  GROUPID="DISS1" ADMID="AUDREC1">
           <METS:interfaceDef LABEL="UVA Standard Image Behavior Definition"
	    LOCTYPE="URN" xlink:href="uva-bdef:stdImage"/>
           <METS:mechanism LABEL="A NEW AND IMPROVED Image Mechanism"
  	    LOCTYPE="URN" xlink:href="uva-bmech:BETTER-imageMech"/>
         </METS:behavior>

以下も参照してください。

結論

METSスキーマは、デジタルライブラリオブジェクトの記述的、管理的、構造的なメタデータエンコードし、これらのさまざまな形式のメタデータ間の複雑なリンクを表現するための柔軟なメカニズムを提供します。したがって、リポジトリ間におけるデジタルライブラリオブジェクトの交換に有用な標準を提供できます。さらに、METSは、デジタルオブジェクトを動作またはサービスに関連付ける機能を提供します。上記の説明ではスキーマの主要な機能を強調しましたが、その機能の全範囲を理解するには、スキーマとそれに含まれるドキュメントを徹底的に調べる必要があります。