 |
Open Archives Initiative Object Reuse and Exchange |
 |
|
Open Archives Initiative Object Reuse and Exchange |
|
オープン･アーカイブズ･イニシアティブ - オブジェクトの再利用と交換（OAI-ORE）は、Webリソースの集合を記述し、交換するための標準を定義する。本書はOAI-OREのコンテキストにおいて対象となる事項を記述し、これらの間の関係を表現するために必要な用語と語彙を記述する。
本書は、OAI-ORE仕様書およびユーザガイドを構成する文書の1つである。OREを使用する動機およびOREが提供するソルーションについての基本的な理解を得たい読者は ORE入門 を読まれたい。
1. はじめに
1.1 表記法
1.2 使用名前空間
1.3 例に関する注記
2. ORE語彙の定義
2.1 OREクラス
2.1.1 ore:Aggregation
2.1.2 ore:AggregatedResource
2.1.3 ore:Proxy
2.1.4 ore:ResourceMap
2.2 ORE関係
2.2.1 ore:aggregates
2.2.2 ore:isAggregatedBy
2.2.3 ore:describes
2.2.4 ore:isDescribedBy
2.2.5 ore:lineage
2.2.6 ore:proxyFor
2.2.7 ore:proxyIn
2.2.8 ore:similarTo
3. 推奨される語彙
3.1 クラス
3.2 関係
3.2.1 ダブリンコア要素
3.2.2 ダブリンコア用語
3.2.3 FOAF用語
3.2.4 RDF用語
3.2.5 RDFスキーマ用語
4. 参考文献
本書の目的は、OAI-OREのコンテキストで使用される概念を記述し、これらの概念を機械が理解可能な形で確実に実装するために必要な専門語彙を明記することである。
仕様書がこの分野における現在･未来の作業と調和するように、できるだけWorld Wide Web [Web Architecture] のアーキテクチャと用語に従った。
本書で記述される語彙項目には次の2種類がある。
本書ではOREモデルに固有でない基本的な用語についてはできるだけ既存の語彙を再利用することを原則とする。そのため、対象となるオブジェクトを記述するために必要な、または適当な用語として本書で取り上げる用語の多くは他の情報源から採用されている。これらの推奨語彙は、OREコンテキストにおける用語の使用例と共に第3節で記述される。ここで取り上げられた項目が包括的なものであると考えられるべきではない。詳細については参考文献を参照されたい。中では、ダブリンコア･メタデータ･イニシアティブ [DCMI] とRDF（Resource Description Framework）[RDF] が中核的な定義を数多く提供している。
本書や他の既存語彙に記述されていない概念については、ドメイン特有の語彙が対象コミュニティで作成･管理されるべきである。将来、コミュニティのベストプラクティスである勧告が本書に統合されるかもしれないが、現時点では、Atomシリアライゼーションに完全対応するために必要な語彙とすべてのドメインで重要と考えられる事項のみを掲載する。
本書の想定読者は、OREデータモデルで使用されている関係とクラスの技術詳細とセマンティクスを求めている実装者である。特に、RDFベースのシリアライゼーションを使用する、または使用予定の実装者は、本書が使用されている最も一般的なすべての語彙用語に対する唯一の参照ポイントであることに気付くだろう。OREを使用する動機およびOREが提供するソルーションについての基本的な理解を得たい読者はORE Primerを読むべきである。
本書におけるキーワード「しなければならない（MUST）」「してはいけない（MUST NOT）」「必須とする（REQUIRED）」「とする（SHALL）」「とはしない（SHALL NOT）」「するべきである（SHOULD）」「するべきでない（SHOULD NOT）」「推奨する（RECOMMENDED）」「することができる（MAY）」「オプションである（OPTIONAL）」は、RFC 2119 [IETF RFC 2119] に記述されているように解釈されるものとする。
本仕様書では、次の名前空間とそれを示す接頭辞を使用する。
| 接頭辞 | 名前空間 URI | 記述 |
|---|---|---|
dc |
http://purl.org/dc/elements/1.1/ |
ダブリンコア要素 [DC Elements] |
dcterms |
http://purl.org/dc/terms/ |
ダブリンコア用語 [DC Terms] |
dcmitype |
http://purl.org/dc/dcmitype/ |
ダブリンコアタイプ [DC Types] |
foaf |
http://xmlns.com/foaf/0.1/ |
FOAF語彙用語 [FOAF] |
owl |
http://www.w3.org/2002/07/owl# |
OWL語彙用語 [OWL] |
ore |
http://www.openarchives.org/ore/terms/ |
ORE語彙用語 [本書] |
oreatom |
http://www.openarchives.org/ore/atom/ |
ORE Atom名前空間 [ORE Atom] |
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
RDF語彙用語 [RDF Vocabulary] |
rdfg |
http://www.w3.org/2004/03/trix/rdfg-1/ |
RDFグラフ語彙 [RDFG] |
rdfs |
http://www.w3.org/2001/01/rdf-schema# |
RDFスキーマ語彙 [RDF Vocabulary] |
以下に示す例は、RDFのTurtleフォーマット [Turtle] で表現されている。上の表で示された接頭辞と共に、仮想的な接頭辞である 'my'（集合体のURIを表す）と 'your'（外部URIを現す） が仮定されている。my:aggregation が集合体を表すように、例には推奨URIではなく説明用のURIが使用されている。また、例としてカエルの写真についての仮想的なコレクションを使用した。
この節では、集合体、プロキシ、isDescribedBy、由来といったORE固有の用語を定義し記述する。これらの用語はORE名前空間 http://www.openarchives.org/ore/terms/ にあり、OREリソースマップの構築に使用される。名前空間文書は http://www.openarchives.org/ore/terms/ で入手できる。
単一のリソースとして扱えるように1つに集められた、関連リソース（集合リソース）の集合。これは、ORE相互運用フレームワークにおいてリソースマップにより記述される実体である。
集合体に含まれるリソース。あるリソースが集合リソースクラスのメンバーであるという表明は、それが少なくとも1つの集合体に集められたこと以外には何も意味しないことに注意されたい。このように、このクラスはほとんど自己言及的であるので、集められたリソースが ore:AggregatedResource クラスのインスタンスであることを表明する必要はない。
プロキシは、ある特定の集合体の中にある集合リソースを表す。ある実体に関して行われるすべての表明は、特定の集合体のコンテキストの中だけでなく、グローバルに真である。そのため、ある集合体の中にあるリソースに限って真であることを表明するためにプロキシオブジェクトが必要となる。例えば、ある特定の雑誌に掲載されている論文を引用したい場合や、リソースに集合体固有のメタデータを与えたい場合である。集合体はプロキシリソースではなく、リソース自体を集めるべきである。そして、そのリソースがある集合体の中に含まれていたという由来は ore:lineage 関係を使って表現されるべきである。
OAI-ORE データモデルによる集合体の記述。リソースマップはRDFグラフであり、実装ガイドラインにより機械可読フォーマットにシリアル化される。
rdf:type で与えられるべきである。
例:
my:resource-map rdf:type ore:ResourceMap . my:aggregation rdf:type ore:Aggregation . my:proxy-1 rdf:type ore:Proxy .
これらの関係、すなわち述語は、OREモデルにおける実体間の関係を記述するために定義されている。
集合体は、その名の通り、リソースを集める。関係 ore:aggregates は、目的語であるリソースが主語（集合体）の集合リソース集合のメンバーであることを表す。この集合体とその集合リソースの間の関係は、例えば、dcterms:hasPart で表されるような単純な部分と全体の関係よりも限定されたものである。
例:
my:aggregation ore:aggregates my:photo-1 ,
my:description-of-photo-1,
my:photo-2 .
ore:isAggregatedBy は、ore:aggregates と逆の関係であり、集合リソースが集合体により集められていることを表明する。この関係の想定される使用法は、発見を容易にするために、あるリソースが別の集合体でも集められていることをリソースマップが表明できるようにすることや、集合体がまた別の集合体に集められていることを表明することが挙げられる。
例:
my:photo-1 ore:isAggregatedBy my:aggregation ,
your:aggregation-of-frogs .
この関係は、主語（リソースマップ）が目的語（集合体）を記述することを表明する。
例:
my:resource-map ore:describes my:aggregation .
ore:describes と逆の関係で、関係の目的語はリソースマップで、主語はリソースマップが記述する集合体である。特に、集合体がそれ自体集合リソースである場合にこの関係を使用すれば、ハーベスタは集合体を記述するリソースマップのありかを知ることができる。また、ore:isDescribedBy は、1つの集合体からこの集合体を記述している様々なフォーマットの複数のリソースマップを指し示すことにも使用できることに注意されたい。
例:
my:aggregation ore:isDescribedBy my:resource-map ,
my:resource-map-rdf .
集合体に含まれるリソースがどこから来たのかを示す来歴の連鎖を体の集合体を使って表現することが望ましい場合があるだろう。これを行うために、集合体のコンテキストにある集合リソースを表現するプロキシオブジェクトが導入された。従って、ore:lineage は2つのプロキシオブジェクトの間の関係である。2つのプロキシはどちらも代理するリソースとして同じリソースを持たなければならない。これは、この関係の主語であるプロキシが代理するリソースが、目的語であるプロキシが代理するリソースが集められている集合体の中に発見されたことを意味する。
例:
my:proxy-1 ore:lineage your:proxy-1 .
プロキシオブジェクトは特定の集合体に集められているリソースを表すのに使用される。関係 ore:proxyFor は、プロキシが代理する集合リソースにプロキシを結びつけるために使用される。この関係の主語はプロキシオブジェクトであり、目的語は集合リソースである。
例:
my:proxy-1 ore:proxyFor my:photo-1 .
プロキシオブジェクトは、代理するリソースが集められている集合体にもリンクしなければならない。関係 ore:proxyIn はこの目的に使用される。この関係の主語はプロキシオブジェクトであり、目的語は集合体である。
例:
my:proxy-1 ore:proxyIn my:aggregation .
この関係の主語は集合体でなければならない。集合体はOREのコンテキストにおいて、この関係の目的語の1つの表現形であると考えられるべきである。なぜなら、広い意味で目的語であるリソースと等価であるからである。例えば、集合体が全体で1つのDOIが付与された雑誌論文を構成するリソースから成る場合である。この集合体はDOIが付与された論文ではないが、その何らかの表示形の1つである。
セマンティック上、この関係は rdfs:seeAlso より限定的であるが、owl:sameAs ほど明示的ではない。owl:sameAs は他の関係において主語と目的語が交換可能であるというプロパティを持つ。集合体の作成日時とそれに類似した論文の作成日時は同じでないので、この関係にはふさわしくない。一方、rdfs:seeAlso は「主語に関する付加的な情報を提供するかもしれないリソースを指定する」（強調を追加）ものであり、この目的にとっては関係が弱すぎる。rdfs:seeAlso は雑誌論文とそのレビューの関係にふさわしいものだろう。何故なら、両者は関連はあるが、同じものの何らかの別表現であるということは全くありえないからである。
例:
my:aggregation ore:similarTo <http://www.flickr.com/photos/carl/sets/12345/> .
他にも数多くの語彙が存在し、各分野で役立つ用語を含んでいる。リソースマップや集合体、集合リソースの包括的な記述には他の語彙の使用が不可欠である。相互運用性を促進し、再利用を容易にするために以下の語彙や用語の使用が推奨される。
集合体が何を含み、何を表現しているかをアプリケーションが理解するためには、OREを使って記述されたリソースにセマンティックなクラスを割り当てることが重要である。例えば、雑誌論文の集合体は、雑誌タイトル、雑誌の号、雑誌の巻次、オーバーレイジャーナル、雑誌の特別号、文献リスト、引用リストなどに型付けることができるだろう。
OREの幅広い適用範囲と必要とされる特異性を考えると、推奨されるクラスは極めてコンテキスト依存であるので、リストアップすることは不可能である。しかし、その重要性に応じてまとめられるクラスには一般的な語彙がいくつか存在する。また、通常、語彙はクラスと関係の両者を含んでいるが、ここでは推奨される語彙のクラスを簡単に記述する。
関係は2つの種類に分けられる。別のオブジェクトを参照するものと、関係の目的語が別のリソースではなくリテラル値のものである。両方に該当する抽象概念も存在する。例えば、権利記述は文字列または外部リソースへの参照として指定することができる。記述は、関係の主語または目的語を区別することなく、語彙の順番に並べた。
以下の項目で推奨される主語と目的語が記載されている場合、それがそのプロパティの正式な主語と目的語であると解釈するべきではない。それはそのプロパティをOREで使用する際の推奨にすぎない。例えば、ある実体が推奨される主語の欄に記載されている場合、それは、そのクラスのインスタンスを主語に、この関係を述語に持つトリプルを含めることを検討する価値があることを意味する。主語が 太字で記載されている場合は、その実体をリソースマップグラフにおける当該関係に含めることが必須である。他の実体も、適切であれば、これらの関係に含めることができる。また、用語に関連するすべての情報を一箇所で示すために、各関係において主要なクラスに対するAtomシリアライゼーションのマッピングも示している。
自由記述によるリソースの説明、または、その他の簡潔な記述的テキスト。リソースの想定使用法や概要を含めることができるだろう。何故作成されたか、何を含んでいるのか、といった集合体に関する情報の提供に使用することもできるだろう。内容要旨をエンコードするための、より具体的な関係については dcterms:abstract も参照のこと。
例:
my:aggregation dc:description "A collection of photographs of frogs" .
リソースのファイルフォーマット。これはMIMEタイプであることが推奨される。リソースマップを利用するアプリケーションがどんな種類のリソースが参照されているかを知ることができるようにするために集合リソースに、また、利用可能なすべてのフォーマット（複数ある場合）から最良のものを探す優先度で好みのフォーマットを指定できるようにするためにリソースマップに、この関係を使用するべきである。
例:
my:resource-map dc:format "text/atom+xml" . my:photo-1 dc:format "image/jpeg" .
リソースのテキストが書かれている言語。値としては、ISO 639-1 [ISO 639-1] などの既成の語彙の使用が推奨される。これは、複数の翻訳がある場合に、アプリケーションがユーザの好みの言語で集合リソースを表示できるようにするために使用することができる。
例:
my:description-of-photo-1 dc:language "en" .
リソースに設定されている権利に関する情報。これは自由記述のプロパティであり、機械に理解されることは期待されない。可能であれば、テキストの一部にクリエイティブ･コモンズ [Creative Commons] ライセンスへの参照を含むことが推奨される。権利情報を含む外部リソースを参照する方法は dcterms:rights を参照して欲しい。
例:
my:resource-map dc:rights """This resource map is free for non-commercial use
and attribution of its authorship must be maintained
(http://creativecommons.org/licenses/by-nc-sa/2.5/)""" .
リソースに与えられた名称。例としては、（通常は集合体や集合リソースとして）リソースマップで言及されている雑誌や図書、論文、画像、データセット、その他のリソースのタイトルがある。
例:
my:aggregation dc:title "Carl's Collection of Frogs" . my:photo-1 dc:title "Photo of a Green Frog" .
リソースの利用者として想定される、またはリソースが役に立つ実体のクラス。これは人（学生、教育者、開発者など）、またはデータセットやメタデータファイルなどの機械可読リソースを処理するソフトウェアのクラスになるだろう。例えば、画像やテキストは人が閲覧することを想定していると思われるが、XMLによる画像に関する技術メタデータの記述はソフトウェアエージェントの利用を想定していると思われる。
例:
my:photo-1 dcterms:audience foaf:Person .
リソースの作成またはその後の変更に貢献したエージェント。これはエージェントを識別するURIであるべきである。エージェントを識別するURIがわからない場合（例えば、誰か他の人の集合体を記述する場合）は、空白ノードか、エージェントに対して新規に作成されたURIを使用するできる。後者の場合は、urn:uuid スキーム [RFC 4122] によるUUID URNを使用することが推奨される。
例:
my:aggregation dcterms:contributor <http://www.csc.liv.ac.uk/~azaroth/self> .
リソースが準拠している既成の標準またはプロファイルへの参照。この関係の目的語は標準を示すリテラル名称ではなく、標準自体であるリソースでなければならない。リソースマップは、記述上または構造上の要件を持つコミュニティが定める複数のアプリケーションプロファイルまたはドメインプロファイルに準拠するかもしれない。集合リソースはいくつもの標準に準拠するかもしれない。
例:
my:aggregation dcterms:conformsTo <http://www.openarchives.org/ore/communities/images/imageProfile.xml> .
実体の作成に対して責任を負うエージェント。これはエージェントを識別するURIであるべきである。エージェントを識別するURIがわからない場合（例えば、誰か他の人の集合体を記述する場合）は、空白ノードか、エージェントに対して新規に作成されたURIを使用するできる。後者の場合は、urn:uuid スキーム [RFC 4122] によるUUID URNを使用することが推奨される。
リソースマップの creator として割り当てられるエージェントは人でなければならない。このリソースマップで示された表明の作成者だとみなされるのはこの人である。
例:
my:aggregation dc:creator <http://frogs.org/people/carl> .
Creator がこの実体を作成した時点。これは、ISO8601形式の文字列リテラルでなければならない。例えば、"2007-10-11T11:30:00Z"。
例:
my:resource-map dcterms:created "2007-10-11T11:30:00Z" .
リソースのファイルサイズ。この関係はアプリケーションが特定のリソースを取り込むべきか否かを決定できるようにすることや取り込みにかかる時間を推定するためのヒントを与えることに使用できるだろう。
例:
my:photo-1 dcterms:extent "534K" .
記述されたリソースの関連リソースであり、記述されたリソースはこのリソースの1つのバージョン、版、翻案である。これは、AtomのエントリIDとリソースマップの間の推奨される関係である。リソースマップのURIはリソースマップの保管場所が変わると変更されるが、エントリのIDは保管場所に変更があっても不変のままでいることができる。そのため、エントリIDは重複の排除や永続性にとって役に立つ。
例:
my:resource-map dcterms:isVersionOf <tag:atom-entry-1> .
実体が最後に更新された時点。これは、ISO8601形式の文字列リテラルでなければならない。例えば、"2007-10-11T11:30:00Z"。
例:
my:resource-map dcterms:modified "2007-10-12T14:00:00Z" .
記述された実体により、参照、引用、またはその他の理由で指し示された関連リソース。この関係は、引用を持つ文書を表す集合体またはリソース間のリンク付けに使用することができるだろう。また、集合体がWebサイトを表している場合は、ページ間の重要なハイパーリンクを表すのに使用できるだろう。
例:
my:aggregation dcterms:references your:aggregation-of-frogs .
記述されたリソースで置換されたリソース。この置換関係は、例えば、リソースマップや集合体、集合リソースの旧バージョンを指し示すのに使用できるだろう。この関係は、新しいリソースが集合体に追加されたが、旧バージョンの集合体も保持したい場合に使用できるだろう。
例:
my:aggregation dcterms:replaces my:previous-aggregation .
URIにより識別される、リソースに設定されている権利に関する情報。可能であれば、クリエイティブ･コモンズ [Creative Commons] のライセンスURIであることが推奨される。
例:
my:aggregation dcterms:rights <http://creativecommons.org/licenses/by-nc-sa/2.5/> .
主語の mailto URIフォーマット [RFC 2368] によるメールアドレス。これは、エラーや欠落の報告を受けられるようにリソースマップの作成者または管理者のメールアドレスを提供するのに使用できるだろう。
例:
<http://www.csc.liv.ac.uk/~azaroth/self> foaf:mbox <mailto:azaroth@liverpool.ac.uk> .
エージェントの個人名。これは、様々な役割の中から creator および contributor としてエージェントを識別するために使用されるURIと個人の名前を関連づけるのに使用されるべきである。
例:
<http://www.csc.liv.ac.uk/~azaroth/self> foaf:name "Rob Sanderson" .
エージェントに関連するドキュメント（通常はホームページ）。
例:
<http://www.csc.liv.ac.uk/~azaroth/self> foaf:page <http://www.csc.liv.ac.uk/~azaroth/index.html> .
リソースがそのインスタンスであるRDFクラス。これは、雑誌、テキスト、画像、個人などのセマンティックなクラスをリソースに割り当てるのに使用できるだろう。
例:
my:aggregation rdf:type ore:Aggregation .
主語であるリソースを定義しているリソースを示す。この関係は、OREにおいて関係 rdf:type を使って与えたカテゴリ用語またはタイプを借用したシソーラスまたは語彙を指定するのに使用できる。
例:
dcmitype:Image rdfs:isDefinedBy dcmitype: .
人間が読むことができるリソースの名前を提供する。これは rdf:type を使ってリソースに割り当てたタイプまたはカテゴリの表示用ラベルを提供するのに使用される。
例:
ore:Aggregation rdfs:label "Aggregation" .
関係 rdfs:seeAlso は、主語に関する付加的な情報を提供する可能性のあるリソースを指定する。例えば、リソースマップに直接含めることは現実的でない情報を含む、リソースマップや集合リソースに関するXMLメタデータレコードへの参照を含めるのに使用できるだろう。
例:
my:photo-1 rdfs:seeAlso my:description-of-photo-1 .
本書は、オープン･アーカイブズ･イニシアティブの成果である。OAIオブジェクトの再利用と交換プロジェクトは、アンドリュー･W･メロン財団、Microsoft社、全米科学財団から助成していただいた。さらに、ネットワーク情報連合からもご支援をいただいた。
本書は、OAI-ORE技術委員会（ORE-TC）の会議に基づいている。会議にはOAI-OREリエゾングループ（ORE-LG）も参加している。ORE-TCの委員は、次のとおりである。Chris Bizer（ベルリン自由大学）、Les Carr（サウサンプトン大学）、Tim DiLauro（ジョンホプキンス大学）、Leigh Dodds（Ingenta）、David Fulker（UCAR）、Tony Hammond（Nature出版グループ）、Pete Johnston（Eduserv財団）、Richard Jones（インペリアル･カレッジ）、Peter Murray（OhioLINK）、Michael Nelson（オールドドミニオン大学）、Ray Plante（NCSAおよび国立仮想天文台）、Rob Sanderson（リバプール大学）、Simeon Warner（コーネル大学）、Jeff Young（OCLC）。ORE-LGの委員は次のとおりである。Leonardo Candela（DRIVER）、Tim Cole（DLF AquiferおよびUIUC図書館）、Julie Allinson（JISC）、Jane Hunter（DEST）、Savas Parastatidis（Microsoft）、Sandy Payette（Fedora Commons）、Thomas Place（DAREおよびティルブルグ大学）、Andy Powell（DCMI）、Robert Tansley（Google, Inc.およびDSpace）。
また、OAI-ORE諮問委員会（ORE-AC）の意見にも感謝する。
