 |
HOME | HANDBOOK | FACTSHEETS | FAQs | RESOURCES | USERS | NEWS | MEMBERS AREA |
目次 前章: 3 解決 次章: 5 アプリケーション
この章では、DOI®システムの第2の主要構成要素にあたるDOI®データモデルの基礎と、これが既存メタデータスキーマを通じて割り当てられたDOI名メタデータの相互運用性を保証する能力について説明します。まずはシステムの概要を伝え、次にDOIデータモデルポリシーの目標（相互運用性、万全管理）とメタデータシステムの3つのツール（カーネルメタデータ、データディクショナリ、メタデータ交換のためのスキーマ）を別々の節で説明します。 この章と併せて用語集を参照することをお勧めします。
© 国際DOI財団 • 最終更新日: 2016年11月2日
4.1 DOI®データモデルの概要
4.2 DOIデータモデルポリシーの目標
4.2.1 相互運用性
4.2.2 管理能力
4.3 DOIメタデータ
4.3.1 DOI®メタデータカーネル
4.3.2 DOIカーネルの使用
4.3.3 DOIメタデータスキーマの管理手順
4.3.3.1 カーネル統制ボキャブラリへの値の追加
4.3.3.2 更新手順
4.3.4 DOIデータディクショナリ
4.3.5 ボキャブラリマッピングフレームワーク(VMF)
4.3.6 メタデータ統合：IDFの目標
4.4 メタデータの所要条件、ISO 26324
4.5 基礎となるオントロジー
メタデータがなければ識別子にほとんど価値はありません。本書において「識別される指示対象に関する情報」と定義されるメタデータとは、人や機械が識別される指示対象を利用するにあたって必要なデータを提供するものです。メタデータは名前、識別子、記述、タイプ、分類、場所、時間、測定値、関係のほかに、指示対象に関連するあらゆる種類の情報を含みます。
国際DOI財団（IDF）の登録機関(以下RA)によるメタデータの扱いには2通りあります。RAは指示対象の提供者から入力メタデータ（通常は指示対象の記述と関連する権利やポリシー）を収集します。RAはDOIシステムサービスをサポートするためある程度の出力を、すなわちサービスメタデータを、提供する必要があります。入力メタデータはサービスメタデータの一部または全部を提供します。場合によってはメタデータ宣言そのものが1つの完全なDOIシステムサービスになります（例えば「この指示対象のためONIXプロダクトメッセージを提供」）。図1にはメタデータ宣言の2つの流れが図示されています。
DOIシステムポリシーではRAの入力/サービスメタデータ宣言の形式や内容に制約を設けていませんが、入力メタデータはDOIカーネルに潜在する最低限の所要条件を満たさなければなりません（下記参照）。RAは独自のメタデータスキーマやメッセージを規定できるほか、既存スキーマの一部または全部を自身の入力/サービスメタデータ宣言に使用することもできます。
DOIデータモデルポリシーはメタデータの内部管理と「RAネットワーク」の中でのRA間のメタデータ交換に関係しており、以下に記す2つの目標の達成を目指しています。
DOIデータモデルにはメタデータポリシーを支援する3つのツールがあります。
RAの責務は3つの文に要約できます。
これらの責務が全てのDOI名で義務付けられるわけではありません。例外は次節で述べる相互運用性要件の観点で検討されます。
DOIデータモデルポリシーの第一の目標はDOI名ユーザーのネットワークの中で相互運用性を促進することです。このため、本章で説明するように異なるRAの間で「意味的妥当性」を成立させる手段が用意されています。
どんな種類の標準化も相互運用性の必要に迫られて進められます。RAが指示対象に発行するDOI名が、メタデータの収集や出力を当該RAが全面的に支配できる私的領域（プライベートドメイン）の中で使われるものなら、標準化の必要はありませんし、DOIデータモデルに関する義務に従う必要もありません。このRAは自身のスキーマと宣言を取り決め、提供者とユーザーにはこれに従うことが望まれます。このような状況は DOIシステムの限定的運用 であり、通常はある団体が自身の私的組織の中だけで使用するDOI名を発行するという特別な目的のためRAになる場合に当てはまります。
ただしこのように孤立した状況は稀です。通常、指示対象にDOI名が発行されるときには相互運用性について基本的前提が成立します。つまり、RAや指示対象の提供者は（現在または将来的に）そのDOI名が他のRAによって提供されるサービスで利用可能となることを望みます。例えば複数のRAが出版者の異なるジャーナルの記事にDOI名を発行する場合、それらのRAと出版者は自分たちのDOI名を他のRAによって提供されているジャーナル関連サービスに入れてもらうことを望むでしょう。
同様に、多くのRAが他のRAから発行されたDOI名を自身が提供しているサービスに入れることを望むでしょう。このような相互運用性はDOIシステムの大きな利点のひとつです。
RAの輪が広がるにつれてこのような要求が浮上しており、また具体的にはなっていませんが、将来的には他の分野においても同様の要求が現れると予測されます。このような状況で、RAと指示対象提供者は同じ指示対象に第2のDOI名を発行したり、入力メタデータの提供や収集を最初からやり直すことを望みません。
加えて、DOIシステムサービスの一部は将来的にRAの直接責任ではなくなる可能性があります。様々なRAが様々なアプリケーションプロファイルを使って発行したDOI名を利用するサービス提供業者は、メタデータの相互運用性の問題に直面することになります。
相互運用を意図する — DOI名には、すなわち発行元RA— の直接管轄下にないサービスで使われる可能性のあるDOI名には、DOIデータモデルポリシーが適用されます。メタデータ相互運用性の目標は2つの課題に表すことができます。
1つ目の課題にはDOIカーネルで対処します。2つ目の課題にはDOI指示対象メタデータ宣言（RMD）とデータディクショナリ（DD）の交換規定で対処します。
DOIデータモデルポリシーの第2の目標は「RAによるDOI名の管理で最低限のクオリティ水準を確保し、DOIシステム全体の管理を円滑化する」ことです。この目標は第1の目標（相互運用性）を後押しするものとみなすこともできますが、厳密には、RAになる見込みがある組織に責任をもってDOI名を発行する力があることを確認し、紛らわしいDOI名がネットワークの中に入り込まないようにするという課題に対処するものです。
データモデルポリシーでは簡単な試験でRAの能力を試すことになっています。この試験ではDOIカーネル宣言を行う能力が問われます。それには、明確なDOI名割り当てを支援する内部システムを整備し、ネットワークの中で相互運用性を万全に支持できる健全性がRAに求められます。DOI名の割り当て日やDOI名を割り当ててもらった登録者の身元に関する記録を管理することもRAに求められます。
DOIデータモデルポリシーは、DOIシステム全体の管理を円滑化する仕組みの将来的発展を支援するものでもあります。それには、例えばデータディクショナリに登録された用語をタイプとして使用してDOI名、サービス、アプリケーションプロファイルを分類する必要があります。
DOI等の識別子は、識別される物が何なのかを説明/記述するある程度のメタデータがなければ、価値がありません。メタデータに対するDOIのアプローチには2つの特徴があります。第1の特徴として、DOI規格はDOI名の指示対象を記述する最低限のメタデータ（「カーネル」メタデータ）を義務付けています（XMLスキーマでサポート）。第2の特徴として、国際DOI財団（IDF）は相互運用性を促進し、RAによる独自のスキーマの作成を支援するため、カーネルで使われる用語やRAによって登録された用語を含むデータディクショナリ（オントロジー）を提供し、ボキャブラリマッピングフレームワークと呼ばれるマッピングツールをサポートしています。本節ではこれらのリソースについて説明します。
「DOIカーネル」は認識と相互運用性という2つの目標を持つ最小限のメタデータです。
この文脈における「認識」は、カーネルメタデータでDOI指示対象にあたる物の種類を（様々な分類によって）明確に示し、ユーザーが（様々な名前、識別子、関係から） その物を妥当な精度で識別できるようにすることを意味します。これらの条件は相補的関係にあります。つまり、（例えば）何かが「カサブランカ」だということが分からなくても、それが映画かDVDだと分かるようにしなければなりませんし、その逆もまたしかりです。指示対象の発見には認識が求められます。偶然か故意に指示対象が発見されたときにユーザーに情報を提供するためにも認識が求められます。メタデータのユーザーは人か機械です。カーネルの構造から指示対象の一意な記述（曖昧性の解消）が提供されるとは限りませんし、場合によってはさらに特化されたメタデータ要素が必要になります。実際にはreferentNameへ追加的記述テキストを加えることで一意な記述を確実に達成できますが、この追加的テキストが正式な分類、測定値、識別子、時間等の構造化されたコンテクスト型メタデータの代わりに使われると、相互運用性の第2の目標が損なわれるため、申し分のない方法とは言えません。
この文脈における「相互運用性」とは、異なるDOI RAからのカーネルメタデータを結合できること、または意味論的なマッピングや変換を行わなくても同じソフトウェアで問い合わせができることを意味します。相互運用性は、データ要素やその値が多様なメタデータスキーマに対して共通である場合に実現します。カーネルは共通のコア要素と分類を義務付けることによってこれを実現しますが、この方法による相互運用性には当然限りがあります。
DOI名の割り当てにあたっては、そのDOI名が割り当てられようとしているオブジェクトを記述するメタデータを登録者が提供する必要があります。最低でもこのメタデータはDOIカーネルメタデータ宣言（別名DOIカーネル）で構成されなければなりません。データ要素（子要素、基数等）と現在の許容値とXML表現の仕様はIDF（ISO 26324登録認定機関）によって管理されています。
表4.1および4.2にはDOIカーネルの要素が記載されています。これらの表はISO 26324の表B.1およびB.2に基づいています。注：下表にはISO 26324以外の追加用語が入る可能性がありますが、追加される可能性があるのは、新しい項目を登録できるオープンリストの用語だけです。したがって下表はISO 26324に完全に整合しています。DOIカーネルのXSD（XMLスキーマ）はIDFによって管理されています。（最新版リリースノートのDOIカーネル XMLスキーマ ページとスキーマへ至るリンク、ならびにDOIカーネルXMLスキーマポリシーの解説を参照してください。）このスキーマには要素の追加的な子要素が含まれます。
表4.2にはDOIカーネルメタデータ宣言の基礎的管理要素が記載されています。これらの要素はDOI名の発行と登録記録そのものに関係するものです。DOIカーネル以外の他の要素と子要素については、必要に応じて値を作成できます。異なるソースからのDOIデータの一元化を促進するため、そのような値はIDF（ISO 26324登録認定機関）の管轄下にあるデータディクショナリに登録しなければなりません。
表4.2にはDOIカーネルメタデータ宣言の基礎的管理要素が記載されています。これらの要素はDOI名の発行と登録記録そのものに関係するものです。DOIカーネル以外の他の要素と子要素については、必要に応じて値を作成できます。異なるソースからのDOIデータの一元化を促進するため、そのような値はIDF（ISO 26324登録認定機関）の管轄下にあるデータディクショナリに登録しなければなりません。
表4.1：DOIカーネルメタデータ宣言の記述的要素
| カーネル要素 | 発生 | 説明 |
| DOI name | 1 | 識別される指示対象に割り当てられる特定のDOI名。 |
| referentIdentifier(s) | 0-n | 同じ指示対象を指し示す他の識別子（例：ISAN、ISBN、ISRC、ISSN、ISTC、ISNI）。 この要素はprimaryReferentTypeに適したタイプ要素を含みます。現時点におけるスキーマはcreationIdentifierTypeとpartyIdentifierTypeを認識します。これらは新しい許容値を登録できるオープンリストです。 |
| referentName(s) | 0-n | 一般に通用している指示対象の名称（例：title）。 この要素はprimaryReferentTypeに適したタイプ要素を含みます。現時点におけるスキーマはcreationNameTypeとpartyNameTypeを認識します。これらは新しい許容値を登録できるオープンリストです。 この要素は言語要素も含みます。その許容値リストはISO 639-2コードリストです。 |
| primaryReferentType | 1 | 指示対象の一次タイプ（例： creation、party、event）。これはオープンリストであり、新しいprimaryReferentTypeを登録できます。 |
| structuralType | 1 | 指示対象の一次structuralType。 creationsには全体的形態による分類が可能な4つの相互排他的な creationStructuralType（(physical、digital、performance、abstraction）があります。 structuralTypeは互いに内包されることがありますが、指示対象のstructuralTypeは全体的形態によって決まり［例えばCD（physical）は、歌の演奏の録音（abstraction）を含むファイル（digital）を含むことがあります］、コンテンツの要素は必要に応じreferentTypeでさらに分類できます。 partiesには3つの相互排他的なpartyStructuralTypes (person, animal, organization)があります。これらのリストはクローズされています。 |
| mode | 0-n | creationsのみ。指示対象を知覚する主要感覚モード（audio、visual、tangible、olfactory、tasteable、none ）。modeは意図された主要知覚モードだけを識別するものです。ほとんどの物理的資源は五感の全てで知覚できますが、中には取るに足りない知覚もあります。例えば印刷された本は触れたり嗅いだりできますが、これらの知覚は視覚モード（コンテンツキャリヤとして意図された機能）を補うか視覚モードに付随するものです。しかし、点字本の場合はtangibleが主要モードとなります。このリストはクローズされています。 |
| character | 0-n | creationsのみ。指示対象のコンテンツが表明される基本的伝達形態。4つの値music、language、image、otherがあります。このリストはクローズされています。 |
| referentType | 0-n | partiesの場合に指示対象のタイプを指定します（author、composer、book publisher、library、university、financial institution、film studio）。 creationｓの場合、指示対象のコンテンツの抽象的性質は、creationStructuralTypeに関わりなく、通常はcreationTypeによって記述されます。これは必要に応じ フォーマット要素やジャンル要素を含めて拡張できます（例：audio file、scientific journal、musical composition、dataset、serial article、eBook、PDF）。 partiesの場合、referentTypeはpartyに関連しassociatedPartyRoleによって記述される役割です（例：Composer、Author、BookPublisher、JournalPublisher)）。 これはオープンリストであり、新しいreferentTypeを登録できます。 |
| linkedCreation | 0-n | creationsのみ。 referentCreationに関連付けられた別のcreation（産物）。 この要素は creationRoleToCreation要素を含みます。これは新しい許容値を登録できるオープンリストです。 |
| linkedParty | 0-n | partiesのみ。 referentPartyに関連付けられた別のparty（当事者）。 この要素はpartyRoleToParty要素を含みます。これは新しい許容値を登録できるオープンリストです。 |
| principalAgent | 0-n | creationsのみ。指示対象のcreation（産物）やpublication（出版物）について主たる責任を担うエンティティ。 この要素は役割を指定する agentRole 要素を含みます（例：Creator、Author、BookPublisher)）。これは新しい許容値を登録できるオープンリストです。 |
| dateOfBirthOrFormation | 0-1 | partiesのみ。 referentPartyの出生日（個人または動物の場合）または設立日（組織の場合）。 |
| dateOfDeathOrDissolution | 0-1 | partiesのみ。referentPartyの死亡日（個人または動物の場合）または解散日（組織の場合）。 |
| associatedTerritory | 0-n | partiesのみ。referentPartyに関連する 領域(例：出生地域、国籍、居住地）。許容値リストはISO 3166a2領域コードリストです。 |
表4.2：DOIカーネルメタデータ宣言の管理要素
| カーネル要素 | 発生 | 説明 |
| registrationAuthorityCode | 1 | このDOI名を発行した機関（ISO 26324登録認定機関により認可）の名称を表すため割り当てられるコード。 |
| issueDate | 1 | このDOI名が発行された日。 |
| issueNumber | 0-1 | DOIカーネルメタデータ宣言の特定のバージョンに付けられる番号またはその他の表示。 |
登録機関には、最低でも発行される各DOI名につきDOIカーネルメタデータ宣言が行われるよう徹底することが期待されます。それには2通りの方法があります。つまり、DOIカーネルXSDを使って宣言を行う方法か、DOIカーネルの要素をRAによって発行されるより広範なメタデータスキーマの中に組み入れる方法です（より一般的な方法）。
登録機関には、求められない限りはDOIカーネルメタデータを作らないという選択肢があります。つまり、必要に応じて内部表現から変換することもできます。
登録者が気にかけるべき最小限のメタデータセットは、登録者の事業要求を満たす必要最低限のメタデータセットであり、常にそれよりずっと少ない技術的に最低限必要なカーネルではありません。カーネルスキーマが義務付けるデータ要素はごく僅かです。登録者がサプライチェーンパートナーに伝えるべきデータは何かについて考えると、最小限のメタデータセットは必要条件にすぎず、それだけで十分というわけではありません。
「スキーマ」はDOIの運用を支援することを目的とするソフトウェアや文書化された一連のメタデータ要素を含みます。通常これはXMLスキーマかRDFスキーマか何らかのプロセスに使われる既定の語彙です。RAの間では、特にリンクトデータ（Linked Data）として共通の機械可読DOIメタデータスキーマを実装した場合の利点についての検討が活発化しています。現在は、メッセージに使用する許容値セットを含むDOIデータディクショナリとメタデータカーネルという2つのDOIメタデータスキーマが存在します。IDFウェブサイトの会員セクションではデータディクショナリの全容が公表されています。カーネルはIDFウェブサイトでXMLスキーマとして公表されています。
多くのカーネル要素は統制語彙によって決められた値（「許容値セット」）を持ちます。上記の表ではこれらの値が太字で強調されています。これらのリストのうち、以下のリストは、RAによる値の追加ができないクローズドリストです。
creationStructuralType
partyStructuralType
mode
character
language (ISO 639-2)
territory (ISO 3166a2)
以下のリストはRAが新しい値を追加できるオープンリストです。
primaryReferentType
agentRole
creationType
creationIdentifierType
creationNameType
creationRoleToCreation
associatedPartyRole
partyIdentifierType
partyNameType
partyRoleToParty
RAは新しい値をDOIデータディクショナリに登録することによってリストに追加できます（下記参照）。
既存のDOIスキーマに変更を加える権限はDOI-RATechグループにあります。同グループのメンバーはスキーマへの更新や新たなスキーマの導入を随時提案できます。変更実施の責任はIDFの選定技術提供者が担います。選定技術提供者はスキーマの管理者として提案を承認し、提案された変更の範囲と複雑さに応じて完了時間を見積ります。通常の変更の場合は2週間程度です。手順は次の通りです。
カーネルで使われる要素と許容値はどれもDOIデータディクショナリに収録されています。DOIデータディクショナリはDOIメタデータの秩序ある発展を支援するために作られた階層型オントロジーです。ここではディクショナリの範囲、構造、保守を詳しく紹介します。
ディクショナリへの用語追加はRAの要請を受けて行われます。メタデータカーネル/許容値を変更することもあれば、メタデータカーネルに加えて他のDOIメッセージスキーマを公開することもあります。どのRAでも新しい値をIDFに登録することによってオープン形式の許容値セットに新しい値を加えることができます。
ISO 26324に記載されているように、DOIメタデータ仕様で使われる全てのデータ要素と許容値（各要素の値として使用できる項目）を収録するデータディクショナリでは、全てのRAがメタデータ要素のオントロジーにおける定義を利用できるようにし、データ交換に必要なメタデータの一元化と変換を支援するためのマッピングを提供しなければなりません。必要に応じ、特定のサービスのためにメタデータが統合される場合があります。この場合はデータディクショナリがデータマッピングを提供し、統合されたメタデータがあたかも1つのセットから提示されるようにしなければなりません。カーネルメタデータで登録者によって使用される許容値はデータディクショナリにすべて登録しておかなければなりません。
DOIデータディクショナリはボキャブラリマッピングフレームワーク (VMF)の中で管理される名前空間として実装され、保守されます。
ユーザーはデータディクショナリの基礎となるコンセプトや構造を理解しなくてもデータディクショナリを利用できます。データディクショナリの主な特徴は次の通りです。
国際DOI財団（IDF）の基本的役割は、その作業が専門家による評価を受け、実用的環境の中で試験され、堅実な原則に基づいていることをユーザーに保証することです。データディクショナリの方法論はW3Cオントロジー言語OWL-DLに照らして検証済みです。データディクショナリの基礎をなすオントロジーは、インデクス（電子商取引におけるデータの相互運用性）構想に端を発し、広く認められ、様々な主要メタデータスキーマで運用されています。インデクスは、コンテンツ、著者、クリエータ、図書館、出版者、権利コミュニティからの参加者によって進められた影響力のあるマルチメディアメタデータプロジェクト（1998～2000年）で、デジタルトランザクションの統合ソリューションとしてイベント方式のメタデータモデルを開発しました。 ファクトシート「インデックスフレームワーク」を参照してください。
RAのスキーマと他のスキーマとDOI以外のオントロジー（ONIX、DDEXメッセージ規格等）の相互運用性を促進するため、IDFはボキャブラリマッピングフレームワーク (VMF)を支持、推奨しています。VMFウェブサイトをホストするIDFはVMF管理構造の一部にもなっています。VMFは複数のコミュニティにわたって意味論的な相互運用性を支援するダウンロード可能なツールで、主要コンテンツメタデータ規格からの語彙の広範で権威あるマッピングを提供しながら、コミュニティの枠を越えた相互運用性を支援します。
VMFは既存RDA/ONIX構想をリソースリレータとカテゴリの包括的語彙に発展させたものであり、それらのスーパーセットは出版者/製作者、教育、書誌/遺産分野の主要規格で使用されています（CIDOC CRM、DCMI、DDEX、DOI、FRBR、MARC21、LOM、ONIX、RDA）。
IDFはこれまでVMFの開発を支援し、RAによるVMFの利用（カーネル/非カーネルメタデータ要素の他スキーマへのマッピング）を奨励し、VMF技術チームとの協議を推進しています。
国際DOI財団（IDF）はメタデータの自動統合がデジタル商取引・文化のためのツールとしてのDOIの可能性を存分に引き出す鍵と考えています。これはセマンティックウェブとリンクトデータ（Linked Data）の基本目標でもあります。ウェブは、現在のように人が使うための情報を提供するドキュメントのネットワークとしてだけではなく、構造化され相互にリンクされた機械処理可能な情報のための媒体として捉える必要があります。
ここで説明するツール（カーネル宣言、DOIデータディクショナリ、VMF）は、優れた実践の基礎と、様々なDOI指示対象に対するメタデータ統合の出発点を提供します。リンクトオープンデータ（Linked Open Data）をはじめとする取り組みはさらなる基盤（インフラ）を提供しますが、これは技術と構文に限ります。これらの取り組みは共有意味（「意味的妥当性）レベルでのデータセット自動統合ソリューションを提供しません。自動統合ソリューションとは、人間の介入や一対一型の大量の「閉鎖的」ソリューションに頼ることなく、異なるRA等から提供されるサービスの連係を実現するものです。
鍵となるのは十分に構造化されたメタデータスキーマの開発と、DOIデータディクショナリやVMFをはじめとするツールの意味論的マッピング能力を利用するサービスの開発です。IDFはそのようなサービスの開発に協力することを選ぶRAに支援を提供します。
ISO26324（DOIシステムのISO規格）にはDOIメタデータの特徴と所要条件について次のように書かれています。「指示対象に関わるサービスと記述と識別を支援するため、オブジェクトは、望ましい精度と粒度のメタデータをDOI名の指示対象に対応付けることを可能にする体系的データモデルに基づき、DOIメタデータで明確かつ正確に記述しなければならない。」これには次のような目的があります。.
DOIメタデータは以下に記す機能をサポートしなければなりません。
例: 音声搬送波、書籍、ビデオ、写真をそれぞれ異なる（似ていたとしても異なる）特徴を持つ基本的に異なる物として扱う代わりに、同じ高水準属性で異なる値を持つ産物として認識し、そのメタデータは共通の環境の中でサポートできる。
DOI名が割り当てられるオブジェクトを記述し識別するメタデータは、速やかに、正確に、記録しなければなりません。複数の既存スキーマにわたって相互運用性を促進するため、DOIメタデータ仕様で使われるデータ要素と許容値はリポジトリに入れなければなりません。データ要素と許容値のリポジトリとしてデータディクショナリを使用しなければなりません。メタデータはDOIカーネルメタデータ宣言の最低限の要件を満たさなければなりません。
DOIデータモデルの基礎となるコンテクスチュアルオントロジー手法はほかにも多くの用途に使われています（第1章：はじめに、第1.6.5節参照）。IDFはこのデータモデルを整備し、さらなる拡張、応用に結び付けるよう徹底しています。RAやアプリケーション開発者はDOIシステムの使用にあたってコンテクスチュアルオントロジーにアクセスする必要はありませんが、アクセスを望む場合はアクセスできます。高水準概念モデルの説明図はここにあります。また、ボキャブラリマッピングフレームワークや関連資料の一部としてさらなる文書を入手できます。詳細についてはIDFに問い合わせてください。
前章: 3 解決 次章: 5 アプリケーション
|
®, DOI®、DOI.ORG®及びshortDOI®は国際DOI®財団 (IDF)の登録商標です。 |