Library and Information Science

A. 研究背景

図書館目録の作成にかかわる目録規則等は，1990年代以降大きな見直しが行われた。こうした見直しは，従来からの冊子等を中心とする情報資源とそのメタデータ作成・流通などを含めた情報環境から，デジタルな情報資源および情報環境への移行を意図している。現在では，目録のメタデータをウェブでの活用や展開，特に他のデータ/メタデータとの接続などが容易なRDF（Resource Description Framework）による機械可読データとして流通させることも目指されている。

このような見直しの結果生まれた記述規則に日本目録規則2018年版（以下，NCR2018またはNCR）^1）がある。この記述規則は，現在，冊子体およびPDFファイルの形で刊行されている。書誌レコードの機能要件（FRBR）等の明確な概念モデルへの依拠，資料の内容的側面と物理的側面の整理，意味的側面と構文的側面の分離，RDAとの相互運用性の担保など，多くの特徴を備えている。それゆえ，従来の1987年版（NCR1987）と比べ内容や構成が大きく異なる。国立国会図書館（NDL）は2021年1月から，独自の適用細則を策定した上で国内刊行資料に対してNCR2018の適用を開始している。大学図書館によるNCR2018の採用例も見られるが，その数は限られている。他の大手MARCレコード作成機関は，採用を検討中である。多くの機関による採用と適用レコードの公開・提供などによって，今後，NCR2018が日本で標準的に用いられる記述規則となることが期待される。

NCR2018を策定した日本図書館協会目録委員会は，冊子体およびPDFファイルでのNCR2018の刊行と並行して，2019年3月より機械可読形式であるExcelファイル等によってNCR2018語彙，すなわち実体，エレメント，関連指示子，値リストの用語などの定義情報を公開している^2）。2020年末には，これに加えてRDF形式の語彙定義データ，具体的には実体と値リストの用語を表すRDFクラス，およびエレメントと関連指示子を示すRDFプロパティの定義データを公開している。次の段階ではこれらRDFクラスとプロパティを用いたメタデータ，すなわち具体的な資料に対する実例としてのメタデータを公開していくことが期待される。これらは，NCR2018に依拠したメタデータをリンクトデータ化する取り組みの一歩と位置づけられる。

一方，準国際標準の地位を獲得しつつある記述規則にRDA（Resource Description and Access）がある。RDAは2010年の刊行後も改訂作業が継続されている。2019年には，依拠する概念モデルをIFLA図書館参照モデル（IFLA LRM）に変更するなど，各種の変更を導入した3Rプロジェクトと呼ばれる改訂作業が完了し，2020年末にRDA Toolkitにおいて変更後のものが正式版RDAへと位置づけられている^3）。こうした改訂の結果，以前のRDAとは大きく構成が異なり，もはや章を分けて，その下を細分化していくという規則構成ではなく，また個別規定を指す条項番号も廃止されている^4）。代わって，エレメント単位で規定群を構成し，これに各種のガイドラインを組み合わせて参照する構成としている。また，関連指示子という種別はなくなり，エレメントに一本化されている。これらゆえ，当時のRDAに準拠して策定されたNCR2018とは大きく異なる様相をもつものとなっている。なお，上記の3Rプロジェクトの進行と並行して，改訂後のRDA語彙（RDAエレメントや値リストの用語など）のRDF定義データはRDA Registryにおいていち早く公開されてきている^5）。

B. 研究目的とRDFデータ化の基本的な考え方

本研究の目的は，記述規則であるNCR2018の機械可読データ化，特にRDFを用いたデータ化を意図し，そのための検討事項およびその選択肢を提示し，併せて適切な選択肢を同定することである。加えて，NCR2018の複数の章について実際にRDFデータ化を試行し，その妥当性の確認を試みる。さらに，RDFデータ化したNCR規定の1つの活用可能性を探るため，NCR規定とそれを適用して作成されたメタデータとを接続する手法を検討する。

RDFデータ化に当たっての基本的な考え方は，目録委員会が公開したNCR2018語彙のRDF定義データにそのまま接続し相互に参照できること，NCR2018内の多様な参照関係を柔軟に辿れるようにすること，個別規定とそれを適用して作成されたメタデータとを接続できることとした。ただし，RDFデータ化したNCR規定群の使用目的や活用法を限定する意図はなく，多様な活用を想定するリンクトデータとしての作成が主目的である。それゆえ，本研究の範囲では，特定目的をもつアプリケーションの開発を意図していない。

RDFデータとするには大きく2つの方向性が考えられる。1つは元データがもつ構成や内容を十分に表現できるよう，その表現や定義に使用するRDFプロパティやクラスを基本的に独自で定義する方向性であり，もう1つは外部で公開された汎用性の高いプロパティやクラスをできる限り採用する方向性である。相互運用性の観点からは後者が望ましいといえるが，その反面，データの意味表現の点では限界が生じる。本研究では基本的に前者を採用する。必要性が発生した時点で，独自定義のプロパティとクラスから外部語彙へのマッピングを定義し，それら外部語彙を適用したRDFデータに変換するという対処とする。

また，多様な活用法に適したRDFデータとするため，NCR2018の規定群に対して形式上の一部変更も許容するという立場で検討する。NCR2018自体の忠実な機械可読データ化を志向するのであれば，XMLによるマークアップ方式が適切と考えられるが，本研究では他の多様なデータとの接続可能性を重視し，敢えてRDFを採用した。一般に，RDFデータは，a）その表現単位（URI付与単位）での自立的な扱いが可能となる，b）RDFモデルによる構造は単純な「主語–述語–目的語」というトリプルによる表現となるなどの特徴をもつ。それに対して，XMLによるデータ化は，a）当該文書データの中で基本的に完結するよう意図され，全体とその部分という包含した構成を想定する，b）文書内の複雑な構成，特に「複合記述」が許容される。この複合記述とは，タグ付けされたテキスト内に出現する語句等にさらにタグ付けし，他の箇所への参照を指示するなどの混合データを認めるものである^6）。

C. 研究対象と先行研究

本研究ではNCR2018に対象を限定する。他の目録規則であるRDAやNCR1987などを対象に加えることも可能ではあるが，それぞれにおいて規則構造などに相違があり，検討や議論が複雑となるため，本研究ではNCR2018に限定する。

本研究の直接的な先行研究に当たるメタデータ作成用の記述規則，特にその本体である規定群をRDFにより機械可読データ化した研究はこれまでに行われておらず，本研究が初めての試みとなる。記述規則に関わるRDFデータ化の試みは，これまでのところ記述規則が扱うデータ項目（エレメントなど）や記述規則に出現する用語等をRDFで定義した語彙の開発にとどまるものであった。RDA, ISBD, NCR2018などの語彙はRDFデータ化され既に公開されているが，それら定義データの活用はあまり進んでいるとはいえない。本研究は，こうした語彙データ活用の可能性を検討する試みとしても位置づけられる。

他方，本研究が取り上げる記述規則と同様に一定の構造をもつ規則の代表例に法令がある。法令の機械可読データ化・RDFデータ化には様々な取組がみられ，大まかには以下の3つの流れにまとめることができる。

