データクオリティパネル クロディア・ミューラービン、 ルーカス・ウェアミニスター ホゼ・エミリオ・ラビラ・ガヤ、 クリスティナ・サラスナ、アンドレア・ データクオリティパネルの皆さん こんにちは 多くの人が私たちのデータが正しいことを 頼るのでデータクオリティは重要です だからデータクオリティについて 話し合いましょう 4人の講演者は データクオリティについて短い紹介をし その後で質疑を行います ではまずルーカスから ありがとう ルーカスです まずウィキデータに既にある データクオリティツールと 開発されていて公開マジかなものについての 概要から始めます いくつかのテーマの グループに分けました エラーを見つけやすくする 問題に対処しやすくする データにより検証し 問題に気づきやすくする 一般的なエラーの元を修正する 既存のデータの質を維持する そして人によるキューレーション そして現在利用可能なものは プロパティの拘束からです ウィキデータで これを見たことがあると思います このような 内部のデータの均一性をチェックする アイコンが出ることがあるでしょう 例えば あるイベントが他に続くなら 他のイベントもこのイベントに 続くべきです このWikidataConの項目では それが見られません この機能はできてまだ数日かも しれません あるいはこれが制限しすぎだったり 簡単すぎなら Query Service を使って チェックを自分で書くこともできます もちろんQuery Serviceは 多くのことに有効ですが エラーを見つけることもできます ひとつ間違いを見つけたら 他の場所もチェックし 他の人が同じエラーをしていないか Query Serviceで見つけられます あるいは２つを組み合わせて 拘束違反を Query Serviceで探せます 例えば ある部分にだけあるエラーや WikiProjectの あなたの関連した部分だけのエラーなどです でも残念なことに その結果は現在のところ完全ではありません 改訂スコアリングもあります これは最近の変更からだけ思いますが 自動アセスメントのウォッチリストに入れて その編集が誠実なものかどうか また被害を与えるものかどうかを 見ることができます これは2次元だと思います だから被害を与えるけど 誠実なものかどうかに注目して 特に友好的な気分なら これらの編集者に 「貢献してくれてありがとう 次回はこのようにしてください」など… でもそうでなければ 誠実でないものや 被害を与えるものを 元に戻すこともできます 似たものに エンティティ・スコアリングがあり これは変更が加えられた 編集をスコアリングするのはなく 全体の改訂をスコアリングします これにはリディアは会議の当初に 話したのと 同じ質の検証が使用されると 思います このユーザースクリプトで これらの１から５のスコアを与えます これは現在の項目のクオリティだと 思います １次資料ツールは すべてのインポートしたい、しかし 直接ウィキデータに入れられる質でない データベースのためのものです だからこれを１次資料ツールで 処理し それから実際に人が判断し 個々のステートメントを 加えるかどうかを決めます 座標を地図で示すことは とても便利な機能ですが クオリティコントロールにも 有用です これがウィキデータ・ドイツの オフィスのはずで 座標がインド海の中にあれば 何か間違っていると気が付きます 単に数字を見るより 簡単にわかります これは 相対的完全性 インディケータというガジェットで この小さなアイコンで示され その項目が完成しているかどうか あるいはどのプロパティが 欠けていそうかを示し 項目を編集しているときに便利なもので もし馴染みない分野で 使うべき正確なプロパティが わからないときには とても便利なガジェットです Shape Expression があります アンドレアかホゼが これらについてお話すると思いますが 基本的には 持っているデータをそのテーマに対して 比較するためのとても有効な方法です どのステートメントが 特定のエンティティを持つべきか 他のエンティティがリンクされるべきか どのように完成されるべきか それによって間違いを見つけることができます えーと これですね Integraality または プロパティ・ダッシュボード 既にあるデータの概要を示します 例えば WikiProject Red Pandaの このフォームで ここにほとんどすべての赤パンダの 性別があるのかわかります 誕生日はどこの動物園かによって かなり変わります 亡くなったパンダは ほとんどいないですね よっかた かわいいからね これはとても便利です そしてOKすると 次に出てくるのは ウィキデータ Bridge クライアント編集として知られているものです ウィキピディア Infobox から ウィキデータを編集します これによりより多くの 閲覧がなされます なぜならもっと多くの人が これらのデータを見るからです これによってウィキピディアでより ウィキデータが使われるようになるでしょう そしてもっと多くの人に気づかれるように なるでしょう 例えばデータが古かったり 更新が必要なときは ウィキデータ自体だけで気が付かれないことを 知ることができます Tainted Referencesもあります これはステートメントの値を編集すると タイポなどを直している場合は 別として リファレンスも更新することがあるでしょう このTainted Referencesは 編集している人にそれを示す他に 他の編集者にも他に どのような編集がされたか示します ステートメントの値が変更され リファレンスが更新されているいないを知り それらを修正するか どうするかを決めることができます もっと修正を入れるか そのままでリファレンス更新は 必要がないとか… これはSigned statementsに関して データの提供者が心配する… UNESCOかなにかが参照された ステートメントがあり 突然 誰かがそのステートメントに 損傷を加えたら UNESCOなどの機関が その損傷されたステートメントを 出したように見られる恐れがあります だからSigned statementsは 暗号的にこのリファレンスに サインを入れることができます 編集を防ぐことはできません でも少なくとも 誰かがステートメントを損傷するか あるいは編集したりすると サインは無効になります そしてそのステートメントが その機関が入れたものでないとわかります もし正しい編集なら そのステートメントを 再度サインすることができます または編集しなおすことができます それから 素晴らしいものとして Citoidがウィキデータにはあります これにはURLを貼り付けたり 識別子 またはISBN ウィキデータIDなど 基本的に 何でもVisual Editorに入れられ きれいにフォーマットされた リファレンスを作成し それにはすべてのデータが含まれていて とても使いやすいです それに比べてウィキデータでは リファレンスを入れたければ リファレンスURLとタイトル 著作者名 出版元、出版日 改訂日などを少なくとも加える必要があり とても厄介です ウィキデータにCitoidを統合することで それが簡単になります 私は以上です ではクリスティーナに渡します （拍手） クリスティーナです チューリッヒ大学の研究員で スイスのコミュニティの 活動者でもあります クラウディア・ミューラーと私が WikidataConにこれを提示した際 期待したことは 今年の始めに データクオリティのワークショップや その他のウィキマニアのセッションで 始めた議論を継続していくことです 今日の講演は基本的に コミュニティと私達が 集めた考察を提供し 会話を続けていくことが目的です これからみなさんと交流を 続けていきたいと思います 私達がもっと重要と思うのは コミュニティの様々なユーザーに 何が必要か そしてデータクオリティの 問題が何かを問い続けることです 編集する人たちだけでなく コードを書く人や データを利用する人 また何が起こったか編集履歴を 実際 利用する研究者など すべてのユーザーを含みます ウィキデータに存在する約80の ツールを評価し それらを異なったデータクオリティの次元で 整理しました 実際に気がついたことは 多くのツールは 完成性をモニターしていて 実際…インターリンクを 可能にするものもありますが 多様性を検証するツールが 欠けていて これは実際ウィキデータに 特にウィキデータのデザイン原則に 組み込めるもののひとつで 多様性をもたせ 異なった出典からの 異なった値の 異なったステートメントを含めます これらは2次資料になるので 実際どれだけの複数の ステートメントがあるか どのように どれだけを向上できるか等を 示すツールはありません また多様なステートメントが存在する 理由もよくわかりません だからこれらのコミュニティでの ディスカッションから まだ注目すべきチャレンジが 浮き上がってきました 例えばこれらのクラウドソーシングの コミュニティがあることは データやグラフの異なった部分に 取り組む異なったグループの人々がいて また異なったバックグラウンドの知識を 注ぎ込まれるという利点がありますが 実際は異なった人々が 異なったプロパティを異なった方法で使い エンティティの識別子に 異なったものを期待するので 何か均一なものに整えるのは 難しいです グローバルな状態を捉えるための ツールがもっと必要だと いう声も聞かれました どのエンティティが 完成性の点で欠けているか また人々が現在 どのような作業をしているか そして異なった言語間のみでなく かつそのWikiProjectと 異なったウィキメディアの プラットフォームに渡る 緊密な共同についての 言及もありました これらのディスカッションからの すべての書き留められたコメントを Etherpadのここのリンクに またウィキマニアのウィキページに 公開しました いくつかの解決策は 実際 異なったWikiProjectで 開発された最善の実践方法を 共有する方向へ向かうように見えますが チームでの仕事を整理し 少なくとも誰が作業をしているか 理解できるツールも求められています またもっとショーケースが求められ よりよい方法でそれらを作成できる テンプレートが求められています 自治体オープンデータの組織との コンタクトを通じて そして特に チューリッヒ市と州と接していると ウィキデータに興味が持たれている ことがわかります つまり誰でもアクセスして データを見ることができる場所で データを皆に提供したいからです だからその目的に沿うには 何かのクオリティの識別子を持つことが とても気が惹かれるでしょう ウィキでは既にありますが また SPARQLの結果にも それらがあると良いでしょう そしてそのコミュニティからの結果が 信頼できるかどうかわかります さらに持っているデータのどの部分が ウィキデータに有益かが理解でき そしてそれらを自動的に 評価するツールが求められます またデータをインポートするべきか リンクするべきかを決断する ある種の手法かツールも必要です 場合によっては 自分たちのリンクのある オープンデータセットを持っている場合 データを入れるべきか ウィキデータへデータセットから リンクを作るべきか あるいは逆方向にするかなどが あるからです またウィキデータのどこにウェブサイトが 参照されているかを知りたいです Query Serviceでそのような クエリを行うと タイムアウトになることもあるので もっとツールを作り これらの質問の答えが 得られるようにすべきです それ以外にも ウィキ研究者はしばしば 編集サマリで情報が 欠けていることがあります 様々なエディタの挙動 ツールやボット あるいは匿名のユーザーなど 理解する作業したとき 私が覚えていることは 例えば使用されたツールを 追跡する標準の方法などが 欠けていたことです PetScanなどそれを既に行うツールも いくつかありますが このようなキメの細かい起源を どのように記録するかについて コミュニティで検討するべきでしょう さらに リンクされたデータに関するけど すべてのタイプのデータに関しない より強固なデータクオリティ次元を 考慮する必要があります リンクで可能にされる 情報取得（Information gain)を 調べてみました つまり ウィキデータを他のデータセットに リンクする際に どれだけのエンティティが 実際クラシフィケーションに得られるか あるいは記述や また使用されている単語などが得られるかも 考えるべきです 簡単な例を挙げると… この場合 ウィキデータ あるいはウィキデータにリンクされた 外部のデータセンターで ナターシャ・ノイと呼ばれる 人のエンティティがあり 所属やその他の情報があります これでOKとして 外部にリンクし そこにその名前のエンティティが既にあり 実際同じ値を持っているとします よりよい方法は 別の名前をもつものにリンクします このひとは2通りの方法で 名前を書くことができるので有効です あるいはウィキデータにない 他の情報や 他のデータセットにない情報を 持つことができます もっとよい方法としては この情報を分類する新しい方法を持つ ターゲットデータセットを 見ることです これが人であるのみでなく 他のデータセットでは 女性であるとかなど 他の分類も言及できます もし他のデータセットで もっと多くの単語が使われていれば 全体の情報を回収するものの 助けにもなります それに関してさらに言えることは フェデレーションクエリーが よりよく行われます マリーシェフ達による クエリーログを見ると オーガニックなクエリーから フェデレーションクエリーは ほんの少ししかないことがわかります 実際フェデレーションはリンクされた データを持つ主なる有利な点の一つでなので コミュニティや ウィキデータを使う人は この例がもっと必要でしょう 使用されたエンドポイントを見ると… これは完全なリストではなく もっとあります もちろんこのデータは2018年３月までの クエリーを評価していますが フェデレーションエンドポイントを見ると それらが使用されているかどうかを 見るべきです 後のディスカッションで使用できる 参加者の皆さんへの２つの質問は あなた達の必要に応じるための データクオリティの問題は なんであるか そしてまた編集や警衛のために 必要な自動化は何かということです 以上です ありがとうございました （拍手） （ホゼ・エミロ・ラブラ） 私が話すことは Shape Expressionに関連し 私達が開発しているツールです 私はホゼ・エミロ・ラブラです これらのツールは異なった人によって つくられました 主にW3C ShEx, Shape Expressions コミュニティグループに関連しています ShEx コミュニティグループです まずお話したいのは RDFShapeで これは一般的なツールです なぜなら Shape Expressionsは ウィキデータのためだけでなく 一般的に RDFを検証する言語だからです これは私が主で開発したもので 一般的にRDFを検証するツールです RDFについて学習したいとか ウィキデータでのみでなく RDFやSPARQL エンドポイントを 検証したいなら このツールをお勧めします また学習については 私は大学で教えていて RDFを教えるにはセマンティクな ウェブコースでそれを使っています だからRDFを習いたいなら これはよいツールだと思います 例えばこのツールでの RDFグラフの可視化です ここへ来る前 先月 ウィキデータ用に特に RDFShapeを分岐し始めました これを WikiShapeと呼んで ウィキデータのプレゼンで紹介しました 行ったことは ウィキデータに関連しないものを削除して ウィキデータ SPARQLエンドポイントなど 幾つかのものをコードに書き込みました ウィキベースにもできるかと 聞かれましたが ウィキベース用を作るのも とても簡単にできます このWikiShapeツールは 新しいもので ほとんどの機能は働くと思いますが 機能しないものもあるでしょう 使ってみて向上させたいと 思われた方はご連絡ください これは［不明瞭］キャプチャですが やってみましょう 動くかどうかみてみましょう まず外に出て… ここ ここにツールがあります このツールでできることは 例えば スキーマ エンティティスキーマの検証です ここに新しい名前空間があり Eの何か… 例えば「human…」と書けば 書いていく間に補完されるので チェックすることができ 例えば 人のShpae Expressionは ここにあるShpae Expression です このエディタには シンタックスが色付けされています これは… 画面が小さいので 大きくしてみましょう 見やすくなるでしょう これがエディタで シンタックスが色付けされています このエディタは ウィキデータ Query Serviceと 同じソースコードからできています 例えば マウスを乗せると 異なったプロパティの ラベルを表示します ウィキデータのエンティティ スキーマは単なるテキストアイデアなので とても便利だと思います このエディタは補完機能があるので よりよく また… 例えば拘束を加えたければ 「wdt:」と打って 「author」と書いて Ctrl+Spaceと打てば 異なった物を提供します これはウィキデータの Query Serviceと似ていますが これはShpae Expression特定のものです なぜならShpae Expressionの作成は SPARQL クエリーを書くより 難しいものではないと思うからです 同じレベルだと思う人もいるでしょうが 私は多分はより簡単だと思います なぜならShpae Expressionは簡単に 機能するようにデザインされているからです これが まず最初の Shpae Expressionのための エディタです そしてまた例えば 簡単に可視化できるでしょう Shpae Expressionがあって 例えば 「written work」は よい Shpae Expressionでしょう 異なった物の間に 何らかの関連があるからです これは 「written work」の UML可視化です UMLでは 簡単に異なったプロパティを見れます これを行った際 何人かの Shpae Expressionに 間違いがあることに気がつきました 何が欠けているプロパティかなどが 簡単に見つけられるからです そしてもうひとつの可能性は 検証ができることだと思います どれかのラベルにあったと思います 閉じてしまったかも… でも例えばここValidate entitiesを クリックできます 例えば 「q52」そして著者である「e42」 「human」で… 「human」でできると思います… そして SPARQLクエリーをしているので 少し時間がかかっています この例はネットワークのせいで 機能しませんが 自分で試してみてください では他のツールのプレゼンを続けましょう 試したい方 フィードバックが欲しい方は 連絡してください プレゼンを続けます これが WikiShape です 既に言いましたが Shpae Expression エディタは GitHubの中の独立したプロジェクトです 個人のプロジェクトで使用できます Shpae Expression ツールをしたければ 任意のプロジェクトに 入れ込めばいいだけです これはGitHubの中にあるので だれでも使えます 私の生徒である同じ著者がさらに 作ったShpae Expression用の エディタがあり ウィキデータ Query Serviceに 影響されたもので 欄の中に SPARQLクエリーの より可視化されたVisual editorがあり このようなものを入れることができます これはスクリーンキャプチャです これはテキストの Shape Expressionであることがわかりますが これはフォーム形式のShape Expressionで ちょっと時間がかかります 異なったフィールドに 異なった行を入れることができます そして ShExEr があります オビエド大学の大学院生が作ったもので 彼がここに来ているので ShExErを紹介します （ダニー）ダニー・フェナンデスです オビエド大学の大学院生で ラビラと一緒に仕事しています 時間が迫っているので 急いでやります デモはしないで スクリーンショットを出しましょう Shape Expressionや他のShape言語で 作業をする通常の方法は 内容領域専門家がいて 先験的に グラフをどのようにするか 構成を定義し その構成を使用して 実際のデータを検証します ラビラが紹介したもののと同様に このツールは 一般的な任意のRDFソース用のツールで 逆方向にデザインされています 幾つかのデータが既にあり Shapeを得たいノードを選択し すると自動的に抽出また Shapeを推測します これは一般目的のツールですが WikidataCon のためにしたことは これらの優れたボタンです クリックすると起こることは たくさんの構成パラメータがあり ウィキデータエンドポイントに対して 機能するようになっています 失礼 このボタンを押せば 基本的にこれが得られます どのような記述が欲しいか またクラスのインスタンスなど 探しているものを選択した後 自動的にスキーマが得られます どれだけのモードが実際使われているかで すべての拘束が整理され あまり共通しないものを 取り除くことができます このポスターが下に掲示されていて 私は今日はこのあたりに 一日中いますので このツールに関心のある方は 声をかけてください ではラブラにマイクを返します ありがとうございました （拍手） （ホゼ）では次のツールにいきましょう これは ShapeDesignerです アンドレア ShapeDesignerを ここで紹介しますか それも後でワークショップで 紹介しますか ワークショップがあるので… 午後 特に Shape Expressionのための ワークショップがあります もっと実際に行い ShExを練習したい方は そちらへお越しください このツールは ShEx… エリックがいます 紹介してくれますね （エリック）簡単に言いたいことは すでに ShEx のインターフェイスは 見たことがあるでしょう これはウィキデータ用のものです 不要なものを除いた ウィキデータ用のものです 一般的なものにはもっと機能がありますが 言っておきたいことは ウィキデータのスキーマを デバグするための 特に有効な機能です Slurpのモードを選択すると 行われることは 検証中に すべての３つ揃いを取り出したいとき つまり多くの失敗が返ってくると これらを見て どの３つ揃いがここにあり… 失礼 ３つ揃いはこの下です これは行われたことのログです ここでリアルタイムで いじることができます 動かしてみたり 変えることができます 素早くできるバージョンです これがShExのフォームで シャヒーンがドキュメントのためには Shape Expressionによって ウィキデータのドキュメントを 埋めるに役立つだろうと 示唆したものです ウィキデータ用には つくられていませんので これはあるスキーマがあるとき そのスキーマを特定の方法で 描画したいということを注記でき そのフォームを作成し データがあれば そのフォームを埋めることもできます PyShExは素晴らしいです （ホゼ）これが最後だと思います 最後はPyShExです PyShExはShape Expressionの Pythonインプリメンテーションです お好きな方は Juyiter Notebooksでも 使えます それだけです （拍手） （アンドレア）私が関与した 特別なプロジェクト Gene Wikiについてお話します それで私達もクオリティの問題を 対処しています そのクオリティについて話す前に Gene Wiki とは何か ちょっと紹介します このプロジェクトの詳細を説明する 論文を最近 書いてちょうど その出版前のものを公開しました 写真を撮っている方もいますが 基本的に Gene Wikiは 生医学のデータ 公開されたデータを ウィキデータに入れるもので ウィキデータに入れるには 特定のパターンに従っています 新しいレポジトリや データセットが手に入ると それがウィキデータに含まれるべきものなら まず最初にコミュニティによる関与です 直接ウィキデータのコミュニティで ある必要はなく ローカルな研究コミュニティによる 関与です オンラインかなにかの方法で会い データモデルを想像します これによりデータを ウィキデータモデルにつなげます 去年のワークショップの 写真がここにあります 特定のデータセットを 見ようとしています たくさんの論議があり schema.org とその他の 存在するオントロジーに揃えています そして最初のステップの終わりに ウィキデータに入れたい スキーマが描かれています ここにあるものは 平素です この後ろにあるのは 今日のパネル内でも 幾つかのスキーマを作れます スキーマができれば 次のステップは スキーマを機械可読にすることです ウィキデータの入れる生医学の データベースから持ち込むデータを つなげる起動可能なモデルが ほしいからです ここで Shape Expressionを 適用しています Shape Expressionは データデットが実際… まず 既にウィキデータに存在する データが同じデータモデルに従っているかが 先ほどのプロセスで達成されます そして Shape Expressionで このトピックのウィキデータのデータが 修正が必要化どうか ウィキデータの中のモデルに 当てはめるに必要な操作があるかなど 検証します それが整ったら ボットを書き始め ボットは定期的に 情報を入れています これがウィキデータに入れられる １次資料です ボットが出来上がったら… これらのボットは 私たちのプロジェクトで作られた Wikidata Integratorと呼ばれる Pythonライブラリの プラットフォームで書かれます ボットが書かれたら 継続的インテグレーションのために Jenkinsというプラットフォームを 使用します Jenkinsでは ウィキデータを１次資料で 継続して更新できます これが先に話した論文のダイアグラムです これが現在の状態です このオレンジの箱が 薬物 遺伝子 疾患 作用する化学物質の １次資料で このモデルは小さくで見にくいですが これがデータベースで ウィキデータ内で管理される資料で １次資料とつながっています これがワークフローです 私達のパートナーのひとつは 疾患オントロジーです 疾患オントロジーは CCOオントロジーで このCCOオントロジーはそれ自身の キューレーションサイクルを持っていて 疾患の領域に合わせて また疾患の解釈に応じて 継続的に疾患オントロジーを 更新しています ウィキデータにも疾患に関する キューレーションサイクルがあり ウィキデータコミュニティでは ウィキデータで常にモニターしています 私達には２つの役割があり 口語的にこれらを ゲートキーパーキュレーターと呼んでいます これは私と同僚が５年前に コンピュータの前に座って ウィキピディアとウィキデータをモニターし もし１次コミュニティ １次資料へ 連絡される問題があれば インプリメンテーションを調べ 決断を下します このウィキデータの入力を信頼するかを見て そして考慮されたら このサイクルに入り 次のイタレーションは 疾患オントロジーの部分で ウィキデータに入れられます WikiPathwayでも同じことをしています WikiPathwayはMediaWikiに触発された 経路のリポジトリです 同じ様にウィキデータには既に 異なった経路が存在します これらの経路のリソースの間で 一致しない場合は それがゲートキーパー キュレーターから コミュニティに連絡され 個々のキューレーションのサイクルは 維持されます もし以前のサイクルを覚えていれば ここでは２つのサイクルと ２つのリソースのみ話しましたが すべてのリソースに対して 行う必要があり 何が起こっているかを管理しなくては なりません キューレーションというのは ウィキピディアのトップページに行き ウィキデータのトップページに行き それをやることです これは持っている２つのゲートキーパー キュレーターから拡張できません 2016年の会議のとき エリックがShape Expressionのプレゼンをし 私もこれをやろうと これでいいぞと思いました Shape Expressionはウィキデータ内の 違いを検知する助けになるので ゲートキーパーがより効果的な レポートを出せます 今年 スキーマエンティティに 感激しました なぜならそれらのエンティティスキーマを ウィキデータ自体に保存できるからです これは以前はGitHubに保存されました ウィキデータのインターフェイスと 揃えられ ドキュメントのディスカッションができたり また改訂もできます トップページとウィキデータの改訂を 利用して ウィキデータに何があるべきか １次資料が何かについて ディスカッションできます エリックがプレゼンしたものは 既にとても有益です ここにヒト遺伝子のための Shape Expressionを作り 簡単なShExを通して使ってみました ご覧の通り 既に… ひとつモニターする必要のある 問題があります スキーマに合わない項目が ひとつあります これには既にスキーマエンティティ キューレーションのレポートが作られ 異なったキューレーションの レポートへ送ります ShEx.js は 構築されたインターフェイスで ここに戻ってみると… 10 だけやってますが 何万ものあるので これもうまく拡張しません だから Wikidata Integratorは SgExサポートにも対応し そして項目のループをループすることができ yes-no yes-no そして真−偽 真−偽と 行えます そしてまた レポートの対処の効率を向上します でも最近 ウィキデータの Query Service上にビルドされ 今 絞り込んでいるところですが 同様にこれも拡張しません どのようにウィキデータのモデルを扱うかは 継続している課題です ShExは巨大に感じるものであるだけでなく その規模は扱うには大きすぎます だから最初の概念の証明 あるいは演習を始めてみました yEDというツールを使います これらのShape Expressionをまず描き… そしてこのスキーマを Shape Expressionの隣接する フォーマットに再生しました だからこれは既に Shape Expression言語に尻込みする 聴衆者でも使用できます しかし実際 これらの視覚識別子には問題があります なぜならここに誰かがすでにyEDに描いた スキーマであるからです ここにも別のものがあります これが使っているのは…綺麗ですね これは壁にかけたいですが 相互運用可能ではありません 私の講演の終わりに このスライドを借りていますが 視聴に来てくれている彼に 感謝します これが大好きです RDFは複雑で鬱陶しいと思われていますが 現実はもっと悪く これはとても簡単です なぜなら現実のデータの問題は 実に複雑です RDFを避けることはできますが 複雑なデータやコンピュータの問題を 避けることはもっと難しいです これはRDFについてですが これはモデリングにも当てはまると思います 私の講演のポイントは どのようにモデリングをやっていくか？ ShEx または 視覚的モデルを討論すべきか… いかに継続していくか？ ご視聴ありがとうございます （拍手） （リディア）ありがとうございました 前に来てください 質疑を始めます 質問は？ はい カメラのためには… （リディア）ええ （参加者１）クリスティーナへの質問で 他のシステムとのリンクで 「情報取得（information gain)」 という言葉を使われましたが 統計と確率に使われる 情報理論の計測に使われる information gainという言葉がありますが… 同じ… 確率理論からの 情報理論からの information gainと同じ計測を 意味しているんですか それともなんからの方法で 情報の取得を測る概念的な意味ですか いいえ実際 シャノン エントロピーを使って インプリメンテーション測定を 定義しているので それを意味します 詳細な式の説明は避けたかったので… （参加者１）はいわかります だから質問したのです （参加者１）ありがとうございました （参加者２）質問というより コメントですが… （リディア）どうぞ （参加者２）クオリティや完成性について 項目レベルに気が配られていますね 私が気になることは同じことが 階層に適応されていないことで 階層が的確でないという 問題があると思います コモンズ検索や他のことで これが問題になると思います できることのひとつは 外部の… 外部の類義語集が その階層を構成する方法として P4900 広範な概念修飾子を使って しかしもっとよい役に立つツールと 思うのは それによって外部の… 類義語集の階層マップを ウィキデータの項目にインポート できるようになります これらのP9400 修飾子と置かれれば 外部の階層から派生した階層を見ることが SPARQLを通じて 実際よりよいクエリーでできます 例えばポーラ・モーマは PKMを使いご存知のように ファッションの仕事を多くしています それを使って私達は ヨーロッパファッション類義語階層と ゲッティAATファッション類義語階層を 取り入れ そして私たちにとって 実に問題となる 高レベルの項目のどこに ギャップがあるか見てみます なぜならしばしばこれらはウィキピディアの 曖昧性解消ページにのみあるので 階層が欠けている より高レベルの 項目がたくさんあり これは時々クオリティと完成性の意味で 把握しておかなければならないものです しかし実際 私が書いたたくさんのPullスクリプト よりもよいツールは… 誰か Pythonで PAWS Notebook内に リンクされたデータや そうでない 外部の類義語集 そしてその階層を取り それらをP9400値にいれる クイックステートメントに入れることです そうすれば後日 叙述がもっと完全になったとき これらのP9400を更新するために 叙述が更新されるにつれ より密度が上がるので システムのその階層が もっと増えたことを示すように これらの修飾子も変える必要があります 誰かそれをしてくれれば とても便利だと思います また項目レベルのみでなく 階層レベルでクオリティと 完成性を向上する 他のアプローチについても 検索するべきです （アンドレア）付け足していいですか？ 実際にやっています フィンが語彙的データで作った Shape Expressionを見ることを お勧めします 彼はShape Expressionを創り そして著作者表現にビルトしています だからウィキデータの中の リンクされたShape Expressionの構想で 特に 私が正しく理解していれば それはまさに Gene Wikiの中で やっていることです ウィキデータに入れられた 疾患オントロジーがあれば 疾患のデータが入れられ この類義語集に一致するかを知るに Shape Expressionを応用できます またウィキデータに入れる必要のある 他の類義語集や制御された語彙の 他のオントロジーがあります これはまさにShape Expressionが 有用です なぜなら疾患オントロジー用の Shape Expressionが持て Mesh用のShape Expressionが持て そして「じゃあクオリティを調べよう」 ということになります なぜなら制御された語彙がある場合 ウィキデータの内容も このクオリティに沿っているとしても それに同意しない コミュニティもあるでしょう だからツールは準備されていても これらのモデルを作り 異なった ユースケースに適用することになります （参加者２）外部のオントロジーを ウィキデータにマップしたものがあれば Shape Expressionはとても有益ですが 私の問題はそれに至ることです どれだけの外部のオントロジーが まだウィキデータに中に無いか そしてそのギャップがどこになるかを 知るために より使いやすいツールで 欠けている 外部のオントロジーを探すことは とても有益になるでしょう ここでの最も大きい問題は ツールではなく ライセンスです オントロジーをウィキデータに 取り込むのは簡単ですが ほとんどのオントロジーは どう言えばいいか… ライセンスの制御があり ウィキデータには使えません （参加者２）とても多くの 一般使用可能な類義語辞書が 文化の分野にはあります −（アンドレア）話し合う必要がありますね −（参加者２）そうですね （アンドレア）では話しましょう （参加者３）コメントしたいことは ジェームスへの答えになります つまり階層がグラフを作り もしあなたが… 基本的に言いたいことは 階層の共通した問題は サークル階層です お互いに戻ってくるようになり 問題がある際には そのような階層を 持つべきではありません このおかしなことは ウィキピディアのカテゴリでよく起こります カテゴリにたくさんサークルがあります しかしいいことにはこれは… 技術的に言ってこれは PMP完成の問題で グラフを作ると簡単に 見つけることができません しかし多くの開発された方法があり これらの階層グラフの 問題を見つけられます 例えば「*Finding Cycles Breaking Cycles in Noisey Hiearachies*」という論文で 英語のウィキピディアのカテゴリの 問題を助けています これをウィキデータのこれらの 階層に応用することができ 問題になりそうなものを見つけ 支障をきたすものを取り除けばいいです 実際 支障を見つけます これは単にアイデアですが… （参加者２）それはいいですね しかしあなたは存在する 不適切なサブクラスの関係の数を 軽く見ていると思います 全く間違った国に 市を持っているようなもので 地理のツールとして それを見つけるものがありますが 階層に使えるツールが必要です 完全に欠けている国に相当する 項目がどこにあるか また全く異なったものに サブクラスされているものがあるかを 認識するためのツールが必要です （リディア）あなたの言っていることは 私と私のチームが 私達のデータを再利用する人たちから よく聞くことと似ています 個々のデータポイントは適正でも オントロジーなどで見なければ それは… なぜこれが起こるかの もっとも問題となる点は ウィキデータの編集の多くが 個々の項目で起こっていて 項目が編集しています 例えばそのグラフの他の部分への 全体への影響を理解していない ことがあります 個々のローカルでの編集の影響を もっと可視化できる方法について アイデアがある方がいれば 誠実に編集を加える人たちに その影響を見せることができれば これは探求する価値が あると思います わあ では君 そして君 そして君 （参加者３）ディスカッションの後で ジェームスの言ったことに 同意を示したいです 基本的にもっと危険なものは 階層でしょう 階層ではなくてもっと一般的に ウィキデータ内のサブクラスの関連の 意味論でしょう この会議のための 最近 言語を学んでいます 例えば多くの場合 言語は同じもののサブクラス そして一部です つまり柔軟なオントロジーを 持っているといえます ウィキデータはときどき それを自由に表現します なぜなら 言語のオントロジーは 政治的にも複雑ですね 不明瞭のレベルを表現する立場で あるのもいいです しかしそれの機械解読をしたければ それは非常に問題です そしてまた オントロジーは 元々 私達のものであった何かから インポートされたことはないと思います 言ってみれば初期ウィキピディアから 集めれたものです このShape Expressionはいいけど ウィキデータのオントロジーを 外部の資料で 検証したり修正をしたりもでき 素晴らしいアイデアですが 最後に 外部のオントロジーをウィキデータに 反映することで終わりますか？ そしてまた外部の資料から 決して集められない私達のオントロジーの 中核はどうすればいいでしょう どのように修正すべきでしょうか？ それはそれ自体の問題になるでしょう 外部の何かで オントロジーを検証するアイデアから 独立して注目しなければ ならなくなるでしょう （参加者４）拘束やシェープで できることは とても素晴らしいですが 主点ははっきりしていく… なぜならデータに何を期待するかが 明瞭にできるようになったからです 以前は個々にツールや スクリプトを作る必要があり 目につきやすく それについて議論できます しかし課題は良し悪しではなく 期待です 人によって ウィキデータでどうモデルするかは 異なった期待と議論があるでしょう そしてこれは… 現在の状況はその方向に 一歩進み これに取り組むには 技術的な知識が必要となるので この拘束を可視化するための それを理解しやすい たぶん自然な言語に変換するための 方法が求められ 良し悪し自体はあまり問題ではないです （リディア）はい （参加者５）クオリティについて 賛同したいのは… 私はたくさんの問題を見つけました インスタンスとサブクラスの間の 意見の差にも行き当たりました これらの状況のエラーだと思い とても時間のかかるプロセスを 探しました 私が見つけたのは「とても 興味深い項目を見つけたら 何か… そして派生するすべての ステートメントを見つけるに すべてのサブクラスの インスタンスを使おう」 これはこれらのエラーを見つける とても有効な方法です しかしShape Expressionができるか… 何か… これらの問題を解消するツールとして 使えれば…でも… （参加者６）構造的な足跡があれば… 構造的な足跡があれば 改ざん可能な… 見てみて これはできると… しかしこれが単に 現実のものを マップしようとしているだけなら とてもたくさんの頭脳が必要でしょう （参加者７）Apple Sire Knowlege の パブロ・メンデスです 私達はどうプロジェクトとコミュニティを 助けるかを見つけるために集まっていますが クリスティーナは間違って 私達が欲しいものを尋ねました （笑）そこで私が思うのは 検証可能性に関して 多くのことが求められます それはプロジェクトやコミュニティ その信頼性の中核となるもののひとつです すべてのステートメントは等しくなく とても争われるものや 簡単に推測できるものとか 例えば誰かの誕生日は簡単に 検証でき 今日のキーノートのように 性別はもっと複雑です もう少しデータのクオリティの分野で 信頼性と検証可能性に関して 知っていることを話してもらえますか あまりなければ もっとあって欲しいと思います（笑） （リディア）はい 明らかにあまり言うことがないようです（笑） （アンドレア）できることがたくさんありますが 昨日 あなたと話したように 昨日習った私の好みの例は もう昨日拝み倒されたものですが Q2 地球に行くと 地球は平面というステートメントがあります この例が大好きです なぜならそれを主張するコミュニティがあり 検証可能なリソースがあるからです これは誠実な例で 拝み倒されるべきでなく ウィキデータにあるべきです Shape Expressionは ここで非常に役立ちます このユースケースにとても 関心があるとか これは同意しないユースケースとか しかしまたこれはいいけど 関心があるというユースケースもあります ここに例があるとします グルコースがあります 生物学者なら グルコースの分子構造の 化学的拘束には興味がないでしょう すべてのグルコースに関することは 同じです でも化学者なら これを聞くと気になると思います 200ほどのものがあります だから複雑のShape Expressionがあります ここで 化学者の立場で これに対応します そしてあなたが 生物学的なユースケースから Shape Expressionを適用したいとします そして共同したければ エリックと ShExについて 話すとよいでしょうが この行程はまだ始まったばかりですが この分野で非常に 重要なものと思っています （リディア）あちらの方 （参加者８）ディスカッションでの 幾つかの点についてアイデアがあります 失わないように… ３つのアイデアが… ちょっと前にジェームスが言ったことで 上部のオントロジーのための開始から ウィキデータにはとても 大きな問題があります WikidataConで２年前に 話しました そしてウィキマニアについて 話し合いました ウィキデータの会議があると いつもこれを話します なぜなら目につくレベルの とても大きな問題だからです 何がエンティティで 何が workで 何も分野か そして芸術 もっとも大きな概念です これは実際 グローバルなオントロジーの 最大の弱点です なぜなら人々は常にこれを整理し すべてを線で分けようとしているからです 覚えている人もいると思いますが 世界中のすべての市を無意識に 壊した人がいます 地理的な項目ではないので 拘束違反に満ちて 誠実な意図でしたが 項目の間違いを直そうとしていたのに すべてを壊していしまいました これをどのように解決できるが 私はわかりません なぜなら実際に写してこれる 外部の機関がないからです 皆さんが作業している 例えば 芸能データベースだとします 直接 芸能のラベルに行くか あるいはエンティティがなにかの 論理的概念には行かず これは実際に… このレベルで機能している データベースは知りませんが これがウィキデータの弱点です データのクオリティを話すにおいて 実際もっと大きなといえるでしょう ここで言ったと同じ様に… 失礼 話題を変えてしまっています クオリティについては 別のセッションで言及しました それに関しては 実際 よいモデリングを行っている人がいて ShExを活用したりして それを行っています ウィキデータでは見れません ShExは見えません ディスカッションページでは WikiPeojectを見ず そして時には プロパティのトークページも見ません そこには明確に a)このプロパティが そのために使用されると記載されています 先週あるプロパティに 拘束を加えました そのプロパティの創作の ディスカッションに この拘束は明確に記述されていました 私はその拘束を加える技術部分を 作っただけですが 誰かに「私の編集をすべて 台無しにした」と言われました その人は過去２年 このプロパティを 間違って使っていました プロパティは実際はとても明瞭ですが 警告などがなく… だからウィキマニアの ピンクのポニーのように WikiPeojectをもって見やすく ShExをもっと見やすくすべきです それがクリスティーナは 言ったことです 既存の解決策が見られていないという 問題があるんです このセッションでは もっとShExを作ろうとか 整理する人の作業を促進しようとか 話していますが ウィキデータの一日目から 整理をしてきていて グローバルには追いついて行けていません 追いつけていけない訳は… 名前が複雑だと知っていて 私だけで整理の作業をしていて すべての中国人の研究者に ラテン語の名前を追加する人がいるとしたら 何ヶ月も整理にかかり 一人ではやっていけません ではその人はバッチで その作業をしたでしょう 私たちが必要なのは… ツールの問題ではなくと 見て理解されるというが問題です 既にツールはたくさんあります （リディア）そうですね しかし時間のようで（笑） 締めくくりましょう たくさんのコメントを ありがとうございました 今日 この後もディスカッションを 続けてください 皆さんのご意見ありがとうございました （拍手）