目録の4つの機能

• 利用者タスクの分析
  • たとえばFRBR 2.2 Scopeでのカタログ利用者の目的分析
  • その分野にどんな情報／資料があるのか、特定の資料／対象についての情報があるか、ある資料はどんな形態で／条件で利用可能なのか、など
  • → Find, Identify, Select, Obtainの4タスク（機能）
• 4つのタスクと機能
  • Find：発見＝タイトル、キーワードなどによる検索（標目、アクセスポイント）
  • Identify：識別＝示されている対象が何なのか、求めている（既知の）資料かどうか判断できる情報
  • Select：選択＝（検索結果などの）選択肢のうち、対象が求めている（未知の）資料かどうかを判断できる情報。識別より広い意味での記述
  • Obtain：入手＝示されている（選択した）対象を取得する手段（の情報）の提供

メタデータ、そしてウェブ

• 分野による機能の比較

  • 機能	書誌（図書館）	ウェブ検索	メタデータ（ウェブ）
    発見	アクセスポイント	主として全文検索	メタデータ検索？
    識別	責任表示、ID、記述	タイトル、URL	（メタ）データの識別子？
    選択	言語、形態、注記なども含む記述全体	スニペット、サムネイル	（メタ）データモデルの記述力？
    入手	請求記号	URL	メタデータもデータ？

• ウェブを視野に入れた（メタ）データの共有
  • 組織や領域を超えて共有・再利用できるメタデータ
  • 異なるコンテクストや予備知識での4つの機能とは
  • 以下、（順序を変えて）識別→記述→発見→取得の流れで考察

Identify：識別と実体

識別のための情報

• その資料が何なのか、他と区別し、判別する情報
  • 固有の名前（識別子）
    • タイトル（標題＋責任表示の連結フィールド）
    • Bib System No.
  • 記述項目の組合せで対象を描く（プロパティ空間）

グローバルなスコープを持つ識別子

• 名前のスコープ（通用範囲）
  • 通用範囲が限定された名前：000746395（この図書館内）、柳瀬さん（目の前の範囲？）
  • コンテクストでスコープを示す：BibSystemNo:000746395
  • 修飾情報でスコープを広げる：柳瀬, 尚紀(1943-)
  • ウェブ上のリソースを識別するにはグローバルなスコープが必要
• URIもしくはIRI
  • ウェブ上のグローバル識別子としてURIを用いることができる
  • 識別子を名前として用いるためには英数字だけでなくUnicode全般の文字を使いたい→国際化識別子IRI
    • ※以下では慣用的な用語としてURIを用いるが、意味としてはすべてIRI

  • http://lib.keio.ac.jp/bibSystemNo/000746395
    http://ja.dbpedia.org/resource/柳瀬尚紀

  • Resouce Identifierなので、ネットワーク上のものだけでなく、抽象的実体や関係の識別にも使える

名前と実体

• 書誌データでの固有名（識別子）と実体
  • 識別のためには、そもそも何を実体と捉えるかの確認が必要

  • 項目名	値	対象となる実体
    BIB System No.	000746395	書籍（？）
    ISBN	4309202829	書籍
    著者	Joyce, James, 1882-1941	人
    出版事項	東京	場所
    出版事項	河出書房新社	出版者
    分類	933.7	分類概念

同じものはどれ？

• 異なる実体と識別のレベル
  • ISBNとBIB System No
  • 請求記号とBookID
  • それぞれ指すものは何か

作品の実体レベルと識別

• FRBRグループ1の実体レベル

  • 実体レベル	対応する実体	識別子
    作品	Ulysses	（VIAF、NDLA）
    表現形	柳瀬尚紀訳	？
    体現形	河出書房新社版	ISBN（BIB System No）
    アイテム	日吉3F西閲覧室所蔵	BookID、請求記号

• FRBRグループ1実体の応用
  • 概念モデルなので、必ずしも現実のデータにそのまま適用できるとは限らない
    • BIB System Noに対応するシリーズとしての実体は、同じレベル（体現形）内での階層
    • 版次は体現形の属性だけれども、厳密には表現形をも区別する
  • 領域による違いやFRBRを念頭に置いた分野ごとのモデル
    • 3レベルで構成するBIBFRAME（後述）
    • 映画記述モデルでは、作品とオリジナル表現形を合わせてWorkと位置づけ、別言語版などはVariantとするなど
    • 作成イベントなど、FRBRにはない実体を用いるモデルも
  • 専門外からの視点を考える必要も
    • 読んだのは「表現形」？「体現形」？　感想を述べる対象は「作品」？
    • 一般的な利用には区分を厳密にしない方が分かりやすいことも

