データクオリティパネル
クロディア・ミューラービン、 ルーカス・ウェアミニスター
ホゼ・エミリオ・ラビラ・ガヤ、 クリスティナ・サラスナ、アンドレア・
データクオリティパネルの皆さん こんにちは
多くの人が私たちのデータが正しいことを 頼るのでデータクオリティは重要です
だからデータクオリティについて 話し合いましょう
4人の講演者は データクオリティについて短い紹介をし
その後で質疑を行います
ではまずルーカスから
ありがとう
ルーカスです まずウィキデータに既にある
データクオリティツールと 開発されていて公開マジかなものについての
概要から始めます
いくつかのテーマの グループに分けました
エラーを見つけやすくする 問題に対処しやすくする
データにより検証し 問題に気づきやすくする
一般的なエラーの元を修正する 既存のデータの質を維持する
そして人によるキューレーション
そして現在利用可能なものは プロパティの拘束からです
ウィキデータで これを見たことがあると思います
このような 内部のデータの均一性をチェックする
アイコンが出ることがあるでしょう
例えば あるイベントが他に続くなら
他のイベントもこのイベントに 続くべきです
このWikidataConの項目では それが見られません
この機能はできてまだ数日かも しれません
あるいはこれが制限しすぎだったり 簡単すぎなら
Query Service を使って チェックを自分で書くこともできます
もちろんQuery Serviceは 多くのことに有効ですが
エラーを見つけることもできます
ひとつ間違いを見つけたら
他の場所もチェックし
他の人が同じエラーをしていないか
Query Serviceで見つけられます
あるいは２つを組み合わせて
拘束違反を Query Serviceで探せます
例えば ある部分にだけあるエラーや
WikiProjectの あなたの関連した部分だけのエラーなどです
でも残念なことに その結果は現在のところ完全ではありません
改訂スコアリングもあります
これは最近の変更からだけ思いますが
自動アセスメントのウォッチリストに入れて
その編集が誠実なものかどうか
また被害を与えるものかどうかを 見ることができます
これは2次元だと思います
だから被害を与えるけど
誠実なものかどうかに注目して
特に友好的な気分なら
これらの編集者に
「貢献してくれてありがとう 次回はこのようにしてください」など…
でもそうでなければ
誠実でないものや 被害を与えるものを
元に戻すこともできます
似たものに エンティティ・スコアリングがあり
これは変更が加えられた 編集をスコアリングするのはなく
全体の改訂をスコアリングします
これにはリディアは会議の当初に 話したのと
同じ質の検証が使用されると 思います
このユーザースクリプトで これらの１から５のスコアを与えます
これは現在の項目のクオリティだと 思います
１次資料ツールは すべてのインポートしたい、しかし
直接ウィキデータに入れられる質でない データベースのためのものです
だからこれを１次資料ツールで 処理し
それから実際に人が判断し
個々のステートメントを 加えるかどうかを決めます
座標を地図で示すことは とても便利な機能ですが
クオリティコントロールにも 有用です
これがウィキデータ・ドイツの オフィスのはずで
座標がインド海の中にあれば
何か間違っていると気が付きます
単に数字を見るより 簡単にわかります
これは 相対的完全性 インディケータというガジェットで
この小さなアイコンで示され
その項目が完成しているかどうか
あるいはどのプロパティが 欠けていそうかを示し
項目を編集しているときに便利なもので
もし馴染みない分野で
使うべき正確なプロパティが わからないときには
とても便利なガジェットです
Shape Expression があります
アンドレアかホゼが これらについてお話すると思いますが
基本的には 持っているデータをそのテーマに対して
比較するためのとても有効な方法です
どのステートメントが 特定のエンティティを持つべきか
他のエンティティがリンクされるべきか どのように完成されるべきか
それによって間違いを見つけることができます
えーと これですね
Integraality または プロパティ・ダッシュボード
既にあるデータの概要を示します
例えば WikiProject Red Pandaの このフォームで
ここにほとんどすべての赤パンダの
性別があるのかわかります
誕生日はどこの動物園かによって かなり変わります
亡くなったパンダは ほとんどいないですね
よっかた かわいいからね
これはとても便利です
そしてOKすると 次に出てくるのは
ウィキデータ Bridge クライアント編集として知られているものです
ウィキピディア Infobox から ウィキデータを編集します
これによりより多くの 閲覧がなされます
なぜならもっと多くの人が これらのデータを見るからです
これによってウィキピディアでより ウィキデータが使われるようになるでしょう
そしてもっと多くの人に気づかれるように なるでしょう
例えばデータが古かったり 更新が必要なときは
ウィキデータ自体だけで気が付かれないことを 知ることができます
Tainted Referencesもあります
これはステートメントの値を編集すると
タイポなどを直している場合は 別として
リファレンスも更新することがあるでしょう
このTainted Referencesは 編集している人にそれを示す他に
他の編集者にも他に どのような編集がされたか示します
ステートメントの値が変更され リファレンスが更新されているいないを知り
それらを修正するか どうするかを決めることができます
もっと修正を入れるか
そのままでリファレンス更新は 必要がないとか…
これはSigned statementsに関して
データの提供者が心配する…
UNESCOかなにかが参照された ステートメントがあり
突然 誰かがそのステートメントに 損傷を加えたら
UNESCOなどの機関が
その損傷されたステートメントを 出したように見られる恐れがあります
だからSigned statementsは
暗号的にこのリファレンスに サインを入れることができます
編集を防ぐことはできません
でも少なくとも 誰かがステートメントを損傷するか
あるいは編集したりすると サインは無効になります
そしてそのステートメントが その機関が入れたものでないとわかります
もし正しい編集なら そのステートメントを 再度サインすることができます
または編集しなおすことができます
それから 素晴らしいものとして
Citoidがウィキデータにはあります
これにはURLを貼り付けたり 識別子 またはISBN
ウィキデータIDなど 基本的に 何でもVisual Editorに入れられ
きれいにフォーマットされた リファレンスを作成し
それにはすべてのデータが含まれていて とても使いやすいです
それに比べてウィキデータでは リファレンスを入れたければ
リファレンスURLとタイトル 著作者名
出版元、出版日
改訂日などを少なくとも加える必要があり とても厄介です
ウィキデータにCitoidを統合することで それが簡単になります
私は以上です
ではクリスティーナに渡します
（拍手）
クリスティーナです
チューリッヒ大学の研究員で
スイスのコミュニティの 活動者でもあります
クラウディア・ミューラーと私が WikidataConにこれを提示した際
期待したことは 今年の始めに
データクオリティのワークショップや その他のウィキマニアのセッションで
始めた議論を継続していくことです
今日の講演は基本的に
コミュニティと私達が 集めた考察を提供し
会話を続けていくことが目的です
これからみなさんと交流を 続けていきたいと思います
私達がもっと重要と思うのは
コミュニティの様々なユーザーに
何が必要か そしてデータクオリティの 問題が何かを問い続けることです
編集する人たちだけでなく コードを書く人や
データを利用する人
また何が起こったか編集履歴を 実際 利用する研究者など
すべてのユーザーを含みます
ウィキデータに存在する約80の ツールを評価し
それらを異なったデータクオリティの次元で 整理しました
実際に気がついたことは
多くのツールは 完成性をモニターしていて
実際…インターリンクを 可能にするものもありますが
多様性を検証するツールが 欠けていて
これは実際ウィキデータに 特にウィキデータのデザイン原則に
組み込めるもののひとつで
多様性をもたせ
異なった出典からの
異なった値の 異なったステートメントを含めます
これらは2次資料になるので
実際どれだけの複数の ステートメントがあるか
どのように どれだけを向上できるか等を 示すツールはありません
また多様なステートメントが存在する
理由もよくわかりません
だからこれらのコミュニティでの ディスカッションから
まだ注目すべきチャレンジが 浮き上がってきました
例えばこれらのクラウドソーシングの コミュニティがあることは
データやグラフの異なった部分に
取り組む異なったグループの人々がいて
また異なったバックグラウンドの知識を 注ぎ込まれるという利点がありますが
実際は異なった人々が 異なったプロパティを異なった方法で使い
エンティティの識別子に 異なったものを期待するので
何か均一なものに整えるのは 難しいです
グローバルな状態を捉えるための
ツールがもっと必要だと いう声も聞かれました
どのエンティティが 完成性の点で欠けているか
また人々が現在 どのような作業をしているか
そして異なった言語間のみでなく かつそのWikiProjectと
異なったウィキメディアの プラットフォームに渡る
緊密な共同についての 言及もありました
これらのディスカッションからの すべての書き留められたコメントを
Etherpadのここのリンクに
またウィキマニアのウィキページに 公開しました
いくつかの解決策は 実際 異なったWikiProjectで
開発された最善の実践方法を
共有する方向へ向かうように見えますが
チームでの仕事を整理し
少なくとも誰が作業をしているか 理解できるツールも求められています
またもっとショーケースが求められ
よりよい方法でそれらを作成できる テンプレートが求められています
自治体オープンデータの組織との
コンタクトを通じて
そして特に
チューリッヒ市と州と接していると
ウィキデータに興味が持たれている ことがわかります
つまり誰でもアクセスして データを見ることができる場所で
データを皆に提供したいからです
だからその目的に沿うには
何かのクオリティの識別子を持つことが とても気が惹かれるでしょう
ウィキでは既にありますが
また SPARQLの結果にも それらがあると良いでしょう
そしてそのコミュニティからの結果が 信頼できるかどうかわかります
さらに持っているデータのどの部分が ウィキデータに有益かが理解でき
そしてそれらを自動的に 評価するツールが求められます
またデータをインポートするべきか リンクするべきかを決断する
ある種の手法かツールも必要です
場合によっては
自分たちのリンクのある オープンデータセットを持っている場合
データを入れるべきか
ウィキデータへデータセットから リンクを作るべきか
あるいは逆方向にするかなどが あるからです
またウィキデータのどこにウェブサイトが 参照されているかを知りたいです
Query Serviceでそのような クエリを行うと
タイムアウトになることもあるので
もっとツールを作り
これらの質問の答えが 得られるようにすべきです
それ以外にも
ウィキ研究者はしばしば
編集サマリで情報が 欠けていることがあります
様々なエディタの挙動 ツールやボット
あるいは匿名のユーザーなど 理解する作業したとき
私が覚えていることは
例えば使用されたツールを 追跡する標準の方法などが
欠けていたことです
PetScanなどそれを既に行うツールも
いくつかありますが
このようなキメの細かい起源を どのように記録するかについて
コミュニティで検討するべきでしょう
さらに
リンクされたデータに関するけど すべてのタイプのデータに関しない
より強固なデータクオリティ次元を 考慮する必要があります
リンクで可能にされる 情報取得（Information gain)を
調べてみました
つまり
ウィキデータを他のデータセットに リンクする際に
どれだけのエンティティが 実際クラシフィケーションに得られるか
あるいは記述や また使用されている単語などが得られるかも
考えるべきです
簡単な例を挙げると…
この場合 ウィキデータ
あるいはウィキデータにリンクされた 外部のデータセンターで
ナターシャ・ノイと呼ばれる 人のエンティティがあり
所属やその他の情報があります
これでOKとして 外部にリンクし
そこにその名前のエンティティが既にあり 実際同じ値を持っているとします
よりよい方法は 別の名前をもつものにリンクします
このひとは2通りの方法で 名前を書くことができるので有効です
あるいはウィキデータにない 他の情報や
他のデータセットにない情報を 持つことができます
もっとよい方法としては
この情報を分類する新しい方法を持つ ターゲットデータセットを
見ることです
これが人であるのみでなく 他のデータセットでは
女性であるとかなど 他の分類も言及できます
もし他のデータセットで もっと多くの単語が使われていれば
全体の情報を回収するものの 助けにもなります
それに関してさらに言えることは
フェデレーションクエリーが よりよく行われます
マリーシェフ達による クエリーログを見ると
オーガニックなクエリーから
フェデレーションクエリーは ほんの少ししかないことがわかります
実際フェデレーションはリンクされた データを持つ主なる有利な点の一つでなので
コミュニティや ウィキデータを使う人は
この例がもっと必要でしょう
使用されたエンドポイントを見ると…
これは完全なリストではなく もっとあります
もちろんこのデータは2018年３月までの クエリーを評価していますが
フェデレーションエンドポイントを見ると
それらが使用されているかどうかを 見るべきです
後のディスカッションで使用できる
参加者の皆さんへの２つの質問は
あなた達の必要に応じるための
データクオリティの問題は なんであるか
そしてまた編集や警衛のために
必要な自動化は何かということです
以上です ありがとうございました
（拍手）
（ホゼ・エミロ・ラブラ） 私が話すことは
Shape Expressionに関連し 私達が開発しているツールです
私はホゼ・エミロ・ラブラです
これらのツールは異なった人によって つくられました
主にW3C ShEx, Shape Expressions コミュニティグループに関連しています
ShEx コミュニティグループです
まずお話したいのは RDFShapeで これは一般的なツールです
なぜなら Shape Expressionsは ウィキデータのためだけでなく
一般的に RDFを検証する言語だからです
これは私が主で開発したもので
一般的にRDFを検証するツールです
RDFについて学習したいとか ウィキデータでのみでなく
RDFやSPARQL エンドポイントを 検証したいなら
このツールをお勧めします
また学習については
私は大学で教えていて
RDFを教えるにはセマンティクな ウェブコースでそれを使っています
だからRDFを習いたいなら これはよいツールだと思います
例えばこのツールでの RDFグラフの可視化です
ここへ来る前 先月
ウィキデータ用に特に RDFShapeを分岐し始めました
これを WikiShapeと呼んで ウィキデータのプレゼンで紹介しました
行ったことは
ウィキデータに関連しないものを削除して
ウィキデータ SPARQLエンドポイントなど 幾つかのものをコードに書き込みました
ウィキベースにもできるかと 聞かれましたが
ウィキベース用を作るのも とても簡単にできます
このWikiShapeツールは 新しいもので
ほとんどの機能は働くと思いますが
機能しないものもあるでしょう
使ってみて向上させたいと 思われた方はご連絡ください
これは［不明瞭］キャプチャですが やってみましょう
動くかどうかみてみましょう
まず外に出て…
ここ
ここにツールがあります
このツールでできることは
例えば スキーマ エンティティスキーマの検証です
ここに新しい名前空間があり Eの何か…
例えば「human…」と書けば
書いていく間に補完されるので チェックすることができ
例えば 人のShpae Expressionは
ここにあるShpae Expression です
このエディタには シンタックスが色付けされています
これは… 画面が小さいので
大きくしてみましょう
見やすくなるでしょう
これがエディタで シンタックスが色付けされています
このエディタは ウィキデータ Query Serviceと
同じソースコードからできています
例えば マウスを乗せると
異なったプロパティの ラベルを表示します
ウィキデータのエンティティ スキーマは単なるテキストアイデアなので
とても便利だと思います
このエディタは補完機能があるので よりよく
また…
例えば拘束を加えたければ
「wdt:」と打って
「author」と書いて Ctrl+Spaceと打てば
異なった物を提供します
これはウィキデータの Query Serviceと似ていますが
これはShpae Expression特定のものです
なぜならShpae Expressionの作成は
SPARQL クエリーを書くより 難しいものではないと思うからです
同じレベルだと思う人もいるでしょうが
私は多分はより簡単だと思います
なぜならShpae Expressionは簡単に 機能するようにデザインされているからです
これが まず最初の
Shpae Expressionのための エディタです
そしてまた例えば 簡単に可視化できるでしょう
Shpae Expressionがあって 例えば
「written work」は よい Shpae Expressionでしょう
異なった物の間に 何らかの関連があるからです
これは 「written work」の UML可視化です
UMLでは 簡単に異なったプロパティを見れます
これを行った際 何人かの Shpae Expressionに
間違いがあることに気がつきました
何が欠けているプロパティかなどが 簡単に見つけられるからです
そしてもうひとつの可能性は
検証ができることだと思います
どれかのラベルにあったと思います 閉じてしまったかも…
でも例えばここValidate entitiesを クリックできます
例えば
「q52」そして著者である「e42」
「human」で… 「human」でできると思います…
そして
SPARQLクエリーをしているので 少し時間がかかっています
この例はネットワークのせいで 機能しませんが
自分で試してみてください
では他のツールのプレゼンを続けましょう
試したい方 フィードバックが欲しい方は 連絡してください
プレゼンを続けます
これが WikiShape です
既に言いましたが
Shpae Expression エディタは GitHubの中の独立したプロジェクトです
個人のプロジェクトで使用できます
Shpae Expression ツールをしたければ
任意のプロジェクトに 入れ込めばいいだけです
これはGitHubの中にあるので だれでも使えます
私の生徒である同じ著者がさらに
作ったShpae Expression用の エディタがあり
ウィキデータ Query Serviceに 影響されたもので
欄の中に
SPARQLクエリーの より可視化されたVisual editorがあり
このようなものを入れることができます
これはスクリーンキャプチャです
これはテキストの Shape Expressionであることがわかりますが
これはフォーム形式のShape Expressionで ちょっと時間がかかります
異なったフィールドに 異なった行を入れることができます
そして ShExEr があります
オビエド大学の大学院生が作ったもので
彼がここに来ているので ShExErを紹介します
（ダニー）ダニー・フェナンデスです
オビエド大学の大学院生で ラビラと一緒に仕事しています
時間が迫っているので 急いでやります
デモはしないで スクリーンショットを出しましょう
Shape Expressionや他のShape言語で 作業をする通常の方法は
内容領域専門家がいて
先験的に グラフをどのようにするか
構成を定義し
その構成を使用して 実際のデータを検証します
ラビラが紹介したもののと同様に このツールは
一般的な任意のRDFソース用のツールで
逆方向にデザインされています
幾つかのデータが既にあり
Shapeを得たいノードを選択し
すると自動的に抽出また Shapeを推測します
これは一般目的のツールですが
WikidataCon のためにしたことは これらの優れたボタンです
クリックすると起こることは
たくさんの構成パラメータがあり
ウィキデータエンドポイントに対して 機能するようになっています
失礼
このボタンを押せば 基本的にこれが得られます
どのような記述が欲しいか
またクラスのインスタンスなど 探しているものを選択した後
自動的にスキーマが得られます
どれだけのモードが実際使われているかで すべての拘束が整理され
あまり共通しないものを 取り除くことができます
このポスターが下に掲示されていて
私は今日はこのあたりに
一日中いますので
このツールに関心のある方は
声をかけてください
ではラブラにマイクを返します ありがとうございました
（拍手）
（ホゼ）では次のツールにいきましょう
これは ShapeDesignerです
アンドレア ShapeDesignerを ここで紹介しますか
それも後でワークショップで 紹介しますか
ワークショップがあるので…
午後 特に Shape Expressionのための ワークショップがあります
もっと実際に行い ShExを練習したい方は
そちらへお越しください
このツールは ShEx… エリックがいます
紹介してくれますね
（エリック）簡単に言いたいことは
すでに ShEx のインターフェイスは 見たことがあるでしょう
これはウィキデータ用のものです
不要なものを除いた ウィキデータ用のものです
一般的なものにはもっと機能がありますが 言っておきたいことは
ウィキデータのスキーマを デバグするための
特に有効な機能です
Slurpのモードを選択すると
行われることは 検証中に
すべての３つ揃いを取り出したいとき
つまり多くの失敗が返ってくると
これらを見て
どの３つ揃いがここにあり…
失礼 ３つ揃いはこの下です
これは行われたことのログです
ここでリアルタイムで いじることができます
動かしてみたり 変えることができます
素早くできるバージョンです
これがShExのフォームで
シャヒーンがドキュメントのためには Shape Expressionによって
ウィキデータのドキュメントを 埋めるに役立つだろうと
示唆したものです
ウィキデータ用には つくられていませんので
これはあるスキーマがあるとき
そのスキーマを特定の方法で
描画したいということを注記でき
そのフォームを作成し
データがあれば そのフォームを埋めることもできます
PyShExは素晴らしいです
（ホゼ）これが最後だと思います
最後はPyShExです
PyShExはShape Expressionの Pythonインプリメンテーションです
お好きな方は Juyiter Notebooksでも 使えます
それだけです
（拍手）
（アンドレア）私が関与した 特別なプロジェクト
Gene Wikiについてお話します
それで私達もクオリティの問題を 対処しています
そのクオリティについて話す前に
Gene Wiki とは何か ちょっと紹介します
このプロジェクトの詳細を説明する
論文を最近 書いてちょうど その出版前のものを公開しました
写真を撮っている方もいますが 基本的に Gene Wikiは
生医学のデータ 公開されたデータを ウィキデータに入れるもので
ウィキデータに入れるには 特定のパターンに従っています
新しいレポジトリや データセットが手に入ると
それがウィキデータに含まれるべきものなら
まず最初にコミュニティによる関与です
直接ウィキデータのコミュニティで ある必要はなく
ローカルな研究コミュニティによる 関与です
オンラインかなにかの方法で会い
データモデルを想像します
これによりデータを ウィキデータモデルにつなげます
去年のワークショップの 写真がここにあります
特定のデータセットを 見ようとしています
たくさんの論議があり
schema.org とその他の 存在するオントロジーに揃えています
そして最初のステップの終わりに ウィキデータに入れたい
スキーマが描かれています
ここにあるものは 平素です
この後ろにあるのは
今日のパネル内でも 幾つかのスキーマを作れます
スキーマができれば
次のステップは スキーマを機械可読にすることです
ウィキデータの入れる生医学の データベースから持ち込むデータを
つなげる起動可能なモデルが ほしいからです
ここで Shape Expressionを 適用しています
Shape Expressionは
データデットが実際… まず
既にウィキデータに存在する データが同じデータモデルに従っているかが
先ほどのプロセスで達成されます
そして Shape Expressionで このトピックのウィキデータのデータが
修正が必要化どうか ウィキデータの中のモデルに
当てはめるに必要な操作があるかなど 検証します
それが整ったら ボットを書き始め
ボットは定期的に 情報を入れています
これがウィキデータに入れられる １次資料です
ボットが出来上がったら…
これらのボットは 私たちのプロジェクトで作られた
Wikidata Integratorと呼ばれる Pythonライブラリの
プラットフォームで書かれます
ボットが書かれたら 継続的インテグレーションのために
Jenkinsというプラットフォームを 使用します
Jenkinsでは
ウィキデータを１次資料で 継続して更新できます
これが先に話した論文のダイアグラムです
これが現在の状態です
このオレンジの箱が 薬物 遺伝子 疾患
作用する化学物質の １次資料で
このモデルは小さくで見にくいですが
これがデータベースで ウィキデータ内で管理される資料で
１次資料とつながっています
これがワークフローです
私達のパートナーのひとつは 疾患オントロジーです
疾患オントロジーは CCOオントロジーで
このCCOオントロジーはそれ自身の キューレーションサイクルを持っていて
疾患の領域に合わせて また疾患の解釈に応じて
継続的に疾患オントロジーを 更新しています
ウィキデータにも疾患に関する キューレーションサイクルがあり
ウィキデータコミュニティでは ウィキデータで常にモニターしています
私達には２つの役割があり
口語的にこれらを ゲートキーパーキュレーターと呼んでいます
これは私と同僚が５年前に
コンピュータの前に座って ウィキピディアとウィキデータをモニターし
もし１次コミュニティ １次資料へ 連絡される問題があれば
インプリメンテーションを調べ 決断を下します
このウィキデータの入力を信頼するかを見て
そして考慮されたら このサイクルに入り
次のイタレーションは 疾患オントロジーの部分で
ウィキデータに入れられます
WikiPathwayでも同じことをしています
WikiPathwayはMediaWikiに触発された 経路のリポジトリです
同じ様にウィキデータには既に 異なった経路が存在します
これらの経路のリソースの間で 一致しない場合は
それがゲートキーパー キュレーターから
コミュニティに連絡され
個々のキューレーションのサイクルは 維持されます
もし以前のサイクルを覚えていれば
ここでは２つのサイクルと ２つのリソースのみ話しましたが
すべてのリソースに対して 行う必要があり
何が起こっているかを管理しなくては なりません
キューレーションというのは
ウィキピディアのトップページに行き
ウィキデータのトップページに行き それをやることです
これは持っている２つのゲートキーパー キュレーターから拡張できません
2016年の会議のとき
エリックがShape Expressionのプレゼンをし
私もこれをやろうと これでいいぞと思いました
Shape Expressionはウィキデータ内の 違いを検知する助けになるので
ゲートキーパーがより効果的な レポートを出せます
今年 スキーマエンティティに 感激しました
なぜならそれらのエンティティスキーマを ウィキデータ自体に保存できるからです
これは以前はGitHubに保存されました
ウィキデータのインターフェイスと 揃えられ
ドキュメントのディスカッションができたり
また改訂もできます
トップページとウィキデータの改訂を 利用して
ウィキデータに何があるべきか １次資料が何かについて
ディスカッションできます
エリックがプレゼンしたものは 既にとても有益です
ここにヒト遺伝子のための Shape Expressionを作り
簡単なShExを通して使ってみました ご覧の通り
既に…
ひとつモニターする必要のある 問題があります
スキーマに合わない項目が ひとつあります
これには既にスキーマエンティティ キューレーションのレポートが作られ
異なったキューレーションの レポートへ送ります
ShEx.js は 構築されたインターフェイスで
ここに戻ってみると… 10 だけやってますが
何万ものあるので これもうまく拡張しません
だから Wikidata Integratorは SgExサポートにも対応し
そして項目のループをループすることができ
yes-no yes-no そして真−偽 真−偽と 行えます
そしてまた
レポートの対処の効率を向上します
でも最近 ウィキデータの Query Service上にビルドされ
今 絞り込んでいるところですが
同様にこれも拡張しません
どのようにウィキデータのモデルを扱うかは 継続している課題です
ShExは巨大に感じるものであるだけでなく
その規模は扱うには大きすぎます
だから最初の概念の証明 あるいは演習を始めてみました
yEDというツールを使います
これらのShape Expressionをまず描き…
そしてこのスキーマを
Shape Expressionの隣接する フォーマットに再生しました
だからこれは既に Shape Expression言語に尻込みする
聴衆者でも使用できます
しかし実際 これらの視覚識別子には問題があります
なぜならここに誰かがすでにyEDに描いた スキーマであるからです
ここにも別のものがあります これが使っているのは…綺麗ですね
これは壁にかけたいですが 相互運用可能ではありません
私の講演の終わりに
このスライドを借りていますが
視聴に来てくれている彼に 感謝します
これが大好きです
RDFは複雑で鬱陶しいと思われていますが
現実はもっと悪く これはとても簡単です
なぜなら現実のデータの問題は
実に複雑です
RDFを避けることはできますが
複雑なデータやコンピュータの問題を 避けることはもっと難しいです
これはRDFについてですが これはモデリングにも当てはまると思います
私の講演のポイントは
どのようにモデリングをやっていくか？
ShEx または 視覚的モデルを討論すべきか…
いかに継続していくか？
ご視聴ありがとうございます
（拍手）
（リディア）ありがとうございました
前に来てください
質疑を始めます
質問は？
はい
カメラのためには…
（リディア）ええ
（参加者１）クリスティーナへの質問で
他のシステムとのリンクで
「情報取得（information gain)」 という言葉を使われましたが
統計と確率に使われる 情報理論の計測に使われる
information gainという言葉がありますが…
同じ…
確率理論からの
情報理論からの
information gainと同じ計測を 意味しているんですか
それともなんからの方法で 情報の取得を測る概念的な意味ですか
いいえ実際 シャノン エントロピーを使って
インプリメンテーション測定を 定義しているので それを意味します
詳細な式の説明は避けたかったので…
（参加者１）はいわかります だから質問したのです
（参加者１）ありがとうございました
（参加者２）質問というより コメントですが…
（リディア）どうぞ
（参加者２）クオリティや完成性について
項目レベルに気が配られていますね
私が気になることは同じことが 階層に適応されていないことで
階層が的確でないという 問題があると思います
コモンズ検索や他のことで
これが問題になると思います
できることのひとつは 外部の…
外部の類義語集が その階層を構成する方法として
P4900 広範な概念修飾子を使って
しかしもっとよい役に立つツールと 思うのは
それによって外部の… 類義語集の階層マップを
ウィキデータの項目にインポート できるようになります
これらのP9400 修飾子と置かれれば
外部の階層から派生した階層を見ることが
SPARQLを通じて 実際よりよいクエリーでできます
例えばポーラ・モーマは PKMを使いご存知のように
ファッションの仕事を多くしています
それを使って私達は ヨーロッパファッション類義語階層と
ゲッティAATファッション類義語階層を 取り入れ
そして私たちにとって 実に問題となる
高レベルの項目のどこに ギャップがあるか見てみます
なぜならしばしばこれらはウィキピディアの 曖昧性解消ページにのみあるので
階層が欠けている より高レベルの 項目がたくさんあり
これは時々クオリティと完成性の意味で 把握しておかなければならないものです
しかし実際
私が書いたたくさんのPullスクリプト よりもよいツールは…
誰か Pythonで PAWS Notebook内に
リンクされたデータや そうでない
外部の類義語集 そしてその階層を取り
それらをP9400値にいれる クイックステートメントに入れることです
そうすれば後日
叙述がもっと完全になったとき
これらのP9400を更新するために
叙述が更新されるにつれ より密度が上がるので
システムのその階層が もっと増えたことを示すように
これらの修飾子も変える必要があります
誰かそれをしてくれれば とても便利だと思います
また項目レベルのみでなく
階層レベルでクオリティと 完成性を向上する
他のアプローチについても 検索するべきです
（アンドレア）付け足していいですか？
実際にやっています
フィンが語彙的データで作った
Shape Expressionを見ることを お勧めします
彼はShape Expressionを創り そして著作者表現にビルトしています
だからウィキデータの中の リンクされたShape Expressionの構想で
特に 私が正しく理解していれば
それはまさに Gene Wikiの中で やっていることです
ウィキデータに入れられた 疾患オントロジーがあれば
疾患のデータが入れられ
この類義語集に一致するかを知るに Shape Expressionを応用できます
またウィキデータに入れる必要のある
他の類義語集や制御された語彙の 他のオントロジーがあります
これはまさにShape Expressionが 有用です
なぜなら疾患オントロジー用の Shape Expressionが持て
Mesh用のShape Expressionが持て
そして「じゃあクオリティを調べよう」 ということになります
なぜなら制御された語彙がある場合
ウィキデータの内容も このクオリティに沿っているとしても
それに同意しない コミュニティもあるでしょう
だからツールは準備されていても
これらのモデルを作り 異なった ユースケースに適用することになります
（参加者２）外部のオントロジーを ウィキデータにマップしたものがあれば
Shape Expressionはとても有益ですが
私の問題はそれに至ることです
どれだけの外部のオントロジーが まだウィキデータに中に無いか
そしてそのギャップがどこになるかを 知るために
より使いやすいツールで
欠けている 外部のオントロジーを探すことは
とても有益になるでしょう
ここでの最も大きい問題は
ツールではなく ライセンスです
オントロジーをウィキデータに 取り込むのは簡単ですが
ほとんどのオントロジーは どう言えばいいか…
ライセンスの制御があり ウィキデータには使えません
（参加者２）とても多くの 一般使用可能な類義語辞書が
文化の分野にはあります
−（アンドレア）話し合う必要がありますね −（参加者２）そうですね
（アンドレア）では話しましょう
（参加者３）コメントしたいことは ジェームスへの答えになります
つまり階層がグラフを作り
もしあなたが…
基本的に言いたいことは
階層の共通した問題は サークル階層です
お互いに戻ってくるようになり 問題がある際には
そのような階層を 持つべきではありません
このおかしなことは ウィキピディアのカテゴリでよく起こります
カテゴリにたくさんサークルがあります
しかしいいことにはこれは…
技術的に言ってこれは PMP完成の問題で
グラフを作ると簡単に 見つけることができません
しかし多くの開発された方法があり
これらの階層グラフの 問題を見つけられます
例えば「*Finding Cycles Breaking Cycles
in Noisey Hiearachies*」という論文で
英語のウィキピディアのカテゴリの 問題を助けています
これをウィキデータのこれらの 階層に応用することができ
問題になりそうなものを見つけ
支障をきたすものを取り除けばいいです
実際 支障を見つけます
これは単にアイデアですが…
（参加者２）それはいいですね
しかしあなたは存在する 不適切なサブクラスの関係の数を
軽く見ていると思います
全く間違った国に 市を持っているようなもので
地理のツールとして それを見つけるものがありますが
階層に使えるツールが必要です
完全に欠けている国に相当する 項目がどこにあるか
また全く異なったものに サブクラスされているものがあるかを
認識するためのツールが必要です
（リディア）あなたの言っていることは
私と私のチームが 私達のデータを再利用する人たちから
よく聞くことと似ています
個々のデータポイントは適正でも
オントロジーなどで見なければ
それは…
なぜこれが起こるかの もっとも問題となる点は
ウィキデータの編集の多くが
個々の項目で起こっていて
項目が編集しています
例えばそのグラフの他の部分への
全体への影響を理解していない ことがあります
個々のローカルでの編集の影響を もっと可視化できる方法について
アイデアがある方がいれば
誠実に編集を加える人たちに
その影響を見せることができれば
これは探求する価値が
あると思います
わあ では君 そして君 そして君
（参加者３）ディスカッションの後で
ジェームスの言ったことに 同意を示したいです
基本的にもっと危険なものは 階層でしょう
階層ではなくてもっと一般的に
ウィキデータ内のサブクラスの関連の 意味論でしょう
この会議のための 最近 言語を学んでいます
例えば多くの場合
言語は同じもののサブクラス そして一部です
つまり柔軟なオントロジーを 持っているといえます
ウィキデータはときどき それを自由に表現します
なぜなら
言語のオントロジーは 政治的にも複雑ですね
不明瞭のレベルを表現する立場で あるのもいいです
しかしそれの機械解読をしたければ
それは非常に問題です
そしてまた
オントロジーは 元々 私達のものであった何かから
インポートされたことはないと思います
言ってみれば初期ウィキピディアから 集めれたものです
このShape Expressionはいいけど
ウィキデータのオントロジーを 外部の資料で
検証したり修正をしたりもでき
素晴らしいアイデアですが 最後に
外部のオントロジーをウィキデータに 反映することで終わりますか？
そしてまた外部の資料から
決して集められない私達のオントロジーの 中核はどうすればいいでしょう
どのように修正すべきでしょうか？
それはそれ自体の問題になるでしょう
外部の何かで オントロジーを検証するアイデアから
独立して注目しなければ ならなくなるでしょう
（参加者４）拘束やシェープで できることは
とても素晴らしいですが
主点ははっきりしていく…
なぜならデータに何を期待するかが 明瞭にできるようになったからです
以前は個々にツールや スクリプトを作る必要があり
目につきやすく それについて議論できます
しかし課題は良し悪しではなく
期待です
人によって ウィキデータでどうモデルするかは
異なった期待と議論があるでしょう
そしてこれは…
現在の状況はその方向に 一歩進み
これに取り組むには
技術的な知識が必要となるので
この拘束を可視化するための
それを理解しやすい たぶん自然な言語に変換するための
方法が求められ 良し悪し自体はあまり問題ではないです
（リディア）はい
（参加者５）クオリティについて 賛同したいのは…
私はたくさんの問題を見つけました
インスタンスとサブクラスの間の 意見の差にも行き当たりました
これらの状況のエラーだと思い
とても時間のかかるプロセスを 探しました
私が見つけたのは「とても 興味深い項目を見つけたら 何か…
そして派生するすべての ステートメントを見つけるに
すべてのサブクラスの インスタンスを使おう」
これはこれらのエラーを見つける とても有効な方法です
しかしShape Expressionができるか…
何か…
これらの問題を解消するツールとして 使えれば…でも…
（参加者６）構造的な足跡があれば…
構造的な足跡があれば 改ざん可能な…
見てみて
これはできると… しかしこれが単に
現実のものを マップしようとしているだけなら
とてもたくさんの頭脳が必要でしょう
（参加者７）Apple Sire Knowlege の パブロ・メンデスです
私達はどうプロジェクトとコミュニティを 助けるかを見つけるために集まっていますが
クリスティーナは間違って 私達が欲しいものを尋ねました
（笑）そこで私が思うのは
検証可能性に関して 多くのことが求められます
それはプロジェクトやコミュニティ
その信頼性の中核となるもののひとつです
すべてのステートメントは等しくなく とても争われるものや
簡単に推測できるものとか
例えば誰かの誕生日は簡単に 検証でき
今日のキーノートのように 性別はもっと複雑です
もう少しデータのクオリティの分野で
信頼性と検証可能性に関して 知っていることを話してもらえますか
あまりなければ もっとあって欲しいと思います（笑）
（リディア）はい
明らかにあまり言うことがないようです（笑）
（アンドレア）できることがたくさんありますが 昨日 あなたと話したように
昨日習った私の好みの例は もう昨日拝み倒されたものですが
Q2 地球に行くと
地球は平面というステートメントがあります
この例が大好きです
なぜならそれを主張するコミュニティがあり
検証可能なリソースがあるからです
これは誠実な例で
拝み倒されるべきでなく ウィキデータにあるべきです
Shape Expressionは
ここで非常に役立ちます
このユースケースにとても 関心があるとか
これは同意しないユースケースとか
しかしまたこれはいいけど 関心があるというユースケースもあります
ここに例があるとします グルコースがあります
生物学者なら
グルコースの分子構造の 化学的拘束には興味がないでしょう
すべてのグルコースに関することは 同じです
でも化学者なら これを聞くと気になると思います
200ほどのものがあります
だから複雑のShape Expressionがあります
ここで 化学者の立場で
これに対応します
そしてあなたが 生物学的なユースケースから
Shape Expressionを適用したいとします
そして共同したければ
エリックと ShExについて 話すとよいでしょうが
この行程はまだ始まったばかりですが
この分野で非常に 重要なものと思っています
（リディア）あちらの方
（参加者８）ディスカッションでの 幾つかの点についてアイデアがあります
失わないように… ３つのアイデアが…
ちょっと前にジェームスが言ったことで
上部のオントロジーのための開始から
ウィキデータにはとても 大きな問題があります
WikidataConで２年前に 話しました
そしてウィキマニアについて 話し合いました
ウィキデータの会議があると
いつもこれを話します
なぜなら目につくレベルの とても大きな問題だからです
何がエンティティで 何が workで 何も分野か
そして芸術 もっとも大きな概念です
これは実際 グローバルなオントロジーの 最大の弱点です
なぜなら人々は常にこれを整理し
すべてを線で分けようとしているからです
覚えている人もいると思いますが
世界中のすべての市を無意識に 壊した人がいます
地理的な項目ではないので 拘束違反に満ちて
誠実な意図でしたが
項目の間違いを直そうとしていたのに
すべてを壊していしまいました
これをどのように解決できるが 私はわかりません
なぜなら実際に写してこれる 外部の機関がないからです
皆さんが作業している
例えば 芸能データベースだとします
直接 芸能のラベルに行くか
あるいはエンティティがなにかの 論理的概念には行かず
これは実際に…
このレベルで機能している データベースは知りませんが
これがウィキデータの弱点です
データのクオリティを話すにおいて
実際もっと大きなといえるでしょう
ここで言ったと同じ様に…
失礼 話題を変えてしまっています
クオリティについては 別のセッションで言及しました
それに関しては 実際 よいモデリングを行っている人がいて
ShExを活用したりして それを行っています
ウィキデータでは見れません ShExは見えません
ディスカッションページでは
WikiPeojectを見ず
そして時には プロパティのトークページも見ません
そこには明確に a)このプロパティが そのために使用されると記載されています
先週あるプロパティに 拘束を加えました
そのプロパティの創作の ディスカッションに
この拘束は明確に記述されていました
私はその拘束を加える技術部分を 作っただけですが
誰かに「私の編集をすべて 台無しにした」と言われました
その人は過去２年 このプロパティを 間違って使っていました
プロパティは実際はとても明瞭ですが 警告などがなく…
だからウィキマニアの ピンクのポニーのように
WikiPeojectをもって見やすく ShExをもっと見やすくすべきです
それがクリスティーナは 言ったことです
既存の解決策が見られていないという 問題があるんです
このセッションでは
もっとShExを作ろうとか
整理する人の作業を促進しようとか 話していますが
ウィキデータの一日目から 整理をしてきていて
グローバルには追いついて行けていません
追いつけていけない訳は…
名前が複雑だと知っていて
私だけで整理の作業をしていて
すべての中国人の研究者に
ラテン語の名前を追加する人がいるとしたら
何ヶ月も整理にかかり 一人ではやっていけません
ではその人はバッチで その作業をしたでしょう
私たちが必要なのは…
ツールの問題ではなくと 見て理解されるというが問題です
既にツールはたくさんあります
（リディア）そうですね しかし時間のようで（笑）
締めくくりましょう
たくさんのコメントを ありがとうございました
今日 この後もディスカッションを 続けてください
皆さんのご意見ありがとうございました
（拍手）