■権利の壁
「デジタルアーカイブにおける「権利の壁」としての肖像権. ➢ 肖像権は法律上明文化された権利ではなく、裁判例で認められた権利. ➢ 最高裁は、法廷での撮影行為等が ...」
■ウェブアーカイブ文献
Niu, J. (2012). An overview of web archiving. D-Lib magazine, 18(3/4).
Vlassenroot, E., Chambers, S., Lieber, S., Michel, A., Geeraert, F., Pranger, J., ... & Mechant, P. (2021). Web-archiving and social media: an exploratory analysis. International Journal of Digital Humanities, 2(1), 107-128.
□SNSとウェブアーカイビング
◇山口和紀 2023 「社会運動のウェブアーカイブズの可能性——ウェブ上の記録をいかに後世に繋ぐのか」，日本社会学会「社会学教育委員会企画テーマセッション質的データのアーカイブ」 https://jss-sociology.org/other/20230818post-14856/#d27
■メモ
20220906→立岩
「紙」の話で考えられてきた難しいことばはいろいろとありますが、アーカイビングの段階を次のように考えてみます。
- 集める
- 整理する
- 公開する
社会運動のウェブアーカイビングについて「集める」の話は書きました＝003に載せたい原稿。「整理する」「公開する」については書いていません。
すこし広げてみると、他のことでもそうだと思います。例えば、ブログのウェブアーカイビングです。
集める→ブログを集めることはある程度できると思います。それを自動化することもできます、いまやってます。ウェブアーカイブスの構築というと、集めることにまず焦点行くと思いますが、ただそれは集める部分の話にすぎず、整理して公開するまで考える必要あると思います。
整理する→なにをどのように整理すればアーカイブスとして適切なのか。これは直感的には、データベースの設計ということになると思います。ブログでもＳＮＳでも一般的に設定できる属性データ（取得日時・種類・タイトル・データサイズetc）があると思いますが、まずこれはどうなるのか。あとは種類別に属性データがあるはずなので、それを考える（たとえばブログなら１記事ごとにまとめるとして、いつ・だれが・どこに載せたものなのかetc）ことも必要です。「紙」で言うところの目録を作ったり、保存場所を適切な場所にしたり、要らないものは捨てたり（トリアージ？）・・・などです。
公開する→紙の資料であれば「所蔵されてはいるが閲覧には許可がいる」「閲覧はＯＫだがコピー禁止」・・・などあります。これはウェブアーカイブスにおいてもそうで、集めたもの全部公開していいのか、だめだとしてどのように区分するのかという問いは立つと思います。公開しないけれどもそこにあつめておいてよいもの、もあるのかもしれません。集めて整理したものをどのように公開するのかは考えないといけないはずです。
それで自分の話を考えてみます。
Twitter社がなくなれば、Twitterのデータがすべて消えてこまる（かもしれない）とします。そうだとすると、とりあえず「おかみ」が「集める」はきちんとやったほうが良いのではないか、と言えると思います。
ただそれだけで良いとは言えず「整理する」はもっと小さい動きだと思います。例えば「集める」でもってきたデータを「ハッシュタグ運動」で細切れにして整理しておく、というのは誰がやるのか、ということを考えてみます。仮に国会図書館がTwitterのデータを集めてきたとして、それを国会図書館が「整理する」ということになるのかといえば、無理だと思います。整理の仕方はいろいろありますし、本に請求記号ラベルをつけて並べるみたいなものとはまったく性質が違います。国会図書館が無理なら基本無理だと思います。もっと市井が「整理」を担当するということになるのではないでしょうか。
ただ、とりあえず「おかみ」が集めておいてくれるということは意義があって・・・、とかは「運動的に」言わないといけないことの気もします。
Twitterのデータ集めてきたとして、それをどのように整理して、公開するのかはどうかという問いは立つと思います。Twitterのデータすべて集めてきたとして、それを全部公開していいのかと言えば違うと思います。とくに本人が消したいものを含んでいる場合などあると思います（それが「アーカイブス」に入って誰でも見れたら困ります）。どうでしょうか。それが書けるかはわかりません。これはブログでもホームページでもそうだと思いますが。
長々と書きましたが、社会運動のウェブアーカイブスについて「集める」は今回の原稿であきらめて、次は「整理する」「公開する」を書こうと思います。
20220910→Nさん
◇20220909
Nさん作成のPythonスクリプトを受領。スクリプト読んだ。
およそ理解した。構成としては以下。
大きくは、スクレイピングする部分とエクセルに出力する部分に分かれている。
スクレイピングする部分は、おおまかにいうと一番最初の起点になるURLを決めて、そこからそのページのPaginationを辿る方法になっている。この方式はやや問題あるような気もするが動いているので一旦、保留。
そのうえで、改良してみた。改良点は以下。
- YYYY年MM月DD日形式をYYYY-MM-DD形式に変換
- 一番最初の起点になるURLを変数で直接していたが、これはドメインに対して可変のパスなので他のブログに応用が効きにくい。フィードから一番最初の投稿を取得して、それを起点にする方式に変更
- カレントディレクトリを.pyファイルがある場所に変更
それでいろいろ作業してみて思ったことです。すごい細かい話も順序考えずに書いてます。
· 保存場所：
Pythonの実行パスと同じディレクトリに保存されるので、ちょっと不便な気もします。とりあえずですが、実行している.pyファイルと同一ディレクトリに入れるというのが手です。
· URLの起点：
クロールの起点になるURLがブログごとに変わる仕様がちょっと使いにくいですね。なんとかして、ブログのトップから一番最初の投稿を探し当てて、の方がいいと思います。
なぜかというと、大量にブログのリストがあったばあい、いちいち最初の投稿を人間が探しに行くというのが手間だからです。
一番最初の投稿を探す方法については後述。普通に考えると、トップページの投稿が表示されている部分のdivの一番最初の子要素を取る、というパース作戦が一番最初に思いつきます。
· クロールの方式：
なぜPagination使ったクロールにしたのか軽く『遡航』に書いた方がいいかもしれないです。
中井さん方式＝最初にクロールの起点になるURLを決めて、そこからクロールしていく方式、ありだと思いますが、なぜ他ではなくそれなのか、ということは大事だと思います。
以下、ありえそうなクロール方法
- ファイルのディレクトリ、ファイル名でクロールする
そのうえで、思いついたアイデアです。おそらくですが、このサイトは下記のようなネーミングしていると思います。
なので、YYYYMMをブログの一番最初の月、202010から順番に1か月ごと増やしていき、article_1から順番{1,2,3,4,5・・・}にurlFetchする。与えたURLのレスポンスがnot foundになるかどうかでページが存在しているかを判定し、順番にクロールし、202209までクロールする。という作戦があると思います。月ごとに順番に記事の通し番号であるかどうかを判定していく、という作戦です。
と、ここまで書いて、トップからクロールしていく作戦の方が、サーバに負荷がないかもしれないと思いました。なので、たぶんPagination使ったクロールが合理的かもしれないです。すくなくともウェブリの場合。
- RSSでクロールする
いちおう、この位置がフィードになるみたいです。
フィードつかってクロールできたりしますが、これは5ページしか表示されないので無理ですね。
なので、フィードで取る作戦はなし。
ただ、これフィードの位置が固定ですね。逆に一番最新の、中井さん方式ではクロールの起点になる位置が可変です＝ブログによって変わる。なので、このフィードから最新投稿を取得し、ブログのサブドメイン（この場合kazuko1513.at.webry.info）が分かれば、フィードから最新投稿取得して、スクレイピングを開始するということができます。
ブログごとに最新投稿の位置（スクレイピングの起点になるURL）を人力で見ていくのは、数が多い場合には面倒なので。
· 元URL：もとのブログのURLがあったほうがいいかもしれないです。使い道ないかもですが、一応損はしないだろうと思います。たとえばですが、どこかのサイトからリンクが張られていて、それをみたいけどnot foundだった、という場合です。この場合「AAA」というURLの中身が見たいが、そのタイトルも中身もよくわからないということがありえます。だとすると、もともとのURLとタイトル・コンテントの紐づけがあったほうがいいです。たぶん、これはどのブログでも普遍的に起こり得ます。
などと思って、コード改良しました。
.pyファイルは私が使っているメールクライアントでは張れないようです。
メール末尾に改良版を添付します。
改良点は以下です。中井さんにとって改良かどうかは分かりませんが山口的には改良です
- 日時を「YYYY年MM月DD日」方式から「YYYY-MM-DD」方式に変更。
これはデータベース作るときに、なんらかの方法で正規化した方がいいからです。おそらく主流はYYYY-MM-DDか、YYYY/MM/DD方式だと思うので
- トップのURLをドメインから取得する方式にしました。
具体的にはドメインからフィードを取得、フィードから最新投稿を取得して、それをエクセルで出力するオブジェクト（Pythonでそう言うのか忘れました）を生成する関数に渡してます
これによって、ウェブリブログのドメインさえあれば、最新記事の取得は自動化できて楽です。
- デフォルトの保存場所
カレントディレクトリがどこなのかわからなくなると思うので、とりあえず.pyがあるフォルダにエクセルファイルを保存することにしました。
そのために
```
import re
import os
import xml.etree.ElementTree as ET
```
してます。
画像の件
考えてみて、結構難問だと思いました。
普通に取得したいだけなら、簡単ですが、それをアーカイブスにするとなると難しいですね。
どうしたらいいでしょうか。かなり本腰入れて考える必要があるだろうと思います。
とりあえず考えてみたロジックです
記事ごとにパースする
imgタグを見つけてすべてのタグで次の処理をする
imgタグのhref属性が、消えそうなブログサービスのサーバの場合は次に進む
ダウンロードして名前を付けて格納する（名前をnameとする）
href属性をファイルパス+nameに置換する
次の記事に行く
こうしておく、というのがとりあえずブログでは手だと思います。
普通に考えると、画像はその消えそうなサーバだけやるという感じですね。それ以外もダウンロードしておくとなるととんでもないことになります。
よろしくお願いいたします。
投稿日：2022/06/15
修正日：2022/06/15 -> 2022/08/24 -> 2022/09/06 -> 2022/09/10 -> 2023/08/20