記述項目の組合せによる識別

• プロパティ空間へのプロット
  • 情報代数のプロパティ空間：いくつかのプロパティq1, q2,...を軸とする空間
  • ある実体eは、プロパティの値v1, v2,...の組合せによってプロパティ空間にプロットされる
  • 適切なプロパティと値の組み合わせを用いることで、ある実体を他の実体と区別できる
    • プロパティの組によっては、異なる実体が空間の同一点にプロットされる可能性がある
  • 

Select：記述形式と語彙

表形式による記述

• シンプルな属性―値対
  • 簡単に扱え、分かりやすく表示できる
• 構造的データ
  • 階層的、構造的データの記述は複数表の組合せが必要。入れ子構造の表現はトリッキーになる
• 未知の項目
  • スキーマ（項目構造）が決まらないデータは扱いにくい
  • 未知のデータを扱うためには項目定義の追加が必要

グラフによる記述

• トリプルを用いた表現
  • 属性―値対に対象（主語）を加えた3つ組（トリプル）で情報を表現
  • 2つのノードをアーク（関係）で結ぶシンプルな構造
  • 
• 柔軟な表現力とシンプルな処理
  • ノードを連結して複雑なモデルを表現できる
  • 
  • 複雑な情報も単純なトリプルに分解して処理できる
  • あらかじめ項目や構造を決める必要がなく柔軟

URIを用いたグラフ

• ノードの名前にURIを用いる
  • 
• 同じURIのノードは連結できる
  • 一つの組織や領域を超えてグラフを連結できる
  • 
    • bib:000746395などはURIの最終部分以外を接頭辞に簡略化した形。以下同様に簡略記法で記述
  • ところで「出版地」「開催地」は？
• アークにもURI
  • 属性・関係（アーク）をプロパティと呼び、どこでも意味が明確になるようにURIで名前付けする
    • トリプルの3要素をURIで表現する。またの名をRDF
  • （メタ）データ作者が思い思いにプロパティURIを決めていては共有しにくい
  • 共通利用可能なプロパティ・セット＝共有語彙を

資料判断のための情報

• 人間に理解可能なラベル
  • URIは基本的にはコンピュータ処理のための名前
  • 人が読んで分かるラベル（タイトル）
  • BibSystemNo:000746395のタイトルはユリシーズだ
• グループ化（クラス）
  • 固有名を普通名（基本的な性質を表すグループ）に対応付ける
  • BookID:30100166440はfrbr:アイテムだ。dbpedia:ユリシーズはfrbr:作品だ
    • 注意：関係（たとえば訳者）は原則としてクラスにはしない。柳瀬尚紀を「訳者クラス」としてしまうと、別の本の「著者」でもあるときに矛盾が生じる
  • 単一分野ではなく、異なる種類の情報が組み合わされる場合、クラスによる判断の重要性が高まる
• プロパティの組合せ
  • 対象の識別だけでなく、特徴を知るための記述
  • 言語、形態、ライセンスなど目的に照らした判断が可能な情報

語彙の選択とメタデータ公開の目的

• 専門領域でのデータ共有
  • 詳細なデータを正確に提供するには専門的語彙が必要
  • MODS RDFはMARC XML→MODS XML→MODS RDFの変換が可能
  • BIBFRAMEはバージョン2.0となり、FRBRに近い形で記述が可能
  • 一方で領域外からは簡単には理解できず、モデル（構造）も複雑
• 領域を超えた広い範囲でのデータ共有・再利用
  • 普及した汎用語彙とシンプルなモデルの方が、一般的には広く利用されやすい
  • 汎用語彙は、Dublin CoreとFOAFなど、複数の組合せが必要になる場合が多い
  • 既存の汎用語彙で記述できない情報は、無理せずそのまま
    • 汎用記述が難しい専門情報は、無理にマッピングせず専門語彙や独自定義語彙で
    • 検索のために期待される情報（後述）は汎用語彙が望ましいが、それ以外は必要なら調べるという形の利用でOK
• ワンストップ語彙
  • schema.org：600超のクラスで広い分野をカバーし、複数語彙を組合せる煩わしさを解消
  • 2015年の調査報告では、収集した100億ウェブページの3割以上がSchema.orgを利用
  • 図書館関連の記述のためにSchema.orgのBib拡張も

専門語彙：MODS RDFによる記述

• 
  • KOSMOSの書誌MARCデータをMODS RDFに変換（型付ノードグラフで表現）
  • 作者がmodsrdf:name、出版地がmodsrdf:placeOfOriginなど、一般には想像しにくいプロパティ名
  • 多くのプロパティが値を複数持つことができ、順序付きリストで表現するので複雑

