WEBVTT

00:00:00.822 --> 00:00:03.472
データクオリティパネル

00:00:03.748 --> 00:00:05.098
クロディア・ミューラービン、
ルーカス・ウェアミニスター

00:00:05.098 --> 00:00:06.671
ホゼ・エミリオ・ラビラ・ガヤ、
クリスティナ・サラスナ、アンドレア・

00:00:06.671 --> 00:00:09.476
データクオリティパネルの皆さん
こんにちは

00:00:09.658 --> 00:00:15.761
多くの人が私たちのデータが正しいことを
頼るのでデータクオリティは重要です

00:00:15.761 --> 00:00:19.289
だからデータクオリティについて
話し合いましょう

00:00:20.029 --> 00:00:26.000
4人の講演者は
データクオリティについて短い紹介をし

00:00:26.000 --> 00:00:29.539
その後で質疑を行います

00:00:30.130 --> 00:00:32.234
ではまずルーカスから

00:00:34.385 --> 00:00:35.385
ありがとう

00:00:35.901 --> 00:00:39.899
ルーカスです
まずウィキデータに既にある

00:00:39.899 --> 00:00:43.806
データクオリティツールと
開発されていて公開マジかなものについての

00:00:43.807 --> 00:00:46.109
概要から始めます

00:00:46.932 --> 00:00:50.623
いくつかのテーマの
グループに分けました

00:00:50.623 --> 00:00:53.761
エラーを見つけやすくする
問題に対処しやすくする

00:00:53.762 --> 00:00:56.322
データにより検証し
問題に気づきやすくする

00:00:56.945 --> 00:01:02.616
一般的なエラーの元を修正する
既存のデータの質を維持する

00:01:02.616 --> 00:01:04.846
そして人によるキューレーション

00:01:05.063 --> 00:01:09.874
そして現在利用可能なものは
プロパティの拘束からです

00:01:10.138 --> 00:01:12.421
ウィキデータで
これを見たことがあると思います

00:01:12.422 --> 00:01:15.130
このような
内部のデータの均一性をチェックする

00:01:15.130 --> 00:01:17.241
アイコンが出ることがあるでしょう

00:01:17.242 --> 00:01:20.800
例えば
あるイベントが他に続くなら

00:01:20.801 --> 00:01:23.760
他のイベントもこのイベントに
続くべきです

00:01:23.761 --> 00:01:27.161
このWikidataConの項目では
それが見られません

00:01:27.162 --> 00:01:29.360
この機能はできてまだ数日かも
しれません

00:01:30.040 --> 00:01:34.461
あるいはこれが制限しすぎだったり
簡単すぎなら

00:01:34.461 --> 00:01:38.080
Query Service を使って
チェックを自分で書くこともできます

00:01:38.081 --> 00:01:41.892
もちろんQuery Serviceは
多くのことに有効ですが

00:01:41.892 --> 00:01:44.543
エラーを見つけることもできます

00:01:44.794 --> 00:01:46.974
ひとつ間違いを見つけたら

00:01:46.975 --> 00:01:49.539
他の場所もチェックし

00:01:49.539 --> 00:01:51.608
他の人が同じエラーをしていないか

00:01:51.608 --> 00:01:53.708
Query Serviceで見つけられます

00:01:53.708 --> 00:01:55.259
あるいは２つを組み合わせて

00:01:55.259 --> 00:01:57.874
拘束違反を
Query Serviceで探せます

00:01:57.875 --> 00:02:00.910
例えば
ある部分にだけあるエラーや

00:02:00.910 --> 00:02:04.122
WikiProjectの
あなたの関連した部分だけのエラーなどです

00:02:04.272 --> 00:02:07.828
でも残念なことに
その結果は現在のところ完全ではありません

00:02:08.422 --> 00:02:09.877
改訂スコアリングもあります

00:02:10.690 --> 00:02:13.186
これは最近の変更からだけ思いますが

00:02:13.186 --> 00:02:16.217
自動アセスメントのウォッチリストに入れて

00:02:16.217 --> 00:02:19.949
その編集が誠実なものかどうか

00:02:19.949 --> 00:02:22.629
また被害を与えるものかどうかを
見ることができます

00:02:22.629 --> 00:02:24.205
これは2次元だと思います

00:02:24.206 --> 00:02:26.426
だから被害を与えるけど

00:02:26.426 --> 00:02:29.898
誠実なものかどうかに注目して

00:02:29.899 --> 00:02:32.523
特に友好的な気分なら

00:02:32.524 --> 00:02:35.293
これらの編集者に

00:02:35.293 --> 00:02:39.470
「貢献してくれてありがとう
次回はこのようにしてください」など…

00:02:40.561 --> 00:02:42.186
でもそうでなければ

00:02:42.187 --> 00:02:44.452
誠実でないものや
被害を与えるものを

00:02:44.453 --> 00:02:46.660
元に戻すこともできます

00:02:47.544 --> 00:02:49.761
似たものに
エンティティ・スコアリングがあり

00:02:49.762 --> 00:02:52.350
これは変更が加えられた
編集をスコアリングするのはなく

00:02:52.350 --> 00:02:53.904
全体の改訂をスコアリングします

00:02:53.904 --> 00:02:56.483
これにはリディアは会議の当初に
話したのと

00:02:56.483 --> 00:02:59.863
同じ質の検証が使用されると
思います

00:03:00.372 --> 00:03:04.569
このユーザースクリプトで
これらの１から５のスコアを与えます

00:03:04.570 --> 00:03:08.176
これは現在の項目のクオリティだと
思います

00:03:10.043 --> 00:03:14.328
１次資料ツールは
すべてのインポートしたい、しかし

00:03:14.328 --> 00:03:18.374
直接ウィキデータに入れられる質でない
データベースのためのものです

00:03:18.374 --> 00:03:20.335
だからこれを１次資料ツールで
処理し

00:03:20.336 --> 00:03:22.956
それから実際に人が判断し

00:03:22.956 --> 00:03:26.024
個々のステートメントを
加えるかどうかを決めます

00:03:28.595 --> 00:03:31.901
座標を地図で示すことは
とても便利な機能ですが

00:03:31.901 --> 00:03:33.928
クオリティコントロールにも
有用です

00:03:33.928 --> 00:03:36.937
これがウィキデータ・ドイツの
オフィスのはずで

00:03:36.938 --> 00:03:39.400
座標がインド海の中にあれば

00:03:39.401 --> 00:03:41.529
何か間違っていると気が付きます

00:03:41.530 --> 00:03:44.790
単に数字を見るより
簡単にわかります

00:03:46.133 --> 00:03:49.576
これは 相対的完全性
インディケータというガジェットで

00:03:49.577 --> 00:03:52.480
この小さなアイコンで示され

00:03:53.007 --> 00:03:55.652
その項目が完成しているかどうか

00:03:55.652 --> 00:03:57.858
あるいはどのプロパティが
欠けていそうかを示し

00:03:57.858 --> 00:04:00.209
項目を編集しているときに便利なもので

00:04:00.209 --> 00:04:03.172
もし馴染みない分野で

00:04:03.172 --> 00:04:05.661
使うべき正確なプロパティが
わからないときには

00:04:05.662 --> 00:04:08.230
とても便利なガジェットです

00:04:08.774 --> 00:04:11.971
Shape Expression があります

00:04:11.971 --> 00:04:15.624
アンドレアかホゼが
これらについてお話すると思いますが

00:04:15.624 --> 00:04:19.137
基本的には
持っているデータをそのテーマに対して

00:04:19.137 --> 00:04:21.258
比較するためのとても有効な方法です

00:04:21.258 --> 00:04:23.570
どのステートメントが
特定のエンティティを持つべきか

00:04:23.570 --> 00:04:25.867
他のエンティティがリンクされるべきか
どのように完成されるべきか

00:04:26.229 --> 00:04:29.374
それによって間違いを見つけることができます

00:04:30.366 --> 00:04:32.181
えーと
これですね

00:04:32.181 --> 00:04:34.696
Integraality または
プロパティ・ダッシュボード

00:04:34.696 --> 00:04:36.953
既にあるデータの概要を示します

00:04:36.953 --> 00:04:39.657
例えば WikiProject Red Pandaの
このフォームで

00:04:39.657 --> 00:04:41.681
ここにほとんどすべての赤パンダの

00:04:41.682 --> 00:04:43.561
性別があるのかわかります

00:04:43.561 --> 00:04:46.854
誕生日はどこの動物園かによって
かなり変わります

00:04:46.854 --> 00:04:50.255
亡くなったパンダは
ほとんどいないですね

00:04:50.317 --> 00:04:52.600
よっかた
かわいいからね

00:04:53.699 --> 00:04:55.654
これはとても便利です

00:04:56.377 --> 00:04:59.185
そしてOKすると
次に出てくるのは

00:04:59.889 --> 00:05:03.784
ウィキデータ Bridge
クライアント編集として知られているものです

00:05:03.785 --> 00:05:07.076
ウィキピディア Infobox から
ウィキデータを編集します

00:05:07.675 --> 00:05:11.395
これによりより多くの
閲覧がなされます

00:05:11.395 --> 00:05:14.302
なぜならもっと多くの人が
これらのデータを見るからです

00:05:14.302 --> 00:05:18.841
これによってウィキピディアでより
ウィキデータが使われるようになるでしょう

00:05:18.841 --> 00:05:21.420
そしてもっと多くの人に気づかれるように
なるでしょう

00:05:21.420 --> 00:05:23.857
例えばデータが古かったり
更新が必要なときは

00:05:23.857 --> 00:05:27.000
ウィキデータ自体だけで気が付かれないことを
知ることができます

00:05:28.380 --> 00:05:30.656
Tainted Referencesもあります

00:05:30.657 --> 00:05:34.679
これはステートメントの値を編集すると

00:05:34.683 --> 00:05:37.279
タイポなどを直している場合は
別として

00:05:37.280 --> 00:05:39.373
リファレンスも更新することがあるでしょう

00:05:39.897 --> 00:05:43.662
このTainted Referencesは
編集している人にそれを示す他に

00:05:43.663 --> 00:05:49.756
他の編集者にも他に
どのような編集がされたか示します

00:05:49.756 --> 00:05:53.241
ステートメントの値が変更され
リファレンスが更新されているいないを知り

00:05:53.241 --> 00:05:57.666
それらを修正するか
どうするかを決めることができます

00:05:57.737 --> 00:05:59.566
もっと修正を入れるか

00:05:59.566 --> 00:06:02.796
そのままでリファレンス更新は
必要がないとか…

00:06:03.543 --> 00:06:09.336
これはSigned statementsに関して

00:06:09.336 --> 00:06:12.355
データの提供者が心配する…

00:06:14.131 --> 00:06:17.231
UNESCOかなにかが参照された
ステートメントがあり

00:06:17.232 --> 00:06:19.872
突然 誰かがそのステートメントに
損傷を加えたら

00:06:19.873 --> 00:06:22.827
UNESCOなどの機関が

