« blogの情報処理ツールとしての可能性(2)/谷口敏夫 | トップページ | blogの情報処理ツールとしての可能性(0)目次/谷口敏夫 »

2005年12月 3日 (土)

blogの情報処理ツールとしての可能性(1)/谷口敏夫

承前[目次]
注記:この記事はニフティー社「ココログ」を使ったMuBlogにあり、その目次頁は以下のアドレスである。
    http://asajihara.air-nifty.com/mu/2005/12/blog_fb43.html

0.はじめに


 (Web)logは、いま世界に普及しているが、その多くはカレントな記事、つまり最新記事重視のニュース考察、世相評価、エッセイ、日記などが多い。これは名称が「logを取る」、つまり垂れ流し的に発生する記録を次々と保管していく由来からもうかがえる。縮刷版のない新聞や、録画しないTV番組に似ている。

 しかしながら、現行のblogを支える諸技術の根底には、これがRDBMS[Relational DataBase Management System]をもって最も効果的に運用されている事実からも、決して他の一般ホームページ型サイトと同祖のものではなく、むしろ、背景に強力なデータベース・エンジンを備えたWeb-DBという範疇から観た方が、その成り立ちがわかりやすい。

 つまり一見、現状カレントな記事発信のために作られたようなblogだが、これは明確なデータベースシステムであり、むしろ過去遡及型記録管理システムと見た方がよい場合もある。

 もちろん開発者達も当初は、他のいろいろな人々と情報コミュニティーを形成するために造った物らしく、さらに特殊な簡易日記アプリケーションの意図が強く、原理的には、背景になんらDBMSなどを備えなくても運用できるようになっている。

 このために、各社が提供する様々なblogや、あるいは自製のblogには、そのままでは過去遡及的利用に耐えないものもある。だが、ある意味で一般には使いがたいDBMSを背景に持った高機能のサービスが、これまで手作りだったホームページ作成よりも、格段に利用しやすくなったという事実は、見逃せない。

 本論は、現行blogを利用して、カレントタイプblogを、過去遡及型記録管理システムとして活用するための、過去二年近く行ってきた実験を通して得た、いくつかの工夫をまとめたものである。

1.(Web)logの特徴

 これまでに生まれてきたソフトウェアは多数あるが、blogサービスはいくつかの特異な性格をもっていた。そして、それがなんら難解な術語や操作を必要とすることなく、数回の閲覧や記事投稿で自然に使えるようになったのは驚きだった。非常に高い機能性をもちながら、どこにこれまでのソフトウェアとは異なる所があるのか、その疑問があった。しばらくして充分にblog記事扱いになれたころ、2004年の夏にそれをまとめてみた。

(1)時間管理

 記事の一々、コメントの一々に、日時が分単位まで克明に記録される。これは時系列、時間の流れに従う人間の習性によくあう。また、一般にHP(旧来のHTMLによるホームページ)記事は、記録の必須事項である日時が曖昧だが、blogは発信者が意図しなくても、自動的に付与される。 日記だから、当たり前と思う前に、記録の発生時点を自動管理する考えは方は非常に大切である。
(2)記事間の関係維持(構造明示)
 日記は時系列であると同時に、断片的とも言える。人が複雑な証左である。人は、連続して考えるだけでなく、連想的に時間をとばしてものを考える。この断片性、不連続性、混沌とした人の発想を、しっかり見直して明確な構造を持たせる仕組みが、blogには備わっている。
 @記事アドレス
 記事には、それが記録されたとき、不変に近い固定アドレスが付与される。このことで永続的に出所が同定される。これは多くの記事をまとめていく際、必須の条件である。HPはそのあたりが曖昧だった。
 @カテゴリの設定
 カテゴリとは、一般的な日本語では「範疇」となるが、分かりやすく書けば「記事を分類することができる」と言って良いだろう。最初は適当なカテゴリを設けて記事に付けていき、記事がまとまってきたなら、カテゴリを詳細化し再定義することで、似通った、関連した記事をまとめて扱えるようになる。
 @リンクとトラックバック
 リンクはHPを触ったことのある人、ないし作ったことのある人なら、よく理解できる。トラックバックはリンクの逆である。だから前者リンクは「正リンク」、後者トラックバックは「逆リンク」といえる。ただ、後者は慣れるまでは少し分かりにくい。
(3)記事とコメントとコメント返し
 コメントがすぐにできるのは、blogの良いところである。掲示板と異なるのは、常に記事という「幹」があって、そこに枝葉を付ける仕組みにある。幹と枝葉を明確に分離し、記録するところに、blogの記録格納の堅牢さが現れている。掲示板は、形式的にすべての投稿がフラットである(技術的にツリー状に整理するものも多いが)。だが、blogは幹(記事)と枝葉(コメント)とがはっきり区分されている。
 この幹(記事)に対するコメントとコメント返しが、記事を中心にして相互交信されるのは、実は革命的なことである。すなわち、発信者と受信者とが、一つの確実に記録された記事(テーマ)に関して、双方向で対話を行っていることになる。これまでの新聞やTVと比較すればその違いがはっきり分かる。