①XMLデータ化：法令の機械可読データ化として以前から取り組まれてきたのは，XMLの適用である。XMLは，複雑な構成をもつ法令自体をそのまま忠実に機械可読データとして表現するのに適している。XMLを適用するためには，元の文書構造を反映したマークアップに必要なXML要素や属性とその順序からなるXMLスキーマ（またはXMLマークアップ用のタグセットとも呼ばれる）を定める必要がある。個別の法令ごとにXMLスキーマを定め適用するよりも，共通のスキーマを定め適用することがデータ交換や活用などにおいて利点が多いため，そうした方向で展開している。わが国では，各府省が法制執務業務支援システム（e-LAWS）にて確認した法令データが総務省の「e-Gov法令検索」によって公開されている。さらに，同サイトからは「法令標準XMLスキーマ」^7）8）を適用してマークアップされた各法令データが取得できる。法令の規定本文は，基本的にChapter（章）–Section（節）–Article（条）–Paragraph（項）–ParagraphSentence（項文）やItem（号）–ItemSentence（号文）というXML要素によりマークアップされ，構造表現されている。また，国際的に共通するXMLスキーマの開発例には国連経済社会局によるAkoma Ntosoがあり，広く法令・議会文書の全文をマークアップするスキーマを提供している^9）10）。

②法令オントロジーの開発：法令の規定内容を論理・形式表現に変換し，法令構造の解析と整合性の検証，推論による法令適用結果の予測などに向けたオントロジーの開発という研究がある^{11）12）13）}。オントロジーとしての語彙（概念）の設定粒度やその表現方法は目的に依存して多様である。ここにおいてXMLやRDF, OWL（Web Ontology Language）やRIF（Rule Interchange Format），SWRL（Semantic Web Rule Language）が採用される場合も多い。論理式による法令の規定内容表現や深い知識表現を意図しており，元々の法令条項等の表現からは大きく乖離する結果となる。

③RDFを適用した法令リンクトデータ：法令を含めた法情報の共有と利用を促進する方策としてリンクトデータの推進がある。日本の法令を対象とした事例には，富士通研究所が開発した「日本の法令LOD」^14）がある。これは総務省により一般公開されている法令を対象にRDFデータ化を試みたものであり，開発されたRDFデータはオープンデータとして公開されている。法令における規定文は，「法令標準XMLスキーマ」に沿って導入したRDFクラスArticle（条）–Paragraph（項）–Item（号）–Sentence（文）などを適用し構造表現されている。他には，法令の制定・改正・廃止などの法令沿革の表現に限定したRDFデータを設計する研究などもある^15）16）。諸外国においても，同様に法令のリンクトデータ化に向けた取り組みや研究が行われている^17）18）。

こうした法令のRDFデータ化・リンクトデータ化は，おおむね法令特有の構造を反映し忠実に表現することを意図しているため複雑な語彙と構造となる。それに対して，本研究が対象とする記述規則は比較的単純な構成である。加えて，本研究ではデータ利活用の容易性・展開可能性を優先し，規則の忠実な再現を意図していない。こうした点において，法令に対するRDFデータ化の試みは先行事例として参考になるが，そのまま依拠できるわけではない。

A. NCR2018規則構造とNCR2018語彙定義

NCR2018の規則構造は，全体がトップダウンの体系を取っている。「第1部総説」に続けて，「第2部属性」と「第3部関連」の各部は章ごとの構成，例えば第2部は「第1章属性総則」，「第2章体現形」，「第3章個別資料」などからなる。そして「第2章体現形」は，「#2.0通則」，「#2.1タイトル」，「#2.2責任表示」などの個別エレメントにかかわる複数の条項から構成され，さらに「#2.1タイトル」は「#2.1.0通則」，「#2.1.1本タイトル」，「#2.1.2並列タイトル」など，下位の条項から構成される。なお，これら下位条項の多くは，エレメント・サブタイプまたはサブエレメントを扱っている。そして，さらに「#2.1.1本タイトル」の下位に，「#2.1.1.1記録の範囲・情報源」，「#2.1.1.1.1記録の範囲」，「#2.1.1.1.2情報源」，「#2.1.1.2記録の方法」，「#2.1.1.2.1別タイトル」，「#2.1.1.2.1別タイトル別法」などの複数の条項が設けられている。このようにNCR2018の条項間には，階層的な関係が設定されている。個々の条項は，その条項番号（「#」が先導する番号）の下で，条項見出しと規定内容文から構成されており，他の条項への参照や例示がこれに加わる場合もある。

他方，目録委員会により公開されているNCR2018語彙は，エレメントや関連指示子を示すRDFプロパティ，実体と値リストの用語を表すRDFクラスからなる。エレメントを表すRDFプロパティには，ラベル，定義，定義域などが定義情報として示されている。第1図にエレメント「本タイトル」のRDF定義データをTurtle形式で示す。本タイトルがRDFプロパティであること，それがエレメント・サブタイプであり，上位プロパティが「タイトル」であることなどが示されている。ちなみに，エレメント等のRDF定義にも複数の考え方があり，目録委員会が選択したのはそのうちの1つの方式である。これはRDAにおけるエレメント等のRDF定義と共通する部分もあれば，相違する部分もある。NCR2018語彙のRDF定義の諸問題については別稿で検討している^19）。

第1図 NCR2018語彙のRDFデータ例：本タイトル

RDFのトリプルデータとして，NCR2018語彙のエレメント^20）や関連指示子の定義データから，対応するNCR2018の規定を直接参照するには，エレメントのURIを主語リソース，NCR規定を表すURIを目的語リソースとして，これらを適切なプロパティで結びつけることになる。第1図のRDFデータにこうしたトリプルを追加するとしたときには，仮のプロパティ「:ncrInstrct」（NCR規定への参照）を導入して，対応する規定への参照を下記のように示すことになる。

<http://jla.or.jp/term/ncr2018/E200002>:ncrInstrct :Ncr2.1.1.

NCR規定を表すURIリソースを，RDFクラス（NCR規定クラス）とするか，プロパティ（NCR規定プロパティ）とするかという選択肢がある。この選択肢にかかる検討は次節以降で展開するが，そのクラス/プロパティの設定粒度，加えてそれらを目的語リソースとして導くプロパティ，すなわちエレメントを主語リソースとするプロパティの設定粒度は複数考えられる。こうした設定粒度に応じて，単一エレメントから参照する規定クラス/プロパティの個数およびこれらを導くプロパティの種類数も変化する。前掲のトリプルデータ例は，あくまでも可能な選択肢のうちの1つとなる。

B. 記述規定をRDFクラスとする場合

まず，NCR2018の規定をRDFクラスとして設定し表現する選択肢を検討する。この場合，RDFクラスを設定する粒度を決める必要があり，エレメント単位，条項番号単位，条項内最小単位という3種類の単位が候補となる。なお，本研究では，NCR2018の最上位レベルの全体構成である「部」と「章」からの構成などをRDFによって表現することは意図しない。あくまでも，個々の章内の個別規定を表現するにとどめる。

1. エレメント単位のクラス設定

