連携するデータ、リンクするデータ

クリック/タップや→/Nキーで次のページに進みます。Aキーで一括表示と切り替え可。

1 データのウェブ

人間向けコンテンツ中心の文書のウェブ
- HTMLによるコンテンツの記述
- 半構造化データ（単純な文書構造の表現）
- 厳密さよりも柔軟性（エラーは許容する）
エージェント処理を前提にしたデータのウェブ
- RDFによる共通のデータ表現
- グラフによる柔軟なモデル
- 整形式XMLなど、構文は厳密に
両者を結ぶリンク
- (X)HTMLへのRDFの埋め込み／(X)HTMLからのRDFの抽出
- いずれのウェブも、リンクによって情報の価値が増す
- グローバル規模のネットワーク効果

2 RDFのトリプルとグラフ

処理しやすいシンプルなトリプル
- RDF: リソースの関係を主語、述語、目的語のトリプルで記述する
- どんなデータでもこの3つの要素だけ考えればよいので処理がシンプル
複雑なデータを記述できる柔軟なグラフ
- グラフ＝トリプルの集合は複雑なモデルも表現できる
- 複雑なモデルも単純なトリプルに還元できる

3 名前と識別

人間はコンテクストを理解できる
- 曖昧な名前でも適切な判断ができる
- 「あのファイル読んでおいて」「じゃあ3時に始めます」
コンピュータには曖昧さのない名前が必要
- 情報ごとに決まった名前付けのルールが
- /home/mkanzaki/2007/keio-lec.txt、2007-11-29T15:00+09:00
Operaが表すものは、文脈によって異なる
- 音楽の文脈なら歌劇
- ウェブ技術の文脈ならブラウザ
- コンピュータが処理するRDFでは、文脈に依存しない名前（識別子）が必要

4 エンティティの識別

記述の対象の明示
- 記述対象を、他の対象と区別する
- 複数の記述のうち、同じものについての記述を判別する
エンティティに識別子を与える
- 事前の（コミュニティ内の）約束に基づく識別子：図書館の書籍ID、NDLSHの概念識別子など
  - 同じ識別子を、別のコミュニティでは異なる意味に用いる可能性がある
- よりグローバルで分散的な識別：URI
- RDFではエンティティ（主語、目的語）をURIで名前付ける
  - URIはネットワーク上でアクセスできないものでも名前付けできる

5 グラフの併合とデータ連携

同一の名前のRDFノードは併合できる
- 「Opera」という名前の2つのノード（リテラルノード）は、同一であることが確認できないのでマージできない
- http://www.kanzaki.com/ns/music/Operaと名前付けられたノードは、併合できる
URIによる識別は、グラフのグローバルな併合を可能にする
- 異なる組織が作ったRDFグラフでも、同じURIならばノードは併合できる
- 異なる図書館、あるいはサービスのデータをRDFグラフとして併合できる
- ひとつの組織、サービスではカバーしていない情報も、グラフ併合によって共有できる

6 RDFリソースの型とリンク

RDFリソースのタイプは3種類

型	機能	主語	述語	目的語
URI	グローバルに名前付けされるリソース	○	○	○
空白ノード	URIで名前付けされないエンティティ	○	×	○
リテラル	文字列そのもの	×	×	○

URIで名前付けする → リンク先が識別される
RDFデータの「リンク」にはURIが必要
空白ノード、リテラルにはリンクできない

7 プロパティの解釈

プロパティをグローバルに表現する
- プロパティも「title」では文脈に依存してしまう
  - 文献カタログならば表題
  - 人物情報ならば敬称
- プロパティもURIで識別（名前付け）する
  - URIは抽象的な概念や関係を名前付けることもできる
  - http://purl.org/dc/elements/1.1/title
  - http://xmlns.com/foaf/0.1/title
RDFのサブプロパティ定義
- あるプロパティは、共通語彙のサブプロパティとして定義できる
  - ex:著者 rdfs:subPropertyOf dc:creator. eg:作者 rdfs:subPropertyOf dc:creator.
- サブプロパティ関係を利用した推論ができる
  - サブプロパティ定義があれば、X ex:著者 Y. からX dc:creator Y. を導くことができる
  - 異なるプロパティを用いたグラフを、dc:creatorを使って横断検索できる

8 データ交換のハブとしてのRDF

