Personal Web Archivingでソーシャルメディアのウェブアーカイブを試みるMat Kelly氏

 Mat Kelly氏。通常のウェブアーカイブの方法ではなかなか技術的にアーカイブの難しいSNSなどをPersonal Web Archivingで収集できるようにしてしまおうとしている人みたいです。WARCファイルを作成するChormeプラグインのWARCreateやウェブアーカイブ版XAMMPともいうべきWeb Archiving Integration Layer (WAIL) を公開しています。
Mat Kellyのウェブサイト
http://matkelly.com/
Mat Kelly氏の意図するところは以下の図がわかりやすいです。
次のパラグラフデ解説あり。
from WARCreate and Future Stewardship: An interview with Mat Kelly | The Signal: Digital Preservation
 
 これはWARCreateについての解説ですが、基本的には方向性はこの図にあるのだろうと思われます。Heritrxのようなクローラーでは収集することができないが、WARCで保存することは技術的に可能なfacebook等のウェブサイト、これをPersonal Web Archivingという手法で保存できるようにしたいのかなと。そして、 Mementoとでつなぐと。スライドや資料を全部みたわけではないので憶測もまじりますが、そのように思えます。なかなかおもろいことをするなぁ。
 自分用にとりあえずまとめてみましたが、Mat Kelly氏のスライドもSlideshareでいくつか公開されています。ここで Mementoとかぁと軽く個人的には驚きました。

Making Enterprise-Level Archive Tools Accessible for Personal Web Archiving from matkelly01

An Extensible Framework for Creating Personal Web Archives of Content Behind Authentication from matkelly01
 

The Revolution Will Not Be Archived from matkelly01
 

WARCreate – Create Wayback-Consumable WARC Files from Any Webpage from matkelly01
 

NDIIPP/NDSA 2011 – YouTube Link Restoration from matkelly01
 

NDIIPP/NDSA 2011 – Archive Facebook from matkelly01

Internet Archiveのブリュースター・ケール氏が問うSiteless Websiteの可能性

 Web情報を収集し、保存して後世に残すことを目的としたウェブアーカイブ(参照:Wikipedia)というプロジェクトがあります。日本では国立国会図書館(プロジェクト名:WARP)が進めていますが、もっとも歴史が古く、有名なのは米国のInternet Archiveでしょう。1996年から開始してすでに2600億件のURLを集めたそうです※1
 そのInternet Archiveを設立したブリュースター・ケール氏(参照:Wikipdia)が2012年10月にInternet Archiveのブログで「Siteless Websiteは可能か」というエントリを投稿しています。

 私自身、クライアントサイドでウェブアーカイブはできないのいかと考えることもあり、ケール氏のこの話は個人的に非常に興味の深いところです。本エントリでは「ブリュースター・ケール氏が問うSiteless Websiteの可能性」と題しまして、サーバーレスウェブサイトの話を紹介します。また、それによってウェブがアーカイブされるかもしれない話も少々触れることになります。
 

1.ケール氏がP2Pのファイル配布について意見募集(人材も?)

 まずはケール氏があのエントリでSiteless Websiteについて触れる前段の話から。ケール氏は2012年2月に以下のエントリをInternet Archiveのブログに投稿しました。
 

内容は・・

Internet Archiveには毎日200万人のユーザーがアクセスして大変(しかも、エジプト人と日本人のユーザーが多い)。しかも、同じファイルを何度も何度もInternet Archiveのサーバーからダウンロードするんだぜ。コストもかかるし、帯域くってしょうがない。
   ↓
最初のユーザーがファイルをInternet Archiveのサーバーからダウンロードしたら、次のユーザーはInternet Archiveのサーバーではなく、最初のユーザーがダウンロードしたファイルをP2Pで融通してくれれすればいいじゃない。意見くれ!

というものでした(超意訳)。
 コメントにはP2Pに関するいろいろなコメントが寄せられています(これ理解できたら楽しそう・・・)。個人的にはコメントで言及されているコンテンツ主体のネットワークというContent-centric_networking(Named data networking 参照:Wikipedia)が気になります。 
 

2.Internet ArchiveのBitTorrentを活用したコンテンツ配布の開始

 そして、あのエントリが投稿されて半年後の2012年8月、Internet Archiveは、BitTorrent(参照: Wikipedia)によるP2Pのデータの配布を開始しました(早い・・・)。配布対象のコンテンツは音声ファイル、映像ファイル、電子書籍ファイルです。つまり、ファイル1つで成り立つコンテンツが対象で、複数のファイルが組み合わされて構成されるアーカイブドウェブサイトは対象外のようです。

 コンテンツをP2Pで配信するBitTorrentの仕組みは、BitTorrentの公開する以下の動画が比較的概要をイメージしやすいと思います。 
 
 

 
 厳密にいえば、上のBitTorrentの映像の説明と少し異なるところもありますが、図でまとめると以下のような感じでしょうか。クライアント同士でコンテンツをP2Pで融通しあうわけです。