(参照記事(1)を一部修正し掲載した)

2.遡及型blogの構築


 本論で述べる過去遡及型とは、記事の蓄積をどれほど有効に使えるようにするのかという考え方である。現代のRDBMSならばSQL文によって、自由に検索し求める記録を得ることができる。しかし一般の[項目名と、文字列と論理式]による「検索」だけでは、過去の記事をわかりやすく探すことはできない。


 以下では、blogが持っている基本的な機能を工夫することによって、本格的な情報検索なしで、過去の記事を容易に得るための方法である。


(1)基本的な手法

 多くのblogサービスが提供するサービスとして、サイドバー(画面の左右)に、カレンダー(日単位)、特定期間バックナンバー(月、週単位)リストを掲載する機能がある。 「最近の記事」リストをサイドバーに表示することもできる。これらは投稿時期によって過去記事を検索するものである。


 また特定の用語や記号を一つ一つの記事に付与し記事をグルーピングする「カテゴリー」機能がある。これは、サイドバーにカテゴリー・リストを表示することで、必要な過去記事をまとめて検索することができる。 


 またblogによっては、簡便な文字列・検索機能を持つものもある。


 これら基本的な諸機能はいずれも、サイドバーに表示することができる。しかしそれなりに役に立つが、記事が増加してくると限界が見える。


(2)リンク・リストと目次記事

 リンク・リストは一般に他者他blogへのリンクが主な使い方である。しかし、これを自己参照的に、自己特定記事にリンクすることで、blogの機能を高めることになる。この場合、その自己特定記事自身に目次機能をもたせることで、より効果がます。


 事例MuBlog では左サイドバーの先頭に「主な記事」という見出しがある。これはリンク名に簡易NDC分類番号を付与し、関係記事をまとめたものである。


  000-2004 総合
    気に入りの記事。
  000-2005 総合
    お気に入りの記事、2005年分。
  069 博物館
    気に入った博物館、行った所も未踏地も。
  210 新撰組
    京都伏見の案内と、2004NHK大河ドラマ「新選組!」。
  629 桜狩り
    京都を中心にした観桜記です。
  999 MuBlog階層表示
    MuBlog「カテゴリー」の階層表示。
  MuBlog目次 :記事掲載順
    2004.03.07~

---↓上記の「000-2004 総合」にリンクしている目次記事 ---
  目次記事:MuBlogの主な記事
◎ 私の京都:四条・三条・河原町篇

2004/12/03  Muがある日、京都の町を散歩して、行きつけの喫茶店や蕎麦屋を紹介しました。数えてみると僅かに1平方キロの場所でしたが、私の青年期から現在までがぎっしりつまっていました。

◎ パソコン自作:「葛野2004P黒」の製作
2004/06/23  毎年一台パソコンを自作しています。この記事は2004年製作のもので、「葛野2004P黒」と名付けました。都合で現在は木幡研の主力マシンになっています。全部で7つの記事から出来ています。

◎ 六本木のワインガーデン:ミスター・スタンプス・ワインガーデン
2004/10/23  Muが東京に行ったとき、風雪梅安一家(梅翁、Joさん)に連れられて行った六本木のレストランです。お店というのも、友人や図書や映画と同じで、単にお金があっても、時間があっても、佳いものに出逢えるわけではありません。全部で2つの記事から出来ています。

 この事例では、左サイドバーにある「主な記事」のうち「000-2004 総合」を指定することで、MuBlogとしてまとめておきたい記事の目次(一覧リスト)が表示される。すなわち、サイドバー上に恒常的にリンク・リストを分類設定し、その指示先にそれぞれの目次記事をもうけ、目次記事の中で各固有の記事にリンクを設定する。
 blogの本編記事相互間の「関係性」を、別記事に目次として格納するわけである。このことで、過去蓄積記事への一定の恒常的探索を可能にする。

(3)カテゴリーの階層表示
 カテゴリーをサイドバーに表示することは可能だが、多くのblogではカテゴリー(の用語)の配列について制限が大きい。カテゴリーの相互関係を樹状に表示するサービスもあるが、一般的ではない。ここでは、カテゴリーの階層関係や注記をまとめて別記事とし、それへのリンク・リストをサイドバーに表示している。

 読書情報


  図書書誌情報
    読書の祖先←上位概念書誌
    読書の素←図書情報
    読書余香←Mu書評
  特別選定図書
    Mu現代古典←銘記された読書
    現代四物語←昭和の鎮魂

