33 posts tagged “event”
昨日の「知の構造化センターシンポジウム」で楽しくなってしまって、今日のWikimedia Conference Japan 2009も行って来ました。ただ、朝は起きられなかったので、午後から。twitterの#wcj2009_Hに@argさんという方が投げている内容や、@mhatta氏のつぶやきを見ていると午前中の「辞書・事典とは何か」は必聴モノだったようで、そこはじわじわと後悔中。
テキスト解析好きなので、ずっと技術セッション=第21回セマンティックウェブとオントロジー研究会を聞いていました。以下メモ。昨日のも同じだけど、僕がメモをミスってたり誤って理解している部分があるかもしれません。その点は考慮してお読みください。改めて見返すと、参加した人にしか分らないキーワードの羅列になってるし、読む人がいるのか分からないけど。
【Wikipediaと研究コミュニティ】(武田英明 国立情報学研究所)
http://www.slideshare.net/takeda/wikipedia-and-research-wcj2009
ソーシャルメディアとしてのWeb
創造とは
・創造は無から生じない(Collect)
・他者の仕事を知り、理解する(Create)
・他者へ自らの仕事をみせていく(Donate、一般にはPublishing)
・これがループ
・このループへの参加を一般人でも可能に、またループを加速したのがWeb
新しい創造のループ
・集まる(Relate):三人寄れば文殊の知恵
・協働する(Collaborate)
・提示する(Present)
・情報を知ることは人を知ること、またその逆も
・情報を見せることは自らを見せること、またその逆も
ソーシャルメディア
・「社会的に広がりのある参加者によって構成され、参加者間のコミュニケーションによって成り立っているメディア」
・特徴:大規模な参加、何らかのコンテンツを生み出す、参加者間の相互作用がコンテンツ作成に影響を与える
・相互作用=コンテンツ:掲示板、Q&Aサイト
・相互作用がコンテンツに影響:Wikipedia、ニコニコ動画
・例:初音ミク動画の協創プロセス
ソーシャルメディアとしてのWikipedia
・大規模性、網羅性、共同性
・データ入手性 … これが非常に大きいファクタ
Wikipediaと研究
・分析対象としてのWikipedia:“Wikipedia現象”の分析
・なぜこれだけ大きくなったのか?だれが、何が、...。
・合意形成のプロセス
・集団性、社会性
・データとしてのWikipedia:Wikipediaデータの利用
・知識の集合として
・多言語の集合として
・構造化文書の集合として
・Wikipediaの支援
編集プロセスに注目した研究
・ページのクオリティは編集者の数より、編集者のgini係数(≒一人の人の占める編集領域の割合の高さ)に相関
→継続的に編集してくれる人の存在の方が重要
・「秀逸なページ」を「クオリティの高いページ」とみなした
知識集合として
・広範で均質な知識源とみなして利用する
・国内各研究
・Yago:オントロジー作成。
・DBpedia:オントロジー作成。上位クラスはYagoから、インスタンスの関係はInfobox(Wikipediaのページ右上に表示されるボックス)から。
・常識、日常知識の利用
・PowerSet
・意外な知識の発見
Wikipediaの利用
・上記のようなさまざまなデータを外部から利用可能
・Linked Dataとは“Web of Data”(ティム・バーナーズ・リーの命名)
・Linked Dataによるマッシュアップ≒Bing?(Bingはそのデータの選択が秀逸)
まとめ
Q&A
Q:興味どころは?
A:分散してるのは当たり前、その上でどう共創していくか、というところ
【Wikipediaからのオントロジー構築とその活用】(山口高平 慶応大学)
資料は後日、研究会のホームページに掲載
ODP(Ontlogy Developping Process)とOL(Ontlogy Lerning:機械学習等)
・Wikipedia2Onto→評価→応用
ODP:オントロジー開発プロセス
・determin scope(Swoogle、watson)
・consider reuse
・enumerate terms
・define classes
・define properties
・define constraints
・create instances
OL:オントロジー学習ツール
・実装は山のようにある
・Doodle-owlというものを作っている
・関係性を、共起性を元にリコメンドし、人が決定する
スクレイピング(ごみを取る)
・一覧ページ
・カテゴリとカテゴリ階層 → is-aとhas-aの混在、InstanceとClassの混在
Is-aの抽出
・後方一致→is-a(空港→日本の空港)
・前方一致→is-a(日本のスポーツ選手→日本のゴルファー:スポーツ選手→ゴルファーというis-a)
・Infoboxのテンプレート
課題
・上位、注意概念が不足しがち
・間違った上下関係
・文字列照合から生じるハイブランチ構造
デモ
・ロボットの太極拳。オントロジー関係ないけどすごい。というかすごいけどオントロジー関係ないw
Q&A
Q:is-aとhas-aを区別しやすい、登録し分ける仕組みをWikipediaに提案することは有用化?利用者にとって便利になるか?
A:かなり利用目的によるところで、意味を調べるといったところ出にはあまり利さないので、デフォルトで提供すべきものではないと思う。
【MediaWikiと構造化知識の抽出】(中山浩太郎 東京大学 知の構造化センター)
Wikipediaの解析がなんの役に立つか
・翻訳辞書、連想シソーラス、Webオントロジ
・Wikipedia API
・セマンティックWeb
デモ
・Wikipedia Thesaurus(http://dev.wikipedia-lab.org/WikipediaThesaurusV3/)
・WikiVisiSL
データ復元編
・pages_articles.xml.bz2がお勧め
・実はダンプデータ間にタイムラグがあり、SQL版とXML版は微妙にデータが一致しない
・解析用であればMyISAMを使用(トランザクションログ不要なのでInnoDBを使わない)
・mwdumperを使用、-serverなどオプション重要
主なディレクトリ
・config:設定ファイル
・skins:スキン、テンプレート
・extensions:プラグイン
・maintenance:メンテナンス用スクリプト
・includes:クラスライブラリ
主なテーブル
・page:ページ構成
・langlinks:言語観リンク
・pagelinks:ページ間リンク
・categorylinks:カテゴリリンク
・text:本文(ページID、テキスト)
便利そうなスクリプト
・maintenanceディレクトリには全部で98のスクリプト
・changePassword.php
・dumpBackup.php
・dumpHTML.php
・updateSearchIndex.php:復元後の検索インデックス更新
・rebuildall.php:テキストインデックス、リンクテーブルの構築
・「php スクリプト」で実行できる。
クラスライブラリ
・解析で厄介なのが、例えば「Wiki構文の解析(除去)」→includes/Parser.phpのParseメソッドでOK、メモリリークすることがあるので注意
・Wiki、Article、Titleなどのクラスも便利
ユーティリティ
・Wikipedia Research Scriptを作っている
【Wikipediaにおけるキーパーソン抽出による信頼度産出精度および速度の改善】(鈴木優 京都大学大学院情報学研究科)
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。
結論
・ほとんどの記事の信頼度が低い。
・記事の信頼度の高い記事は少量
研究の目的
・Wikipediaの記事の質を産出
・高い質の記事を読者に提供(質の低い記事を排除)するため
・記述の不十分な記事を著者に提示するため
・二つの特徴
・実用的な時間での信頼度産出
・精度の高い信頼度産出
著者の信頼性の評価
・Adler et al. WikiSym '08, WWW 2007
・著者が他の部分のレビューを行ったから、残すべきところを残したという考え方
問題点
・時間がかかる。
・履歴はすべてで100万件弱、すべて1秒で処理したとしても...。
アプローチ
・80%の記事を書いている20%の著者(Ziphの法則)に絞って調べる
・キーパーソンを特定する
・編集量多い著者、編集した記事数の多い著者をチョイス
編集履歴と編集量順の相関
・順位の相関:スピアマンの順位の相関係数を使用
Q&A
Q:以降の編集回数より、移行の経過時間を評価するべきでは?
A:実際に時間を信頼性抽出に使用してみたところ、信頼性が低かった。
【Wikipediaにおける編集者の活動分析】(山崎由佳 慶応大学メディア研究科)
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。
・分析対象:bot、IPユーザ、ログインユーザから計100名
・編集回数が5回、25解
ネットワーク分析
・平均経路長とクラスタ係数を調べる
・再編集は経路長最小
平均経路長
・変種回数が増えるほど平均経路長が長い
・種別でみると、ボットは突出して平均経路長が長い
クラスタ係数
・クラスタ係数は大きなばらつきが見られない
・種別でみると、人間はクラスタ係数が高く、ぼっとは極小
分類
A.狭範囲、少編集:特定分野の編集に興味、IPユーザ?
B.広範囲、少編集:閲覧記事が気になり編集、ログインユーザ?
C.広範囲、多編集:bot
D.狭範囲、多編集:いなかったけど、あえて言えば荒らし?
※ここで抽出したクラスタとカテゴリの関係性は?
※広範囲、多編集、記事系統に偏りのあるログインユーザを見つけると、ダンドリストタイプかも?
Q&A
Q:IPユーザは同一人物とは限らないが、それがノイズにならないか?
A:そこは懸念点、何かいい方法はないか?
※逆にIPユーザが個人なのかグループなのか、などの分析ができそう?
Q:平均経路長にリンク関係などを考慮したらどうか?
A:やりたいと思っている。例えば記事間のホップ数を考慮したいと思っている。
【ウィキペディア記事閲覧回数の特徴分析】(山名早人 早稲田大学)
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。
取得データ
・ダンプデータ
・閲覧回数データ → これも信頼性や貢献度を定量化するのには有用では?
閲覧回数データ
・Domas Mituzas氏が公開している(http://dammit.ly/wikistats)
・1時間ごとのデータで、言語コード、記事名、閲覧回数、バイト数。
・転送時は転送元、転送先療法でカウントされる。
・pagecountsの他にprojectcountsもある
編集回数との比較
・UUを調査
・IPユーザは一人のユーザとしてカウント
・編集回数・UU数が多いものは閲覧回数・UU数が多い
・編集回数・UU数が少ないものは閲覧回数・UU数は広く分布
・Spearmanの順位相関係数は低い
→逆に編集回数からは分らない情報が閲覧回数には含まれているかも知れない
検索エンジンでのヒット回数(≒語の有名度)との比較
・正の相関:順位相関係数0.53
Q&A
Q:月間編集回数より累積編集回数のほうが質に関係があって閲覧数と相関しそうに感じる。なぜ月間の編集回数なのか?
A:そこは特に検討していない。
※月間の編集回数の変化と閲覧回数は相関するかも(減衰が早い=早く誤りがなくなる、枯れていく傾向)
【Wikipediaカテゴリネットワークからの意外性のある関連性の抽出】(野田洋平 東京大学)
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。
オープンコーラ
・Wikipedia上にあるが、あまり知られていない
・「オープンソース」と「コーラ」から辿れる
→オープンソースとコーラの意外な関連
アプローチ
・グラフネットワーク構造から特徴量抽出
・カテゴリ間の関連性の意外性が高い=共通小項目が少ない、カテゴリ同士が遠い
・カテゴリA、カテゴリB、共通インスタンス(記事)の関係性をすべて取得し、その中から以外性のある関係性を発見する
【多言語に展開するWikipediaの特徴の比較調査】(森竜也 東京電機大学)
※発表資料が「第21回セマンティックウェブとオントロジー研究会」ページで公開されています。
言語観の差異
・言語間では、ある言語にはあり、ある言語にはないというページがある
・文化、歴史、etc.が違うのだからあって当然
→積極的に個々を調べるべき
・あるカテゴリに対する言語版ごと下位エントリの数を比較する
※あるエントリのサイズを比較しても面白いかも知れない
方法
・XMLを直接解析
・Luceneインデックスとして保存
問題
・ここでもカテゴリ間の上下関係に不適切なものがある(イスラム教→...→オリンピック競技など)
・タイトルをbigramで比較し、閾値0.25で切るようにした。
・結果を見ると第二次世界大戦と太平洋戦争の間が切られているなど、よくないものがある
例
・言語版の違いが大きい例:江戸時代、キリスト教、第一次世界大戦
・言語版の違いが小さい例:データ構造
※これで何をすることをゴールにしてるんだろう?
※スコアの増加傾向の比較をすると、将来予測(Wikipediaでの動向からして○○文化圏ではこれから××分野が熱くなりそうだ)に使えるかも知れない
【総合討論】
-- Wikipediaの「信頼度を測る」という話題が多かったが、信頼できなさをどこに感じるか?
武田:ある水準まで信頼性は達していると思うが、極論すれば専門家による信頼度に及ばない部分は出ると思う。その意味で、逆に信頼度の低い記事を排除するというアプローチはありだと思うし、そこは機械的な手法が効く部分だと思う。
山口:オントロジーの構築をコストレスでできないかということを考えてきた。電力分野を調べたことがあるのだが、意外と電力分野は専門的な知識までしっかり書かれている。そこにある知識をそのまま実地に適用していいかというと創ではないが、最初の手がかりとしては有効だと、これは電力の専門家と話していて出てきた。最初に使える資源としては有用だと思うし、そう使う手法を開発していった方がいい。
中山:Wikipediaの信頼性を語るときに、ツールがいいのかというと、それ以上にソーシャルのパワーがいいものだと思う。その意味で、ソーシャル、個々人が判断しやすい情報を提示する方向性がいいと思う。
-- 各国語版の中で日本語版はポップカルチャーが多い。その偏りがあるということは良いことか悪いことか?それを生かす方法は?
中山:ページ間のパスを調べていると、英語ではうまくいく場合でも日本語ではポップカルチャー的なところにバイアスがかかることはある。そこで言語観で解析時にはバイアスがかからないような指標を取り入れたりする。しかし偏りがあること自体は、それが文化だと思うので、悪いとは思わない。
武田:私もむしろそういうところにある種の知の集積ができた、フォーカスのあたるところが見えてきたという価値だと思う。それがわからないという問題が解決してきたと捉えられるし、それをもっと可視化したらいいと思う。ドイツ語版Wikipediaで製本をしたときに偏りのないものにする取り組みがあったという話を聞いて、それはそれで面白いと思うけど、僕はむしろ偏りがわかるように作るのが面白いと思うし、そうすることがポジティブなフィードバックを生むと思う。
山口:私の立場では、結局Wikipediaに頼るべきではないというところ。それはそれとして、例えばポップじゃない電力分野が充実していたり、私としては文句はない。
-- Wikiepdiaの課題としてカテゴリとして小さいところがあり、本当に小さいのか手薄なのかわからない。裏番組の相互オントロジーではどんな話を?
橋田(会場から):総合概念のオントロジーを構築して提供しようという話。ITハンドブックでは小項目主義を採り、36分科会にふり、ドメインによるコントロールで粒をそろえた。Wikiepdiaではドメインによるコントロールをするものではなく、そうした形になってないのだと思うし、それはそれで結構なことだと思う。ただ一つ気がかりなのは、一般の市民から知りたい専門知識のリクエストが上がっていながら、専門家が答えられていないといったことがあれば、それは残念。
田中(東京大学):400にもなるプロジェクトはあるようだが、そこまではいっていないし、研究者としてそういうところはサポートしていければなあ、と思う。
(会場):Wikipediaに深く関わっているが、例えば2ちゃんねるのようなファンの多い分野にはプロジェクトが多いが、伝統芸能といったところをどうしていくかという問題は残る。
-- 不足分野があったときに、専門家を巻き込むような仕組みの事例はないのでしょうか?
武田:アメリカでは大学や図書館で編集方法を教えるといったワークショップのようなものはあったらしい。
(会場):Wikipediaのルールに「独自研究を載せない」というものがあって、それがどうなのかな、というものがある。
武田:Wikipediaで言っているのは、factを書けという風にとるべき。自分の研究を書いてはいけない、という意味に取る必要はない。
(会場):過去にWikipedianとして活動したが、文献の少ない項目で、どうしようもなく自分の文献を参照している。また、学会ジャーナルの編集部などが、適切なリファレンスだと思えばパブリシティを高める上で積極的に記述と参照をしていってもいいと思う。
武田:ファクトとして書くのであれば、それはファクトに基づいて反論すればいいので、ありではないかと思う。
(会場):Wikiベースでオントロジーを作るというアプローチは?
武田:セマンティックウィキという例がある。
(会場):今のアプローチでは、コミュニティに対して一方通行で、例えばインスタンスであればコミュニティで作れるなどの方向はあると思う。
信頼性を図る上でのディスカッションページの自然言語的な解析など、あってよいはずなのに手薄な分野というのはあると思う。Wikipedia研究の薄い部分は?
中山:他のリソースとの融合。ボトムアップが得意な分野とトップダウンが適する分野があるのだから、そうした外部の例えばワードネットとの融合など、そうしたところをやっていくことが重要になるように思う。他のウェブ情報とのダブルチェックなど
山口:実際に非常にシャロウな処理しかしていない。もっとディープな言語処理を持ち込んでいったら、例えば前に座られている松尾先生などが入っていただけたら、すごい進むと思う。もう一段深い世界に至れると思う。
武田:情報系の人が喜ぶようなデータは出しているが、社会系の人と組んだような研究はまだ少ないように思って、どちらから入ってくるのかわからないがそこができたらまたいい研究ができるのではないかと思う。
【クロージングセッション】
-- A会場のセッションがまだ終わらないので、急遽ウィキペディアQ&A
Q: ウィキペディアで管理者が非常に足りないと聞く。アンサイクロペディアにのびた君制度というのがあって、そういった取り組みをしたらどうか?
A: いくつかあって、インターン制度などの話も進んでいる。
Q: 実際に自分で書いてみたりして、やりがいとか嬉しかったことなどは?
A: ...えーと、ここで答えようとしている二人は、あまり書いていないので...。
A: オープンソースの世界では「かゆいところに手を」ということがあるが、ウィキペディアでもそういう人が多い。また「キャリアに役立つんだ」というOSS開発者も多いが、ウィキペディアでは創は履歴書にかけないというか、隠す人が多い。それでも利用者ページをみると、自分で勉強してまとめて発表するというプロセスが楽しい、あるいはコミュニティ内部でのインタラクションが楽しいといった手ごたえだと思う。
A: もめたりとかして利用者ページに「しばらく休みます」と書くと「がんばってください」とコメントが入ったりというのはみます。
■ 終わってみて
Wikiepedia研究というのは、こんなに多くに人が取り組んでいるのだな、というのが何よりの感想。Wikiばなというのはそれなりに多くのWikiフェイバリットが参加してくれていたと思うのだけど、Wikipedia界隈とも、こうしたWikipedia研究者とも重なる部分が少なくて、もっと、融合する必要はないにしても異文化のまま接点というか交流があってもいいんじゃないかな、と。
あと懇親会は話をできた人たちが面白くていろいろ聞けたし、クロージングあたりでいろいろいいこと言ってると思ったりしたのだけど、懇親会は参加した人の楽しみということで僕のメモはなし。
マイニングなどの話もある「知の構造化センターシンポジウム」というイベントがあると知っていってきました。東大。赤羽からだと、南北線で15分とかからず近いんですね。
- 「多様な意見」はなぜ正しいのか
- コミュニティの知識創造:コミュニティが、コンテキストをつくり、コンテンツ(意味のある情報)を生み出す
- 19世紀のエジソン:専門知の勉強、膨大な試行錯誤/これからのエジソン:ネットで呼びかけ
- 投資家(エンジェル)集団Common Angelsの巧みなコミュニケーション・プロセスの設計
- 新時代のナレッジツール(○○力)7種
2週間前になりますが、enNetforumの第2回EGMセミナーを聞いてきました。
特に面白いと思ったokdtこと岡田良太郎氏の発表は、資料を公開しないとのことだったのでどうにも感想など書けずにいたのですが、今日になって事務局から資料公開のお知らせが。見てみると、okdtさんの資料も公開されています。
ということで、okdtさんの資料「クラウドソーシング - 組織のポテンシャルを上げる“協業”のスタイル」の個人的な見どころ。
- 12~16ページの資料。McKinseyの"How businesses are using Web 2.0"などは未見で、探すために正式タイトルを知りたいと思ったところ。
- 21ページ。ここら辺は押さえておきたいというような有名企業例が列挙されてるのはおいしい。
- 26ページ。これを念頭に置くと、業務で作られるにグループはゲゼルシャフト、SNSなどが作るのはゲマインシャフト、「人の流動性が確保できてる」企業でも、SNSなどの導入はやはり人間関係の多様化につながるのだと確信できる。
- 29~32ページ。クラウドソーシングが有効な場面がまとまってる。ちなみにセミナー全体では「社員の隙間時間を集約して従来型生産」という話もあったけど、それは違う方向を向いているっぽい気がする。
全体に、このページ数ですごく良くまとまった資料だと思います。お薦め。
----
本エントリは2008年9月に社内SNSに書いたものを、2009年12月に転載しました。
また同じく第2回EGMセミナーでのTG情報ネット様の発表に着想を得て、「社内SNSの定着度を平均フレンド数で測る」というエントリをokilab.jpに書いています。併せてお読みいただければ幸いです。
今日は午前中、コクヨオフィスシステムの霞が関ライブオフィスで行われていたKOS Fair 2008 【RESONANCE FIELD 2.0】へ。
おかげでこの数週間自転車通勤の僕は、午後からの出社のために真昼の日差しの中を自転車に乗って移動になってしまったのだけど、それだけのことはあった。面白かった。
今回は焦点はエコなオフィス、図でいえば分母のCurbon Freeにウェイトが移ってしまってるらしい。僕がはそもそも、ビジネス顕微鏡の話に惹かれていった、つまりクリエイティブオフィスの方により関心があったのだけど、それはこの前の焦点だった様子。
ところが、鳥居さん(といったと思う)という方がクリエイティブオフィスの方の話を熱心にしてくれたり、紹介資料も探し出してきてくれたりして、嬉しかった。すごくよく考えられてて、聞いてて楽しい。
以下に関連記事をメモしておく。
- コクヨ「RESONANCE FIELD 2.0」:「同じ席には2時間まで」「疲れたらプラネタリウムで休憩」――コクヨの新オフィスとは - ITmedia Biz.ID
- コクヨ「RESONANCE FIELD 2.0」:社内の「あの人とあの人が仲がいい」を視覚化――ビジネス顕微鏡 - ITmedia Biz.ID
- 外回りから帰った社員をクールダウン、コクヨオフィスシステム|オフィス・アイ(ケンプラッツ)
- コクヨオフィスシステム、本社オフィスを環境配慮を可視化する次世代ワークスタイルとして提案 - 日経プレスリリース(※「関連資料」に写真など)
このオフィス、5月にリニューアルされたものということで、その時の詳しい記事があった。上の記事に登場したプラネタリウム、ビジネス顕微鏡、クールダウンルームなどの新顔以外にも、多くの仕掛けがあったので、リニューアル時の記事も見てもらうと良いと思う。
これだけの沢山の仕組みが、単体の面白ギミックじゃなくて、人がオフィス内で自然にクリエイティブに動くように連携している点がすごい。
例えばITmediaの記事に「同じ席には2時間まで、会議室の使用も2時間まで――。時間を区切って集中する。」と書かれているが、それだけじゃない。午前の3時間、午後の4時間の間に、それぞれ一度は時間切れする。時間切れすることで、次の席を予約しに予約システムのあるロッカールームに行き、新しい席に向かう。
ITmediaの記事の「オフィスでの行動が見えてますか」という写真を見てほしい。ロッカールームが14の赤丸。赤丸は、ビジネス顕微鏡が明らかにした会話の多いエリアだ。そしてその往復時に通る通路沿いに、15がアトリエ、8がフラット、7が左からサプリ、パノラマ、グリッドと呼ばれるエリア。会話が生まれる空間というギミックと、就業時間中にオフの瞬間が生まれるような運用、そしてオフの瞬間に会話空間を横切り会話空間に入るという配置。
「同じ席には2時間まで、会議室の使用も2時間まで――。オフを作って創造する。」そんな意味もあるのだ。これが「すごくよく考えられてて、聞いてて楽し」かったことの一端。刺激の生まれやすい、知的な空間というものを、考えさせられたイベントでした。
第8回「gungi」行ってきました。
■「携帯サイト開発へ押し寄せるのグローバル化の波」(タイトルが変わってました)
携帯電話のガラパゴス話、「日本の携帯は開発者の自由度がもっと高くても良いのでは」といった意見の披瀝に続いて、NOKIA携帯がどれだけ自由にいじれるかのデモ。
NOKIA携帯にTelnet接続し、Python for S60(だと思う)のコマンドプロンプトから、発呼、切断、録音、再生などをしていた。コンパイルされたプログラムではなく、インタプリタから逐次コマンド入力で携帯電話そのものの機能を動かせるのは、とてもあけっぴろげな感じで確かに楽しい。
途中で紹介されていたFunambol、紹介を聞いていた時は携帯電話プラットフォーム間の差異を吸収するライブラリみたいなものかと思ったのだけど、SyncML(PIMデータなどの同期用マークアップランゲージ)アプリケーションだった。Open Tech Pressに「Funambolのビジネスを生かすオープンソース・ソフトウェア」という記事がある。
「最新バージョンのFunambolに対応するコネクタを作成した開発者に$1,000~3,000の賞金が贈られる」というCodesniperプログラムは面白いね。現在のCodesniperプログラムのページを見ると、Trolltech Qtopia Plug-inに$3000の賞金がかけられていたり、Google Android Push Email and PIM ClientがCode Receivedになっていたりする。
■ 「今からでも間に合う! AIR の第一歩」
あまり理解しなかったので詳細は割愛。一つ私が大きく勘違いしていたのは、Airはブラウザ上で動くアプリケーションを作るためのものだと認識していたこと。実際には、かなり簡単にデスクトップアプリケーションを作れるものみたいだった。Perl/TkみたいにPerl/Airライブラリとか出てくるとうれしいのだけど、コンパイルが必要だと厳しいか。
■ 「“グリムス”という参加型環境サイトのご紹介」
ブログパーツ「gremz」提供者らによるgremz、gremzの実装、開発者チーム運営について。資料は公開予定とのこと。
興味があったのはサーバ環境と資金繰り。基本的に、さくらのレンタルサーバで運営しているとのこと。
- さくらレンタルサーバで、最初は月500円のスタンダードプラン
- 1週間時点(Blog Action Dayで取り上げられたらしい)で最初のダウン、DBチューニングで乗り切る
- ユーザー数5000人あたりで1日の転送量が10GBに→5000円プランに
- 現在、次の方策を検討中
gremzは、ブログ更新状況に応じて樹が育つブログパーツが基本形態で、あるところまで育つと、gremzからNGOを通じて実際に植林がおこなわれるとのこと。「苗代は案外と高くなくて、アフィリエイトでだいたい回っている感じです」ということだったけど、サーバ代なども込みの話だったのかな。確認できれば良かった。
■ その他
体調不良につき、懇親会は不参加にしたので「その他」はあまりないのですが、上田修子さんに久しぶりにお会いしました。「最近、とあるWeb屋に就職しました」とのことで、新しい名詞を頂戴しました。おめでとうございます。
2週間ほど前になりますが、Googleデベロッパーズ交流会Vol.5「OpenSocial」に行ってきました。社内SNSに日記として公開していたメモを(一部省略して)転載します。
- People API - 個人および個人同士の関係についての情報。
- Activities API - 人の行動に関する最新情報を公表して表示する機能。
- Persistence API - サーバー不要のステートフルなアプリケーションを実現する、シンプルなキー/値のデータストア。
オリジナルアプリケーションの配布
- iGadget風のXMLファイルを作成すればよい。
以下を実現する。
- ガジェットサーバ
- OpenSocialコンテナ
- OpenSocialゲートウェイ(RESTful)
1.でそのサーバ上でOpenSocialアプリケーションを実行できるようになる。2.でオープンソーシャルAPIを提供できるようになる(のか?)。3.でRESTでAPIを中継できるようになる。OpenSocialのサーバサイド実装のためのスィート?
現在、ビルドされたもののダウンロードは用意されていない。「もうすぐ」の予定。svnからのチェックアウトは可能。
現在、グループなどでディスカッションが行われている「提案」段階。REST APIはJavaScript以外の言語からの利用を容易にする、携帯向けサービスを開発できるようにするなどの必要性から、進行されている。
パネルディスカッション
◇ ドコイク?OpenSocial 店舗検索ガジェット(α版)
リクルートMedia Technology Labs.の川崎有亮氏による発表。
- OpenSocial APIを利用した店舗ブックマークガジェットを作成した。
- ドコイク?上で実行できるよう、Shindigを組み込んでドコイク?をガジェットサーバ化した。
- 本日初公開。
◇ 開発どうしてる?
- Orkutは不安定すぎ。hi5やMySpaceで開発して、動作試験まできてからOrkutでも試してる。
- デプロイして実行は面倒なので、Code Runner(これ自体OpenSocialガジェット)を使うとよい。
- MySpace Developer Platformにも同様の機能がある。
Wiki飯に行ってきました。ここしばらく、イベント系は避けていたので、すごく久しぶりな感じです。
●
参加者はWikiaの中の人1名、Wikipedianな人2名、Wikimaniaに行った&また行こうと思っている人1名、Bloggerで「関連トリビアルはWikiaにまとめようと思い始めた」人1名、その関係者1名、Bloggerでちょっと個人Wikiサイトな人1名、CHAKUWIKIの人、私でした。名前記載、リンクOKか聞き忘れたので、比較的匿名で書きます。
Wikiに興味がある/Wikiサイトをしている人が気軽に集まった感じの会。私(Wikiデベロッパ?)と、Wikiサービサーな人がいて、その二人が異色なぐらい(そして浮くのが私という)。WikiばながWikiに熱心に参加している人系、Wiki小話がWikiに対してシリアスな感じの人系な傾向を感じちゃうところはやっぱりあって、こんなイベントも定着してくれるといいな、と思います。
●
某氏とマイクロブロギングについて。
Blog、Wikiと違って、SNSやマイクロブロギングは「友達のいる所には入る」動機がありますね。したがって、一人勝ち傾向がより顕著に現れるでしょうし、twitterの日本語化が済むと、今のtwitterユーザはそのままで日本語版twitterユーザなのでここが一人勝ちというのをひっくり返すのはしんどいことなのではないかな、という気がします。
他のマイクロブロギングは、機能の差別化を測って、「この機能があるからこれを使う」「この機能があるからこれも(twitterの他に)使う」というところを押さえに行くべきタイミングなのではないかな、と思いました。酔った頭では。ついでに、酔った頭で思いついたものを提案してみたのですが、それがどうなるかは五里霧中。
...というか、Wiki飯なトークじゃないですね。
●
今回のWiki飯はTikiTikiというお店で開催していて、途中でお店の人が(?)ダンスを披露するショータイムが挟まりました。途中でお客さんを参加させてて、某氏とWikipedianな人の2名も連れて行かれてたのだけど、某氏は特にテレがなくて、それがかっこよかった。
あと本日いただいた名詞にゴージャスカレー姉妹という一枚があって、映えるタイプの美人な方でした。ダンスに参加しても映えたと思うのだけど、なんでダンサーさん達に引っこ抜かれなかったのかな。
●
テーブルの半分ぐらいで「Wiki界隈の人、Wikiへの思いを語らな過ぎ!」と思っていることをぶつけてみました。
「みんな、こうWikiを使おうよ」とか「Wiki、こう使ってもうWikiなしなんてありえない。お前がなんと言おうと」とか「Wikiってこういうものだよ、うん、きっとそう」とか、Wikiについて主観的にWiki参加者、Wikiサイトオーナが語っているのをあまり見ない気がします。知識経営視点などで「トレンドなWiki」について語っているのは多く見られるようになったので、バランス的にもWikiの現場視点の語りも増えてくるといいな、と思うのだけど。
ということで、Wikiaの中の人がWiki縛りでWikiだけについて語るブログが始まります。本人はやらないといってましたが、やると固く信じています。
●
なんだか久しぶりに泥酔気味です。酒量が過ぎてしまう、楽しいお酒でした。久しぶりにお会いしたお二人にも、初めてお会いしたかたがたにも、ゆきちさんにも感謝。
そんなWiki飯、もう次回を2月22日(金)と決めて、予約もしたそうです。僕みたいなすれっからしというかでがらしなWiki人はほっといて、「最近Wiki始めたんです」とか「Wiki楽しいと思います」とか、もっとWikiを楽しんでいる人が集まる会になるとよいと思います。楽しそうだなと思う人、気軽に参加してみてください!
OpenPNEサイトの運営者交流会「PNEパートナーズ交流会」の9月度が今晩あります。
■ タイトル: 9月度PNEパートナーズ交流会 - OpenPNEで社内SNS
■ 開催日時: 9月25日(火) 20:00~22:00
■ 場所: 「クワトロエス・プラス」
■ 内容: ネットワーキング、Open PNEの動向、SNS導入事例、PRタイム
このSNS導入事例で、OKI社内SNSの状況やカスタマイズ内容などをご紹介することになりました。15分ほどでさっくりとなので、簡単にユーザ数などの統計値と、こんなカスタマイズをしましたという概要レベル。
会社からは「社内SNSやってるとかプレスリリースみたいな感じでは未公表だけど、まあここだけの話的にやっておいで」と許可が出たので、ここだけの話的にこっそり話してきます。参加申込み状況は知らないのですが、まだ参加申込みを受け付けているみたいなので、ご関心のある方はこちらからどうぞ。
# こういうイベントで、事前に話者に申込み状況を教えてくれたりって、不思議に経験ないな。
# 人数とか参加者のプロフィールとか、開催者より話者が必要な情報だと思うんだけど。
しばらく開催されていなかったWiki小話ですが、今週末にWiki小話Vol.8「イントラWikiを語る」を開催したいと思います。
Wiki小話Vol.8「イントラWikiを語る。」 日時:9月29日(土)14:00~16:00 場所:ルノアール新宿区役所横店会議室 費用:飲み物代(ワンドリンク注文してください)
場所決め等で手間取っている間に席が埋まりつつありますが、もう少しだけ余裕が。
申込み等は、案内ページの方で、よろしくお願いします。
SlideShareでご覧いただけます。
このようなストーリーと、社内Wikiならではの要・不要を検討したい機能として「Wikiファーム」「Wikiポータル」「WYSIWYG」「アクセス管理」「履歴管理」を挙げて、まとめました。Wikiは基本的には、個人作業やグループワークにおいて便利なツールで、しかも設置は容易です。このため、企業にはボトムアップで、非公式に持ち込まれていきます。
こうしたWiki上での作業は、作業過程でのメモや書きかけのもの、使用しないと決めた情報など、様々な情報の蓄積を生み出しますが、ナレッジとして利用されるには各Wikiをイントラネットとあわせて横串で検索できる仕組みなどが必要です。
一方で、アクセス可能であるという時点で、予期せぬ情報の漏洩減となる可能性があります。これを踏まえて、企業の立場ではWikiを「LAN上のどこか」から「公認のイントラネット内」に集約する必要があります。
これは、Wikiに限らず、情報収集過程を蓄積するSBS、これまで公開されなかった知見を蓄積するBlogなど、Web 2.0ツール全般に言えることです。これらを公認・集約して、セキュリティ・コントロールを取り戻すこと、ナレッジを蓄積・拡大するプラットフォームとして統合することが必要です。一言で言えば、Enterprise 2.0のプラットフォームの構築を、トップダウンで行う必要があります。
なお、社内Wikiについては昨年の春から検討をはじめて、早1年半になります。この間に、株式会社シャノン様、TISの倉貫様、NECの福岡様、enNetforumの遠山様、マッシュアップペディアの中津川様、技術評論社様、他多くの方々にお世話になりました。今後とも社内Wikiについての活動は続けていきますが、一つの区切りでもあり、ひとまずこの場でお礼申し上げます。