データクオリティパネル
クロディア・ミューラービン、
ルーカス・ウェアミニスター
ホゼ・エミリオ・ラビラ・ガヤ、
クリスティナ・サラスナ、アンドレア・
データクオリティパネルの皆さん
こんにちは
多くの人が私たちのデータが正しいことを
頼るのでデータクオリティは重要です
だからデータクオリティについて
話し合いましょう
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を作ろうとか
整理する人の作業を促進しようとか
話していますが
ウィキデータの一日目から
整理をしてきていて
グローバルには追いついて行けていません
追いつけていけない訳は…
名前が複雑だと知っていて
私だけで整理の作業をしていて
すべての中国人の研究者に
ラテン語の名前を追加する人がいるとしたら
何ヶ月も整理にかかり
一人ではやっていけません
ではその人はバッチで
その作業をしたでしょう
私たちが必要なのは…
ツールの問題ではなくと
見て理解されるというが問題です
既にツールはたくさんあります
（リディア）そうですね
しかし時間のようで（笑）
締めくくりましょう
たくさんのコメントを
ありがとうございました
今日 この後もディスカッションを
続けてください
皆さんのご意見ありがとうございました
（拍手）