1 00:00:00,822 --> 00:00:03,472 データクオリティパネル 2 00:00:03,748 --> 00:00:05,098 クロディア・ミューラービン、 ルーカス・ウェアミニスター 3 00:00:05,098 --> 00:00:06,671 ホゼ・エミリオ・ラビラ・ガヤ、 クリスティナ・サラスナ、アンドレア・ 4 00:00:06,671 --> 00:00:09,476 データクオリティパネルの皆さん こんにちは 5 00:00:09,658 --> 00:00:15,761 多くの人が私たちのデータが正しいことを 頼るのでデータクオリティは重要です 6 00:00:15,761 --> 00:00:19,289 だからデータクオリティについて 話し合いましょう 7 00:00:20,029 --> 00:00:26,000 4人の講演者は データクオリティについて短い紹介をし 8 00:00:26,000 --> 00:00:29,539 その後で質疑を行います 9 00:00:30,130 --> 00:00:32,234 ではまずルーカスから 10 00:00:34,385 --> 00:00:35,385 ありがとう 11 00:00:35,901 --> 00:00:39,899 ルーカスです まずウィキデータに既にある 12 00:00:39,899 --> 00:00:43,806 データクオリティツールと 開発されていて公開マジかなものについての 13 00:00:43,807 --> 00:00:46,109 概要から始めます 14 00:00:46,932 --> 00:00:50,623 いくつかのテーマの グループに分けました 15 00:00:50,623 --> 00:00:53,761 エラーを見つけやすくする 問題に対処しやすくする 16 00:00:53,762 --> 00:00:56,322 データにより検証し 問題に気づきやすくする 17 00:00:56,945 --> 00:01:02,616 一般的なエラーの元を修正する 既存のデータの質を維持する 18 00:01:02,616 --> 00:01:04,846 そして人によるキューレーション 19 00:01:05,063 --> 00:01:09,874 そして現在利用可能なものは プロパティの拘束からです 20 00:01:10,138 --> 00:01:12,421 ウィキデータで これを見たことがあると思います 21 00:01:12,422 --> 00:01:15,130 このような 内部のデータの均一性をチェックする 22 00:01:15,130 --> 00:01:17,241 アイコンが出ることがあるでしょう 23 00:01:17,242 --> 00:01:20,800 例えば あるイベントが他に続くなら 24 00:01:20,801 --> 00:01:23,760 他のイベントもこのイベントに 続くべきです 25 00:01:23,761 --> 00:01:27,161 このWikidataConの項目では それが見られません 26 00:01:27,162 --> 00:01:29,360 この機能はできてまだ数日かも しれません 27 00:01:30,040 --> 00:01:34,461 あるいはこれが制限しすぎだったり 簡単すぎなら 28 00:01:34,461 --> 00:01:38,080 Query Service を使って チェックを自分で書くこともできます 29 00:01:38,081 --> 00:01:41,892 もちろんQuery Serviceは 多くのことに有効ですが 30 00:01:41,892 --> 00:01:44,543 エラーを見つけることもできます 31 00:01:44,794 --> 00:01:46,974 ひとつ間違いを見つけたら 32 00:01:46,975 --> 00:01:49,539 他の場所もチェックし 33 00:01:49,539 --> 00:01:51,608 他の人が同じエラーをしていないか 34 00:01:51,608 --> 00:01:53,708 Query Serviceで見つけられます 35 00:01:53,708 --> 00:01:55,259 あるいは2つを組み合わせて 36 00:01:55,259 --> 00:01:57,874 拘束違反を Query Serviceで探せます 37 00:01:57,875 --> 00:02:00,910 例えば ある部分にだけあるエラーや 38 00:02:00,910 --> 00:02:04,122 WikiProjectの あなたの関連した部分だけのエラーなどです 39 00:02:04,272 --> 00:02:07,828 でも残念なことに その結果は現在のところ完全ではありません 40 00:02:08,422 --> 00:02:09,877 改訂スコアリングもあります 41 00:02:10,690 --> 00:02:13,186 これは最近の変更からだけ思いますが 42 00:02:13,186 --> 00:02:16,217 自動アセスメントのウォッチリストに入れて 43 00:02:16,217 --> 00:02:19,949 その編集が誠実なものかどうか 44 00:02:19,949 --> 00:02:22,629 また被害を与えるものかどうかを 見ることができます 45 00:02:22,629 --> 00:02:24,205 これは2次元だと思います 46 00:02:24,206 --> 00:02:26,426 だから被害を与えるけど 47 00:02:26,426 --> 00:02:29,898 誠実なものかどうかに注目して 48 00:02:29,899 --> 00:02:32,523 特に友好的な気分なら 49 00:02:32,524 --> 00:02:35,293 これらの編集者に 50 00:02:35,293 --> 00:02:39,470 「貢献してくれてありがとう 次回はこのようにしてください」など… 51 00:02:40,561 --> 00:02:42,186 でもそうでなければ 52 00:02:42,187 --> 00:02:44,452 誠実でないものや 被害を与えるものを 53 00:02:44,453 --> 00:02:46,660 元に戻すこともできます 54 00:02:47,544 --> 00:02:49,761 似たものに エンティティ・スコアリングがあり 55 00:02:49,762 --> 00:02:52,350 これは変更が加えられた 編集をスコアリングするのはなく 56 00:02:52,350 --> 00:02:53,904 全体の改訂をスコアリングします 57 00:02:53,904 --> 00:02:56,483 これにはリディアは会議の当初に 話したのと 58 00:02:56,483 --> 00:02:59,863 同じ質の検証が使用されると 思います 59 00:03:00,372 --> 00:03:04,569 このユーザースクリプトで これらの1から5のスコアを与えます 60 00:03:04,570 --> 00:03:08,176 これは現在の項目のクオリティだと 思います 61 00:03:10,043 --> 00:03:14,328 1次資料ツールは すべてのインポートしたい、しかし 62 00:03:14,328 --> 00:03:18,374 直接ウィキデータに入れられる質でない データベースのためのものです 63 00:03:18,374 --> 00:03:20,335 だからこれを1次資料ツールで 処理し 64 00:03:20,336 --> 00:03:22,956 それから実際に人が判断し 65 00:03:22,956 --> 00:03:26,024 個々のステートメントを 加えるかどうかを決めます 66 00:03:28,595 --> 00:03:31,901 座標を地図で示すことは とても便利な機能ですが 67 00:03:31,901 --> 00:03:33,928 クオリティコントロールにも 有用です 68 00:03:33,928 --> 00:03:36,937 これがウィキデータ・ドイツの オフィスのはずで 69 00:03:36,938 --> 00:03:39,400 座標がインド海の中にあれば 70 00:03:39,401 --> 00:03:41,529 何か間違っていると気が付きます 71 00:03:41,530 --> 00:03:44,790 単に数字を見るより 簡単にわかります 72 00:03:46,133 --> 00:03:49,576 これは 相対的完全性 インディケータというガジェットで 73 00:03:49,577 --> 00:03:52,480 この小さなアイコンで示され 74 00:03:53,007 --> 00:03:55,652 その項目が完成しているかどうか 75 00:03:55,652 --> 00:03:57,858 あるいはどのプロパティが 欠けていそうかを示し 76 00:03:57,858 --> 00:04:00,209 項目を編集しているときに便利なもので 77 00:04:00,209 --> 00:04:03,172 もし馴染みない分野で 78 00:04:03,172 --> 00:04:05,661 使うべき正確なプロパティが わからないときには 79 00:04:05,662 --> 00:04:08,230 とても便利なガジェットです 80 00:04:08,774 --> 00:04:11,971 Shape Expression があります 81 00:04:11,971 --> 00:04:15,624 アンドレアかホゼが これらについてお話すると思いますが 82 00:04:15,624 --> 00:04:19,137 基本的には 持っているデータをそのテーマに対して 83 00:04:19,137 --> 00:04:21,258 比較するためのとても有効な方法です 84 00:04:21,258 --> 00:04:23,570 どのステートメントが 特定のエンティティを持つべきか 85 00:04:23,570 --> 00:04:25,867 他のエンティティがリンクされるべきか どのように完成されるべきか 86 00:04:26,229 --> 00:04:29,374 それによって間違いを見つけることができます 87 00:04:30,366 --> 00:04:32,181 えーと これですね 88 00:04:32,181 --> 00:04:34,696 Integraality または プロパティ・ダッシュボード 89 00:04:34,696 --> 00:04:36,953 既にあるデータの概要を示します 90 00:04:36,953 --> 00:04:39,657 例えば WikiProject Red Pandaの このフォームで 91 00:04:39,657 --> 00:04:41,681 ここにほとんどすべての赤パンダの 92 00:04:41,682 --> 00:04:43,561 性別があるのかわかります 93 00:04:43,561 --> 00:04:46,854 誕生日はどこの動物園かによって かなり変わります 94 00:04:46,854 --> 00:04:50,255 亡くなったパンダは ほとんどいないですね 95 00:04:50,317 --> 00:04:52,600 よっかた かわいいからね 96 00:04:53,699 --> 00:04:55,654 これはとても便利です 97 00:04:56,377 --> 00:04:59,185 そしてOKすると 次に出てくるのは 98 00:04:59,889 --> 00:05:03,784 ウィキデータ Bridge クライアント編集として知られているものです 99 00:05:03,785 --> 00:05:07,076 ウィキピディア Infobox から ウィキデータを編集します 100 00:05:07,675 --> 00:05:11,395 これによりより多くの 閲覧がなされます 101 00:05:11,395 --> 00:05:14,302 なぜならもっと多くの人が これらのデータを見るからです 102 00:05:14,302 --> 00:05:18,841 これによってウィキピディアでより ウィキデータが使われるようになるでしょう 103 00:05:18,841 --> 00:05:21,420 そしてもっと多くの人に気づかれるように なるでしょう 104 00:05:21,420 --> 00:05:23,857 例えばデータが古かったり 更新が必要なときは 105 00:05:23,857 --> 00:05:27,000 ウィキデータ自体だけで気が付かれないことを 知ることができます 106 00:05:28,380 --> 00:05:30,656 Tainted Referencesもあります 107 00:05:30,657 --> 00:05:34,679 これはステートメントの値を編集すると 108 00:05:34,683 --> 00:05:37,279 タイポなどを直している場合は 別として 109 00:05:37,280 --> 00:05:39,373 リファレンスも更新することがあるでしょう 110 00:05:39,897 --> 00:05:43,662 このTainted Referencesは 編集している人にそれを示す他に 111 00:05:43,663 --> 00:05:49,756 他の編集者にも他に どのような編集がされたか示します 112 00:05:49,756 --> 00:05:53,241 ステートメントの値が変更され リファレンスが更新されているいないを知り 113 00:05:53,241 --> 00:05:57,666 それらを修正するか どうするかを決めることができます 114 00:05:57,737 --> 00:05:59,566 もっと修正を入れるか 115 00:05:59,566 --> 00:06:02,796 そのままでリファレンス更新は 必要がないとか… 116 00:06:03,543 --> 00:06:09,336 これはSigned statementsに関して 117 00:06:09,336 --> 00:06:12,355 データの提供者が心配する… 118 00:06:14,131 --> 00:06:17,231 UNESCOかなにかが参照された ステートメントがあり 119 00:06:17,232 --> 00:06:19,872 突然 誰かがそのステートメントに 損傷を加えたら 120 00:06:19,873 --> 00:06:22,827 UNESCOなどの機関が 121 00:06:22,827 --> 00:06:26,992 その損傷されたステートメントを 出したように見られる恐れがあります 122 00:06:26,993 --> 00:06:28,706 だからSigned statementsは 123 00:06:28,706 --> 00:06:31,488 暗号的にこのリファレンスに サインを入れることができます 124 00:06:31,488 --> 00:06:33,562 編集を防ぐことはできません 125 00:06:34,169 --> 00:06:37,744 でも少なくとも 誰かがステートメントを損傷するか 126 00:06:37,744 --> 00:06:40,255 あるいは編集したりすると サインは無効になります 127 00:06:40,255 --> 00:06:43,851 そしてそのステートメントが その機関が入れたものでないとわかります 128 00:06:43,851 --> 00:06:47,484 もし正しい編集なら そのステートメントを 再度サインすることができます 129 00:06:47,484 --> 00:06:49,851 または編集しなおすことができます 130 00:06:51,203 --> 00:06:54,166 それから 素晴らしいものとして 131 00:06:54,166 --> 00:06:56,846 Citoidがウィキデータにはあります 132 00:06:57,379 --> 00:07:01,340 これにはURLを貼り付けたり 識別子 またはISBN 133 00:07:01,340 --> 00:07:05,260 ウィキデータIDなど 基本的に 何でもVisual Editorに入れられ 134 00:07:05,260 --> 00:07:08,241 きれいにフォーマットされた リファレンスを作成し 135 00:07:08,242 --> 00:07:11,049 それにはすべてのデータが含まれていて とても使いやすいです 136 00:07:11,049 --> 00:07:14,337 それに比べてウィキデータでは リファレンスを入れたければ 137 00:07:14,338 --> 00:07:18,801 リファレンスURLとタイトル 著作者名 138 00:07:18,802 --> 00:07:20,449 出版元、出版日 139 00:07:20,450 --> 00:07:25,141 改訂日などを少なくとも加える必要があり とても厄介です 140 00:07:25,141 --> 00:07:29,261 ウィキデータにCitoidを統合することで それが簡単になります 141 00:07:30,245 --> 00:07:33,604 私は以上です 142 00:07:33,604 --> 00:07:36,400 ではクリスティーナに渡します 143 00:07:37,788 --> 00:07:42,339 (拍手) 144 00:07:43,780 --> 00:07:45,471 クリスティーナです 145 00:07:45,472 --> 00:07:47,672 チューリッヒ大学の研究員で 146 00:07:47,673 --> 00:07:51,417 スイスのコミュニティの 活動者でもあります 147 00:07:51,557 --> 00:07:57,658 クラウディア・ミューラーと私が WikidataConにこれを提示した際 148 00:07:57,658 --> 00:08:01,278 期待したことは 今年の始めに 149 00:08:01,278 --> 00:08:05,250 データクオリティのワークショップや その他のウィキマニアのセッションで 150 00:08:05,250 --> 00:08:07,650 始めた議論を継続していくことです 151 00:08:07,650 --> 00:08:09,204 今日の講演は基本的に 152 00:08:09,204 --> 00:08:11,482 コミュニティと私達が 集めた考察を提供し 153 00:08:11,482 --> 00:08:16,645 会話を続けていくことが目的です 154 00:08:16,645 --> 00:08:20,932 これからみなさんと交流を 続けていきたいと思います 155 00:08:20,932 --> 00:08:23,690 私達がもっと重要と思うのは 156 00:08:23,690 --> 00:08:26,167 コミュニティの様々なユーザーに 157 00:08:26,167 --> 00:08:32,471 何が必要か そしてデータクオリティの 問題が何かを問い続けることです 158 00:08:32,471 --> 00:08:34,730 編集する人たちだけでなく コードを書く人や 159 00:08:34,730 --> 00:08:36,510 データを利用する人 160 00:08:36,510 --> 00:08:40,220 また何が起こったか編集履歴を 実際 利用する研究者など 161 00:08:40,220 --> 00:08:41,691 すべてのユーザーを含みます 162 00:08:42,571 --> 00:08:47,614 ウィキデータに存在する約80の ツールを評価し 163 00:08:47,614 --> 00:08:52,826 それらを異なったデータクオリティの次元で 整理しました 164 00:08:52,826 --> 00:08:54,241 実際に気がついたことは 165 00:08:54,241 --> 00:08:57,780 多くのツールは 完成性をモニターしていて 166 00:08:57,780 --> 00:09:02,960 実際…インターリンクを 可能にするものもありますが 167 00:09:02,960 --> 00:09:08,241 多様性を検証するツールが 欠けていて 168 00:09:08,241 --> 00:09:13,750 これは実際ウィキデータに 特にウィキデータのデザイン原則に 169 00:09:13,750 --> 00:09:15,932 組み込めるもののひとつで 170 00:09:15,932 --> 00:09:17,297 多様性をもたせ 171 00:09:17,297 --> 00:09:19,818 異なった出典からの 172 00:09:19,818 --> 00:09:22,491 異なった値の 異なったステートメントを含めます 173 00:09:22,491 --> 00:09:24,384 これらは2次資料になるので 174 00:09:24,384 --> 00:09:26,546 実際どれだけの複数の ステートメントがあるか 175 00:09:26,546 --> 00:09:31,291 どのように どれだけを向上できるか等を 示すツールはありません 176 00:09:31,291 --> 00:09:33,200 また多様なステートメントが存在する 177 00:09:33,200 --> 00:09:35,451 理由もよくわかりません 178 00:09:36,191 --> 00:09:39,963 だからこれらのコミュニティでの ディスカッションから 179 00:09:39,963 --> 00:09:43,271 まだ注目すべきチャレンジが 浮き上がってきました 180 00:09:43,271 --> 00:09:47,538 例えばこれらのクラウドソーシングの コミュニティがあることは 181 00:09:47,538 --> 00:09:50,914 データやグラフの異なった部分に 182 00:09:50,914 --> 00:09:53,539 取り組む異なったグループの人々がいて 183 00:09:53,539 --> 00:09:57,053 また異なったバックグラウンドの知識を 注ぎ込まれるという利点がありますが 184 00:09:57,053 --> 00:10:02,043 実際は異なった人々が 異なったプロパティを異なった方法で使い 185 00:10:02,043 --> 00:10:05,125 エンティティの識別子に 異なったものを期待するので 186 00:10:05,125 --> 00:10:08,801 何か均一なものに整えるのは 難しいです 187 00:10:09,381 --> 00:10:11,370 グローバルな状態を捉えるための 188 00:10:11,370 --> 00:10:15,843 ツールがもっと必要だと いう声も聞かれました 189 00:10:15,843 --> 00:10:20,946 どのエンティティが 完成性の点で欠けているか 190 00:10:20,946 --> 00:10:26,340 また人々が現在 どのような作業をしているか 191 00:10:26,340 --> 00:10:29,713 そして異なった言語間のみでなく かつそのWikiProjectと 192 00:10:29,713 --> 00:10:32,251 異なったウィキメディアの プラットフォームに渡る 193 00:10:32,251 --> 00:10:35,586 緊密な共同についての 言及もありました 194 00:10:35,586 --> 00:10:39,211 これらのディスカッションからの すべての書き留められたコメントを 195 00:10:39,211 --> 00:10:42,221 Etherpadのここのリンクに 196 00:10:42,221 --> 00:10:46,149 またウィキマニアのウィキページに 公開しました 197 00:10:46,149 --> 00:10:49,059 いくつかの解決策は 実際 異なったWikiProjectで 198 00:10:49,059 --> 00:10:51,442 開発された最善の実践方法を 199 00:10:51,442 --> 00:10:55,681 共有する方向へ向かうように見えますが 200 00:10:55,681 --> 00:10:58,701 チームでの仕事を整理し 201 00:10:58,701 --> 00:11:03,841 少なくとも誰が作業をしているか 理解できるツールも求められています 202 00:11:03,841 --> 00:11:08,234 またもっとショーケースが求められ 203 00:11:08,234 --> 00:11:12,175 よりよい方法でそれらを作成できる テンプレートが求められています 204 00:11:13,494 --> 00:11:17,105 自治体オープンデータの組織との 205 00:11:17,105 --> 00:11:18,756 コンタクトを通じて 206 00:11:18,756 --> 00:11:20,421 そして特に 207 00:11:20,421 --> 00:11:22,841 チューリッヒ市と州と接していると 208 00:11:22,841 --> 00:11:26,278 ウィキデータに興味が持たれている ことがわかります 209 00:11:26,278 --> 00:11:28,972 つまり誰でもアクセスして データを見ることができる場所で 210 00:11:28,972 --> 00:11:33,897 データを皆に提供したいからです 211 00:11:33,897 --> 00:11:35,886 だからその目的に沿うには 212 00:11:35,886 --> 00:11:39,231 何かのクオリティの識別子を持つことが とても気が惹かれるでしょう 213 00:11:39,231 --> 00:11:41,490 ウィキでは既にありますが 214 00:11:41,490 --> 00:11:44,090 また SPARQLの結果にも それらがあると良いでしょう 215 00:11:44,090 --> 00:11:46,742 そしてそのコミュニティからの結果が 信頼できるかどうかわかります 216 00:11:46,742 --> 00:11:50,861 さらに持っているデータのどの部分が ウィキデータに有益かが理解でき 217 00:11:50,861 --> 00:11:55,976 そしてそれらを自動的に 評価するツールが求められます 218 00:11:56,041 --> 00:12:01,136 またデータをインポートするべきか リンクするべきかを決断する 219 00:12:01,136 --> 00:12:03,894 ある種の手法かツールも必要です 220 00:12:03,894 --> 00:12:05,304 場合によっては 221 00:12:05,304 --> 00:12:08,487 自分たちのリンクのある オープンデータセットを持っている場合 222 00:12:08,487 --> 00:12:09,746 データを入れるべきか 223 00:12:09,747 --> 00:12:12,964 ウィキデータへデータセットから リンクを作るべきか 224 00:12:12,964 --> 00:12:15,540 あるいは逆方向にするかなどが あるからです 225 00:12:15,840 --> 00:12:20,043 またウィキデータのどこにウェブサイトが 参照されているかを知りたいです 226 00:12:20,044 --> 00:12:23,361 Query Serviceでそのような クエリを行うと 227 00:12:23,362 --> 00:12:25,392 タイムアウトになることもあるので 228 00:12:25,392 --> 00:12:28,181 もっとツールを作り 229 00:12:28,181 --> 00:12:32,240 これらの質問の答えが 得られるようにすべきです 230 00:12:33,148 --> 00:12:36,208 それ以外にも 231 00:12:36,208 --> 00:12:39,361 ウィキ研究者はしばしば 232 00:12:39,362 --> 00:12:42,023 編集サマリで情報が 欠けていることがあります 233 00:12:42,024 --> 00:12:45,623 様々なエディタの挙動 ツールやボット 234 00:12:45,623 --> 00:12:49,879 あるいは匿名のユーザーなど 理解する作業したとき 235 00:12:49,879 --> 00:12:53,403 私が覚えていることは 236 00:12:53,403 --> 00:12:57,514 例えば使用されたツールを 追跡する標準の方法などが 237 00:12:57,514 --> 00:13:00,057 欠けていたことです 238 00:13:00,593 --> 00:13:03,154 PetScanなどそれを既に行うツールも 239 00:13:03,155 --> 00:13:05,230 いくつかありますが 240 00:13:05,230 --> 00:13:09,250 このようなキメの細かい起源を どのように記録するかについて 241 00:13:09,250 --> 00:13:13,531 コミュニティで検討するべきでしょう 242 00:13:14,169 --> 00:13:15,321 さらに 243 00:13:15,322 --> 00:13:20,801 リンクされたデータに関するけど すべてのタイプのデータに関しない 244 00:13:20,802 --> 00:13:25,262 より強固なデータクオリティ次元を 考慮する必要があります 245 00:13:25,262 --> 00:13:30,402 リンクで可能にされる 情報取得(Information gain)を 246 00:13:30,402 --> 00:13:32,322 調べてみました 247 00:13:32,322 --> 00:13:33,881 つまり 248 00:13:33,882 --> 00:13:36,681 ウィキデータを他のデータセットに リンクする際に 249 00:13:36,682 --> 00:13:41,931 どれだけのエンティティが 実際クラシフィケーションに得られるか 250 00:13:41,931 --> 00:13:44,991 あるいは記述や また使用されている単語などが得られるかも 251 00:13:44,991 --> 00:13:46,881 考えるべきです 252 00:13:46,881 --> 00:13:51,041 簡単な例を挙げると… 253 00:13:51,042 --> 00:13:54,269 この場合 ウィキデータ 254 00:13:54,270 --> 00:13:57,771 あるいはウィキデータにリンクされた 外部のデータセンターで 255 00:13:57,772 --> 00:14:00,487 ナターシャ・ノイと呼ばれる 人のエンティティがあり 256 00:14:00,487 --> 00:14:02,601 所属やその他の情報があります 257 00:14:02,602 --> 00:14:05,239 これでOKとして 外部にリンクし 258 00:14:05,240 --> 00:14:08,919 そこにその名前のエンティティが既にあり 実際同じ値を持っているとします 259 00:14:09,670 --> 00:14:12,889 よりよい方法は 別の名前をもつものにリンクします 260 00:14:12,889 --> 00:14:16,881 このひとは2通りの方法で 名前を書くことができるので有効です 261 00:14:16,882 --> 00:14:19,714 あるいはウィキデータにない 他の情報や 262 00:14:19,715 --> 00:14:22,323 他のデータセットにない情報を 持つことができます 263 00:14:22,390 --> 00:14:24,652 もっとよい方法としては 264 00:14:24,653 --> 00:14:29,210 この情報を分類する新しい方法を持つ ターゲットデータセットを 265 00:14:29,210 --> 00:14:31,392 見ることです 266 00:14:31,393 --> 00:14:35,354 これが人であるのみでなく 他のデータセットでは 267 00:14:35,355 --> 00:14:39,525 女性であるとかなど 他の分類も言及できます 268 00:14:39,526 --> 00:14:43,401 もし他のデータセットで もっと多くの単語が使われていれば 269 00:14:43,402 --> 00:14:46,588 全体の情報を回収するものの 助けにもなります 270 00:14:47,371 --> 00:14:51,233 それに関してさらに言えることは 271 00:14:51,234 --> 00:14:55,809 フェデレーションクエリーが よりよく行われます 272 00:14:55,810 --> 00:15:00,448 マリーシェフ達による クエリーログを見ると 273 00:15:01,285 --> 00:15:04,301 オーガニックなクエリーから 274 00:15:04,302 --> 00:15:06,921 フェデレーションクエリーは ほんの少ししかないことがわかります 275 00:15:06,922 --> 00:15:12,801 実際フェデレーションはリンクされた データを持つ主なる有利な点の一つでなので 276 00:15:12,802 --> 00:15:16,903 コミュニティや ウィキデータを使う人は 277 00:15:16,903 --> 00:15:18,898 この例がもっと必要でしょう 278 00:15:18,898 --> 00:15:22,666 使用されたエンドポイントを見ると… 279 00:15:22,667 --> 00:15:25,401 これは完全なリストではなく もっとあります 280 00:15:25,402 --> 00:15:30,479 もちろんこのデータは2018年3月までの クエリーを評価していますが 281 00:15:30,480 --> 00:15:34,807 フェデレーションエンドポイントを見ると 282 00:15:34,808 --> 00:15:37,048 それらが使用されているかどうかを 見るべきです 283 00:15:37,813 --> 00:15:40,441 後のディスカッションで使用できる 284 00:15:40,442 --> 00:15:43,001 参加者の皆さんへの2つの質問は 285 00:15:43,001 --> 00:15:45,511 あなた達の必要に応じるための 286 00:15:45,511 --> 00:15:47,412 データクオリティの問題は なんであるか 287 00:15:47,412 --> 00:15:50,401 そしてまた編集や警衛のために 288 00:15:50,402 --> 00:15:52,943 必要な自動化は何かということです 289 00:15:53,838 --> 00:15:55,587 以上です ありがとうございました 290 00:15:55,779 --> 00:15:57,527 (拍手) 291 00:16:06,030 --> 00:16:08,595 (ホゼ・エミロ・ラブラ) 私が話すことは 292 00:16:08,595 --> 00:16:14,715 Shape Expressionに関連し 私達が開発しているツールです 293 00:16:15,536 --> 00:16:19,371 私はホゼ・エミロ・ラブラです 294 00:16:19,371 --> 00:16:23,215 これらのツールは異なった人によって つくられました 295 00:16:23,920 --> 00:16:28,480 主にW3C ShEx, Shape Expressions コミュニティグループに関連しています 296 00:16:28,481 --> 00:16:30,121 ShEx コミュニティグループです 297 00:16:30,144 --> 00:16:36,081 まずお話したいのは RDFShapeで これは一般的なツールです 298 00:16:36,082 --> 00:16:40,681 なぜなら Shape Expressionsは ウィキデータのためだけでなく 299 00:16:40,682 --> 00:16:44,168 一般的に RDFを検証する言語だからです 300 00:16:44,168 --> 00:16:47,568 これは私が主で開発したもので 301 00:16:47,568 --> 00:16:50,880 一般的にRDFを検証するツールです 302 00:16:50,881 --> 00:16:55,139 RDFについて学習したいとか ウィキデータでのみでなく 303 00:16:55,140 --> 00:16:58,621 RDFやSPARQL エンドポイントを 検証したいなら 304 00:16:58,622 --> 00:17:00,891 このツールをお勧めします 305 00:17:00,891 --> 00:17:03,255 また学習については 306 00:17:03,255 --> 00:17:05,640 私は大学で教えていて 307 00:17:05,641 --> 00:17:09,151 RDFを教えるにはセマンティクな ウェブコースでそれを使っています 308 00:17:09,161 --> 00:17:12,121 だからRDFを習いたいなら これはよいツールだと思います 309 00:17:13,033 --> 00:17:17,598 例えばこのツールでの RDFグラフの可視化です 310 00:17:18,587 --> 00:17:22,643 ここへ来る前 先月 311 00:17:22,643 --> 00:17:28,441 ウィキデータ用に特に RDFShapeを分岐し始めました 312 00:17:28,443 --> 00:17:33,082 これを WikiShapeと呼んで ウィキデータのプレゼンで紹介しました 313 00:17:33,082 --> 00:17:34,441 行ったことは 314 00:17:34,442 --> 00:17:38,805 ウィキデータに関連しないものを削除して 315 00:17:38,805 --> 00:17:44,801 ウィキデータ SPARQLエンドポイントなど 幾つかのものをコードに書き込みました 316 00:17:44,802 --> 00:17:49,041 ウィキベースにもできるかと 聞かれましたが 317 00:17:49,042 --> 00:17:52,000 ウィキベース用を作るのも とても簡単にできます 318 00:17:52,760 --> 00:17:56,280 このWikiShapeツールは 新しいもので 319 00:17:57,015 --> 00:17:59,843 ほとんどの機能は働くと思いますが 320 00:17:59,844 --> 00:18:02,468 機能しないものもあるでしょう 321 00:18:02,469 --> 00:18:06,281 使ってみて向上させたいと 思われた方はご連絡ください 322 00:18:06,281 --> 00:18:12,680 これは[不明瞭]キャプチャですが やってみましょう 323 00:18:15,385 --> 00:18:16,945 動くかどうかみてみましょう 324 00:18:16,953 --> 00:18:20,070 まず外に出て… 325 00:18:22,453 --> 00:18:23,453 ここ 326 00:18:24,226 --> 00:18:28,324 ここにツールがあります 327 00:18:28,324 --> 00:18:29,844 このツールでできることは 328 00:18:29,845 --> 00:18:35,275 例えば スキーマ エンティティスキーマの検証です 329 00:18:35,276 --> 00:18:38,611 ここに新しい名前空間があり Eの何か… 330 00:18:38,612 --> 00:18:44,805 例えば「human…」と書けば 331 00:18:44,806 --> 00:18:48,812 書いていく間に補完されるので チェックすることができ 332 00:18:48,812 --> 00:18:52,001 例えば 人のShpae Expressionは 333 00:18:52,790 --> 00:18:55,937 ここにあるShpae Expression です 334 00:18:55,938 --> 00:18:59,841 このエディタには シンタックスが色付けされています 335 00:18:59,842 --> 00:19:04,559 これは… 画面が小さいので 336 00:19:05,676 --> 00:19:07,590 大きくしてみましょう 337 00:19:09,194 --> 00:19:10,973 見やすくなるでしょう 338 00:19:10,973 --> 00:19:14,241 これがエディタで シンタックスが色付けされています 339 00:19:14,241 --> 00:19:17,851 このエディタは ウィキデータ Query Serviceと 340 00:19:17,851 --> 00:19:19,641 同じソースコードからできています 341 00:19:19,642 --> 00:19:23,960 例えば マウスを乗せると 342 00:19:23,961 --> 00:19:27,961 異なったプロパティの ラベルを表示します 343 00:19:27,962 --> 00:19:33,478 ウィキデータのエンティティ スキーマは単なるテキストアイデアなので 344 00:19:33,478 --> 00:19:38,601 とても便利だと思います 345 00:19:38,602 --> 00:19:42,493 このエディタは補完機能があるので よりよく 346 00:19:42,494 --> 00:19:43,743 また… 347 00:19:43,744 --> 00:19:48,241 例えば拘束を加えたければ 348 00:19:48,241 --> 00:19:51,570 「wdt:」と打って 349 00:19:51,570 --> 00:19:56,884 「author」と書いて Ctrl+Spaceと打てば 350 00:19:56,884 --> 00:19:58,922 異なった物を提供します 351 00:19:58,922 --> 00:20:02,388 これはウィキデータの Query Serviceと似ていますが 352 00:20:02,389 --> 00:20:06,445 これはShpae Expression特定のものです 353 00:20:06,445 --> 00:20:11,975 なぜならShpae Expressionの作成は 354 00:20:11,976 --> 00:20:15,841 SPARQL クエリーを書くより 難しいものではないと思うからです 355 00:20:15,842 --> 00:20:21,255 同じレベルだと思う人もいるでしょうが 356 00:20:22,278 --> 00:20:26,296 私は多分はより簡単だと思います 357 00:20:26,296 --> 00:20:31,241 なぜならShpae Expressionは簡単に 機能するようにデザインされているからです 358 00:20:31,242 --> 00:20:35,001 これが まず最初の 359 00:20:35,001 --> 00:20:36,620 Shpae Expressionのための エディタです 360 00:20:37,371 --> 00:20:41,467 そしてまた例えば 簡単に可視化できるでしょう 361 00:20:41,468 --> 00:20:44,801 Shpae Expressionがあって 例えば 362 00:20:44,802 --> 00:20:49,386 「written work」は よい Shpae Expressionでしょう 363 00:20:49,386 --> 00:20:53,300 異なった物の間に 何らかの関連があるからです 364 00:20:54,823 --> 00:20:58,160 これは 「written work」の UML可視化です 365 00:20:58,161 --> 00:21:02,090 UMLでは 簡単に異なったプロパティを見れます 366 00:21:02,790 --> 00:21:06,794 これを行った際 何人かの Shpae Expressionに 367 00:21:06,795 --> 00:21:09,216 間違いがあることに気がつきました 368 00:21:09,217 --> 00:21:12,988 何が欠けているプロパティかなどが 簡単に見つけられるからです 369 00:21:13,588 --> 00:21:15,771 そしてもうひとつの可能性は 370 00:21:15,772 --> 00:21:19,520 検証ができることだと思います 371 00:21:20,496 --> 00:21:25,285 どれかのラベルにあったと思います 閉じてしまったかも… 372 00:21:26,267 --> 00:21:30,988 でも例えばここ*Validate entities*を クリックできます 373 00:21:32,308 --> 00:21:34,232 例えば 374 00:21:35,404 --> 00:21:41,921 「q52」そして著者である「e42」 375 00:21:42,818 --> 00:21:46,180 「human」で… 「human」でできると思います… 376 00:21:49,050 --> 00:21:50,050 そして 377 00:21:50,688 --> 00:21:56,365 SPARQLクエリーをしているので 少し時間がかかっています 378 00:21:56,365 --> 00:21:59,134 この例はネットワークのせいで 機能しませんが 379 00:21:59,657 --> 00:22:01,580 自分で試してみてください 380 00:22:02,759 --> 00:22:07,026 では他のツールのプレゼンを続けましょう 381 00:22:07,026 --> 00:22:12,353 試したい方 フィードバックが欲しい方は 連絡してください 382 00:22:13,133 --> 00:22:15,540 プレゼンを続けます 383 00:22:18,923 --> 00:22:20,576 これが WikiShape です 384 00:22:23,800 --> 00:22:26,509 既に言いましたが 385 00:22:27,681 --> 00:22:34,157 Shpae Expression エディタは GitHubの中の独立したプロジェクトです 386 00:22:35,605 --> 00:22:37,472 個人のプロジェクトで使用できます 387 00:22:37,472 --> 00:22:41,036 Shpae Expression ツールをしたければ 388 00:22:41,036 --> 00:22:45,635 任意のプロジェクトに 入れ込めばいいだけです 389 00:22:45,636 --> 00:22:48,235 これはGitHubの中にあるので だれでも使えます 390 00:22:48,868 --> 00:22:51,970 私の生徒である同じ著者がさらに 391 00:22:52,034 --> 00:22:55,704 作ったShpae Expression用の エディタがあり 392 00:22:55,704 --> 00:22:58,819 ウィキデータ Query Serviceに 影響されたもので 393 00:22:58,819 --> 00:23:00,681 欄の中に 394 00:23:00,682 --> 00:23:05,103 SPARQLクエリーの より可視化されたVisual editorがあり 395 00:23:05,104 --> 00:23:07,135 このようなものを入れることができます 396 00:23:07,136 --> 00:23:09,123 これはスクリーンキャプチャです 397 00:23:09,123 --> 00:23:12,662 これはテキストの Shape Expressionであることがわかりますが 398 00:23:12,662 --> 00:23:17,822 これはフォーム形式のShape Expressionで ちょっと時間がかかります 399 00:23:18,595 --> 00:23:23,400 異なったフィールドに 異なった行を入れることができます 400 00:23:23,401 --> 00:23:25,800 そして ShExEr があります 401 00:23:26,879 --> 00:23:31,882 オビエド大学の大学院生が作ったもので 402 00:23:31,883 --> 00:23:34,540 彼がここに来ているので ShExErを紹介します 403 00:23:38,147 --> 00:23:40,024 (ダニー)ダニー・フェナンデスです 404 00:23:40,025 --> 00:23:43,800 オビエド大学の大学院生で ラビラと一緒に仕事しています 405 00:23:44,710 --> 00:23:47,725 時間が迫っているので 急いでやります 406 00:23:47,726 --> 00:23:52,641 デモはしないで スクリーンショットを出しましょう 407 00:23:52,642 --> 00:23:57,897 Shape Expressionや他のShape言語で 作業をする通常の方法は 408 00:23:57,897 --> 00:23:59,521 内容領域専門家がいて 409 00:23:59,522 --> 00:24:02,313 先験的に グラフをどのようにするか 410 00:24:02,314 --> 00:24:03,555 構成を定義し 411 00:24:03,556 --> 00:24:06,983 その構成を使用して 実際のデータを検証します 412 00:24:08,124 --> 00:24:11,641 ラビラが紹介したもののと同様に このツールは 413 00:24:11,642 --> 00:24:14,441 一般的な任意のRDFソース用のツールで 414 00:24:14,442 --> 00:24:17,375 逆方向にデザインされています 415 00:24:17,376 --> 00:24:18,758 幾つかのデータが既にあり 416 00:24:18,759 --> 00:24:23,165 Shapeを得たいノードを選択し 417 00:24:23,165 --> 00:24:26,718 すると自動的に抽出また Shapeを推測します 418 00:24:26,719 --> 00:24:29,791 これは一般目的のツールですが 419 00:24:29,791 --> 00:24:34,063 WikidataCon のためにしたことは これらの優れたボタンです 420 00:24:34,884 --> 00:24:37,081 クリックすると起こることは 421 00:24:37,081 --> 00:24:42,079 たくさんの構成パラメータがあり 422 00:24:42,080 --> 00:24:46,251 ウィキデータエンドポイントに対して 機能するようになっています 423 00:24:46,251 --> 00:24:47,971 失礼 424 00:24:48,733 --> 00:24:52,883 このボタンを押せば 基本的にこれが得られます 425 00:24:52,884 --> 00:24:55,126 どのような記述が欲しいか 426 00:24:55,127 --> 00:24:59,360 またクラスのインスタンスなど 探しているものを選択した後 427 00:24:59,361 --> 00:25:01,321 自動的にスキーマが得られます 428 00:25:02,319 --> 00:25:07,111 どれだけのモードが実際使われているかで すべての拘束が整理され 429 00:25:07,112 --> 00:25:09,772 あまり共通しないものを 取り除くことができます 430 00:25:09,772 --> 00:25:12,126 このポスターが下に掲示されていて 431 00:25:12,127 --> 00:25:14,595 私は今日はこのあたりに 432 00:25:14,596 --> 00:25:16,454 一日中いますので 433 00:25:16,455 --> 00:25:19,081 このツールに関心のある方は 434 00:25:19,082 --> 00:25:21,476 声をかけてください 435 00:25:21,477 --> 00:25:24,624 ではラブラにマイクを返します ありがとうございました 436 00:25:24,625 --> 00:25:29,265 (拍手) 437 00:25:29,812 --> 00:25:32,578 (ホゼ)では次のツールにいきましょう 438 00:25:32,579 --> 00:25:34,984 これは ShapeDesignerです 439 00:25:34,984 --> 00:25:37,241 アンドレア ShapeDesignerを ここで紹介しますか 440 00:25:37,242 --> 00:25:39,287 それも後でワークショップで 紹介しますか 441 00:25:39,287 --> 00:25:40,603 ワークショップがあるので… 442 00:25:40,603 --> 00:25:44,437 午後 特に Shape Expressionのための ワークショップがあります 443 00:25:45,265 --> 00:25:47,939 もっと実際に行い ShExを練習したい方は 444 00:25:47,940 --> 00:25:52,324 そちらへお越しください 445 00:25:52,875 --> 00:25:55,720 このツールは ShEx… エリックがいます 446 00:25:55,721 --> 00:25:56,890 紹介してくれますね 447 00:25:57,969 --> 00:26:00,687 (エリック)簡単に言いたいことは 448 00:26:00,687 --> 00:26:05,711 すでに ShEx のインターフェイスは 見たことがあるでしょう 449 00:26:05,711 --> 00:26:07,601 これはウィキデータ用のものです 450 00:26:07,602 --> 00:26:12,930 不要なものを除いた ウィキデータ用のものです 451 00:26:12,930 --> 00:26:17,937 一般的なものにはもっと機能がありますが 言っておきたいことは 452 00:26:17,937 --> 00:26:19,977 ウィキデータのスキーマを デバグするための 453 00:26:19,978 --> 00:26:23,201 特に有効な機能です 454 00:26:23,201 --> 00:26:29,224 Slurpのモードを選択すると 455 00:26:29,225 --> 00:26:31,444 行われることは 検証中に 456 00:26:31,445 --> 00:26:34,694 すべての3つ揃いを取り出したいとき 457 00:26:34,695 --> 00:26:36,274 つまり多くの失敗が返ってくると 458 00:26:36,275 --> 00:26:39,586 これらを見て 459 00:26:39,587 --> 00:26:41,800 どの3つ揃いがここにあり… 460 00:26:41,801 --> 00:26:44,120 失礼 3つ揃いはこの下です 461 00:26:44,121 --> 00:26:45,647 これは行われたことのログです 462 00:26:46,327 --> 00:26:49,180 ここでリアルタイムで いじることができます 463 00:26:49,181 --> 00:26:51,033 動かしてみたり 変えることができます 464 00:26:51,033 --> 00:26:54,160 素早くできるバージョンです 465 00:26:54,663 --> 00:26:56,481 これがShExのフォームで 466 00:26:56,482 --> 00:27:00,035 シャヒーンがドキュメントのためには Shape Expressionによって 467 00:27:00,035 --> 00:27:04,631 ウィキデータのドキュメントを 埋めるに役立つだろうと 468 00:27:04,631 --> 00:27:07,338 示唆したものです 469 00:27:08,095 --> 00:27:11,681 ウィキデータ用には つくられていませんので 470 00:27:11,682 --> 00:27:14,081 これはあるスキーマがあるとき 471 00:27:14,082 --> 00:27:15,402 そのスキーマを特定の方法で 472 00:27:15,403 --> 00:27:17,518 描画したいということを注記でき 473 00:27:17,519 --> 00:27:19,031 そのフォームを作成し 474 00:27:19,031 --> 00:27:21,582 データがあれば そのフォームを埋めることもできます 475 00:27:24,517 --> 00:27:26,164 PyShExは素晴らしいです 476 00:27:28,025 --> 00:27:31,080 (ホゼ)これが最後だと思います 477 00:27:31,821 --> 00:27:34,080 最後はPyShExです 478 00:27:34,675 --> 00:27:38,151 PyShExはShape Expressionの Pythonインプリメンテーションです 479 00:27:39,193 --> 00:27:42,680 お好きな方は Juyiter Notebooksでも 使えます 480 00:27:42,680 --> 00:27:44,432 それだけです 481 00:27:44,433 --> 00:27:47,170 (拍手) 482 00:27:52,916 --> 00:27:56,121 (アンドレア)私が関与した 特別なプロジェクト 483 00:27:56,121 --> 00:27:58,074 Gene Wikiについてお話します 484 00:27:58,075 --> 00:28:04,596 それで私達もクオリティの問題を 対処しています 485 00:28:04,597 --> 00:28:06,684 そのクオリティについて話す前に 486 00:28:06,685 --> 00:28:09,229 Gene Wiki とは何か ちょっと紹介します 487 00:28:09,855 --> 00:28:15,175 このプロジェクトの詳細を説明する 488 00:28:15,175 --> 00:28:18,160 論文を最近 書いてちょうど その出版前のものを公開しました 489 00:28:19,821 --> 00:28:23,839 写真を撮っている方もいますが 基本的に Gene Wikiは 490 00:28:23,846 --> 00:28:28,027 生医学のデータ 公開されたデータを ウィキデータに入れるもので 491 00:28:28,028 --> 00:28:32,200 ウィキデータに入れるには 特定のパターンに従っています 492 00:28:33,130 --> 00:28:36,809 新しいレポジトリや データセットが手に入ると 493 00:28:36,810 --> 00:28:39,600 それがウィキデータに含まれるべきものなら 494 00:28:39,601 --> 00:28:41,607 まず最初にコミュニティによる関与です 495 00:28:41,607 --> 00:28:44,184 直接ウィキデータのコミュニティで ある必要はなく 496 00:28:44,184 --> 00:28:46,530 ローカルな研究コミュニティによる 関与です 497 00:28:46,530 --> 00:28:50,286 オンラインかなにかの方法で会い 498 00:28:50,286 --> 00:28:52,881 データモデルを想像します 499 00:28:52,882 --> 00:28:56,197 これによりデータを ウィキデータモデルにつなげます 500 00:28:56,197 --> 00:28:59,944 去年のワークショップの 写真がここにあります 501 00:28:59,945 --> 00:29:02,663 特定のデータセットを 見ようとしています 502 00:29:02,663 --> 00:29:05,280 たくさんの論議があり 503 00:29:05,281 --> 00:29:09,780 schema.org とその他の 存在するオントロジーに揃えています 504 00:29:10,320 --> 00:29:15,508 そして最初のステップの終わりに ウィキデータに入れたい 505 00:29:15,509 --> 00:29:17,336 スキーマが描かれています 506 00:29:17,337 --> 00:29:20,440 ここにあるものは 平素です 507 00:29:20,441 --> 00:29:21,766 この後ろにあるのは 508 00:29:21,767 --> 00:29:25,240 今日のパネル内でも 幾つかのスキーマを作れます 509 00:29:26,560 --> 00:29:28,399 スキーマができれば 510 00:29:28,400 --> 00:29:31,320 次のステップは スキーマを機械可読にすることです 511 00:29:32,358 --> 00:29:36,841 ウィキデータの入れる生医学の データベースから持ち込むデータを 512 00:29:36,842 --> 00:29:39,690 つなげる起動可能なモデルが ほしいからです 513 00:29:40,393 --> 00:29:45,182 ここで Shape Expressionを 適用しています 514 00:29:46,471 --> 00:29:52,518 Shape Expressionは 515 00:29:52,518 --> 00:29:57,040 データデットが実際… まず 516 00:29:57,041 --> 00:30:01,782 既にウィキデータに存在する データが同じデータモデルに従っているかが 517 00:30:01,783 --> 00:30:04,718 先ほどのプロセスで達成されます 518 00:30:04,719 --> 00:30:08,031 そして Shape Expressionで このトピックのウィキデータのデータが 519 00:30:08,031 --> 00:30:10,926 修正が必要化どうか ウィキデータの中のモデルに 520 00:30:10,926 --> 00:30:15,013 当てはめるに必要な操作があるかなど 検証します 521 00:30:15,937 --> 00:30:19,867 それが整ったら ボットを書き始め 522 00:30:20,670 --> 00:30:23,801 ボットは定期的に 情報を入れています 523 00:30:23,802 --> 00:30:27,308 これがウィキデータに入れられる 1次資料です 524 00:30:27,846 --> 00:30:29,303 ボットが出来上がったら… 525 00:30:29,304 --> 00:30:33,001 これらのボットは 私たちのプロジェクトで作られた 526 00:30:33,002 --> 00:30:36,201 Wikidata Integratorと呼ばれる Pythonライブラリの 527 00:30:36,202 --> 00:30:38,167 プラットフォームで書かれます 528 00:30:38,698 --> 00:30:41,851 ボットが書かれたら 継続的インテグレーションのために 529 00:30:41,851 --> 00:30:44,540 Jenkinsというプラットフォームを 使用します 530 00:30:44,540 --> 00:30:45,762 Jenkinsでは 531 00:30:45,762 --> 00:30:51,160 ウィキデータを1次資料で 継続して更新できます 532 00:30:52,178 --> 00:30:55,889 これが先に話した論文のダイアグラムです 533 00:30:55,890 --> 00:30:57,241 これが現在の状態です 534 00:30:57,242 --> 00:31:02,059 このオレンジの箱が 薬物 遺伝子 疾患 535 00:31:02,060 --> 00:31:07,827 作用する化学物質の 1次資料で 536 00:31:07,827 --> 00:31:10,870 このモデルは小さくで見にくいですが 537 00:31:10,870 --> 00:31:17,472 これがデータベースで ウィキデータ内で管理される資料で 538 00:31:17,473 --> 00:31:20,560 1次資料とつながっています 539 00:31:20,561 --> 00:31:22,355 これがワークフローです 540 00:31:22,870 --> 00:31:25,312 私達のパートナーのひとつは 疾患オントロジーです 541 00:31:25,312 --> 00:31:27,672 疾患オントロジーは CCOオントロジーで 542 00:31:28,179 --> 00:31:31,990 このCCOオントロジーはそれ自身の キューレーションサイクルを持っていて 543 00:31:32,756 --> 00:31:35,736 疾患の領域に合わせて また疾患の解釈に応じて 544 00:31:35,737 --> 00:31:39,687 継続的に疾患オントロジーを 更新しています 545 00:31:40,336 --> 00:31:44,361 ウィキデータにも疾患に関する キューレーションサイクルがあり 546 00:31:44,362 --> 00:31:49,844 ウィキデータコミュニティでは ウィキデータで常にモニターしています 547 00:31:50,406 --> 00:31:51,601 私達には2つの役割があり 548 00:31:51,602 --> 00:31:55,477 口語的にこれらを ゲートキーパーキュレーターと呼んでいます 549 00:31:56,009 --> 00:31:59,561 これは私と同僚が5年前に 550 00:31:59,562 --> 00:32:03,414 コンピュータの前に座って ウィキピディアとウィキデータをモニターし 551 00:32:03,415 --> 00:32:08,601 もし1次コミュニティ 1次資料へ 連絡される問題があれば 552 00:32:08,602 --> 00:32:11,765 インプリメンテーションを調べ 決断を下します 553 00:32:11,765 --> 00:32:14,850 このウィキデータの入力を信頼するかを見て 554 00:32:14,850 --> 00:32:18,555 そして考慮されたら このサイクルに入り 555 00:32:18,555 --> 00:32:22,686 次のイタレーションは 疾患オントロジーの部分で 556 00:32:22,687 --> 00:32:25,411 ウィキデータに入れられます 557 00:32:27,419 --> 00:32:31,480 WikiPathwayでも同じことをしています 558 00:32:31,481 --> 00:32:36,601 WikiPathwayはMediaWikiに触発された 経路のリポジトリです 559 00:32:36,602 --> 00:32:40,901 同じ様にウィキデータには既に 異なった経路が存在します 560 00:32:41,463 --> 00:32:44,713 これらの経路のリソースの間で 一致しない場合は 561 00:32:44,722 --> 00:32:46,701 それがゲートキーパー キュレーターから 562 00:32:46,702 --> 00:32:49,521 コミュニティに連絡され 563 00:32:49,522 --> 00:32:53,715 個々のキューレーションのサイクルは 維持されます 564 00:32:53,715 --> 00:32:57,068 もし以前のサイクルを覚えていれば 565 00:32:57,069 --> 00:33:03,041 ここでは2つのサイクルと 2つのリソースのみ話しましたが 566 00:33:03,566 --> 00:33:05,840 すべてのリソースに対して 行う必要があり 567 00:33:05,840 --> 00:33:08,061 何が起こっているかを管理しなくては なりません 568 00:33:08,062 --> 00:33:09,505 キューレーションというのは 569 00:33:09,505 --> 00:33:11,377 ウィキピディアのトップページに行き 570 00:33:11,377 --> 00:33:14,544 ウィキデータのトップページに行き それをやることです 571 00:33:14,545 --> 00:33:19,316 これは持っている2つのゲートキーパー キュレーターから拡張できません 572 00:33:19,860 --> 00:33:22,777 2016年の会議のとき 573 00:33:22,778 --> 00:33:26,933 エリックがShape Expressionのプレゼンをし 574 00:33:26,934 --> 00:33:29,277 私もこれをやろうと これでいいぞと思いました 575 00:33:29,278 --> 00:33:34,240 Shape Expressionはウィキデータ内の 違いを検知する助けになるので 576 00:33:34,240 --> 00:33:41,159 ゲートキーパーがより効果的な レポートを出せます 577 00:33:42,275 --> 00:33:46,019 今年 スキーマエンティティに 感激しました 578 00:33:46,020 --> 00:33:50,765 なぜならそれらのエンティティスキーマを ウィキデータ自体に保存できるからです 579 00:33:50,765 --> 00:33:53,183 これは以前はGitHubに保存されました 580 00:33:53,860 --> 00:33:56,815 ウィキデータのインターフェイスと 揃えられ 581 00:33:56,816 --> 00:33:59,350 ドキュメントのディスカッションができたり 582 00:33:59,350 --> 00:34:00,762 また改訂もできます 583 00:34:00,763 --> 00:34:05,261 トップページとウィキデータの改訂を 利用して 584 00:34:05,262 --> 00:34:12,255 ウィキデータに何があるべきか 1次資料が何かについて 585 00:34:12,255 --> 00:34:14,060 ディスカッションできます 586 00:34:14,966 --> 00:34:19,686 エリックがプレゼンしたものは 既にとても有益です 587 00:34:19,686 --> 00:34:24,335 ここにヒト遺伝子のための Shape Expressionを作り 588 00:34:24,336 --> 00:34:30,225 簡単なShExを通して使ってみました ご覧の通り 589 00:34:30,225 --> 00:34:32,428 既に… 590 00:34:32,429 --> 00:34:34,641 ひとつモニターする必要のある 問題があります 591 00:34:34,642 --> 00:34:37,316 スキーマに合わない項目が ひとつあります 592 00:34:37,316 --> 00:34:43,139 これには既にスキーマエンティティ キューレーションのレポートが作られ 593 00:34:43,140 --> 00:34:46,360 異なったキューレーションの レポートへ送ります 594 00:34:48,058 --> 00:34:52,788 ShEx.js は 構築されたインターフェイスで 595 00:34:52,788 --> 00:34:55,860 ここに戻ってみると… 10 だけやってますが 596 00:34:55,860 --> 00:35:00,362 何万ものあるので これもうまく拡張しません 597 00:35:00,362 --> 00:35:05,168 だから Wikidata Integratorは SgExサポートにも対応し 598 00:35:05,168 --> 00:35:07,431 そして項目のループをループすることができ 599 00:35:07,431 --> 00:35:11,494 yes-no yes-no そして真−偽 真−偽と 行えます 600 00:35:11,495 --> 00:35:12,495 そしてまた 601 00:35:13,065 --> 00:35:16,514 レポートの対処の効率を向上します 602 00:35:17,256 --> 00:35:22,662 でも最近 ウィキデータの Query Service上にビルドされ 603 00:35:23,181 --> 00:35:24,998 今 絞り込んでいるところですが 604 00:35:24,999 --> 00:35:26,560 同様にこれも拡張しません 605 00:35:26,561 --> 00:35:31,391 どのようにウィキデータのモデルを扱うかは 継続している課題です 606 00:35:32,202 --> 00:35:36,682 ShExは巨大に感じるものであるだけでなく 607 00:35:36,683 --> 00:35:40,356 その規模は扱うには大きすぎます 608 00:35:41,068 --> 00:35:46,081 だから最初の概念の証明 あるいは演習を始めてみました 609 00:35:46,082 --> 00:35:47,680 yEDというツールを使います 610 00:35:48,184 --> 00:35:52,590 これらのShape Expressionをまず描き… 611 00:35:52,591 --> 00:35:57,788 そしてこのスキーマを 612 00:35:57,788 --> 00:36:01,279 Shape Expressionの隣接する フォーマットに再生しました 613 00:36:01,280 --> 00:36:04,840 だからこれは既に Shape Expression言語に尻込みする 614 00:36:04,840 --> 00:36:07,432 聴衆者でも使用できます 615 00:36:07,961 --> 00:36:12,308 しかし実際 これらの視覚識別子には問題があります 616 00:36:12,309 --> 00:36:18,229 なぜならここに誰かがすでにyEDに描いた スキーマであるからです 617 00:36:18,230 --> 00:36:23,838 ここにも別のものがあります これが使っているのは…綺麗ですね 618 00:36:23,838 --> 00:36:29,414 これは壁にかけたいですが 相互運用可能ではありません 619 00:36:30,281 --> 00:36:32,131 私の講演の終わりに 620 00:36:32,131 --> 00:36:35,732 このスライドを借りていますが 621 00:36:35,732 --> 00:36:37,594 視聴に来てくれている彼に 感謝します 622 00:36:37,595 --> 00:36:39,423 これが大好きです 623 00:36:39,424 --> 00:36:42,362 RDFは複雑で鬱陶しいと思われていますが 624 00:36:42,362 --> 00:36:44,293 現実はもっと悪く これはとても簡単です 625 00:36:45,581 --> 00:36:48,133 なぜなら現実のデータの問題は 626 00:36:48,134 --> 00:36:50,031 実に複雑です 627 00:36:50,031 --> 00:36:51,981 RDFを避けることはできますが 628 00:36:51,981 --> 00:36:55,760 複雑なデータやコンピュータの問題を 避けることはもっと難しいです 629 00:36:55,761 --> 00:36:59,535 これはRDFについてですが これはモデリングにも当てはまると思います 630 00:37:00,112 --> 00:37:02,769 私の講演のポイントは 631 00:37:03,387 --> 00:37:05,882 どのようにモデリングをやっていくか? 632 00:37:05,882 --> 00:37:10,826 ShEx または 視覚的モデルを討論すべきか… 633 00:37:11,426 --> 00:37:13,271 いかに継続していくか? 634 00:37:13,474 --> 00:37:14,840 ご視聴ありがとうございます 635 00:37:15,102 --> 00:37:17,787 (拍手) 636 00:37:19,759 --> 00:37:21,543 (リディア)ありがとうございました 637 00:37:21,692 --> 00:37:24,001 前に来てください 638 00:37:24,002 --> 00:37:27,741 質疑を始めます 639 00:37:28,610 --> 00:37:30,203 質問は? 640 00:37:31,507 --> 00:37:32,507 はい 641 00:37:34,253 --> 00:37:36,890 カメラのためには… 642 00:37:38,835 --> 00:37:40,968 (リディア)ええ 643 00:37:43,094 --> 00:37:46,273 (参加者1)クリスティーナへの質問で 644 00:37:47,366 --> 00:37:51,371 他のシステムとのリンクで 645 00:37:51,371 --> 00:37:53,689 「情報取得(information gain)」 という言葉を使われましたが 646 00:37:53,690 --> 00:37:55,619 統計と確率に使われる 情報理論の計測に使われる 647 00:37:55,620 --> 00:37:58,001 information gainという言葉がありますが… 648 00:37:58,002 --> 00:37:59,541 同じ… 649 00:37:59,542 --> 00:38:01,736 確率理論からの 650 00:38:01,736 --> 00:38:04,173 情報理論からの 651 00:38:04,174 --> 00:38:06,040 information gainと同じ計測を 意味しているんですか 652 00:38:06,040 --> 00:38:09,024 それともなんからの方法で 情報の取得を測る概念的な意味ですか 653 00:38:09,025 --> 00:38:13,695 いいえ実際 シャノン エントロピーを使って 654 00:38:13,695 --> 00:38:20,161 インプリメンテーション測定を 定義しているので それを意味します 655 00:38:20,162 --> 00:38:22,696 詳細な式の説明は避けたかったので… 656 00:38:22,697 --> 00:38:24,977 (参加者1)はいわかります だから質問したのです 657 00:38:24,978 --> 00:38:27,088 (参加者1)ありがとうございました 658 00:38:32,795 --> 00:38:35,047 (参加者2)質問というより コメントですが… 659 00:38:35,048 --> 00:38:36,241 (リディア)どうぞ 660 00:38:36,242 --> 00:38:39,840 (参加者2)クオリティや完成性について 661 00:38:39,840 --> 00:38:42,547 項目レベルに気が配られていますね 662 00:38:42,547 --> 00:38:47,374 私が気になることは同じことが 階層に適応されていないことで 663 00:38:47,374 --> 00:38:51,480 階層が的確でないという 問題があると思います 664 00:38:51,481 --> 00:38:53,463 コモンズ検索や他のことで 665 00:38:53,464 --> 00:38:55,774 これが問題になると思います 666 00:38:56,771 --> 00:39:00,601 できることのひとつは 外部の… 667 00:39:00,602 --> 00:39:04,842 外部の類義語集が その階層を構成する方法として 668 00:39:04,842 --> 00:39:10,291 P4900 広範な概念修飾子を使って 669 00:39:11,037 --> 00:39:16,167 しかしもっとよい役に立つツールと 思うのは 670 00:39:16,168 --> 00:39:21,212 それによって外部の… 類義語集の階層マップを 671 00:39:21,212 --> 00:39:24,111 ウィキデータの項目にインポート できるようになります 672 00:39:24,111 --> 00:39:28,199 これらのP9400 修飾子と置かれれば 673 00:39:28,200 --> 00:39:32,234 外部の階層から派生した階層を見ることが 674 00:39:32,490 --> 00:39:37,534 SPARQLを通じて 実際よりよいクエリーでできます 675 00:39:37,534 --> 00:39:41,346 例えばポーラ・モーマは PKMを使いご存知のように 676 00:39:41,346 --> 00:39:43,533 ファッションの仕事を多くしています 677 00:39:43,533 --> 00:39:50,524 それを使って私達は ヨーロッパファッション類義語階層と 678 00:39:50,524 --> 00:39:53,812 ゲッティAATファッション類義語階層を 取り入れ 679 00:39:53,812 --> 00:39:57,957 そして私たちにとって 実に問題となる 680 00:39:57,957 --> 00:40:00,511 高レベルの項目のどこに ギャップがあるか見てみます 681 00:40:00,511 --> 00:40:04,355 なぜならしばしばこれらはウィキピディアの 曖昧性解消ページにのみあるので 682 00:40:04,356 --> 00:40:09,270 階層が欠けている より高レベルの 項目がたくさんあり 683 00:40:09,271 --> 00:40:14,480 これは時々クオリティと完成性の意味で 把握しておかなければならないものです 684 00:40:14,480 --> 00:40:16,608 しかし実際 685 00:40:16,643 --> 00:40:20,782 私が書いたたくさんのPullスクリプト よりもよいツールは… 686 00:40:21,144 --> 00:40:26,472 誰か Pythonで PAWS Notebook内に 687 00:40:26,472 --> 00:40:31,141 リンクされたデータや そうでない 688 00:40:31,141 --> 00:40:35,172 外部の類義語集 そしてその階層を取り 689 00:40:35,172 --> 00:40:41,099 それらをP9400値にいれる クイックステートメントに入れることです 690 00:40:41,165 --> 00:40:42,165 そうすれば後日 691 00:40:42,166 --> 00:40:44,527 叙述がもっと完全になったとき 692 00:40:44,528 --> 00:40:48,821 これらのP9400を更新するために 693 00:40:48,821 --> 00:40:51,590 叙述が更新されるにつれ より密度が上がるので 694 00:40:51,590 --> 00:40:55,377 システムのその階層が もっと増えたことを示すように 695 00:40:55,390 --> 00:40:59,526 これらの修飾子も変える必要があります 696 00:40:59,526 --> 00:41:03,728 誰かそれをしてくれれば とても便利だと思います 697 00:41:03,728 --> 00:41:07,121 また項目レベルのみでなく 698 00:41:07,122 --> 00:41:10,762 階層レベルでクオリティと 完成性を向上する 699 00:41:10,763 --> 00:41:12,810 他のアプローチについても 検索するべきです 700 00:41:13,308 --> 00:41:15,216 (アンドレア)付け足していいですか? 701 00:41:16,362 --> 00:41:19,901 実際にやっています 702 00:41:19,911 --> 00:41:23,551 フィンが語彙的データで作った 703 00:41:23,552 --> 00:41:27,330 Shape Expressionを見ることを お勧めします 704 00:41:27,330 --> 00:41:29,640 彼はShape Expressionを創り そして著作者表現にビルトしています 705 00:41:29,641 --> 00:41:32,528 だからウィキデータの中の リンクされたShape Expressionの構想で 706 00:41:32,529 --> 00:41:35,005 特に 私が正しく理解していれば 707 00:41:35,006 --> 00:41:37,183 それはまさに Gene Wikiの中で やっていることです 708 00:41:37,184 --> 00:41:40,841 ウィキデータに入れられた 疾患オントロジーがあれば 709 00:41:40,842 --> 00:41:44,681 疾患のデータが入れられ 710 00:41:44,682 --> 00:41:47,767 この類義語集に一致するかを知るに Shape Expressionを応用できます 711 00:41:47,767 --> 00:41:50,919 またウィキデータに入れる必要のある 712 00:41:50,920 --> 00:41:53,389 他の類義語集や制御された語彙の 他のオントロジーがあります 713 00:41:53,389 --> 00:41:55,401 これはまさにShape Expressionが 有用です 714 00:41:55,402 --> 00:41:57,963 なぜなら疾患オントロジー用の Shape Expressionが持て 715 00:41:57,964 --> 00:41:59,644 Mesh用のShape Expressionが持て 716 00:41:59,645 --> 00:42:01,761 そして「じゃあクオリティを調べよう」 ということになります 717 00:42:01,762 --> 00:42:04,929 なぜなら制御された語彙がある場合 718 00:42:04,929 --> 00:42:09,567 ウィキデータの内容も このクオリティに沿っているとしても 719 00:42:09,568 --> 00:42:12,086 それに同意しない コミュニティもあるでしょう 720 00:42:12,086 --> 00:42:14,521 だからツールは準備されていても 721 00:42:14,521 --> 00:42:18,144 これらのモデルを作り 異なった ユースケースに適用することになります 722 00:42:18,811 --> 00:42:22,521 (参加者2)外部のオントロジーを ウィキデータにマップしたものがあれば 723 00:42:22,521 --> 00:42:25,928 Shape Expressionはとても有益ですが 724 00:42:25,929 --> 00:42:29,474 私の問題はそれに至ることです 725 00:42:29,475 --> 00:42:34,881 どれだけの外部のオントロジーが まだウィキデータに中に無いか 726 00:42:34,882 --> 00:42:37,636 そしてそのギャップがどこになるかを 知るために 727 00:42:37,636 --> 00:42:40,660 より使いやすいツールで 728 00:42:40,660 --> 00:42:44,286 欠けている 外部のオントロジーを探すことは 729 00:42:44,286 --> 00:42:45,537 とても有益になるでしょう 730 00:42:47,678 --> 00:42:49,062 ここでの最も大きい問題は 731 00:42:49,062 --> 00:42:51,201 ツールではなく ライセンスです 732 00:42:51,803 --> 00:42:55,249 オントロジーをウィキデータに 取り込むのは簡単ですが 733 00:42:55,250 --> 00:42:59,295 ほとんどのオントロジーは どう言えばいいか… 734 00:42:59,965 --> 00:43:03,256 ライセンスの制御があり ウィキデータには使えません 735 00:43:04,068 --> 00:43:06,678 (参加者2)とても多くの 一般使用可能な類義語辞書が 736 00:43:06,678 --> 00:43:08,209 文化の分野にはあります 737 00:43:08,210 --> 00:43:10,851 −(アンドレア)話し合う必要がありますね −(参加者2)そうですね 738 00:43:10,852 --> 00:43:12,384 (アンドレア)では話しましょう 739 00:43:13,624 --> 00:43:19,192 (参加者3)コメントしたいことは ジェームスへの答えになります 740 00:43:19,192 --> 00:43:22,401 つまり階層がグラフを作り 741 00:43:22,374 --> 00:43:24,041 もしあなたが… 742 00:43:24,579 --> 00:43:28,888 基本的に言いたいことは 743 00:43:28,889 --> 00:43:30,820 階層の共通した問題は サークル階層です 744 00:43:30,821 --> 00:43:33,796 お互いに戻ってくるようになり 問題がある際には 745 00:43:33,796 --> 00:43:35,920 そのような階層を 持つべきではありません 746 00:43:37,022 --> 00:43:41,295 このおかしなことは ウィキピディアのカテゴリでよく起こります 747 00:43:41,295 --> 00:43:43,374 カテゴリにたくさんサークルがあります 748 00:43:43,898 --> 00:43:46,612 しかしいいことにはこれは… 749 00:43:47,713 --> 00:43:51,582 技術的に言ってこれは PMP完成の問題で 750 00:43:51,583 --> 00:43:53,880 グラフを作ると簡単に 見つけることができません 751 00:43:54,473 --> 00:43:57,046 しかし多くの開発された方法があり 752 00:43:57,047 --> 00:44:00,624 これらの階層グラフの 問題を見つけられます 753 00:44:00,625 --> 00:44:04,860 例えば「*Finding Cycles Breaking Cycles 754 00:44:04,861 --> 00:44:07,955 in Noisey Hiearachies*」という論文で 755 00:44:07,956 --> 00:44:12,671 英語のウィキピディアのカテゴリの 問題を助けています 756 00:44:12,672 --> 00:44:17,141 これをウィキデータのこれらの 階層に応用することができ 757 00:44:17,142 --> 00:44:19,540 問題になりそうなものを見つけ 758 00:44:19,541 --> 00:44:22,481 支障をきたすものを取り除けばいいです 759 00:44:22,482 --> 00:44:24,593 実際 支障を見つけます 760 00:44:24,594 --> 00:44:26,960 これは単にアイデアですが… 761 00:44:28,250 --> 00:44:29,930 (参加者2)それはいいですね 762 00:44:29,931 --> 00:44:33,672 しかしあなたは存在する 不適切なサブクラスの関係の数を 763 00:44:33,672 --> 00:44:35,402 軽く見ていると思います 764 00:44:35,403 --> 00:44:39,680 全く間違った国に 市を持っているようなもので 765 00:44:40,250 --> 00:44:44,874 地理のツールとして それを見つけるものがありますが 766 00:44:44,875 --> 00:44:49,201 階層に使えるツールが必要です 767 00:44:49,202 --> 00:44:53,477 完全に欠けている国に相当する 項目がどこにあるか 768 00:44:53,478 --> 00:44:57,673 また全く異なったものに サブクラスされているものがあるかを 769 00:44:57,674 --> 00:45:01,804 認識するためのツールが必要です 770 00:45:02,804 --> 00:45:07,165 (リディア)あなたの言っていることは 771 00:45:07,166 --> 00:45:12,024 私と私のチームが 私達のデータを再利用する人たちから 772 00:45:12,025 --> 00:45:13,991 よく聞くことと似ています 773 00:45:15,002 --> 00:45:16,638 個々のデータポイントは適正でも 774 00:45:16,639 --> 00:45:20,163 オントロジーなどで見なければ 775 00:45:20,164 --> 00:45:21,857 それは… 776 00:45:22,388 --> 00:45:26,437 なぜこれが起こるかの もっとも問題となる点は 777 00:45:26,437 --> 00:45:30,736 ウィキデータの編集の多くが 778 00:45:30,736 --> 00:45:34,544 個々の項目で起こっていて 779 00:45:34,545 --> 00:45:36,201 項目が編集しています 780 00:45:37,653 --> 00:45:42,075 例えばそのグラフの他の部分への 781 00:45:42,075 --> 00:45:44,245 全体への影響を理解していない ことがあります 782 00:45:45,265 --> 00:45:50,040 個々のローカルでの編集の影響を もっと可視化できる方法について 783 00:45:50,041 --> 00:45:53,185 アイデアがある方がいれば 784 00:45:54,005 --> 00:45:57,550 誠実に編集を加える人たちに 785 00:45:57,550 --> 00:46:02,633 その影響を見せることができれば 786 00:46:03,214 --> 00:46:04,474 これは探求する価値が 787 00:46:04,481 --> 00:46:06,481 あると思います 788 00:46:06,939 --> 00:46:12,237 わあ では君 そして君 そして君 789 00:46:12,237 --> 00:46:14,238 (参加者3)ディスカッションの後で 790 00:46:14,238 --> 00:46:18,262 ジェームスの言ったことに 同意を示したいです 791 00:46:18,263 --> 00:46:22,467 基本的にもっと危険なものは 階層でしょう 792 00:46:22,468 --> 00:46:23,910 階層ではなくてもっと一般的に 793 00:46:23,911 --> 00:46:28,022 ウィキデータ内のサブクラスの関連の 意味論でしょう 794 00:46:28,022 --> 00:46:32,561 この会議のための 最近 言語を学んでいます 795 00:46:32,562 --> 00:46:35,257 例えば多くの場合 796 00:46:35,257 --> 00:46:39,463 言語は同じもののサブクラス そして一部です 797 00:46:39,463 --> 00:46:43,577 つまり柔軟なオントロジーを 持っているといえます 798 00:46:43,577 --> 00:46:46,256 ウィキデータはときどき それを自由に表現します 799 00:46:46,256 --> 00:46:47,257 なぜなら 800 00:46:47,258 --> 00:46:50,721 言語のオントロジーは 政治的にも複雑ですね 801 00:46:50,722 --> 00:46:55,038 不明瞭のレベルを表現する立場で あるのもいいです 802 00:46:55,038 --> 00:46:57,983 しかしそれの機械解読をしたければ 803 00:46:57,984 --> 00:46:59,468 それは非常に問題です 804 00:46:59,468 --> 00:47:00,468 そしてまた 805 00:47:00,469 --> 00:47:03,686 オントロジーは 元々 私達のものであった何かから 806 00:47:03,687 --> 00:47:05,490 インポートされたことはないと思います 807 00:47:05,491 --> 00:47:08,321 言ってみれば初期ウィキピディアから 集めれたものです 808 00:47:08,322 --> 00:47:11,324 このShape Expressionはいいけど 809 00:47:11,325 --> 00:47:15,575 ウィキデータのオントロジーを 外部の資料で 810 00:47:15,576 --> 00:47:18,191 検証したり修正をしたりもでき 811 00:47:18,191 --> 00:47:20,026 素晴らしいアイデアですが 最後に 812 00:47:20,027 --> 00:47:25,440 外部のオントロジーをウィキデータに 反映することで終わりますか? 813 00:47:25,441 --> 00:47:28,281 そしてまた外部の資料から 814 00:47:28,281 --> 00:47:30,642 決して集められない私達のオントロジーの 中核はどうすればいいでしょう 815 00:47:30,643 --> 00:47:32,248 どのように修正すべきでしょうか? 816 00:47:32,248 --> 00:47:35,276 それはそれ自体の問題になるでしょう 817 00:47:35,277 --> 00:47:39,010 外部の何かで オントロジーを検証するアイデアから 818 00:47:39,010 --> 00:47:41,333 独立して注目しなければ ならなくなるでしょう 819 00:47:49,353 --> 00:47:53,379 (参加者4)拘束やシェープで できることは 820 00:47:53,380 --> 00:47:54,769 とても素晴らしいですが 821 00:47:55,205 --> 00:47:58,481 主点ははっきりしていく… 822 00:47:58,482 --> 00:48:03,229 なぜならデータに何を期待するかが 明瞭にできるようになったからです 823 00:48:03,229 --> 00:48:06,893 以前は個々にツールや スクリプトを作る必要があり 824 00:48:06,894 --> 00:48:10,601 目につきやすく それについて議論できます 825 00:48:10,602 --> 00:48:13,641 しかし課題は良し悪しではなく 826 00:48:13,642 --> 00:48:15,870 期待です 827 00:48:15,870 --> 00:48:18,105 人によって ウィキデータでどうモデルするかは 828 00:48:18,106 --> 00:48:20,737 異なった期待と議論があるでしょう 829 00:48:21,246 --> 00:48:23,095 そしてこれは… 830 00:48:23,096 --> 00:48:26,280 現在の状況はその方向に 一歩進み 831 00:48:26,281 --> 00:48:28,041 これに取り組むには 832 00:48:28,042 --> 00:48:31,041 技術的な知識が必要となるので 833 00:48:31,042 --> 00:48:35,721 この拘束を可視化するための 834 00:48:35,722 --> 00:48:40,915 それを理解しやすい たぶん自然な言語に変換するための 835 00:48:40,939 --> 00:48:43,768 方法が求められ 良し悪し自体はあまり問題ではないです 836 00:48:44,925 --> 00:48:45,925 (リディア)はい 837 00:48:50,986 --> 00:48:53,893 (参加者5)クオリティについて 賛同したいのは… 838 00:48:53,894 --> 00:48:57,010 私はたくさんの問題を見つけました 839 00:48:58,838 --> 00:49:02,330 インスタンスとサブクラスの間の 意見の差にも行き当たりました 840 00:49:02,331 --> 00:49:05,963 これらの状況のエラーだと思い 841 00:49:05,963 --> 00:49:11,521 とても時間のかかるプロセスを 探しました 842 00:49:11,522 --> 00:49:14,840 私が見つけたのは「とても 興味深い項目を見つけたら 何か… 843 00:49:14,840 --> 00:49:17,347 そして派生するすべての ステートメントを見つけるに 844 00:49:17,347 --> 00:49:21,628 すべてのサブクラスの インスタンスを使おう」 845 00:49:21,628 --> 00:49:26,215 これはこれらのエラーを見つける とても有効な方法です 846 00:49:26,215 --> 00:49:29,427 しかしShape Expressionができるか… 847 00:49:29,841 --> 00:49:31,582 何か… 848 00:49:31,583 --> 00:49:36,934 これらの問題を解消するツールとして 使えれば…でも… 849 00:49:40,514 --> 00:49:43,041 (参加者6)構造的な足跡があれば… 850 00:49:45,910 --> 00:49:49,310 構造的な足跡があれば 改ざん可能な… 851 00:49:49,310 --> 00:49:51,191 見てみて 852 00:49:51,192 --> 00:49:54,350 これはできると… しかしこれが単に 853 00:49:54,350 --> 00:49:56,640 現実のものを マップしようとしているだけなら 854 00:49:56,640 --> 00:49:59,450 とてもたくさんの頭脳が必要でしょう 855 00:50:05,810 --> 00:50:09,081 (参加者7)Apple Sire Knowlege の パブロ・メンデスです 856 00:50:09,081 --> 00:50:12,548 私達はどうプロジェクトとコミュニティを 助けるかを見つけるために集まっていますが 857 00:50:12,548 --> 00:50:15,464 クリスティーナは間違って 私達が欲しいものを尋ねました 858 00:50:16,194 --> 00:50:19,880 (笑)そこで私が思うのは 859 00:50:19,880 --> 00:50:24,017 検証可能性に関して 多くのことが求められます 860 00:50:24,017 --> 00:50:26,398 それはプロジェクトやコミュニティ 861 00:50:26,398 --> 00:50:28,841 その信頼性の中核となるもののひとつです 862 00:50:28,841 --> 00:50:32,322 すべてのステートメントは等しくなく とても争われるものや 863 00:50:32,322 --> 00:50:34,071 簡単に推測できるものとか 864 00:50:34,071 --> 00:50:35,772 例えば誰かの誕生日は簡単に 検証でき 865 00:50:35,772 --> 00:50:38,943 今日のキーノートのように 性別はもっと複雑です 866 00:50:40,063 --> 00:50:43,441 もう少しデータのクオリティの分野で 867 00:50:43,441 --> 00:50:47,255 信頼性と検証可能性に関して 知っていることを話してもらえますか 868 00:50:54,545 --> 00:50:58,440 あまりなければ もっとあって欲しいと思います(笑) 869 00:51:00,510 --> 00:51:02,672 (リディア)はい 870 00:51:03,822 --> 00:51:06,516 明らかにあまり言うことがないようです(笑) 871 00:51:07,666 --> 00:51:12,404 (アンドレア)できることがたくさんありますが 昨日 あなたと話したように 872 00:51:12,404 --> 00:51:16,814 昨日習った私の好みの例は もう昨日拝み倒されたものですが 873 00:51:16,814 --> 00:51:19,579 Q2 地球に行くと 874 00:51:19,579 --> 00:51:22,451 地球は平面というステートメントがあります 875 00:51:23,476 --> 00:51:26,510 この例が大好きです 876 00:51:26,510 --> 00:51:28,963 なぜならそれを主張するコミュニティがあり 877 00:51:29,203 --> 00:51:31,128 検証可能なリソースがあるからです 878 00:51:31,335 --> 00:51:33,191 これは誠実な例で 879 00:51:33,191 --> 00:51:35,817 拝み倒されるべきでなく ウィキデータにあるべきです 880 00:51:36,124 --> 00:51:39,664 Shape Expressionは 881 00:51:39,664 --> 00:51:42,161 ここで非常に役立ちます 882 00:51:43,141 --> 00:51:45,775 このユースケースにとても 関心があるとか 883 00:51:45,775 --> 00:51:47,652 これは同意しないユースケースとか 884 00:51:47,652 --> 00:51:53,119 しかしまたこれはいいけど 関心があるというユースケースもあります 885 00:51:53,119 --> 00:51:55,349 ここに例があるとします グルコースがあります 886 00:51:55,349 --> 00:51:56,419 生物学者なら 887 00:51:56,419 --> 00:51:59,399 グルコースの分子構造の 化学的拘束には興味がないでしょう 888 00:51:59,399 --> 00:52:03,041 すべてのグルコースに関することは 同じです 889 00:52:03,041 --> 00:52:05,816 でも化学者なら これを聞くと気になると思います 890 00:52:05,816 --> 00:52:08,281 200ほどのものがあります 891 00:52:08,281 --> 00:52:10,903 だから複雑のShape Expressionがあります 892 00:52:10,903 --> 00:52:12,501 ここで 化学者の立場で 893 00:52:12,501 --> 00:52:13,833 これに対応します 894 00:52:13,833 --> 00:52:16,741 そしてあなたが 生物学的なユースケースから 895 00:52:16,741 --> 00:52:19,447 Shape Expressionを適用したいとします 896 00:52:19,447 --> 00:52:20,721 そして共同したければ 897 00:52:20,721 --> 00:52:25,138 エリックと ShExについて 話すとよいでしょうが 898 00:52:25,138 --> 00:52:28,738 この行程はまだ始まったばかりですが 899 00:52:28,738 --> 00:52:31,660 この分野で非常に 重要なものと思っています 900 00:52:34,230 --> 00:52:35,983 (リディア)あちらの方 901 00:52:40,682 --> 00:52:46,295 (参加者8)ディスカッションでの 幾つかの点についてアイデアがあります 902 00:52:46,295 --> 00:52:49,827 失わないように… 3つのアイデアが… 903 00:52:51,187 --> 00:52:55,815 ちょっと前にジェームスが言ったことで 904 00:52:55,815 --> 00:52:58,834 上部のオントロジーのための開始から 905 00:52:58,834 --> 00:53:01,840 ウィキデータにはとても 大きな問題があります 906 00:53:02,810 --> 00:53:05,411 WikidataConで2年前に 話しました 907 00:53:05,411 --> 00:53:07,483 そしてウィキマニアについて 話し合いました 908 00:53:07,483 --> 00:53:08,889 ウィキデータの会議があると 909 00:53:08,889 --> 00:53:11,068 いつもこれを話します 910 00:53:11,068 --> 00:53:15,951 なぜなら目につくレベルの とても大きな問題だからです 911 00:53:15,951 --> 00:53:22,886 何がエンティティで 何が workで 何も分野か 912 00:53:22,886 --> 00:53:25,502 そして芸術 もっとも大きな概念です 913 00:53:27,152 --> 00:53:33,018 これは実際 グローバルなオントロジーの 最大の弱点です 914 00:53:33,018 --> 00:53:38,815 なぜなら人々は常にこれを整理し 915 00:53:38,815 --> 00:53:42,707 すべてを線で分けようとしているからです 916 00:53:43,887 --> 00:53:46,827 覚えている人もいると思いますが 917 00:53:46,827 --> 00:53:51,716 世界中のすべての市を無意識に 壊した人がいます 918 00:53:51,716 --> 00:53:57,484 地理的な項目ではないので 拘束違反に満ちて 919 00:53:57,484 --> 00:54:01,035 誠実な意図でしたが 920 00:54:01,035 --> 00:54:04,090 項目の間違いを直そうとしていたのに 921 00:54:04,090 --> 00:54:06,688 すべてを壊していしまいました 922 00:54:07,508 --> 00:54:10,210 これをどのように解決できるが 私はわかりません 923 00:54:11,130 --> 00:54:16,261 なぜなら実際に写してこれる 外部の機関がないからです 924 00:54:16,261 --> 00:54:18,486 皆さんが作業している 925 00:54:18,486 --> 00:54:21,719 例えば 芸能データベースだとします 926 00:54:21,719 --> 00:54:24,684 直接 芸能のラベルに行くか 927 00:54:24,684 --> 00:54:29,221 あるいはエンティティがなにかの 論理的概念には行かず 928 00:54:29,221 --> 00:54:31,681 これは実際に… 929 00:54:31,681 --> 00:54:34,671 このレベルで機能している データベースは知りませんが 930 00:54:34,671 --> 00:54:38,221 これがウィキデータの弱点です 931 00:54:38,221 --> 00:54:41,521 データのクオリティを話すにおいて 932 00:54:41,521 --> 00:54:43,802 実際もっと大きなといえるでしょう 933 00:54:45,242 --> 00:54:49,512 ここで言ったと同じ様に… 934 00:54:49,512 --> 00:54:51,644 失礼 話題を変えてしまっています 935 00:54:51,644 --> 00:54:55,389 クオリティについては 別のセッションで言及しました 936 00:54:55,389 --> 00:55:00,031 それに関しては 実際 よいモデリングを行っている人がいて 937 00:55:00,031 --> 00:55:02,364 ShExを活用したりして それを行っています 938 00:55:03,054 --> 00:55:07,358 ウィキデータでは見れません ShExは見えません 939 00:55:07,358 --> 00:55:09,007 ディスカッションページでは 940 00:55:09,007 --> 00:55:10,525 WikiPeojectを見ず 941 00:55:10,525 --> 00:55:13,612 そして時には プロパティのトークページも見ません 942 00:55:13,612 --> 00:55:19,673 そこには明確に a)このプロパティが そのために使用されると記載されています 943 00:55:20,453 --> 00:55:24,218 先週あるプロパティに 拘束を加えました 944 00:55:24,218 --> 00:55:26,839 そのプロパティの創作の ディスカッションに 945 00:55:26,839 --> 00:55:29,157 この拘束は明確に記述されていました 946 00:55:29,157 --> 00:55:33,433 私はその拘束を加える技術部分を 作っただけですが 947 00:55:33,433 --> 00:55:37,420 誰かに「私の編集をすべて 台無しにした」と言われました 948 00:55:37,420 --> 00:55:41,297 その人は過去2年 このプロパティを 間違って使っていました 949 00:55:41,297 --> 00:55:46,872 プロパティは実際はとても明瞭ですが 警告などがなく… 950 00:55:46,872 --> 00:55:50,332 だからウィキマニアの ピンクのポニーのように 951 00:55:50,332 --> 00:55:54,278 WikiPeojectをもって見やすく ShExをもっと見やすくすべきです 952 00:55:54,278 --> 00:55:56,992 それがクリスティーナは 言ったことです 953 00:55:56,992 --> 00:56:02,169 既存の解決策が見られていないという 問題があるんです 954 00:56:02,169 --> 00:56:04,667 このセッションでは 955 00:56:04,667 --> 00:56:08,288 もっとShExを作ろうとか 956 00:56:08,288 --> 00:56:11,232 整理する人の作業を促進しようとか 話していますが 957 00:56:11,992 --> 00:56:14,262 ウィキデータの一日目から 整理をしてきていて 958 00:56:14,262 --> 00:56:17,617 グローバルには追いついて行けていません 959 00:56:17,617 --> 00:56:20,437 追いつけていけない訳は… 960 00:56:20,437 --> 00:56:23,075 名前が複雑だと知っていて 961 00:56:23,075 --> 00:56:26,211 私だけで整理の作業をしていて 962 00:56:26,211 --> 00:56:28,900 すべての中国人の研究者に 963 00:56:28,900 --> 00:56:31,812 ラテン語の名前を追加する人がいるとしたら 964 00:56:31,812 --> 00:56:35,950 何ヶ月も整理にかかり 一人ではやっていけません 965 00:56:35,950 --> 00:56:39,548 ではその人はバッチで その作業をしたでしょう 966 00:56:39,548 --> 00:56:41,066 私たちが必要なのは… 967 00:56:41,066 --> 00:56:44,227 ツールの問題ではなくと 見て理解されるというが問題です 968 00:56:44,227 --> 00:56:46,451 既にツールはたくさんあります 969 00:56:46,451 --> 00:56:50,268 (リディア)そうですね しかし時間のようで(笑) 970 00:56:50,268 --> 00:56:52,113 締めくくりましょう 971 00:56:52,113 --> 00:56:54,185 たくさんのコメントを ありがとうございました 972 00:56:54,185 --> 00:56:56,461 今日 この後もディスカッションを 続けてください 973 00:56:56,461 --> 00:56:58,553 皆さんのご意見ありがとうございました 974 00:56:58,553 --> 00:57:03,411 (拍手)