異なる語彙をRDFを介して効率的にマッピングする
- アプリケーションごとにプロパティ（属性名）が異なるケースが多い
- 語彙統一は非現実的、サービスごとにマッピングを行うのは非効率（N×N問題）
- 異なる語彙をRDFの共通語彙にマッピングすることで、N×1に
最大公約数としての共通語彙
- RDFをハブとするには、共通のプロパティがあると好都合
- 最大公約数の語彙を介せば、最小限の情報は交換（共有）できる
- さまざまなコミュニティで未知の語彙が使われるウェブでは、完全な交換よりもまず共有できることが重要
  - RDFを介したデータ連携に関しては、RDFとメタデータの相互運用も参照

9 データのモデルと連携

データの連携には、語彙だけでなくモデルも含めた交換が必要
- MARC21、MODS、新旧Dublin Coreはそれぞれ語彙だけでなくデータを表現するモデルも異なる
- 単純なモデルでは、複雑なモデルの情報を全て反映できないことがある
  - たとえば、シリーズの書誌を単著のモデルで表すと、グラフ併合時に無理が生じる
モデル交換には規則・推論が必要になる
- MARC XMLサイトで提供されるスタイルシートを用いて、MRAC XML → MODSやMRAC XML → Simple DCの変換が可能
- 双方向の変換は難しいこともある（情報が欠落する）
- モデルが近ければ、語彙が違ってもそのままマージして利用することも可能

10 MARCからMARC XMLへ

MARC21タグ

008 .. 050107s2005    ja a     |||| 001 ||jpn d
100 1. $a神崎, 正英
245 10 $aセマンティック・ウェブのためのRDF/OWL入門 $c神崎正英著
260 .. $a東京 :$b森北出版,$c2005.1

※KOSMOSの『セマンティック・ウェブのためのRDF/OWL入門』データの一部

MARC XML

タグ（フィールド）をcontrolfieldもしくはdatafield要素とし、$で区切られたサブフィールドをsubfield要素とする単純マッピング

<controlfield tag="008">050107s2005    ja a     |||| 001 ||jpn d</controlfield>
<datafield tag="100" ind1="1" ind2=" ">
  <subfield code="a">神崎, 正英</subfield>
</datafield>
<datafield tag="245" ind1="1" ind2="0">
  <subfield code="a">セマンティック・ウェブのためのRDF/OWL入門 </subfield>
  <subfield code="c">神崎正英著</subfield>
</datafield>
<datafield tag="260" ind1=" " ind2=" ">
  <subfield code="a">東京 :</subfield>
  <subfield code="b">森北出版,</subfield>
  <subfield code="c">2005.1</subfield>
</datafield>

MARCデータ全体をXMLにしたサンプル

11 MARC XMLからMODSへ

OCLC提供のXSLTを利用した変換

<titleInfo>
  <title>セマンティック・ウェブのためのRDF/OWL入門</title>
</titleInfo>
<name type="personal">
  <namePart>神崎, 正英</namePart>
  <role>
    <roleTerm authority="marcrelator" type="text">creator</roleTerm>
  </role>
</name>
<originInfo>
  <place>
    <placeTerm type="code" authority="marccountry">ja</placeTerm>
  </place>
  <place>
    <placeTerm type="text">東京</placeTerm>
  </place>
  <publisher>森北出版</publisher>
  <dateIssued>2005.1</dateIssued>
  <dateIssued encoding="marc">2005</dateIssued>
</originInfo>
<language>
  <languageTerm authority="iso639-2b" type="code">jpn</languageTerm>
</language>
<note type="statement of responsibility">神崎正英著</note>
<recordInfo>
  <recordCreationDate encoding="marc">050107</recordCreationDate>
</recordInfo>

MARCデータ全体をMODSに変換したサンプル

元のMARCフィールドが統合・分解されて構造化される＝モデルが変換される
- たとえばoriginInfoは260フィールドと008フィールドの国コードから、また008フィールドのほかの情報はlanguageやrecordInfoなどに
RDFではない＝MODSの構文（スキーマ）を理解していないと処理できない

12 MARC XMLからDublin Coreへ

OCLC提供のXLSTによる変換

<dc:title>セマンティック・ウェブのためのRDF/OWL入門 /</dc:title>
<dc:creator>神崎, 正英</dc:creator>
<dc:publisher>東京 : 森北出版,</dc:publisher>
<dc:date>2005.1</dc:date>
<dc:language>jpn</dc:language>

