みなみの備忘録

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

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は、デジタルオブジェクトを動作またはサービスに関連付ける機能を提供します。上記の説明ではスキーマの主要な機能を強調しましたが、その機能の全範囲を理解するには、スキーマとそれに含まれるドキュメントを徹底的に調べる必要があります。

2022年3月～9月のメモ

半年以上空いての更新となりました。9月から職名が変わり、研究員になりました（が、やることは変わっていません）。3月から博論執筆が本格化し、振り返る頭の余力がなくなっており・・・無事に学位も取得できたので、ぼちぼち再開します。3月から9月まではキーワードだけ列挙する方向で。

 

＝＝＝＝＝

3月

4月

  • JDCatサロンインタビュー記事まとめ
  • IDCC22予稿提出
  • LaTeX勉強
  • 博論提出（一次）

5月

6月

7月

  • 本務諸々
  • 博論提出（二次）
  • 公聴会＋本審査
  • JOSS2022セッション報告記事執筆（9月末公開予定・・だが遅れている様子）

8月

  • Asia OA webinar開催（Webinar: Institutional Repositories Assessment）
  • JDCatサロンインタビュー記事まとめ
  • COAR community framework ver.2翻訳（公開調整中）
  • RDM事例集取りまとめ
  • 博論最終調整

9月

2022年2月のメモ

年度末らしく、〆切に追われる日々。久々にモチベーション（というか体力）の限界を感じる。。。もはや事実の列挙しかする余裕もないけれども、メモとして残します。

＝＝＝＝
上旬

RDM事例形成プロジェクトの第2回意見交換会を実施。プロジェクトメンバーの属性がバラバラなせいか、毎回アンカンファレンスの様相を呈していて大変面白い。当初3年間のプロジェクトは一旦終わりだけれども、来年度以降も何か出来ると良いですね。
8日は2か月ぶりに出勤。職場が大規模な模様替えをするとのことで、書籍梱包作業のリーダーを任される。もう肉体労働しかないだろうと考えてPCは持参せず、午前中いっぱいで作業は終わり。久々にリアルな人とお話しました。

 

中旬
急遽舞い込んできた発注の仕様書作成に追われる。本来ここでやっておきたかった執筆とかインタビュー記事の作成とか報告書作成とか、諸々が後回しに・・・これかなりきついかも。いくつか微妙に〆切を破りつつ、何とか乗り切った（はず）。
某書籍出版企画の校正に着手。10万文字以上もあるのに驚き。用語の統制が一番の課題かも。
その他、執筆中の論文が最終の詰めに入ってから一気にペースダウン。。。書けば書くほどappendixが増えていく。困った。

 

下旬
久々に外部イベントに参加。今年度は一回きりだったSPARC Japanセミナーを聴講しました。

国際学術情報流通基盤整備事業 │ イベント情報 │ 2021 │ 2021年度「研究データポリシーが目指すものとは」

第2部、流石に登壇者の人数多すぎではと思いつつ、終わってみると対面でやってた時のフロア質問に近い感じに収まったような。喋って欲しいステークホルダーがいるのであれば、ディスカッションだけでも加わってもらうのは良い手かもしれない、と企画側の視点で見ていました。
2月末〆切の原稿、とうとう間に合わず・・・関係者の皆さま、誠に申し訳ないのですが今しばらく猶予をください。

2022年1月のメモ

毎月の振り返りも2年目に入りました。のっけから書き出しが遅れましたが、今年も何とか続けたいです。

＝＝＝＝

上旬

お正月は大学院生らしく粛々と論文の執筆を。図表を年末にまとめて整理できたので、気持ちが大分楽になった。全く年末年始感がないままに4日からしっかり仕事が始まる。年末に暖めていた全国規模のアンケート調査が早速スタート。

機関リポジトリ／データリポジトリの運用実態に関するアンケート調査を開始しました
←相変わらずアンカーリンクが効かない・・・

 

中旬

学会用の研究報告執筆に追われる。過去に公開された文献を見るといつも書いていた分野とは違ったノリの報告が多く、割と書きあぐねていたものの、後半になってようやく感覚が掴めてきた。この週は割とじっくり向き合う時間が取れたのが幸いだったか。


下旬

21日はデジタル公共文書の勉強会。専門外での発表だったのでやや不安だったものの、少人数で密度の濃い議論が出来た。専門家に揉まれるのはやっぱり楽しいですね。次の週には持ち越し課題となっていた某ガイドライン執筆打合せ。どんどん話題が膨らみ、100ページを超えそうな勢いに・・・まあ、書いてから考えよう。