00:06:22.827 --> 00:06:26.992
その損傷されたステートメントを
出したように見られる恐れがあります

00:06:26.993 --> 00:06:28.706
だからSigned statementsは

00:06:28.706 --> 00:06:31.488
暗号的にこのリファレンスに
サインを入れることができます

00:06:31.488 --> 00:06:33.562
編集を防ぐことはできません

00:06:34.169 --> 00:06:37.744
でも少なくとも
誰かがステートメントを損傷するか

00:06:37.744 --> 00:06:40.255
あるいは編集したりすると
サインは無効になります

00:06:40.255 --> 00:06:43.851
そしてそのステートメントが
その機関が入れたものでないとわかります

00:06:43.851 --> 00:06:47.484
もし正しい編集なら そのステートメントを
再度サインすることができます

00:06:47.484 --> 00:06:49.851
または編集しなおすことができます

00:06:51.203 --> 00:06:54.166
それから
素晴らしいものとして

00:06:54.166 --> 00:06:56.846
Citoidがウィキデータにはあります

00:06:57.379 --> 00:07:01.340
これにはURLを貼り付けたり
識別子 またはISBN

00:07:01.340 --> 00:07:05.260
ウィキデータIDなど 基本的に
何でもVisual Editorに入れられ

00:07:05.260 --> 00:07:08.241
きれいにフォーマットされた
リファレンスを作成し

00:07:08.242 --> 00:07:11.049
それにはすべてのデータが含まれていて
とても使いやすいです

00:07:11.049 --> 00:07:14.337
それに比べてウィキデータでは 
リファレンスを入れたければ

00:07:14.338 --> 00:07:18.801
リファレンスURLとタイトル
著作者名

00:07:18.802 --> 00:07:20.449
出版元、出版日

00:07:20.450 --> 00:07:25.141
改訂日などを少なくとも加える必要があり
とても厄介です

00:07:25.141 --> 00:07:29.261
ウィキデータにCitoidを統合することで
それが簡単になります

00:07:30.245 --> 00:07:33.604
私は以上です

00:07:33.604 --> 00:07:36.400
ではクリスティーナに渡します

00:07:37.788 --> 00:07:42.339
（拍手）

00:07:43.780 --> 00:07:45.471
クリスティーナです

00:07:45.472 --> 00:07:47.672
チューリッヒ大学の研究員で

00:07:47.673 --> 00:07:51.417
スイスのコミュニティの
活動者でもあります

00:07:51.557 --> 00:07:57.658
クラウディア・ミューラーと私が
WikidataConにこれを提示した際

00:07:57.658 --> 00:08:01.278
期待したことは
今年の始めに

00:08:01.278 --> 00:08:05.250
データクオリティのワークショップや
その他のウィキマニアのセッションで

00:08:05.250 --> 00:08:07.650
始めた議論を継続していくことです

00:08:07.650 --> 00:08:09.204
今日の講演は基本的に

00:08:09.204 --> 00:08:11.482
コミュニティと私達が
集めた考察を提供し

00:08:11.482 --> 00:08:16.645
会話を続けていくことが目的です

00:08:16.645 --> 00:08:20.932
これからみなさんと交流を
続けていきたいと思います

00:08:20.932 --> 00:08:23.690
私達がもっと重要と思うのは

00:08:23.690 --> 00:08:26.167
コミュニティの様々なユーザーに

00:08:26.167 --> 00:08:32.471
何が必要か そしてデータクオリティの
問題が何かを問い続けることです

00:08:32.471 --> 00:08:34.730
編集する人たちだけでなく
コードを書く人や

00:08:34.730 --> 00:08:36.510
データを利用する人

00:08:36.510 --> 00:08:40.220
また何が起こったか編集履歴を
実際 利用する研究者など

00:08:40.220 --> 00:08:41.691
すべてのユーザーを含みます

00:08:42.571 --> 00:08:47.614
ウィキデータに存在する約80の
ツールを評価し

00:08:47.614 --> 00:08:52.826
それらを異なったデータクオリティの次元で
整理しました

00:08:52.826 --> 00:08:54.241
実際に気がついたことは

00:08:54.241 --> 00:08:57.780
多くのツールは
完成性をモニターしていて

00:08:57.780 --> 00:09:02.960
実際…インターリンクを
可能にするものもありますが

00:09:02.960 --> 00:09:08.241
多様性を検証するツールが
欠けていて

00:09:08.241 --> 00:09:13.750
これは実際ウィキデータに
特にウィキデータのデザイン原則に

00:09:13.750 --> 00:09:15.932
組み込めるもののひとつで

00:09:15.932 --> 00:09:17.297
多様性をもたせ

00:09:17.297 --> 00:09:19.818
異なった出典からの

00:09:19.818 --> 00:09:22.491
異なった値の
異なったステートメントを含めます

00:09:22.491 --> 00:09:24.384
これらは2次資料になるので

00:09:24.384 --> 00:09:26.546
実際どれだけの複数の
ステートメントがあるか

00:09:26.546 --> 00:09:31.291
どのように どれだけを向上できるか等を
示すツールはありません

00:09:31.291 --> 00:09:33.200
また多様なステートメントが存在する

00:09:33.200 --> 00:09:35.451
理由もよくわかりません

00:09:36.191 --> 00:09:39.963
だからこれらのコミュニティでの
ディスカッションから

00:09:39.963 --> 00:09:43.271
まだ注目すべきチャレンジが
浮き上がってきました

00:09:43.271 --> 00:09:47.538
例えばこれらのクラウドソーシングの
コミュニティがあることは

00:09:47.538 --> 00:09:50.914
データやグラフの異なった部分に

00:09:50.914 --> 00:09:53.539
取り組む異なったグループの人々がいて

00:09:53.539 --> 00:09:57.053
また異なったバックグラウンドの知識を
注ぎ込まれるという利点がありますが

00:09:57.053 --> 00:10:02.043
実際は異なった人々が
異なったプロパティを異なった方法で使い

00:10:02.043 --> 00:10:05.125
エンティティの識別子に
異なったものを期待するので

00:10:05.125 --> 00:10:08.801
何か均一なものに整えるのは
難しいです

00:10:09.381 --> 00:10:11.370
グローバルな状態を捉えるための

00:10:11.370 --> 00:10:15.843
ツールがもっと必要だと
いう声も聞かれました

00:10:15.843 --> 00:10:20.946
どのエンティティが
完成性の点で欠けているか

00:10:20.946 --> 00:10:26.340
また人々が現在
どのような作業をしているか

00:10:26.340 --> 00:10:29.713
そして異なった言語間のみでなく
かつそのWikiProjectと

00:10:29.713 --> 00:10:32.251
異なったウィキメディアの
プラットフォームに渡る

00:10:32.251 --> 00:10:35.586
緊密な共同についての
言及もありました

00:10:35.586 --> 00:10:39.211
これらのディスカッションからの
すべての書き留められたコメントを

00:10:39.211 --> 00:10:42.221
Etherpadのここのリンクに

00:10:42.221 --> 00:10:46.149
またウィキマニアのウィキページに
公開しました

00:10:46.149 --> 00:10:49.059
いくつかの解決策は
実際 異なったWikiProjectで

00:10:49.059 --> 00:10:51.442
開発された最善の実践方法を

00:10:51.442 --> 00:10:55.681
共有する方向へ向かうように見えますが

00:10:55.681 --> 00:10:58.701
チームでの仕事を整理し

00:10:58.701 --> 00:11:03.841
少なくとも誰が作業をしているか
理解できるツールも求められています

00:11:03.841 --> 00:11:08.234
またもっとショーケースが求められ

00:11:08.234 --> 00:11:12.175
よりよい方法でそれらを作成できる
テンプレートが求められています

00:11:13.494 --> 00:11:17.105
自治体オープンデータの組織との

00:11:17.105 --> 00:11:18.756
コンタクトを通じて

00:11:18.756 --> 00:11:20.421
そして特に

00:11:20.421 --> 00:11:22.841
チューリッヒ市と州と接していると

00:11:22.841 --> 00:11:26.278
ウィキデータに興味が持たれている
ことがわかります

00:11:26.278 --> 00:11:28.972
つまり誰でもアクセスして
データを見ることができる場所で

00:11:28.972 --> 00:11:33.897
データを皆に提供したいからです

00:11:33.897 --> 00:11:35.886
だからその目的に沿うには

00:11:35.886 --> 00:11:39.231
何かのクオリティの識別子を持つことが
とても気が惹かれるでしょう

00:11:39.231 --> 00:11:41.490
ウィキでは既にありますが

00:11:41.490 --> 00:11:44.090
また SPARQLの結果にも
それらがあると良いでしょう

00:11:44.090 --> 00:11:46.742
そしてそのコミュニティからの結果が
信頼できるかどうかわかります

00:11:46.742 --> 00:11:50.861
さらに持っているデータのどの部分が
ウィキデータに有益かが理解でき

00:11:50.861 --> 00:11:55.976
そしてそれらを自動的に
評価するツールが求められます

00:11:56.041 --> 00:12:01.136
またデータをインポートするべきか
リンクするべきかを決断する

00:12:01.136 --> 00:12:03.894
ある種の手法かツールも必要です

00:12:03.894 --> 00:12:05.304
場合によっては

00:12:05.304 --> 00:12:08.487
自分たちのリンクのある
オープンデータセットを持っている場合

00:12:08.487 --> 00:12:09.746
データを入れるべきか

00:12:09.747 --> 00:12:12.964
ウィキデータへデータセットから
リンクを作るべきか

00:12:12.964 --> 00:12:15.540
あるいは逆方向にするかなどが
あるからです

00:12:15.840 --> 00:12:20.043
またウィキデータのどこにウェブサイトが
参照されているかを知りたいです

00:12:20.044 --> 00:12:23.361
Query Serviceでそのような
クエリを行うと

00:12:23.362 --> 00:12:25.392
タイムアウトになることもあるので

00:12:25.392 --> 00:12:28.181
もっとツールを作り

00:12:28.181 --> 00:12:32.240
これらの質問の答えが
得られるようにすべきです

00:12:33.148 --> 00:12:36.208
それ以外にも

00:12:36.208 --> 00:12:39.361
ウィキ研究者はしばしば

00:12:39.362 --> 00:12:42.023
編集サマリで情報が
欠けていることがあります

00:12:42.024 --> 00:12:45.623
様々なエディタの挙動
ツールやボット

00:12:45.623 --> 00:12:49.879
あるいは匿名のユーザーなど
理解する作業したとき

00:12:49.879 --> 00:12:53.403
私が覚えていることは

00:12:53.403 --> 00:12:57.514
例えば使用されたツールを
追跡する標準の方法などが

00:12:57.514 --> 00:13:00.057
欠けていたことです

00:13:00.593 --> 00:13:03.154
PetScanなどそれを既に行うツールも

00:13:03.155 --> 00:13:05.230
いくつかありますが

00:13:05.230 --> 00:13:09.250
このようなキメの細かい起源を
どのように記録するかについて

00:13:09.250 --> 00:13:13.531
コミュニティで検討するべきでしょう