もっとも単純なモデル（Simple Dublin Core）への変換

DCの新しいモデルに従った変換

<dc:title>セマンティック・ウェブのためのRDF/OWL入門</dc:title>
<dc:creator>
 <dct:Agent>
  <rdfs:label>神崎, 正英</rdfs:label>
 </dct:Agent>
</dc:creator>
<dc:publisher>
 <dct:Agent>
  <rdfs:label>森北出版</rdfs:label>
  <ex:location>東京</ex:location>
  <ex:country rdf:resource="http://www.loc.gov/mods/v3/marccountry#ja"/>
 </dct:Agent>
</dc:publisher>
<dc:date>2005-01</dc:date>
<dc:language rdf:resource="http://www.loc.gov/mods/v3/iso639-2b#jpn"/>

#11のMODSを新DCモデルに変換したサンプル

DCの新モデルの表現力はMODSにひけを取らない
- Dublin Coreの表現力が貧弱なのではなく、古くから使われている「Simple Dublin Core」が、もっともシンプルなモデルを採用しているだけ
- 場所などのDCで提供されないプロパティは、別の語彙と組み合わせて表現できる

13 MODSをRDF化する

DCのモデルに近くなるようRDFへの変換規則を考える
- トリプルが成り立たない部分はrdf:parseType="Resource"を加えてノードを補う
- authority、type属性を利用して目的語をURI化する
- role属性のようにモデルが大きく異なる部分は、特殊規則で変換する

変換例

<m:titleInfo rdf:parseType="Resource">
  <m:title>セマンティック・ウェブのためのRDF/OWL入門</m:title>
</m:titleInfo>
<m:creator>
  <m:Personal>
    <m:namePart>神崎, 正英</m:namePart>
  </m:Personal>
</m:creator>
<m:originInfo rdf:parseType="Resource">
  <m:place rdf:resource="&mods;marccountry#ja"/>
  <m:place>東京</m:place>
  <m:publisher>森北出版</m:publisher>
  <m:dateIssued>2005.1</m:dateIssued>
  <m:dateIssued rdf:resource="&mods;marc#2005"/>
</m:originInfo>
<m:language rdf:resource="&mods;iso639-2b#jpn"/>
<m:statement_of_responsibility>神崎正英著</m:statement_of_responsibility>
<m:recordInfo rdf:parseType="Resource">
  <m:recordCreationDate rdf:resource="&mods;marc#050107"/>
</m:recordInfo>

MARCデータ全体をMODS/RDFに変換したサンプル
変換には実験的なXSLTを利用

- ※図では比較のためにMODS/RDFの一部の要素を省略

14 RDF化のメリット

未知の語彙であってもとりあえずトリプルとして処理できる
- 語彙が分からなくても、グラフ（データ）をトリプルに分解し、データベースに収録できる
- 語彙の定義（subPropertyOfなど）を与えれば、あとから推論を行うこともできる
モデルさえ同じなら、語彙が未知でも検索できる
- RDFのクエリSPARQLはグラフのパターンを探し出す
- プロパティを変数にした検索ができる＝異なる語彙であっても横断検索ができる
- ```
SELECT ?book ?name
WHERE {
  ?book ?creatorProperty ?person .
  ?person ?nameProperty ?name .
  FILTER (regex(?name, "神崎") && regex(?name, "正英")) .
}
```

15 異なるモデルの問題

モデルが異なると、グラフパターンが当てはまらない
- #14のSPARQLクエリは、旧ダブリン･コア（Simple Dublin Core）には適用できない
  - 旧DCモデルではdc:creatorの目的語がリテラル（名前）
- ダブリン・コアとMODS/RDFでは、タイトルのモデルが異なる
異なるパターンのUNIONで検索することは可能
- ```
SELECT ?book ?title
WHERE {
  {?book ?titleProperty ?title . }
  UNION {?book ?titleProperty [ ?titleLabel ?title ] .}
  FILTER regex(?title, "RDF/OWL入門")
}
```
  - ただしこの場合は、図のbNode1も1番目のグラフパターンにマッチするので、?bookの答えになってしまう

16 多ノード複合モデルと検索