最終日にはこちらも持ち越し課題の書籍出版プロジェクト打合せを実施。11月のミニワークショップが反映された厚みのある内容になってきました。完成が楽しみです。

2021年12月のメモ

今年ももうすぐ終わり。無事に毎月の記録をつけ終えられそうです。意外と振り返る機会も多かったため、頑張って来年も続けてみよう。

＝＝＝
上旬

九州大学ーイリノイ大学による合同シンポジウム「デジタルトランスフォーメーション(DX)時代のデータキュレーションと情報管理」に参加。

【12/9開催】Kyushu-Illinois Strategic Partnership Colloquia Series：#4 | Global Gateways Kyushu University

講演資料：Data Curation and Information Management in the Age Digital Transformation - Collections | Kyushu University Library

両大学での実践的な取り組みを中心に、データキュレーションに関する幅広い講演があった。個人的に面白かった講演は、Allen Renearさんの「データキュレーション教育：2つのコース例とその振り返り」。イリノイ大ではデータキュレーションに関する教育を、サービス管理者向けとデータサイエンティスト向けの2つに分けて実践しているとのこと。極めて大雑把に両者の関係を整理すると、前者はデータキュレーションの運用に関すること、後者はデータモデルやデータ統合、クリーニングといったエンジニアリングに関すること、を教えているらしい。確かに求められるスキルが全然違うので、分けて教えるのはとても合理的だと納得しつつ、後者に対して国内ではあまり触れてこなかった点にやや反省。
データキュレーションの実践を国内でどう展開するか、は来年の大きな課題になりそうなので、どこから取り掛かるべきか年末の宿題とします。

中旬

博士課程の中間発表2回目。現在の研究活動紹介と、博士論文執筆に向けた議論など。研究活動は概ね順調、と評価いただいたものの、やはり全体を通じたストーリー展開にまだ課題がありそう。これも年末じっくり考えますか。
12/15はAXIES年次大会に参加。

2021年度 年次大会｜2021年度 年次大会｜年次大会｜大学ICT推進協議会 - AXIES

結局RDM部会セッションしか出られなかった・・・相変わらずのオンライン参加なので普段の会議と代わり映えがしないが、今年で終了のプロジェクトについて、後継をどうするか議論する貴重な機会。そろそろ次の企画書を書かないと。
その他、JSPSデータインフラ事業で行っているインタビュー記事第4弾が無事公開された。
JDCatサロン - 公的統計データの利活用

毎回ディープなお話を聞けるのでとても気に入っている企画。来年度以降も引き続き実施できないか交渉したいところ。

 

下旬

職場の忘年会は結局出られず（というか時間帯を忘れてた）。
最終週になって、自宅回線の機器故障。全く仕事にならない・・・復帰までの2日間が恐ろしく長かった。とはいえネットに依存した業務体制自体は変えようがなく、むしろ来るタイミングが年末で良かったというべきか。
27日開催の某経営委員会は奇跡的に機器が稼働してくれたおかげで、スムーズに終了。最近は原稿の校閲をする機会が減ってしまい少し物足りない気持ちが・・・そんなこともないか。自分の論文を早く書きます。

2021年11月のメモ

引き続きイベント続きの月でした。今月は国内イベントが中心（といってもRDAは結構ボリュームがあった）。成果物もいくつか無事に公開へこぎ着けて一安心。

＝＝＝＝
上旬はRDA 18th plenaryにバーチャル参加。

RDA's 18th Plenary: Programme | RDA

今回は喋る機会はなかったものの、図書館総合展と時期が重なったこともあり妙に慌ただしい気持ちに。個人的に一番興味深かったのはGORCのセッション。

Building the International Model for the Global Open Research Commons (GORC) | RDA

グループ名のスケールの大きさとは裏腹に、検索タグの付与に使用する用語といったかなりニッチな部分を詳細に議論しており、地に足がついた進め方に感銘を受けた。

職場のブログにも感想を書きました（こっちは概要のみ）。

RDA 18th plenary に参加しました｜活動報告｜国立情報学研究所 オープンサイエンス基盤研究センター

他にはデータリポジトリのセッションにも興味あったのだけど、朝1時スタートということで力尽きた。あとで録画を見ます。

Defining Common Attributes for Data Repositories | RDA

並行して、図書館総合展でフォーラムを1つ開催しました。

学術機関による研究データのキュレーションサービスを考えよう

日本の大学図書館ではほぼ根付いていないデータキュレーションサービスを取り上げたので、そもそも人が来てくれるのか不安があったものの、登壇者の方々のお陰で400人を超える方に登録いただいた様子。質疑応答も活発で、大変充実したセッションになりました。 

もう一つ、「人文学・社会科学におけるデータ共有のための手引き」が無事に公開されました。

人文学・社会科学におけるデータ共有のための手引き

足掛け2年ほど？社会科学を中心にいろいろな分野の方々と濃い議論をし、普段と違った読者層への書き方で悩んだりと、非常に貴重な経験ができました。今後各所での活用に期待しています。

 

中旬は某書籍出版計画が本格始動。共同執筆陣でミニワークショップを3回くらい行い、ひたすら構成を考える。これ超面白い。
並行して、JPCOARの総合展セッションに合わせる形で、某タスクフォースで作成していたチェックリストを公開しました。

「リポジトリのグッドプラクティスのためのCOARコミュニティフレームワーク」チェックリスト ver.1

こっちは半年くらいの成果物であるものの、かなり密度の濃い議論や展開でした。今年度の残りは活用と普及方法に注力することになりそうです。

 

下旬、11/22はRDUFの総会・公開シンポジウムに参加しました。

イベント | 研究データ利活用協議会 RDUF（Research Data Utilization Forum）

（イベントの固定リンクがないの地味にやりづらい・・）

自分は活動中の部会の進捗報告などを担当しつつ、今回はかなり聞きに回る。総会のライトニングトークがさらに充実した印象。それと、今回初のプレナリーセッションが非常に興味深いご講演でした。これは是非続けてほしい。

もう一つ、九大さんのシンポジウムを聴講。

シンポジウム「情報管理組織のミッションと専門職養成」開催のご案内 – 統合新領域学府 ライブラリーサイエンス専攻

別用がありやや聞き流す形になってしまったものの、ご講演は非常に興味深かった。司書の方はかなり技術寄りなご講演、アーキビストの方は理論的な側面が強いご講演という対比があり、さらに「残すべき情報」に対しては似たような指摘をされているようでいて、文脈に対する意識が大分違うように感じた。強いて言えば、前者は情報の新たな活用可能性を意識した文脈の付与、後者は情報解釈の正統性に対する文脈の付与、という感じだろうか（いまいちうまく表現できていない・・）。

どちらも必要な情報だけれども、リッチなメタデータ付与には当然コストがかかる。特に知識インフラに関わる専門性はなぜ必要なのか、どう役立つのかの議論はもう少し外向けに分かりやすい形でやっていく必要があるかもしれない（データライブラリアン職である自分の宿題そのものですね）。

2021年10月のメモ

国際会議への参加が多い月でした。英語力向上の必要性を痛感。自宅にいながら自然と鍛えられる方法が欲しい・・・今月は週別に書き留めるほどの分量がないため、ざっくりまとめて記載。

＝＝＝＝

上旬はなぜか各種問い合わせが殺到。イベント（図書館総合展／RDUF公開シンポジウム）関係、学会関係、共同研究関係と盛りだくさん。ひたすら調整しているうちに過ぎていった感じでした。
合間を縫って、各所へ最近立ち上げたRDM関連掲示板の広報などを。

RDM 日本コミュニティ - 研究データ管理に関する日本語コミュニティ

問い合わせ（というか対応）がさらに増えた気もする。

 

中旬はeResearch Australasia 2021に参加。

https://conference.eresearch.edu.au/2021-program/

オーストラリアの活動中心の会議であるものの、5日間にわたり様々なセッションが開催され、大変活気のあるイベントでした（初参加）。そのうち職場の日誌から参加報告を出すかもしれない。
もう一点、執筆が止まっていた某イベントの参加報告をやっとこさ出す。遅れてすみませんでした・・・

 

下旬はCOAR Asia OA meeting 2021に参加。

COAR Asia OA Meeting 2021 | Singapore Management University (SMU)

こちらも何気に初参加。シンガポールの方々の運営が素晴らしかった。
本イベント、アジア各国の取り組みを広く聞けるのが魅力の一つだが、今年はCOAR本体へのフィードバックを意図したセッションもいくつか用意されており、Asia OAグループの存在感が増してきたことを実感。うまく一緒に進めていきたいところ。
あとは、今更ながら進行中のプロジェクトを紹介するページを立ち上げました（2年遅かった・・かも）。

AXIES-JPCOAR 研究データ連絡会 - RDM事例形成プロジェクト

来年度以降も何らかの形で続けていく、ということでご容赦を。