重要な部分が大きくなるように作ってある

HTML::FeaturedImage - URLに含まれる画像のうち、重要そうなものを取り出すためのPerlモジュール - fubaはてなのひとつまえのHTML::Feature::Engine::TsubuanLike - fubaはてなを読んでzuzara : ブログの記事本文を抽出するスクリプトをつくってみたアルゴリズムがどうだったかなーと読み返して。

美しくないですが、HTMLだけでなくレンダリングしたときにどれくらいの面積を占めるかという情報を利用すると精度が上がると思います。たいていは一番でかい面積を占めてるのがメインのコンテンツになっているとおもわれます。ただ、その親要素は当然メインの部分よりも大きい面積を持っているのでそのへんはちょっと細工が必要ですが、判断材料としては有用です。本文でない部分が面積が一番大きくて目立っているのはあんまりないと予想できるので、もうあきらめてFirefox上で全部やるのがいい気もするなーというのを、ここさいきん思います。SIMILE - ゼロメムはてな支店のCrowbarがXULRunnerでhttpサーバ動かしてそこで全部やるのを見て、やっぱそれでいいのかもとおもいました。

もちろん PC MAGAZINE みたいなのもあって、CNETとかCODEZINE(記憶ほどひどくはなかった)とかもうちょっとがんばればこんなかんじなので、視覚情報だけに頼ることはできませんが、もともと人間が目で見ることを前提にデザインされているHTMLからデータを抜き出すのに視覚的なサイズがどれくらいになっているかを使えるのは大きな助けになると感じました。でもだいたい視覚的サイズは文字数に比例しているので(比例していないとそもそもディスプレイで文字が読めない。本文はそうでないところよりもフォントサイズが小さいのが期待できますが、それでどれだけ変わるかはわかりません)


こういうときにAutoPagerizeのSITEINFOにそのSITEINFOを適用可能なURLがひとつサンプルとして入っていると、pageElementを取得してサイズ計算して、pageElementがページ全体の何パーセントかになっているかを数字で出せて、このアプローチがどれくらい有効なのか検証できたり(そういう教師付き学習の正解データとして使えますよというはなしをmoz24のときにされていた気がする)、デザインが変わったりして記述されているXPathがマッチしなくなっていないかとか機械的にチェックできる(CPANのビルドテストみたいに)ので地味に追加したりしたいです。