議事録担当： Web2.0部会
メタデータ株式会社 松田圭子
■日時：2008年2月6日(水), 13:00- 16:30
■場所：池袋サンシャインシティ文化会館709号室（PAGE2008ジョイントイベント）
■参加者：XMLDB：９名、Webサービス実証：６名、Web2.0：１０名 （重複有；総計２１名）
■アジェンダ
Welcome! (一言 )
各部会ごとの議論 30分
本プロジェクトの経緯の簡単な説明（＋質疑）
・インフォテリアc2talk.net、OnSheetをAPIや機能部品を中心に紹介
３部合同：デモ、各部会議論のブリーフィング
３部合同：コンテンツとそのマッシュアップ案
３部合同：要素技術、利用API、技術的討議
３部合同：役割分担の確認
分担の原案：
・XMLDB部会：機能要件、コンテンツ・ＸＭＬデータの提示。
・Webサービス実証部会：APIの作成。（＋スクレイピング）
・Web2.0部会：UI設計、マッシュアップアイディア。
ご参考（一部）：
「10の破壊的トレンド」（1/10のWeb2.0部会で紹介）の主要記事と、画期的サービスのURL集：
http://hiroyoshi.wordpress.com/
■合同部会議事録
★本プロジェクトの経緯
発端：XML ConsサイトのPDFコンテンツを便利に検索できるシステム案をXMLDB部会で設計検討。
↓
XML Consサイトのデータを再活用した新Webサービスの試行
・より自由な方針で、部会合同ならではの技術でやれることに挑戦する
・サイト更新プロジェクトとは別物
・公開は発表時に見せる程度、Web上設置はしない
可能なら今日疎結合のしくみを決めたい。
アウトプットイメージ 何がでるか。
動くものを作ってもよいしRFPの雛形でもよい（疎結合でやるのはたいへんか）
データやりとりのインタフェースだけ決めておくのでもよい。
部会ごとに成果物が違ってもいいかもしれない
コンテンツは：
メインになるのは過去イベントの記録、資料、セミナー資料
今後のイベント情報
MLは？（保存されてないかも）
www.archive.org や事務局にデータあるかも
現サイトでの課題：
検索機能
たどり方がわかりにくい
★３部合同：デモ、各部会の議論のブリーフィング
～討議
○[スクレイピング]メタデータ 松田
Yahoo!pipesのfetchpage機能を使った簡易スクレイピングデモ
表形式のページ（セミナー記録）からRSS形式でデータを取り出す。
→配置を元にしたデータ取出しのため意味づけは別途作業が必要
日付、話者名などの切りだしも今回は特にしていない
このデモの準備作業にかかった時間は30分程度と手軽である
関連議論：
ドキュメントの量によりスクレイピングが適切かは変わる。
結果を見ると完全自動化は難しそう。表の同一カラム内に複数の意味のデータ
（人名は名簿で切り出しておくと自動化できる？）
パターン化されたもののスクレイピングは実装可。
パターンの変化、追加への対応はどうする
アプローチとして、検索結果をタイムライン表示するGoogle機能とかの方法はどう？
ドキュメントの中からメタデータの抜き出しだけをやるという手もありそうだ
日付、名前、タイトルとかを抜き出してくるというアプローチなら実装うまくいきそう
精度を上げるには。
XMLDBにどういう粒度で入れたいか。
→日付、場所、等の取り出しは？
既存のスクレイピング、抜き出し、辞書利用、などの諸方法から
どのような粒度、精度の処理ができるかを検討、技術情報として再利用
WordをXML化してDBに入れてという要望も聞こえる。
Excel, WordなどMSOfficeデータ 構造化してメタデータつけてXMLDB格納したい。
○[OnSheet、c2talk] インフォテリア 甲斐さん
c2talk.netについては、前回Web2.0部会議事録 も参照。
・c2talk.net イベントプラットフォーム
「ぴあ」クリスマスカレンダーに採用された。
c2talkにデータ登録して、＠ぴあで表示するつくり。ほぼ２週間で実装。
c2talkに格納したイベントデータはRSS,ICS,JSONP,独自XMLで取り出せる。
API公開あり。
・OnSheet
http://info.onsheet.net/
http://www2.onsheet.net/tour/api
https://wiki.editgrid.com/wiki/API
Webサービスで表計算機能を提供。EditGrid OEM開発
ブログパーツ機能：表の一部やグラフをgadget的に呼び出せる。
表示形式、表示範囲等が自由度高く設定できる。
パーマリンクでグラフをリンクして、データ内容が変化すれば追従する
マイデータフォーマット機能：
ワークシート内のデータに対してXSLTをかけて希望の形式で表示。
デザイン指定が細かくできる。
API提供も。Googleカレンダーへのマッシュアップも可能
シートの共有、マージは
（複数の部署のシートからの内容を一覧できるようにしたいができるか）
APIを利用すればできる。内部のマクロでは該当機能はない。
OnSheet Pipeline機能 （OnSheetに限らず利用できるデータ加工機能）
Excelからのデータをほぼ同じインタフェースで使える。
セルへのタギングはできるか？1行目を項目名として扱うとか、、
→現状では自動対応していない
データの置き場を社外にしたくない場合対応できるか→設置方法は状況による。
データインポートは？Excel、csvほか数種類
関数もそろっている。
リモートデータ機能：
株価ほか、URL指定して簡易スクレイピングで１セルを埋めることができる
Sun×リクルートのMA4にAPI提供するかも
○[DB部会ブリーフィング]（ジャストシステム 加藤さん）
当プロジェクトの概要、分担検討。
詳細は資料参照。
当プロジェクトの目的：次世代Webサイトのフューチャを一般に提示
html > xhtml > XMLDB
資料 > テキスト抽出 > XMLDB
属性検索・前文検索、タグ付け>構造変化
タグを埋めてからxhtml化できるとよいが。
データをみんなで直す？
付加価値は？
検索（属性検索）はもちろん、マッシュアップによる
参照回数、拍手タグ、評価、Thankyouポイント（一般ユーザ）
XQuery、必要なタグだけの取り出し、ソーティング
いくつかのレイヤでXML処理、検索
動画も扱いたい。→ニコニコ連動？
関連議論：
機能要望
・検索させずに検索できる（別のなにかでトリガー）
・KnowWhoやりたい
プロフィール見たい（所属部会、動き、関連資料）Google検索とMUとか
・タイムライン、イベントカレンダー
・属性検索「タイトルに"Python"と入ってる」
・どういうタギングにする？
検索したユーザがタギングするか。
→タグクラウドつけるか。
・検索用語にタグのオートコンプリート
ただのキーワード、タグを自由につけられるだけでなく
項目名：値 を自由に（その場で）つけることがXMLDBならできる。
上記はスキーマ変更なし。
さらに、スキーマ変更も自在にできる点もアピールしたいが。
・ファイルアップロード機能（画像など）は？XMLDB内に直接埋め込む手もある。
・スキーマ編集やデータ編集にxfy使う手も。
○[XMLConsサイトからXMLDBにして扱うデモ]東芝ソリューション 矢野さん
現状のサイトではPDFの内容について検索できない。
手動でXML（HTMLからとってくるのは現状は課題。XHTMLに期待）を作成した。
ヘッダ：タイトル、日時
ボディ：PDFからテキストを取ってきて入れてある
このXMLDBに対する検索動作のデモ。
イベント、セミナー更新の際のフィードができる
属性での検索（検索結果もフィード）が可能
関連議論：
・コンテンツにないキーワードへの対応ができないか
DB側がキーワード辞書を持っておく手も。
・クライアント側で検索時に「使わないキーワード」指定も？
（Googleで現状でもできる"-"指定機能）
・どのようなDB構造になっているといいか。
→タグは決めない方針もありえる
・人名切り出しは実験中（６～８割までは順調にできる、その先のチューニングは大変）
→ユーザがルールを補完する仕組みがほしい。
使いながらコンテンツを洗練、しくみを補完させる方針はどうだろう
→ユーザからのレスポンスを入れる方式がいいか（Wikipediaのように）
→恩恵が返ってくるしくみ、インセンティブがあれば動くか。
タグはその方針が機能しそうだが
内容、コンテンツ自体の補完はニーズがないか。
サイト更新の必要性か、チャレンジ課題か
・全文検索結果を属性別で（どの属性に該当データがあったかで分類）表示する方法も
部会タグ：内容を見て部会を判断する など。
・はじめからタグがある方針？
・検索結果が部会に該当する場合はそれを示すという方針
★役割分担の確認
ゴールイメージ：
３部会の成果を繋げて「動くもの」を作りたい。（一部はりぼてでも可）
（Week時点ではオンラインで一般公開はしない、最先端技術を組み合わせたWebサービス）
RFPや、そのままある程度責任もって顧客に提案できるアーキテクチャを見せたいとの意見もあるが、
従来、試作結果を事実(fact)としてプレス発表したものと違い、リスクが考えられる。
（会員企業の裏書endorsement付きの仕組み！？と誤解されない配慮が必要）
DB部会→基本的には、できたものを渡すスタンス
既存サイトから取り出したものを格納、件数は未定
（スクレイピングの評価は部会内で方針きめることとする）
持たせるメタ情報は？ユーザ要求によって項目が違うのでは
今決めなくてもほかの部会が動けるか？
まずシンプルに作って要望あれば対応の方針
→スキーマ自体が「ない」DB、なんでもあり形式にする
問題が発生しそうなのはスクレイピングまわり
XQueryでアクセス？
JDBCのインタフェースでXMLDBにアクセスできるか？
DBとWebアプリ別にサーバを。
実証部会：ビジネスロジック実装；Webサービス３種
（SOAP、なんちゃってREST、RESTfulの実装コスト評価）
Web20部会：Webアプリの実装（RESTfulを使うか）
（話題に出たのでメモ：popflyはwsdl対応している）
マッシュアップはどのレイヤーでするか？実はどれも可。
・MashupHUBはDB側のアプリサーバ層でマッシュアップしている
・Webサービスアプリサーバ層でマッシュアップする方法もある
・Webクライアントでマッシュアップする方法もある。
XMLDBのアプリサーバとWebサービスのアプリサーバを
両方使うのは無意味か？
ビジネスロジックの組み込みは、XMLDBのアプリサーバでは難しい。
実証部会が担当するWebサービスのアプリサーバが
XMLDBに対してクエリを投げる方針で進めよう。
担当は以下のようにする。
DB部会：DBとDBサーバ、データ入れる、クライアントライブラリを渡す
（範囲と期間の確定が必要なベンダもある）
IBM 東芝ソリューション （サイバーテックも可）
実証部会：Webサービスアプリサーバ層
Web2.0部会：Webクライアント層
----
★★ 次回について
Web2.0部会
日時：２００８年２月２９日（金) １４：００～１６：３０
場所：キヤノンソフト情報システム 東京支社 タカセビル９階 セミナールーム
地図：http://www.canon-js.co.jp/company/map_tokyo.html
議題候補：
合同プロジェクトの実装案
他
----
以 上