_ キーワードでの関連づけ

GETしてstriptagしてChasenで形態素解析して名詞らしき単語だけを抽出し、それをベースに解析すれば、日記本文中に使われているキーワードを使った関係図の作成も、なんとかなりそうな気がしてきた。

ただ、よく使われる一般名詞と固有名詞をどうやって差別化するかが難しい。単純に出現した単語でリンクを張っていくのではなく、その単語のweb全体での出現頻度の増減を監視して、「増減が激しかったキーワード＝話題のキーワード」と捉えることで、なんとかなるかな？　あと、出現数があまりにも多すぎる単語は、一般名詞として解析対象から捨てるようにしたり。

というのは、一つの単語（名詞）＝キーワードという単純な場合に有効そうだけど、実際のことを考えると、単語の組み合わせという形で表現される話題が非常に多そうだ。そうなると、あるページで出現した単語の組み合わせがほかのページでも使われているか、という多対多の組み合わせ数をカウントする処理が必要になって、マシンパワーを激しく食いそうな気が。自動で全パターンをカウントして解析するのはつらいかな。

_ 書影リンク拡張

Amazon.co.jpのアソシエイトプログラムには、書影付きリンクの方法が用意されていることに今さらながらに気がついたので、hnsを強引に拡張して書影付きリンクに対応させてみた。相変わらずhns（というか、PerlっぽいPerlプログラム）がよくわかっていないので、実装方法がかなり強引かもしれない。具体的にどうやったのかというと、

• theme.phの「package HNS::Hnf::Command::IMG」部に、「$TemplateWithISBN=qw(<a href="http://www.amazon.co.jp/exec/obidos/ASIN/%2/my-associate-id"><img %align src="http://images.amazon.com/images/P/%2.09.MZZZZZZZ.jpg" alt="%content" border="0">）」というのを追加
• Command.pmの「package HNS::Hnf::Command::IMG」のTemplateに「use vars qw($TemplateNosize $TemplateWithsize $TemplateWithISBN);」を追加。
• Command.pmの「package HNS::Hnf::Command::IMG」のsub AsHTMLで、Templateを切り変えているif文の冒頭に

  if ($src =~ /^isbn:/i ){
      $Template = $TemplateWithISBN;
      $src=~s/^isbn://i;
      $self->{attr}->[2]=$src;
  }
  elsif ……
  

  を追加

って感じ。これで「IMG n ISBN:4344402146」なんてやると、

な感じになる。ここはほとんど画像がないデザイン的に寂しいページだし、せっかくだから読書感想の項目にだけでも書影リンクを張って、ちょっと華やかにしてみようかな。

_ TrackBackの文字コード from 今日のなんでやねん (13:49)

• TrackBackの文字コード - http://kitaj.no-ip.com/tdiary/20030425.html#p01

文字コード判別は3のcharset要素（＋ヘッダのcharset）だけ対応しておけばいいと思いますよ。1、2はTrackBackの（今後の）仕様とバッティングしないように、わざと一般的ではない表現を使っているだけなんで。

今のところcharset要素利用者が増えつつあるみたいですし、それが本家仕様に取り込まれる可能性を高めるためにも、中途半端な1、2は非対応にしておいた方がいい気がします。

ところでやっぱり、既存のいわゆる日記システム系にTrackBack送信処理をきれいに（使いやすく）取り込むのは結構難しいですよね……。HNSにも受信＆表示だけならば組み込めるんだけど。

とか考え始めると、TrackBack的な機能を持つ新しい仕様を考えることにまだ未練が残る。

個人的には、tDiaryにTrackBack対応してもらいたいと思いつつも、TrackBack的な機能を利用するためのもっと良くできた新しい技術を作ってもらいたいとも思っていたりもした。自分で作ろうかとも思ったけれども、こういうのはある程度のユーザーベースがないと面白くないし。

TrackBackの仕様のいまいちだと思われる部分は以下。これを解消しつつTrackBackと同等以上の機能を持てればいい。

1. 記事に対応するメタ情報（RDF）の表現が美しくない
2. 世の中のURL表現というものにはかなり揺らぎがある（大文字小文字、インデックスファイルの省略、QueryStringやPATH_INFOなどの引数違い）のに、それを意識せずにURLをキー扱いしている
   1. 1HTMLファイル中に複数の記事（RDF）が混在する状態で、その中の1記事のRDFを抜き出すためには、記事URL（アンカーリンク）をキーで検索するしかない。けれども、URLはキーとしては信頼できない。URLは、「URL→ドキュメント」方向では1：1（これも動的システムでは怪しいけど）だが、「ドキュメント→URL」では1：nなのに。
   2. URLをキーとして使うのではなく、コンテンツ管理システムID（こちらはトップページへのURLをベースにしてもいいかもしれない）＋記事ID（これはURLの一部などから、揺らぎがない要素を抜き出して使うなどで対応）をキーとして利用し、それに対応するURLをlink要素で表現するとか。
3. TrackBackにはいろいろな機能があるが、それぞれの仕様に統一感がない（これはまあ好みの問題だけど）
   1. XML指向なのかREST指向なのか
4. RSSとの連携が中途半端
   1. RSSのitemが持つTrackBack Ping URLと、HTML中に埋め込まれたRDFのTrackBack Ping URLみたいに、連携せずに重複している要素が気持ち悪い。
   2. RDFから記事IDを抜き出して（あるいはURLから記事IDを抜き出すための仕組みを用意して）、RSS取得インターフェースにそのitemのメタ情報を問い合わせて、RSS経由で正規化されたTrackBack Ping URLを受け取ったりすると仕様的にはきれいなんだけど
      1. HTTPアクセス回数が増えるデメリットと1回のHTTPアクセスで受け取るデータ量が減る（解析コストも下がる）メリットのバーターか

なんか書き始めると止まらない＆細かい仕様を考え始めちゃうな。ここ最近はそんなことをやっている時間がないので、このあたりで思考停止。

_ BasicReaderとライセンス (13:49)

BasicReaderとかの続き。

BasicReaderは、地道に隙間で作りつつあるんだけど、GPLにする気力は減退中。オープンソースにする意味があると俺が感じるものってのは、ある程度完成（最終形として作成終了）するあてがあるものか、あるいは自分ではそれ以降開発を続ける気がなくなったものか、どちらかなんだよな。

BasicReaderとかWikiLikeみたいなソフトに関しては、一般的な意味での完成はする（実用レベルには達する）けれども、自分的にはその後も延々と根本的な仕様から見直しつつ開発を継続しようと思っているんで、オープンソースにするデメリットが大きすぎる（オープンにしたソースの開発と、自分の趣味での開発が全然一致せず、それを一致させようとするのはコストが高い）。

やっぱり個人的には、基本的にバイナリフリー＆ソースはサンプルコード扱い（ソースの二次利用・配布権はあいまい＆厳密にはつど問い合わせ）って方が性に合っているのかな。厳密にオープンソース系のライセンスを適用しようとすると、どうも違和感がぬぐいきれない。

_ 2004F1サンマリノGP (13:51)

予選

PC修理だしのためのバックアップ作業をしながらみていたんで、何も書けなかったよ。ともかくバトン＆BARホンダ初ポールポジションおめでとう。

決勝

すばらしいBARの2台のスタート。

モントーヤもうピットストップですか。よっぽど軽かったのかな。あら、その後もみんなどんどん入ってくるのね。今回は最初のピットまでがみんな早めなのか。

うーん、琢磨はピットストップいまいちだったか。バトンは悪くなかったけれども、ミハエルに作戦負けって感じだな。ミハエルこのままあとは逃げて終わりですか。もう一波乱ないかなー。

今川井ちゃん、「イルモアのトップがこうそうされた」とか言っただろう。「更迭」が読めなかったな、貴様。

あら、琢磨エンジンブローですか。なんかいろんな意味でバトンとの差が目立つなー。

うーん、結局ミハエルの楽勝レースですか。バトンも悪くなかったけど、ミハエルの方が役者が上だってことかなー。あー、それにしても久しぶりのSRX7のキーボードは打ちにくいなー。

_ tDiaryのアンカーリンク時にドキュメントタイトルを表示する その5 (04:14)

決定版とか言っておきながら、まだいじっている。セクションアンカーの文字列長を、ちゃんと@confから持ってくるようにした。これで曖昧な部分がなくなったんじゃないでしょうか。

23,29d22
<
<         if (highlightElem.tagName == 'H3') {
<           var diary_title = "#{@conf.html_title.gsub(/"/, '\\"')} (#{@date.strftime('%Y-%m-%d')})";
<           var sanchor_length = #{@conf.section_anchor.gsub(/<[^>]+?>/, '').length};
<           var section_title = highlightElem.innerHTML.replace(/<[^>]+?>/g, '').substr(sanchor_length);
<           document.title = section_title + ' - ' + diary_title;
<         }