00:13:14.169 --> 00:13:15.321
さらに

00:13:15.322 --> 00:13:20.801
リンクされたデータに関するけど
すべてのタイプのデータに関しない

00:13:20.802 --> 00:13:25.262
より強固なデータクオリティ次元を
考慮する必要があります

00:13:25.262 --> 00:13:30.402
リンクで可能にされる
情報取得（Information gain)を

00:13:30.402 --> 00:13:32.322
調べてみました

00:13:32.322 --> 00:13:33.881
つまり

00:13:33.882 --> 00:13:36.681
ウィキデータを他のデータセットに
リンクする際に

00:13:36.682 --> 00:13:41.931
どれだけのエンティティが
実際クラシフィケーションに得られるか

00:13:41.931 --> 00:13:44.991
あるいは記述や
また使用されている単語などが得られるかも

00:13:44.991 --> 00:13:46.881
考えるべきです

00:13:46.881 --> 00:13:51.041
簡単な例を挙げると…

00:13:51.042 --> 00:13:54.269
この場合 ウィキデータ

00:13:54.270 --> 00:13:57.771
あるいはウィキデータにリンクされた
外部のデータセンターで

00:13:57.772 --> 00:14:00.487
ナターシャ・ノイと呼ばれる
人のエンティティがあり

00:14:00.487 --> 00:14:02.601
所属やその他の情報があります

00:14:02.602 --> 00:14:05.239
これでOKとして
外部にリンクし

00:14:05.240 --> 00:14:08.919
そこにその名前のエンティティが既にあり
実際同じ値を持っているとします

00:14:09.670 --> 00:14:12.889
よりよい方法は
別の名前をもつものにリンクします

00:14:12.889 --> 00:14:16.881
このひとは2通りの方法で
名前を書くことができるので有効です

00:14:16.882 --> 00:14:19.714
あるいはウィキデータにない
他の情報や

00:14:19.715 --> 00:14:22.323
他のデータセットにない情報を
持つことができます

00:14:22.390 --> 00:14:24.652
もっとよい方法としては

00:14:24.653 --> 00:14:29.210
この情報を分類する新しい方法を持つ
ターゲットデータセットを

00:14:29.210 --> 00:14:31.392
見ることです

00:14:31.393 --> 00:14:35.354
これが人であるのみでなく
他のデータセットでは

00:14:35.355 --> 00:14:39.525
女性であるとかなど
他の分類も言及できます

00:14:39.526 --> 00:14:43.401
もし他のデータセットで
もっと多くの単語が使われていれば

00:14:43.402 --> 00:14:46.588
全体の情報を回収するものの
助けにもなります

00:14:47.371 --> 00:14:51.233
それに関してさらに言えることは

00:14:51.234 --> 00:14:55.809
フェデレーションクエリーが
よりよく行われます

00:14:55.810 --> 00:15:00.448
マリーシェフ達による
クエリーログを見ると

00:15:01.285 --> 00:15:04.301
オーガニックなクエリーから

00:15:04.302 --> 00:15:06.921
フェデレーションクエリーは
ほんの少ししかないことがわかります

00:15:06.922 --> 00:15:12.801
実際フェデレーションはリンクされた
データを持つ主なる有利な点の一つでなので

00:15:12.802 --> 00:15:16.903
コミュニティや
ウィキデータを使う人は

00:15:16.903 --> 00:15:18.898
この例がもっと必要でしょう

00:15:18.898 --> 00:15:22.666
使用されたエンドポイントを見ると…

00:15:22.667 --> 00:15:25.401
これは完全なリストではなく
もっとあります

00:15:25.402 --> 00:15:30.479
もちろんこのデータは2018年３月までの
クエリーを評価していますが

00:15:30.480 --> 00:15:34.807
フェデレーションエンドポイントを見ると

00:15:34.808 --> 00:15:37.048
それらが使用されているかどうかを
見るべきです

00:15:37.813 --> 00:15:40.441
後のディスカッションで使用できる

00:15:40.442 --> 00:15:43.001
参加者の皆さんへの２つの質問は

00:15:43.001 --> 00:15:45.511
あなた達の必要に応じるための

00:15:45.511 --> 00:15:47.412
データクオリティの問題は
なんであるか

00:15:47.412 --> 00:15:50.401
そしてまた編集や警衛のために

00:15:50.402 --> 00:15:52.943
必要な自動化は何かということです

00:15:53.838 --> 00:15:55.587
以上です
ありがとうございました

00:15:55.779 --> 00:15:57.527
（拍手）

00:16:06.030 --> 00:16:08.595
（ホゼ・エミロ・ラブラ）
私が話すことは

00:16:08.595 --> 00:16:14.715
Shape Expressionに関連し
私達が開発しているツールです

00:16:15.536 --> 00:16:19.371
私はホゼ・エミロ・ラブラです

00:16:19.371 --> 00:16:23.215
これらのツールは異なった人によって
つくられました

00:16:23.920 --> 00:16:28.480
主にW3C ShEx, Shape Expressions
コミュニティグループに関連しています

00:16:28.481 --> 00:16:30.121
ShEx コミュニティグループです

00:16:30.144 --> 00:16:36.081
まずお話したいのは
RDFShapeで これは一般的なツールです

00:16:36.082 --> 00:16:40.681
なぜなら Shape Expressionsは
ウィキデータのためだけでなく

00:16:40.682 --> 00:16:44.168
一般的に RDFを検証する言語だからです

00:16:44.168 --> 00:16:47.568
これは私が主で開発したもので

00:16:47.568 --> 00:16:50.880
一般的にRDFを検証するツールです

00:16:50.881 --> 00:16:55.139
RDFについて学習したいとか
ウィキデータでのみでなく

00:16:55.140 --> 00:16:58.621
RDFやSPARQL エンドポイントを
検証したいなら

00:16:58.622 --> 00:17:00.891
このツールをお勧めします

00:17:00.891 --> 00:17:03.255
また学習については

00:17:03.255 --> 00:17:05.640
私は大学で教えていて

00:17:05.641 --> 00:17:09.151
RDFを教えるにはセマンティクな
ウェブコースでそれを使っています

00:17:09.161 --> 00:17:12.121
だからRDFを習いたいなら
これはよいツールだと思います

00:17:13.033 --> 00:17:17.598
例えばこのツールでの
RDFグラフの可視化です

00:17:18.587 --> 00:17:22.643
ここへ来る前
先月

00:17:22.643 --> 00:17:28.441
ウィキデータ用に特に
RDFShapeを分岐し始めました

00:17:28.443 --> 00:17:33.082
これを WikiShapeと呼んで
ウィキデータのプレゼンで紹介しました

00:17:33.082 --> 00:17:34.441
行ったことは

00:17:34.442 --> 00:17:38.805
ウィキデータに関連しないものを削除して

00:17:38.805 --> 00:17:44.801
ウィキデータ SPARQLエンドポイントなど
幾つかのものをコードに書き込みました

00:17:44.802 --> 00:17:49.041
ウィキベースにもできるかと
聞かれましたが

00:17:49.042 --> 00:17:52.000
ウィキベース用を作るのも
とても簡単にできます

00:17:52.760 --> 00:17:56.280
このWikiShapeツールは
新しいもので

00:17:57.015 --> 00:17:59.843
ほとんどの機能は働くと思いますが

00:17:59.844 --> 00:18:02.468
機能しないものもあるでしょう

00:18:02.469 --> 00:18:06.281
使ってみて向上させたいと
思われた方はご連絡ください

00:18:06.281 --> 00:18:12.680
これは［不明瞭］キャプチャですが
やってみましょう

00:18:15.385 --> 00:18:16.945
動くかどうかみてみましょう

00:18:16.953 --> 00:18:20.070
まず外に出て…

00:18:22.453 --> 00:18:23.453
ここ

00:18:24.226 --> 00:18:28.324
ここにツールがあります

00:18:28.324 --> 00:18:29.844
このツールでできることは

00:18:29.845 --> 00:18:35.275
例えば スキーマ
エンティティスキーマの検証です

00:18:35.276 --> 00:18:38.611
ここに新しい名前空間があり
Eの何か…

00:18:38.612 --> 00:18:44.805
例えば「human…」と書けば

00:18:44.806 --> 00:18:48.812
書いていく間に補完されるので
チェックすることができ

00:18:48.812 --> 00:18:52.001
例えば
人のShpae Expressionは

00:18:52.790 --> 00:18:55.937
ここにあるShpae Expression です

00:18:55.938 --> 00:18:59.841
このエディタには
シンタックスが色付けされています

00:18:59.842 --> 00:19:04.559
これは…
画面が小さいので

00:19:05.676 --> 00:19:07.590
大きくしてみましょう

00:19:09.194 --> 00:19:10.973
見やすくなるでしょう

00:19:10.973 --> 00:19:14.241
これがエディタで
シンタックスが色付けされています

00:19:14.241 --> 00:19:17.851
このエディタは
ウィキデータ Query Serviceと

00:19:17.851 --> 00:19:19.641
同じソースコードからできています

00:19:19.642 --> 00:19:23.960
例えば
マウスを乗せると

00:19:23.961 --> 00:19:27.961
異なったプロパティの
ラベルを表示します

00:19:27.962 --> 00:19:33.478
ウィキデータのエンティティ
スキーマは単なるテキストアイデアなので

00:19:33.478 --> 00:19:38.601
とても便利だと思います

00:19:38.602 --> 00:19:42.493
このエディタは補完機能があるので
よりよく

00:19:42.494 --> 00:19:43.743
また…

00:19:43.744 --> 00:19:48.241
例えば拘束を加えたければ

00:19:48.241 --> 00:19:51.570
「wdt:」と打って

00:19:51.570 --> 00:19:56.884
「author」と書いて
Ctrl+Spaceと打てば

00:19:56.884 --> 00:19:58.922
異なった物を提供します

00:19:58.922 --> 00:20:02.388
これはウィキデータの
Query Serviceと似ていますが

00:20:02.389 --> 00:20:06.445
これはShpae Expression特定のものです

00:20:06.445 --> 00:20:11.975
なぜならShpae Expressionの作成は

00:20:11.976 --> 00:20:15.841
SPARQL クエリーを書くより
難しいものではないと思うからです

00:20:15.842 --> 00:20:21.255
同じレベルだと思う人もいるでしょうが

00:20:22.278 --> 00:20:26.296
私は多分はより簡単だと思います

00:20:26.296 --> 00:20:31.241
なぜならShpae Expressionは簡単に
機能するようにデザインされているからです

00:20:31.242 --> 00:20:35.001
これが まず最初の

00:20:35.001 --> 00:20:36.620
Shpae Expressionのための
エディタです

00:20:37.371 --> 00:20:41.467
そしてまた例えば
簡単に可視化できるでしょう

00:20:41.468 --> 00:20:44.801
Shpae Expressionがあって
例えば

00:20:44.802 --> 00:20:49.386
「written work」は
よい Shpae Expressionでしょう