URIを付与する単位をNCRエレメントに対応する記述規定群とする方式である。エレメントからの参照もこの単位となる。エレメント「タイトル」に対応するのがNCR規定「#2.1タイトル」のクラス，「本タイトル」に対応するのが規定「#2.1.1本タイトル」のクラス，「並列タイトル」に対応するのが「#2.1.2並列タイトル」のクラスとなる。このとき，それぞれの下位規定（#2.1.1に対する#2.1.1.1，#2.1.1.1.1など）にはURIが付与されない。つまり，識別と参照の単位となるURIは，エレメントのレベルでの付与となる。

第2図に，「#2.1.1本タイトル」を規定クラスとしたときのRDFデータを示す（クラスのURI「:Ncr2.1.1」は仮のもの）。RDFトリプル「:Ncr2.1.1 rdf:type :NcrInstruction.」によって，主語リソースがNCRの規定クラス（「:NcrInstruction rdf:type rdfs:Class.」）であることを表現している。プロパティ「:instrctFor」と「:instruction」は本研究で独自に定義したもので，前者はこの規定クラスを適用するエレメント，後者は規定文を示す。この単位設定の場合には，規定文として#2.1.1.1，#2.1.1.1.1などの#2.1.1の下位規定をすべてここに並べることになる。

第2図 記述規定をRDFクラスとした場合のRDFデータ例：エレメント単位

下位規定を単に並べるのではなく，構造化して表現するために空白ノードを導入する手法が考えられる。当該規定クラスを主語リソースとするRDFデータにおいて空白ノードを導入し，構造化した表現とすることで下位規定を区分することはできる。ただし，URIによって下位レベルの識別や参照はできず，あくまでも人間向けの可読性を意図した構造化にとどまる。

このようにエレメント単位の規定クラス設定では，各規定クラスが多数のトリプルデータから構成される。それゆえ，NCR2018内の多様な参照関係を柔軟に辿れるようにするなど，想定する活用法には適さない。同様に，エレメントの下で「記録の範囲」，「記録の情報源」，「記録の方法」などの区分ごとに分けてURIを付与する方式もあるが，基本的な構図や制約はエレメント単位の場合と同じとなる。

2. 条項番号単位のクラス設定

「#2.1」や「#2.1.1.1.2」などのNCRの条項番号が付与されている単位ごとにURIを付与しクラスとする方式である。これにより，「#2.1タイトル」，「#2.1.1本タイトル」，「#2.1.1.1記録の範囲・情報源」，「#2.1.1.1.1」，「#2.1.1.1.2」などは，それぞれが独立した規定クラスとなる。条項「#2.1.1本タイトル」のRDFデータを第3図に示した。NCRの条項番号に対応するクラスを「:Ncr2.1.1」，「:Ncr2.1.1.1」などのURIで表している。規定クラス「:Ncr2.1.1」の下位に位置づけられている「:Ncr2.1.1.1」や「:Ncr2.1.1.2」などのクラスにはプロパティ「:lower」によるリンク，逆に上位に位置づけられるクラス「:Ncr2.1」には「:upper」によるリンクを形成している。

第3図 記述規定をRDFクラスとした場合のRDFデータ例：条項番号単位

このクラス設定では，条項内の規定文をいかに表現するかが併せて問題となる。これには，条項内の規定文を単一リテラル値（プロパティ「:instruction」の目的語リソース）とするか，段落などの最小の要素ごとに区分し，それぞれを独立した値とする（「:instruction」を複数回繰り返す）か，あるいは空白ノードを導入して構造化して表すといった選択肢がある。ただし，これらはいずれも独立したURIをもたないため識別や参照の単位とはならず，人間による可読性を高めるのみである。併せて，エレメントを主語リソースとするプロパティの設定についても，単一のプロパティ（「:instruction」）とするか，「記録の範囲・情報源」，「記録の方法」などを区別する複数種のプロパティとするのかという選択肢があるが，複数種に区分しても大幅な利点増加とは考えられない。

また，第1図に示したエレメントの定義データからの参照先をどこに設定するかを決める必要がある。この点については，エレメントに対応する最上位規定クラスのみにリンクさせる（例：エレメント「本タイトル」に対して「:Ncr2.1.1」）のか，あるいは当該エレメントに対するすべての規定クラス（例：「:Ncr2.1.1.1」，「:Ncr2.1.1.1.1」などすべて）を列記してリンクさせるのかが選択肢となる。前述したように，条項番号単位の直上位と直下位の規定はプロパティ「:upper」と「:lower」によってリンクさせていることも踏まえて，エレメントの定義データからのリンク先を検討することになる。

こうした条項番号単位のクラス設定とすることによって，NCR内の規定間の階層関係および参照関係を適切に表現できるようになる（この点の詳細については，次章で論じる）。そのため，RDFデータとしての活用を広く意図するならば，少なくともこの粒度でのクラス設定が求められる。

3. 条項内最小単位のクラス設定

NCRの規定には，単一条項内がさらにa, b, cなどの記号をもって細分され，これらの区分単位も条項番号に準じるものとして，他の規定から参照されているものがある（例：「（参照：#2.1.1.2.8b）を見よ。）」など）。こうした条項内での細分を重視する場合，細分された条項内最小単位でクラスを設定する方式が考えられる。この場合のURIは，それぞれ元の区分に採用されている記号（a, b, cなど）を組み合わせて構成する。例えば，「#2.1.1.2.2本タイトル　上部または前方の語句」は，意味的に独立して扱えるa, b, cという3つの下位区分をもっており，それぞれを独立したURI「:Ncr2.1.1.2.2a」，「:Ncr2.1.1.2.2b」などとする。ただし，条項内のa, b, cといった区分が当該部分の独立性を表してはいない場合，つまり個々の部分が独立して適用できるものではない場合もあり，機械的には判定できない。例えば，「#2.0.2.2.1A体現形の優先情報源　有形の電子資料，マイクロ資料」では，a, b, cという区分が優先情報源の選定順位を表しているにすぎず，個々の部分が独立して適用できるものではない。

他方，a, b, cという明示的な下位区分を設けていないが，単一条項が意味的に独立した複数の部分から構成される場合がある。場合によっては，a, b, cなどで区分されている規定においても，その個々の区分下でさらに複数部分に細分できる条項もある。これらの場合に，規定として自立して扱える最小単位ごとにURIを付与しクラスとする方式が考えられる。情報資源のメタデータと実際に適用されたNCR規定部分とを相互に参照できるようにするなど，RDFデータとしてより展開したレベルで表現かつ参照できることを意図するならば，こうした最小単位でのURI付与とする意義があるものと考える。

例えば，本タイトルに関わる規定「#2.1.1.2.4併記された語句」は，規定文“同義語による別の表現，原語形とその略語，外来語とその原語などが，タイトルに併記されている場合は，情報源での表示順序，…”があり，それに続けて参照と例示が示され，その後さらに別の規定文“情報源でタイトル全体が，複数の言語および（または）文字種で併記されている場合も，情報源での表示順序，配置，デザイン等に基づいて本タイトルを選定する。…”とそれに伴う参照が記載されている。この規定は前半と後半がそれぞれ自立して解釈され適用できるため，RDFデータ化において2つの最小単位に細分することが，データとしての応用可能性を広げると考える。第4図では，条項単位の規定クラス「:Ncr2.1.1.2.4」とは別に，最小単位クラス「:Ncr2.1.1.2.4-1」と「:Ncr2.1.1.2.4-2」とを設けている。単一条項を細分した場合にも，条項単位のURIを併せて設定する必要があり，それは他の規定からこの条項への参照（条項単位の参照）がありうるからである。条項内最小単位のクラス設定にかかわるその他の事項は，次章において取り上げる。