専門語彙：BIBFRAMEによる記述

• 
  • 米議会図書館の書誌MARCデータをBIBFRAMEに変換したものの簡略版
  • HeldItem→Instance→Workの3階層で実体を表現
  • バージョン1.0のモデルに比べて空白ノードが減少、注釈が異なるモデルで用いられている

汎用語彙：DCとFOAFによる記述

• 
  • KOSMOSの書誌データをDublin CoreとFOAFで表現
  • シンプルに表現できるが、注記、出版地のように直接表現できないものを割愛（語彙を追加すれば記述可能）
  • 翻訳元のように代替プロパティ（dct:source）でカバーできるものもあるが、やや精度を欠く

ワンストップ語彙：Schema.orgによる記述

• 
  • Schema.orgを利用しているWorldCatの書誌データの簡略版
  • workExample / exampleOfWorkで3レベルの実体を関連付け（BIBFRAMEに似ている）
  • 出版事項をPublicationEventとして扱うとともに、出版地、出版者のショートカットも加えて利用しやすくしたモデル

注釈モデルによる記述

• 
  • 説明を加えてウェブ注釈語彙で表現
  • 対象の客観情報と注釈を区別するので、他のグラフと組み合わせたときに混乱がない
    • 件名や分類は資料の注釈とすべき？
    • 注釈作者を区別してユーザタグも含められる（対象はURIで共有）
    • 注釈部分こそが各組織の付加価値
  • 同じターゲット（資料URI）を指すことで、組織を超えた複数の注釈が連携
    • 対象のURI（「ユリシーズ」を指すURI）の共有が重要になる

Find：検索と発見

SPARQLによるグラフの検索

• 知りたい情報をグラフのパターンで表現
  • グラフデータはSPARQLを用いて検索できる
  • 未知の部分を?xxxの形の変数として求めるグラフパターンを表現
  • 
• パターン一致による検索
  • 検索対象となるグラフから、パターンに一致する部分を見出す
  • 

モデルの選択

• 同種の情報もモデルが違うと異なる形に
  • 
  • 「タイトル」を検索するときに、どのようなパターンを使えばよいか分からない
  • グラフを統合したときに、同じパターンで「タイトル」を検索できない

検索とプロパティ

• グラフのアクセスポイント
  • 最も一般的なキーワードによる検索には、リテラル値が必要
  • その対象を端的に表す名称（ラベル）を対象の直接のプロパティとしてリテラル値で与える
  • 
  • BIBFRAMEのインスタンスにはbib:titleStatementがあるが、予備知識が必要。汎用語彙ならdc:title、schema:nameなどラベルのプロパティ、そうでなければrdfs:labelを加える
• 絞り込みを可能にする
  • クラスや主題から、共通の性質や特徴を持つリソースを選ぶ（集中機能）
  • クラスや分類の階層を利用した絞り込み（あるいは拡張）

  • SELECT * WHERE {
    	?book dct:subject [ skos:broader* ndc9:933.7 ].
    }

    • プロパティ・パスを用いたSPARQLクエリにより、分類記号が933.7もしくはその下位分類である書籍を検索できる。

ウェブでの発見

• エンドポイントと検索
  • SPARQLエンドポイント：グラフデータをSPARQLで検索可能にして公開するサービス
  • エンドポイントから別のエンドポイントを呼び出しての検索（統合クエリ）も可能
  • それぞれのエンドポイントが提供するグラフのモデルが分からないと利用しにくい
  • ウェブ上のグラフを収集する検索エンジンも無いわけではないが、網羅的ではない
• リンクとセレンディピティ
  • 文書のウェブでは、検索したページから、ハイパーリンクを辿って行ける
  • リンクによって思わぬ発見（セレンディピティ）が生まれる。書架を眺めるのにも通じる
  • グラフデータも、URIを名前付けに用いているので、リンクを辿って新たなデータを発見できる…はず

Obtain：データとしてのメタデータ

リンクするデータ

• アクセス可能なURI
  • http:スキームURIなら識別子（名前）にアクセスしたときグラフデータを返すことができる
  • 人や書物のURIでも、その説明グラフへの転送などによって、データを提供できる
  • バーナーズ＝リーのLinked Dataの4ルール
  • 

メタデータとアクセス対象

• 対象実体にアクセスするためのメタデータ
  • 書誌の請求記号
  • 美術館目録のデジタル画像へのリンク
  • 画像コレクションや異なるサイズの画像提供サービスを利用するためのIIIFマニフェスト
