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
あるいは２つを組み合わせて

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
このユーザースクリプトで
これらの１から５のスコアを与えます

60
00:03:04,570 --> 00:03:08,176
これは現在の項目のクオリティだと
思います

61
00:03:10,043 --> 00:03:14,328
１次資料ツールは
すべてのインポートしたい、しかし

62
00:03:14,328 --> 00:03:18,374
直接ウィキデータに入れられる質でない
データベースのためのものです

63
00:03:18,374 --> 00:03:20,335
だからこれを１次資料ツールで
処理し

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年３月までの
クエリーを評価していますが

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
参加者の皆さんへの２つの質問は

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
でも例えばここ<i>Validate entities</i>を
クリックできます

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
すべての３つ揃いを取り出したいとき

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
どの３つ揃いがここにあり…

460
00:26:41,801 --> 00:26:44,120
失礼
３つ揃いはこの下です

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
これがウィキデータに入れられる
１次資料です

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
ウィキデータを１次資料で
継続して更新できます

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
作用する化学物質の
１次資料で

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
１次資料とつながっています

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
私達には２つの役割があり

548
00:31:51,602 --> 00:31:55,477
口語的にこれらを
ゲートキーパーキュレーターと呼んでいます

549
00:31:56,009 --> 00:31:59,561
これは私と同僚が５年前に

550
00:31:59,562 --> 00:32:03,414
コンピュータの前に座って
ウィキピディアとウィキデータをモニターし

551
00:32:03,415 --> 00:32:08,601
もし１次コミュニティ １次資料へ
連絡される問題があれば

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
ここでは２つのサイクルと
２つのリソースのみ話しましたが

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
これは持っている２つのゲートキーパー
キュレーターから拡張できません

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
ウィキデータに何があるべきか
１次資料が何かについて

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
（参加者１）クリスティーナへの質問で

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
（参加者１）はいわかります
だから質問したのです

657
00:38:24,978 --> 00:38:27,088
（参加者１）ありがとうございました

658
00:38:32,795 --> 00:38:35,047
（参加者２）質問というより
コメントですが…

659
00:38:35,048 --> 00:38:36,241
（リディア）どうぞ

660
00:38:36,242 --> 00:38:39,840
（参加者２）クオリティや完成性について

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
（参加者２）外部のオントロジーを
ウィキデータにマップしたものがあれば

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
（参加者２）とても多くの
一般使用可能な類義語辞書が

736
00:43:06,678 --> 00:43:08,209
文化の分野にはあります

737
00:43:08,210 --> 00:43:10,851
−（アンドレア）話し合う必要がありますね
−（参加者２）そうですね

738
00:43:10,852 --> 00:43:12,384
（アンドレア）では話しましょう

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

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
（参加者２）それはいいですね

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
（参加者３）ディスカッションの後で

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
（参加者４）拘束やシェープで
できることは

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
（参加者５）クオリティについて
賛同したいのは…

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
（参加者６）構造的な足跡があれば…

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
（参加者７）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
（参加者８）ディスカッションでの
幾つかの点についてアイデアがあります

902
00:52:46,295 --> 00:52:49,827
失わないように…
３つのアイデアが…

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で２年前に
話しました

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
その人は過去２年 このプロパティを
間違って使っていました

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
（拍手）