第4図 記述規定をRDFクラスとした場合のRDFデータ例：条項内最小単位

C. 記述規定をRDFプロパティとする場合

続いて，NCR2018の規定をRDFプロパティとする選択肢を検討する。仮に条項番号単位のプロパティとした場合のRDFデータは，前述した条項番号単位のクラス設定とおおむね同じとなる（第5図）。ただし，プロパティであることが明示される（rdf:Property）。プロパティの設定粒度についても複数の選択肢がある点はクラスとした場合と同じである。以下に，プロパティとすることに特有の検討事項を2つ取り上げる。

第5図 記述規定をRDFプロパティとした場合のRDFデータ例：条項番号単位

まず，当該プロパティの主語リソースをどのように設定するかが問題となる。これには，以下の2つの方式が考えられる。

方式1-1：主語リソースはプロパティであるNCRエレメントとする。この場合，規定プロパティはエレメントに対する説明や補足を導くものとなる。NCR規定がエレメントに対する説明という点では適切であるが，一方，それら規定プロパティが導く目的語リソースをこの場合にどのようなものとするのか，適切な想定ができない。

方式1-2：主語リソースは個々の体現形インスタンスなどの実体インスタンスとする。つまり，プロパティの定義域（rdfs:domain）には該当する実体クラスを指定する（第5図では定義域を体現形としている）。そして，下記のように，目的語リソースは当該規定を適用した結果として導かれた値（リテラルまたはURIリソース）とする。

ex：実体インスタンスのURI_1：個別規定プロパティのURI_1"リテラル値"｜URIリソース．

結局のところ，NCR規定プロパティは記録行為（その規定内容に相当する行為）自体を表していることになると捉えることができる。例えば，主語リソースが体現形インスタンス1，述語が規定プロパティ「:ncr2.1.1」（本タイトルの規定）と想定すると，その目的語リソースは当該規定を適用して得られたリテラル値であるタイトル文字列とすることなどが考えられる。こうした扱いは意味あるものかもしれないが，積極的な利点は見いだしがたい。同一の実体インスタンスかつ同一エレメントに対しても，メタデータ作成機関・作成者による選択や解釈に依存して複数の異なる規定が同時に組み合わされて適用されうること，さらにはその適用結果においても異なる値が導出されうることなどを適切に扱えることが求められる。

さらに，上位の規定および下位の規定であるプロパティとどのように関係づけるか，エレメントとどのように関係づけるかという問題もある。これらの問題への対処には，以下の方式がそれぞれ考えられる。

方式2-1：特有のプロパティを導入して上位規定・下位規定を関係づける。これは，規定をクラス設定する場合と同様の対処法である。第5図では，仮に「:lower」と「:upper」を用いて上位・下位関係を表している。

方式2-2：プロパティであるエレメントに対して，rdfs:subPropertyOfを用いて「プロパティ–サブプロパティ」の関係とする。エレメントに関する記述規定としてプロパティを設定し，かつ上記の方式1-2を採用したときに，エレメントのサブプロパティとする選択肢がある。第5図ではエレメント「本タイトル」のサブプロパティとしてNCR規定プロパティ「:Ncr2.1.1」を位置づけている。

前章の検討で示した通り，NCRの個別規定はRDFクラスとすることも，RDFプロパティとすることも可能である。ただし，プロパティとすることに特段の利点があるとは思われず，またエレメントとの使い分けなど複雑さを導入することになるため，本研究においては，個別規定をクラスとして設定する方式を採用する。加えて，参照やそれによるリンクの実質的な意味合いを高めるため，単一条項を自立した複数の部分に細分できる場合にはその細分単位を採用する。こうした細分がなされない規定は，条項番号単位のクラスとなる。本章では，こうした方針に立脚した上で，規定クラス間の関係指示および別法と参照指示の扱いについて検討する。

A. 条項番号に沿った規定間関係の扱い

記述規則のRDFデータ化では，規定クラスのURIを条項番号に基づいて付与することに併せて，条項番号が表す個別規定間の階層的な関係を表現することが求められる。この点にかかわる検討事項には，「#2.1タイトル」，「#2.1.1本タイトル」，「#2.1.1.1記録の範囲・情報源」などの条項番号に沿った規定間の関係を「全体–部分」と見なすべきか，「上位–下位」と見なすべきかを判断することがある。なお，いずれと見なす場合にもプロパティ「rdfs:subClassOf」で両者をつなぐ，すなわちRDFの「クラス–サブクラス」とすることは適切ではないと考える。サブクラス関係と見なすことは，下位のクラスは上位クラスがもつ性質・属性をすべて継承しつつ，より個別的な性質が付加される場合であり，記述規則を構成する規定間にはこうした捉え方は適合しないからである。本研究では，以下の点を踏まえて，規定間の階層的な関係を「上位–下位」と見なす（「全体–部分」としない）こととする。

①「#2.1.0通則」，「#2.1.0.1記録の範囲」は，エレメント「#2.1.1本タイトル」・「#2.1.2並列タイトル」などに適用する「通則」という位置づけである。つまり，前者はより広範囲をカバーする上位の規定，後者がその下位規定となるが，条項番号はこれを表現しておらず，「全体–部分」とは見なしがたい。条項番号上では，#2.1.0は，#2.1.1，#2.1.2などと同列である。

②「#2.1タイトル」，「#2.1.1本タイトル」，「#2.1.1.1記録の範囲・情報源」などは，それ自体では実質的な規定内容を持たず，条項番号下位の規定群を単に束ねる位置づけにある。「#2.1タイトル」は，“タイトルは，エレメントである。”とのみ規定しており，エレメント「タイトル」の定義情報において既に同内容が宣言されている。「#2.1.1本タイトル」についても同様であり，「#2.1.1.1記録の範囲・情報源」に至っては一切の規定文をもたず，条項番号と見出しのみから構成されている。これらは，条項番号下位の規定群を束ねていると見ることが適切であろう。また，他の箇所から参照される可能性もあるため，これら条項のRDFクラスとしての必要性はある。

本研究では，上位の条項番号から下位の条項番号を結びつけるプロパティ「:lower」と，逆方向のプロパティ「:upper」を導入する。これらによって，双方向に参照が可能となる。なお，概念間の上位下位関係を表現する汎用的なプロパティとしてSKOSが定める「broader」（http://www.w3.org/2004/02/skos/core#broader）と「narrower」があるが，ここではNCR条項番号と規定の特性を考慮し，独自のプロパティを採用した。第3図や第4図におけるこれらプロパティの適用箇所がその具体例となる。

