公開はゴールではなく、長い後半戦の始まりである。データセットが参照され続けるには、更新と版の管理、リンクの維持、形式の陳腐化への対処、そして誰が何をしたかの記録が要る。地理・画像・三次元のデータは、ファイルが大きく、形式の変化が速く、配信に専用の仕組みを要するため、これらの課題がとくに切迫した形で現れる。
更新・版管理・撤回
データセットは公開後も修正や拡張が続く。どの版がいつ公開され、何が変わったかの記録がなければ、引用した研究者は後から同じデータを参照できない。版に識別子を対応づけて引用可能にする設計は、「識別子とデータ引用」を参照。
撤回も記録の問題である。データを非公開に戻した場合、その事実と理由を残さないと、リンクが単に切れたのか、意図的に下げられたのかが判別できない。公開可否を判断する基準は「公開できるもの・できないもの」を参照。
リンクが切れること、形式が読めなくなること
公開したデータへの参照は、二つの経路で壊れていく。URL が無効になることと、形式が将来のソフトウェアで読めなくなることである。
URL の維持については、DOI や ARK の解決サービスを長期にわたってどう運営するかという問いがある。しかしこの問いを論じた記事は本節にも「識別子とデータ引用」にも紐づいておらず、ここでは扱えない(末尾の「現時点で薄い領域」を参照)。
形式の陳腐化への備えとして、標準に沿ったメタデータ記述が働くことは、バム遺跡の三次元復元の事例から読み取れる。この事例では公開にあたり、資源をクラスとして体系化するオントロジー的な記述を採り、Dublin Core などの標準語彙と国際標準の Object ID を組み合わせ、Protégé でメタデータを作成し、RDF ストアに PostgreSQL、RDF の API に Apache Jena を用いた [UC-020 §メタデータの管理と公開]。標準ベースの記述は、データの形式が変わってもメタデータの意味を保ちやすい。ただし、この事例が示しているのはメタデータの設計であり、三次元データそのものの形式の移行に踏み込んだ記述ではない。
標準に沿った記述をしていても、配信先の維持は別の問題として残る。同プロジェクトは Bam3DCG というサイトでデータの一部を公開していた [UC-020 §メタデータの管理と公開]。記事の更新記録によれば、このサイトのリンクは後に切れていることが確認され、関連リンクから削除された [UC-020]。長期公開を意図した設計が整っていても、配信先の消失は防げない。
誰が何をしたかの記録
データの来歴と処理の記録は、再利用と検証の前提になる。バム遺跡の事例では、オントロジーの設計の背景に共同研究者の研究があったこと、メタデータの作成に Protégé を使ったことが記されている [UC-020 §メタデータの管理と公開]。誰がどの処理をどの道具で行ったかが残っていれば、後からデータを使う研究者は、その処理の信頼性を自分で評価できる。
地理・画像・三次元のデータに固有の難しさ
ファイルが大きい、形式の変化が速い、閲覧に専用の配信基盤が要る、という三点が、地理・画像・三次元のデータに共通する難しさである。三次元データの形式と処理の詳細は「三次元の計測と復元」を参照。
配信の側では、メタデータの標準化に加えて、RDF ストアや API のような技術基盤が伴うことが、バム遺跡の事例から読み取れる [UC-020 §メタデータの管理と公開]。こうした基盤は、データを一度置くだけでなく、機械的に参照できる状態で維持するために要る。ただしその運用コストや担い手をどう確保するかは、この事例からは分からない。