ある1台の端末がサーバーからダウンロードしたコンテンツAを複数のクライアント同士でP2Pで共有している
図1 Internet ArchiveのBitTorrentを活用したP2Pによるコンテンツの配布のイメージ
 ここまでは、Internet Archiveにくる大量のアクセスをP2Pを使って分散させるというお話でしたが、ケール氏はTorrentFreakのインタビューに答える形で、次は「分散型コンテンツ保存システム(distributed preservation system for content)」を構築したいと述べています。それがSiteless Websiteの話につながります(たぶん)。
 

3.ケール氏、Siteless Websiteの可能性を問う

 ケール氏は2012年10月に以下のエントリ(冒頭にあげたものの再掲)を投稿し、次はSiteless Websiteの可能性を問いかけています。

 Bittorrentがサーバーなしで分散型ファイルサーバーを実現しているように、特定の1つの置き場所を持たないウェブサイトはありえないのか。Siteless Website、おそらくクライアントだけで実現されるサーバーレスウェブサイトと置き換えてもよいのでしょうか。
 ケール氏はSiteless Websiteを以下のように定義しています。

  • Siteless Websiteのホームコンピュータは1つだけではない。
  • Siteless Websiteは時間の経過とともに多くの人間によってサポートされるようになる。

 
 あのエントリでは、詳しくは語られていませんが、先の「分散型コンテンツ保存システム(distributed preservation system for content)」と組み合せて考えるとSiteless Websiteについて、いろいろと想像(妄想)できるところもあります。
 

4.Siteless Websiteとは

 ケール氏の言うSiteless Websiteを少し私の想像で肉付けしてみたいと思います。あくまで私の想像ですので、ご注意ください。
 現在のWebはクライアントサーバモデル(参照: Wikipedia)を基本としてます。コンテンツを配布するサーバーと受け取るクライアントの役割が明確に分かれています。クライアント同士が通信したり、コンテンツをやり取りする場合もその間にサーバーを介することになります(以下の図のB)。
クライアントサーバモデルのイメージ図。1台のサーバーに複数のクライントがリクエストをだして同じリソースを取得している図。
図2 クライアントサーバモデルのイメージ
 同じリソースに対して異なるクライアントからリクエストされてもそれぞれに同じように返すので、その分重複して帯域を食います。これでは負荷がかかる。ということで、Internet Archiveが2012年8月に始めたのが先の項で紹介したBitTorrentを活用したP2Pによるコンテンツの配布でした。
 そして、ケール氏の目指す、「分散型コンテンツ保存システム(distributed preservation system for content)」を実現する”Siteless Website”です。ケール氏の挙げる条件をまとめると以下のようなイメージにあるのではないかと思います。
 

図3 Siteless Websiteのイメージ図 その1(あくまで私の想像です)
 サーバー・クライアント型のウェブサイトが完全に排除されることもないだろうと一応サーバーを残してありますが、Seedたるクライアントからもコンテンツの提供がスタートしています。その後は各端末でどんどん複製され、いわば、各クライアントがホストとなり、クライアント同士でコンテンツをやり取りしていくようになります。
 コンテンツのやりとりの結果として、図4のように各クライアントにコンテンツの複製物がおかれるようになります。