また，本研究では規定間の上位下位関係を指示するケースを，直上位および直下位のみに限定した。例えば，第3図では規定クラス「:Ncr2.1.1」に対して直下位の規定クラスのみ指示しており，2段階下位のクラス（「:Ncr2.1.1.1.1」，「:Ncr2.1.1.1.2」など）やそのさらに下位のクラスを示していない。それらは，直下位クラスのRDFデータを取得し，続けて下位方向に辿ることにより，順次辿りつくことができる。

条項番号の扱いに関して併せて確認しておくべき事項に，下記のものがある。

①「A」・「B」などが末尾に付いた条項は，それらが付いていない条項の下位とする。例えば，「#4.1.3A活版印刷が主となる時代以降の著作」，「#4.1.3B活版印刷が主となる時代より前の著作」は，「#4.1.3優先タイトルの選択」の下位規定とし，「#4.1.3.1著作の部分」や「#4.1.3.2著作の集合」等と同レベルの位置づけとする。こうした扱いは，NCRにおける条項見出しの付け方からも明白と判断した。

②「別法」・「任意追加」・「任意省略」の条項は，それらが対象としている本則と同じレベルとする。例えば，「#4.1.3.2別法」は「#4.1.3.2」と同じレベル，「#4.1.3A別法」は「#4.1.3A」と同じレベルとする。よって，クラス「:Ncr4.1.3.2別法」の直上位は「:Ncr4.1.3」となる。

③同列に位置づけられる条項において，その前後の条項を指示することも考えられる。例えば，「:prev」や「:next」などを導入して前後関係を表すこともできるが，本研究では特にその必要性はないと考え採用しない。

次に，主語リソースとなる規定クラスのラベル（rdfs:label）について付言する。条項に付けられた見出しはラベルとして記録するが，条項番号による階層関係に基づき，当該条項の位置づけが分かる形で見出しを構成することにした。例えば，条項「#2.1.1.2.4」の見出しは「併記された語句」であるが，各条項を独立したトリプルデータとするとこのままの見出しでは分かりにくいため，条項の階層関係に従って「タイトル–本タイトル–記録の方法–併記された語句」というラベルを機械的に生成した（第4図参照）。

B. 条項内最小単位のクラス設定における規定間関係の扱い

前章の「3. 条項内最小単位のクラス設定」で論じた通り，単一の条項である「#2.1.1.2.4併記された語句」は，独立した2つの単位に細分できる。こうした場合，条項番号に基づく元の単位にURIを付与し，さらに独立させた2つの最小単位にそれぞれURIを付与する。本研究ではそれらを「:Ncr2.1.1.2.4」と，「:Ncr2.1.1.2.4-1」・「:Ncr2.1.1.2.4-2」という枝番形式のURIで表す。その上で，これらの相互関係は，単一の条項を分割した結果としての「全体–部分」関係と捉え，プロパティ「:hasPart」と「:isPartOf」を用い，双方向に参照できるよう表現する。すなわち，クラス「:Ncr2.1.1.2.4」が部分であるクラス「:Ncr2.1.1.2.4-1」と「:Ncr2.1.1.2.4-2」から構成されること，併せて後者2つからはそれらの全体に該当する前者のクラスがあることを示す（第4図参照）。

なお，この事例において全体に位置づけられる規定クラス「:Ncr2.1.1.2.4」には，具体的な規定文はない（プロパティ「:instruction」を用いて表現する部分がない）。このままのRDFデータで問題ないと考えるが，必要とあれば，細分部分への参照を含む規定文，例えば“同義語による別の表現，原語形とその略語，外来語とその原語などが，タイトルに併記されている場合，情報源でタイトル全体が複数の言語および（または）文字種で併記されている場合は，それぞれ#2.1.1.2.4-1，#2.1.1.2.4-2に従う。”を新たに構成することもできる。

同様に，単一条項がa, b, cなどによって区分されており，それに依拠して条項内を細分した場合も，プロパティ「:hasPart」と「:isPartOf」を用いて条項とその細分部分の相互関係を示す。それぞれの細分部分の自立性を強調する必要があれば，規定文に一部改変を加えることもできる。例えば，「#2.1.1.2.2上部または前方の語句」は，“情報源において，明らかに本タイトルと判定される部分の上部または前方に表示されている語句は，次のように扱う。”とあり，それに続く3つの部分，“a） 語句が，本タイトルの一部として意図されていない説明的な導入句である場合は，…”，“b） 語句が，明らかに本タイトルと判定される部分と不可分な場合は，…”，“c） 語句が，本タイトルの一部とみなされず，タイトル関連情報，責任表示，版次，出版者，シリーズの本タイトル等の別のエレメントと判断される場合は，…”とに分かれている。これらをそれぞれ規定クラスとしての独立性を高めたRDFデータ表現とするには，規定文を一部改変し，例えば次のようにすることが考えられる。

:Ncr2.1.1.2.2 :instruction “情報源において，明らかに本タイトルと判定される部分の上部または前方に表示されている語句は，#2.1.1.2.2a，#2.1.1.2.2b，#2.1.1.2.2cに従い扱う。”.

:Ncr2.1.1.2.2a :instruction “情報源において，明らかに本タイトルと判定される部分の上部または前方に表示されている語句が，本タイトルの一部として意図されていない説明的な導入句である場合は，…。”.

C. 別法の扱い

NCRには，本則と択一の関係にある別法の条項が存在する。別法は，対応する本則と同じ条項番号をもち，条項見出しに続けて「別法」の語が付加されている。本研究では，別法のURIは末尾に文字列「別法」を付加したものとする。例えば，本則である「:Ncr2.1.1.2.6」に対する別法はURI「:Ncr2.1.1.2.6別法」となる。その上で本則との関係を明示するため，プロパティ「:instrctType」（規定タイプ）と，その目的語リソースであるクラス「:Alternative」（択一）を記録する。別法は意味的には「owl:disjointWith」（排他的クラス）に近いが，記述規定における別法である点を明示するために上記のクラス「:Alternative」をもって表現した。加えて，対応する本則のURIをプロパティ「:alternativeTo」をもって示す（第6図）。

第6図 記述規定をRDFクラスとした場合のRDFデータ例：「別法」の扱い。方式2

また，NCR2018の別法の規定は，本則と共通する部分を繰り返した上で，本則と異なる規定箇所が記号「*」を用いて明示されている。条項番号単位でクラス設定する場合は，特に留意すべきことはないが，条項内最小単位のクラス設定とする場合には1つの別法を最小単位に分割してURIを付与し，相互に「全体–部分」として関係づけることになる。

そして，別法の規定が別法固有の部分と本則と共通する部分の両方から構成される場合には，以下の2つの選択肢が生じる。

方式1：本則と共通する部分も別法として独立したURIを付与し，それが本則のある部分と同一である点を「owl:sameAs」または「owl:equivalentClass」をもって表す。併せて，当該別法の構成を示す。

