公開はゴールではなく、長い後半戦の始まりである。更新と版の管理、撤回、リンクの維持、形式の陳腐化への対処、誰が何をしたかの記録が要る。地理・画像・三次元のデータは、ファイルが大きい、形式が変わる、配信に専用の仕組みを要するといった事情で、これらがとくに切迫した形で現れるはずである。ただし、この節に紐づく記事は三次元データの事例一件のみで、その事例が直接示すのはメタデータの設計と配信基盤、配信先の消失にとどまる。

更新・版管理・撤回

データセットは公開後も修正や拡張が続く。どの版がいつ公開され、何が変わったかの記録がなければ、引用した研究者は後から同じデータを参照できない。撤回も記録の問題である。データを非公開に戻した場合、その事実と理由を残さなければ、リンクが単に切れたのか、意図的に下げられたのかが判別できない。

ここまでは一般的な論の組み立てであり、記事の裏づけはない。版の命名や撤回通知の出し方といった具体的な運用は、記事から導けない。

リンクが切れること、形式が読めなくなること

公開したデータへの参照は、二つの経路で壊れていく。URL が無効になることと、形式が将来のソフトウェアで読めなくなることである。

形式の陳腐化への備えとして、標準に沿ったメタデータ記述が働きうるという読みを、バム遺跡の三次元復元の事例から引き出せる。この事例では公開にあたり、資源をクラスとして体系化して記述するオントロジー的な方法を採り、語彙には Dublin Core などの標準を組み合わせ、国際標準のメタデータとして Object ID も利用した。メタデータの作成にはオントロジーエディターの Protégé を用い、公開には RDF ストアに PostgreSQL、RDF の API に Apache Jena を用いている [UC-020 §メタデータの管理と公開]。標準ベースの記述なら、データの形式が変わってもメタデータの意味を保ちやすいはずだというのは、この節の読みであって記事の主張ではない。記事が述べるのはメタデータの設計と使った道具までで、三次元データそのものの形式の移行には踏み込んでいない。

標準に沿った記述をしていても、配信先の維持は別の問題として残る。同プロジェクトは Bam3DCG というサイトでデータの一部を公開していた [UC-020 §メタデータの管理と公開]。記事の改訂記録によれば、このサイトへのリンクは切れていること(404)が確認され、関連リンクから削除された [UC-020 §関連リンク]。標準的なメタデータを備えていても、配信先そのものの消失は防げなかった。

誰が何をしたかの記録

データの来歴と処理の記録は、再利用と検証の前提になる。バム遺跡の事例では、オントロジー的な記述を採った背景に共同研究者のオントロジー研究があったこと、メタデータの作成にオントロジーエディターの Protégé を使ったことが記されている [UC-020 §メタデータの管理と公開]。誰がどの処理をどの道具で行ったかが残っていれば、後からデータを使う研究者は、その処理の信頼性を自分で評価できる。ただし、この事例が示すのは作成者の背景と使った道具の記録にとどまり、処理の履歴を体系的に残す仕組みまでは述べていない。

地理・画像・三次元のデータに固有の難しさ

ファイルが大きい、形式が変わる、配信に仕組みが要る、という三点が、地理・画像・三次元のデータに固有の難しさだと考えられる。このうち記事から裏づけられるのは、配信の仕組みの側だけである。

配信の側では、メタデータの標準化に加えて、RDF ストアや API のような技術基盤が伴うことを、バム遺跡の事例から読み取れる [UC-020 §メタデータの管理と公開]。こうした基盤は、データを一度置くだけでなく、機械的に参照できる状態で維持するために要る。ただしその運用コストや担い手をどう確保するかは、この事例からは分からない。