Siteless Websiteのイメージ図その1。次のパラグラフで解説
図4 Siteless Websiteのイメージ図 その2 コンテンツの複製物がクライアント側に蓄積されるイメージ(あくまで私の想像です)
 以上、私が想像しうるSiteless Websiteでした。クライアントサーバーモデルとP2Pが融合するようなWebといえるのでしょうか。利点として以下が挙げられます。

  • クライアント側にコンテンツのアーカイブの役割を担わせることで、ほぼ無限ともいえる大容量のストレージを確保することができる。
  • ウェブサイトのホストであるサーバーやSeedたるクライアントが落ちたとしても、またはコンテンツが削除されたとしても、クライアント側に大量にある複製されたコンテンツによってアクセスを担保することができる。
  • アクセスされればされるほど、クライアント側に大量の複製が作成され、アクセスも分散されていくので、クライアントサーバモデルのように特定のサーバーにアクセスが過度に集中する事態をさけることもできる。

 しかし、P2Pのセキュリティ上の問題や著作権の問題を置いておくとしても課題は多そうです。たとえば、以下の3点が気になります。

  1. ウェブサイトのホストが唯一ではない場合のURIのあり方
  2. 真正性の担保
  3. サーバーやSeedにおかれているウェブサイトが更新したら、クライアントに大量に複製された過去の情報はどうするのか。

 1のURIの問題。クライアントサーバーモデルでは、Webのホストは1つであるため、場所を示すURLが識別子として機能しています。しかし、全く同じコンテンツが複数のコンピュータに大量にあるシステムの場合、URLのような場所を一意に指し示す識別子では、同じコンテンツに対して複数の識別子が振られることになります。コンテンツ主体で考えると。コンテンツ主体の識別子、つまり、どこにあるかは問題にせずに「コンテンツa」と指定できる識別子が必要になるような気がします。 
 2の真正性の担保の問題。間に複数のクライアントが入る可能性がある以上、中継した悪意のある第三者による改変のリスクも無視できません。手元に届いたコンテンツが改変されていないことが分かる仕組み、改変をされたら、されたことが分かる仕組みが必要でしょう。先のエントリ(「「Web情報を保存するとは何か」の続き-」)で述べたような、リソースが転載されたタイミングで付与されるメタデータが重要になってくるのだと思います。
 問題は3の更新の問題ですね。DNSの設定変更のようにWeb中に更新情報を行き渡らせる必要があるのでしょうか。うーん、よくわかりません。しかし、せっかくアーカイブされたウェブサイトですから、そのまま新しいバージョンに上書き更新されるのではなく、(特に公開者が拒まなければ)古いバージョンも保存される仕組みが取り入れられると、Web情報の保存の観点から理想的です。
 課題は多いとは思いますが、W3Cに”Unhosted Web Community Group“というCommunity Group(参照: Web標準Blog)も立ち上げられており、ケール氏以外にもSiteless WebsiteのようなWebを考えている人は結構いるようです。10年、15年後のWebは、今我々が知っているWebと全く異なるものになっているのかもしれません。
 
※1 https://twitter.com/internetarchive/status/298925082103930881

「Web情報を保存するとは何か」の続き-Web情報の保存についての個人的で簡潔な妄想-

 以前、以下のようなエントリを書きました。

 要点をまとめると
 Webにおけるユーザーの行動の結果として、Webを構成するリソース、またはその断片的な一部は、ユーザーにより断片化され、大量に複製される形で残っていくのではないか。
ということでした。言い換えると、画像の転載やテキストの一部のコピペなどより(しかも、それが転載と複製を繰り返されることで)、一部とはいえ、Web上にあった情報は残っていくものもあるんじゃないかということでした(複製にまさる保存手段なしということで)。オリジナルが失われても、転載されたものが一部残っていたおかげで辛うじて当時のオリジナルの情報を部分的にでも再現できるなんてあたりは、紙の史資料と同じですね。
 そして、結果としてそういう形でしか残らなかった情報を将来の人間は活用するしかない場面が出てくるのはないか。ならば、自然に情報が残っていくにまかせるのではなく、少しでもよい方向にもっていくことはできないだろうかと、一応業界人なので考えたりします。
  
 いろいろとあるのでしょうね。少しでも残りやすくするとか、なるべく理想に近い残り方をするようにするとか。
  
 Internet Archiveなどが取り組んでいるようなウェブアーカイビングプロジェクト(参照:Wikipedia)で保存されているような理想的な形ではないとしても、結果として断片的な形で情報が残ることも折り込んで、どうすれば少しでも真正性を担保できるのか、将来の歴史家の負担を軽減できるのかということは図書館がいつか考えなければならないのでないかという気がしてきました。
 具体的に何をすればよいのでしょう。
 すぐに思いつくのが、将来にわたって真正性を担保できるようなメタ情報を少しでもリソースに残すことに貢献することでしょうか。
 リソースにメタデータが新規に付与され、それにメタ情報が追加・修正されるタイミングはざっと以下の2つあるかと思いますが、

  1. リソースが作成されたタイミングで埋め込まれるメタデータ(例としは、Exifなど)
  2. リソースが転載されたタイミングで新たなメタデータが埋め込まれる。

 1は例にもあげたようなExifなど、すでに結構あるかと思います。必要ならその仕様の改訂に意見して必要なメタ情報が残るようにする、ないフォーマットにはメターデータが付与されるように意見を出すとか。
 2はどれくらいあるのでしょうか。そもそもどうすればできるのかも分かりませんが、OSに依存することが結構多そうですね。しかし、どのような経路をたどって、そのリソースがその時代に残ったのかという情報が記録される仕組みが1ファイルレベルで欲しいところです。コピペされたテキストは1ファイルどころではないですが、今の時代に残ったテキストがどういう経路でコピペされ、どのように改変されていったかその差分情報がWikiのように残れば理想的です。そういう仕組みってどうすればできるんでしょうか。
 ところで、今回、真正性、真正性という言葉を多用してしまいましたが、この使い方でよいのかしら・・