APMLから、興味の更新とその可搬性を考える (2)

　前回の記事に早速言及頂いたので考えが揮発しないうちに続きを書いておきたい。

APMLによって、自分に興味のある情報が勝手に届く仕組みが実現されるわけだけれど、その便利さを享受しながらも、自分の世界を固定化するのではなくて、どんどん広げて行けるような仕掛けも欲しい。

APMLに考える個人の符号化という話 - WebGrove

- with GroveLog

　自分の興味が攪拌/更新され、世界が広がるサービスというのは間違いなく魅力的だが、そういった経験はある種のアクシデンタルな性格を帯びるはずだ。ゆえに、そういった経験を“期待してサービスを利用する”時点でそのアクシデント性は減耗してしまうという問題を孕んでいる。

　このような問題に対して『計算不可能性を設計する』において宮台真司は、

ノイズやアクシデントを許容するアーキテクチャを設計する時、「期待通りのハプニングという非ハプニング」の逆説をどう脱パラドクスするか （P212）

と提起した上で、アーキテクト（設計者）の設計に際する姿勢に関し、

アクシデントが続くべきだとしても、同じアクシデントの反復だと見做されないように、絶えずアーキテクチャを更新し、新たな期待の地平をつくり、先回りして期待を破るべきです。 （P213）

と述べている。
　
　アクシデント以前の「個人の興味にマッチする」という段階においても（今回の文脈に限定すれば）今だ極めて単純なアルゴリズムと仕組みしか持たないAmazonやGoogleがこのトピックの先行事例であることから、マッチングとは別に「新たな期待の地平をつくる」ことを同時にカヴァーする（ウェブ）サービスというのは当面出てこないと考えてよさそうだが、結局必ず直面する問題ではある。

　APMLの描く方向性として、サービス横断的に興味関心情報を送受信していくことで、プッシュされる可能性のある情報もジャンル横断的に増加し、それに伴い上で言う「期待通りの」アクシデント性については早晩拡張することができるだろう。その次のフェーズとして、絶えず肯定的な意味で期待を裏切り続ける設計に耐えるAPML（かその代替）自身のアジャイルな更新（再設計）が見えてくる。

　つまり、（これは完全に感覚的な意見だが）おそらくアーキテクチャ自身がその設計を設計し続けることでユーザーに対してアクシデントを提供する（といった設計をアーキテクトが行う）ことになっていくだろう。これは例えばAI（人工知能）分野にヒントがある気が直感的にするのでまた追って考えていきたい。

APMLから、興味の更新とその可搬性を考える

　以前フィードアグリゲーターをBloglinesからlivedoorReader(LDR)へスイッチしたのは、各フィードごとに重み付けができる「レート」機能と、ショートカットキーの充実がポイントだったし、後発ながらそういった評価（+軽快な挙動）によって乗り換えユーザーを多く獲得していった経緯があったと記憶している。

　APMLはLDRの「レート」機能のような実装を汎用的に定義し、ユーザーが明示的に自分の興味をプログラムに伝える一方で、アプリケーションレベルで自動的かつ継続的に個人の興味の更新（変な言い方だが）していくことができるようになる。
　そしてそれに応じた情報の提示をしていく可能性をひらく（XMLSchemaによるAPMLの構造定義では自動収集されるimplicitデータとユーザー任意のexplictデータを区別している）。


　今現在LDRのレートはフィード登録時、あるいは登録編集画面で任意に設定するexplicitな仕組みになっているが、フィード参照回数、記事参照回数、記事リンク先訪問回数などは履歴として取得できるので、今の実装でもLDRローカルで自動レイティング、及び関連フィードや記事の提示が可能だ。
　これはAmazonの「おすすめの商品」機能と「この商品を買った人はこんな商品も買っています」機能に準えて考えることもできるだろう。implicitな興味（それが本質的な興味かどうかはわからないが）を自覚させられる局面はAmazonやGoogleによって既に我々は多数経験している。

　APMLによって蓄積＆書き出される個人の興味情報は、フィードのインポート/エクスポートの際使われるOPMLファイルのようにXMLベースのAPMLファイルとして持ち出すことができる。


　また、「興味の鮮度」を考えたとき、アプリケーション層では正の興味だけでなく負の興味も捕捉しながら、ユーザーの興味関心を快いレベルで攪拌するような巧妙な情報提示を行っていくようになるだろう。これについては今後もう少し展開したい。