第1回メディア開発委員会2005/08/27ドキュメント

地域: 岐阜
(登録日: 2005/09/15 更新日: 2017/07/18)

前川道博／プロジェクト概要・PopCorn/PushCorn

記録日: 2005/08/27

●PopCorn技術仕様
http://www.mmdb.net/popcorn/
　このうちの「マニュアル」です。

●PushCorn概要
http://www.mmdb.net/pushcorn/
　

小林隆生／ごとっとやっちろ・open-gorotto

記録日: 2005/08/27

●ごろっとやっちろ
http://www.gorotto.com/
　open-gorottoの前身となる実稼動システム

●open-gorotto（オープンソース）
http://og.akadigi.jp/
　

依田平／不定形文書の検索方法

記録日: 2005/08/27

●神戸大学図書館検索システム
http://www.lib.kobe-u.ac.jp/
不定形文書の部分検索を適用した検索システム
　

討議内容（採録テキスト）＝作成途中

（途中から）

＜ＳＮＳのデータ連携＞

●小林
RSSはブログ以外にも使える　更新情報なので、行政情報持ってくるとか。とりあえずブログとの連携がうまく行っている。

●河井
greeは簡単に飛ばしているだけ。外に出て行く／外から来るのに寛容
mixiはないのが課題　RSSの発想がない
●鈴木
目指しているビジネスモデルが違う
●河井
greeは自分を核にしてつなげる。
mixiは囲い込んで一生を終わらせよう。その人の嗜好を掴んで、という発想。
SNSでもけっこう違う。
●鈴木
RSSの取り扱いでソフトの性格がわかる。
●小林
RSSが普及しない理由にXMLの解釈が煩雑というのがある。
うちではそれを解消したく簡単にXMLを扱いたくて簡単XMLパーサを作っている
文章を持ってくるときにDONを通すけど、通した後は配列に入れちゃう。
どこの項目見てもデータが入っている形。
●河井
バージョンも1.0も2.0もあって。
●小林
最近はFONとかある。中味みるとダブリンコアとか入っていて結構煩雑。
自由度が高いので解釈のやりかたがいろいろあって、それによって解析できたりできなかったり。セマンティックウェブのよしあしがある
なるべく簡単に扱わないと普及しないので、RSSだけでなく普通のXMLファイルも読めるようにしている
この仕掛けを使ってSNSとSNSをつなぐ仕掛けを作ろうとしている。
昨日後半にさらっと流した資料