方式2：本則と異なる部分のみにURIを付与し，本則と同一内容の規定部分は，本則の規定クラスURIをそのまま記録し参照させる。具体的には，当該別法の構成を表す規定クラスを定め，こうした関係を表現する。第6図の規定「#2.1.1.2.6別法」がまさにそうした事例である。“*情報源に複数の言語または文字種によるタイトルがある場合は，その情報源での表示順序，配置，デザイン等に基づいて本タイトルを選定する*。”が別法固有の部分，その後に続く“本タイトルとしなかったタイトルは，…”は本則と同一規定文である。この場合，本則と異なる部分を別法の個別規定として表し（クラス「:Ncr2.1.1.2.6別法-1」），本則と同じ部分「:Ncr2.1.1.2.6-3」はそれを参照させる。第6図に示したように，「:Ncr2.1.1.2.6別法 :hasPart :Ncr2.1.1.2.6別法-1，:Ncr2.1.1.2.6-3 .」によって，別法全体の構成を示す。なお，本則である「:Ncr2.1.1.2.6」は3つの最小単位に細分され，そのうち3番目の規定クラスが別法と共通している。以上の通り，本研究は方式2を採用した。

別法と類似する性質をもった条項に「任意追加」や「任意省略」がある。本研究では，「任意追加」や「任意省略」についても，そのURIは末尾にこれら文字列を付加したものとする（例：「:Ncr2.1.1.2.2任意追加」など）。併せて，プロパティ「:instrctType」とその目的語リソース「:Optional」（任意）とによって，任意規定であることを明示する。任意規定も，本則と同様に，条項内最小単位に細分することができる。

D. 参照指示の扱い

NCRの規定は，関連する条項を指し示す「参照指示」を組み入れている。この参照指示には，①独立した参照指示（例：“（参照: #2.1.1.4b），#2.1.1.4別法b），#2.2.0.6を見よ。）”）と，②規定文内に埋め込まれた参照指示（例：“原資料のタイトルが同一の情報源に表示されている場合は，#2.1.1.3に従う。”）の2種類がある。本研究では，両者を抽出しプロパティ「:referredInstrct」（参照先規定）を用いて，RDFデータにおける参照関係として記録する。前者①の場合には，さらに「:referredInstrctStmnt」（参照先指示規定文）によって，元の表現をそのまま記録する（第4図参照）。

加えて，上記の①・②の両者において，③参照先の個々の条項番号を記した参照指示の場合と，④範囲を示した参照指示（例：「#2.10.1.2～#2.10.1.2.4別法」）の場合がある。このうち④については，指定範囲に含まれる規定のうち，実質的な参照先の条項と見なすべきものに関して解釈に幅がありうる。つまり，範囲指示に含まれるすべての条項が，あるいはその範囲内の最下位レベルの条項まで，実質的に参照されているとは考えにくい場合も多い。④に関するこの問題に対処するには，以下の2つの方式が考えられる。

方式1：指定範囲の先頭に記された条項番号と末尾に記された条項番号のみを，それぞれの位置づけを表す相互に異なるプロパティで記録する。例えば「:referredInstrctRangeStart」（参照先規定の範囲指定開始）と「:referredInstrctRangeEnd」（範囲指定終了）などを用いて表現する。ただし，この方式では，範囲内に存在する個別規定への直接的なリンクではないため，該当する規定群をそのままでは参照できない。

方式2：実際の参照先条項と見なすべきものに関して方針を定め，それに依拠して該当する規定の抽出を行い，プロパティ「:referredInstrct」を用いて該当規定を直接記録する。

本研究では，規定間参照を容易に辿ることができるデータとすべく，方式2を採用する。ただし，こうした範囲指定における実質的な参照先条項と見なすべきものに関してNCR2018自体に解釈の指示はないため，採用に当たっては以下の方針を独自に定め，それに依拠して該当する規定の抽出を行った。条項番号が表す条項間の上位下位関係がプロパティ「:upper」・「:lower」を用いて併せて表現されている点を踏まえた方針設定である。

①範囲指定における先頭の条項番号と末尾の条項番号とが条項階層レベルで一致しており，かつ下記②に該当しない場合には，それらの中間に該当する条項について同じ階層レベルのもののみ採用する。また，それらの下位レベルの条項は参照しない。例えば，「#4.3～#4.7」の場合には，#4.3，#4.4，#4.5，#4.6，#4.7の参照とし，#4.3.1，#4.3.2などは参照しない。

②先頭条項番号と末尾条項番号とが階層レベルで一致しているが，一部の中間レベルが異なる条項番号の場合には，共通部分からなるパターンを設定し，それに該当する条項のみ参照する。例えば，「#4.16.0.1.2～#4.20.0.1.2」は，共通パターン「#4.?.0.1.2」とし，#4.16.0.1.2，#4.17.0.1.2，#4.18.0.1.2，#4.19.0.1.2，#4.20.0.1.2のみ参照する（#4.16.0.2，#4.17.0.1などは参照しない）。

③先頭条項番号と末尾条項番号とが階層レベルで一致しない場合には，a）先頭番号が階層上位，末尾番号が階層下位のときには，先頭番号と同列の条項を順次参照し，加えて末尾番号については指定された下位レベルの条項まで順次参照する。例えば，「#1.11～#1.12.3」は，#1.11，#1.12，さらに#1.12.1，#1.12.1別法，#1.12.2，#1.12.2別法，#1.12.3への参照とする。b）先頭番号が階層下位，末尾番号が階層上位のときには（例：「#4.8.3～#4.12」），先の処理aと逆にする。「#4.8.3～#4.12」は，#4.8.3と#4.9，#4.10，#4.11，#4.12に展開する。c）上記以外の場合には，事例ごとにその適切な解釈を適用し，参照として記録すべき規定クラスを決定する。

前章までの検討により採用した選択肢に基づいて，NCR2018の規定群を実際にRDFデータに変換した。これにより，採用した選択肢の実施可能性を確認すると共に，検討事項に漏れがないかを確認した。

今回の試行では，属性の記録を扱った章のうち，「第2章体現形」，「第4章著作」，「第6章個人」を対象にした。これらは多くの条項から構成される代表的な章と捉えることができる。NCRの各章ごとの文書ファイルから個々の規定を読み出し，プログラムでRDFトリプルデータに機械的に変換した。その後，筆者らが分担して人手による確認と修正を行った。特に，各条項の規定を条項番号単位のトリプルデータとすべきか，より小さな条項内最小単位のトリプルデータとすべきかについては機械的に判断できず，人手による判断が不可欠であった。この作業の手間を最小化するために，条項番号単位の変換と条項内の段落単位の変換の両者を行ったトリプルデータを機械的に生成し，確認作業者により妥当と判断された方を選択できるようにした。

第1表に，人手による確認・修正作業を経た，最終的なRDFトリプルデータへの変換結果の集計値を示した。紙幅の都合上，本章では変換結果の集計値およびその補足説明をもって試行結果の提示とする。第1表ではNCR2018の3つの章ごとに集計値を示している。表中の「条項数」とは条項番号が付与されている数であり，別法や任意追加・省略もそれぞれ独立した条項として数えられている。第2章が条項数1254，第4章が277，第6章が148となり，体現形の属性の記録を扱った第2章が他に比べて極めて大きな条項数であることが示されている。本則，別法，任意（任意追加と任意省略を合わせたもの）に分けてその内訳を記載したが，別法かつ任意という条項（例：「#2.5.1.2記録の方法　別法　任意追加1」など）が第2章に16，第4章に1あるため，合計数とは一致していない。第2章に別法と任意規定が多いことが分かるが，他の章においても一定程度の別法が含まれていることが読み取れる。