名前を姓と名に分けるような多ノード複合モデルの場合
- たとえばMODSのnamePart要素を、type属性を用いて姓と名に分ける場合
- RDFで表現すると次のようになる
- ```
<m:Personal>
  <m:family>神崎</m:family>
  <m:given>正英</m:given>
</m:Personal>
```
想定するモデルが異なると単純な検索では見つからない
- ひとつのプロパティ値に姓と名が含まれることを前提とした#14のクエリでは、検索できない

17 ラベルを利用した汎用検索

多ノード複合モデルの場合、ハブノードにもrdfs:labelを与える
モデルはそのままでも、ラベルを介して共通の検索や表示が可能
- 氏名プロパティがリテラル値を持つモデルでも、複合ノードモデルでも、共通して検索できる
- ```
SELECT ?book ?name
WHERE { ?book ?creatorProperty [?nameproperty ?name] . 
        FILTER (regex(?name, "神崎") && regex(?name, "正英")) .}
```
  - #14のクエリと同じもの（記述法のバリエーション）
  - UNIONでグラフパターンを加えれば、旧ダブリン・コアのモデルも検索できる

18 ラベルの効用

ラベルはデータを人間が確認するために重要
- RDFデータも最終的には人間が利用するもの
- RDFブラウザ（例えばTabulator）などでデータを見るとき、ラベルがないと分かりにくい
- - ※図は#13のMODS/RDFをTabulatorで表示した画面
- ラベル（rdfs:labelもしくはそのサブプロパティ）があれば、ノードを展開しなくてもどんなデータかが分かる
- - ※図はrdfs:labelを加えたMODS/RDFをTabulatorで表示した画面

19 リンクするデータ

データのウェブもリンクによって広がりが生まれる
- 文書のウェブ（HTMLのウェブ）では、リンクがあって当然
- 現在の多くの書誌（RDF）データは、著者や主題が文字列で取得できても、その先につながらない
- データにURIを与えてリンク可能にする
リンクするデータ4原則
- ものごとをURIで名前付けする
- これらの名前を調べる（参照する）ことができるように、http:スキームのURIを使う
- 名前付けしたURIが参照されたら、有用な情報を返す
- ほかのURIへのリンクを加えて、より多くのものごとを見出せるようにする
- （Linked Data - Design Issues）

20 リンクできない主題件名

文字列としての主題件名
- リテラル（文字列）の主題件名は、検索はできるがリンクできない
- ```
<dc:subject>データ通信</dc:subject>
```
URIによる主題件名表現
- 主題件名をURIで表現すれば、グラフのマージはできる
- ```
<dc:subject rdf:resource="http://www.loc.gov/mods/v3/BSH#データ通信"/>
```
- しかし、そのURIを参照しても情報が得られないと、リンクはつながらない
  - URIが識別するものはネットワーク上のリソースに限らないことに注意

21 主題件名とリンクするデータ

主題から上位主題、関連主題などへのリンク
- シソーラスのBT,RTなどを利用し、関連する主題URIへとグラフをつなぐ
- 主題URIを参照すると、そのリンクの情報も返すようにする
  - ただし、主題のURIと、主題に関する情報（情報リソース＝主題指示子）のURIは区別するのが現在のウェブ・アーキテクチャ
  - ```
  <SubjectIndicator 
    rdf:about="http://www.kanzaki.com/ns/psi/ja/データ通信">
   <foaf:primaryTopic>
    <Subject 
      rdf:about="http://www.kanzaki.com/ns/psi/ja/データ通信#s"/>
   </foaf:primaryTopic>
  </SubjectIndicator>
```
- HTMLのブラウザがリンクを辿るように、RDFブラウザもリンクするデータを辿っていく

22 ユーザによる情報

分散型で扱いやすいユーザ情報モデル
- タグ：ユーザによる自由なキーワード
- レビュー：ユーザによる紹介、評価
  - cf:評判のオントロジーとFOAF
- 新しい付加価値もしくはリンクの可能性

主題件名の専門性 vs. タグの集合知

	主題件名	ユーザによるタグ
適切性	専門知識を反映	多数の「集合知」を反映
一貫性	語彙が統制されており、比較的長期にわたって安定（改訂の問題はある）	多義語、同義語の問題が不可避で、タグを付けた時期によって意味が異なる場合がある
網羅性	広い領域を満遍なくカバーするが、新しい動きに即応できない	領域によってばらつきがあるが、最新動向を反映
関連づけ	シソーラスの階層による関連件名	統計的な近さの計算による類似提示
コスト	高い	低い

