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