条項番号単位ではなく，条項内最小単位に「細分された条項数」は3つの章それぞれにおいて389, 100, 65であった。これらの本則，別法，任意の内訳も記載してある。なお，別法かつ任意という条項における最小単位への細分は発生していない。条項内最小単位への細分によって生成された「最小部分数」はそれぞれの章において1088, 263, 193であった（ここには分割された条項番号レベルのクラス数は含めていない）。また，III章「C. 別法の扱い」で前述した通り，別法の条項において細分した単位が本則の細分部分と内容が等しいときには，当該細分部分について新たなクラスを別法において生成せず，該当する本則の細分部分をそのまま流用する（つまり，「:hasPart」により本則の細分部分を導く）ことにしている。こうした流用が発生した回数および該当する別法の条項数を「別法における本則部分の流用回数」として示した。例えば，第2章では，30の別法において51回，こうした本則の流用がなされている。

第1表の下半分には，作成したRDFデータ全体の集計結果を示した。3つの章それぞれの「合計トリプル数」は，2342, 540, 341である。すなわち，トリプルデータの主語リソースは条項単位のクラスの場合と細分単位のクラスの場合とがある。今回生成したRDFデータは，条項番号単位のクラス設定をしたものと条項内最小単位でクラス設定をしたものから構成されるため，この合計数は各章の条項数に細分部分数を加えた数に等しい。

加えて，各章のRDFデータとしての特徴を示すために，各種の「プロパティの出現回数」を示した。各プロパティの説明は，付録に示す。第1表に示された数値からは，以下の特徴が読み取れる。

・プロパティ「:instruction」（規定文）は，規定の指示内容を文章により表現した規定文を導くものである。主語リソースごとに，当該プロパティの出現は最大1回である（複数適用され出現することはない）。3つの章のRDFデータではそれぞれ1854, 411, 275回出現している。規定文をもたない規定がある程度存在することが表れている。

・「:instrctFor」（適用先エレメント）：規定が本タイトルなどの特定エレメントに関わるものであった場合に，そのエレメントを記録するプロパティである。3つの章ともに合計トリプル数よりも少ない出現数となっており，NCR規定が必ずしも特定のエレメントに関係するものばかりでないことを示している。

・「:upper」「:lower」（上位規定，下位規定）：条項番号に基づく上位下位関係を示すプロパティである。これら2つのプロパティの出現数は同数となる。それぞれの章において1211, 253, 123回出現しており，当然ながら条項数に近い値となる。

・「:referredInstrct」（参照先規定）：参照指示を示すプロパティであり，参照先は条項番号単位のものと条項内最小単位のものとがある（例：目的語リソースが「:Ncr2.1.1.4」や「:Ncr2.1.1.4b」となるものなど）。第4章は，このプロパティの出現回数が790で全体トリプル数540よりも多い。他の2つの章には同様の傾向がないことから，第4章の規定には参照関係が多いという特徴が見て取れる。

・「:referredTable」（表の参照）：規定に含まれる表または付録の表を参照するプロパティである。条項と同様にクラスとした表（: Ncr表2.15.0.2など）を目的語リソースとして導く（例：Ncr2.15.0.2-2 :referredTable :Ncr表2.15.0.2.）。このプロパティが，3つの章においてそれぞれ68, 4, 2回出現している。

・「:hasPart」「:isPartOf」（部分規定，全体規定）：条項を細分した場合に条項単位から細分部分への関係指示には前者のプロパティを，細分部分から条項単位への関係指示には後者のプロパティを適用する。これらが出現回数で同一とならないのは，細分あり別法内での本則部分の流用の場合に，前者のプロパティは使用されるが，後者のプロパティは使用されないため，その差分が発生する。

A. 個別規定からメタデータへの参照

記述規則をRDFデータ化することで，記述規則とそれに従って作成されたメタデータとを容易に接続することができる。NCR2018のRDFデータにおいては，下記のようにメタデータURIを参照させることで，メタデータとの接続が実現できる。

:Ncr2.1.1.2.4  :instrctAppExample ex：体現形メタデータURI_1.

このときの参照先URIは情報リソースであるメタデータを表し，実体インスタンス（実世界オブジェクト）を指してはいない。メタデータを参照先とすることで，同一実体インスタンスが，特定のエレメントの扱いにおいて異なる規定が適用されうること，そして異なる値が記録されうることを適切に対処できる。すなわち，同一実体インスタンスに対して，エレメント値の異なるメタデータが作成されうることを適切に扱えることになる。

なお，参照先である目的語リソースがメタデータURIである場合に加えて，トリプル群からなるRDFグラフ自体を指す場合を想定することができる。これによって，個々の規定が適用された事例（「実体インスタンスURI–エレメント–値」というトリプル）をグラフとして直接参照できる。メタデータURIを介して，それを主語リソースとするデータとする場合（B節参照）と比べて直接的な記載となる。具体的には，Named Graph（名前付きグラフ）と呼ばれるものであり，TriGなどのシリアライズ形式を用いて表現できる。

さらには，W3Cにおいて草案の段階にあるRDF拡張案であるRDF-star（以前は「RDF*」と表記）を適用することもできる。これによって，プロパティ「:instrctAppExample」の目的語リソースの箇所に直接，当該個別規定の適用事例であるトリプルデータを示すことができる。

B. メタデータから個別規定への参照

前節の構図とは逆に，メタデータを起点にして，当該メタデータに実際に適用されたNCR個別規定を記録し参照することも可能である。ただし，この逆向きの接続を実現させるには，メタデータ記述の対象とする著作から個別資料までの実体リソースのインスタンス（とそのURI），個人・団体等の実体インスタンス（とそのURI）を，メタデータ（とそのURI）から区別すべきかという問題を検討する必要がある。海外における議論や実装例を見ると，個人・団体等については，対象とする実体インスタンスとそれに対するメタデータとを区別する立場が取られることが多く，この点は一定程度の合意が得られていると見なすことができよう。著作についても議論や実装例があるが，両者を区別する立場と区別しない立場の両方があり，広く合意されているとは言いがたい状況にある^{21）22）23）}。表現形，体現形，個別資料に関しては，こうした議論自体が殆ど見られない。

上記にかかわる検討はリンクトデータ化に向けて重要であるが，本研究の検討課題の範囲を超えるため，ここでは検討を展開しない。本稿ではメタデータと実体インスタンスを区別するという立場に暫定的に立脚し，本研究が射程とする事項の議論をその上に積み上げる。メタデータと実体インスタンスは区別するという立場に立つため，両者のURIはfoaf（http://xmlns.com/foaf/spec/）によるプロパティ「foaf:primaryTopic」「foaf:isPrimaryTopicOf」，あるいは「foaf:focus」などを用いてリンクさせる。

例1: ex：体現形メタデータURI_1 foaf:primaryTopic ex：体現形インスタンスURI_1.

例2: ex：体現形インスタンスURI_1 foaf:isPrimaryTopicOf ex：体現形メタデータURI_1.