リソースの分散を重きにおいてSNSをつなげようかと考えている
地域情報を自分のところにまとめておく。ブログとかはRSSで集約しておきましょう。
地域の情報が固まった状態でつながっていくんで、非常に見やすいインターネットの地域社会になるんではないかというイメージ
●鈴木
地域情報って一つのポータルにまとめられないんだよね
こっちは観光情報、こっちは経済情報とか分散しがち
だから一つにまとめてみたいんだけどまとめきれていない
●小林
なぜまとめきれないかと言うと、いろいろな表現があるから統合的に扱える仕掛けがなかった
行政の予算執行が、各々に出すから、全体に出すわけでないから、行政の縦割りでさまざまなサイトを複数立ち上げる格好になる
●前川
RSSで情報をパブリッシングしていけばいいですか？
●小林
RSSでとりあえず集めるということなんですよね。
自分の地域情報を外に出すもあるが、システムがダウンした時の対策。
例えば地震とかで自分のところのSNSが消えた。その時に他の地域のが補完してくれる仕掛けを用意したい
そのためにはSNSの情報を他に流す仕掛けがいるので、さっきの話のと似ている。
ネットワークの作り方。（SNSがいくつかあって、新たなSNSが）一個入ってきました。hashのIDをそれぞれのSNSに配るというやり方。
それぞれのSNSには物理的な緯度経度がある。サーバの緯度経度も一緒に送る。
●前川
物理的な緯度経度とは？　北緯？度のような…
●小林
そうです。
●鈴木
面白いね。普通インターネットは場所的な立地は考えない。
●前川
普通はネットワーク上のアドレス空間ですね。
●小林
なぜ緯度経度が必要かというと、自分が地域の情報を流してバックアップしてもらうのは、近隣だよという認識のため
●河井
サーバは引っ越したらそこは関係ないよ…と。
●小林
例えば自分の市がサイトがダウンしたら隣町から入ろうという意識になる。よそまで飛ばしてしまうと、全国に飛び交ってそれぞれのサーバがパンクする。
●鈴木
緯度経度でやりとりしようというのはグルーピングのことだけではなくて？
●小林
グルーピングもできる。たまたま自動化したいだけで、緯度経度使っている。グルーピングのしかたは座標系でもいいし、取り決めでもいい。それはＳＮＳの作り方による。
●河井
近隣の緯度経度にサーバがあるとＲＳＳが吐き出せるものと、自動的に取りに行くという…。
●小林
取りに行くというより、まず配信する。いったんつないで信頼性を高めよう。実際にやってみないといいのかどうかわからない。
これはやばい方法だけど、ここ（あるサーバ）に登録してある情報はこっちとこっち（近隣の２つ）にも配信する。この人はこのメールアドレスとハンドルネームとパスワードだというのを送るとまずいので、ハッシュ関数というのがある。例えばこの名前とこのパスワードとハンドルネームを検索すると、この数字になりますよ。この数字からこっちは導き出せない。そういう数式がある。その数式情報だけを送る。こっちがダウンしてこっちからログインしたい時はそのハッシュ関数を用いて認証させる。これで自動的に配って地域から発信できる状態にする。
●鈴木
実際コンテンツがダウンしたときには？
●小林
そこでリソースの多重化がある。今ユーザを配った…。当然リソースも配らないと意味ないんで、コンテンツも出す。全部配るとバックアップも腹痛になるかなってことで、今のところ重要な情報だけコピーしようかなと考えた。全部コピーしてもかまわないと思う。
自分が持っている元のサイトのユーザのハッシュ値と日記のデータをくっつけて送る。ふだんはその情報は見えない。で、これがダウンしたときはそれを表に出すようにする。そこでいろいろ書き込みが起こったら、復旧後にまたこっち（元のサイト）に転送し直す。そういう仕掛けです。
本当はバックアップ取っているサイトどうしを通信させて、同期とれればいいけどうまい考えが思いつかない。
●鈴木
トラフィックが許してくれない。
●小林
ここでユーザとデータが揃った。
もう一つ、友達のＳＮＳに入る仕組み。ちょうど出国審査を受けて入国審査を受けるようなイメージ。このＳＮＳにＡという人がいたとする。この人がこのＳＮＳに入りたいときには入国して仮登録するような感じ。
●鈴木
なるほど。ハッシュ値の交換があるからできる。
●小林
外国人として動く。当然こっちにログインすれば勝手に入れる状態。
もう一つ外国人と友達というケース。Ａが隣のＳＮＳに仮登録する。こっちには外国人Ａとして登録される。するとＢという人もこっち（Ａの属するＳＮＳ）にも入れるようにする。お互いのＳＮＳから見ると、同じユーザのリンクのつながりですけど、大きくシステムを見ないような。手前に立ってみるとお互いがつながっているように見える。そういう仕掛けを作ろうかな。
●鈴木
要するにmixiのお友達グループの中にGREEの誰々さんが入るという…。
●小林
そんな感じ。
●河井
それって総務省の地域ＳＮＳのつなぐっていう発想とつながりますか。
●小林
つながります。地域ＳＮＳどうしをつなぐっていうのは、次の段階の話で総務省ではそこまではやっていない。これは自分の地域の実験。
最初に思っていたのは公務員のＳＮＳを立ち上げようかな。九州地区、四国地区、何とか地区とＳＮＳを分けて、そこに自治体として入って外国人として入ってつなげていく仕掛けを構築しようかな。
当然、情報のやりとりはＲＤＦでやりとりする。ＳＮＳの自動検知、リソースの多重化、入国の管理…。リソースの多重化はＲＤＦのダブリンコアでやる。友達とか入国管理はＦＯＦを使って通信させる。Friend of Friendという。その仕様がころころ変わっているみたいで、どういう適用のしかたにするか悩んでいる。とりあえず自分ＸＭＬを作ってみて、それから標準的なＸＭＬの方に持っていこうかな、と考えている。
データのやりとりはＸＭＬでやるのが基本。
●鈴木
個人用のブログも、これがきっちり動けば引越しというスタイルがなくなるのかも。
●小林
そうなんですよね。
●鈴木
現状では自分のデータは自分のパソコンにバックアップ取る。データを吐き出すってところで。現行ではテキストで吐き出してるところはあるが、データベースでは画像の扱いが難しくて、結局、ＰＤＦで吐き出してみたり…。画像だけでなくテキスト以外も含めて現状ではＸＭＬに落ち着くと思う。ＸＭＬの中に画像を埋め込むというような形の方法があるのであれば、完全に個人としては持ち出しやすい。容量に関係ないといえば一番いいだろう。
●小林
MIMEでエンコードして中に持っておく方法でもいい。
●河井
その方が安全。相手のサーバが死んでしまっても自分のところに持っていられる。
ボクのブログでは、画像にリンクはってるだけなんで、昔の画像はココログにある。今の画像はＦＣ２に持ってる。
●小林
ややこしいですね。
●鈴木
自分でもわからなくなってしまう。
●河井
いつ引っ越したかわかるんで、それでわかることはわかる。
●鈴木
最近ジュゲムというサイトがダウンして大騒ぎになったことがあった。そういう時にリンクだけじゃ救いようがない。
●小林
これ（ＳＮＳ間の継承）があれば補完してくれるので、何かしらログインすれば自分の情報が見れる。
●前川
危機分散の考え方。いくつもコピーして失われないようにする。
●小林
やり方はインターネットの自律ネットワーク。それとリソース分散＝冗長化をもとにしている。
●前川
リンクほど信頼性のないものはない。リンク先がいつ失われてもおかしくない。自分のデータの実体があることを何ら保証しない。多重化が目的ですね。
●鈴木
これは面白い。ＩＸが東京に一極集中して問題が起きた時にどうするか。
●小林
アプリがウェブサービスのところに至ると、ルーティングという考え方がいらなくなるので逆にシステムが組みやすい。それぞれのサービスがきちんと動けばルータみたいなのはいらない。お互いの情報をきちんと把握していればいい話なんで。あそこと通信したいという意思があれば、下のレイヤーでちゃんと通信やってくれる。
●鈴木
今、東京にコンテンツサーバが一極集中してるけど、この考え方がうまく稼動すれば、地域のデータセンターのような安定性が高くないところでも、十分に安定性の高いサイトが構築できる。
●小林
地域ＳＮＳで思うのが、1000人とか2000人の単位を管理するのは結構簡単。なぜ簡単かというと見回しがよくできるから。それが何万とか10万とかになるともう訳がわからない。それよりも管理者がいるサイトをいくつも作ってお互いが連携した方がうまくいくのではないか。
●鈴木
そう思いますね。
●前川
セキュリティの話も絡むが、そのサーバを公開しようと思うからそこでセキュリティを固めないといけなくなる。例えば鈴木さんの南房総でサーバを立ち上げて運用する。公開するときにもう１台別のサーバをおいて、そっちをクローンにしてパブリッシュすると、攻撃受けても元は痛まない。元はファイアウォールの中に入っていていい。発信元は自分のところに置いて、パブリッシュするときは別のサーバにコピーしたものをおけば非常に安全な運用ができる。元は知られなくていい。非常にセキュリティが高くなる。サーバを分散させる。
●鈴木
ユーザにとっても安心。各地域地域でサーバを管理している人のこと考えると、お互い助け合おうじゃないかと。
●前川
地域ポータルサイトがＡ，Ｂ，Ｃ、いくつもあるとすると、これを統合的に扱えるサイトを設けて、皆でパブリッシュし合おうと。それを公開すればいい。
●小林
以上がＳＮＳのデータ連携の部分。