00:20:49.386 --> 00:20:53.300
異なった物の間に
何らかの関連があるからです

00:20:54.823 --> 00:20:58.160
これは 「written work」の
UML可視化です

00:20:58.161 --> 00:21:02.090
UMLでは
簡単に異なったプロパティを見れます

00:21:02.790 --> 00:21:06.794
これを行った際
何人かの Shpae Expressionに

00:21:06.795 --> 00:21:09.216
間違いがあることに気がつきました

00:21:09.217 --> 00:21:12.988
何が欠けているプロパティかなどが
簡単に見つけられるからです

00:21:13.588 --> 00:21:15.771
そしてもうひとつの可能性は

00:21:15.772 --> 00:21:19.520
検証ができることだと思います

00:21:20.496 --> 00:21:25.285
どれかのラベルにあったと思います
閉じてしまったかも…

00:21:26.267 --> 00:21:30.988
でも例えばここ<i>Validate entities</i>を
クリックできます

00:21:32.308 --> 00:21:34.232
例えば

00:21:35.404 --> 00:21:41.921
「q52」そして著者である「e42」

00:21:42.818 --> 00:21:46.180
「human」で…
「human」でできると思います…

00:21:49.050 --> 00:21:50.050
そして

00:21:50.688 --> 00:21:56.365
SPARQLクエリーをしているので
少し時間がかかっています

00:21:56.365 --> 00:21:59.134
この例はネットワークのせいで
機能しませんが

00:21:59.657 --> 00:22:01.580
自分で試してみてください

00:22:02.759 --> 00:22:07.026
では他のツールのプレゼンを続けましょう

00:22:07.026 --> 00:22:12.353
試したい方 フィードバックが欲しい方は
連絡してください

00:22:13.133 --> 00:22:15.540
プレゼンを続けます

00:22:18.923 --> 00:22:20.576
これが WikiShape です

00:22:23.800 --> 00:22:26.509
既に言いましたが

00:22:27.681 --> 00:22:34.157
Shpae Expression エディタは
GitHubの中の独立したプロジェクトです

00:22:35.605 --> 00:22:37.472
個人のプロジェクトで使用できます

00:22:37.472 --> 00:22:41.036
Shpae Expression ツールをしたければ

00:22:41.036 --> 00:22:45.635
任意のプロジェクトに
入れ込めばいいだけです

00:22:45.636 --> 00:22:48.235
これはGitHubの中にあるので
だれでも使えます

00:22:48.868 --> 00:22:51.970
私の生徒である同じ著者がさらに

00:22:52.034 --> 00:22:55.704
作ったShpae Expression用の
エディタがあり

00:22:55.704 --> 00:22:58.819
ウィキデータ Query Serviceに
影響されたもので

00:22:58.819 --> 00:23:00.681
欄の中に

00:23:00.682 --> 00:23:05.103
SPARQLクエリーの 
より可視化されたVisual editorがあり

00:23:05.104 --> 00:23:07.135
このようなものを入れることができます

00:23:07.136 --> 00:23:09.123
これはスクリーンキャプチャです

00:23:09.123 --> 00:23:12.662
これはテキストの
Shape Expressionであることがわかりますが

00:23:12.662 --> 00:23:17.822
これはフォーム形式のShape Expressionで
ちょっと時間がかかります

00:23:18.595 --> 00:23:23.400
異なったフィールドに
異なった行を入れることができます

00:23:23.401 --> 00:23:25.800
そして ShExEr があります

00:23:26.879 --> 00:23:31.882
オビエド大学の大学院生が作ったもので

00:23:31.883 --> 00:23:34.540
彼がここに来ているので
ShExErを紹介します

00:23:38.147 --> 00:23:40.024
（ダニー）ダニー・フェナンデスです

00:23:40.025 --> 00:23:43.800
オビエド大学の大学院生で
ラビラと一緒に仕事しています

00:23:44.710 --> 00:23:47.725
時間が迫っているので
急いでやります

00:23:47.726 --> 00:23:52.641
デモはしないで
スクリーンショットを出しましょう

00:23:52.642 --> 00:23:57.897
Shape Expressionや他のShape言語で
作業をする通常の方法は

00:23:57.897 --> 00:23:59.521
内容領域専門家がいて

00:23:59.522 --> 00:24:02.313
先験的に
グラフをどのようにするか

00:24:02.314 --> 00:24:03.555
構成を定義し

00:24:03.556 --> 00:24:06.983
その構成を使用して
実際のデータを検証します

00:24:08.124 --> 00:24:11.641
ラビラが紹介したもののと同様に
このツールは

00:24:11.642 --> 00:24:14.441
一般的な任意のRDFソース用のツールで

00:24:14.442 --> 00:24:17.375
逆方向にデザインされています

00:24:17.376 --> 00:24:18.758
幾つかのデータが既にあり

00:24:18.759 --> 00:24:23.165
Shapeを得たいノードを選択し

00:24:23.165 --> 00:24:26.718
すると自動的に抽出また
Shapeを推測します

00:24:26.719 --> 00:24:29.791
これは一般目的のツールですが

00:24:29.791 --> 00:24:34.063
WikidataCon のためにしたことは
これらの優れたボタンです

00:24:34.884 --> 00:24:37.081
クリックすると起こることは

00:24:37.081 --> 00:24:42.079
たくさんの構成パラメータがあり

00:24:42.080 --> 00:24:46.251
ウィキデータエンドポイントに対して
機能するようになっています

00:24:46.251 --> 00:24:47.971
失礼

00:24:48.733 --> 00:24:52.883
このボタンを押せば
基本的にこれが得られます

00:24:52.884 --> 00:24:55.126
どのような記述が欲しいか

00:24:55.127 --> 00:24:59.360
またクラスのインスタンスなど
探しているものを選択した後

00:24:59.361 --> 00:25:01.321
自動的にスキーマが得られます

00:25:02.319 --> 00:25:07.111
どれだけのモードが実際使われているかで
すべての拘束が整理され

00:25:07.112 --> 00:25:09.772
あまり共通しないものを
取り除くことができます

00:25:09.772 --> 00:25:12.126
このポスターが下に掲示されていて

00:25:12.127 --> 00:25:14.595
私は今日はこのあたりに

00:25:14.596 --> 00:25:16.454
一日中いますので

00:25:16.455 --> 00:25:19.081
このツールに関心のある方は

00:25:19.082 --> 00:25:21.476
声をかけてください

00:25:21.477 --> 00:25:24.624
ではラブラにマイクを返します
ありがとうございました

00:25:24.625 --> 00:25:29.265
（拍手）

00:25:29.812 --> 00:25:32.578
（ホゼ）では次のツールにいきましょう

00:25:32.579 --> 00:25:34.984
これは ShapeDesignerです

00:25:34.984 --> 00:25:37.241
アンドレア ShapeDesignerを
ここで紹介しますか

00:25:37.242 --> 00:25:39.287
それも後でワークショップで
紹介しますか

00:25:39.287 --> 00:25:40.603
ワークショップがあるので…

00:25:40.603 --> 00:25:44.437
午後 特に Shape Expressionのための
ワークショップがあります

00:25:45.265 --> 00:25:47.939
もっと実際に行い
ShExを練習したい方は

00:25:47.940 --> 00:25:52.324
そちらへお越しください

00:25:52.875 --> 00:25:55.720
このツールは ShEx…
エリックがいます

00:25:55.721 --> 00:25:56.890
紹介してくれますね

00:25:57.969 --> 00:26:00.687
（エリック）簡単に言いたいことは

00:26:00.687 --> 00:26:05.711
すでに ShEx のインターフェイスは
見たことがあるでしょう

00:26:05.711 --> 00:26:07.601
これはウィキデータ用のものです

00:26:07.602 --> 00:26:12.930
不要なものを除いた
ウィキデータ用のものです

00:26:12.930 --> 00:26:17.937
一般的なものにはもっと機能がありますが
言っておきたいことは

00:26:17.937 --> 00:26:19.977
ウィキデータのスキーマを
デバグするための

00:26:19.978 --> 00:26:23.201
特に有効な機能です

00:26:23.201 --> 00:26:29.224
Slurpのモードを選択すると

00:26:29.225 --> 00:26:31.444
行われることは
検証中に

00:26:31.445 --> 00:26:34.694
すべての３つ揃いを取り出したいとき

00:26:34.695 --> 00:26:36.274
つまり多くの失敗が返ってくると

00:26:36.275 --> 00:26:39.586
これらを見て

00:26:39.587 --> 00:26:41.800
どの３つ揃いがここにあり…

00:26:41.801 --> 00:26:44.120
失礼
３つ揃いはこの下です

00:26:44.121 --> 00:26:45.647
これは行われたことのログです

00:26:46.327 --> 00:26:49.180
ここでリアルタイムで
いじることができます

00:26:49.181 --> 00:26:51.033
動かしてみたり
変えることができます

00:26:51.033 --> 00:26:54.160
素早くできるバージョンです

00:26:54.663 --> 00:26:56.481
これがShExのフォームで

00:26:56.482 --> 00:27:00.035
シャヒーンがドキュメントのためには
Shape Expressionによって

00:27:00.035 --> 00:27:04.631
ウィキデータのドキュメントを
埋めるに役立つだろうと

00:27:04.631 --> 00:27:07.338
示唆したものです

00:27:08.095 --> 00:27:11.681
ウィキデータ用には
つくられていませんので

00:27:11.682 --> 00:27:14.081
これはあるスキーマがあるとき

00:27:14.082 --> 00:27:15.402
そのスキーマを特定の方法で

00:27:15.403 --> 00:27:17.518
描画したいということを注記でき

00:27:17.519 --> 00:27:19.031
そのフォームを作成し

00:27:19.031 --> 00:27:21.582
データがあれば
そのフォームを埋めることもできます

00:27:24.517 --> 00:27:26.164
PyShExは素晴らしいです

00:27:28.025 --> 00:27:31.080
（ホゼ）これが最後だと思います

00:27:31.821 --> 00:27:34.080
最後はPyShExです

00:27:34.675 --> 00:27:38.151
PyShExはShape Expressionの
Pythonインプリメンテーションです

00:27:39.193 --> 00:27:42.680
お好きな方は Juyiter Notebooksでも
使えます

00:27:42.680 --> 00:27:44.432
それだけです

00:27:44.433 --> 00:27:47.170
（拍手）

00:27:52.916 --> 00:27:56.121
（アンドレア）私が関与した
特別なプロジェクト

00:27:56.121 --> 00:27:58.074
Gene Wikiについてお話します

00:27:58.075 --> 00:28:04.596
それで私達もクオリティの問題を
対処しています

00:28:04.597 --> 00:28:06.684
そのクオリティについて話す前に

00:28:06.685 --> 00:28:09.229
Gene Wiki とは何か
ちょっと紹介します

00:28:09.855 --> 00:28:15.175
このプロジェクトの詳細を説明する

00:28:15.175 --> 00:28:18.160
論文を最近 書いてちょうど
その出版前のものを公開しました