目録委員会が定めたNCRエレメントのプロパティは定義域に実体クラス（著作，体現形，個人など）を指定しており，そのためメタデータURIをエレメントの主語とすることはできず，下記のようなトリプルデータの構成となる（プロパティ「ncr:E200002」は本タイトル，「ncr:E200003」は並列タイトル）。

@prefix ncr：<http://jla.or.jp/term/ncr2018/ >.

ex：体現形メタデータURI_1 foaf:primaryTopic ex：体現形インスタンスURI_1.

ex：体現形インスタンスURI_1 ncr:E200002“タイトル１”;

ncr:E200003“タイトル2”.

第7図は，NCRエレメント，NCR個別規定と，メタデータ，そして実体インスタンスとの関係を図示している。NCRエレメントと個別規定との関係，メタデータと実体インスタンスとの関係を，それぞれをつなぐプロパティを用いて表している。なお，NCRエレメントのみプロパティ（図中では便宜的に点線で囲んである）であり，NCR個別規定，メタデータ，実体インスタンスはいずれもクラスのインスタンスである。前述の通り，エレメントは実体インスタンスを主語リソースとするが，メタデータとの直接のリンクはない（正確には，メタデータはエレメントとその値などから構成される）。他方，NCR個別規定はメタデータと相互にリンクさせることができ，個別規定から適用例としてのメタデータにリンクし，逆にメタデータからは適用された個別規定を記録し参照できるようにすることが可能である。換言すれば，個別規定と実体インスタンスとの間には参照関係がない。

第7図 NCRエレメント，個別規定，メタデータ，実体インスタンスの相互関係

メタデータにおいて，適用されたNCR個別規定を記録し参照できるようにするために，本研究ではプロパティ「:appInstrct」（規定の適用），「:targetElement」（対象エレメント），「:elementValue」（エレメント値），「:appIndvInstrct」（適用した個別規定）を導入する。加えて，以下の選択肢がある。

方式1：適用された個別規定をメタデータの下に記録する。a）エレメントの値がリテラルの場合と，b）エレメント値としてURIを取る場合の構成を，第8図に示す。プロパティ「:appInstrct」によって，元のトリプルデータに加えて，対象としたエレメントとその値，適用したNCR個別規定を記録している。この場合には，本タイトルが「タイトル1」であることがデータ全体から見れば重複して記録されているが，プロパティ「:elementValue」を適用せず，重複した記録を回避することもできる。エレメント「本タイトル」において個別規定「:NCR個別規定URI_1」が適用されたことが示されている。具体例として冊子体資料であるNCR2018自体を体現形インスタンスとするメタデータの一部を第9図に示した。

第8図 メタデータから個別規定への参照：方式1

第9図 メタデータから個別規定への参照：方式1の具体例

あるいは，メタデータであるRDFグラフを主語リソースとするNamed Graphを採用し，適用されたNCR個別規定を記録することができる。さらには，RDF拡張案であるRDF-starを適用し記録することも可能である。

方式2：適用された個別規定を実体インスタンスの下に記録する。第10図にトリプルデータの構成を示す。NCRエレメントのRDF定義ではその値の記録法の多様さに対応するため，値域（rdfs:range）が指定されていない。そのため，図示したように値に空白ノードを採用しても齟齬がない。

第10図 メタデータから個別規定への参照：方式2

さらには，メタデータにおいて適用規定のURIを記録することに加えて，採用した情報源，情報源上での表示形なども含めて記録することが考えられる。これらはメタデータ記述に伴う「根拠」と見なすことができ，当該メタデータの品質を担保するばかりでなく，その後の応用も広がる可能性をもつ。例えば，プロパティ「:sourceOfInfo」（情報源）を導入し，採用した情報源をリテラル値で指示する，または情報源の画像ファイルURL等を記録することなどが考えられる。

本研究は，記述規則であるNCR2018のRDFデータ化を意図し，そのための検討事項や項目および選択肢を提示し，その上で適切な選択肢を同定した。併せて，NCR2018の3つの章について実際にRDFデータ化を試行し，その妥当性の確認を試みた。得られた成果をまとめると，下記のようになる。

①RDFデータとして広く活用できるように，NCR2018の条項番号単位に加えて，自立して適用できる細分の単位（条項内最小単位）を採用してRDFデータ化を行った。各規定に適した単位でRDFクラスを設定しURIを付与した上で，条項間の階層的な関係，参照関係，元条項とその細分部分との関係，本則と別法や任意規定との関係などを適切に表現できるようにした。条項内最小単位を採用した点については，有効な利活用とその手間という観点からの適否を十分に検討することはできておらず，今後の課題と考えている。

②3つの章の規定群に対して，RDFデータへの機械的な変換と人手による確認・修正作業を実行し，実際にRDFデータを整備した。これによって，RDFトリプルデータの集計値など概況を把握するとともに，選択した方針の下，大きな障壁なしにRDFデータとすることができる点を確認できた。おそらくは他の章についても同様にRDFデータ化を図ることができるものと予想している。

③記述規則とそれを適用して作成されたメタデータとを接続することを検討し，十分に実施可能である点を確認した。具体的にいえば，RDF化したNCR規定からそれを適用したメタデータへの参照と，逆にメタデータから実際に適用されたNCR規定への参照をいかに実現するかを検討した。NCRを適用して作成されたメタデータに対して適用された規定群の情報を詳細に記録することで，メタデータの信頼性の担保などにつなげられると考えられる。

紙幅の制約から本稿で取り上げなかった事項の1つは，NCRエレメント以外の語彙やスキーマを用いて作成されたメタデータにおいても，NCR2018の規定群を適用して作成された事例であれば，適用されたNCRの規定への参照を記録することができる点である。例えば，NDLがNCR2018を適用してMARC21書誌・典拠レコードを作成している。そうした場面においてもMARC21レコードをRDF形式データに変換した上で，適用されたNCR個別規定を記録できる。ただし，そのためには，NCRエレメントと他の語彙やスキーマとのマッピングが前提となる。

本稿で取り上げなかったもう1つの事項は，NCR2018に対する個別機関の適用細則の扱いである。NDLはNCR2018を自館で適用するための細則を順次公開しており^24），それら適用細則についても，本研究の延長上でRDFデータ化を図ることができ，メタデータから実際に適用された個別の細則規定への参照を記録することもできる。

他方，今後の展開として，RDAなど，他の記述規則のRDFデータ化を試みる研究や，本研究で整備したRDFデータを活用した研究が考えられる。

本稿は，著者らがこれまで口頭発表した内容を踏まえたものであるが^25）26），その後変更を加えた部分がある。変更点については，煩雑さを避けるため，本稿では細かく注記していない。また，著者のうち1名は現在，目録委員会の委員を務めており，NCR2018語彙のRDFデータの策定と公開にも携わっている。そこから着想を得た研究課題であるとはいえ，本研究はあくまでも委員会業務外の研究であり，目録委員会としての見解を示したものではない。こうした研究の契機を与えてくれたこと，および成果発表を寛容に認めていただいていることに対して，目録委員会の委員諸氏に謝意を表す。