open-gorottoではレイヤーが下の方の話で、モジュール化する話がある。
今のうちのサイトの構成は（画面出して）こんな感じになっている。一番下のレイヤーがＯＳ。その上でＤＢＭＳが動いている。その上でＡＰＩが３つ動いている。WIKIとSNSとGIS。WIKIというのはキーワード生成とかHTML生成とかをやるレンダリングエンジン。SNSは友達とか「つなぐ」っていう話ではなくて実はアクセス制御。この人には情報出していい、この人には出してはいけない。GISはおまけの機能。その上でそれぞれのモジュールが動いているという考え方。これまで整理していなかったので、煩雑なソースになっていた。ここ（モジュールのレイヤー）を独立して動かそうということで組みなおし中。
まずアクセス制御の話。（画面変えて）実は生データはこれだけ。他にはユーザの基本情報。ハンドルネームは何々とか、ユーザは有効かなど。もう一つはグルーピングデータベース。このユーザはどのグループに属してますかというグルーピング。公開条件ＤＢというのは、このリソースはどのグループに公開していいかという情報。
例えば、ある人がとある日記を見たいと考えたとする。ＤＢ検索するとどんなになるかというと、まず基本情報ＤＢとリソースＤＢをくっつけて、リソースの保持者が誰かを特定する。そのリソースの保持者が所属しているグループはどこかを次に見る。これには当然メンバーのIDまで入っている。自分が「全て」というメンバーになっていれば、全てに入っているユーザもドーンと持ってくる。それからさらにフィルタリングする。グルーピングの情報全て組み合わせて、それをさらに上のところに持っていく。最終的にこの人が残っているかいないかで、出す・出さないを判定している。
どうしてこういう構造しているかというと、これだけで友達かどうかの判定ができる利点があるから。ごろっとには今は友達の友達はないが、全てに公開するというのはアクセス制限をさせないのではなくて、入会した人は「全てサークル」というグループに入っている。友達は「友達サークル」に入っている。友達の友達という概念も「友達の友達サークル」を作ってやれば機能が実装できる。で、こういうモデルにしている。

