すべてをコンピュータの中に（繋がってしまったデータとその未来）

公開シンポジウム

漢字構造情報のRDF化の試み（守岡知彦）
国立国会図書館のメタデータ標準 ̶ データを繋げるメタデータ: DC-NDL ̶（柴田洋子）
PageRank と学術論文の評価: ノーベル賞の窓を探そう（藤田裕二）

全国共同利用・共同研究拠点「人文学諸領域の複合的共同研究国際拠点」
2013.2.16

目次
この冊子の説明... p. 1

シンポジウムについて... p. 2---------------------------------------------

漢字構造情報のRDF化の試み
守岡知彦（京都大学人文科学研究所）... p. 3

国立国会図書館のメタデータ標準̶データを繋げるメタデータ: DC-NDL̶
柴田洋子（国立国会図書館電子情報部）... p. 23

PageRank と学術論文の評価: ノーベル賞の窓を探そう
藤田裕二（(株)ターンストーンリサーチ, 日本大学）... p. 36

この冊子の説明
この冊子は，京都大学人文科学研究所共同研究プロジェクト: 「情報処理技術
は漢字文献からどのような情報を抽出できるか̶̶人文情報学の基礎を築く」主
催の公開シンポジウム「すべてをコンピュータの中に（繋がってしまったデータとその未来）」（2013年2月16日開催）の予稿集である。

1

シンポジウムについて
日時と場所
2013年2月16日（金）, 13:00-17:40
京都大学人文科学研究所本館101セミナー室