00:28:19.821 --> 00:28:23.839
写真を撮っている方もいますが
基本的に Gene Wikiは

00:28:23.846 --> 00:28:28.027
生医学のデータ 公開されたデータを
ウィキデータに入れるもので

00:28:28.028 --> 00:28:32.200
ウィキデータに入れるには
特定のパターンに従っています

00:28:33.130 --> 00:28:36.809
新しいレポジトリや
データセットが手に入ると

00:28:36.810 --> 00:28:39.600
それがウィキデータに含まれるべきものなら

00:28:39.601 --> 00:28:41.607
まず最初にコミュニティによる関与です

00:28:41.607 --> 00:28:44.184
直接ウィキデータのコミュニティで
ある必要はなく

00:28:44.184 --> 00:28:46.530
ローカルな研究コミュニティによる
関与です

00:28:46.530 --> 00:28:50.286
オンラインかなにかの方法で会い

00:28:50.286 --> 00:28:52.881
データモデルを想像します

00:28:52.882 --> 00:28:56.197
これによりデータを
ウィキデータモデルにつなげます

00:28:56.197 --> 00:28:59.944
去年のワークショップの
写真がここにあります

00:28:59.945 --> 00:29:02.663
特定のデータセットを
見ようとしています

00:29:02.663 --> 00:29:05.280
たくさんの論議があり

00:29:05.281 --> 00:29:09.780
schema.org とその他の
存在するオントロジーに揃えています

00:29:10.320 --> 00:29:15.508
そして最初のステップの終わりに
ウィキデータに入れたい

00:29:15.509 --> 00:29:17.336
スキーマが描かれています

00:29:17.337 --> 00:29:20.440
ここにあるものは
平素です

00:29:20.441 --> 00:29:21.766
この後ろにあるのは

00:29:21.767 --> 00:29:25.240
今日のパネル内でも
幾つかのスキーマを作れます

00:29:26.560 --> 00:29:28.399
スキーマができれば

00:29:28.400 --> 00:29:31.320
次のステップは
スキーマを機械可読にすることです

00:29:32.358 --> 00:29:36.841
ウィキデータの入れる生医学の
データベースから持ち込むデータを

00:29:36.842 --> 00:29:39.690
つなげる起動可能なモデルが
ほしいからです

00:29:40.393 --> 00:29:45.182
ここで Shape Expressionを
適用しています

00:29:46.471 --> 00:29:52.518
Shape Expressionは

00:29:52.518 --> 00:29:57.040
データデットが実際…
まず

00:29:57.041 --> 00:30:01.782
既にウィキデータに存在する
データが同じデータモデルに従っているかが

00:30:01.783 --> 00:30:04.718
先ほどのプロセスで達成されます

00:30:04.719 --> 00:30:08.031
そして Shape Expressionで
このトピックのウィキデータのデータが

00:30:08.031 --> 00:30:10.926
修正が必要化どうか
ウィキデータの中のモデルに

00:30:10.926 --> 00:30:15.013
当てはめるに必要な操作があるかなど
検証します

00:30:15.937 --> 00:30:19.867
それが整ったら
ボットを書き始め

00:30:20.670 --> 00:30:23.801
ボットは定期的に
情報を入れています

00:30:23.802 --> 00:30:27.308
これがウィキデータに入れられる
１次資料です

00:30:27.846 --> 00:30:29.303
ボットが出来上がったら…

00:30:29.304 --> 00:30:33.001
これらのボットは
私たちのプロジェクトで作られた

00:30:33.002 --> 00:30:36.201
Wikidata Integratorと呼ばれる
Pythonライブラリの

00:30:36.202 --> 00:30:38.167
プラットフォームで書かれます

00:30:38.698 --> 00:30:41.851
ボットが書かれたら
継続的インテグレーションのために

00:30:41.851 --> 00:30:44.540
Jenkinsというプラットフォームを
使用します

00:30:44.540 --> 00:30:45.762
Jenkinsでは

00:30:45.762 --> 00:30:51.160
ウィキデータを１次資料で
継続して更新できます

00:30:52.178 --> 00:30:55.889
これが先に話した論文のダイアグラムです

00:30:55.890 --> 00:30:57.241
これが現在の状態です

00:30:57.242 --> 00:31:02.059
このオレンジの箱が
薬物 遺伝子 疾患

00:31:02.060 --> 00:31:07.827
作用する化学物質の
１次資料で

00:31:07.827 --> 00:31:10.870
このモデルは小さくで見にくいですが

00:31:10.870 --> 00:31:17.472
これがデータベースで
ウィキデータ内で管理される資料で

00:31:17.473 --> 00:31:20.560
１次資料とつながっています

00:31:20.561 --> 00:31:22.355
これがワークフローです

00:31:22.870 --> 00:31:25.312
私達のパートナーのひとつは
疾患オントロジーです

00:31:25.312 --> 00:31:27.672
疾患オントロジーは CCOオントロジーで

00:31:28.179 --> 00:31:31.990
このCCOオントロジーはそれ自身の
キューレーションサイクルを持っていて

00:31:32.756 --> 00:31:35.736
疾患の領域に合わせて
また疾患の解釈に応じて

00:31:35.737 --> 00:31:39.687
継続的に疾患オントロジーを
更新しています

00:31:40.336 --> 00:31:44.361
ウィキデータにも疾患に関する
キューレーションサイクルがあり

00:31:44.362 --> 00:31:49.844
ウィキデータコミュニティでは
ウィキデータで常にモニターしています

00:31:50.406 --> 00:31:51.601
私達には２つの役割があり

00:31:51.602 --> 00:31:55.477
口語的にこれらを
ゲートキーパーキュレーターと呼んでいます

00:31:56.009 --> 00:31:59.561
これは私と同僚が５年前に

00:31:59.562 --> 00:32:03.414
コンピュータの前に座って
ウィキピディアとウィキデータをモニターし

00:32:03.415 --> 00:32:08.601
もし１次コミュニティ １次資料へ
連絡される問題があれば

00:32:08.602 --> 00:32:11.765
インプリメンテーションを調べ
決断を下します

00:32:11.765 --> 00:32:14.850
このウィキデータの入力を信頼するかを見て

00:32:14.850 --> 00:32:18.555
そして考慮されたら
このサイクルに入り

00:32:18.555 --> 00:32:22.686
次のイタレーションは
疾患オントロジーの部分で

00:32:22.687 --> 00:32:25.411
ウィキデータに入れられます

00:32:27.419 --> 00:32:31.480
WikiPathwayでも同じことをしています

00:32:31.481 --> 00:32:36.601
WikiPathwayはMediaWikiに触発された
経路のリポジトリです

00:32:36.602 --> 00:32:40.901
同じ様にウィキデータには既に
異なった経路が存在します

00:32:41.463 --> 00:32:44.713
これらの経路のリソースの間で
一致しない場合は

00:32:44.722 --> 00:32:46.701
それがゲートキーパー
キュレーターから

00:32:46.702 --> 00:32:49.521
コミュニティに連絡され

00:32:49.522 --> 00:32:53.715
個々のキューレーションのサイクルは
維持されます

00:32:53.715 --> 00:32:57.068
もし以前のサイクルを覚えていれば

00:32:57.069 --> 00:33:03.041
ここでは２つのサイクルと
２つのリソースのみ話しましたが

00:33:03.566 --> 00:33:05.840
すべてのリソースに対して
行う必要があり

00:33:05.840 --> 00:33:08.061
何が起こっているかを管理しなくては
なりません

00:33:08.062 --> 00:33:09.505
キューレーションというのは

00:33:09.505 --> 00:33:11.377
ウィキピディアのトップページに行き

00:33:11.377 --> 00:33:14.544
ウィキデータのトップページに行き
それをやることです

00:33:14.545 --> 00:33:19.316
これは持っている２つのゲートキーパー
キュレーターから拡張できません

00:33:19.860 --> 00:33:22.777
2016年の会議のとき

00:33:22.778 --> 00:33:26.933
エリックがShape Expressionのプレゼンをし

00:33:26.934 --> 00:33:29.277
私もこれをやろうと
これでいいぞと思いました

00:33:29.278 --> 00:33:34.240
Shape Expressionはウィキデータ内の
違いを検知する助けになるので

00:33:34.240 --> 00:33:41.159
ゲートキーパーがより効果的な
レポートを出せます

00:33:42.275 --> 00:33:46.019
今年 スキーマエンティティに
感激しました

00:33:46.020 --> 00:33:50.765
なぜならそれらのエンティティスキーマを
ウィキデータ自体に保存できるからです

00:33:50.765 --> 00:33:53.183
これは以前はGitHubに保存されました

00:33:53.860 --> 00:33:56.815
ウィキデータのインターフェイスと
揃えられ

00:33:56.816 --> 00:33:59.350
ドキュメントのディスカッションができたり

00:33:59.350 --> 00:34:00.762
また改訂もできます

00:34:00.763 --> 00:34:05.261
トップページとウィキデータの改訂を
利用して

00:34:05.262 --> 00:34:12.255
ウィキデータに何があるべきか
１次資料が何かについて

00:34:12.255 --> 00:34:14.060
ディスカッションできます

00:34:14.966 --> 00:34:19.686
エリックがプレゼンしたものは
既にとても有益です

00:34:19.686 --> 00:34:24.335
ここにヒト遺伝子のための
Shape Expressionを作り

00:34:24.336 --> 00:34:30.225
簡単なShExを通して使ってみました
ご覧の通り

00:34:30.225 --> 00:34:32.428
既に…

00:34:32.429 --> 00:34:34.641
ひとつモニターする必要のある
問題があります

00:34:34.642 --> 00:34:37.316
スキーマに合わない項目が
ひとつあります

00:34:37.316 --> 00:34:43.139
これには既にスキーマエンティティ
キューレーションのレポートが作られ

00:34:43.140 --> 00:34:46.360
異なったキューレーションの
レポートへ送ります

00:34:48.058 --> 00:34:52.788
ShEx.js は
構築されたインターフェイスで

00:34:52.788 --> 00:34:55.860
ここに戻ってみると…
10 だけやってますが

00:34:55.860 --> 00:35:00.362
何万ものあるので
これもうまく拡張しません

00:35:00.362 --> 00:35:05.168
だから Wikidata Integratorは
SgExサポートにも対応し

00:35:05.168 --> 00:35:07.431
そして項目のループをループすることができ

00:35:07.431 --> 00:35:11.494
yes-no yes-no そして真−偽 真−偽と
行えます

00:35:11.495 --> 00:35:12.495
そしてまた

00:35:13.065 --> 00:35:16.514
レポートの対処の効率を向上します

00:35:17.256 --> 00:35:22.662
でも最近 ウィキデータの 
Query Service上にビルドされ

00:35:23.181 --> 00:35:24.998
今 絞り込んでいるところですが

00:35:24.999 --> 00:35:26.560
同様にこれも拡張しません

00:35:26.561 --> 00:35:31.391
どのようにウィキデータのモデルを扱うかは
継続している課題です

00:35:32.202 --> 00:35:36.682
ShExは巨大に感じるものであるだけでなく

00:35:36.683 --> 00:35:40.356
その規模は扱うには大きすぎます

00:35:41.068 --> 00:35:46.081
だから最初の概念の証明
あるいは演習を始めてみました

00:35:46.082 --> 00:35:47.680
yEDというツールを使います

00:35:48.184 --> 00:35:52.590
これらのShape Expressionをまず描き…

00:35:52.591 --> 00:35:57.788
そしてこのスキーマを

00:35:57.788 --> 00:36:01.279
Shape Expressionの隣接する
フォーマットに再生しました

00:36:01.280 --> 00:36:04.840
だからこれは既に
Shape Expression言語に尻込みする

00:36:04.840 --> 00:36:07.432
聴衆者でも使用できます

00:36:07.961 --> 00:36:12.308
しかし実際
これらの視覚識別子には問題があります

00:36:12.309 --> 00:36:18.229
なぜならここに誰かがすでにyEDに描いた
スキーマであるからです

00:36:18.230 --> 00:36:23.838
ここにも別のものがあります
これが使っているのは…綺麗ですね

00:36:23.838 --> 00:36:29.414
これは壁にかけたいですが
相互運用可能ではありません

00:36:30.281 --> 00:36:32.131
私の講演の終わりに

00:36:32.131 --> 00:36:35.732
このスライドを借りていますが

00:36:35.732 --> 00:36:37.594
視聴に来てくれている彼に
感謝します

00:36:37.595 --> 00:36:39.423
これが大好きです

00:36:39.424 --> 00:36:42.362
RDFは複雑で鬱陶しいと思われていますが

00:36:42.362 --> 00:36:44.293
現実はもっと悪く
これはとても簡単です

00:36:45.581 --> 00:36:48.133
なぜなら現実のデータの問題は

00:36:48.134 --> 00:36:50.031
実に複雑です

00:36:50.031 --> 00:36:51.981
RDFを避けることはできますが

00:36:51.981 --> 00:36:55.760
複雑なデータやコンピュータの問題を
避けることはもっと難しいです

00:36:55.761 --> 00:36:59.535
これはRDFについてですが
これはモデリングにも当てはまると思います

00:37:00.112 --> 00:37:02.769
私の講演のポイントは

00:37:03.387 --> 00:37:05.882
どのようにモデリングをやっていくか？

00:37:05.882 --> 00:37:10.826
ShEx または
視覚的モデルを討論すべきか…

00:37:11.426 --> 00:37:13.271
いかに継続していくか？

00:37:13.474 --> 00:37:14.840
ご視聴ありがとうございます

00:37:15.102 --> 00:37:17.787
（拍手）

00:37:19.759 --> 00:37:21.543
（リディア）ありがとうございました

00:37:21.692 --> 00:37:24.001
前に来てください

00:37:24.002 --> 00:37:27.741
質疑を始めます

00:37:28.610 --> 00:37:30.203
質問は？

00:37:31.507 --> 00:37:32.507
はい

00:37:34.253 --> 00:37:36.890
カメラのためには…

00:37:38.835 --> 00:37:40.968
（リディア）ええ

00:37:43.094 --> 00:37:46.273
（参加者１）クリスティーナへの質問で

00:37:47.366 --> 00:37:51.371
他のシステムとのリンクで

00:37:51.371 --> 00:37:53.689
「情報取得（information gain)」
という言葉を使われましたが

00:37:53.690 --> 00:37:55.619
統計と確率に使われる
情報理論の計測に使われる

00:37:55.620 --> 00:37:58.001
information gainという言葉がありますが…

00:37:58.002 --> 00:37:59.541
同じ…

00:37:59.542 --> 00:38:01.736
確率理論からの

00:38:01.736 --> 00:38:04.173
情報理論からの

00:38:04.174 --> 00:38:06.040
information gainと同じ計測を
意味しているんですか

00:38:06.040 --> 00:38:09.024
それともなんからの方法で
情報の取得を測る概念的な意味ですか

00:38:09.025 --> 00:38:13.695
いいえ実際
シャノン エントロピーを使って

00:38:13.695 --> 00:38:20.161
インプリメンテーション測定を
定義しているので それを意味します

00:38:20.162 --> 00:38:22.696
詳細な式の説明は避けたかったので…

00:38:22.697 --> 00:38:24.977
（参加者１）はいわかります
だから質問したのです

00:38:24.978 --> 00:38:27.088
（参加者１）ありがとうございました

00:38:32.795 --> 00:38:35.047
（参加者２）質問というより
コメントですが…

00:38:35.048 --> 00:38:36.241
（リディア）どうぞ

00:38:36.242 --> 00:38:39.840
（参加者２）クオリティや完成性について

00:38:39.840 --> 00:38:42.547
項目レベルに気が配られていますね

00:38:42.547 --> 00:38:47.374
私が気になることは同じことが
階層に適応されていないことで

00:38:47.374 --> 00:38:51.480
階層が的確でないという
問題があると思います

00:38:51.481 --> 00:38:53.463
コモンズ検索や他のことで

00:38:53.464 --> 00:38:55.774
これが問題になると思います

00:38:56.771 --> 00:39:00.601
できることのひとつは
外部の…

00:39:00.602 --> 00:39:04.842
外部の類義語集が
その階層を構成する方法として

00:39:04.842 --> 00:39:10.291
P4900 広範な概念修飾子を使って

00:39:11.037 --> 00:39:16.167
しかしもっとよい役に立つツールと
思うのは

00:39:16.168 --> 00:39:21.212
それによって外部の…
類義語集の階層マップを

00:39:21.212 --> 00:39:24.111
ウィキデータの項目にインポート
できるようになります

00:39:24.111 --> 00:39:28.199
これらのP9400 修飾子と置かれれば

00:39:28.200 --> 00:39:32.234
外部の階層から派生した階層を見ることが

00:39:32.490 --> 00:39:37.534
SPARQLを通じて
実際よりよいクエリーでできます

00:39:37.534 --> 00:39:41.346
例えばポーラ・モーマは
PKMを使いご存知のように

00:39:41.346 --> 00:39:43.533
ファッションの仕事を多くしています

00:39:43.533 --> 00:39:50.524
それを使って私達は
ヨーロッパファッション類義語階層と

00:39:50.524 --> 00:39:53.812
ゲッティAATファッション類義語階層を
取り入れ

00:39:53.812 --> 00:39:57.957
そして私たちにとって
実に問題となる

00:39:57.957 --> 00:40:00.511
高レベルの項目のどこに
ギャップがあるか見てみます

00:40:00.511 --> 00:40:04.355
なぜならしばしばこれらはウィキピディアの
曖昧性解消ページにのみあるので

00:40:04.356 --> 00:40:09.270
階層が欠けている より高レベルの
項目がたくさんあり

00:40:09.271 --> 00:40:14.480
これは時々クオリティと完成性の意味で
把握しておかなければならないものです

00:40:14.480 --> 00:40:16.608
しかし実際

00:40:16.643 --> 00:40:20.782
私が書いたたくさんのPullスクリプト
よりもよいツールは…

00:40:21.144 --> 00:40:26.472
誰か Pythonで
PAWS Notebook内に

00:40:26.472 --> 00:40:31.141
リンクされたデータや
そうでない

00:40:31.141 --> 00:40:35.172
外部の類義語集
そしてその階層を取り

00:40:35.172 --> 00:40:41.099
それらをP9400値にいれる
クイックステートメントに入れることです

00:40:41.165 --> 00:40:42.165
そうすれば後日

00:40:42.166 --> 00:40:44.527
叙述がもっと完全になったとき

00:40:44.528 --> 00:40:48.821
これらのP9400を更新するために

00:40:48.821 --> 00:40:51.590
叙述が更新されるにつれ
より密度が上がるので

00:40:51.590 --> 00:40:55.377
システムのその階層が
もっと増えたことを示すように

00:40:55.390 --> 00:40:59.526
これらの修飾子も変える必要があります

00:40:59.526 --> 00:41:03.728
誰かそれをしてくれれば
とても便利だと思います

00:41:03.728 --> 00:41:07.121
また項目レベルのみでなく

00:41:07.122 --> 00:41:10.762
階層レベルでクオリティと
完成性を向上する

00:41:10.763 --> 00:41:12.810
他のアプローチについても
検索するべきです

00:41:13.308 --> 00:41:15.216
（アンドレア）付け足していいですか？

00:41:16.362 --> 00:41:19.901
実際にやっています

00:41:19.911 --> 00:41:23.551
フィンが語彙的データで作った

00:41:23.552 --> 00:41:27.330
Shape Expressionを見ることを
お勧めします

00:41:27.330 --> 00:41:29.640
彼はShape Expressionを創り
そして著作者表現にビルトしています

00:41:29.641 --> 00:41:32.528
だからウィキデータの中の
リンクされたShape Expressionの構想で

00:41:32.529 --> 00:41:35.005
特に
私が正しく理解していれば

00:41:35.006 --> 00:41:37.183
それはまさに Gene Wikiの中で
やっていることです

00:41:37.184 --> 00:41:40.841
ウィキデータに入れられた
疾患オントロジーがあれば

00:41:40.842 --> 00:41:44.681
疾患のデータが入れられ

00:41:44.682 --> 00:41:47.767
この類義語集に一致するかを知るに
Shape Expressionを応用できます

00:41:47.767 --> 00:41:50.919
またウィキデータに入れる必要のある

00:41:50.920 --> 00:41:53.389
他の類義語集や制御された語彙の
他のオントロジーがあります

00:41:53.389 --> 00:41:55.401
これはまさにShape Expressionが
有用です

00:41:55.402 --> 00:41:57.963
なぜなら疾患オントロジー用の
Shape Expressionが持て

00:41:57.964 --> 00:41:59.644
Mesh用のShape Expressionが持て

00:41:59.645 --> 00:42:01.761
そして「じゃあクオリティを調べよう」
ということになります

00:42:01.762 --> 00:42:04.929
なぜなら制御された語彙がある場合

00:42:04.929 --> 00:42:09.567
ウィキデータの内容も
このクオリティに沿っているとしても

00:42:09.568 --> 00:42:12.086
それに同意しない
コミュニティもあるでしょう

00:42:12.086 --> 00:42:14.521
だからツールは準備されていても

00:42:14.521 --> 00:42:18.144
これらのモデルを作り 異なった
ユースケースに適用することになります

00:42:18.811 --> 00:42:22.521
（参加者２）外部のオントロジーを
ウィキデータにマップしたものがあれば

00:42:22.521 --> 00:42:25.928
Shape Expressionはとても有益ですが

00:42:25.929 --> 00:42:29.474
私の問題はそれに至ることです

00:42:29.475 --> 00:42:34.881
どれだけの外部のオントロジーが
まだウィキデータに中に無いか

00:42:34.882 --> 00:42:37.636
そしてそのギャップがどこになるかを
知るために

00:42:37.636 --> 00:42:40.660
より使いやすいツールで

