-
[GLAMパネル]
-
[スサンナ・オーネス、マイク・ディキソン、
ユアヒム・ナイバート、ビート・エスターマン]
-
皆さん こんにちは
-
GLAMパネルにようこそ
-
始める前に
２つお知らせがあります
-
第１に Etherpadを広く活用して
メモを取ってください
-
第２に 自宅やその他の場所で
ご覧の皆さんへ
-
ご質問があれば
-
Etherpadへ
書き込んでください
-
この部屋のサポート担当が
把握していく予定です
-
皆さんの貢献を拝見した後に
-
私たちが決定した
今年のパネルのテーマは
-
実際のウィキメディアの
プロジェクトを凌駕する
-
データ エコシステムにおける
ウィキデータの役割です
-
これは新しいウィキメディア財団の戦略とも
完全に一致するものです
-
今日は４名のパネリストがいます
-
３名と私です
-
ご紹介しますので
登壇してください
-
こちらはスサンナ・オーネスです
-
長年フリー ナレッジの活動をしており
-
数多くのウィキプロジェクトに
参加しています
-
今日は フィンランド国立図書館との
共同プロジェクトに関して
-
お伝えいただく予定です
-
次にご紹介するのは 私の隣の
マイク・ディキソンです
-
ご覧の順で
２番目にお話しいただきます
-
彼はニュージーランドの学芸員です
-
また 動物学者で
ウィキペディア編集者でもあり
-
さらに 2018年と2019年における
-
ニュージーランド初の
ウィキペディアン代表です
-
お話しいただくのは
その役割に関する経験と
-
その状況の中で
ウィキデータが果たしている役割です
-
次にご紹介するのは
ユアヒム・ナイバートです
-
キールとハンブルグにある
ドイツ国立経済学図書館からお越しです
-
彼が取り組んでいるのは
世界最大の公開出版物アーカイブを
-
ウィキデータを使用して
一般に利用しやすくすることです
-
最後に私
ビート・エスターマンです
-
スイスのベルン応用科学大学に
勤めています
-
スイスやオーストリアで
OpenGLAMを長年推進しています
-
今日お伝えするのは
-
Canadian Arts Presenting Associationと
行っている活動です
-
舞台芸術に焦点を当てたものであって
-
ウィキデータが主ではありませんが
-
そこでもウィキデータが果たしている
役割を理解していただけるはずです
-
では着席させていただきまして
-
スサンナにお話しいただきましょう
-
こんにちは
スサンナ・オーネスです
-
ウィキメディア フィンランドで
-
非常勤のGLAMコーディネーターとして
働いています
-
またオープン ナレッジの分野で
コンサルタントも行っています
-
これはどちらかと言うと
後者に関するお話です
-
私が携わっているのは
-
地理的データグループに関する仕事です
-
その対象は―
-
英語では何かというか
調べました…
-
フィンランド王族統治の
文化遺産構想です
-
これは次に関係しています
-
地名と
-
地名がフィンランドのGLAMセクターの
異なるリポジトリにどう表されるか
-
また GLAMセクターが異なるソースを
どうまとめようとしているか
-
ウィキデータやその他モデリングにより
GLAMセクターがどう情報を得るかです
-
ここに示されているのは
YSO placesへの３つの主なソースで
-
これらは全国的または一般的な
オントロジーの一部です
-
AHAAは
フィンランドのアーカイブ向け
-
Melindaは
フィンランド図書館向け
-
KOOKOSは
フィンランド美術館・博物館向けです
-
ですから３つの
コンテンツ管理システムが
-
YSO placesにまとまっています
-
ウィキデータとの間では
すでにデータのやりとりが行われていて
-
国土調査向けの
ネームプロジェクトも同様です
-
またFinnish Names Archiveという
第３プロジェクトもあり
-
YSO placesには
まだ寄与していませんが
-
そのための計画はあります
-
全体の課題の中でも
-
重要なモデリングの課題の１つは
-
このプロジェクトに表されている地名に
-
３種類の要素があることです
-
うち１つ目が場所で
位置を持つものです
-
２つ目が地名で
例えば地名学による地名です
-
３つ目がソースで
-
これは場所と地名の双方の由来または
その裏付けとなる文献です
-
YSO placesは...
-
ここ右上に
同じ図がまたありますが
-
主に場所を重視しています
-
重要な点は YSO placesが
-
フィンランド国立図書館とFintoの
プロジェクトであることです
-
現在フィンランド語とスウェーデン語では
7,000を超える場所が存在し
-
英語では3,000を超える場所が
存在しており
-
パブリック ドメイン（CC０）の
ライセンスを取得してあります
-
ここに表示されているのは
Fintoのサービスです
-
場所はセベッティヤルビを
選択してあります
-
これは私たちのスコルト・サーミ語での
言語プロジェクトにも関係しています
-
ここはフィンランドの
極北に位置する場所で
-
スコルト・サーミが居住しています
-
ここで分かるのは―
-
この場所に関するデータが
-
ウィキデータと
国土調査のデータに
-
リンクしていることです
-
こちらがその詳細です
-
またこれはリポジトリの中に
階層的に整理されていますので
-
セベッティヤルビは
今表示されていませんが
-
この自治体の下に存在しています
-
そして その地域
-
そして国としてのフィンランドや
さらに広域の地域に含まれています
-
ここで分かるのは
YSO placesの多くが
-
Mix'n'Matchを通じて
すでにウィキデータと照合されています
-
未照合のものもあります
-
ですが 名前の量は
それほど多くありません
-
たった5,000未満です
-
他にもリポジトリとして
-
フィンランドの地理空間的プラットフォーム
プロジェクトによる
-
Place Names Cardsがあります
-
すべてフィンランドの地図に
載っている地名です
-
これらにはCCライセンス
バージョン4.0が付与された
-
リンクトデータもあります
-
80万の地図ラベルは
-
フィンランド語、スウェーデン語
フィンランドの３つのサーミ語によるものです
-
また２種類の異なるエンティティがあります
-
１つは場所で
-
もう１つは地名などの
場所の名前です
-
両方に恒久URIがあります
-
例えば同じセベッティヤルビに対し
-
まずフィンランド語
続いて３つのサーミ語
-
言語同様
地理的データがあり
-
そして場所の種類などの
さらなる情報があります
-
これは地名に対するカードで
-
独自のURIがあります
-
失礼 英語のリストに
翻訳されていないようですが
-
プロジェクトの一部は
多言語で取り扱われています
-
次にFinnish Names Archive
についてです
-
これは2017年フィンランドの
言語機関によるプロジェクトで
-
場所や地名でなく
-
それらのソースを説明するものです
-
地名に関する
３百万の現地調査記録を含む
-
ウィキベースのプロジェクトです
-
ウィキベースに主にフィンランド語
いくつかはスウェーデン語で収められています
-
サーミ語の名でも
傑出したコレクションがあり
-
興味深いものです
-
CC BY（表示）のライセンスが
付与されているため
-
ウィキデータの観点からは
困難ではありますが
-
フィンランド語の
ローカル ウィキベースがあれば
-
私たちがこのプロジェクトで
初めてそれに取り組めるかもしれません
-
こちらがそのプロジェクトの
スクリーンショットで
-
表示されているのは
場所に関する情報―
-
収集者が最初に使用した地図と
-
彼らが収集した情報から
生み出されたカードです
-
こちらはカードの１つで
-
それらに含まれる詳細データです
-
カードが送られる先は
リンクト データ プロジェクトで
-
ヘルシンキのデジタル
ヒューマニティラボ（HDHⅬ）と
-
アールト大学の
コンピューティング グループである
-
セマティック コンピューターと
（SeCo）
-
Names Sampoという
フィンランドの言語機関によるものです
-
これは地名のソースに追加される
-
集約型リサーチインターフェースです
-
左側で 多数のソースが
あることがここで分かります
-
またこのデータに基づいて
異なる視覚化も行えます
-
私が提案しているアイデアは
-
ローカル ウィキベース向けのモデリングに
このデータを使用することです
-
モデル方法などの
モデリングに関する疑問は出てきます
-
異なる方法や慣習が
それぞれにあるからです
-
良い点は わずかな努力で
少数言語をサポートできることです
-
ここに２つの選択肢があります
[場所が新規項目になるのはいつか]
-
フィンランド語の
時空オントロジーであるSAPOのモデルと
-
ウィキデータのモデルです
-
ウィキデータでは
新規項目にならない傾向があります
-
プロパティ変更に関わらず
同じ項目のままであることが理想です
-
一方 SAPOモデルでは
-
エリアや地名の変更があると
新規項目になります
-
そこで 場所と地名とソースの
３つの側面を持つ
-
この区分に戻りましょう
-
地名は エンティティとプロパティの
どちらにすべきでしょうか
-
ウィキデータが
プロパティを使用している一方
-
国土調査プロジェクトは
エンティティを使用しています
-
それとも
語彙素にするべきでしょうか？
-
ウィキデータは
地名に対して
-
語彙素よりも
テキストのプロパティを選択しています
-
失礼 逆でしたか？（笑）
-
ですから 地名は―
-
語彙素ではなく
プロパティですね
-
ウィキベースの欠点は
-
内部に地理的情報が
不足していることかもしれません
-
例えば 基本設定では…
-
地域的な地理的情報を
使用できるようにするためには
-
スタックにテクノロジーを
加える必要があるでしょう
-
またウィキデータのコーパスを
活用できるようにするためには
-
フェデレーションが必要です
-
以上です
ありがとうございます
-
（拍手）
-
はい
-
（マオリ語）
-
ようこそ 皆さん
マイク・ディキソンです
-
１年間
-
ニュージーランドの
ウィキペディアン代表でした
-
ウィキペディアン代表とは
何かと思われるでしょう
-
調べてみると ご覧のように
そんなものはないからです
-
補助金申請で
私が造った言葉です
-
財団は気に入ってくれたようなので
-
その肩書を使っています
-
１年間で35の異なる機関を経験しました
-
そのほとんどが在駐で
トレーニングセッションを行い
-
公開イベントを企画し
-
各所でウィキメディア戦略を
発展できるよう努めました
-
面白い経験で
-
さまざま広範囲の
プロジェクトや人々に出会いました
-
面白く啓蒙的な方法で
ウィキデータを扱っている
-
異なるプロジェクトの
いくつかをお話します
-
これが皆さんの議論に
役立つかもしれません
-
このプロジェクトは最初
ウィキペディアのプロジェクトでした
-
ウィキペディアの名は
よく知られていたからです
-
伝統的な編集マラソンや
ジェンダーギャップに関するものなど
-
複数の別のイベントを企画しました
-
多くの皆さんが[聞き取り不能]
-
新しい編集者をうまく募集したり
することができました
-
コモンズへ
大量のアップロードを行いました
-
次のような事例もありました
-
昆虫学のイラストレーター
デス・ヘルモアによる
-
千を超えるオリジナルアート作品の
コレクションが
-
ハードドライブに放置されており
-
10年に渡る調査研究
[聞き取り不能]
-
すべてCC BYライセンスの下で
公表する許可を得たのです
-
これで世間の人たちに
見てもらいやすくなりました
-
甲虫類のたくさんのイラストで
皆が理解でき
-
ジェンダーギャップを埋める
ワークショップも 皆が理解できます
-
ですが ウィキデータは
-
GLAMセクターや
特定の活動を行う外部の人々に
-
導入してもらうのは
難しいものでした
-
ウィキデータは
-
ウィキペディアン代表の
プロジェクトの
-
ますます重要な部分になると
私は気付き始めました
-
プロジェクトが進むにつれ
-
私の仕事の大部分を
占めるようになりました
-
そこで ウィキデータを
自分で学ぼうとし始めました
-
どれだけ重要か
分かり始めたからです
-
こんなプロジェクトがありました
-
カカポ（フクロウオウム）は
ニュージーランド固有の跳べないオウムです
-
種を絶滅から救う仕事をしている
保護局と協働し
-
「ウィキデータへ
一羽一羽のカカポを収めては」と
-
アイデアを投げ掛けました
-
とんでもないようですが
-
十分に実行可能なプロジェクトで
-
すでにいくつかは収められています
-
カカポはたくさんいるわけではないので
-
扱える作業です
-
開始時には148羽いて
１羽が死にましたが
-
記録的な繁殖期に
213羽まで増えました
-
過去50年で最大のカカポ数というのは
素晴らしいことです
-
これは一大事で
-
ニュージーランドで毎日
報道されました
-
新しいカカポが生まれるたび
-
（聴衆）ニューヨークタイムズでも
-
（マイク）そうですか
素晴らしい
-
これは国内ニュースでした
皆に好かれている鳥です
-
面白いことに
-
個体数の多い種と違い
-
カカポは１羽残らず
独自の名前が名付けられていて
-
独自のID番号があることです
-
またしばしば
良い伝記データもあります
-
例えば出生地や
誕生日
-
孵化した日や
父母
-
死亡した場合は
死亡日などです
-
こうした情報は
保護局のデータベースにあります
-
最も有名なカカポの１羽は
-
風にちなみ名付けられた
Sirocco（シロコ）で
-
ご覧の誕生データがあり
-
Twitterアカウントもあります
-
ウィキデータは
それに関して多少問題があります
-
Twitterアカウントを
持てないからですかね
-
アルバムカバーで
特集されたりしています
-
このプロパティは複数あり
-
最も有名な
固有のカカポの１羽です
-
個々のカカポを収めるアイデアを
保護局に投げ掛けた際
-
どれだけの伝記データを公表するか
-
考慮する必要がありました
-
簡単なリストにして
-
現在212羽...
２羽は死んだので210羽が
-
生存しているカカポの
候補すべてです
-
巣立つときに名付けられ
-
まだヒナの間だけ
コード番号を持ちます
-
完全に羽が生えそろった時に
-
ウィキデータを整えて
-
種全体をウィキデータに収めるのですが
-
DOC IDに対する
プロパティは考える必要があり
-
それを皆さんにご相談したいのです
-
特定のIDを使用すべきか
-
または 特定の調査プロジェクトに
タグ付けされている―
-
個体の鳥や植物や動物に対して機能する
IDを考えるべきかというのは
-
良い質問です
-
２つ目のプロジェクトは
クライストチャーチ アート ギャラリーです
-
ニュージーランドで
最も有名なアーティスト
-
コリン・マカホンの絵画が
数点 存在しています
-
ニュージーランド
スクール ジャーナルのための絵画で
-
当時 政府が出資したものでした
-
ニュージーランドの
アーカイブが
-
これらの絵画の著作権を
持っていました
-
これは非常に稀な状況です
-
私はクライストチャーチ
アート ギャラリーに勤め
-
オークランド
アートギャラリーと共に
-
Find New Zealand Artists
というサイトを管理していました
-
この仕事は
ニュージーランドのアーティストの
-
各機関の保有資産を追跡することでした
-
データベースにある
１万８千の異なるアーティストの大半に
-
情報がほとんどありませんでした
-
そこで例のMix'n'Matchで参照し
-
少なくとも誕生日
または死亡日
-
誕生地や死亡地の
-
情報があるものをエクスポートしました
-
ですから あまり限定されていません
-
それでも 一致したものは
それほどありませんでした
-
でも 現在ウィキデータで
著名なアーティストに一致するものは
-
現在約1,500あります
-
これは良いことです
-
ですが彼らにとっての利点は
-
彼らのウェブサイトであることです
-
資産へのリンクで管理するだけです
-
ですがこの伝記データは
-
アーティスト一人一人に対し
現在 手作業で作成されています
-
エクスポートや
Mix'n'Matchによる照合で
-
それまで気付かなかった
-
数々の入力ミスと間違いなどが
明らかになりました
-
Excelを通じて
並び替えを実行すると
-
これらの問題が明らかになります
-
ウィキデータから情報を取り込めると
私が言ったとき
-
彼らにとって
それは真新しい考えで
-
ウィキデータの価値は急に変わりました
-
これは利点の１つだと思います
-
手間暇かけて手作業でキュレートされた
ウェブサイトがある場合
-
１万８千ものエントリーに
多数の誤りがあっても
-
他の人に事実確認と修正を
行ってもらうという
-
別の方法を示せれば
-
共感してもらえます
-
私たちは次のような
アイデアを投げ掛けました
-
30年代のクライストチャーチの
ニュージーランド アーティストの
-
歴史本のすべてを
「ウィキデータ化」するというもので
-
あらゆる人物、コネクション、場所、展示
などの出版物をデータ化するものです
-
これは管理できる規模のプロジェクトで
彼らは喜んでいました
-
３つ目に Maori Subject Headings
（マオリ件名標目）をお見せします
-
waka（ワカ）とは
-
特定の種類のカヌー
戦争カヌーに対するマオリ名です
-
ニュージーランドの国立図書館に
wakaに対するリスティングがあり
-
国立図書館は
マオリの件名標目に関して
-
マオリ語による
独自の辞書を持っているからです
-
そこでwakaは
-
マオリ語と英語で定義されています
-
さらに狭義の言葉もあります
-
画面端でご覧になれます
-
典型的なものは
taurapa（トゥーラパ）です
-
まずマオリ語で
次に英語で定義されています
-
これはご覧のように
彫刻を施した船尾のことで
-
英語で「sternpost」ですが
-
taurapaに
その語は使えません
-
taurapaは特定の種類の
戦争カヌーの船尾のみを指すからです
-
それに相当する英語はありません
-
文化的特定用語のオントロジー全体が
注意深くまとめられ
-
国立図書館とマオリ人により
確認されています
-
英語でもマオリ語でも
-
常に 定義や説明に
追加や改善がされています
-
素晴らしいことです
-
私はこのたくさんの情報を
-
まずマオリ語で
次に必要に応じ英語への翻訳で
-
ウィキデータに収めることを
考えつきました
-
そうなったらいいですよね
-
こちらが著作権とライセンスです
-
あいにく非営利‐改変禁止です
-
そこで彼らがこのライセンスを
選択した理由について
-
お話ししましょう
-
恐らく このいかなる情報も
営利目的で使用できないという保証を条件に
-
腰を下ろして
[聞き取り不能]ことに承諾した
-
マオリ人からのみ同意を得たからです
-
そこがこの仕事のもどかしい面で
-
こうした制限事項に直面しています
-
次の３つを前面に押し出して
議論の拍車をかけたいと思います
-
ウィキデータに種全体を取り込むこと
-
ウィキデータの価値に関する
アートギャラリー学芸員の考えを変えること
-
そして別の言語で完全なオントロジーが
ある場合にどうするか―
-
これはクリエイティブ コモンズの
ライセンスが限定的なため実現していません
-
ありがとうございました
-
（拍手）
-
ユアヒム・ナイバートです
-
ZBW（ドイツ経済学中央図書館）に
勤めています
-
これはハンブルグにある
経済学のための情報センターで
-
私は科学ソフトウェア開発者として
働いています
-
昨年の仕事の一部は
ウィキデータへ提供するデータの準備でした
-
メタデータの提供や
20世紀の出版物アーカイブなど
-
初めての経験として
その仕事に関してお伝えします
-
私たちが知る限りでは
-
これは世界最大の
公開出版物アーカイブです
-
1908年から2005年の間に
集められた
-
1,500を超える新聞と定期刊行物があり
-
収集範囲はドイツ国内から
世界にまで及びます
-
すべてが網羅されているので
-
興味を引くものであり
-
世界中に進出したい
ハンブルグの経営者には
-
特に興味深いものだと思います
-
ご覧のとおり
この資料は新聞の切り抜きで
-
紙に貼られていて
-
それがフォルダーに集められています
-
こちらが人物に関するアーカイブの
小さなコーナーで
-
それと同様に
-
企業や一般の話題や業績
すべての人
-
興味を引きそうなこと
すべてに関する情報が集められています
-
これらのフォルダーは
-
2004年から2007年までのDFG
（ドイツ研究振興会）出資プロジェクトにより
-
およそ1949年までは
スキャンされています
-
結果として現在までに
-
この時代の主題関係書類は
２万５千あります
-
これには約２百万あるいは
それ以上の数のページが含まれ
-
オンラインに掲載されています
-
当時 ZBWが開発した
アプリケーションがあり
-
現在では少し時代遅れで
-
凝ったものではなく
さらに問題なのは
-
オラクルやColdFusionに基づき
開発されたアプリケーションは
-
Windowsサーバー上で
運用するものなので
-
長期的に持続可能ではありません
-
もっと凝ったリンクト データ
アプリケーションへこれを統合すべきか
-
大胆な措置を取って
-
すべてのデータを公開するかを
話し合いました
-
データにはCC0ライセンスを
割り当ててあります
-
現在は主要アクセス レイヤー
-
主要ディスカバリ レイヤー
プライマリ アクセス レイヤーを
-
リンクト オープン データ ウェブへ
移行していますが
-
ここで実は最も合理的なのは
-
ウィキデータへメタデータを収めて
-
コレクションのすべてのフォルダーを
-
ウィキデータとリンクさせることです
-
そうすれば見つかりやすく
-
これらフォルダーに関する
すべてのメタデータを
-
ウィキデータへ転送することもできます
-
そこで使用でき
データの追加や
-
修正も行えるようになります
-
ZBWはまだもちろん
画像の保管を管理します
-
いかなる方法でも
移行できないとか
-
オリジナルの作者が所有していたため
ライセンスを与えられない画像です
-
ですが 将来的には
IIIFマニフェストに基づき
-
DFGビューアー経由の
メタデータファイルにより
-
それらを利用できるようにします
-
固定ランディングページも
準備する予定です
-
これはウィキデータへの参照の
データポイントの機能を果たすものです
-
また ウィキデータへ
うまく収められないデータを
-
利用できるようにする予定です
-
私たちはウィキデータへの
データ統合とデータ提供を
-
そのデータの
SPARQLエンドポイントから成る
-
カスタムのインフラを使用し行い
-
そして
フェデレーテッド クエリを使用して
-
エンドポイントと
ウィキデータのクエリサービスとの間で
-
一致した文を作成します
-
これは SPARQLクエリ自体
またはスクリプト経由の変換での
-
連結という観点を通して行うものです
-
これにより その文のための
出典も生成され
-
QuickStatementsの
コードへ収められ
-
オンラインで使用できます
-
こちらが成果です
-
誕生日などのように
簡単なものではないですが
-
すでに存在している項目に関する
-
複雑な文もあります
-
例えば 企業の管理役員だったこの人物です
-
ご覧の期間に
-
科学的文脈で使用するために…
-
参照されています
-
データ提供の
最初の部分が済むと
-
人物のアーカイブは
完全にウィキデータにリンクされます
-
これは情報ツールでもあります
-
以前は数多くの項目に
外部の出典がありませんでした
-
私たちには6,000を超える
文がありましたが
-
これは現在はアーカイブのメタデータが
出典とされています
-
人物に関しては最も簡単でした
-
なぜならウィキデータで
人物は簡単に識別できるからです
-
そこに90％超は
すでに存在していたので
-
私たちはそれにリンクできました
-
欠けている人物のために
100項目ほど作成しました
-
現在はアーカイブの残りの部分
-
特にトピックのアーカイブに
取り組んでいます
-
つまり世界全体の
知識組織化のために
-
歴史体系のマッピングに取り組み
-
ウィキデータへ新聞の切り抜きとして
資料化しているのです
-
基本的概念をお伝えすると
-
国とトピックのアーカイブは
-
国々の階層構造と
その他の地理的エンティティで
-
整理されています
-
これは英語に翻訳されていて
利用しやすくなっています
-
ドイツ語は…
-
トピックでは
深い階層に分類されています
-
この組み合わせにより
-
１つのフォルダーが定義されています
-
私たちが次に行いたいことは
-
これをウィキデータへの
構造として一致させ
-
データを移行することです
-
知識組織化という
この良い挑戦に
-
皆さんご参加ください
-
この仕事を追跡する場が
ウィキプロジェクトで
-
皆さんはそれをフォローしたり
それに参加したりできます
-
以上です
ありがとうございました
-
（拍手）
-
私たちはウィキデータへ
舞台芸術を取り込んでいます
-
舞台芸術向けのリンクト オープン データ
エコシステムを構築することで
-
舞台芸術とリンクトデータを
クラウドへ取り込んでいるのです
-
これからウィキデータに関連する質問に
お答えしようとしており
-
皆さんにもその回答に
ご協力いただきたいと思いますが
-
まずは 私の経験からお話しさせてください
-
私は今年―
-
今年前半にCAPACOAと
楽しく仕事をしていました
-
Canadian Arts Presenting Association
（カナダ芸術表現協会）の頭文字で
-
リンクト オープン データを
カナダの芸術部門全体で採用してもらえるよう
-
Linked Digital Future Initiative
というプロジェクトを開始したのです
-
過去５年間の観察に基づき
彼らはそれを行いました
-
[聞き取り不能]
舞台芸術で重要な課題は
-
メタデータが
不十分な品質であったことと
-
リンクされておらず
相互運用できなかったことでした
-
そんなわけで
パフォーマンスやイベントの中には
-
Googleや個人の端末などで
-
うまく見つけてもらえないものも
ありました
-
そこで私たちが共に築いたビジョンは
-
一度に数多くの利害関係者のための
情報ベースを持つことでした
-
舞台芸術全体の
バリューネットワークを調べて
-
そこでの主要な利害関係者を
明らかにしました
-
また追求したい
利用シナリオも調べ
-
それを情報ベースまたは
異なるプラットフォームから成る
-
アーキテクチャ全体に地図化しました
-
これは明らかに
分散アーキテクチャであり
-
巨大な一枚岩ではありません
-
各自10分しかないので
-
これをさっとご説明しますが
-
詳細に興味がある方がいれば
-
今晩とか明日 理解を深める時間が
あると思います
-
私たちが着手したのは
舞台芸術のバリューネットワークからで
-
これは面白いことに
去年発表されました
-
以前の仕事に基づき
構築できたのはラッキーです
-
中央にあるのが
舞台芸術の基本の価値連鎖で
-
さまざまな利害関係者が
それを取り囲んでいます
-
私たちは全部で
20の利害関係グループを見つけ
-
各利害関係グループのため
-
それを７つの大きなカテゴリへ要約しました
-
そしてインフラの観点から
-
彼らがどのようなニーズを持ちうるか
-
また 全体がリンクされ
データが公開で利用できたら
-
何を達成できるかを
系統立てて明らかにしました
-
異なるタイプが表示されていて
-
Production（制作）
-
Presention & Promotion
（表現とプロモーション）
-
Coverage & Reuse
（報道と再利用）
-
Live Audiences
（ライブ オーディエンス）
-
Online Consumption
（オンライン消費）
-
Heritage（継承）
-
Research & Education
（調査研究と教育）です
-
こちらに最初の一部分が表示されている
-
大きな表を設定した後
-
その表で比較し
-
すべての利害関係グループが
全体に渡り利用しているのは
-
どのデータタイプかを調べました
-
これは全体に共通する
大きな基本データで
-
この領域こそ
-
共に協力して
データを維持することが
-
合理的な領域なのです
-
プラットフォームの
アーキテクチャについては
-
ここに４つのレイヤーがありますね
-
下部にはデータレイヤーが表示されています
-
もちろんウィキデータは
その一部の機能を果たしますが
-
その他データベース
分散データベースもたくさんあり
-
SPARQLエンドポイントを通じて
データが公開されています
-
中央の黄色部分が
セマンティック レイヤーで
-
物事を表現するための
共通の言語で
-
舞台芸術の物事や
オントロジーに関する文を作成できます
-
そして次に
アプリケーション レイヤーがあり
-
これはデータ分析やデータ抽出などの
さまざまなモジュールで構成されています
-
つまり 非構造化データを
構造化データにする方法や
-
それをツールでサポートする方法です
-
それからデータの画像化もあります
-
大量のデータがあれば
何らかの方法で可視化できます
-
また上部に
プレゼンテーション レイヤーがあり
-
これが普通の人たちが実際に
日々やりとりするもので
-
検索エンジンや百科事典
文化的アジェンダ
-
その他各種サービスがあります
-
一から始めたわけではなく
-
この領域で
すでに作業がなされていました
-
私が参加してきたプロジェクトから
いくつかの例を取り上げましょう
-
またその他についても
取り上げていきます
-
私はこの領域において
-
舞台芸術に関する
スイスのアーカイブから始めました
-
スイスの舞台芸術のデータベースを
構築するまで
-
舞台芸術のオントロジーを作成しました
-
現在はRDFになっています
-
スイスの舞台芸術の歴史に関しては
-
60、70年間の
データベースがありますから
-
それを基礎に開発できますし
-
RDFに変換もされています
-
データが利用できる
構築プラットフォームもありました
-
ウィキデータへ
いくらか取り込み済みです
-
一部はスイスからのデータで
-
舞台芸術機関からのデータもあります
-
例えば バート・マグナスが
それに関与しており
-
彼が背景の原動力です
-
またウィキメディア コモンズからの
データもありますが
-
私たちの残りのメタデータと
うまくリンクされていません
-
また この取り込みを行うことで
-
スイスのデータモデルを
ウィキデータへ実装し始めたことになります
-
カナダの実装提携業者の１つが
-
Culture Createsです
-
プラットフォームを運営し
劇場のウェブサイトから情報を取得し
-
それをナレッジ グラフに入力し
-
そして 検索エンジンや
その他デバイスに表示します
-
そこでも実装や
オントロジーへの拡張の必要があり
-
スライドで分かるように
-
まだ空き領域はありますが
重複もあります
-
重要な重複は
一般共有された言語で
-
これはさまざまなデータセットを
リンクするのに役立ちます
-
また重要なことは
-
ベースレジストリと典拠ファイルを
使用していることです
-
ここが これらのリンクにより
-
ウィキデータが
重要な役割を果たす所です
-
では Linked Data Future Initiatives
諮問委員会による
-
アドバイスを共有したいと思います
-
少なくとも２つのアドバイスがあります
-
カナダ自体の舞台芸術の
ナレッジ グラフを埋めるため
-
カナダの方々には絶対的に重要です
-
スイスの舞台芸術のアーカイブと異なり
-
すでに存在しているデータベースから
始めるわけではなく
-
一から構築しなければならないからです
-
データをそこに取り込むことが
間違いなく重要です
-
２つ目に ご覧のように
ウィキデータはすでに役立っています
-
ウィキデータは
諮問委員会によると
-
ナレッジグラフArtsdata.caを
補完するものであり
-
舞台芸術関連のデータを増補するため
-
貢献の努力がなされるべき
とのことです
-
そこが私たちが今後
短中期的に取り組む箇所であり
-
そのためここで
その努力に協力してくれる人が
-
見つけられればと思います
-
現在 私たちは
互いに補完するものとみなしています
-
そこで両方の手法の
長所と短所を考える必要があります
-
こちらがウィキデータと従来の
リンクト オープン データとの比較です
-
皆さんの経験も交えて
喜んでお話ししたいと思います
-
ウィキデータには大きな長所があります
-
クラウドソースの
プラットフォームであり
-
関係者を招いて
協力してもらいやすいからです
-
短所は管理しにくいことです
-
データの所有者は
自身の図などの権利を手放すことになり
-
データ品質や完成度の管理を
-
自分の管理下にある場合と比べて
ウィキデータで追跡するのは困難です
-
ウィキデータのその他の長所は
-
世界規模の図への
瞬時での統合が要求されることです
-
つまり段階的に
他のデータベースと
-
調整していくことはできません
-
これも長所だと考えられます
-
もちろん統合や
相互運用性をお求めなら
-
ウィキデータでは初めからきちんと
その機能が備わっています
-
データ モデリング方法の統一は
-
両方のケースで課題となっています
-
ですが 最初は各自の部門で行うほうが
簡単に見えます
-
ある時点でその作業が済めば
-
ウィキペディアで
継続する作業になるからです
-
データ取り込みの
優先順位付けに関しては
-
現時点で次の規則に従っています
-
まず 本来誰に権限があるか
確かでない状態で
-
データを取り込むことです
-
こうすれば間違いなく
共有で管理されることになります
-
また クラウドソースの手法の
可能性が高いデータを取り込むこと
-
ウィキペディアで再利用される
可能性の高いデータを取り込むことです
-
また データモデリングと
標準化に関する
-
国際的な共同作業は
-
もし他の場所で行われていなければ
-
ウィキデータ上で
直接行われることが望ましいです
-
同じ場所でデータを取り込めば
交流が生まれるからです
-
次に ベースレジストリと典拠ファイルに
焦点を当てましょう
-
既存オントロジーの拡張として
-
異なるデータや
管理されていない語彙の間で
-
リンクしやすくなるからです
-
スライドがあと２枚だけあります
-
次のステップは
Wiki Loves Performing Artsに向け
-
すべてのGLAMの手法を
合わせることです
-
つまり会場や組織を
-
インフォボックスや
バブル テンプレートの形式で表し
-
ウィキペディアに
データを取り込もうとする試みです
-
もう１つ追求するプロジェクトは
COST Actionで
-
来年 提起する予定の
-
舞台芸術向けのリンクト オープン データ
エコシステムです
-
COSTはヨーロッパのプログラムで
-
ネットワーキング活動と
-
ここに取り上げ挙げられた
トピックをサポートしています
-
うち２つを抜粋してありますが
-
１つはウィキデータと
従来のリンクト オープン データ間での
-
フェデレーションに関する質問です
-
もう１つは
これも重要だと思いますが
-
大きな可能性を秘めている部分で
-
ウィキデータのデータを追加する
国際キャンペーンの実施です
-
以上です
ありがとうございました
-
では 私の同僚たちに
登壇いただきましょう
-
パネルへどうぞ
マイクも必要かもしれません
-
それから…
-
質問の機会を差し上げます
-
また 私の同僚たちにも
-
お互いに質問があるかお尋ねします
-
聴衆の皆さんからは
質問があるでしょうか
-
（聴衆１）[聞き取り不能]
-
お一人ずつに質問ですが
-
どこで線引きをして
-
どのように―
-
自分のウィキベースを
運用する必要がある場合や
-
ウィキデータへ取り込みたい内容を
規定するのでしょうか
-
順序良く取り込める背景には
明確な図表があるのでしょうか
-
マイクがあるので
まず私からお答えします
-
課題の１つは著名度です
-
別のプロジェクトで
それに取り組んでいます
-
ライセンス供与も課題の１つです
-
ご自分のデータベースでは
自分独自の規定を適用できますから
-
そうなると
どこでも可能だと思います
-
３つ目はサンドボックスとして
データを保持し
-
ウィキデータへ取り込むため
それを準備することです
-
以上が今考えられる
主要な３つですが
-
まだあると思います
-
私にとっては
著作権はいつも課題です
-
国立図書館が
ウィキベースに向けて移行したい場合
-
マオリ語の言葉での
これまでの業績のため
-
彼らがライセンス管理を
継続しなければなりません
-
カカポのデータベースには
-
保護局が公開できると考えた
データのみがありますが
-
その運用を見れば
-
非公開のウィキベースを使用して
-
独自データベースを
管理したくなるかもしれません
-
単に彼らが現在運用している
Excelスプレッドシート体系よりも
-
視覚化ツールの一部を
適用できたほうがいいからです
-
データの種類に依ると思います
-
出版物のアーカイブでは
もちろん幸運な立場で
-
資料は出版されたものや
-
当時 出版するには高額で
公開されたものですから
-
これは簡単です
-
プロジェクトは―
-
典型的なプロジェクトでは
-
ある期間 資金提供され
それが終了すると
-
データに起こることは
倉庫に格納されるか
-
永遠には運用されないソフトウェアに
格納されることになります
-
ですから私の観点からは
明らかで
-
当時はウィキデータはありませんでしたが
現在はあるので
-
ウィキデータのような
より大きなエコシステムへ
-
データを取り込む方法と照らし合わせ
-
早い段階で
持続可能性を議論することは
-
私たちのプロジェクトにとって
間違いなく合理的です
-
またデータコミュニティーと
話し合うのも意味があります
-
例えば ウィキデータへ追加するには
何が著名で合理的か
-
また所有権の形式を保つには
何が合理的か
-
洗練されたアプリケーションよりも
-
簡単な形式でも
視認性を高めたほうがいいとか
-
維持されない保管場所へ
多額の資金を提供する代わりに
-
大きなデータクラウドへ
リンクさせたほうがいいなどの議論です
-
先ほどここでプレゼンした
プロジェクトでもお伝えしたように
-
従来のリンクト オープン データ手法と
ウィキデータとでは二重性がありますので
-
非公開のウィキベース設定
という問題ではないのです
-
抱えていた課題の１つは
もちろんウィキデータで
-
自分自身のデータを取り込む際に
-
人々というか 他人の
ハウスキーピングを行う必要があります
-
それによって参加する人が
減るかもしれませんが
-
段階的に取り組んでいくということです
-
現時点では データベースは
-
従来のリンクト オープン データに
ありますが
-
私たちはそれをウィキデータと
リンクし始めており
-
これは継続的なプロセスで
-
最終的に大半のデータを
ウィキデータに収める領域と
-
その他のデータベースに残す領域とを
明らかにしていきます
-
明らかに同期に関しては
すでに課題であるように
-
今後も課題になります
-
リンクトデータの分野では
-
誰を信用できるか
-
誰が何の権限を持つかなど
協議が必要です
-
（司会者）他にご質問は？
-
（聴衆２）ありがとうございます
-
私が完全に同感できるのは
-
どこで境界線を引き
ウィキデータにデータを収めるかどうか
-
どのような理由や目的で
ローカルのデータベースに
-
データを保存し 作成や管理や維持を
行うかという課題です
-
これは大きな議論で
-
単にウィキデータへデータを
移行するという
-
流行りを超えたものだと思います
-
公開により人類に貢献でき
-
優れたツールがあるからです
-
現実の物事はもっと複雑だと思います
-
それにも関わらず
興味深い議論だと思います
-
また 別のパネルのイベントで
議論されている
-
別の問題もあります
-
１つの側面では
自身のデータベースを持ち
-
どのようなテクノロジーであれ
-
ウィキデータへ公開したり
-
またはウィキベースのテクノロジーで
情報を作成管理する
-
独自のシステムを開発したりすると
-
同期やフェデレーションなどは
-
使用するテクノロジーの問題です
-
実際は ウィキデータを
公開のためだけに使用しているか
-
ウィキデータの下にある
インフラを使用して
-
自分のデータの作成や
管理をしているかです
-
ウィキデータのパネルについて
議論があり
-
ここで別の議論も出てきますが
-
物事は別のレベルにあると思います
-
ウィキベースかウィキデータかという
議論に達するのは―
-
間違いだと思います
-
ウィキデータのインフラを
重視しすぎてしまいます
-
舞台芸術の領域のように
他にもインフラはあるからです
-
私たちには
別の補完コミュニティーもあり
-
MusicBrainzは
独自のプラットフォームを運用し
-
リンクト オープン データを提供しています
-
私が理解している限りでは
-
ウィキデータのコミュニティー内で
-
彼らのデータを
重複しないという同意があり
-
すべてのデータをコピーはしませんが
補完し合うものだと受け入れています
-
そこで ウィキペディアで
データを統合するとどうなるでしょう？
-
例えばインフォボックスです
-
彼らのSPARQLエンドポイントから
そのデータを直接引き出せるでしょうか？
-
またはすべてのデータを
コピーせざるを得ないのであれば
-
それにはどんなプロセスが
関与するのでしょうか？
-
（聴衆２）議論はまだ続いていると思います
-
このイベントの中では
-
関心を寄せるコミュニティーは
両方あるはずですから―
-
ウィキベースに関心がある人たちと
-
ウィキデータに関心がある人たち
-
そしてその両方に関心がある人たちです
-
ですが余儀なくウィキベースに
移行するわけではありません
-
そうとも限りません
-
MusicBrainzは
ウィキベース稼働ではありません
-
（聴衆２）別の問題があると
申し上げたかったのです
-
相関する場合もありますし
まったく関係ない場合もあります
-
もう１つ質問か意見があります
-
管理された語彙の
階層構造の管理についてです
-
例えば シソーラスや
Fintoです
-
場所があり
-
マオリ語での―
-
Subject Headingsがあり
-
階層構造での管理という概念に
対処しなければなりません
-
ご意見をお聞かせください―
-
ウィキデータで管理された
知識組織化体系を
-
管理する可能性については？
-
FintoとYSO placesの場合では
-
リポジトリは
-
最終的にいくつかのソースの
集まりになります
-
ですから ともかく流動的です
-
必ずしも必要ありません
-
私は国立図書館の代表ではないですが
-
その考えられるプロジェクトで
-
既存の構造を管理したり
対処したりする必要はないのです
-
その意味では
まだ探索がされるべき領域です
-
Maori Subject Headingsは
-
ウィキペディアの構造に対して
理想的に自身に役立っているようです
-
ですが ライセンス供与は
禁じられています
-
ライセンスが異なっていたら
-
ウィキデータへ
取り込まれていたでしょう
-
誰かが階層構造を好まずに
変更を始めると同時に
-
その構造を構築した人から
すぐに激しい抗議が来て
-
さまざまな異なるマオリから
-
最新の階層構造について
承認を得ることになります
-
それが解決しようとしている課題です
-
知識組織化体系という言葉は
-
すべて違います
-
ウィキデータで
異なる階層構造を表すことが
-
良い考えかは確かではありません
-
データの重ね合わせを
考えたほうがいいかもしれません
-
コンセプトレベルでの
マッピング作業については
-
例えば ZBWの共同事業として
経済学向けのシソーラスがあります
-
このシソーラスは
自身の階層構造を持っており
-
もちろん ウィキデータのコンセプトへ
-
ウィキデータの中に
代替構造を実際に保管せず
-
シソーラスの階層構造を
反映することは可能ですが
-
これは混乱を招きます
-
しかし ウィキデータを
コンセプトの貯蔵庫として考えるべきでしょう
-
外部にあるレイヤーとリンクでき
-
必ずしもウィキデータの中に
存在する必要がないものという
-
別の見方を与えてくれます
-
（司会者）他にご質問は？
-
なければ...どうぞ
-
（聴衆３）ユアヒム
最後の点を確認させてください
-
レイヤーは あなたのお考えでは
-
外部で管理され
-
誰かがどうにかして ウィキデータ側から
-
ウィキデータと統合されるものですか？
-
それとも管理方法について
すでにお考えがありましたか？
-
いいえ 考えてはいませんでした
-
ZBWとウィキデータで
いくつか試みはありましたが
-
ウィキデータで
[聞き取り不能]でした
-
これはまったく新しい
複雑な問題です
-
議論によりますし
-
そのようなことを行うには
管理を諦めなければなりません
-
ですが 明らかにされるべきです
-
もう１つ受けますか？
-
（聴衆４）質問は
カカポのプロジェクトについてです
-
はい
-
（聴衆４）こうした項目に
個々の動物を持つことについて
-
ウィキデータの
コミュニティーから反対はありましたか？
-
これまでのところないです
-
（聴衆４）以前この件を
聞いたことのある人は？
-
これまで反対がないのは
まだ誰も知らないからでは？
-
時に小さな議論がされています
-
ウィキデータで
こうしたことに関心がある方たちは皆
-
これを 有名な競走馬やネコに対する
個々のウィキデータ項目の付与を
-
自然に延長したものだと
見なしています
-
うまくモデル化されています
-
そこに種全体を収めるのは
大胆でしょうが
-
完全に管理できることだと思います
-
（聴衆４）ネコやイヌで
お試しにならないように
-
（笑）
-
（司会者）お時間が参りました
-
ご参加ありがとうございました
-
パネリストの皆さんが
休憩の間も質問をお受けします
-
お楽しみください
-
ありがとうございました
-
（拍手）