_ ムスコにケジラミ

ちょっと前から保育園で流行っていたんだけど、ついにうちのムスコにも来た。ちなみに髪の毛ね。ちっちゃい白いフケみたいなのがついているんだけど、髪の毛にしがみついているんで、軽くこすっても取れない（爪でこすれば取れる）。一応病院に行ってきたんだけど、ケジラミだということを顕微鏡で確認した上で、単にそれ用のシャンプー（というかシャンプーに混ぜた薬？）を紹介されただけだった。シャンプーは保険適用外で小さい割にちょっとお高め。しばらくそれを使って頭を洗いつつ、昼寝用のシーツとパジャマは毎日持って帰って洗えば、それでいいらしい。まあこんなので保育園を休めといわれたら困るよね。ただまあそのせいでなかなか（保育園から）根絶されないんだろうけど。

_ obsoleteフラグ

blogとかの古い記事に、簡単にobsoleteフラグを付ける機能があるといいね。消しはしないけど、すでに現状に即していない記事ですよ、というのをわかりやすくするために。obsoleteフラグがついた記事は、古文書風にぼろぼろに表示される（CSSがあたる）といいのかな。

第三者からの評価として行う場合は、ソーシャルブックマークなんかでobsoleteタグを付けておいて、そのタグの数で識別する、なんてのもいいかもね。

あと、記事の掲載日時を表示するときには、単に「○○年×月△日」とだけ書くんじゃなくて、ある程度古くなったら自動的に「○○年×月△日（掲載から□年経過）」とか、その記事が古いことをわかりやすく表示するといいかもね。

っつーか、自分のところもそうだし何か調べていてググった場合もそうだけど、古い技術系の記事のobsolete度合いを簡単に識別する手段があると便利だよね。obsolete度評価専門のソーシャルブックマークとか誰かつくんね？