00:42:40.660 --> 00:42:44.286
欠けている
外部のオントロジーを探すことは

00:42:44.286 --> 00:42:45.537
とても有益になるでしょう

00:42:47.678 --> 00:42:49.062
ここでの最も大きい問題は

00:42:49.062 --> 00:42:51.201
ツールではなく
ライセンスです

00:42:51.803 --> 00:42:55.249
オントロジーをウィキデータに
取り込むのは簡単ですが

00:42:55.250 --> 00:42:59.295
ほとんどのオントロジーは
どう言えばいいか…

00:42:59.965 --> 00:43:03.256
ライセンスの制御があり
ウィキデータには使えません

00:43:04.068 --> 00:43:06.678
（参加者２）とても多くの
一般使用可能な類義語辞書が

00:43:06.678 --> 00:43:08.209
文化の分野にはあります

00:43:08.210 --> 00:43:10.851
−（アンドレア）話し合う必要がありますね
−（参加者２）そうですね

00:43:10.852 --> 00:43:12.384
（アンドレア）では話しましょう

00:43:13.624 --> 00:43:19.192
（参加者３）コメントしたいことは
ジェームスへの答えになります

00:43:19.192 --> 00:43:22.401
つまり階層がグラフを作り

00:43:22.374 --> 00:43:24.041
もしあなたが…

00:43:24.579 --> 00:43:28.888
基本的に言いたいことは

00:43:28.889 --> 00:43:30.820
階層の共通した問題は
サークル階層です

00:43:30.821 --> 00:43:33.796
お互いに戻ってくるようになり
問題がある際には

00:43:33.796 --> 00:43:35.920
そのような階層を
持つべきではありません

00:43:37.022 --> 00:43:41.295
このおかしなことは
ウィキピディアのカテゴリでよく起こります

00:43:41.295 --> 00:43:43.374
カテゴリにたくさんサークルがあります

00:43:43.898 --> 00:43:46.612
しかしいいことにはこれは…

00:43:47.713 --> 00:43:51.582
技術的に言ってこれは PMP完成の問題で

00:43:51.583 --> 00:43:53.880
グラフを作ると簡単に
見つけることができません

00:43:54.473 --> 00:43:57.046
しかし多くの開発された方法があり

00:43:57.047 --> 00:44:00.624
これらの階層グラフの
問題を見つけられます

00:44:00.625 --> 00:44:04.860
例えば「*Finding Cycles Breaking Cycles

00:44:04.861 --> 00:44:07.955
in Noisey Hiearachies*」という論文で

00:44:07.956 --> 00:44:12.671
英語のウィキピディアのカテゴリの
問題を助けています

00:44:12.672 --> 00:44:17.141
これをウィキデータのこれらの
階層に応用することができ

00:44:17.142 --> 00:44:19.540
問題になりそうなものを見つけ

00:44:19.541 --> 00:44:22.481
支障をきたすものを取り除けばいいです

00:44:22.482 --> 00:44:24.593
実際 支障を見つけます

00:44:24.594 --> 00:44:26.960
これは単にアイデアですが…

00:44:28.250 --> 00:44:29.930
（参加者２）それはいいですね

00:44:29.931 --> 00:44:33.672
しかしあなたは存在する
不適切なサブクラスの関係の数を

00:44:33.672 --> 00:44:35.402
軽く見ていると思います

00:44:35.403 --> 00:44:39.680
全く間違った国に
市を持っているようなもので

00:44:40.250 --> 00:44:44.874
地理のツールとして
それを見つけるものがありますが

00:44:44.875 --> 00:44:49.201
階層に使えるツールが必要です

00:44:49.202 --> 00:44:53.477
完全に欠けている国に相当する
項目がどこにあるか

00:44:53.478 --> 00:44:57.673
また全く異なったものに
サブクラスされているものがあるかを

00:44:57.674 --> 00:45:01.804
認識するためのツールが必要です

00:45:02.804 --> 00:45:07.165
（リディア）あなたの言っていることは

00:45:07.166 --> 00:45:12.024
私と私のチームが
私達のデータを再利用する人たちから

00:45:12.025 --> 00:45:13.991
よく聞くことと似ています

00:45:15.002 --> 00:45:16.638
個々のデータポイントは適正でも

00:45:16.639 --> 00:45:20.163
オントロジーなどで見なければ

00:45:20.164 --> 00:45:21.857
それは…

00:45:22.388 --> 00:45:26.437
なぜこれが起こるかの
もっとも問題となる点は

00:45:26.437 --> 00:45:30.736
ウィキデータの編集の多くが

00:45:30.736 --> 00:45:34.544
個々の項目で起こっていて

00:45:34.545 --> 00:45:36.201
項目が編集しています

00:45:37.653 --> 00:45:42.075
例えばそのグラフの他の部分への

00:45:42.075 --> 00:45:44.245
全体への影響を理解していない
ことがあります

00:45:45.265 --> 00:45:50.040
個々のローカルでの編集の影響を
もっと可視化できる方法について

00:45:50.041 --> 00:45:53.185
アイデアがある方がいれば

00:45:54.005 --> 00:45:57.550
誠実に編集を加える人たちに

00:45:57.550 --> 00:46:02.633
その影響を見せることができれば

00:46:03.214 --> 00:46:04.474
これは探求する価値が

00:46:04.481 --> 00:46:06.481
あると思います

00:46:06.939 --> 00:46:12.237
わあ では君 そして君 そして君

00:46:12.237 --> 00:46:14.238
（参加者３）ディスカッションの後で

00:46:14.238 --> 00:46:18.262
ジェームスの言ったことに
同意を示したいです

00:46:18.263 --> 00:46:22.467
基本的にもっと危険なものは
階層でしょう

00:46:22.468 --> 00:46:23.910
階層ではなくてもっと一般的に

00:46:23.911 --> 00:46:28.022
ウィキデータ内のサブクラスの関連の
意味論でしょう

00:46:28.022 --> 00:46:32.561
この会議のための
最近 言語を学んでいます

00:46:32.562 --> 00:46:35.257
例えば多くの場合

00:46:35.257 --> 00:46:39.463
言語は同じもののサブクラス
そして一部です

00:46:39.463 --> 00:46:43.577
つまり柔軟なオントロジーを
持っているといえます

00:46:43.577 --> 00:46:46.256
ウィキデータはときどき
それを自由に表現します

00:46:46.256 --> 00:46:47.257
なぜなら

00:46:47.258 --> 00:46:50.721
言語のオントロジーは
政治的にも複雑ですね

00:46:50.722 --> 00:46:55.038
不明瞭のレベルを表現する立場で
あるのもいいです

00:46:55.038 --> 00:46:57.983
しかしそれの機械解読をしたければ

00:46:57.984 --> 00:46:59.468
それは非常に問題です

00:46:59.468 --> 00:47:00.468
そしてまた

00:47:00.469 --> 00:47:03.686
オントロジーは
元々 私達のものであった何かから

00:47:03.687 --> 00:47:05.490
インポートされたことはないと思います

00:47:05.491 --> 00:47:08.321
言ってみれば初期ウィキピディアから
集めれたものです

00:47:08.322 --> 00:47:11.324
このShape Expressionはいいけど

00:47:11.325 --> 00:47:15.575
ウィキデータのオントロジーを
外部の資料で

00:47:15.576 --> 00:47:18.191
検証したり修正をしたりもでき

00:47:18.191 --> 00:47:20.026
素晴らしいアイデアですが
最後に

00:47:20.027 --> 00:47:25.440
外部のオントロジーをウィキデータに
反映することで終わりますか？

00:47:25.441 --> 00:47:28.281
そしてまた外部の資料から

00:47:28.281 --> 00:47:30.642
決して集められない私達のオントロジーの
中核はどうすればいいでしょう

00:47:30.643 --> 00:47:32.248
どのように修正すべきでしょうか？

00:47:32.248 --> 00:47:35.276
それはそれ自体の問題になるでしょう

00:47:35.277 --> 00:47:39.010
外部の何かで
オントロジーを検証するアイデアから

00:47:39.010 --> 00:47:41.333
独立して注目しなければ
ならなくなるでしょう

00:47:49.353 --> 00:47:53.379
（参加者４）拘束やシェープで
できることは

00:47:53.380 --> 00:47:54.769
とても素晴らしいですが

00:47:55.205 --> 00:47:58.481
主点ははっきりしていく…

00:47:58.482 --> 00:48:03.229
なぜならデータに何を期待するかが
明瞭にできるようになったからです

00:48:03.229 --> 00:48:06.893
以前は個々にツールや
スクリプトを作る必要があり

00:48:06.894 --> 00:48:10.601
目につきやすく
それについて議論できます

00:48:10.602 --> 00:48:13.641
しかし課題は良し悪しではなく

00:48:13.642 --> 00:48:15.870
期待です

00:48:15.870 --> 00:48:18.105
人によって
ウィキデータでどうモデルするかは

00:48:18.106 --> 00:48:20.737
異なった期待と議論があるでしょう

00:48:21.246 --> 00:48:23.095
そしてこれは…

00:48:23.096 --> 00:48:26.280
現在の状況はその方向に
一歩進み

00:48:26.281 --> 00:48:28.041
これに取り組むには

00:48:28.042 --> 00:48:31.041
技術的な知識が必要となるので

00:48:31.042 --> 00:48:35.721
この拘束を可視化するための

00:48:35.722 --> 00:48:40.915
それを理解しやすい
たぶん自然な言語に変換するための

00:48:40.939 --> 00:48:43.768
方法が求められ
良し悪し自体はあまり問題ではないです

00:48:44.925 --> 00:48:45.925
（リディア）はい

00:48:50.986 --> 00:48:53.893
（参加者５）クオリティについて
賛同したいのは…

00:48:53.894 --> 00:48:57.010
私はたくさんの問題を見つけました

00:48:58.838 --> 00:49:02.330
インスタンスとサブクラスの間の
意見の差にも行き当たりました

00:49:02.331 --> 00:49:05.963
これらの状況のエラーだと思い

00:49:05.963 --> 00:49:11.521
とても時間のかかるプロセスを
探しました

00:49:11.522 --> 00:49:14.840
私が見つけたのは「とても
興味深い項目を見つけたら 何か…

00:49:14.840 --> 00:49:17.347
そして派生するすべての
ステートメントを見つけるに

00:49:17.347 --> 00:49:21.628
すべてのサブクラスの
インスタンスを使おう」

00:49:21.628 --> 00:49:26.215
これはこれらのエラーを見つける
とても有効な方法です

00:49:26.215 --> 00:49:29.427
しかしShape Expressionができるか…

00:49:29.841 --> 00:49:31.582
何か…

00:49:31.583 --> 00:49:36.934
これらの問題を解消するツールとして
使えれば…でも…

00:49:40.514 --> 00:49:43.041
（参加者６）構造的な足跡があれば…

00:49:45.910 --> 00:49:49.310
構造的な足跡があれば
改ざん可能な…

00:49:49.310 --> 00:49:51.191
見てみて