• メタデータそのものが対象データ
  • 論文の引用分析においては、書誌が対象データ
  • 年表や地図へのマッピングなど、メタデータを材料（＝対象データ）にした表現
  • ある作品をとりあげた論文は、作品を対象とする注釈であると同時にそれ自身が資料
• データとしてもアクセス（利用）可能なメタデータを！

（メタ）データのアクセシビリティ

• アクセス可能なデータ
  • 閉じた組織やサービスの中でしか利用できないデータのサイロではなく、データを広く公開する
  • エンドポイントやAPIなど、プログラムでの利用を可能にする
    • 目録のHTMLページだけでは、プログラム処理は容易ではない
  • リンクするデータ（もしくはダウンロード用データ）の提供
• 自由なライセンス
  • ライセンス（利用条件）が明記されていないと、データを利用できない
  • 可能ならばパブリックドメイン（CC0）や表記（CC-BY）など、自由度の高いライセンスで
  • 一括ライセンスが難しければ、客観データのみCC0などライセスの区別も
• 利用・共有しやすいデータ
  • データの鮮度や来歴が分かる情報＝（メタ）データのメタデータ
  • 異なるコンテクストでも誤解が生じない記述（たとえば注釈モデル）
    • 元の組織内では暗黙の了解があっても、別のグラフと併合すると解釈できなかったり意味が変わってしまう場合がある
  • モデルを無理に単純化せず、汎用性のあるショートカットを追加
    • 単純化したデータを復元することはできない。利用側で必要に応じて処理するのが合理的

    • メタデータマッピングはしばしば破壊的な情報の劣化を引き起こしてきました。……メタデータマッピングはメタデータを整理するアグリゲーター……の責任によって行われるべきであり、各図書館は自らの図書館が扱う合理的なデータを配信するべきです。

      カーリルのブログ

    • ショートカットは、たとえばWorldCat（Schema.org）の出版者、出版地
  • 多くの人が読めるラベル、非専門家でも理解できるモデル説明の提供
    • とりあえず、やはり英語 → 知らない言語のデータを見ると痛感する
    • ハックしなくてもクエリや変換の方針を立てられるように

参照先

• 参照したリソース
  1. Functional Requirements for Bibliographic Records -- Final Report, 1998, International Federation of Library Associations
     <http://archive.ifla.org/VII/s13/frbr/>
  2. An information algebra: phase 1 report - language structure group of the CODASYL development committee, 1962, Commun. ACM, Vol. 5, No. 4. pp. 190-204
     <http://doi.org/10.1145/366920.366935>
  3. MODS RDF Ontology, Library of Congress
     <https://www.loc.gov/standards/mods/modsrdf/>
  4. BIBFRAME - Bibliographic Framework Initiative, Library of Congress
     <http://www.loc.gov/bibframe/>
  5. DCMI Metadata Terms
     <http://dublincore.org/documents/dcmi-terms/>
  6. FOAF Vocabulary Specification
     <http://xmlns.com/foaf/spec/>
  7. schema.org
     <http://schema.org/>
  8. Schema.org: Evolution of Structured Data on the Web, by R.V. Guha, et al, 2015-12-15, ACM Queue, Volume 13, issue 9
     <http://queue.acm.org/detail.cfm?id=2857276>
  9. Web Annotation Vocabulary, 2016-09-06, W3C Candidate Recommendation
     <https://www.w3.org/TR/annotation-vocab/>
  10. SPARQL 1.1 Query Language, 2013-03-21, W3C Recommendation
      <https://www.w3.org/TR/sparql11-query/>
  11. SPARQL 1.1 Federated Query, 2013-03-21, W3C Recommendation
      <https://www.w3.org/TR/sparql11-federated-query/>
  12. Semantic Web Search Engines, SWEO Community Project
      <https://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/SemanticWebSearchEngines>
  13. Linked Data - Design Issues, by Tim Berners-Lee, 2006-07-27
      <http://www.w3.org/DesignIssues/LinkedData.html>
  14. Presentation API 2.1, International Image Interoperability Framework
      <http://iiif.io/api/presentation/2.1/>
  15. Public Domain Dedication, Creative Commons
      <http://creativecommons.org/publicdomain/zero/1.0/>
  16. Attribution 4.0 International, Creative Commons
      <http://creativecommons.org/licenses/by/4.0/>
  17. 横断検索向け高速連携プロトコルUnitrad Fast-Linkを提唱, 2016-11-03, カーリルのブログ
      <http://blog.calil.jp/2016/11/fastlink.html>