録画による記録
人文: USTREAM (http://ustream.tv/channel/zinbun/)

プログラム
第1部
趣旨説明

13:00-13:10
漢字構造情報のRDF化の試み

守岡知彦（京都大学人文科学研究所）
13:10-14:00
国立国会図書館のメタデータ標準̶データを繋げるメタデータ: DC-NDL̶
柴田洋子（国立国会図書館電子情報部）
14:20-15:10
PageRank と学術論文の評価: ノーベル賞の窓を探そう
藤田裕二（(株)ターンストーンリサーチ, 日本大学）
15:30-16:20

第2部
パネルディスカッション

コメントと問題提起: 永崎研宣（人文情報学研究所）
16:40-17:40

2

漢字構造情報の RDF 化の試み
守岡 知彦

はじめに

1

多くの漢字は偏と旁などの部品の組み合わせによって構成されている。こうした漢字の部品の組合せ構造は形の抽象的表現となるだけでなく、字義や音価にも関係しており、字源に基づく文字構造の分析は「解字」と呼ばれ、そうしたデータは重要な辞書記述のひとつでもある。
こうした漢字の部品の組合せ構造に関する情報のことを「漢字構造情報」と呼ぶことにする。漢字構造情報の機械可読な表現手法には、幾つかの表現形式が提案され利用されてきたが、Ideographic Description Sequence (IDS) 形式が ISO/IEC 10646 [2] の一部として標準化されている。
CHISE project では 2001 年度未踏ソフトウェア創造事業の助成を受けて、当時 UCSに収録されていた統合漢字、同拡張 A, B の約７万字の漢字を対象とする IDS 形式に基づく漢字構造情報のデータベース化を行い、「CHISE 漢字構造情報データベース」として公1開した。[14] 2005 年には WWW ベースの検索サービス「CHISE IDS 漢字検索」[8] を公開した。これは 2005 年の IRG 京都会議のデモを通じ、漢字の符号化作業における有用性も広く知られるようになり、現在では新たに UCS 統合漢字を提案する際に提出しなければならない情報のひとつとなっている。
CHISE では「CHISE 漢字構造情報データベース」は CHISE 文字オントロジー [9][4]の一部を構成するものとなっており、漢字構造情報は文字に関する素性の一種として扱われ、全体として文字に関する意味ネットワークになっている。WWW 上でも、「CHISEIDS 漢字検索」の検索結果の左端をクリックすることで、各文字の情報を得ることができるようになっており、リンクを辿っていくことで文字に関する各種情報を得ることができるようになっている。[11]一方、WWW の世界では、メタデータやオントロジーを表現するための形式として RDF[7] が標準化されている。CHISE 文字オントロジーのような文字に関する知識を表現した
情報資源も他の情報資源との連携を鑑みれば RDF 等の WWW 標準に対応することが重要であるといえる。そこで、2012 年にはこうした情報の RDF/XML 形式 [6] での出力機能を実装した。しかしながら、現状では CHISE 文字オントロジーの構造をそのまま RDFで表現したものとなっており、標準的な語彙の利用や独自語彙の定義の点で問題があるといえる。漢字構造情報に関しても、IDS の構文木をほぼそのまま RDF 化したようなものとなっており、RDF に基づく構造化という点で現状のままで良いかどうか検討の余地があるといえる。
1

現在では、拡張漢字 C, D もカバーしている。

3

そこで、本稿では IDS 形式やその拡張表現に基づいた漢字構造情報の RDF 化に関して複数の手法を挙げて検討し、その問題点や解決法について議論したい。

2

IDS とは

漢字構造情報に基づく符号化手法の試みは 1970 年代に遡るが、漢字符号化の主流とはならず、標準的な記法も確立されて来なかった。その後、ISO/IEC 10646-1:2000 [1] においてはじめて漢字構造情報の標準記法である IDS (Ideographic Description Sequence) とそのためのオペレータ群である IDC (Ideographic Description Characters) （図 1）が定義された。

図 1: Ideographic Description Characters

IDS （図 2）は Lisp 言語における S 式と同様な前置記法の一種で、オペレータである
IDC の後に２個ないしは３個の部品をとる。IDC の種類によって後に来る部品の数は決4

まっているので、S 式と異なり、括弧は不要である。例えば、「村」は２個の部品を左右に並べるオペレータ「❌」を使って「❌木寸」と書くことができる。IDS では部品としてIDS をとることも可能であり、入れ子状の記述が可能である。

図 2: IDS の例（CHISE 漢字構造情報データベース）

3

S 式による表現

IDS は漢字構造情報を文字列として扱ったり、文字列としてパターンマッチングしたりするのには便利であるが、部品として IDS が現れる場合の処理はそのままでは少し面倒である。よって、より込み入った処理を考えれば、IDS を構文解析した結果の構文木として扱う方が便利であるといえる。そこで、CHISE 文字オントロジーの内部表現としてはLisp 言語における S 式を用いている。
IDS は Lisp 言語における S 式と同様な前置記法なので、その構文解析は極めて容易であり、オペレータの前とオペレータがとる最後の部品の後に括弧を付ければ S 式となる。

5

CHISE 文字オントロジーでは Chaon モデルに基づき文字素性の集合として文字を表現しているが、漢字構造情報はこの文字素性の１つと看做せ、ideographic-structure という素性名が使われている。
例えば、「峠」の ideographic-structure 素性は(ideographic-structure((name . "IDEOGRAPHIC DESCRIPTION CHARACTER LEFT TO RIGHT")(=ucs. #x2FF0))((=ucs . #x5C71) ; 山)((ideographic-structure((name . "IDEOGRAPHIC DESCRIPTION CHARACTER ABOVE TO BELOW")(=ucs. #x2FF1))((=ucs . #x4E0A) ; 上)((=ucs . #x4E0B) ; 下))(=ucs. #x209D7)))のように表すことができる。ここで、((素性名 . 値) ...)
は Chaon モデル的に文字を素性の集合で表現した「文字指定 (char-spec)」と呼ばれる形式で、１文字を表す。文字と文字指定は同一視できるようになっているので、漢字構造における部品として現れる文字も ideographic-structure 素性を持つことで再帰的な表現が可能となる。
CHISE 文字オントロジーでは「文字参照 (char-ref)」と呼ばれる形式がある。これは(:属性名 値 ... :char 文字オブジェクト)という形の Lisp でいう所の属性リスト (property list) の一種で、:char 属性で指定した文字に他の属性で指定したメタデータを付加することができる。ideographic-structure 素
性では文字オブジェクトの代わりにこの形式のデータを置くことができ、これによって部
品やオペレータに出典情報や位置情報などの付加データを付随させることが可能である。
但し、文字参照形式で記述した付加データは IDS（や拡張 IDS）では表現することはできないという問題があるので注意が必要である。2

4

RDF による表現

4.1

文字列を用いた表現

一番安直な方法は IDS の文字列をそのまま用いて、
2

付加データを落した IDS にすることは可能である。

6

<rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=峠"><ids>❌山❍上下</ids></rdf:Description>のように書いてしまうことである。ただ、この場合、部品や部品間のつながりが構造化されておらず問題である。

4.2

コンテナを用いた表現

RDF には複数のものをひとまとめにして扱うための仕組みとして『コンテナ』というものがある。このコンテナを使うことで、3 節で述べた S 式における表現と同様な（IDSの構文木に相当する）木構造のグラフを表現することができる。
RDF が定義しているコンテナ用の語彙には
rdf:Bag メンバーの順序は重要でないグループ
rdf:Seq メンバーの順序が重要なグループ
rdf:Alt メンバーがある指示対象の代替表現（別名や別表記等）になってる場合
rdf:li グループの要素がある。漢字構造情報の場合、部品の順番に意味があるので、rdf:Seq を使うのが良いといえる。例えば、「峠」の場合、<rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E5%B3%A0"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"><rdf:Seq><rdf:li><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E2%BF%B0"></rdf:Description></rdf:li><rdf:li><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E5%B1%B1"></rdf:Description></rdf:li><rdf:li><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%F0%A0%A7%97"></rdf:Description></rdf:li></rdf:Seq></est:ideographic-structure></rdf:Description>7

のように書くことができる。3

4.3

コレクションを用いた表現

4.2 節で述べた RDF コンテナの問題点は、記述したもの以外のメンバーが存在しないことを明示できないことである。これは記述困難な部品を持った文字の漢字構造を記述す
る時に、不完全な漢字構造情報が表現できるという意味では便利かも知れないが、完全な漢字構造情報を表現するのには問題である。
RDF には複数のメンバーからなるグループを表現するための仕組みとして『コレクション』というものもある。RDF コレクションは、RDF コンテナと異なり、閉じたリストを表現するもので、メンバーとして明示されたものだけからなるグループを表現することができる。
RDF コレクションは、rdf:first と rdf:rest という２つの語彙と定義済み資源
rdf:nil を使って表現するようになっている。これは S 式におけるリストの表現と同じものであり、rdf:first は Lisp における car 部、rdf:rest は Lisp における cdr 部、
rdf:nil は Lisp における nil と同じものである。
これを使って、例えば、「峠」の漢字構造情報は<rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E5%B3%A0"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"
rdf:nodeID="cons1" /></rdf:Description><rdf:Description rdf:nodeID="cons1"><rdf:firstrdf:resource="http://www.chise.org/est/rdf.cgi?character=%E2%BF%B0"/><rdf:rest rdf:nodeID="cons2"/></rdf:Description><rdf:Description rdf:nodeID="cons2"><rdf:firstrdf:resource="http://www.chise.org/est/rdf.cgi?character=%E5%B1%B1"/><rdf:rest rdf:nodeID="cons3"/></rdf:Description><rdf:Description rdf:nodeID="cons3"><rdf:firstrdf:resource="http://www.chise.org/est/rdf.cgi?character=%F0%A0%A7%97"/><rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/></rdf:Description>のように表現することができる。
ただ、こうした表現方法だと、長いリストを書くのが面倒なので、S 式の場合と同様な短縮記法が用意されている。例えば、上記の例の場合、2013 年 1 月 26 日現在、EST[12] (CHISE-wiki) による CHISE 文字オントロジーの RDF/XML 形式での出力に用いているのはこの形式である。
38

<rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E5%B3%A0"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"
rdf:parseType="Collection"><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E2%BF%B0"/><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%E5%B1%B1"/><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=%F0%A0%A7%97"/></est:ideographic-structure></rdf:Description>という風に表現できる。

4.4

IDC の述語化

4.3 節で述べたように RDF コレクションを使うことで、S 式の場合と同様な情報を記述することができる訳だが、この方法の場合 IDS の構文木に相当するものを表現することはできているものの、それが意味しているもの、即ち、オペレーターの意味や部品の位置関係といったものは RDF のグラフとしては表現されていないといえる。
この問題を解決するには、例えば、「峠」の場合、『「木」は「峠」の左側である』というような文を RDF で表現すれば良いといえる。つまり、IDS では部品の組合せ方に関する情報はオペレーターである IDC が担っており、4.3 節の方法ではそれを資源として表現していたが、『〜の左側である』のような相対的な位置関係を示す述語を用いる訳である。
安岡孝一氏4 は IDS の RDF 化を検討した際にこうしたアプローチを採った。以下、安岡氏のメモ「IDS は RDF で書けるのか」から引用する：
ナイーブには、RDF の主語と目的語をいずれも「漢字」とし、述語を IDCとすれば、書ける気がする。しかし、そのような形式にした場合、IDC は目的語を複数とるのに対し、RDF の目的語は 1 つ (複数書くことも可能だが、それは単なる並置であって順序関係がない) なので、そのまま直感的に記述することができない。5
この問題を解決するには、たとえば U+2FF0をとに分けて、それ木彡」とぞれを述語とすることが考えられる。すなわち「杉」に対する「いう IDS であれば
杉
杉

木.
彡.

と RDF 表現すればいいわけだ。
京都大学人文科学研究所附属東アジア人文情報学研究センター准教授。漢字コード屋さんにしてタイプ
ライター史家5[守岡注] 4.2 節や 4.3 節で述べたように、順序関係を持った複数の要素からなるグループを目的語として記述することは可能である。
49これで漢字構造情報を『直観的』に RDF で記述できるような気がする。しかし、漢字の部品には複数の漢字を部品として組み合わせたものもあり、漢字構造情報には再帰的な構造が存在している。このため、ナイーブにこの方式を適用すると、ループ構造が生じてしまうのである。また、IDC には『横に部品を３つ並べる』ことを意味するものや『縦に部品を３つ並べる』ことを意味する引数が３つのオペレーターが存在するが、安岡氏は『〜の中である』ことを意味する述語を用いる代わりに、２引数のオペレーターを使った
形に正規化するアプローチを採った。以下、再び安岡氏のメモ「IDS は RDF で書けるのか」から引用する：
ただし、このやり方では「彬」をとで表現する場合に、ひと工夫必要となる。一意性を保っておかないと、ヤヤコシイことになりかねないからだ。
そのために、たとえば「左から切っていく」というアプローチを、ここでは仮に採用しておくことにしよう。すなわち
木.
杉.

彬
彬

という RDF 表現だけを許す、というやり方だ。少し厳密な言い方をすれば、の目的語は、さらに述語を取り得るようなものであってはならな
述語
い、という制限をかけることになる。
ちなみに U+2FF2で書かれた IDS に対との組合せで RDF を書く
しても、ことにすれば、大丈夫な気がする。たとえば#$木木彡」という IDS は、「彬」に対する「木"!"#$匿名ノードを使って
!!
彬
彬

木.
[
木 ], [

彬彡].

と RDF 表現すれば、たぶん問題ないと思う。

!

%## #$ #$
!"
#
$
& 彡
!" !"

こうして、木構造であるはずの IDS がループ構造を持つグラフに化けてしまった訳である。こうなってしまうと検索も面倒なことになってしまう。以下、また安岡氏のメモ「IDS
は RDF で書けるのか」を引用する：6
ただ、このやり方を採った場合、たとえば「杉」を部品に含む漢字の検索は、多少ヒネリが必要となる。「杉」に到達可能な有向 IDS-RDF グラフが答となるのは当然だが、それに加えて
#$

木

"!"
!
#$
!!
## #$
!"
$
#

x

彡

6

!"

#$

木

"!"
!
#$
!!

y

## #$ #$
!"
$
#
& 彡
!" !"

最初の引用からこの引用を合わせたものがメモの全文である（守岡が付けた注は除く）。

10

を満たす x や y (いずれも匿名ノードの可能性がある) に到達可能な有向 IDSRDF グラフも答となりうるのだ。この点に注意して処理系を組む必要があるだろう。
直観的に表現しようとしたはずなのに、なんでこんなややこしいことになってしまった
のだろう？

4.5

『文字概念』と『文字の出現』

4.4 節で述べた安岡氏の方法がおかしな結果になってしまったのは、結論からいえば、
抽象概念としての文字と相対的な位置情報を持った（いわば、『文字概念』のインスタン
スとしての）文字を区別せずに、『文字概念』に直接リンクを張ってしまったことに起因するといえる。もう一度、3 節の S 式による表現と、4.2 節と 4.3 節の RDF による表
現を注意深く見直してみれば、文字と部品が直接リンクしておらず、入れ子になる場合も
est:ideographic-structure という述語（ideographic-structure 素性）やコンテナ等を介して間接的につながっていることに気づくかも知れない。
判り易くするために、4.4 節で安岡氏が挙げた「彬」の例を 4.2 節で述べた RDF コン
テナを用いる方法で記述した場合のグラフを図 3 に示す。
4.4 節の「彬」のグラフと同様にループ構造は生じているが、ideographic-structure
素性の値となる rdf:Seq コンテナがその型情報と共に要素の位置情報を保持しており、それらの位置情報で示されるコンテナ中の場所の中身として文字オブジェクトが参照されている。こうした参照関係をコンテナの中の子箱にオブジェクトが入っているように看做せば、この RDF は本質的に木構造を表現しているという風に解釈することができる（図4）。7もう少し概念的な問題として考えてみれば、例えば、抽象的な概念としての『木』と紙に書かれた文字や印刷された文字（ここにある「木」）はその存在論的な位置が異なっていることに気づくと思う。UCS のコードポイント U+6728 や JIS X 0208 の区点 44-58
が指し示しているのは、かつてこの世に存在し、また、これから紙に書かれたり、印刷されたり、ディスプレイに映し出されたり、その他各種デバイスで表示されたり、将来的には脳内に直接伝達されたりされなかったりするかも知れない、すべての宇宙、過去と未来のすべての『木』という漢字なのである！
こうしたものを文字符号の世界では『抽象文字』と呼ぶ。抽象文字は具体的な文字の形を持たず、ある範囲の字体を包摂する。これに対し、紙に書かれた文字や印刷された文字、あるいは、ディスプレイに映し出されたり、その他各種デバイスで表示された文字は『字形』と呼ばれる。字形は具体的な形を持つ抽象文字のインスタンスの一種といえる。
ただ、IVS (Ideographic Variation Sequence)[3] に関する議論に見られるように、ある程度具体的な形を指示しつつ、紙やディスプレイといった文字を表現するデバイス上での具体的な形を持たないもの、いわば、『字形レベルの文字概念』とでもいうものも文字を考える場合に考えなければならない概念のひとつである。ただ、ややこしいことに、これもまた、しばしば、「字形」と呼ばれたりもする。87
8(a (a b)) のようなリストをループ構造ではなく木構造だと解釈するのと同様である。
グリフと呼ばれることもあるが、こちらもいろんな使われ方をしがちである。

11

%ideographic-structure

&'&'(
#_3

))
#type #_1

ideographic-structure #_2

&'(
#type

!"#$

#_1

&

#_3

#_2

(

'

図 3: RDF コンテナを使って「彬」を書いた場合%
ideographic-structure

&'&'(
#_1

&

#_2

#_3

'

))

#type

ideographic-structure&'(#type #_1

!"#$

&

#_2

'

#_3

(

図 4: 図 3 のグラフが表現する木構造

12

具体物上の『字形』は具体的な形を持つだけでなく、その具体物上の具体的な位置を占めている。これに対し、ある IVS が表現するものは実際に紙やディスプレイといった物
理的なデバイス上に書かれたり、印刷されたり、表示されたりしない限り、具体物上の具体的な位置を持たない。その意味では、抽象文字と同様である。もし、URI のような IDを付与するとすれば、[5] 前者は具体物に振られた ID とその中での相対的な位置、例えば、本の場合、本が存在する場所とページ番号とカラム番号と行番号と行中の何文字かというような情報によって一意に指示することができるだろう。一方、後者はそういう訳にはいかない。物理的な実体ではないからである。もちろん、印刷物の場合、同じ版面から印刷されたものはそれぞれの具体物中の同じ相対位置にほぼ同じ形の文字が書かれているはずである。とはいえ、紙の繊維が微妙に違ってたり、汚れたり折り目が付いてたりして、同じ場所をスキャンしても異なった画像になってしまうかも知れない。つまり、ある種の『理想化』を行わないと、『字形レベルの文字概念』にならないといえる。9
漢字構造情報は、その全体としては、『字形レベルの文字概念』と同様に、具体物に紐づけられていない（物理世界の時空上の座標位置を持たない）抽象的な存在である。しかしながら、その中の部品は漢字構造中の相対的な位置関係を持つといわざるを得ない。即ち、漢字構造情報は『字形レベルの文字概念』や抽象文字と（それらが指し示す形状の具
体度＝包摂範囲の差を無視すれば）存在論的に同種のものだといえ、その属性の中に位置情報を含まないものといえる。しかし、漢字の中の部品に関する情報にはその属性のひとつとして位置情報が必要なのである。よって、仮に形状が一緒だとしても（そして、同じ漢字概念を示していたとしても）、位置情報が異なれば違うオブジェクトだと考えなければならない。
このことは「『杉』の左側の部品と『松』の左側の部品は同じ形をしているが、『木』とは形が異なる。これは偏化変形の一種である」という文が書けるかという問題を考えれば『「彬」の左側の部品』と『「彬」の真中の部判り易いかも知れない。4.4 節の表現の場合、品』の区別がなく、全て『抽象文字の「木」』になっている。このため、「「彬」の左側の部
品と「彬」の真中の部品は形が似ている」という文が書けない訳である。
こうした性質の差異を表現するために、具体物に紐づけられていない（物理世界の時空上の座標位置を持たない）抽象的な存在としての文字を『文字概念』と呼ぶことにする。
これは [10] における『グリフ』と同様に、それが指し示す形状の具体度＝包摂範囲の差に関係なく、抽象文字や字体、『字形レベルの文字概念』といったものは全て『文字概念』の一種と考えることにする。一方、何らかの位置情報で示される場所に現れた『文字概念』のインスタンスのようなものを『文字の出現』(character occurrence) と呼ぶことにする。
10 このモデルに従えば、字形や漢字の中の部品は『文字の出現』の一種になる。
9
例えば、『大漢和番号 12345 の字形』は、多分、この世に存在する全ての大漢和辭典の大漢和番号 12345の字形の平均画像を意味しないと思われる。なぜなら、ある本には折り目が付いてるかも知れないし、ある本には繊維にゴミが付いてるかも知れないし、ある本には落書や汚れが付いてるかも知れない。ここで想定されているものは、究極的には、『理想的な紙に理想的に印刷され理想的に保存された大漢和番号 12345 の字形』というこの世には実際に存在しないものだといえる。
10[15] では 7.2 節「もう一つのインスタンス問題：表現のオントロジー」において、文字の問題に関しても議論している。ここでは文字を文章や絵画、小説、音楽などの「表現」の一種とする立場を採っており、文字の場合、「実体」である二次元図形と、「表現」の一種である『（書かれた）文字図形』、「内容」としての『文字の典型形状の仕様』、および、「表現物」としての紙に書かれた文字を区別している。ここでの議論はやや文字の視覚的記号としての側面に偏っているようにも思えるが、概ね、『（書かれた）文字図形』は『文字の出現』、『文字の典型形状の仕様』は『文字概念』、『紙に書かれた文字』は字形に相当するものと考えられる。

13

4.6

部品概念を採り入れた IDC の述語化

4.4 節と 4.5 節での議論を踏まえれば、漢字、漢字構造情報、『文字の出現』の一種としての漢字の中の部品を別のオブジェクトとして扱いつつ、『IDC の述語化』を行った方法を採るのが望ましいと考えられる。

4.6.1『IDC の述語化』の改良『IDC の述語化』には、4.4 節で紹介した安岡氏の方法のように、３引数オペレーター
を２引数のものに分解・正規化する方法も考えられるが、ここでは IDS が表現する情報を保存できるように、分解・正規化を行わずに述語化することにする。
（文字の）名前』 (character name) を手がかりに関係素性名を決め
ここでは、IDC の『ることにする。
例えば、U+2FF0 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER LEFT TO RIGHT>であるが、この内の用字系 (script) を示す接頭辞 IDEOGRAPHIC DESCRIPTION CHARACTERを除いた部分は LEFT TO RIGHT であり、ここから、関係素性->connect-left, ->connect-rightを生成することができる。
同様に、U+2FF1 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER ABOVE TO BELOW>であるので、関係素性->connect-above, ->connect-belowが生成できる。
U+2FF2 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER LEFT TO MIDDLE AND RIGHT>であるので、関係素性->connect-left, ->connect-middle, ->connect-rightが生成できる。
同様に、U+2FF3 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER ABOVE TO MIDDLE AND BELOW>であるので、関係素性->connect-above, ->connect-middle, ->connect-below

14が生成できる。
ただ、この場合、横に並べた場合の真中と縦に並べた時の真中が区別できないのは問題かも知れない。そこで、前者を->connect-middle@horizontal,
後者を->connect-middle@verticalとすることにする。
U+2FF4 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER FULL SURROUND>
であるが、前述の方法のままでは適用できないので、囲む部分を示す関係素性を ->enclosure@full
囲まれる部分を示す関係素性を ->surrounded@fullとすることにする。11
U+2FF5 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER SURROUND FROM ABOVE>であるので、前述の方法に準じて、囲む部分を示す関係素性を ->enclosure@from-above
囲まれる部分を示す関係素性を ->surrounded@from-aboveとすることにする。
同様に、U+2FF6 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER SURROUND FROM BELOW>であるので、囲む部分を示す関係素性 ->enclosure@from-below
囲まれる部分を示す関係素性 ->surrounded@from-belowが生成できる。
同様に、U+2FF7 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER SURROUND FROM LEFT>
であるので、GlyphWiki の偏化変形修飾子では囲い系部品を示す修飾子の分類が IDC のと異なっているため、GlyphWiki との対応を考慮して、囲み系の関係素性名にドメインを用いている。[13]1115囲む部分を示す関係素性 ->enclosure@from-left
囲まれる部分を示す関係素性 ->surrounded@from-leftが生成できる。
同様に、U+2FF8 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER SURROUND FROM UPPER LEFT>
であるので、囲む部分を示す関係素性 ->enclosure@from-upper-left
囲まれる部分を示す関係素性 ->surrounded@from-upper-leftが生成できる。
同様に、U+2FF9 の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER SURROUND FROM UPPER RIGHT>であるので、囲む部分を示す関係素性 ->enclosure@from-upper-right
囲まれる部分を示す関係素性 ->surrounded@from-upper-rightが生成できる。
同様に、U+2FFA の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER SURROUND FROM LOWER LEFT>
であるので、囲む部分を示す関係素性 ->enclosure@from-lower-left
囲まれる部分を示す関係素性 ->surrounded@from-lower-leftが生成できる。
U+2FFB の場合、その名前は<IDEOGRAPHIC DESCRIPTION CHARACTER OVERLAID>
であるが、便宜的に、上書きされる（主要な）部分を示す関係素性 ->underlying
上書きする（付加的）部分を示す関係素性 ->overlayingを用いることにする。

4.6.2

IDC のための型の導入

IDC を型としても表現するために、IDC の名前の接頭辞を除いた部分から機械的に作成した語彙を用いることにする。例えば、U+2FF0 の場合は chise.ids:left-to-rightとなり、U+2FFA の場合は chise.ids:surround-from-lower-left となる。

16

4.6.3『文字の出現』の RDF 化『文字の出現』を『文字概念』（= 文字オブジェクト）と同格なものとして扱うためには、『文字概念』と同様な情報資源として表現すれば良い。また、『文字の出現』と『文字概念』の間の関係を示す述語として chise.ids:to.content（->content 素性）を導入する。
これらを使って、例えば、「彬」の漢字構造情報は<rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=彬"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"><chise.ids:left-to-rightxmlns:chise.ids="http://www.chise.org/est/rdf.cgi?domain=chise.ids/"><chise.ids:to.connect-left><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character-occurrence=彬/left"><chise.ids:to.content><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=木"></rdf:Description></chise.ids:to.content></rdf:Description></chise.ids:to.connect-left><chise.ids:to.connect-right><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character-occurrence=彬/right"><chise.ids:to.content><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=杉"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"><chise.ids:left-to-right><chise.ids:to.connect-left><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character-occurrence=杉/left"><chise.ids:to.content><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=木"></rdf:Description></chise.ids:to.content></rdf:Description></chise.ids:to.connect-left><chise.ids:to.connect-right><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character-occurrence=杉/right"><chise.ids:to.content><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=彡"></rdf:Description></chise.ids:to.content></rdf:Description></chise.ids:to.connect-right></chise.ids:left-to-right>

17</est:ideographic-structure></rdf:Description></chise.ids:to.content></rdf:Description></chise.ids:to.connect-right></chise.ids:left-to-right></est:ideographic-structure></rdf:Description>のように書くことができる。図 5 にこの RDF グラフを示す。

"
ideographic-structure!#!#$
connect-leftconnect-right"%&'()%
content"%"#$%&&#typeideographic-structure
content

!#$
#type

!!

connect-left!#$%"#$%
content

connect-right!#$%&'()%
content#$

図 5: 『文字の出現』オブジェクトを導入した場合の「彬」のグラフ

18

4.6.4

IDS 用コンテナを使った簡略化

4.6.3 節の例を見れば判るように、『文字の出現』をオブジェクト化した結果、漢字構造
情報の RDF はかなり複雑なものとなってしまった。
しかしながら、4.5 節で述べたように、4.2 節で述べた RDF コンテナを使った方法であっても、コンテナが要素の位置情報を保持しており、実質的に『文字の出現』をオブジェクト化した場合と同様の情報を表現できていた訳である。
『文字の出現』における位置の情報
そこで、IDC に相当する RDF コンテナを導入し、をコンテナ側に持たせることで、簡略化することを考える。
例えば、「彬」の漢字構造情報は<rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=彬"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"><chise.ids:left-to-rightxmlns:chise.ids="http://www.chise.org/est/rdf.cgi?domain=chise.ids/"><chise.ids:to.connect-left><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=木"></rdf:Description></chise.ids:to.connect-left><chise.ids:to.connect-right><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=杉"><est:ideographic-structure
xmlns:est="http://www.chise.org/est/rdf.cgi?domain=est/"><chise.ids:left-to-right><chise.ids:to.connect-left><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=木"></rdf:Description></chise.ids:to.connect-left><chise.ids:to.connect-right><rdf:Description
rdf:about="http://www.chise.org/est/rdf.cgi?character=彡"></rdf:Description></chise.ids:to.connect-right></chise.ids:left-to-right></est:ideographic-structure></rdf:Description></chise.ids:to.connect-right></chise.ids:left-to-right></est:ideographic-structure></rdf:Description>のように表現する訳である。図 6 にこの RDF グラフを示す。

19

#ideographic-structure"$"$%
connect-right

&&
#type

ideographic-structure

connect-left

"$%
#type

!"

connect-rightconnect-left%$

図 6: IDC コンテナを使った簡略化を行った場合の「彬」のグラフ

4.7

包摂範囲の異なる文字概念間の関係

これまで挙げた例では、簡単化のために、漢字構造情報中の部品は全て UCS の抽象文
字相当のものとして扱ってきたが、字体レベルのものや字形レベルのものといったより包摂範囲の狭い（より具体的な形状を示す）『文字概念』オブジェクトを部品としても良い。
実際、CHISE 文字オントロジー中では包摂範囲の異なるものを部品として用いた漢字構
造情報が用いられており、部品の包摂範囲を使って『文字概念』が示す包摂範囲を示すことができる。

5

おわりに
漢字構造情報を RDF を用いた表現法について議論し、• 文字列を用いた表現• RDF コンテナを用いた表現• RDF コレクションを用いた表現• 安岡メモでの表現• 『文字の出現』オブジェクトを用いた表現• IDC コンテナを用いた簡略化

20

という６種類の方法を実例を挙げて比較検討を行った。
漢字構造情報を RDF を用いて表現する場合、IDS の構文木に相当する情報が十分に保持されていることと、それが意味するものが RDF のグラフとしてきちんと表現されていることが望ましい。そのためには、• IDC の述語化・型の導入• 抽象文字や字形、グリフといったものを、包摂範囲の差に基づく軸と位置情報の有無に関する軸で整理– 後者の軸に基づき、『文字概念』位置情報を持たないもの（デバイスに紐づけられていないもの；
表現としての文字の『内容』；概念としての文字の『設計図』のようなもの）『文字の出現』位置情報を持つもの（文字が置かれた場に紐づけられている；
文字の『表現』）という概念を導入• 『文字の出現』を通常の資源、もしくは、IDC コンテナで表現といった手法を採るのが良いと考えられる。
本稿では漢字構造情報の RDF に関わる問題に関してなるべく網羅的に取り上げることを試みたが、『多粒度漢字構造情報』の RDF 化等の幾つかの問題については、残念ながら今回は取り上げることができなかった。こうした問題に関してはまた別稿で取り上げたい。
最後に、本稿を書くきっかけを与えて頂いた、山崎直樹氏と安岡孝一氏に感謝する。特に、安岡孝一氏には氏のメモ「IDS は RDF で書けるのか」をご教示頂いたばかりか、そのLATEX のソースコードを提供して頂き、その利用をお許し頂いたことは、そこで提案された『IDC の述語化』というアイディアとともに、本稿を書く上での大きな助けとなった。

参考文献[1] International Organization for Standardization (ISO). Information technology —Universal Multiple-Octet Coded Character Set (UCS) – Part 1: Architecture andBasic Multilingual Plane (BMP), 2000 年 3 月. ISO/IEC 10646-1:2000.
[2] International Organization for Standardization (ISO). Information technology —Universal Multiple-Octet Coded Character Set (UCS), 2012 年 6 月. ISO/IEC
10646:2012.
[3] Ken Lunde, Richard Cook, and John H. Jenkins (ed.). Unicode Ideographic Variation Database. Unicode Technical Standard #37, 2011 年 11 月. Revision 8.
[4] Tomohiko Morioka. CHISE: Character processing based on character ontology. In
Large-scale Knowledge Resources (LKR2008), No. 4938 in LNAI, pp. 148–162, 2008
年 3 月.

21

[5] Henry S. Thompson. Web Architecture and Naming for Knowledge Resources. In
Large-scale Knowledge Resources (LKR2008), No. 4938 in LNAI, pp. 334–343, 2008
年 3 月.
[6] World Wide Web Consortium, http://www.w3.org/TR/2004/REC-rdf-syntaxgrammar-20040210/. RDF/XML Syntax Specification (Revised), 2004 年 2 月.
[7] World Wide Web Consortium, http://www.w3.org/TR/2004/REC-rdf-concepts20040210/. Resource Description Framework (RDF): Concepts and Abstract Syntax,
2004 年 2 月.
[8] 守岡知彦. CHISE IDS 漢字検索. http://www.chise.org/ids-find.
[9] 守岡知彦. 文字オントロジーに基づく文字処理について. 情処研報, Vol. 2006, No.
112, pp. 25–32, 2006 年 10 月. 2006-CH-72.
[10] 守岡知彦. CHISE に基づくグリフ・オントロジーの試み. 人文科学とコンピュータシ
ンポジウム論文集—デジタル・ヒューマニティーズの可能性, 情報処理学会シンポジ
ウムシリーズ, 第 2009 巻, pp. 9–14. 情報処理学会, 情報処理学会, 2009 年.
[11] 守岡知彦. CHISE のセマンティック Wiki 化の試み. 情処研報, Vol. 2010-CH-87,
No. 8, pp. 1–8, 2010 年 7 月.
[12] 守岡知彦. Wiki 的手法に基づく構造化データの編集について. 人文科学とコンピュー
タシンポジウム論文集 —人文工学の可能性〜異分野融合による「実質化」の方法〜,
情報処理学会シンポジウムシリーズ, 第 2010 巻, pp. 33–40. 情報処理学会, 情報処理学会, 2010 年 12 月.
[13] 守岡知彦. 漢字字形データベースと文字オントロジーの データ統合の可能性について. 情処研報, Vol. 2012-CH-94, No. 8, pp. 1–8, 2012 年 5 月.
[14] 守岡知彦, クリスティアン・ウィッテルン. 文字データベースに基づく文字オブジェク
ト技術の構築. 情報処理振興事業協会 平成 13 年度 成果報告集. 情報処理振興事業協会, 2002 年. http://www.ipa.go.jp/NBP/13nendo/reports/explorat/charadb/
charadb.pdf.
[15] 溝口理一郎. オントロジー工学. 知の科学. オーム社, 2005 年 1 月.

22࿖┙࿖ળ࿑ᦠ㙚ߩࡔ࠲࠺࡯࠲ᮡḰ㧙࠺࡯࠲ࠍ❬ߍࠆࡔ࠲࠺࡯࠲㧦DC-NDL㧙ᩊ↰ ᵗሶ㧔࿖┙࿖ળ࿑ᦠ㙚㧕yshibata@ndl.go.jpⷐᣦ㧦⍮⼂߿ᖱႎߣ೑↪⠪ࠍ⊛⏕ߦ⚿߮ߟߌࠆߎߣߪ‫ޔ‬࿑ᦠ㙚ߩ㊀ⷐߥᓎഀߩ৻ߟߢ޽ࠆ‫ޕ‬࿖┙࿖ળ࿑ᦠ㙚ߢߪ‫⤘ޔ‬ᄢߥᖱႎ⾗Ḯߩਛ߆ࠄ೑↪⠪߇ㆡಾߥᖱႎࠍ⊒⷗࡮⼂೎ߢ߈ࠆᚻᲑߣߒߡ‫ޔߚ߹ޔ‬࿑ᦠ㙚ࠍߪߓ߼᭽‫ߥޘ‬ᯏ㑐߇ᚲ᦭ߔࠆ࠺࡯࠲ࠍ❬ߍ‫ߩߘޔ‬೑↪น⢻ᕈࠍะ਄ߐߖࠆᨒ⚵ߺߣߒߡ‫࠲࡯࠺࠲ࡔޔ‬ᮡḰ DC-NDL ࠍቯ߼ߡ޿
ࠆ‫ᧄޕ‬Ⓜߢߪ‫ߦࡉࠚ࠙ࠢ࠶ࠖ࠹ࡦࡑ࠮ޔ‬ኻᔕߒߚ DC-NDL ߩࠦࡦ࠮ࡊ࠻߿╷ቯ⚻✲‫ޕࠆߔ੺⚫ߡ޿ߟߦ╬⸘⸳ࡑ࡯ࠠࠬޔ‬ࠠ࡯ࡢ࡯࠼㧦ࡔ࠲࠺࡯࠲㧘࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉ㧘Dublin Core

1. ߪߓ߼ߦ ⍮⼂߿ᖱႎߣ೑↪⠪ࠍ⊛⏕ߦ⚿߮ߟߌࠆߎߣߪ‫ޔ‬࿑ᦠ㙚ߩ㊀ⷐߥᓎഀߩ৻ߟߢ޽ࠆ‫ޕ‬࿖┙࿖ળ࿑ᦠ㙚㧔NDL㧕ߪ‫ޔ‬࿖ߩ໑৻ߩ⚊ᧄ࿑ᦠ㙚࡮଻ሽ࿑ᦠ㙚ߣߒߡ‫ޔ‬࿖ౝߢೀⴕ
ߐࠇࠆ಴‛ࠍᐢߊ෼㓸ߒ‫⾆ޔ‬㊀ߥᢥൻ⊛⾗↥ߣߒߡ଻ሽߔࠆߣߣ߽ߦ‫ޔ‬⍮⼂࡮ᢥൻߩၮ⋚ߣߒߡ⺕߽߇೑↪ߢ߈ࠆⅣႺ࡮ᚻᲑࠍឭଏߔࠆߎߣࠍ૶๮ߣߒߡ޿ࠆ‫ޔߪࠄࠇߎޕ‬࿑ᦠ߿㔀⹹ߣ޿ߞߚශ೚಴

‛ߦߣߤ߹ࠄߕ‫࠻࠶ࡀ࡯࠲ࡦࠗޔ‬਄ߢᵹㅢߔࠆ᭽‫ߥޘ‬ᖱႎ⾗Ḯ߽฽߹ࠇࠆ‫⤘ޕ‬ᄢߥᖱႎ⾗Ḯߩਛ߆ࠄ೑↪⠪߇ㆡಾߥᖱႎࠍ⊒⷗ߢ߈ࠆᚻᲑߣߒߡ‫ޔ‬ߘߩᖱႎ⾗Ḯߦ㑐ߔࠆ࠺࡯࠲‫߇࠲࡯࠺࠲ࡔߜࠊߥߔޔ‬㊀ⷐߢ޽ࠆ‫ޔ߼ߚߩߘޕ‬NDL ߢߪ‫ޔ‬ᇦ૕ߦ᜚ࠄߕᄙ᭽ߥᖱႎ⾗Ḯࠍㆡಾߦᢛℂ㧔⚵❱ൻ㧕ߒ‫ޔ‬೑↪ߦଏߔࠆߚ߼ߩࡔ࠲
࠺࡯࠲ߩᨒ⚵ߺߣߒߡ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ㧔DC-NDL㧕‫ޠ‬1ࠍቯ߼‫ߦࠇߎޔ‬Ḱ᜚ߒߚࡔ࠲࠺࡯࠲ࠍ૞ᚑ࡮ឭଏߒߡ޿ࠆ‫ޕ‬ ᧄⓂߢߪ‫ޔ‬2 ┨ߢ DC-NDL ߩ᭎ⷐ‫ޔ࠻ࡊ࠮ࡦࠦޔ‬3 ┨ߢ Dublin Core ߣ NDL ߩേะ߆ࠄߺߚ DC-NDL ߩᄌㆫ‫ޔ‬4 ┨ߢ᭎ᔨࡕ࠺࡞߿ࡈࠜ࡯ࡑ࠶࠻╬ߩ઀⚵ߺࠍ⸃⺑ߒ‫ޔ‬5┨ߢ੹ᓟߩข⚵ߺߦߟ޿ߡㅀߴࠆ‫ޕ‬1એਅ‫޿ߥ߇╬␜⴫ ߦ․ޔ‬႐ว‫ޔ‬DC-NDL ߪᦨᣂ ߩ DC-NDL 2011 ᐕ 12 ᦬

23ࠍ⴫ࠊߔ‫ޕ‬2. ᨒ⚵ߺ
2.1. DC-NDL ߣߪ
DC-NDL ߪ‫ޔ‬NDL ߇ណ↪ߔࠆࡔ࠲࠺࡯࠲ߩ⸥ㅀ⺆ᒵߣ⸥ㅀⷙೣߩ✚⒓ߢ޽ࠆ‫ޕ‬࿖ౝߩ࿑ᦠ㙚߿㑐ㅪᯏ㑐╬ߦ߅ߌࠆ࠺࡯࠲ߩ੤឵࡮౒᦭ߦ߽೑↪ߢ߈ࠆࡔ࠲࠺࡯࠲ᮡḰߣߒߡߛߌߢߥߊ‫ߩߘޔ‬ฬ߇␜ߔࠃ߁ߦ‫ޔ‬࿖㓙⊛ߥࡔ࠲࠺࡯࠲ᮡḰߢ޽ࠆ Dublin Core ߦၮߠ߈‫ޔ‬࿖㓙⊛ߥࡔ࠲࠺࡯࠲ߩᵹㅢߦነਈߔࠆߎߣ߽ᔒะߒߡ޿ࠆ‫ޔ߼ߚߩߘޕ‬Dublin
Core ╬ߩ࿖㓙⊛ߥࡔ࠲࠺࡯࠲ᮡḰߢቯ⟵ߐࠇߚ⺆ᒵߦട߃‫ޔ‬ᣣᧄ⺆ߩ⺒ߺ߳ߩኻᔕ╬‫ޔ‬
NDL ߇⚵❱ൻࠍⴕ߁㓙ߦᔅⷐߥ⺆ᒵࠍ⁛⥄ߢቯ⟵ߒߡណ↪ߒߡ޿ࠆ‫ޔߚ߹ޕ‬ฦ⺆ᒵߦߟ޿ߡ‫ޔ‬NDL ߦ߅ߌࠆᮡḰ⊛ߥࡔ࠲࠺࡯࠲ߩ⸥ㅀᣇᴺ߽ቯ߼ߡ߅ࠅ‫ޔ‬એਅߩਃㇱߢ᭴ᚑߐࠇߡ޿ࠆ2‫ޕ‬‫৻╙ޟ‬ㇱ NDL Metadata Terms‫ޠ‬
NDL ߇⁛⥄ߦቯ⟵ߒߚ⺆ᒵ㓸‫ޕ‬଀㧕¾

࠲ࠗ࠻࡞߿૞ᚑ⠪ߦኻߔࠆ⺒ߺ "dcndl:transcription"¾

࿑ᦠ㙚⾗ᢱߩ․ᕈߦᔕߓߚ⺆ᒵ㧔ඳ჻⺰ᢥߩቇ૏ಽ㊁ฬ "dcndl:degreeName"‫ޔ‬ႎ๔⇟ภ "dcndl:dissertationNumber"╬㧕¾ᮡḰ⊛ߥ⛔೙⺆ᒵ࡮ಽ㘃૕♽㧔࿖㓙ᮡḰ࿑ᦠ⇟ภ"dcndl:ISBN"‫ޔ‬࿖┙࿖ળ࿑ᦠ㙚ઙฬᮡ⋡⴫"dcndl:NDLSH"╬㧕‫╙ޟ‬ੑㇱ Application Profile‫ޠ‬
NDL ߇ࡔ࠲࠺࡯࠲ࠍ૞ᚑߔࠆ㓙ߦ↪޿ࠆ⺆ᒵߩᮡḰ⊛ߥ⸥ㅀᣇᴺߦߟ޿ߡቯ߼ߚ߽
ߩ‫ޕ‬ᣢሽߩ⺆ᒵ෸߮⁛⥄ߢቯ⟵ߒߚ⺆ᒵߩ NDL ߦ߅ߌࠆ૶↪ᴺ‫ޔ‬୯ߩ⸥ㅀᒻᑼ‫⃻⴫ޔ‬଀╬ࠍ⺑᣿‫ޕ‬‫╙ޟ‬ਃㇱ RDF ࠬࠠ࡯ࡑ‫ޠ‬
NDL ߇⁛⥄ߦቯ⟵ߒߚ⺆ᒵࠍ࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉߦ߅ߌࠆᮡḰ⊛ߥࡔ࠲࠺࡯࠲ߩ
⴫⃻ᣇᴺߢ޽ࠆ RDF㧔Resource Description Framework㧕ᒻᑼߢ⸥ㅀߒߚࡈࠔࠗ࡞‫ޕ‬‫৻╙ޟ‬ㇱ NDL Metadata Terms‫ߩޠ‬ᯏ᪾น⺒ߦ⋧ᒰ‫ޕ‬

2.2. ࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉᔒะ
࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉߪ‫࠻࠶ࡀ࡯࠲ࡦࠗޔ‬਄ߩᖱႎ⾗Ḯߦ᣿⏕ߥᗧ๧ࠍᜬߟ࠺࡯࠲ࠍ
ઃਈߒ‫ߩߘ߇࠲࡯ࡘࡇࡦࠦޔ‬ᗧ๧ࠍᯏ᪾⊛ߦಣℂߢ߈ࠆᰴ਎ઍ࠙ࠚࡉߩ᭴ᗐ෸߮ߘߩታ
⃻ߦะߌߚข⚵ߺߢ޽ࠆ‫ࡉࠚ࠙ࠢ࠶ࠖ࠹ࡦࡑ࠮ޕ‬ᛛⴚߩᵴ↪ߦࠃࠅ‫ޔ‬೑↪⠪ߪ‫࠲ࡦࠗޔ‬࡯ࡀ࠶࠻਄ߩ⤘ᄢߥᖱႎ⾗Ḯߩਛ߆ࠄ⥄りߩ᳞߼ࠆᖱႎߦ⊛⏕ߦߚߤࠅ⌕ߊߎߣ߇ߢ
߈ࠆࠃ߁ߦߥࠆ‫ޕ‬ߘߩߚ߼‫ޔ‬DC-NDL ߩࡔ࠲࠺࡯࠲ࠬࠠ࡯ࡑߪ RDF ࠍ↪޿ߡ޿ࠆ‫ޔߒ߆ߒޕ‬DC-NDL
2

http://www.ndl.go.jp/jp/aboutus/standards/meta.html㧔ෳᾖ 2013-01-11㧕

24ࠍណ↪ߔࠆᯏ㑐߿ࠪࠬ࠹ࡓߢᔅߕߒ߽ RDF ᒻᑼߩࡔ࠲࠺࡯࠲ߦኻᔕߢ߈ࠆߣߪ㒢ࠄߥ޿ߚ߼‫ޔ‬RDF ᒻᑼߢ⴫⃻ߢ߈ߥ޿႐วߢ߽૶↪ߢ߈ࠆ⺆ᒵ߽޽ࠊߖߡቯ⟵ߒߡ޿ࠆ‫ޕ‬ട߃ߡ‫⺆ߩ࠲࡯࠺࠲ࡔޔ‬ᒵ߽ RDF ᒻᑼߢቯ⟵ߒߡ޿ࠆ‫⺆ޕ‬ᒵࠍቯ⟵ߔࠆ㓙‫࠲࡯࠺ޔ‬㗄⋡ߦ⁛⥄ߩฬ⒓ࠍߟߌߚߛߌߢߪ‫ߩߘߪ࠲࡯ࡘࡇࡦࠦޔ‬ᗧ๧ࠍℂ⸃ߔࠆߎߣ߇ߢ߈ߥ
޿‫⺆ߩߘޔ߼ߚߩߘޕ‬ᒵߩᜬߟᗧ๧ࠍᯏ᪾ಣℂߢ߈ࠆᒻᑼߢ⴫⃻ߔࠆᔅⷐ߇޽ࠆ‫ߎߘޕ‬ߢ‫ޔ‬RDF ࠍ↪޿ߡ⺆ᒵࠍቯ⟵ߒ‫⺆ޔ‬ᒵߩ⸥ㅀኻ⽎ߣߥࠆᖱႎ⾗Ḯ㧔࡝࠰࡯ࠬ㧕ߩ▸࿐ࠍᜰቯߔࠆቯ⟵ၞ‫⺆ޔ‬ᒵߩ୯߇ขࠅᓧࠆ▸࿐ࠍᜰቯߔࠆ୯ၞࠍߘࠇߙࠇ⸳ቯߔࠆߣߣ߽
ߦ‫ޔ‬Dublin Core ߢቯ⟵ߐࠇߚਥⷐߥ⺆ᒵߣ㑐ㅪߠߌ‫ ࠍࠄࠇߎޔ‬RDF ࠬࠠ࡯ࡑߣߒߡ
ቯ⟵࡮౏㐿ߒߡ޿ࠆ‫ޕ‬
2.3. ⋧੕ㆇ↪ᕈߩะ਄
NDL ߢߪ‫⥄ޔ‬㙚ߩߺߥࠄߕ‫ޔ‬࿖ౝߩ࿑ᦠ㙚߿㑐ㅪᯏ㑐╬ߦ߅޿ߡ߽ DC-NDL ߩ೑↪
ࠍផㅴߒߡ޿ࠆ‫⋧ߩ࠲࡯࠺࠲ࡔޔߢߎߘޕ‬੕ㆇ↪ᕈࠍะ਄ߔࠆߚ߼ߩၮ␆⊛ߥࡕ࠺࡞ߢ
޽ࠆࠕࡊ࡝ࠤ࡯࡚ࠪࡦ࡮ࡊࡠࡈࠔࠗ࡞3ߩ⠨߃ᣇࠍขࠅ౉ࠇ‫⺆ޔ‬ᒵߩቯ⟵㧔࠮ࡑࡦ࠹ࠖ
ࠢࠬ㧕ߣ⺆ᒵߩ⸥ㅀᣇᴺ࡮⸥ㅀᒻᑼ㧔ࠪࡦ࠲࠶ࠢࠬ㧕ࠍಽߌߡቯ⟵ߒߡ޿ࠆ‫ࠤ࡝ࡊࠕޕ‬࡯࡚ࠪࡦ࡮ࡊࡠࡈࠔࠗ࡞ߪ‫ޔ‬Dublin Core ߇ឭ໒ߒߡ޿ࠆᨒ⚵ߺߢ޽ࠅ‫ޔ‬ᓟ⠪ߩࠪࡦ࠲࠶ࠢࠬߦ⹥ᒰߒ‫⸥ࠍ࠲࡯࠺࠲ࡔޔ‬ㅀߔࠆ㓙ߦߤߩࠃ߁ߥ⺆ᒵࠍ૶↪ߒ‫ߥ߁ࠃߩߤޔ‬ᒻᑼߢ⸥ㅀߔࠆ߆ࠍቯ⟵ߒߚ⸥ㅀⷙೣߣ߽޿߃ࠆ‫ߩߎޕ‬ਛߢߪ‫⺆ࠆߔ↪૶ޔ‬ᒵࠍᔅߕߒ߽
Dublin Core ߢቯ⟵ߐࠇߡ޿ࠆ߽ߩߦ㒢ቯߔࠆᔅⷐߪߥߊ‫࡯ࠠࠬ࠲࡯࠺࠲ࡔߩઁߩߘޔ‬ࡑߢቯ⟵ߐࠇߡ޿ࠆᣢሽߩ⺆ᒵࠍᵹ↪ߔࠆߎߣ߽‫ޔ‬ᣂߚߦ⁛⥄ߢቯ⟵ߒߚ⺆ᒵࠍ૶↪ߔࠆߎߣ߽ߢ߈ࠆ‫ߌߛࠆ߈ߢޕ‬ᣢሽߩᮡḰ⊛ߥ⺆ᒵࠍౣ೑↪ߔࠆߎߣߢ‫ޔ‬࿖㓙⊛ߥ⺆ᒵߩ౒᦭ࠍଦㅴߔࠆߎߣ߇ߢ߈‫⋧ޔ‬੕ㆇ↪ᕈࠍ㜞߼ࠆߎߣ߇ߢ߈ࠆ‫ޕ‬DC-NDL ߢߪ‫ޔ‬NDL Metadata Terms ߇࠮ࡑࡦ࠹ࠖࠢࠬߦ⋧ᒰߒ‫ޔ‬Application
Profile ߇ࠪࡦ࠲࠶ࠢࠬߦ⋧ᒰߔࠆ‫ޕ‬ᣢሽߩ⺆ᒵߢߪ⴫⃻ߢ߈ߥ޿ⷐ⚛ߦߟ޿ߡߩߺNDL Metadata Terms ߣߒߡቯ⟵ߒߡ߅ࠅ‫ޔ‬ᣣᧄ⺆ߩ․ᕈ߳ߩ㈩ᘦ߿࿖ౝߢ᥉෸ߒߡ
޿ࠆ⛔೙⺆ᒵ߿ಽ㘃૕♽߳ߩኻᔕࠍⴕߞߡ޿ࠆ‫ޕ‬ᓟ⠪ߩ Application Profile ߪ NDLߦ߅ߌࠆᮡḰ⊛ߥ⸥ㅀⷙೣߢ޽ࠅ‫․ޔ‬ቯߩࠪࠬ࠹ࡓߩታⵝߦၮߠߊ߽ߩߢߪߥ޿߇‫ߎޔ‬ࠇࠍ౏㐿ߔࠆߎߣߢ‫ߩઁޔ‬࿑ᦠ㙚߿㑐ㅪᯏ㑐╬߇⥄ᯏ㑐ߩࠕࡊ࡝ࠤ࡯࡚ࠪࡦ࡮ࡊࡠࡈࠔ
ࠗ࡞ࠍᬌ⸛ߔࠆ㓙ߩෳ⠨ߣߥࠆߎߣ߽ડ࿑ߒߡ޿ࠆ‫ޕ‬
2.4. Dublin Core ߳ߩḰ᜚
 NDL ߢߪ‫ޔ‬࿖ౝߦߣߤ߹ࠄߕ࿖ᄖߩᯏ㑐ߣߩࡔ࠲࠺࡯࠲ߩ੤឵࡮౒᦭ࠍଦㅴߔࠆߚ
߼‫ޔ‬࿖㓙⊛ߦ᥉෸ߒߡ޿ࠆ Dublin Core ߳ߩḰ᜚ߦദ߼ߡ޿ࠆ‫ߩ⺆⸒ޔࠅࠃߦࠇߎޕ‬ოࠍ⿥߃ߡ਎⇇ߣ❬߇ࠅ‫ࠅࠃޔ‬᏷ᐢߊ࠺࡯࠲߇ᵴ↪ߐࠇࠆߎߣ߇ᦼᓙߐࠇࠆ‫ޕ‬DC-NDL

DC-NDL ߩ㨬╙ੑㇱ Application Profile㨭ߣ඙೎ߔࠆߚ߼‫ޔ‬Dublin Core ߦ߅ߌࠆ Application
Profile ߪ‫ߣޠ࡞ࠗࠔࡈࡠࡊ࡮ࡦ࡚ࠪ࡯ࠤ࡝ࡊࠕޟ‬એਅ⴫⸥ߔࠆ‫ޕ‬
325

ߦ㑐ߒߡߪ‫ޔ‬ታ㓙ߪ⁛⥄ߦ᜛ᒛߒߚⷐ⚛ࠍዋߥ߆ࠄߕ฽߻ߚ߼‫޿⸒ߪߣ࡞ࡊࡦࠪޔ‬㔍޿ߣߩᜰ៰߽޽ࠆ߇‫ޔ‬Dublin Core ߩ⺆ᒵ⥄૕ߪߘߩ߹߹ߩᒻߢ೑↪ߒ‫ߩߘޔ‬ၮᧄ⊛ߥ⠨߃ᣇ߿ᨒ⚵ߺࠍฃߌ⛮ߋᆫ൓ࠍ᣿␜ߔࠆߚ߼‫ޟޔ‬࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯
࠲⸥ㅀ㧔DC-NDL㧕‫ߣޠ‬๭⒓ߒߡ޿ࠆ‫ޕ‬

3. ᱠߺ
DC-NDL ߩ␲ߪ‫ޔ‬2001 ᐕ 3 ᦬ߦ╷ቯߒߚ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࡔ࠲࠺࡯࠲⸥ㅀⷐ⚛㧔NDL
ࡔ࠲࠺࡯࠲㧕
‫ߦޠ‬㆚ࠆ‫ޕ‬એ㒠‫ޔ‬࿖ౝᄖߩࡔ࠲࠺࡯࠲ࠍขࠅᏎߊ⁁ᴫࠍㆡቱ෻ᤋߒߥ߇ࠄ‫ޔ‬
3 ᐲߩᡷ⸓ࠍ⚻ߡ⃻࿷ߩ DC-NDL ߦ⥋ࠆ‫ߩߘޕ‬ᄌㆫߦߟ޿ߡ‫ޔ‬NDL ߦ߅ߌࠆ㔚ሶ࿑ᦠ㙚ࠨ࡯ࡆࠬߩㅴዷߣ Dublin Core ߩേะߦᴪߞߡㅀߴࠆ‫ޕ‬
3.1. ࿖┙࿖ળ࿑ᦠ㙚ࡔ࠲࠺࡯࠲⸥ㅀⷐ⚛㧔NDL ࡔ࠲࠺࡯࠲㧕
㧔2001 ᐕ 3 ᦬㧕
NDL ࡔ࠲࠺࡯࠲ߪ‫੹ޔ‬ᓟߩ NDL ߦ߅ߌࠆ㔚ሶ࿑ᦠ㙚᭴▽ߩ޽ࠅᣇࠍ߹ߣ߼ߚ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚㔚ሶ࿑ᦠ㙚᭴ᗐ‫ޠ‬4㧔1998 ᐕ 5 ᦬㧕ߦၮߠ߈‫ޔ‬NDL ߇࠙ࠚࡉࠨࠗ࠻߿㔚ሶ㔀⹹╬ߩࡀ࠶࠻ࡢ࡯ࠢ♽㔚ሶ಴‛ࠍ⚵❱ൻߔࠆ㓙ߦ↪޿ࠆࡔ࠲࠺࡯࠲㧔ᦠ⹹ᖱႎ㧕ߩၮḰߣߒߡ╷ቯߐࠇߚ‫ޕ‬⸥ㅀⷐ⚛ߦߪ‫ޔ‬ᰴߩℂ↱߆ࠄ Dublin Core Metadata Element
Set㧔DCMES㧕5ߣ๭߫ࠇࠆ Dublin Core ߩၮᧄ 15 ⷐ⚛ࠍណ↪ߒߚ‫ޕ‬¾

࿖㓙⊛ߥᮡḰൻࠍផㅴߒߡ߅ࠅ‫ޔ‬᥉෸ߒߡ޿ࠆࡔ࠲࠺࡯࠲ߢ޽ࠆ

¾

࡝ࡦࠢᖱႎ߿ᮭ೑㑐ଥߩߚ߼ߩ⸥ㅀⷐ⚛߇޽ࠅ‫࠻࠶ࡀ࡯࠲ࡦࠗޔ‬਄ߩᖱႎ⾗Ḯߩ⸥ㅀߦ೑ὐ߇޽ࠆ

¾◲ଢߢ޽ࠅ‫ޔ‬૞ᚑ⠪߿಴⠪⥄り߇ࠦࡦ࠹ࡦ࠷㧔৻ᰴᖱႎ㧕ߘߩ߽ߩߦࡔ࠲࠺࡯

࠲ࠍઃਈߢ߈ࠆ
ၮᧄ 15 ⷐ⚛ߦട߃‫ޔ‬ฦⷐ⚛ߩᗧ๧ౝኈࠍ⵬ቢߒ‫❱⚵ࠍ࠲࡯࠺࠲ࡔߦ⚦⹦ࠅࠃޔ‬ൻߔࠆߚ߼‫ޔ‬Dublin Core ߢផᅑߐࠇߚ㒢ቯሶߩ৻ㇱߣ‫ޔ‬NDL ߇⁛⥄ߢ⸳ቯߒߚ㒢ቯሶࠍ૶↪ߒߚ‫ޕ‬⸵⻌ࠍᓧߚ࠙ࠚࡉࠨࠗ࠻߿㔚ሶ㔀⹹ࠍ෼㓸࡮଻ሽߔࠆታ㛎ࡊࡠࠫࠚࠢ࠻‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࠗࡦ࠲࡯ࡀ࠶࠻⾗Ḯㆬᛯ⊛⫾Ⓧታ㛎੐ᬺ㧔WARP㧕‫ޠ‬㧔2002 ᐕ㧕߿ࠗࡦ࠲࡯ࡀ࠶࠻
਄ߩ࠺࡯࠲ࡌ࡯ࠬࠍ⚵❱ൻߒߚ࡝ࡦࠢ㓸‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚࠺࡯࠲ࡌ࡯ࠬ࡮࠽ࡆࠥ࡯࡚ࠪ
ࡦ࡮ࠨ࡯ࡆࠬ㧔Dnavi㧕‫ޠ‬6㧔หᐕ㧕╬‫ޔ‬ਥߦ NDL ߩᣂߚߥ㔚ሶ࿑ᦠ㙚ࠨ࡯ࡆࠬߢណ↪
ߐࠇߚ‫ޕ‬
3.2. ࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀⷐ⚛㧔DC-NDL 2007 ᐕ㧕

NDL ࡔ࠲࠺࡯࠲╷ቯᓟ‫ޔ‬೨ㅀߩ WARP ߇‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࠗࡦ࠲࡯ࡀ࠶࠻ᖱႎㆬᛯ
⊛⫾Ⓧ੐ᬺ‫ ߡߒߣޠ‬2006 ᐕ߆ࠄᧄᩰ੐ᬺൻߒߚ‫ޔߚ߹ޕ‬ඳ‛㙚࡮⟤ⴚ㙚╬ߩᢥൻᯏ㑐
http://www.ndl.go.jp/jp/aboutus/elib_plan.html㧔ෳᾖ 2013-01-11㧕
http://dublincore.org/documents/dces/㧔ෳᾖ 2013-01-11㧕
6 http://dnavi.da.ndl.go.jp/㧔ෳᾖ 2013-01-11㧕
4
526

߿ቇⴚᯏ㑐╬߇ឭଏߒߡ޿ࠆ࠺ࠫ࠲࡞ࠦࡦ࠹ࡦ࠷ࠍ৻ర⊛ߦᬌ⚝ߢ߈ࠆ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚࠺ࠫ࠲࡞ࠕ࡯ࠞࠗࡉࡐ࡯࠲࡞㧔PORTA㧕‫ ߇ޠ‬2007 ᐕߦ౏㐿ߐࠇߚ‫ޔࠅࠃߦࠇߎޕ‬NDL
ߦ߅ߌࠆ࠺ࠫ࠲࡞ࠕ࡯ࠞࠗࡉߩ᭴▽߇ㅴዷߒ‫❱⚵ޔ‬ൻߩኻ⽎ߣߒߡᛒ߁ߴ߈ᖱႎ⾗Ḯߩ⒳㘃߿․ᕈ߽ߐࠄߦᄙ᭽ൻߒߚ‫ޕ‬৻ᣇ‫ޔ‬Dublin Core ߦߟ޿ߡ߽ᣂߚߥേ߈߇⷗ࠄࠇߚ‫ޔߕ߹ޕ‬2003 ᐕߦ DCMES ߇࿖㓙ⷙᩰൻ㧔ISO 15836㧕ߐࠇ‫ޔ‬ฬታߣ߽ߦ࿖㓙⊛ߥࡔ࠲࠺࡯࠲ᮡḰߣߥߞߚ‫ޔߦࠄߐޕ‬2005 ᐕߦߪ࿖ౝᮡḰ㧔JIS X 0836㧕ߣߒߡ߽ቯ߼ࠄࠇߚ‫ޕ‬߹ߚ‫ޔ‬ᣂߚߥᛛⴚ߳ߩኻᔕߣߒߡ‫ߩ߳ࡉࠚ࠙ࠢ࠶ࠖ࠹ࡦࡑ࠮ߦ․ޔ‬ข⚵ߺ߇ㅴߺ‫ޔ‬
Dublin Core ߩ᭎ᔨ⊛ߥ᭴ㅧࠍ␜ߒߚ DCMI Abstract Model㧔DCMI ᛽⽎ࡕ࠺࡞㧕7߇ឭ␜ߐࠇ㧔2005 ᐕ㧕‫ߩߘޔ‬ᓟ‫ޔ‬ᡷ⸓ߒߚࡕ࠺࡞߇౏㐿ߐࠇߚ㧔2007 ᐕ㧕8‫ޕ‬ߎࠇࠄࠍ〯߹߃‫ޔ‬NDL ߢߪ‫ޔ‬࿖ౝᯏ㑐ߦ߅ߌࠆࡔ࠲࠺࡯࠲૞ᚑߩታ〣ࠍⷞ㊁ߦ౉ࠇ‫ޔ‬
2006 ᐕᐲ߆ࠄ NDL ࡔ࠲࠺࡯࠲ߩᡷ⸓૞ᬺߦ⌕ᚻߒ‫ޔ‬2007 ᐕ 5 ᦬ߦ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀⷐ⚛㧔DC-NDL 2007 ᐕ㧕‫౏ࠍޠ‬㐿ߒߚ‫ޕ‬Dublin CoreߦḰ᜚ߔࠆၮᧄᣇ㊎ߪᄌࠊࠄߕ‫ޔ‬ᣣᧄ⺆ߩᖱႎ⾗Ḯߦኻᔕߔࠆߚ߼‫߿࡞࠻ࠗ࠲ޔ‬૞ᚑ⠪ߩ⺒ߺ߿‫ޔ‬࿖ౝߦ߅ߌࠆ⛔೙⺆ᒵ߿⼂೎ሶ╬ߩᮡḰ૕♽ߦ㑐ߔࠆ⺆ᒵࠍ⁛⥄ߦ᜛ᒛߒߚ‫ޕ‬ߘߒߡ‫ޔ‬NDL ౝᄖߩࠪࠬ࠹ࡓߣ࠺࡯࠲ࠍㅪ៤ߔࠆ㓙‫ޔ‬PORTA ߩࡔ࠲࠺࡯࠲ߣߒߡታ
㓙ߦ೑↪ߔࠆߎߣߢ‫ޔ‬࿖ౝߩ࿑ᦠ㙚߿㑐ㅪᯏ㑐ߩ࠺ࠫ࠲࡞ࠕ࡯ࠞࠗࡉ߳ߩᶐㅘࠍ࿑ߞߚ‫ޕ‬
3.3. ࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ㧔DC-NDL 2010 ᐕ 6 ᦬

㧕Dublin Core ߪ⋧੕ㆇ↪ᕈࠍ⠨ᘦߒ‫⺆ޔ‬ᒵߣߒߡၮᧄ 15 ⷐ⚛ࠍቯ߼ߚ߇‫⸥ߩߘޔ‬ㅀ
ᣇᴺߦߟ޿ߡߩ೙⚂ߪ⸳ߌߕ‫ޔ‬㕖Ᏹߦࠪࡦࡊ࡞߆ߟ⥄↱ᐲߩ㜞޿ࡔ࠲࠺࡯࠲߇⸥ㅀߢ߈
ࠆߎߣ߆ࠄᐢߊ᥉෸ߒߚ‫ࡉࠚ࠙ࠢ࠶ࠖ࠹ࡦࡑ࠮ޔߒ߆ߒޕ‬ⅣႺߢߩࠦࡦࡇࡘ࡯࠲ߦࠃࠆ⥄േಣℂߦߪ‫ࠅࠃޔ‬෩ኒߢ♖✺ߥࡔ࠲࠺࡯࠲߇ᔅⷐߣߐࠇࠆ╬ߩℂ↱߆ࠄ‫ޔ‬Dublin Core ߦ߅޿ߡᓢ‫߇ߒ⋥⷗ߦޘ‬࿑ࠄࠇ‫ޔ‬2008 ᐕ 1 ᦬ߦ DCMI Metadata Terms9߇౏⴫ߐࠇߚ‫ޕ‬
DCMI Metadata Terms ߢߪ‫ޔ‬RDF ࠍෳ⠨ߦ࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉߩታ⃻ߦะߌ‫⸥ޔ‬ㅀⷐ⚛ߩ᜛ల߿ᗧ๧ቯ⟵ߩ⷗⋥ߒ‫▸↪૶ޔ‬࿐ߩ᣿⏕ൻ߿᭎ᔨ㑐ଥߩᢛℂ߇ⴕࠊࠇߚ‫ޕ‬ ৻ᣇ‫ޔ‬NDL ߦ߅ߌࠆࡔ࠲࠺࡯࠲ࠍขࠅᏎߊ⁁ᴫ߽ߐࠄߦㅴዷߒߚ‫ޕ‬2009 ᐕ 7 ᦬ߦ࿖┙࿖ળ࿑ᦠ㙚ᴺ߇ᡷᱜߐࠇ‫ޔ‬ᣣᧄ࿖ౝߩ౏⊛ᯏ㑐╬߇৻⥸ߦ౏㐿ߒߡ޿ࠆࠗࡦ࠲࡯ࡀ࠶
࠻ᖱႎߦߟ޿ߡߪ⸵⻌ࠍᓧߕߦ‫ޔ‬෼㓸࡮଻ሽ߇ߢ߈ࠆࠃ߁ߦߥߞߚߎߣࠍฃߌ‫ޔ‬WARP10ߦ߅ߌࠆ࠙ࠚࡉࠨࠗ࠻ߩ෼㓸▸࿐࡮㗫ᐲ߇᜛లߒߚ‫ޔߚ߹ޕ‬ᄢⷙᮨ࠺ࠫ࠲࡞ൻ੐ᬺߩᚑ
ᨐߢ޽ࠆ࠺ࠫ࠲࡞ൻ↹௝ߩࡔ࠲࠺࡯࠲૞ᚑ߿‫࡮⚕ޔ‬㔚ሶᇦ૕ࠍ໧ࠊߕ৻᜝ߒߡᖱႎ⾗Ḯ

http://dublincore.org/documents/abstract-model/㧔ෳᾖ 2013-01-11㧕
ᡷ⸓᩺ߪ 2007 ᐕ 4 ᦬ߦឭ␜ߐࠇ‫ޔ‬6 ᦬ߦ⏕ቯߒߚ‫৻ޕ‬ᣇ‫ޔ‬DC-NDL2007 ᐕ ߪหᐕ 5 ᦬ߦ౏㐿ߒߚߚ߼‫ߩ࡞࠺ࡕߥ⊛⚳ᦨޔ‬෻ᤋߪᰴ࿁ᡷ⸓߳ߩ⺖㗴ߣߒߚ‫ޕ‬
9 http://dublincore.org/documents/dcmi-terms/㧔ෳᾖ 2013-01-11㧕
10 ᱜᑼฬ⒓ߪ‫⾗࠻࠶ࡀ࡯࠲ࡦࠗޟ‬ᢱ෼㓸଻ሽ੐ᬺ㧔࠙ࠚࡉࠨࠗ࠻೎㧕‫ߦޠ‬ᄌᦝ‫ޕ‬7
8

27

෸߮ࡔ࠲࠺࡯࠲ࠍᬌ⚝ߢ߈ࠆᣂࠨ࡯ࡆࠬ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࠨ࡯࠴‫ޠ‬11ߩ㐿⊒ߦኻᔕߔࠆߚ߼‫ޔ‬2009 ᐕ 9 ᦬߆ࠄᄢ᏷ߥᡷ⸓૞ᬺߦ⌕ᚻߒߚ‫ޕ‬ߎߩ㓙‫ޔ‬DC-NDL ߩ․ᓽߩ৻ߟߢ߽޽ࠆ࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉ߳ߩኻᔕࠍᒝൻߒߚ‫ޕ‬
DCMI Metadata Terms ߩ࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉᔒะߣᱠ⺞ࠍ޽ࠊߖ‫ޔ‬DC-NDL ߢ⁛⥄ߦቯ⟵ߒߚ⺆ᒵ߽ࠦࡦࡇࡘ࡯࠲ߢ⸃㉼ߢ߈ࠆࠃ߁ߦ NDL Metadata Terms ߩ RDF
ࠬࠠ࡯ࡑࠍ↪ᗧߒߚ‫ޔߚ߹ޕ‬‫ޟ‬2.3 ⋧੕ㆇ↪ᕈߩะ਄‫ߢޠ‬ㅀߴߚㅢࠅ‫⺆ޔ‬ᒵߩᗧ๧ߩቯ⟵㧔࠮ࡑࡦ࠹ࠖࠢࠬ㧕ߣ⺆ᒵߩ૶↪ᣇᴺ㧔ࠪࡦ࠲࠶ࠢࠬ㧕߇৻૕ߣߥߞߡ޿ߚᓥ᧪ߩ᭴ᚑ
ࠍᡷ߼‫ޔ‬NDL ߢ⁛⥄ߦቯ⟵ߒߚ⺆ᒵ㓸 NDL Metadata Terms ߣ‫ޔ‬Dublin Core ╬ߩᮡḰ⊛ߥ⺆ᒵ෸߮ NDL Metadata Terms ෺ᣇߩ⸥ㅀᣇᴺࠍቯ߼ߚ Application Profileߦಽ㔌ߒߚ‫ߚߒ߁ߎޕ‬᭴ᚑᄌᦝࠍ෻ᤋߒ‫⸥ޔ‬ㅀⷐ⚛એᄖ߽฽߻ߎߣ߆ࠄ‫ޔ‬ᓥ᧪ߩᣣᧄ⺆ฬ⒓‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀⷐ⚛‫ޟࠍޠ‬࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ‫ޕߚߒߣޠ‬3.4. ࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ㧔DC-NDL 2011 ᐕ 12 ᦬
DC-NDL 2010 ᐕ 6 ᦬㧕ߩ౏㐿ᓟ‫ޔ‬หᐕ 10 ᦬ߦ DCMI Metadata Terms ߩዊⷙᮨߥ

ᄌᦝ12߇ⴕࠊࠇߚ‫ޕ‬ዊⷙᮨߣߪ޿߃‫⃻⴫ߩ࡞࠻ࠗ࠲ޔ‬ᣇᴺߩᄌᦝ╬ዋߥ߆ࠄߕ DC-NDLߦ߽ᓇ㗀ࠍ෸߷ߔౝኈߢ޽ߞߚ‫ޟޔߚ߹ޕ‬࿖┙࿖ળ࿑ᦠ㙚ࠨ࡯࠴‫ޔ߽ߡ޿߅ߦޠ‬㐿⊒ߩᚑᨐࠍ〯߹߃‫ߩ࠲࡯࠺࠲ࡔޔ‬ឭଏ╬ߦ㑐ߔࠆߐࠄߥࠆࠨ࡯ࡆࠬలታൻߩߚ߼ߩᯏ⢻᜛ᒛ߳ߩኻᔕ߽ᔅⷐߣߥߞߚ‫ޔ߼ߚߩߘޕ‬Dublin Core ߦḰ᜚ߔࠆၮᧄ⊛ߥᣇ㊎߿᭴ᚑߪᄌᦝߖߕ‫ޔ‬ᣂߚߥ⺆ᒵߩㅊട߿⸥ㅀᣇᴺߩୃᱜ╬ߩߺࠍታᣉߒ‫ޔ‬DC-NDL 2011 ᐕ 12᦬ߣߒߡ౏㐿ߒߚ‫ޕ‬
⴫ 1 ߪ‫ޔ‬Dublin Core ߩേะ෸߮ NDL ߩ㔚ሶ࿑ᦠ㙚ࠨ࡯ࡆࠬߩㅴዷ߆ࠄߺߚ

DC-NDL ߩᄌㆫࠍ߹ߣ߼ߚ߽ߩߢ޽ࠆ‫ޕ‬

1112

http://iss.ndl.go.jp/㧔ෳᾖ 2013-01-11㧕
http://dublincore.org/usage/decisions/2010/dcterms-changes/㧔ෳᾖ 2013-01-11㧕

28⴫ 1 DC-NDL ߩᄌㆫ㧔2013 ᐕ 1 ᦬⃻࿷㧕ᐕDCͲNDL ߣ NDL ߩേะDublinCore ߩേะၮᧄ 15 ⷐ⚛ߩၮᧄ⊛วᗧ

1997 1998 㨬࿖┙࿖ળ࿑ᦠ㙚㔚ሶ࿑ᦠ㙚᭴ᗐ㨭╷ቯ



13



2000 㨬㔚ሶ࿑ᦠ㙚ࠨ࡯ࡆࠬታᣉၮᧄ⸘↹㨭 㨬ࡀ࠶࠻ࡢ࡯
ࠢ♽㔚ሶ಴

14

‛ߦ㑐ߔࠆᜰ㊎㨭 ╷ቯ

2001 NDL ࡔ࠲࠺࡯࠲౏㐿

2002 WARP࡮Dnavi ╬ߩ㔚ሶ࿑ᦠ㙚ࠨ࡯ࡆࠬ౏㐿*࠙ࠚࡉࠨࠗ࠻‫❱⚵ߩࠬ࡯ࡌ࠲࡯࠺ޔ‬ൻ㐿ᆎ࿖㓙ⷙᩰ (ISO15836)

2003 15

2004 㨬࿖┙࿖ળ࿑ᦠ㙚㔚ሶ࿑ᦠ㙚ਛᦼ⸘↹ 2004㨭 ╷ቯ2005 DCMI ᛽⽎ࡕ࠺࡞㧔ផᅑ㧕౏㐿

2006 WARP ᧄᩰ੐ᬺൻDCMES  1.1 ౏㐿2007 DCͲNDL2007 ᐕ

DCMI ᛽⽎ࡕ࠺࡞ᡷ⸓౏㐿

PORTA ౏㐿*ᄙ᭽ߥᇦ૕࡮⒳㘃ߩᖱႎ⾗Ḯߦ㑐ߔࠆࡔ࠲࠺࡯࠲ᮡ

ࠪࡦࠟࡐ࡯࡞ࡈ࡟࡯ࡓࡢ࡯ࠢ
ឭ␜Ḱൻߩᔅⷐᕈ

DCMIMetadataTerms ౏㐿2008 ‫ࠔࡈࡠࡊ࡮ࡦ࡚ࠪ࡯ࠤ࡝ࡊࠕޟ‬ࠗ࡞ߩߚ߼ߩࠪࡦࠟࡐ࡯࡞ࡈ
࡟࡯ࡓࡢ࡯ࠢ‫ޠ‬16౏㐿
2009 ⪺૞ᮭᴺᡷᱜ㧔2010 ᐕ 1 ᦬ᣉⴕ㧕*ේ⾗ᢱ଻ሽߩߚ߼ߩ࠺ࠫ࠲࡞ൻ߇น⢻ߦᄢⷙᮨ࠺ࠫ࠲࡞ൻ੐ᬺߩታᣉ㧔2 ߆ᐕ㧕‫ࠪ࡯ࠤ࡝ࡊࠕ࡮ࠕࠦࡦ࡝ࡉ࠳ޟ‬࡚ࡦ࡮ࡊࡠࡈࠔࠗ࡞ߩߚ߼ߩࠟ
ࠗ࠼࡜ࠗࡦ‫ޠ‬17౏㐿࿖┙࿖ળ࿑ᦠ㙚ᴺᡷᱜ㧔2010 ᐕ 4 ᦬ᣉⴕ㧕*࿖ౝ౏⊛ᯏ㑐╬ߩ࠙ࠚࡉࠨࠗ࠻࡮㔚ሶ㔀⹹╬ࠍ⸵⻌ߥߊ෼㓸࡮଻ሽน⢻ߦ

2010 DCͲNDL2010 ᐕ 6 ᦬౏㐿

DCMI Metadata Terms ዊⷙᮨᡷ‫⾗࠻࠶ࡀ࡯࠲ࡦࠗޟ‬ᢱ෼㓸଻ሽ੐ᬺ‫ޠ‬᜛ల‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࠨ࡯࠴㧔㐿⊒2011 DCͲNDL2011 ᐕ 12 ᦬⸓㧕‫౏ޠ‬㐿

౏㐿18‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚࠺ࠫ࠲࡞ൻ⾗ᢱ‫౏ ޠ‬㐿*࠺ࠫ࠲࡞ൻࠦࡦ࠹ࡦ࠷ߩࡔ࠲࠺࡯࠲ߩᮡḰൻ߇⺖㗴

2012 ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࠨ࡯࠴‫ޠ‬ᱜᑼ౏㐿
*API ߦࠃࠆ DCͲNDL ᒻᑼߩࡔ࠲࠺࡯࠲ឭଏ㐿ᆎ

http://www.ndl.go.jp/jp/aboutus/elib_standardproject.html㧔ෳᾖ 2013-01-11㧕
http://www.ndl.go.jp/jp/aboutus/elib_nw.html㧔ෳᾖ 2013-01-11㧕
15 http://www.ndl.go.jp/jp/aboutus/elib_plan2004.html㧔ෳᾖ 2013-01-11㧕
16 http://dublincore.org/documents/singapore-framework/㧔ෳᾖ 2013-01-11㧕
17 http://dublincore.org/documents/profile-guidelines/㧔ෳᾖ 2013-01-11㧕
18 http://dl.ndl.go.jp/㧔ෳᾖ 2013-01-11㧕
13
14

29

4. ઀⚵ߺ ᧄ┨ߢߪ‫ޔ‬DC-NDL ߩࠬࠠ࡯ࡑ᭴ㅧߦߟ޿ߡ⺑᣿ߔࠆ‫ޕ‬
4.1. ᭎ᔨࡕ࠺࡞
DC-NDL ߩ⺆ᒵߪ‫ޔ‬3 ߟߩࠢ࡜ࠬ‫▤ޟ‬ℂᖱႎ㧔dcndl:BibAdminResource㧕‫ޠ‬‫⹹ᦠޟ‬ᖱ
ႎ㧔dcndl:BibResource㧕‫ޠ‬෸߮‫ޟ‬୘૕ᖱႎ㧔dcndl:Item㧕‫ߦޠ‬ಽ߆ࠇࠆ‫ޕ‬‫▤ޟ‬ℂᖱႎ‫ߪޠ‬ࡔ࠲࠺࡯࠲⥄૕ߦ㑐ߔࠆᖱႎ㧔ࡔ࠲࠺࡯࠲ߩ૞ᚑᣣ߿ᦝᣂᣣ╬㧕‫ޔ‬‫⹹ᦠޟ‬ᖱႎ‫⸥ߪޠ‬ㅀኻ⽎ߩᖱႎ⾗Ḯߦ㑐ߔࠆᖱႎ㧔࠲ࠗ࠻࡞߿૞ᚑ⠪╬㧕‫ޔ‬‫ޟ‬୘૕ᖱႎ‫⸥ߪޠ‬ㅀኻ⽎ࠍᚲ⬿ߔࠆฦᯏ㑐ߩࡠ࡯ࠞ࡞ᖱႎ㧔⺧᳞⸥ภ╬㧕ߦ⹥ᒰߔࠆ‫ޕ‬ฦࠢ࡜ࠬ㑆ߪ㑐ㅪᕈࠍ⴫ࠊߔ⺆ᒵ
㧔dcndl:record㧕ߢ㑐ㅪߠߌࠄࠇߡ޿ࠆ‫ޕ‬
RDF ߪ‫ߩߣߏߩ߽ޔ‬㑐ଥࠍਥ⺆‫ޔ‬ㅀ⺆෸߮⋡⊛⺆ߩ 3 ߟߩⷐ⚛㧔࠻࡝ࡊ࡞㧕ߢ⸥ㅀߒ‫ߺ⚵ࠍ࡞ࡊ࡝࠻ޔ‬วࠊߖࠆߎߣߢ‫ⶄޔ‬㔀ߥ᭴ㅧߩ࠺࡯࠲߽⴫⃻ߢ߈ࠆ‫࠲ࡦࠗޔߚ߹ޕ‬࡯ࡀ࠶࠻਄ߩ࡝࠰࡯ࠬߦ㒢ࠄߕ‫ޔ‬᭎ᔨ‫ޔ‛ੱޔ‬੐⽎╬޽ࠄࠁࠆ߽ߩߦ৻ᗧߩ⼂೎ሶߢ޽ࠆ URI ࠍઃਈߔࠆߎߣߢ‫ߩࠄࠇߎޔ‬㑐ଥࠍ⥄↱ߦ⸥ㅀߒߡ޿ߊߎߣ߇ߢ߈ࠆ‫ޕ‬ ࿑ 1 ߪ RDF ߢ⴫⃻ߒߚ DC-NDL ߩ᭎ᔨࡕ࠺࡞଀ߢ޽ࠆ‫ޕ‬ᢙᄙߩ࠻࡝ࡊ࡞ࠍ❬ߍࠆߎߣߢ‫ޔ‬ฦ࠺࡯࠲㑆ߩ㑐ଥᕈ߇⸥ㅀߢ߈ࠆ઀⚵ߺߣߥߞߡ޿ࠆ‫ޕ‬࿑ 1 DC-NDL ᭎ᔨࡕ࠺࡞㧔ࠗࡔ࡯ࠫ㧕

4.2. ណ↪⺆ᒵ ‫ޟ‬2.3 ⋧੕ㆇ↪ᕈߩะ਄‫ߢޠ‬ㅀߴߚㅢࠅ‫ޔ‬ᣢሽߩ⺆ᒵࠍߢ߈ࠆ㒢ࠅ೑↪ߔࠆࠕࡊ࡝ࠤ
࡯࡚ࠪࡦ࡮ࡊࡠࡈࠔࠗ࡞ߩ⠨߃ᣇߦḰߓ‫ ⴫ޔ‬2 ߩ⺆ᒵࠍណ↪ߒߡ޿ࠆ‫ޕ‬30

⴫ 2 DC-NDL ߢណ↪ߔࠆ⺆ᒵ⺆ᒵDublinCoreMetadataElementSet,

ฬ೨ⓨ㑆

ធ㗡ㄉ

http://purl.org/dc/elements/1.1/dc

DCMIMetadataTerms

http://purl.org/dc/terms/

dcterms

DublinCoreTypeVocabulary

http://purl.org/dc/dcmitype/

dcmitype

FOAFVocabulary

http://xmlns.com/foaf/0.1/foaf

RDFVocabulary

http://www.w3.org/1999/02/22ͲrdfͲsyntaxͲns#

rdf

RDFSchemaVocabulary

http://www.w3.org/2000/01/rdfͲschema#rdfs

OWLWebOntologyLanguage

http://www.w3.org/2002/07/owl#

owl

NDLMetadataTerms

http://ndl.go.jp/dcndl/terms/

dcndl

NDLTypeVocabulary

http://ndl.go.jp/ndltype/

ndltypeVersion1.1

4.3. ࡔ࠲࠺࡯࠲ࡈࠜ࡯ࡑ࠶࠻
ࠪࠬ࠹ࡓߏߣߦౝㇱߢ଻ᜬߔࠆ࠺࡯࠲ᒻᑼ߇⇣ߥߞߡ޿ߡ߽‫↪ޔ‬ㅜ߇ౝㇱಣℂߩߚ߼ߢ޽ࠇ߫‫ߦࡓ࠹ࠬࠪߩߘޔ‬ㆡߒߚᒻᑼߢታⵝߒߡ޿ߡ߽ᡰ㓚ߪߥ޿‫ࠬࠪߩઁޔߒ߆ߒޕ‬࠹ࡓߣ࠺࡯࠲ࠍ੤឵࡮౒᦭ߔࠆ႐ว‫⋧ޔ‬੕ߦᄌ឵น⢻ߥ⺆ᒵ߿࠺࡯࠲ࡕ࠺࡞߇ᔅⷐߦߥ
ࠆ‫ޕ‬ㅪ៤వߩࠪࠬ࠹ࡓߏߣߦࠞࠬ࠲ࡑࠗ࠭ߔࠆߎߣ߽น⢻ߛ߇‫ޔ‬ᄙᢙߩࠪࠬ࠹ࡓߣല₸⊛ߦ߿ࠅߣࠅߔࠆߚ߼ߦߪᮡḰ⊛ߥ࠺࡯࠲ᒻᑼߢ౉಴ജࠍⴕ߁ߎߣ߇ᦸ߹ߒ޿‫ߚߩߘޕ‬߼‫ޔ‬࿑ᦠ㙚߿㑐ㅪᯏ㑐╬߇ࡔ࠲࠺࡯࠲ࠍ੤឵࡮౒᦭ߔࠆߚ߼ߩᮡḰ⊛ߥࡈࠜ࡯ࡑ࠶࠻ߣ
ߒߡ‫ޔ‬DC-NDL(RDF)෸߮ DC-NDL(Simple)ߩ 2 ⒳㘃ࠍቯ⟵ߒߡ޿ࠆ‫ޕ‬DC-NDL(RDF)ߪ‫ޔ‬᭴ㅧൻߐࠇߚ RDF/XML ᒻᑼߢ౉಴ജߢ߈‫࡯࠺࠲ࡔߥ࠴࠶࡝ޔ‬࠲ࠍ૞ᚑ࡮೑↪ߢ߈ࠆ‫৻ޕ‬ᣇ‫ޔ‬DC-NDL(Simple)ߪ‫ޔ‬೑↪㗫ᐲߩ㜞޿ⷐ⚛ߩߺࠍ XML
ᒻᑼߢ౉಴ജߢ߈ࠆࡈࠜ࡯ࡑ࠶࠻ߢ޽ࠆ‫ޕ‬೨⠪ߣᲧセߒߡᖱႎ㊂ߪ㒢ࠄࠇߡ޿ࠆ߇‫ⶄޔ‬㔀ߥ㓏ጀ᭴ㅧࠍᜬߚߕᢥሼㅢࠅࠪࡦࡊ࡞ߥࡈࠜ࡯ࡑ࠶࠻ߢ޽ࠆߚ߼‫ޔ‬RDF ߦኻᔕߢ߈
ߥ޿ࠪࠬ࠹ࡓߢ߽ታⵝߔࠆߎߣ߇ߢ߈ࠆ‫ޕ‬ߎࠇࠄߩࡈࠜ࡯ࡑ࠶࠻ߪ‫ޔ‬ᯏ㑐㑆ߩ࠺࡯࠲੤឵ߛߌߢߥߊ‫ޔ‬೑↪⠪߇⥄↱ߦ࠺࡯࠲ࠍ
❬ߍ‫ޔ‬ᣂߚߥࠨ࡯ࡆࠬߣߒߡ೑ᵴ↪ߔࠆߎߣ߽ߢ߈ࠆ‫ޕ‬

5. ข⚵ߺ
5.1. ⃻࿷ߩข⚵ߺ̆NDL ߢߩណ↪⁁ᴫ̆࿖ౝߩ㑐ㅪᯏ㑐ߩᚲ᦭ߔࠆᄙ᭽ߥᖱႎ⾗Ḯࠍ⛔ว⊛ߦᬌ⚝ߢ߈ࠆ‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ࠨ࡯࠴‫ޔߪߢޠ‬ㅪ៤ᯏ㑐ߣߩࡔ࠲࠺࡯࠲ߩ੤឵↪ࡈࠜ࡯ࡑ࠶࠻ߣߒߡ DC-NDL(RDF)෸
߮ DC-NDL(Simple) ࠍ ታ ⵝ ߒ ߡ ߅ ࠅ ‫ ޔ‬ฦ ᒻ ᑼ ߩ ࡔ ࠲ ࠺ ࡯ ࠲ ࠍ ข ᓧ ߢ ߈ ࠆ API
㧔Application Program Interface㧕߽ឭଏߒߡ޿ࠆ19‫ޕ‬
19

http://iss.ndl.go.jp/information/metadata/㧔ෳᾖ 2013-01-11㧕

31࿑ 2 ߪ‫ޔ‬࿖┙࿖ળ࿑ᦠ㙚ࠨ࡯࠴߆ࠄ಴ജߒߚ DC-NDL(RDF)ᒻᑼߩࡔ࠲࠺࡯࠲଀ߢ
޽ࠆ‫ޟޕ‬4.1 ᭎ᔨࡕ࠺࡞‫ߢޠ‬ㅀߴߚ 3 ࠢ࡜ࠬ߆ࠄᚑࠅ‫ޔ‬᭴ㅧൻߐࠇߚᒻߢ⴫⃻ߐࠇߡ޿ࠆ‫৻ޕ‬ᣇ‫ޔ‬DC-NDL(Simple)ߪ‫ޔ‬RDF ࠍ↪޿ߥ޿ࡈ࡜࠶࠻ߥ XML ߢ⴫⃻ߐࠇߡ޿ࠆ
ߚ߼‫▤ޔ‬ℂᖱႎ෸߮୘૕ᖱႎߩ⸥ㅀߪ฽߹ࠇߡ޿ߥ޿20‫ޕ‬▤ℂᖱႎ
dcndl:BibAdminResourceᦠ⹹ᖱႎdcndl:BibResource୘૕ᖱႎԘ
dcndl:Item୘૕ᖱႎԙ
dcndl:Item࿑ 2 DC-NDL(RDF)ᒻᑼߩࡔ࠲࠺࡯࠲଀

਄⸥એᄖߦ㨬࿖┙࿖ળ࿑ᦠ㙚࠺ࠫ࠲࡞ൻ⾗ᢱ㨭ߢឭଏߔࠆᚲ⬿⾗ᢱߩ࠺ࠫ࠲࡞ൻࠦࡦ
࠹ࡦ࠷㧔↹௝‫ޔ‬㖸Ḯ╬㧕߿ WARP ߢ෼㓸࡮଻ሽߒߡ޿ࠆ࠙ࠚࡉࠨࠗ࠻ߩࡔ࠲࠺࡯࠲ࠬ
ࠠ࡯ࡑߣߒߡ૶↪ߒߡ޿ࠆ߶߆‫ޔ‬‫ޟ‬࿖┙࿖ળ࿑ᦠ㙚ౖ᜚࠺࡯࠲ᬌ⚝࡮ឭଏࠨ࡯ࡆࠬ㧔Web
NDL Authorities㧕‫ޠ‬21ߩౖ᜚࠺࡯࠲ࠍ⸥ㅀߔࠆࡔ࠲࠺࡯࠲ߦ߽৻ㇱ NDL Metadata
Terms ࠍណ↪ߒߡ޿ࠆ‫ޔߚ߹ޕ‬㨬࿖┙࿖ળ࿑ᦠ㙚᧲ᣣᧄᄢ㔡ἴࠕ࡯ࠞࠗࡉ᭴▽ࡊࡠࠫࠚDC-NDL(Simple)ߩ଀ߪ‫ޔ‬ਅ⸥ෳᾖ‫ޕ‬
http://iss.ndl.go.jp/api/oaipmh?verb=GetRecord&metadataPrefix=dcndl_simple&identifier=oai:iss.ndl.go.jp:R100000002-I000011254088-00
21 http://id.ndl.go.jp/auth/ndla㧔ෳᾖ 2013-01-11㧕
20

32

ࠢ࠻㨭22ߢߪ‫ޔ‬࿖ౝᄖߩฦᯏ㑐╬߇෼㓸࡮଻ሽߒߡ޿ࠆ᧲ᣣᧄᄢ㔡ἴߩ⸥㍳࡮ᢎ⸠╬ߩ৻ర⊛ߥᬌ⚝ࠍน⢻ߣߔࠆߚ߼‫ޔ‬ᢥᦠ‫ޔ‬౮⌀‫ޔ‬㖸ჿ෸߮േ↹╬ߩᄙ᭽ߥ㔡ἴߦ㑐ߔࠆᖱႎ⾗Ḯߩߚ߼ߩࡔ࠲࠺࡯࠲ࠬࠠ࡯ࡑࠍ╷ቯߒߡ߅ࠅ‫ ߦࠬ࡯ࡌߩߘޔ‬DC-NDL ࠍขࠅ౉ࠇߡ޿ࠆ‫ޕ‬5.2. ੹ᓟߩข⚵ߺ (1) ̆ࠝࡦ࡜ࠗࡦ⾗ᢱ߳ߩኻᔕ̆
 2012 ᐕ 6 ᦬‫ޔ‬࿖┙࿖ળ࿑ᦠ㙚ᴺߩ৻ㇱ߇ᡷᱜߐࠇ‫ޔ‬᳃㑆ߩ಴ߔࠆࠝࡦ࡜ࠗࡦ⾗ᢱࠍ NDL ߇෼㓸ߒ‫଻ޔ‬ሽߔࠆߎߣ߇น⢻ߣߥߞߚ23‫⾗ࡦࠗ࡜ࡦࠝޕ‬ᢱߣߪ‫ࠆࠁࠊ޿ޔ‬㔚ሶᦠ☋߿㔚ሶ㔀⹹ߦ⋧ᒰߒ‫ޔ‬2013 ᐕ 7 ᦬߆ࠄήఘ߆ߟ DRM㧔ᛛⴚ⊛೙㒢ᚻᲑ㧕ߩߥ޿ࠝࡦ࡜ࠗࡦ⾗ᢱߩ෼㓸߇㐿ᆎߐࠇࠆ‫ౕޕ‬૕⊛ߦߪ‫࠻࠶ࡀ࡯࠲ࡦࠗ߇ੱ⑳ޔ‬਄ߢ౏㐿ߒߚ㔚ሶᦠ☋࡮㔚ሶ㔀⹹ߩ߁ߜ‫․ޔ‬ቯߩࠦ࡯࠼㧔ISBN‫ޔ‬ISSN‫ޔ‬DOI㧕߇ઃਈߐࠇߚ߽ߩ
෶ߪ․ቯߩࡈࠜ࡯ࡑ࠶࠻㧔PDF‫ޔ‬PDF/A‫ޔ‬EPUB‫ޔ‬DAISY㧕ߢ૞ᚑߐࠇߚ߽ߩߩ޿ߕ
ࠇ߆ߦ⹥ᒰߔࠆ߽ߩߢ޽ࠅ‫ޔ‬ᐕ㐓‫ޔⷩⷐޔ‬ᯏ㑐⹹‫⺞ޔ‬ᩏႎ๔ᦠ‫ޔ‬੐ᬺႎ๔ᦠ‫ޔ‬ቇⴚ⺰ᢥ‫ޔ‬♿ⷐ‫ޔ‬ᛛႎ‫ޔ࡯࠲࡟ࠬ࡯ࡘ࠾ޔ‬ዊ⺑‫ޔ‬ታ↪ᦠ‫߇╬ᦠ┬ఽޔ‬᜼ߍࠄࠇࠆ‫ޕ‬ࠝࡦ࡜ࠗࡦ⾗ᢱߩ೙ᐲ⊛෼㓸ߩ㐿ᆎߦࠃࠅ‫ߢ߹ࠇߎޔ‬એ਄ߦ‫⚕ޔ‬ᇦ૕ߣ㔚ሶᇦ૕‫ޔ‬
PDF ߣ EPUB ╬ߩห৻⪺૞24ߢ⇣ߥࠆᇦ૕࡮ࡈࠜ࡯ࡑ࠶࠻ߩᖱႎ⾗Ḯ߇Ⴧടߔࠆߣ⷗
ㄟ߹ࠇࠆ‫ߩࠄࠇߎޕ‬ᖱႎ⾗Ḯࠍ৻ర⊛ߥࡈ࡟࡯ࡓࡢ࡯ࠢ25ߦ߅޿ߡ⴫⃻ߢ߈ࠆࠃ߁ߦߔ
ࠆߣߣ߽ߦ‫ޔ‬ᖱႎ⾗Ḯ㑆ߩ㑐ㅪᕈࠍࡔ࠲࠺࡯࠲ߣߒߡ⸥ㅀߔࠆߎߣ߇㊀ⷐߣߥࠆ‫ޕ‬NDLߢߪ‫ޔ‬DC-NDL ࠍ↪޿ߡ‫ࠆߥ⇣ޔ‬ᇦ૕߿ࡈࠜ࡯ࡑ࠶࠻ߩᖱႎ⾗Ḯࠍห৻⪺૞ߩ߽ߣߦ
㓸߼ࠆࠃ߁ߥ઀⚵ߺࠍ߹ߛታ⃻ߢ߈ߡ޿ߥ޿‫ޔ߼ߚߩߘޕ‬೑↪⠪߇᳞߼ࠆᖱႎ⾗Ḯࠍᄙ᭽ߥᇦ૕࡮ࡈࠜ࡯ࡑ࠶࠻ߩਛ߆ࠄല₸⊛ߦ⼂೎࡮ㆬᛯߢ߈ࠆࠃ߁ߥห৻⪺૞ߩ㓸ਛᯏ⢻ߩዉ౉ࠍᬌ⸛ߔࠆ╬‫ޔ‬ᓟㅀߔࠆ࿖㓙⊛ߥേะࠍ⷗ߥ߇ࠄ੹ᓟߩኻᔕࠍ⠨߃ࠆᔅⷐ߇޽ࠆ‫ޕ‬߹ߚ‫⾗ࡦࠗ࡜ࡦࠝޔ‬ᢱߢߪ‫⾗ޔ‬ᢱߩ૞ᚑ⠪࡮౏㐿⠪⥄り߇ᣢߦࡔ࠲࠺࡯࠲ࠍઃਈߒߡ
޿ࠆ႐ว߿‫ᧄޔ‬ᢥߩ࠹ࠠࠬ࠻ᖱႎࠍ߽ߜ‫ోޔ‬ᢥᬌ⚝߇น⢻ߥ႐ว߽ᄙ޿‫ޔ߼ߚߩߘޕ‬ᖱႎ⾗Ḯߩ⒳೎ࠍ໧ࠊߕߦ৻ర⊛ߦᬌ⚝࡮೑↪ߢ߈‫⾗ࡦࠗ࡜ࡦࠝߟ߆ޔ‬ᢱߩ․ᕈߦᔕߓߚ
⚵❱ൻ߇น⢻ߥࡔ࠲࠺࡯࠲ࠍᬌ⸛ߔࠆߦ޽ߚࠅ‫ߩߘޔ‬૞ᚑන૏߿⸥ㅀߩ☸ᐲߦߟ޿ߡ⇐ᗧߔࠆᔅⷐ߇޽ࠈ߁‫ޕ‬ߎ߁ߒߚ⺖㗴ߩ⸃᳿ߦข⚵߻ߦ޽ߚࠅ‫⋧ޔ‬੕ㆇ↪ᕈߩะ਄ࠍታ⃻ߔࠆߚ߼ߦ⸳⸘ߐࠇ
ߚ DC-NDL ߩၮᧄ⊛ߥᨒ⚵ߺ߿઀⚵ߺߪ᦭ലߢ޽ࠆߣᦼᓙߐࠇࠆ‫ޕ‬
5.3. ੹ᓟߩข⚵ߺ (2) ̆࿖㓙⊛ߥേะ߳ߩኻᔕ̆ ࿑ᦠ㙚ࠦࡒࡘ࠾࠹ࠖߢߪ‫⋧ߦ࠲࡯࠺࠲ࡔޔ‬ᒰߔࠆᦠ⹹࠺࡯࠲ߩᯏ᪾น⺒ᒻᑼߣߒߡ

http://www.ndl.go.jp/jp/311earthquake/disaster_archives/index.html㧔ෳᾖ 2013-01-11㧕
http://www.ndl.go.jp/jp/aboutus/online_data.html㧔ෳᾖ 2013-01-11㧕
24 ᧄⓂߦ߅ߌࠆ‫⪺ޟ‬૞‫⸥⹹ᦠޔߪޠ‬ㅀߩ᭎ᔨࡕ࠺࡞ FRBR ߦ߅ߌࠆ‫⪺ޟ‬૞㧔Work㧕
‫ޠ‬
㧔⍮⊛࡮⧓
ⴚ⊛ഃㅧ‛ߩන૏㧕ߦ⋧ᒰߔࠆ‫ޕ‬
25 ࡔ࠲࠺࡯࠲ߩ⸥ㅀ‫ޔ‬ᵹㅢ෸߮੤឵╬ߩߚ߼ߩኈࠇ‛‫ޕ‬ᨒ⚵ߺ‫ޕ‬
22
23

33

MARC㧔MAchine Readable Cataloging㧕߇ᐢߊ᥉෸ߒߡ޿ࠆ‫ޔߒ߆ߒޕ‬MARC ߪ 1960ᐕઍߩ࠺࡯࠲▤ℂᛛⴚߦၮߠߊߚ߼‫ޔ‬ᛛⴚߩ⊒ዷ߿ᖱႎ⾗Ḯߩ⸥ㅀᣇᴺߩᄌൻߦኻᔕߒ‫ޔ‬ࠃࠅ⃻࿷෸߮੹ᓟߩ࠙ࠚࡉⅣႺߦහߒߚ࠺࡯࠲૞ᚑ࡮੤឵ⅣႺ߳⒖ⴕߔࠆᔅⷐᕈ߇ᓢ‫ޘ‬ߦ⹺⼂ߐࠇᆎ߼ߚ‫ޔߢߎߘޕ‬XML ߿ RDF‫ޔ‬URI ╬ߩ࠮ࡑࡦ࠹ࠖ࠶ࠢ࠙ࠚࡉࠍታ⃻ߔࠆߚ߼ߩᛛⴚࠍ౒ㅢၮ⋚ߣߒ‫ࡉࠚ࠙ޔ‬਄ߦ߅ߌࠆ࿑ᦠ㙚╬߇ᚲ᦭ߔࠆ࠺࡯࠲ߩ㐿᡼ᕈ࡮ౣ೑↪ᕈࠍ㜞߼ࠆߚ߼‫ޔ‬ᣂߚߥࡈ࡟࡯ࡓࡢ࡯ࠢࠍ᭴▽ߔࠆേ߈߇⿠߈ߡ޿ࠆ‫ޕ‬ᶏᄖߢߪ‫ޔ‬☨࿖⼏ળ࿑ᦠ㙚╬߇ਛᔃߣߥࠅ‫ޔ‬MARC ᦧࠊࠆᣂߒ޿ᦠ⹹ࡈ࡟࡯ࡓࡢ࡯ࠢ26ߩ㐿⊒߇ㅴࠎߢ޿ࠆ‫ߚߒ߁ߎޔ߼ߚߩߘޕ‬േะ╬ߦᵈᗧࠍᛄ޿ߟߟ‫ޔ‬ᣣᧄߩ⸒⺆ⅣႺ╬ߦㆡߒߚࡈ
࡟࡯ࡓࡢ࡯ࠢࠍᬌ⸛ߔࠆߦ޽ߚࠅ‫ޔ‬DC-NDL ߩㆡ↪น⢻ᕈࠍ⠨߃ࠆᔅⷐ߽޽ࠆ‫ޕ‬
5.4. ੹ᓟߩข⚵ߺ (3) ̆ߐࠄߦ❬߇ࠆ࠺࡯࠲߳ߩኻᔕ̆
࠙ࠚࡉో૕ߢߪ‫ ߿ࡉࠚ࠙ࠢ࠶ࠖ࠹ࡦࡑ࠮ޔ‬Linked Data ߣ޿ߞߚᛛⴚ࡮᭎ᔨߪߎߩ
ᢙᐕߢᶐㅘߒ‫ߩߘޔ‬೑ᵴ↪ࠍଦㅴߔࠆࠃ߁ߥ᭽‫ߥޘ‬ข⚵ߺ߇ⴕࠊࠇߡ޿ࠆ‫ޕ‬2011 ᐕߦ
ߪ W3C ߩ࿑ᦠ㙚 Linked Data ࠗࡦࠠࡘࡌ࡯࠲ࠣ࡞࡯ࡊ߇ Linked Data ࠍ࿑ᦠ㙚࠺࡯࠲ߦㆡ↪ߔࠆߎߣߩ೑ὐ߿ߘߩᣇᴺ╬ࠍឭ⸒ߔࠆᦨ⚳ႎ๔ᦠࠍೀⴕߒߚ27‫ޔߚ߹ޕ‬࿖ౝߦ߅޿ߡ߽‫ޔ‬ඳ‛㙚࡮⟤ⴚ㙚ߩ࠺࡯࠲߿ቇⴚᖱႎࠍ Linked Data ߣߒߡ౏㐿ߔࠆ
LODAC Project28╬ߩข⚵ߺ߽⷗ࠄࠇࠆࠃ߁ߦߥߞߚ‫ޕ‬ߒ߆ߒ‫ޔ‬࿖ౝߩ࿑ᦠ㙚╬ߦ߅ߌࠆታ㓙ߩㆡ↪⁁ᴫࠍ⷗ߡߺࠆߣ‫ޔ‬Linked Data ࠍᵴ↪
ߒߡ࠺࡯࠲߇❬߇ࠅ޽ߞߡ޿ࠆߣ޿߁ࠃࠅߪ‫ޔ‬OAI-PMH ╬ߩ࠙ࠚࡉ API ࠍਛᔃߣߒ
ߚࡔ࠲࠺࡯࠲ㅪ៤߇ㅴዷߒߡ޿ࠆᲑ㓏ߢ޽ࠆ‫੹ޕ‬ᓟ‫ ߿ࡉࠚ࠙ࠢ࠶ࠖ࠹ࡦࡑ࠮ޔ‬Linked
Data ߇ߐࠄߦ᥉෸ߒ‫ޔ‬ฦᯏ㑐߇ RDF ߿ URI ╬ߩᮡḰߦၮߠ߈‫౏ߩ࠲࡯࠺ޔ‬㐿࡮౒᦭ࠍㅴ߼ࠆߎߣ߇ߢ߈ࠇ߫‫࠲࡯࠺ޔ‬㑆ߩ㑐ଥᕈࠍߐࠄߦ᭴▽ߢ߈‫৻ޔ‬ᱠㅴࠎߛ࠺࡯࠲ߩ❬߇ࠅࠍታ⃻ߢ߈ࠆ‫ޔࠅࠃߦࠇߎޕ‬ฦᯏ㑐߇ᚲ᦭ߔࠆᖱႎ⾗Ḯߩ࠙ࠚࡉ਄ߦ߅ߌࠆนⷞᕈ
߿೑↪น⢻ᕈ߇ߐࠄߦะ਄ߔࠆߎߣ߽ᦼᓙߐࠇࠆ‫ޕ‬ߎ߁ߒߚ࠺࡯࠲ߩ❬߇ࠅࠍታ⃻ߔࠆ‫ߩޠࡉࡂޟ‬ᓎഀࠍᨐߚߖࠆࡔ࠲࠺࡯࠲ᮡḰߣߒߡ‫ޔ‬੹ᓟ߽ DC-NDL ߩ⛽ᜬ▤ℂߦദ߼ߡ޿߈ߚ޿‫ޕ‬

http://www.loc.gov/marc/transition/㧔ෳᾖ 2013-01-11㧕
http://www.w3.org/2005/Incubator/lld/XGR-lld-20111025/㧔ෳᾖ 2013-01-11㧕ᣣᧄ⺆⸶㧦http://www.ndl.go.jp/jp/aboutus/standards/translation/XGR-lld-20111025.html㧔ෳᾖ 2013-01-11㧕
28 http://lod.ac/㧔ෳᾖ 2013-01-11㧕
26
27

34

ෳ⠨ᢥ₂
[1] “࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ㧔DC-NDL㧕”.
http://www.ndl.go.jp/jp/aboutus/standards/meta.html, (ෳᾖ 2013-01-11).
[2] “࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ㧔DC-NDL㧕⸃⺑”.
http://www.ndl.go.jp/jp/aboutus/standards/meta/about_dcndl.html,(ෳᾖ 2013-01-11).
[3] “࿖┙࿖ળ࿑ᦠ㙚࠳ࡉ࡝ࡦࠦࠕࡔ࠲࠺࡯࠲⸥ㅀ㧔DC-NDL㧕ታ଀㓸”.
http://www.ndl.go.jp/jp/aboutus/standards/meta/dcndl_examples.html,(ෳᾖ 2013-01-11).

35

PageRank と学術論文の評価: ノーベル賞の窓を探そう

藤田裕二（(株)ターンストーンリサーチ, 日本大学）
yuji@turnstone.jp

1. はじめに
近年, 情報通信技術の発展に伴って, 利用可能なデータが急速に増大したことにより, データ処理の新たな手法が続々と考案されつつある. その多くは, 確率論を応用したものである. これらの手法は古典的な意味での「アルゴリズム」とは違って, 常に正しい(あるいは望ましい)結果をもたらすことは必ずしも保証されていないが, 古典的なアルゴリズムを用いると現実的なコストでは解決不可能な課題について, ほぼ望ましい動作をする.
そのようなアルゴリズムのなかに, 大手検索サービス Google search で利用されてきた PageRank がある. PageRank はウェブサイトのコンテンツの重要度を, リンク関係に基づいて統計的に評価するアルゴリズムであり, その的確な動作と頑健性は初期の Google 社の発展の有力な原動力となったと言われている.

2. PageRank アルゴリズム紹介
PageRank アルゴリズム自体の解説は馬場肇氏による下記のサイトが直観的かつ正確である.
http://homepage2.nifty.com/baba̲hajime/wais/pagerank.html
馬場氏によると PageRank は、 「多くの良質なページからリンクされているペー
ジは、やはり良質なページである」 という再帰的な関係をもとに、全てのページの重要度を判定したものである。
このアイデアをウェブサイトにせよ他のコンテンツにせよ, 実際に使おうとするな
らばいくつか問題がある.
最初の問題は, ある文書から引用される別の文書が, 他の文書を引用し… という関係が出発点の文書まで巡っている場合は, このループ内部のコンテンツをどうやって評価すればいいのか? ということである. ある文書の重要度が変化すれば, その効果が巡り巡って自分の重要度を変化させてしまい, それが再び伝播して… などとのんび
りやっていたのでは永遠に決着しない. 重要度の定義が再帰的な構成となっているの36

である. さらに言えば, ループ内部の文書のスコアが決まらないことには, これが引用している他の文書のスコアも決まらない.
じつはこの問題は物理学のなかで有限状態マルコフ過程の定常分布として既に解決されており, 理論的な回答が存在する.
引用関係にもとづいて, 文書 i から j に読者が移動する確率 p̲ji を j 行 i 列に収容した行列 M の最大固有値に対応する固有ベクトルが, 各文書に読者が滞在する
最終的な確率を与える. すなわちベクトルの値が各文書の重要さである.
しかし, その回答をそのまま文書間引用ネットワークに適用するにはいくつか障害があり, これをシンプルかつ実用的な手法で解決した事が, Page, Larry の, ネットワ
ーク科学の理論における主要な貢献の一つである.

3. 学術論文評価への応用と画期的業績の特定
PageRank の発想は, 他のテーマにも自然に応用できる. web contents におけるリンク関係は, そもそもは学術論文における引用関係にその発想の源泉をだどることができるので, たとえば重要な学術論文のなかで引用された業績は重要である, としてこのアルゴリズムを応用する事は自然である.

現状, 被引用数あるいはそれに基づくインパクトファクタなどで研究業績を評価する事が主流であるが, web

検索の歴史を学術論文の評価がなぞるとすれば, PageRank はより頑健で信頼できる評価であると期待されるので, この発想に基づく先行研究が複数存在する.
これらの研究によると, 被引用数に比較して高い PageRank をもつ業績は, 数多くの重要な論文の生みの親という役割をもっていることを示す指標であり,そのいくつかは実際にノーベル賞の受賞などにつながり, 画期的なものとして評価されている.

4. 実装上の問題
多数の node 間の遷移確率を保持する巨大な行列を, そのままメモリに格納することは不可能であり, 非効率的でもある. ただし行列の大部分の値は 0 であるから, そのような疎行列を圧縮して処理するためのアルゴリズムが複数存在し, いくつかはライ
ブラリとして利用可能である.
PageRank アルゴリズムはいくつかの変数をとって, その振る舞いを変化させるが,特にこれを学術論文の評価に用いる場合は, 遷移確率の減衰率に加えて発表年度の補正として適用する陳腐化率とでもいうべきパラメタが新たに加わる. これら二つのパ
ラメタの最適値を求める作業は, PageRank 自体の計算のコストが小さくないだけに,

37

相当の労力が必要である. また, この陳腐化率はテーマや分野によって異なるので, 実
用上の見地から適切な値を算出する方法の考案が待たれるところである.

5. スパム問題とアルゴリズムの限界
PageRank アルゴリズムはかなり頑健であり, データの間に存在する意味内容から生じる構造をたくみに捕捉することができることがこれまでの経験で知られているが,悪用しようとすれば弱点が無いわけではない. 中古車市場の研究にもあるように, 安
物を高く売りたいのは普遍的な欲求である. たとえば通信販売のサイトを持っていたとして, 手間暇をかけずに自分のサイトのスコアを向上させることができれば, 低い
コストで高い宣伝効果を得ることができる. そのために必要なのは, 他サイトからの多数の(無意味な)リンクである. そのようなサイトは, 迷惑メール "スパム" の類似物として "ウェブスパム" と呼ばれており, 大手検索サービスでは様々な対策を迫られている. 同様の問題は学術誌においても存在し, 掲載に際して系列雑誌の, しかも必ずしも本質的でない論文を引用することを求められる事例が知られている. これはPageRank アルゴリズムへの攻撃を意図したものではないが, やはり PageRank の集計結果に悪影響を及ぼす.
また, 文献 3 がその最後で指摘しているとおり, これらの指標は, 人気のあるもの
がさらに人気を集める, という側面がある事に常に注意を払って利用する必要がある.
結局のところ, コンテンツの価値はそれが担う意味内容に存在し, たった一つの数値が学術的内容の精査の完全な代替となることは, 到底ありえないからだ.

参考文献
1. Page, L., Brin, S., "The PageRank Citation Ranking: Bringing Order to the Web"
2. Maslov, S., Redner, S. "Promise and Pitfalls of Extending Googleʼs PageRank
Algorithm to Citation Networks"
3. Chen, P, Xie, H., Maslov, S., Redner, S.,"Finding Scientific Gems with Google"

4. 馬場肇 "Google の秘密 - PageRank 徹底解説"(http://homepage2.nifty.com/baba̲hajime/wais/pagerank.html)

38

すべてをコンピュータの中に（繋がってしまったデータとその未来）
発行日: 2013年2月16日
発行者: 全国共同利用・共同研究拠点「人文学諸領域の複合的共同研究
国際拠点」
住所: 〒606-8501 京都大学人文科学研究所
印刷: