How Metadata Quality is assessed in Europeana(Europeanaの報告書より)

http://pro.europeana.eu/files/Europeana_Professional/Publications/Metadata%20Quality%20Report.pdf

Europeanaのメタデータマネジメントの実態が垣間見える“Report and Recommendations from the Task Force on Metadata Quality”(2015年5月)という報告書をざっと読んだ。

図書館界隈でもウェブ上に分散するシステムからメタデータをアグリゲートして大規模なデータベースを構築するという例は少なくない。そういったシステムにおいてはしばしば汚いメタデータと格闘するはめになる(はずだ)が、その実態を知る機会は少ないのでこの報告書はとてもありがたい。特に多言語環境のメタデータマネジメントの苦労は気になるところだった。

報告書の概要はカレントアウェアネス-Eで阿部さんがみごとに紹介されている(これまたありがたい)。ただ、原文を読んでみたらいろいろ面白い(自分好みの)情報が書かれていたので、特に私が強く興味を持った“How Metadata Quality is assessed in Europeana”というセクションについてメモしておきたい。


疎外感

いきなり

Members of the Task Force, and data partners contributing to the Europeana Aggregators’ Forum, raised issues of feeling excluded from Europeana. They felt that they did not understand what happened to their data once it left their own repositories.

という出だしに思わず笑ってしまった。そう。疎外感がある。


EDM(Europeana Data Model)における9個の必須要素

Fig 2.1.1に挙げられている要素は以下の通り。9個じゃなく10個あるけど最後のは「あれば必須」。

  • edm:dataProvider
  • edm:isShowAt or edm:isShownBy
  • edm:provider
  • edm:rights
  • edm:aggregatedCHO
  • dc:title or dc:description
  • dc:language for text objects
  • dc:subject or dc:type or dc:coverage or dcterms:spatial
  • edm:type
  • edm:ugc (when applicable)

最低限これだけはということで定められているようだけど、“In practice, the mandatory elements are sometimes misinterpreted, accidentally misused or contradictory. ”ということらしい。

EDMについてはこちらを参照。CHO = Cultural Heritage Object、か。aggragatedはOAI-OREにちなんでいる。
http://pro.europeana.eu/page/edm-documentation

Europeana Publishing Guideというガイドラインがあるらしい。
http://pro.europeana.eu/publication/publication-policy


Europeana Aggregation teamによるメタデータチェック

体制

人手によるチェック。まず気になるのは担当者の人数(FTE)とエフォート率。

The ingestion procedure is undertaken by a team of four Operations Officers who manually process all datasets submitted by data providers to Europeana. There is usually a period of two weeks during the month during which EDM datasets are harvested, assessed, edited and enriched to be published on the Europeana portal and API.

ワークフロー

基本的なフローは阿部さんの記事にあるとおりなので省略。プレチェック→マッピング→必須要素チェック→重複除去、の流れ。

・データセットから抽出したサンプルをEDM XMLの生データで確認する。
・フィールドの出現回数や一意のデータの数など,メタデータの統計を確認する。
・品質評価ツールMINTを使って,各フィールドの種別とその記述内容が合致している かを確認する。
・EDMスキーマへのマッピングを確認する。
・識別子に重複があるレコードを確認し削除する。
http://current.ndl.go.jp/e1688

ツール

このフローのなかで登場するのが

というツールたち。

最初のSugarCRMは本当はメタデータチェックとは関係ないんだけど、なるほど、ここでCRMツールを使うんだ、と驚いた。図書館利用者への問い合わせ対応をCRMで、履歴を全学で共有して、ってのはむかし考えてたけど……。

残るREPOX、UIM、MINTの3つがメインのツールになる。このうちMINTが一番重要。なお、REPOXとMINTはD-NET(OpenAIREのインフラ)でも使われていると別の文献で読んだ。
http://dx.doi.org/10.1108/PROG-08-2013-0045

統計を確認?

上の2番目の「メタデータの統計を確認する」はことばだけだとちょっと分かりづらい。例えばMINTではデータセットのざっくりした感じをつかめるようで、例えば以下の図は @rdf:about が258494件あるけど、ユニーク(distinct)な dc:title は61169件、dc:description は11件しかない、なんかやばい、という例を示したもの。

f:id:kitone:20160202193728p:plain

その他に edm:isShownAt や edm:isShownBy に記述されたリンクをチェックしたり、外部のシソーラス(Getty Art and Architecture Thesaurus等)へのリンクが適切かどうかをチェックしたり(ここでUIMシソーラスのデータを引っ張ってきて表示してくれる。これがデリファレンスだろう)。

必須要素等のチェック

オリジナルのスキーマからEDMにマッピングしたあとで、MINTによって必須要素等のチェックが行われる。以下の図ではいろいろエラーメッセージが出てますね。

f:id:kitone:20160202195136p:plain

重複除去

最後に重複除去。これはMINTではなくUIMのほうで行うらしい。

This only occurs when the identifiers (rdf:about of the edm:ProvidedCHO) are duplicates or near duplicates in the dataset. Unfortunately, it does not apply duplication checks to all metadata 39/54 Report and Recommendations from the Europeana Task Force on Metadata Quality fields and so cannot identify multiple records containing the same titles or descriptions.

というだけのことらしく、機械学習メタデータを処理して……という想定とは大きく異なっていた。


メタデータチェックにおけるパートナー機関の役割

ざっくりいえば、メタデータ提供する前に自分たちでしっかりチェックしといてね、という感じ。MINTを使ってるパートナー機関も一部存在するらしい。