00:49:51.192 --> 00:49:54.350
これはできると…
しかしこれが単に

00:49:54.350 --> 00:49:56.640
現実のものを
マップしようとしているだけなら

00:49:56.640 --> 00:49:59.450
とてもたくさんの頭脳が必要でしょう

00:50:05.810 --> 00:50:09.081
（参加者７）Apple Sire Knowlege の
パブロ・メンデスです

00:50:09.081 --> 00:50:12.548
私達はどうプロジェクトとコミュニティを
助けるかを見つけるために集まっていますが

00:50:12.548 --> 00:50:15.464
クリスティーナは間違って
私達が欲しいものを尋ねました

00:50:16.194 --> 00:50:19.880
（笑）そこで私が思うのは

00:50:19.880 --> 00:50:24.017
検証可能性に関して
多くのことが求められます

00:50:24.017 --> 00:50:26.398
それはプロジェクトやコミュニティ

00:50:26.398 --> 00:50:28.841
その信頼性の中核となるもののひとつです

00:50:28.841 --> 00:50:32.322
すべてのステートメントは等しくなく
とても争われるものや

00:50:32.322 --> 00:50:34.071
簡単に推測できるものとか

00:50:34.071 --> 00:50:35.772
例えば誰かの誕生日は簡単に
検証でき

00:50:35.772 --> 00:50:38.943
今日のキーノートのように
性別はもっと複雑です

00:50:40.063 --> 00:50:43.441
もう少しデータのクオリティの分野で

00:50:43.441 --> 00:50:47.255
信頼性と検証可能性に関して
知っていることを話してもらえますか

00:50:54.545 --> 00:50:58.440
あまりなければ
もっとあって欲しいと思います（笑）

00:51:00.510 --> 00:51:02.672
（リディア）はい

00:51:03.822 --> 00:51:06.516
明らかにあまり言うことがないようです（笑）

00:51:07.666 --> 00:51:12.404
（アンドレア）できることがたくさんありますが
昨日 あなたと話したように

00:51:12.404 --> 00:51:16.814
昨日習った私の好みの例は
もう昨日拝み倒されたものですが

00:51:16.814 --> 00:51:19.579
Q2 地球に行くと

00:51:19.579 --> 00:51:22.451
地球は平面というステートメントがあります

00:51:23.476 --> 00:51:26.510
この例が大好きです

00:51:26.510 --> 00:51:28.963
なぜならそれを主張するコミュニティがあり

00:51:29.203 --> 00:51:31.128
検証可能なリソースがあるからです

00:51:31.335 --> 00:51:33.191
これは誠実な例で

00:51:33.191 --> 00:51:35.817
拝み倒されるべきでなく
ウィキデータにあるべきです

00:51:36.124 --> 00:51:39.664
Shape Expressionは

00:51:39.664 --> 00:51:42.161
ここで非常に役立ちます

00:51:43.141 --> 00:51:45.775
このユースケースにとても
関心があるとか

00:51:45.775 --> 00:51:47.652
これは同意しないユースケースとか

00:51:47.652 --> 00:51:53.119
しかしまたこれはいいけど
関心があるというユースケースもあります

00:51:53.119 --> 00:51:55.349
ここに例があるとします
グルコースがあります

00:51:55.349 --> 00:51:56.419
生物学者なら

00:51:56.419 --> 00:51:59.399
グルコースの分子構造の
化学的拘束には興味がないでしょう

00:51:59.399 --> 00:52:03.041
すべてのグルコースに関することは
同じです

00:52:03.041 --> 00:52:05.816
でも化学者なら
これを聞くと気になると思います

00:52:05.816 --> 00:52:08.281
200ほどのものがあります

00:52:08.281 --> 00:52:10.903
だから複雑のShape Expressionがあります

00:52:10.903 --> 00:52:12.501
ここで
化学者の立場で

00:52:12.501 --> 00:52:13.833
これに対応します

00:52:13.833 --> 00:52:16.741
そしてあなたが
生物学的なユースケースから

00:52:16.741 --> 00:52:19.447
Shape Expressionを適用したいとします

00:52:19.447 --> 00:52:20.721
そして共同したければ

00:52:20.721 --> 00:52:25.138
エリックと ShExについて
話すとよいでしょうが

00:52:25.138 --> 00:52:28.738
この行程はまだ始まったばかりですが

00:52:28.738 --> 00:52:31.660
この分野で非常に
重要なものと思っています

00:52:34.230 --> 00:52:35.983
（リディア）あちらの方

00:52:40.682 --> 00:52:46.295
（参加者８）ディスカッションでの
幾つかの点についてアイデアがあります

00:52:46.295 --> 00:52:49.827
失わないように…
３つのアイデアが…

00:52:51.187 --> 00:52:55.815
ちょっと前にジェームスが言ったことで

00:52:55.815 --> 00:52:58.834
上部のオントロジーのための開始から

00:52:58.834 --> 00:53:01.840
ウィキデータにはとても
大きな問題があります

00:53:02.810 --> 00:53:05.411
WikidataConで２年前に
話しました

00:53:05.411 --> 00:53:07.483
そしてウィキマニアについて
話し合いました

00:53:07.483 --> 00:53:08.889
ウィキデータの会議があると

00:53:08.889 --> 00:53:11.068
いつもこれを話します

00:53:11.068 --> 00:53:15.951
なぜなら目につくレベルの
とても大きな問題だからです

00:53:15.951 --> 00:53:22.886
何がエンティティで
何が workで 何も分野か

00:53:22.886 --> 00:53:25.502
そして芸術
もっとも大きな概念です

00:53:27.152 --> 00:53:33.018
これは実際 グローバルなオントロジーの
最大の弱点です

00:53:33.018 --> 00:53:38.815
なぜなら人々は常にこれを整理し

00:53:38.815 --> 00:53:42.707
すべてを線で分けようとしているからです

00:53:43.887 --> 00:53:46.827
覚えている人もいると思いますが

00:53:46.827 --> 00:53:51.716
世界中のすべての市を無意識に
壊した人がいます

00:53:51.716 --> 00:53:57.484
地理的な項目ではないので
拘束違反に満ちて

00:53:57.484 --> 00:54:01.035
誠実な意図でしたが

00:54:01.035 --> 00:54:04.090
項目の間違いを直そうとしていたのに

00:54:04.090 --> 00:54:06.688
すべてを壊していしまいました

00:54:07.508 --> 00:54:10.210
これをどのように解決できるが
私はわかりません

00:54:11.130 --> 00:54:16.261
なぜなら実際に写してこれる
外部の機関がないからです

00:54:16.261 --> 00:54:18.486
皆さんが作業している

00:54:18.486 --> 00:54:21.719
例えば 芸能データベースだとします

00:54:21.719 --> 00:54:24.684
直接 芸能のラベルに行くか

00:54:24.684 --> 00:54:29.221
あるいはエンティティがなにかの
論理的概念には行かず

00:54:29.221 --> 00:54:31.681
これは実際に…

00:54:31.681 --> 00:54:34.671
このレベルで機能している
データベースは知りませんが

00:54:34.671 --> 00:54:38.221
これがウィキデータの弱点です

00:54:38.221 --> 00:54:41.521
データのクオリティを話すにおいて

00:54:41.521 --> 00:54:43.802
実際もっと大きなといえるでしょう

00:54:45.242 --> 00:54:49.512
ここで言ったと同じ様に…

00:54:49.512 --> 00:54:51.644
失礼 話題を変えてしまっています

00:54:51.644 --> 00:54:55.389
クオリティについては
別のセッションで言及しました

00:54:55.389 --> 00:55:00.031
それに関しては 実際
よいモデリングを行っている人がいて

00:55:00.031 --> 00:55:02.364
ShExを活用したりして
それを行っています

00:55:03.054 --> 00:55:07.358
ウィキデータでは見れません
ShExは見えません

00:55:07.358 --> 00:55:09.007
ディスカッションページでは

00:55:09.007 --> 00:55:10.525
WikiPeojectを見ず

00:55:10.525 --> 00:55:13.612
そして時には
プロパティのトークページも見ません

00:55:13.612 --> 00:55:19.673
そこには明確に a)このプロパティが
そのために使用されると記載されています

00:55:20.453 --> 00:55:24.218
先週あるプロパティに
拘束を加えました

00:55:24.218 --> 00:55:26.839
そのプロパティの創作の
ディスカッションに

00:55:26.839 --> 00:55:29.157
この拘束は明確に記述されていました

00:55:29.157 --> 00:55:33.433
私はその拘束を加える技術部分を
作っただけですが

00:55:33.433 --> 00:55:37.420
誰かに「私の編集をすべて
台無しにした」と言われました

00:55:37.420 --> 00:55:41.297
その人は過去２年 このプロパティを
間違って使っていました

00:55:41.297 --> 00:55:46.872
プロパティは実際はとても明瞭ですが
警告などがなく…

00:55:46.872 --> 00:55:50.332
だからウィキマニアの
ピンクのポニーのように

00:55:50.332 --> 00:55:54.278
WikiPeojectをもって見やすく
ShExをもっと見やすくすべきです

00:55:54.278 --> 00:55:56.992
それがクリスティーナは
言ったことです

00:55:56.992 --> 00:56:02.169
既存の解決策が見られていないという
問題があるんです

00:56:02.169 --> 00:56:04.667
このセッションでは

00:56:04.667 --> 00:56:08.288
もっとShExを作ろうとか

00:56:08.288 --> 00:56:11.232
整理する人の作業を促進しようとか
話していますが

00:56:11.992 --> 00:56:14.262
ウィキデータの一日目から
整理をしてきていて

00:56:14.262 --> 00:56:17.617
グローバルには追いついて行けていません

00:56:17.617 --> 00:56:20.437
追いつけていけない訳は…

00:56:20.437 --> 00:56:23.075
名前が複雑だと知っていて

00:56:23.075 --> 00:56:26.211
私だけで整理の作業をしていて

00:56:26.211 --> 00:56:28.900
すべての中国人の研究者に

00:56:28.900 --> 00:56:31.812
ラテン語の名前を追加する人がいるとしたら

00:56:31.812 --> 00:56:35.950
何ヶ月も整理にかかり
一人ではやっていけません

00:56:35.950 --> 00:56:39.548
ではその人はバッチで
その作業をしたでしょう

00:56:39.548 --> 00:56:41.066
私たちが必要なのは…

00:56:41.066 --> 00:56:44.227
ツールの問題ではなくと
見て理解されるというが問題です

00:56:44.227 --> 00:56:46.451
既にツールはたくさんあります

00:56:46.451 --> 00:56:50.268
（リディア）そうですね
しかし時間のようで（笑）

00:56:50.268 --> 00:56:52.113
締めくくりましょう

00:56:52.113 --> 00:56:54.185
たくさんのコメントを
ありがとうございました

00:56:54.185 --> 00:56:56.461
今日 この後もディスカッションを
続けてください

00:56:56.461 --> 00:56:58.553
皆さんのご意見ありがとうございました

00:56:58.553 --> 00:57:03.411
（拍手）