(4)記事目録
 MuBlog では、後述するが、全文検索、項目検索のために全データを一定時期毎にココログからダウンロードし、MuDB2005システムとして情報検索に使っている。この時、同時に全記事リストを出力し、新たな記事として編集し登録している。現在は登録順だけを使っているが、データベースのレポート機能によって、様々な索引を作ることも可能である。
  ~
  414 佐野藤右衛門邸の桜平成十七年→MuBlog
  415 祇園円山公園の夕桜平成十七年→MuBlog
  416 NHK義経(14)源三位頼政の宇治平等院→MuBlog
  417 天神川の桜海・平成十七年→MuBlog
  418 金魚と住む、平成17年の春→MuBlog
  ~

 以上の(2)~(4)は、いずれも別記事として詳細な目次や階層関係、リスト形式を作り、その記事自体へのアクセスは、サイドバーのリンク・リスト機能を使ったものである。簡単な工夫ではあるが、blogに従来の自由なホームページ仕様を組み込むことで、遡及記録の探索に役立っている。

継承[↓[その(2)参照]

|

« blogの情報処理ツールとしての可能性(2)/谷口敏夫 | トップページ | blogの情報処理ツールとしての可能性(0)目次/谷口敏夫 »

Blogメモ」カテゴリの記事

情報図書館学」カテゴリの記事

コメント

「おもろない、眠い」と、この日、発表中にネットが繋がっていたので、コメントを入れた。やはり、こういう気むずかしい話は、眠くなる。

記録と記録との関係性を定義していくのは難しいことである。
難しいことがわかっているのに、連結させるところに、眠くなるところがある。

かといって、自動結合は信じていない。結合の要素は多岐にわたり、しかも時間帯で変化する。その一瞬を切り取って連結するのだから、その連結という行為があらたな「記録」をうみだしたことになる。

まことに、世界を解釈するということは、難しい(笑)

投稿: Mu | 2005年12月 9日 (金) 15時55分

 この記事、大変興味深く読ませていただいていたのですが。

 ブログの特徴とか、リンクやトラックバックとか、わかりやすい解説で、とてもためになっています。

 リンクとトラックバックの使い分けに悩んでいます。記事の自己参照をするのなら、リンクにしたほうがいいのか、トラックバックをして、構造的に記事同士を結びつければいいのか、後々になって見るとき、どちらがいいのかよくわかりません。

 また、記事がたまってくると、見やすく整理するために、(目次)作りが大切だと「MuBlog」で学ばさせていただきました。
 「ふうてん老人日記」の過去記事は、シンプルですが、とても見やすいです。それ自体が目次になっているんですよね。

 (おもろない)とおっしゃらず、興味を持って続きを楽しみにしている人間もおりますので、がんばってください♪

投稿: wd | 2005年12月 9日 (金) 16時50分

wdさん、2005年12月 9日 午後 04時50分
さて、
http://www.koka.ac.jp/taniguti96M/0/40/TamaiM/TamaiM.html
↑これですね。これは期せずして単純な目次形式がどれほど役にたつか、自分でも気がついておりました。要するに、手を加えない要素情報(タイトル)だけの時系列配列は、この時代の「ふうてん」さんの記事全貌をあらわしているわけですよね。一覧性というのは、ものすごく大きな意味を持つと思います。

図書館の目録ターミナルの小さな世界は、綺麗に整理された書庫書棚の代わりを、なかなか果たせません。

さて、さて。
自己参照トラックバックは、その極限の意味をわかりやすく示すために用いている方法です。
指し示す主体記事と、指し示される客体記事とが、相互に立場を変えられるものなら、主体←→客体ならば、すなわち、両記録に対して施術者が同等の権限をもつならば、お互いに通常リンクを張り合いしても、結果は同値ですよ。

現状でのMu流決定打は、相互にトラックバックを付けることですね。というのは、トラックバック機能には、記事の一部が組み込まれて表示されますね。あれは、説明文付きリンクの機能を自動的にはたしています。

(おもろない)←口癖でもあります。真意は、ここまで結合機能を持たせるなら、属性リンク、つまりリンクする相手とどういう関係でリンクするのかを付加できる機能ですね。それが欲しいところです。ないから、「おもろない」です。
以上

投稿: Mu | 2005年12月 9日 (金) 20時43分

この記事へのコメントは終了しました。

トラックバック


この記事へのトラックバック一覧です: blogの情報処理ツールとしての可能性(1)/谷口敏夫:

« blogの情報処理ツールとしての可能性(2)/谷口敏夫 | トップページ | blogの情報処理ツールとしての可能性(0)目次/谷口敏夫 »