次にデータをどうやって登録するか。例えば日記のモジュールがあるとする。日記を書く仕組みは日記ＤＢを更新して公開する。単にこれだけ。このモジュールがそういう動作をしてくれれば問題ない。外部のリソースの読み込み方法は、１時間おきにこのＲＳＳを取ってきなさい、というＤＢを持っている。それをもとにもってきて、こことここを更新しているだけ。ガンガンも同じ。ガンガンに画像入れて全てに公開。そういうデータ更新のしかたをするだけで、アクセス制御ができる。だから誰々に日記を公開する・しないというデータモデルじゃなくて、日記は日記、生のまま入っている。だからテーブルを増やすだけでいろんなモジュールに対応できる。

今、実はopen-gorottoのデザインを変えている。今こんな感じでメニューが出る。メニューをモジュール化しようかなということで、今外した状態にしている。
（未設定のトップ画面を出してみて）今何もない。ここにプラグインを追加して機能が追加されていく。それぞれのプラグインの機能はリソースＤＢと全てを公開するか、しないかというＤＢを更新するかしないかで、ＳＮＳの機能をそのまま持っていけるという仕掛け。これ（未設定のトップ画面）もログイン・プラグイン。ログイン・プラグインだけ動かしている。
●鈴木
小林さんがインタフェースの仕様だけしっかり作ってくれれば。
●小林
そうなんですよね。これＮＴＴデータが使うということで整理してた。今ベタのソースで更新されてもらうと、後から取り込むとき大変になるので、できるだけ分離しておくと自分も楽できる。
●鈴木
モジュールになっていると使う方はブラックボックスになって気にしないで使える。ベタになると直さないといけない。
●

[ 記録日(2005/08)へ戻る ]

[ 地域(岐阜) | 記録日(2005/08) | 登録日(2005/09) ]

[ ホーム| ]

eメディア・フォーラム