両者は対照的な特徴を持つので、どちらが優れているかというよりも、相補的な関係

23 タグとリンクするデータ

文字列としてのキーワードとリンク
- タグは統制されないキーワード文字列
  - 多くのサービスでタグにはリンクが与えられるが、それはタグ（主題）を表すものではなく、タグを与えられたリソースへのリンク集
- まず文字列に対応するURI（キーワードリソース）を考える
- キーワードリソースは、複数の意味（主題リソース）を持つことがある
- - ここでwm:はキーワードと主題を結びつけるための実験語彙
コンテクストを加えたタグのモデル
- 複数のタグがセットになってコンテクストを表す
- タグセットを文書に与えた日時と付与者
- - タグとオントロジーのモデルの改良案

24 リンク可能なキーワードとWikipedia

Wikipediaを介したリンクするデータの可能性
- 主題（キーワード）のWikipediaページにfoaf:isPrimaryTopicOfとしてリンク
- カテゴリ、言語リンクなどを利用した関連主題へのリンク
- 曖昧さ回避ページを利用した多義語の解決案提供
- リダイレクトを利用した同義語の解決
- $図17:{Book}--keyword-->{keyword:opera}--sense-->{psi:Opera_music}--isPrimaryTopicOf-->{wpedia:Opera}.$
- Wikipediaを利用したリンク可能なキーワード（例：opera）のテスト中

25 まとめ

RDFをデータ連携のハブとして利用する
- URIを用いて名前をグローバル化する
- サブプロパティ関係を利用して語彙の効率的なマッピングを行う
共有可能なモデルを用いる
- モデルを複雑にし過ぎず、DCMI抽象モデルなど標準モデルに近づける
- 独自モデルが必要な場合は、語彙とモデルを交換用モデルに変換する手段を提供する
ラベルを与える
- 各エンティティにラベルを与えて人間に理解しやすくする
- 複合ノードのハブには、各ノードの文字列を連結したラベルを与える
リンクするデータに
- プロパティ値にもURIを与え、さらにそこから情報を取得できるようにする
- 利用者参加型データなど、データの広がりを加える

26 参照先

参照したリソース
1. Resource Description Framework
  <http://www.w3.org/RDF/> (☞#2)
2. Uniform Resource Identifier (URI): Generic Syntax, by T. Berners-Lee, R. Fielding and L. Masinter, 2005-01, RFC 3986
  <http://www.ietf.org/rfc/rfc3986.txt> (☞#4)
3. RDFとメタデータの相互運用, 2007-03-09
  <http://www.kanzaki.com/works/2007/pub/0309dlw.html> (☞#8)
4. MARC21
  <http://www.loc.gov/marc/> (☞#9)
5. Metadata Object Description Schema
  <http://www.loc.gov/standards/mods/> (☞#9)
6. Dublin Core Metadata Initiative
  <http://www.dublincore.org/> (☞#9)
7. MARC XML
  <http://www.loc.gov/standards/marcxml/> (☞#9)
8. DCMI Abstract Model, by Andy Powell, et al., 2007-06-04, DCMI Recommendation
  <http://www.dublincore.org/documents/abstract-model/> (☞#12)
9. MODS/XML to RDF conversion stylesheet, 2007-11-21
  <http://www.kanzaki.com/works/2007/pub/mods2rdf.xsl> (☞#13)
10. SPARQL Query Language for RDF
  <http://www.w3.org/TR/rdf-sparql-query/> (☞#14)
11. Tabulator: Generic data browser
  <http://www.w3.org/2005/ajar/tab> (☞#18)
12. Linked Data - Design Issues, Tim Berners-Lee
  <http://www.w3.org/DesignIssues/LinkedData.html> (☞#19)
13. 評判のオントロジーとFOAF, 2007-01-25
  <http://www.kanzaki.com/works/2007/pub/0125intap.html> (☞#22)
14. Word to Subject Mapping Vocabulary, 2007-07-04
  <http://purl.org/net/ns/wordmap> (☞#23)
15. タグとオントロジー, 2007-01-17
  <http://www.kanzaki.com/works/2007/pub/0117ritsumei.html> (☞#23)
16. リンク可能なキーワード（例：opera）
  <http://www.kanzaki.com/ns/keyword/opera#word> (☞#24)