Atom Publishing Protocol の用途と将来

2006 年のネット開発に向けて覚えるべき技術 のコメントで、Atom PP が何に嬉しい技術なのかいまいち掴めていないため、自信のない書き込みをしたところ、kwmr さんから Yoshimatsu さんの面白いブログのエントリを紹介いただいた。

バックエンド側からの情報注入の口として Atom Publishing Protocol は重要になるだろう、という話。

個々の企業から情報を提供させて、それらをまとめて提供する「場」を作ることで生計を立てているネットサービスというのがある。Yoshimatsu さんが言及されている Amazon はもちろんそうだし、Kakaku.com , ぐるなび, Home’s なんかもそう、 Vector とかも提供者に個人が多いが同様ではないか。

これらの情報集積型ネットサービスは、当初は運営者が手作業で情報を入力したり営業をかけていたものが、情報量の増加とそれによるユーザ数の増加に伴って力関係が逆転し、今では情報提供側がお願いして/料金を払ってでも載せてもらうという形になってきている。これらのサービスで検索されないということは、ネット経由で探しているユーザ達にとっては世に存在しないも同様だからである。

当然、これらのサービス運営者達が情報を提供させるためのフォーマットやインタフェースを整備しているのは間違いないだろう。PC ショップはともかく、町の不動産屋やレストランのオーナーに CSV だの XML だのを直接書かせられるはずもない。実際にどうやっているのか知らないが、整備されたデータ更新専用のウェブサイトなり独自の PC クライアントなりが提供されているはず。

では、そういった情報注入側のインタフェースに関して、Atom PP 対応が進むか、と聞かれると、サービス側にあまりメリットが無いのではないか。新しく作る際に、都合のよいライブラリが揃ってるから、という理由で Atom PP を採択することはあるだろうけど、もし既存の独自プロトコルを使っているなら、それを Atom PP に置き換える意味までは無いように思う。

サービス提供側にしてみれば、同じデータを競合のところに簡単に持っていかれては困るわけで、たとえば Kakaku.com に価格情報を登録するインタフェースが Atom PP としてオープンになっていたら、Kakaku.com の競合サイトは「Kakaku.com と ○○ と △△ に一括登録できるクライアントツール」みたいなのをより簡単に作って配れてしまうのでは。ま、もちろん、クローズトなプロトコルであっても同様のツールは作れるだろうので、それだけで参入障壁とはいえなくても。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

5 thoughts on “Atom Publishing Protocol の用途と将来”

  1. データをオープンにすることで何を得られるの?というところの問題とオープンにするときのインタフェースの問題。オープンにするのであれば、出来るだけ統一化(あるいは繋がる先の多い)されたインタフェースにしなければ意味が薄くなってしまう...そこで何らかの統一インタフェースが作られる所以があると感じます。
    (何をオープンにするかも重要なポイントですが)
    で、秋本さんがご指摘の通り「どちらの実装が、既存のweb開発者にとっては使いやすいのか?」というところで決まってくると思います。RESTベースの開発者フレンドリーなインタフェースというところが、AtomPPの可能性を高めているところかと...。
    http://www.goodpic.com/mt/archives/000185.html
    で、私はそういうところは、まだまだ不勉強で…鋭い指摘にはひとたまりもないのですけれども :)

  2. まあ、データ注入の口を何で作ったところで、1位企業が強大であれば、2位3位企業はそれにあわせてくるか、データ移行ツール的なものを出してくるように思います。ですので、Atom PP を避けることが本当に意味があると思っているわけではありません。

    Unix のソケットのように、ウェブサイトへのデータ提供は Atom PP ライブラリを書くのが普通だ、というような状況になるのであれば、プログラマとしては楽になりますね。

  3. 暴論ですが…

    閲覧系が ftp/txt -> http/html -> http/rss と進化してきたように、出版系も ftp -> webdav -> atompp と進化していく、というレベルの話のような気もします。
    atompp の市場規模というのは、RSS に対する http:webdav の比に比例するんじゃないでしょうか。

  4. こんにちは。

    「サービス側にあまりメリットが無いのではないか」の段落部分に反応させていただきますと、

    現状、街の不動産屋には、(例えばアットホーム)の営業の方が足で回って物件情報を集めてたりします。あとFAXとか。専用クライアントを出しているのはアドパークのみ(普通のHTTP POSTしてるだけ)。

    アンマリ知られてないかも知れませんが、それが不動産業界の実態だったりします。

    もちろん、Webベースでも入力出来ます。しかし沢山あって更新頻度も高く、あまりにも面倒なので、結局大手一社(アットホームとか)程度だけに入力し、結果として寡占状態、価格上昇という、最悪のサイクルにあります。

    さらに言うと、法令で定められているように、レインズという流通ネットワークにも、必ず物件情報を流さなければならないのですが、これが化石時代の代物で、もちろんまともなプロトコルなんて存在しません。

    ですから本来は、情報の持ち主である、業界団体側がなんとかするべきなんです。

    まぁ業界団体が動きだすには、あと10年ぐらいかかると思うけど。

  5. feeds さん、情報ありがとうございます。

    そのあたりはてっきり IT 化されているのかと思ってましたが、まだ FAX が幅を効かせてるんですか。ということは、FAX からオンラインへデータを移すキーパンチャーのような仕事もまだ存在するわけですね。

    レインズは、こないだ家を借りたばかりなので、目の前で検索する状況をつぶさに眺めてました。独自の PC クライアントでしたね。使いにくそうだなあ、とは思いましたが。

    情報の持ち主が動かないとすれば、もう一つ、勝手に各社のウェブ画面を統合したインタフェースを与えるようなサービスもありうるように思いますがいかがでしょう?

    たとえば、古くは検索エンジン一括登録の一発太郎のようなものだったり、
    http://ippatsu.net/TARO/

    各社のオンラインバンクについて Web アプリケーションを解析して無理やり統合している Yahoo! の MoneyLook であったり、
    http://biz.yahoo.co.jp/accountmanager/moneylook/web/

    もし、各社に登録するのがたいへん、というところで止まっているのであれば、この手のツールが登場してもよさそうに思います。

    # もっとも、その場合に業界上位のサービスは、この手のサービスを遮断してくる危険が大きいですが。

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.