Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://www.asahi-net.or.jp/~ax2s-kmtn/internet/skos/REC-skos-reference-20090818.html below:

SKOSリファレンス

SKOSは、いくつかの異なる分野の知識、技術、慣行の橋渡しを行い、データを共有するための規格です。

図書館情報学では、図書や工芸品などの膨大な収集物を組織化するためのツールの開発に、長く卓越した伝統がささげられています。一般的に、これらのツールは、「知識組織化体系」(KOS、knowledge organization systems)として、また、時には「統制構造化された語彙」として知られています。やがて、実践コミュニティや合意済みの標準がそれぞれにサポートする、いくつかの似て非なる様式が現れてきました。シソーラス、分類表、件名標目表、タクソノミーを含む異なる系統の知識組織化体系が、現代そして従来の情報システムで広く認められ適用されています。実際には、シソーラスや分類表、タクソノミーは、これらの異なる系統を大まかに特徴付けるためにいくつかのプロパティーを使用できますが、これらの完全な線引きは困難でありえます（例えば、[BS8723-3]を参照してください）。SKOSに関する重要なポイントは、そのユニークな特徴に加え、これらの系統のそれぞれにかなり共通点があり、同じような方法で利用されているということです[SKOS-UCR]。しかし、現在は、これらの知識組織化体系をデータとして表現し、それらをコンピュータ・システムの間で交換するための広く用いられている標準はありません。

W3CのSemantic Web Activity [SW]は、データベース・システム、形式論理学、WWWの境界において、新しい分野の統合的な研究技術開発を促進させました。この業績は、セマンティック・ウェブの基礎となる標準の開発につながりました。RDF（Resource Description Framework）は、ウェブに対し、共通のデータの抽象化と構文を提供します。RDF語彙記述言語（RDFS）とウェブ・オントロジー言語（OWL）はともに、ウェブ上のデータに対し、共通のデータ・モデル化（スキーマ）言語を提供します[RDFS] [OWL-GUIDE]。SPARQLクエリ言語およびプロトコルは、ウェブ上のデータと相互作用を行うための標準的な手段を提供します[SPARQL]。

多くのアプリケーションは、異なる情報源のデータを公開、共有、交換、統合（「結合」）するための共通の枠組みが必要であるため、これらの技術は、様々なアプリケーションにまたがって適用されています。異なるコミュニティが今まで別個の情報源に散在していたデータの隠れた価値を開発したいと考えていたため、様々な情報源のデータをリンクする性能は多くのプロジェクトを動機づけています。

セマンティック・ウェブのビジョンの一面は、情報を発見、共有するための新しいルートを提供し、ウェブ上の膨大な統一性のない（つまり、人間が読める）情報をより良く組織化したいというものです。RDFSとOWLは、形式的に定義された知識表現言語で、コンピュータ処理に適した意味を表現する方法、ウェブ上の既存の情報を補足し構造を付与する意味を表現する方法を提供します[RDF-PRIMER] [OWL-GUIDE]。しかし、実際には、まとまった量の情報にこれらの技術を適用するためには、大規模な情報資源の正確な記述（つまり、アノテーションや目録作成）に加え、特定領域の知識に関する詳細なマップを構築する必要がありますが、これらの多くは、大規模であるために自動的に行えません。米国議会図書館の件名標目[LCSH]や国連食糧農業機関のAGROVOCシソーラス[AGROVOC]のように、多くの既存の知識組織化体系が既に開発・利用されているため、情報と知識の組織化に関する図書館情報学において蓄積された経験とベスト・プラクティスは、明らかにこのビジョンを補足し、適用しうるものです。

したがって、SKOSは、知識組織化体系の設計と応用に関わる図書館情報学の異なる実践コミュニティの架け橋となることを目指しています。さらに、SKOSは、既存の知識組織化モデルをセマンティック・ウェブ技術のコンテキストに移植し、既存の知識組織化体系をRDFに移植するための安価な移行パスを提供することにより、これらのコミュニティとセマンティック・ウェブとの架け橋になることを目指しています。

将来を見据え、SKOSは、不統一な情報の開発・分析、非形式的で社会が介在した大規模な情報の組織化、知識の形式的な表現の間に位置しています。図書館情報学において知識組織化に関して蓄積された経験と知恵をセマンティック・ウェブの技術的なコンテキストに利用、適用、転換可能にすることにより、既存のセマンティック・ウェブ技術（とりわけ、OWLなどの知識表現の形式的な体系）を補う形で、SKOSは多くの新しく有益な応用を可能にし、それが技術と実務の両方における新たな統合的な研究開発の方向につながることが望まれます。

SKOSは、シソーラス、分類表、件名標目表やタクソノミーなどの知識組織化体系のための一般的なデータ・モデルです。SKOSを用いて、知識組織化体系を機械可読データとして表現できます。次に、これをコンピュータ・アプリケーション間で交換し、ウェブ上で機械可読形式で公開できます。

この仕様では、SKOSデータ・モデルは、OWL Fullオントロジー[OWL-SEMANTICS]として形式的に定義されます。SKOSデータは、RDFトリプル[RDF-CONCEPTS]として表され、任意の抽象RDF構文（RDF/XML[RDF-XML]またはTurtle [TURTLE]などの）を用いることでコード化されるかもしれません。SKOS、RDFとOWLの関係の詳細に関しては、次の項を参照してください。

SKOSデータ・モデルは、知識組織化体系を、概念を包括する概念体系であるとみなします。これらのSKOS概念体系とSKOS概念は、URIで識別され、誰でもが一意に任意のコンテキストからそれらを参照できるようにし、それらをWWWの一部にします。SKOS概念の識別と記述の詳細は、3項. skos:Conceptクラスを、概念体系の詳細は4項. 概念体系を参照してください。

「romantic love」や「れんあい」のような、英語や日本語（ここでは、ひらがなで記述）などの任意の自然言語で、いろいろな字句（Unicode）文字列でSKOS概念をラベル付けできます。任意の言語によるこれらのラベルは、その言語に対する優先ラベルで示したり、代替ラベルで示したりすることができます。ラベルは「hidden（非表示）」にもでき、これは、テキストのインデックスで知識組織化体系に問い合わせを行う場合に有用です。SKOS字句ラベル付けプロパティーの詳細は、5項. 字句ラベルを参照してください。

1つ以上の表記法をSKOS概念に割り当てることができ、これは、特定の概念体系の範囲内で一意に概念を識別するために用いられる字句コードです。コンピュータ・システム内でSKOS概念を識別する望ましい方法はURIですが、表記法は、蔵書目録で用いられる分類コードなどのように既に用いられている他の識別体系との橋渡しを行ってくれます。表記法の詳細は、6項. 表記法を参照してください。

SKOS概念は、各種の注記をドキュメント化できます。SKOSデータ・モデルは、とりわけ、スコープ・ノート、定義、編集注記をサポートした基本的なドキュメンテーション・プロパティーの集合を提供します。この集合は、完全なものではなく、サード・パーティーがより多くの特殊な注記をサポートするために拡張可能なフレームワークを提供するものです。注記の詳細は、7項. ドキュメンテーション・プロパティーを参照してください。

SKOS概念は、意味関係プロパティーを用いて他のSKOS概念にリンクできます。SKOSデータ・モデルは、SKOS概念間の階層リンクと関連リンクをサポートします。またもや、SKOSデータ・モデルのあらゆる部分と同様に、サード・パーティーは、より特定的な必要性をサポートするためにこれらを拡張できます。SKOS概念のリンク付けの詳細は、8項. 意味関係を参照してください。

SKOS概念は、集合にグルーピングでき、これは、ラベル付け、および/または順序付けできます。SKOSデータ・モデルのこの機能は、シソーラス中のノード・ラベルに対するサポートを提供するためのものであり、概念の順序付けが重要であったり何らかの有益な情報を提供する状況に対してサポートを提供するためのものです。集合の詳細は、9項. 概念集合を参照してください。

SKOS概念は、異なる概念体系の中の他のSKOS概念にマッピングできます。SKOSデータ・モデルは、階層、関連、類似、完全の4つの基本的な形のマッピングをサポートします。マッピングの詳細は、10項. マッピング・プロパティーを参照してください。

最後に、SKOSに対する拡張は、付録B. ラベル用SKOS拡張（SKOS-XL）で定義されています。SKOS-XLは、字句エンティティの識別、記述、リンクに対し、より多くのサポートを提供します。

SKOSデータ・モデルの要素はクラスとプロパティーであり、データ・モデルの構造と完全性は、これらのクラスとプロパティーの論理的な特性によって、また、これらの相互依存性によって定義されます。SKOSは、より高度なアプリケーションでは、定義域に関する知識を表現し交換するOWLと併用できるため、恐らくこれは、SKOSの最も強力な、しかし、潜在的に厄介な側面の1つです。しかし、SKOSは形式的な知識表現言語ではありません。

この違いを理解するには、形式的なオントロジーで明確化された「知識」が、公理と事実の集合として表現されることを考えてみてください。シソーラスや分類表は、完全に異なる性質のものであり、いかなる公理や事実も言明しません。シソーラスや分類表は、むしろ、自然言語や他の非形式的な手段により、時に便宜上「概念」と呼ばれる、様々な考えや意味の集合を識別・記述します。この「概念」は、様々な構造（最も一般的には、階層構造と関連性ネットワーク）で配列し、組織化することもできます。しかし、これらの構造は形式的なセマンティクスを持たず、世界（world）に関する形式的な公理か事実のどちらかとして確実に解釈することができません。実際に、これらは、決してそれを目的としたものではありませんでした。というのは、これらは、ある主題領域に関する便利で直感的なマップの提供のみを行う役割を持つものだからです。そして、これは、その後に、その領域に関連するドキュメントなどの対象を組織化し発見するための補助ツールとして使用できます。

シソーラスや分類表に組み込まれた「知識」を任意の形式的な目的で明確化するためには、シソーラスや分類表を形式的オントロジーとして再編成する必要があります。言い換えれば、誰かが構造と、シソーラスや分類表の知的コンテンツとを形式的な公理と事実に変換する作業を行わなければなりません。この変換作業は、知的に過酷、かつ、時間を要し、したがって、費用がかかります。シソーラスなどを、そのまま、非形式的な、主題領域内のナビゲーション用の便利な構造として用いても、多くを得ることができます。そのままでそれらを用いると、再編成が必要でなく、したがって、あまり費用はかかりません。さらに、一部のKOSは、設計上、その領域の論理ビューを示すように作られていません。実際に、そのようなKOSを形式的な論理ベースの表現に変換すると、元々意図した目的に合わない表現になってしまうという変化をもたらすかもしれません。

しかし、OWLは強力なデータ・モデル化言語を提供します。したがって、OWLは、シソーラスや分類表をそのまま表現するためのデータ・モデルを構築するために使用できます。これが、まさにSKOSが行うことです。このアプローチをとると、シソーラスや分類表の「概念」は、SKOSデータ・モデルで個体としてモデル化され、シソーラスや分類表から得られたそれらの「概念」に関する非形式的な記述と「概念」とのリンクは、決してクラスやプロパティーの公理としてではなく、それらの個体に関する事実としてモデル化されます。これらが「概念Xは、優先ラベル'Y'を持っており、シソーラスZの一部である」などの、シソーラスや分類表自体に関する事実であることに注意してください。これらは、形式的なオントロジーで表現されているかもしれないため、特定の主題領域内に世界がどのように配置されるかに関する事実ではありません。

その後に、SKOSデータは、RDFトリプルとして表現されます。以下のRDFグラフ（1.7.3項で論じるように[TURTLE]による)は、シソーラスに関するいくつかの事実を表現します。

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:altLabel "adoration"@en ;
  skos:broader <B> ;
  skos:inScheme <S> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en ;
  skos:altLabel "feeling"@en ;
  skos:topConceptOf <S> .

<S> rdf:type skos:ConceptScheme ;
  dct:title "My First Thesaurus" ;
  skos:hasTopConcept <B> .

このポイントは、SKOSデータ・モデルの形式的な定義と、それをソフトウェア・システムにどのように実装できるかを理解するために欠かせません。このポイントは、特にSKOSとOWLをハイブリッドな形式的/準形式的設計の一部として組み合わせて用いる場合に、SKOSのより高度なアプリケーションにも欠かせません。

しかし、ユーザの観点からは、形式的な知識表現体系と、非形式あるいは準形式的な知識組織化体系との区別は、当然、不明瞭になるかもしれません。言い換えれば、以下のグラフの<A>と<B>は個体（skos:Conceptのインスタンス）であり、<C>と<D>はクラス（owl:Classのインスタンス）であることは、ユーザには関係ないかもしれません。

<A> rdf:type skos:Concept ;
  skos:prefLabel "love"@en ;
  skos:broader <B> .

<B> rdf:type skos:Concept ;
  skos:prefLabel "emotion"@en .

<C> rdf:type owl:Class ;
  rdfs:label "mammals"@en ;
  rdfs:subClassOf <D> .

<D> rdf:type owl:Class ;
  rdfs:label "animals"@en .

しかし、SKOSデータ・モデルを意識した情報システムは、この区別をよく理解している必要があるでしょう。

SKOS用RDFスキーマとラベル用SKOS拡張（SKOS-XL）に関しては、付録C. SKOSおよびSKOS-XL名前空間ドキュメントで記述されています。スキーマで完全には捕捉できない制約があるため、RDF/XMLドキュメントがこの仕様の規範的なサブセットを提供することに注意してください。

RDFおよびOWL Fullのセマンティクスの下では、RDFグラフの形式的な意味（解釈）は、真偽値[RDF-SEMANTICS][OWL-SEMANTICS]です。つまり、RDFグラフは、真または偽として解釈されます。

一般的に、RDFグラフが真になりえなければ、矛盾していると言われます。言い換えれば、矛盾を含んでいれば、RDFグラフは矛盾しています。

RDFとRDFS語彙を単独で用いると、矛盾した記述は、事実上不可能です。OWL語彙を同様に用いた場合には、矛盾を記述する多くの方法があります。例えば、次のRDFグラフをご覧ください。

<Dog> rdf:type owl:Class .<Cat> rdf:type owl:Class .
<Dog> owl:disjointWith <Cat> .
<dogcat> rdf:type <Dog> , <Cat> .

このグラフは、<Dog>と<Cat>がどちらもクラスであり、これらが互いに素、つまり、共通するメンバーが全くないと述べています。これは、<dogcat>には<Dog>と<Cat>の両方の型があるというステートメントと矛盾します。このグラフを満足することができるOWL Full解釈はなく、したがって、このグラフはOWL Fullと整合性がありません。

OWL Fullを知識表現言語として用いる場合には、矛盾の概念は、オントロジーで言明される公理や事実の矛盾を明らかにしてくれるため、有用です。これらの矛盾を解決することにより、我々は、知識の領域に関してさらに学び、面白くて有効な推論を引き出すことが可能な、その領域のより良いモデルに至ります。

OWL Fullをデータ・モデル化（つまり、スキーマ）言語として用いる場合、ここでも矛盾の概念は有用ですが、別の意味でです。ここでは、人間の知識自体の論理的な整合性には関与しません。我々は、ある任意のデータが任意のデータ・モデルと適合する（つまり、一致する）か否かを確実に規定できるように、データ・モデルを形式的に定義することにのみ関心があります。データがデータ・モデルと矛盾しているならば、データは適合しません。

ここでは、ある任意のデータが実際の世界と一致しているか否か、すなわち、これらが絶対的な意味で真か偽かには関与しません。アプリケーションの任意のクラス内の相互運用性は共通のデータ・モデルと一致するデータに依存するため、我々はデータがデータ・モデルと適合するか否かに興味があるだけです。

この視点を表現する別の方法は、完全性の概念を用いるというものです。完全性条件は、データ・モデルの形式的な定義の範囲内のステートメントで、これは、任意のデータがデータ・モデルに対して整合性があるか否かを規定するために用いられ、例えば、<Dog>と<Cat>が互いに素のクラスであるというステートメントをデータ・モデルにおける完全性条件と見なすことができます。この条件のとき、以下のデータは整合性がありません。

<dogcat> rdf:type <Dog> , <Cat> .

本ドキュメントで提供されているSKOSデータ・モデルの定義には、完全性条件を表す限られた数のステートメントが含まれています。これらの完全性条件は、データがSKOSデータ・モデルに関して整合性がない状況を定義することによって、相互運用性を促進するために含まれています。その後で、これらの完全性条件の一部またはすべてが任意のデータに適合しているかをチェックし、ひいては、データがSKOSデータ・モデルと整合性があるかをチェックするツールを実装できます。

これらの完全性条件は、SKOSデータ・モデルのクラスとプロパティーの形式的な定義の一部です。しかし、これらは、別の目的に役立つため、他の部分の形式的な定義とは別に提示しています。完全性条件は、主に任意のデータがSKOSデータ・モデルと整合性があるかを規定するのに役立ちます。SKOSデータ・モデルの定義の他のすべてのステートメントは、論理的な推論をサポートするためにのみ役立ちます。（次の項も参照してください。）

完全性条件は、できる限り、その実装方法から独立した形でSKOSデータ・モデルに定義されています。これは、SKOSデータ・モデルとの矛盾を発見するための手順を実装できる別の方法がいくつかあるからです。OWL推論システムを用いて矛盾を発見できます。あるいは、一部の矛盾は、データ内の特殊なパターンを検索するか、ハイブリッドな方法によって発見できます（例えば、RDFSやOWLの推論システムを用いて推論を引き出し、その後に、推論されたグラフのパターンを検索します）。

SKOSデータ・モデルの完全性条件は予想よりも数が少なく、特にデータベース・システムの閉じた世界の中での作業に慣れている者にとってはそうです。次の項および下記の3～10項の注記も参照してください。

このドキュメントでは、SKOSデータ・モデルをOWL Fullオントロジーとして定義します。例えば、エンティティ関係モデルやUMLクラス・モデルとしてといった、SKOSデータ・モデルを定義できる方法は他にもあります。データ・モデル化言語としてのOWL Fullは、様々な意味で、直観的にはこれらの他のモデル化のアプローチと同じに見えますが、重大で根本的な違いがあります。

RDFとOWL Fullは、データが広く流通しうる（例えば、ウェブ）システム用に設計されています。そのようなシステムが大きくなるにつれ、システムのすべてのデータがどこにあるかを知ることは現実的ではなく、事実上不可能になります。したがって、一般に、そのようなシステムから得られたデータが完全であると推測すことはできません。いくつかのデータが欠落しているように思われる場合には、一般的に、データがシステムの他のどこかに存在するかもしれないと推測しなければなりません。この推測は、大まかに言えば、開世界仮説[OWL-GUIDE]として知られています。

これは、実際には、OWL Fullオントロジーとして定義されたデータ・モデルでは、いくつかの定義が、直観と相いれない意味を持ちうえことを意味します。欠落したデータから結論を得ることはできず、何かを削除しても残りのデータを矛盾していることにはできないでしょう。例えば、これは、下記の8項のskos:semanticRelationの定義で例示されています。プロパティーskos:semanticRelationは、定義域と値域skos:Conceptを持つように定義されています。これらの定義域と値域の定義は推論を認めます。次のグラフを考えてみてください。

<A> skos:semanticRelation <B>.

このケースでは、上記のグラフは次のグラフを含意します。

<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

したがって、このようなステートメントはskos:semanticRelationの定義により含意されるため、ここで<A>と<B>がskos:Conceptのインスタンスであると明示的に述べる必要はありません。

SKOSデータ・モデルでは、定義のほとんどのステートメントは、完全性条件ではなく、データ・モデルの異る要素間の論理的な依存性に関するステートメントです。これは、（開世界仮説下では）多くのシンプルな推論を認めます。例えば、これは、skos:broaderとskos:narrowerは逆プロパティーであるという、下記の7項のステートメントによって例証されます。このステートメントは、次を意味します。

<A> skos:narrower <B> .

は、次を含意する。

<B> skos:broader <A> .

これらの2つのグラフは、両方とも、単独でSKOSデータ・モデルと整合性があります。

シソーラスや分類表などの知識組織化体系は多様な状況で用いられており、個々の知識組織化体系は多くの異なる情報システムで使用できます。SKOSデータ・モデルをOWL Fullオントロジーとして定義することで、セマンティック・ウェブは、これらの知識組織化体系に関わるデータを公開、交換、共有、リンクするための媒体として使用できます。このため、データ・モデル化言語としてのOWL Fullの表現の豊かさのため、そして、形式的オントロジーを併用してシソーラス、分類表などを使用する可能性のため、OWL Fullは、SKOSデータ・モデルを定義するために用いられてきました。したがって、開世界仮説は、SKOSデータ・モデルの基本となる前提であり、このドキュメントを読むときには念頭におくべきです。

[RDF-PRIMER]と[OWL-GUIDE]も参照してください。

上記で論じたように、知è˜çµ„織化体系の概念には、広範囲な工芸品が含まれます。そのため、SKOSスã‚ーマには、過剰介入の危険性があり、一部のアプリケーションではSKOSを使用できなくなります。これを軽減するため、形式的な制約を含むことに疑問がある状況（例えば、

に関するè°è«–を参照）では、制約は形式的に記述されませんでした。時として、形式的な制約が記述されていなくても、用法の慣習は推奨されます。より制約的な挙動を必要とするアプリケーションは、SKOS語彙に対する拡張を定義できます。[

]も参照してください。

このドキュメントは、OWL FullオントロジーとしてSKOSデータ・モデルを形式的に定義します。SKOSデータ・モデルの要素は、OWLのクラスとプロパティーであり、これらをウェブ上で一意に使用できるように、これらのクラスとプロパティーのそれぞれに、URI（Uniform Resource Identifier）を付与しています。このURIは、SKOS語彙です。

下記の2項で完全なSKOS語彙を示します。そして、3項から10項でSKOSデータ・モデルを形式的に定義します。データ・モデルの定義は、純粋に便宜上の理由で、多くの項に分散しています。これらの3から10の各項は、共通のレイアウトに従っています。

• 前書き ― その項がカバーする趣旨を非形式的に紹介します。
• 語彙 ― その項で定義するSKOS語彙のURIを示します。
• クラスおよびプロパティーの定義 ― それらのURIで指示されたクラスとプロパティー間の論理的な特性と相互依存性を形式的に定義します。
• 完全性条件 ― 完全性条件があれば、提示します。
• 例 ― SKOSデータ・モデルと整合性のあるデータと、（必要に応じて）SKOSデータと整合性のないデータの両方の、いくつかの規範的な例を示します。
• 注記 ― 注記と議論を補記します。

このドキュメントで述べるほとんどのクラスとプロパティーの定義と完全性条件は、RDF、RDFS、およびOWLの語彙を用いて、RDFトリプルとして記述できます。しかし、OWL Fullの表現の豊かさの限界のためや、あるクラスに対する標準的なURIが不足しているために、不可能なものも少しあります。このドキュメントを全般的に読み易すくするために、形式的な定義と完全性条件は、RDFトリプルと他の表記法とを混在させて記述するのではなく、全体にわたり、散文の形で記述してます。

この散文形式は、概ね、[RDFS]で用いられる形式に従っており、RDFとOWLの実用的な知識を有する読者にとって明快であるはずです。

そのため、例えば「ex:Personはowl:Classのインスタンスである」は、次の通りになります。

ex:Person rdf:type owl:Class .

「ex:hasParentとex:hasMotherはそれぞれowl:ObjectPropertyのインスタンスである」は、次の通りになります。

ex:hasParent rdf:type owl:ObjectProperty .
ex:hasMother rdf:type owl:ObjectProperty .

「ex:hasMotherはex:hasParentのサブプロパティーである」は、次の通りになります。

ex:hasMother rdfs:subPropertyOf ex:hasParent .

「ex:hasParentのrdfs:rangeは、クラスex:Personである」は、次の通りになります。

ex:hasParent rdfs:range ex:Person .

SKOSデータ・モデルの一部の形式的な側面をRDF、RDFS、OWL語彙のいずれかを用いてRDFトリプルとして述べることができない場合、これらのステートメントがどのようにRDF語彙の解釈に関する形式的な条件に翻訳されるかが、RDFとOWLオントロジーの基本的理解を有する読者にとって明快であるべきです（例えば、5項の「資源は、言語タグごとに1未満のskos:prefLabelの値を持つ」が、任意の資源xに対し、IとIEXTが[RDF-SEMANTICS]で定義されている関数である場合、集合{ y | <x,y> is in IEXT(I(skos:prefLabel)) }の2つのメンバーが同じ言語タグを共有しないことを意味する）。

このドキュメントの本文では、完全なURIは、例えば<http://example.org/ns/example>のように、アングルブラケットで囲み込んだ等幅フォントで引用されます。相対URIも同じ方法で引用され、基底URI<http://example.org/ns/>に関連付けられています。例えば、<example>と<http://example.org/ns/example>は同じURIです。

また、このドキュメントの本文では、URIは省略形で引用されます。省略形のURIは、アングルブラケットなしの等幅フォントで引用されます。下記の省略形の表を用いて展開してください。

したがって、例えば、skos:Conceptは<http://www.w3.org/2004/02/skos/core#Concept>の省略形です。

RDFグラフの例は、Terse RDF Triple言語（Turtle）[TURTLE]を用いて示されます。すべての例は、次の接頭辞とURI基底指示子が先行していることを想定します。

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .

したがって、次の例

<MyConcept> rdf:type skos:Concept .

は、次のTurtleドキュメントと同等です。

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@base <http://example.org/ns/> .    
<MyConcept> rdf:type skos:Concept .

これは、次のRDF/XMLドキュメント[RDF-XML]と同等です。

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 

    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 

    xmlns:skos="http://www.w3.org/2004/02/skos/core#"

    xmlns:owl="http://www.w3.org/2002/07/owl#"

    xml:base="http://example.org/ns/">
    
    <skos:Concept rdf:about="MyConcept"/>
    
</rdf:RDF>

これは、次のN-TRIPLESドキュメント[NTRIPLES]と同等です。

<http://example.org/ns/MyConcept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> .

Turtleにおける、同じ主語または述語を持つ複数のトリプルを省略するための「;」と「,」という文字の使用に注意してください。一部の例では、RDFコレクションを表すTurtle構文である「(…)」を用います。

この仕様では、適合性の形式的な概念を定義しません。

しかし、RDFグラフとSKOSデータ・モデル（以下で形式的に定義している）とを合わせると論理的な矛盾が生じるならば、そのグラフはSKOSと矛盾しているでしょう。

この仕様では、型skos:Concept、skos:ConceptScheme、skos:Collectionやskosxl:Labelの資源を識別するためにURIを用いる場合は、ウェブでそれらのURIに逆参照するときに特殊な作業をする必要はありません[WEBARCH]。しかし、SKOSデータの公表者は、[COOLURIS]と[RECIPES]で示されたガイドラインに従うことを強く推奨します。

SKOS名前空間URIは、次のとおりです。

• http://www.w3.org/2004/02/skos/core#

SKOS語彙は、次の表の左欄のURIです。

SKOS語彙のすべてのURIは、ローカル名（例えば、"prefLabel"）をSKOS名前空間URIに追加することで、構成されます。

付録Bとクイック・アクセス・パネルのSKOS概要も参照してください。

クラスskos:Conceptは、SKOS概念のクラスです。

SKOS概念は、アイデアや考え（思考の単位）と見なすことができます。しかし、何で思考の単位を構成されるかは主観的であり、この定義は限定的なものではなく示唆的です。

SKOS概念の考えは、知識織化体系の概念的あるいは知的な構造を記述し、KOS内で確立された特定のアイデアや意味を参照するときに有用です。

SKOSはシソーラスや分類表などの準形式的なKOSを表すための手段となるように設計されているため、このクラスの形式的な定義には、ある程度の自由度が含まれることに注意してください。

SKOS概念の識別と記述の詳細な例は、[SKOS-PRIMER]を参照してください。

次のグラフは、<MyConcept>がSKOS概念（つまり、skos:Conceptのインスタンス）であると述べています。

<MyConcept> rdf:type skos:Concept .

この仕様は、skos:Conceptがowl:Classのインスタンスであるという言明以外には、SKOS概念のクラスとOWLクラスのクラスとの形式的な関係について少しも補記しません。そのような記述を行わないという決定は、SKOSをOWLと組み合わせて使うための様々な設計パターンのアプリケーションを自由に開発できるように行われました。

次の例のグラフでは、<MyConcept>は、skos:Conceptとowl:Classのインスタンスです。

<MyConcept> rdf:type skos:Concept , owl:Class .

この例は、SKOSデータ・モデルと整合性があります。

同様に、この仕様は、SKOS概念のクラスとOWLプロパティーのクラスとの形式的な関係について述べません。

次の例のグラフでは、<MyConcept>はskos:Conceptとowl:ObjectPropertyのインスタンスです。

<MyConcept> rdf:type skos:Concept , owl:ObjectProperty .

この例は、SKOSデータ・モデルと整合性があります。

SKOS概念体系は、1つ以上のSKOS概念の集合と見なすことができます。それらの概念間の意味関係（リンク）は、概念体系の一部とも見なされるかもしれません。しかし、この定義は、限定的というよりは示唆的なものであり、以下で述べる形式的なデータ・モデルには幾分かの自由度があります。

概念体系の概念は、未知の情報源のデータを処理するときと、2つ以上の異なる知識組織化体系に基づいて記述したデータを処理するときに有用です。

概念体系の識別、記述に関する詳細な例は、[SKOS-PRIMER]を参照してください。

次のグラフは2つのSKOS概念を持つ概念スキーマを記述しており、そのうちの1つはそのスキーマにおける最上位概念です。

<MyScheme> rdf:type skos:ConceptScheme ;

skos:hasTopConcept <MyConcept> .

<MyConcept> skos:topConceptOf <MyScheme> .

<AnotherConcept> skos:inScheme <MyScheme> .

個々のSKOS概念体系の概念は概ね、個々のシソーラス、分類表、件名標目表やその他の知識組織化体系の概念に対応しています。

しかし、ほとんどの現行の情報システムでは、シソーラスや分類表はクローズド・システムとして扱われています ― そのシステム内で定義された概念の単位を他のシステムと共有できません（他のシステムの単位にそれらをマッピングすることは可能ですが）。

SKOSも似たアプローチを取りますが、SKOS概念が0、1、または1以上の概念体系の共有をさせない条件はありません。

したがって、例えば、次のグラフでは、SKOS概念<MyConcept>は、2つの異る概念体系を共有しています ― これは、SKOSデータ・モデルと整合性があります。

<MyScheme> rdf:type skos:ConceptScheme .

<AnotherScheme> rdf:type skos:ConceptScheme ;

owl:differentFrom <MyScheme> .

<MyConcept> skos:inScheme <MyScheme> , <AnotherScheme> .

例えば、2つ以上の既存の概念体系をリンクすることで新しい概念体系を記述できるため、この自由度は好ましいです。

また、概念体系の境界を閉じる方法がないことに注意してください。そのため、skos:inSchemeを用いて、SKOS概念X、Y、Zが概念体系Aを共有すると述べることはできますが、X、Y、ZのみがAを共有すると述べる方法はありません。

したがって、概念体系を記述するためにSKOSを使用できますが、SKOSは概念体系を完全に定義するメカニズムは全く提供しません。

この仕様書では、SKOS概念体系のクラスとOWLオントロジーのクラスとの形式的な関係に関する記述を行いません。そのような記述を行わないという決定は、SKOSをOWL[OWL-GUIDE]と組み合わせて使うための様々な設計パターンを開発可能とするために行われました。

次のグラフの例では、<MyScheme>は、SKOS概念体系とOWLオントロジーの両方です。これは、SKOSデータ・モデルと整合性があります。

<MyConcept> skos:inScheme <MyScheme> .

プロパティーskos:hasTopConceptは、慣習上、概念体系を、その体系の階層関係において最上位にあるSKOS概念にリンクするために用いられます。しかし、この慣習を実施する完全性条件はありません。したがって、次のグラフは、厳密にはskos:hasTopConceptの用法の慣習を守っていませんが、SKOSデータ・モデルとは整合性があります。

<MyScheme> skos:hasTopConcept <MyConcept> .
<MyConcept> skos:broader <AnotherConcept> .
<AnotherConcept> skos:inScheme <MyScheme> .

アプリケーションは、そのようなデータを拒否できますが、必ずしも拒否しなければならないわけではありません。

2つのSKOS概念間のリンクは同じ概念体系内での包含を含意しません。これを次の例で示しています。

<A> skos:narrower <B> .
<A> skos:inScheme <MyScheme> .

は、次を含意しない。

<B> skos:inScheme <MyScheme> .

下記の8項も参照してください。

プロパティーskos:inSchemeに対する定義域が記述されていないことに注意してください。つまり、事実上、その定義域はすべての資源（rdfs:Resource）のクラスです。柔軟性を提供するために定義域を記述しないという決定が行われ、SKOSの拡張によって新しいクラスに関する資源を定義可能になりますが、それでも、それらをskos:ConceptSchemeにリンクするためにskos:inSchemeを用います。下記の例82も参照してください。

字句ラベルは、「romantic love」や「れんあい」のような、英語や日本語（ここでは、ひらがなで記述）などの、任意の自然言語によるUnicodeの文字列です。

SKOSは、字句ラベルと任意の型の資源とを関連付けるための基本語彙を提供します。特に、SKOSは、任意の資源に対し、優先、代替、「非表示」の字句ラベルの区別を可能にします。

優先および代替のラベルは、人間が読める知識組織化体系の表現を生成・作成するときに有用です。これらのラベルは、SKOS概念の意味に関する最大のヒントを提供してくれます。

非表示ラベルは、ユーザがテキスト・ベースの検索機能で知識組織化体系と相互作用を行う場合に有用です。例えば、ユーザは、関連概念を見つけようとしているときに、スペルミスした単語を入力するかもしれません。スペルミスしたクエリが非表示ラベルとマッチング可能であれば、ユーザは関連概念を見つけられるでしょうが、その一方で、非表示ラベルはユーザには見えないでしょう（したがって、更なる誤りが助長されません）。

字句ラベルは、形式的に、RDFプレーン・リテラル[RDF-CONCEPTS]です。RDFプレーン・リテラルは、Unicodeの文字列である字句形式と、[BCP47]で定義されている構文に適合する文字列の任意の言語タグで構成されます。

SKOS概念のラベル付けの例の詳細は、[SKOS-PRIMER]を参照してください。次の例がSKOSデータ・モデルの一般的な機能を示すためだけのものであって、異なる言語タグを持つラベルの条件に対するペスト・プラクティスを必ずしも意味するわけではないことに特に注意してください。SKOSリファレンスは、さまざまな状況にまたがった適切なデータ・モデルの確立を目指しており、後で、より特定の状況に対応した用法の慣習によって精緻化され、そして/または制約できます。ラベルと言語タグに関するアプリケーション固有および言語固有の用法の慣習は、SKOSリファレンスの範囲外です。

次のグラフは、整合性があり、2つの異なる言語（フランス語と英語）の字句ラベルの条件を例示しています。

<MyResource>
  skos:prefLabel "animals"@en ;
  skos:altLabel "fauna"@en ;
  skos:hiddenLabel "aminals"@en ;
  skos:prefLabel "animaux"@fr ;
  skos:altLabel "faune"@fr .

次のグラフは、整合性があり、4つの異なるバリエーション（漢字、平仮名、片仮名、またはラテン文字（ローマ字）で書かれた日本語）の字句ラベルの条件を例示しています。

<AnotherResource>
  skos:prefLabel "東"@ja-Hani ;
  skos:prefLabel "ひがし"@ja-Hira ;
  skos:altLabel "あずま"@ja-Hira ;
  skos:prefLabel "ヒガシ"@ja-Kana ;
  skos:altLabel "アズマ"@ja-Kana ;
  skos:prefLabel "higashi"@ja-Latn ;
  skos:altLabel "azuma"@ja-Latn .

次のグラフは、2つの異なる優先字句ラベルに同じ言語タグが与えられているため、SKOSデータ・モデルと整合性がありません。

<Love> skos:prefLabel "love"@en ; skos:prefLabel "adoration"@en .

次のグラフは、優先字句ラベルと代替字句ラベルの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<Love> skos:prefLabel "love"@en ; skos:altLabel "love"@en .

次のグラフは、代替字句ラベルと非表示字句ラベルの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<Love> skos:altLabel "love"@en ; skos:hiddenLabel "love"@en .

次のグラフは、優先字句ラベルと非表示字句ラベルの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<Love> skos:prefLabel "love"@en ; skos:hiddenLabel "love"@en .

skos:prefLabel、skos:altLabel、およびskos:hiddenLabelに対する定義域が記述されていないことに注意してください。したがって、これらのプロパティーの有効な定義域は、すべての資源（rdfs:Resource）のクラスです。

したがって、プロパティーskos:prefLabel、skos:altLabel、およびskos:hiddenLabelを用いて任意の型の資源をラベル付けすることは、SKOSデータ・モデルと整合性があります。

次の例のグラフでは、skos:prefLabel、skos:altLabel、およびskos:hiddenLabelを、型owl:Classの資源をラベル付けするために用いました ― これはSKOSデータ・モデルと整合性があります。

<MyClass> rdf:type owl:Class ;
  skos:prefLabel "animals"@en ;
  skos:altLabel "fauna"@en ;
  skos:hiddenLabel "aminals"@en ;
  skos:prefLabel "animaux"@fr ;
  skos:altLabel "faune"@fr .

skos:prefLabel、skos:altLabel、およびskos:hiddenLabelの値域は、RDFプレーン・リテラル[RDF-CONCEPTS]のクラスであることに注意してください。

慣習上、RDFプレーン・リテラルは、常にトリプルの目的語の位置で用いられ、その場合、述語は、skos:prefLabel、skos:altLabel、またはskos:hiddenLabelのうちの1つです。グラフがこの用法の慣習に従わない場合、アプリケーションは、そのようなデータを拒否できますが、必ずしも拒否しなければならないわけではありません。下記の注記も参照してください。

一部のアプリケーションには、ラベルに関連した（例えば、それらのラベルの記述や、ラベル（頭字語などの）間の付加的な関係の定義を可能にする）追加機能が必要です。URIを用いたラベルの識別でこれを実現できます。付録Aで定義しているラベル用SKOS拡張は、これに対するサポートを提供します。

次のグラフでは、資源は2つの代替字句ラベルを持っていますが、優先字句ラベルは持っていません。これは、SKOSデータ・モデルと整合性があり、データ・モデルから得られる付加的な含意はありません。しかし、多くのアプリケーションが人間が読める最適な表示を生成するために優先字句ラベルを必要とすることに注意してください。

<Love> skos:altLabel "adoration"@en , "desire"@en .

[BCP47]は、言語を識別するためのタグを定義します。「en」、「en-GB」、「en-US」が、それぞれ、英語、イギリス英語、アメリカ英語に用いられる3つの異なる言語タグであることに注意してください。同様に、「ja」、「ja-Hani」、「ja-Hira」、「ja-Kana」、「ja-Latn」は、それぞれ、日本語、漢字、平仮名、片仮名、またはラテン文字（ローマ字）で書かれた日本語に用いられる5つの異なる言語タグです。

「en」、「en-US」、「en-GB」が異なる言語タグであるため、次のグラフはSKOSデータ・モデルと整合性があります。

<Colour> skos:prefLabel "color"@en , "color"@en-US , "colour"@en-GB .

次のグラフでも「en」と「en-GB」が異なる言語タグであるため、字句ラベル付けプロパティーの間には衝突はなく、したがって、グラフはSKOSデータ・モデルと整合性があります。

<Love> skos:prefLabel "love"@en ; skos:altLabel "love"@en-GB .

しかし、上記の5.1項で述べたように、これらの例がSKOSデータ・モデルの一般的な機能を示すためだけのものであって、異なる言語タグを持つラベルの条件に対するペスト・プラクティスを必ずしも意味するわけではないことに注意してください。ラベルと言語タグに関するアプリケーション固有および言語固有の用法の慣習は、SKOSリファレンスの範囲外です。

アプリケーションは、例えば、[BCP 47]で定義されている「ルックアップ」アルゴリズムの実装により、任意の言語のラベルに対するリクエストをSKOS概念体系で提供される関連言語タグを持つラベルにマッチングさせることをお勧めします。この方法でマッチングを行うアプリケーションは、ラベルがあらゆる可能な言語のバリエーション（多いかもしれない）で提供されることを必要とせず、字句形式が異なるラベルのみを任意の言語または言語の集合に提供するSKOS概念体系と互換性があります。

表記法は、任意の概念体系の範囲内で概念を一意に識別するための「T58.5」や「303.4833」などの文字列です。

表記法は、それが通常、任意の自然言語による1つの単語や単語の羅列とは認識されなという点で字句ラベルと異なっています。

この項では、skos:notationプロパティーを定義しています。このプロパティーは、表記法を型付きリテラル[RDF-CONCEPTS]として指定するために用いられます。

次の例は、字句形式がUnicodeの文字列「303.4833」であり、データ型がURI<http://example.com/ns/MyNotationDatatype>で表される表記法を持つ資源<http://example.com/ns/MyConcept>を示しています。

<MyConcept> skos:notation "303.4833"^^<MyNotationDatatype> .

型付きリテラルは、データ型URI[RDF-CONCEPTS]と組み合わせたUnicodeの文字列です。

型付きリテラルは、整数や、浮動小数点や日付などの値を表すために一般的に用いられ、xs:integer、xs:float、およびxs:dateなどの、XMLスキーマ仕様[XML-SCHEMA]で定義済みのデータ型が多くあります。

他の状況に対しては、新しいデータ型を定義でき、これは一般的に「ユーザ定義データ型」[SWBP-DATATYPES]と呼ばれます。

慣習上、プロパティーskos:notationは、トリプルの目的語の位置で型付きリテラルと共にのみ用いられ、その場合、データ型URIは、表記法や分類コードの特定のシステムに対応するユーザ定義データ型を表します。

多くの状況で、シンプルに特定の表記法体系に対するデータ型URIを作り、表記法がどのように構成されるか、および/またはどの字句形式が許されるかを記述するドキュメントでデータ型を非形式的に定義すれば十分かもしれません。しかし、少なくとも、XMLスキーマ言語で、より形式的にデータ型の字句スペースを定義することも可能であることに注意してください（[SWBP-DATATYPES]の2項を参照）。ユーザは、データ型のサポートによってツールが異なりえることを意識しているべきです。しかし、[OWL-REFERENCE]の6.3項で論じているように、ツールは、少なくとも字句的に同一であるリテラルを同等と扱うべきです。

skos:notationプロパティーのカーディナリティーには制約がありません。概念は、0または1以上の表記法を持つことができます。

概念が1つ以上の表記法を持つ場合、これらは、同じ表記法体系からのものでも、異なる表記方法からのものでありえます。表記法が異なる体系からのものである場合、これを示すために異なるデータ型を使用できます。同じ（つまり、同じデータ型URIを持つ）表記法体系から1つ以上の表記法を指定するのは、一般的な方法ではありません。

慣習上、同じ概念体系の2つの概念に、同じ表記法は付与できません。たとえそれらが存在していたとしても、表記法を用いて概念を一意に参照することはできないでしょう（つまり、表記法は曖昧になるでしょう）。

skos:notationとskos:prefLabelを組み合わせて使用することには制約はありません。次の例では、同じ文字列が、表記法の字句形式と、優先ラベルの字句形式の両方として提供されています。

<Potassium>
  skos:prefLabel "K"@en ;
  skos:notation "K"^^<ChemicalSymbolNotation> .

型付きリテラルは、文字列とデータ型URIで構成されます。慣習上、skos:notationはトリプルの目的語の位置で型付きリテラルと共にのみ用いられます。

プレーン・リテラルは、文字列と言語タグで構成されています。慣習上、skos:prefLabel（およびskos:altLabelとskos:hiddenLabel）は、トリプルの目的語の位置でプレーン・リテラルと共にのみ用いられます。

言語タグとデータ型URIの両方を持つRDFリテラルといったものはありません。すなわち、型付きリテラルは言語タグを持たず、プレーン・リテラルはデータ型URIを持ちません。

skos:notationに対する定義域が記述されていないことに注意してください。したがって、有効な定義域は、すべての資源（rdfs:Resource）のクラスです。したがって、skos:notationを任意の型の資源と共に用いることは、SKOSデータ・モデルと整合性があります。

注記は、SKOS概念に関連する情報を提供するために用いられます。この情報の性質には制限がなく、例えば、プレーン・テキストやハイパーテキスト、画像でありえ、定義や概念の範囲に関する情報、編集上の情報、他のあらゆる種類の情報でありえます。

SKOSには、注記を概念に関連付けるためのプロパティーが7つあり、この項で形式的に定義されています。各SKOSドキュメンテーション・プロパティーの推奨される使用法の詳細は、[SKOS-PRIMER]を参照してください。

これらの7つのプロパティーは、あらゆる状況をカバーすることを目的しているのではなく、一部の最も一般的な状況において有用で、より多くの特殊な注記を定義するための拡張ポイントを提供することを目的としています。SKOSを拡張するために推奨されるベスト・プラクティスの詳細は、[SKOS-PRIMER]を参照してください。

SKOSドキュメンテーション・プロパティーに関し、[SKOS-PRIMER]では、3つの異なる使用パターンが推薦されています ― 「RDFリテラルとしてのドキュメンテーション」、「関連資源記述としてのドキュメンテーション」、および「ドキュメント参照としてのドキュメンテーション」。この項で定義されているデータ・モデルは、3つすべての設計パターンに対応することを目的しています。

次のグラフは「RDFリテラルとしてのドキュメンテーション」のパターンの例を示しています。

<MyResource> skos:note "this is a note"@en .

次のグラフは「ドキュメント参照としてのドキュメンテーション」のパターンの例を示しています。

<MyResource> skos:note <MyNote> .

SKOSドキュメンテーション・プロパティーに対する定義域が記述されていないことに注意してください。したがって、これらのプロパティーに対する有効な定義域は、すべての資源（rdfs:Resource）のクラスです。したがって、SKOSドキュメンテーション・プロパティーを用いて任意の型の資源に関する情報を提供することは、SKOSデータ・モデルと整合性があります。

次の例のグラフでは、型owl:Classの資源に対するプレーン・テキストの定義を提供するためにskos:definitionを用いました ― これは、SKOSデータ・モデルと整合性があります。

<Protein> rdf:type owl:Class ;
  skos:definition """A physical entity consisting of a sequence of amino-acids; a protein monomer; a single polypeptide chain. An example is the EGFR protein."""@en .

SKOSドキュメンテーション・プロパティーに対する値域が記述されておらず、その結果、これらのプロパティーの値域が事実上、すべての資源（rdfs:Resource）のクラスであることに注意してください。RDFとOWL Fullセマンティクスの下では、すべてが、RDFプレーン・テキストを含む資源です。

SKOSの意味関係はSKOS概念間のリンクで、この場合、リンクは、リンクされた概念の意味に内在しています。

SKOSは、階層と関連という意味関係の2つの基本的なカテゴリーを区別します。2つの概念間の階層リンクは、何らかの方法、1つがもう一方（「狭義」）より一般的（「広義」）であることを示します。2つの概念間の関連リンクは、2つが本質的に「関連している」が、1つがもう一方より一般的ではないことを示します。

プロパティーskos:broaderとskos:narrowerは、2つのSKOS概念間の直接的な階層リンクを言明するために用いられます。トリプル<A> skos:broader <B>は、<B>（トリプルの目的語）が、<A>（トリプルの主語）より広義な概念であると言明します。同様に、トリプル<C> skos:narrower <D>は、<D>（トリプルの目的語）が、<C>（トリプルの主語）より狭い概念であると言明します。

慣習上、skos:broaderとskos:narrowerは、2つのSKOS概念間の直接的な（すなわち、直近の）階層リンクを言明するためにのみ用いられます。これは、任意の概念に対する直接的な広義および狭義のリンクにアクセスする便利で信頼できる方法をアプリケーションに提供します。この用法の慣習をサポートするために、プロパティーskos:broaderとskos:narrowerは、推移的なプロパティーであると宣言されないことに注意してください。

一部のアプリケーションは、例えば、クエリ拡張で検索再現率を改良するために、概念間の直接的および間接的の両方の階層リンクを利用する必要があります。このために、プロパティーskos:broaderTransitiveとskos:narrowerTransitiveが提供されています。トリプル<A> skos:broaderTransitive <B>は、直接的または間接的な階層リンクを表し、この場合、<B>は<A>の広義の「先祖（ancestor）」です。同様に、トリプル<C> skos:narrowerTransitive <D>は、直接的または間接的な階層リンクを表し、この場合、<D>は<C>の狭義の「子孫（descendant）」です。

慣習上、プロパティーskos:broaderTransitiveとskos:narrowerTransitiveは、言明を行うために用いられません。その代わり、これらのプロパティーは、後で概念間の直接的または間接的な階層リンクにアクセスするために使用できる階層リンクの推移閉包を推論するために用いられます。

プロパティーskos:relatedは、2つのSKOS概念間の関連リンクを言明するために用いられます。

階層リンクおよび関連リンクの記述に関するより多くの例に関しては、[SKOS-PRIMER]を参照してください。

skos:relatedが対称的プロパティーであり、skos:broaderTransitiveとskos:narrowerTransitiveが逆であるため、skos:relatedは、skos:narrowerTransitiveと素の関係でもあります。

次のグラフは、<A>と<B>（<B>が<A>より広義）との直接的な階層リンクと、<A>と<C>との関連リンクを言明しており、SKOSデータ・モデルと整合性があります。

<A> skos:broader <B> ; skos:related <C> .

次のグラフは、関連リンクと階層リンクの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<A> skos:broader <B> ; skos:related <B> .

次のグラフも関連リンクと階層リンクの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<A> skos:broader <B> ; skos:related <C> .
<B> skos:broader <C> .

上記の例では、衝突がすぐには明らかではありません。衝突は推論が行われる際に明らかになります。上記のクラスとプロパティーの定義に基づき、次のグラフができます。

<A> skos:broaderTransitive <C> ; skos:related <C> .

次のグラフも関連リンクと階層リンクの間に衝突があるため、SKOSデータ・モデルと整合性がなく、上記のクラスとプロパティーの定義からリンクを推論できます。

<A> skos:narrower <B> ; skos:related <C> .
<B> skos:narrower <C> .

次の図は、SKOS意味関係プロパティーとのサブプロパティーの関係を非形式的に例示しています。

skos:semanticRelation
 |
 +― skos:related
 |
 +― skos:broaderTransitive
 |    |
 |    +― skos:broader
 |
 +― skos:narrowerTransitive
      |
      +― skos:narrower

skos:semanticRelationの定義域と値域がクラスskos:Conceptであることに注意してください。skos:broader、skos:narrower、およびskos:relatedは、skos:semanticRelationのそれぞれのサブプロパティーであるため、上記の例26は、<A>、<B>、および<C>がskos:Conceptのそれぞれのインスタンスであることを含意します。

skos:relatedは、対称的なプロパティーです。次の例は、この条件から得られる含意を示しています。

<A> skos:related <B> .

は、次を含意する。

<B> skos:related <A> .

skos:relatedは対称的なプロパティーですが、この条件は、skos:relatedのサブプロパティーには制約を置かないことに注意してください（つまり、skos:relatedのサブプロパティーは、対称的、非対称的、または反対称的でありえ、それでも、SKOSデータ・モデルと整合性がある）。

次の例では、この点を示すために、対称的でない2つの新しいプロパティーがskos:relatedのサブプロパティーとして宣言されています。また、SKOSデータ・モデルと整合性があるこの例は、それに続く一部の含意を示しています。

<cause> rdf:type owl:ObjectProperty ;

rdfs:subPropertyOf skos:related .

<effect> rdf:type owl:ObjectProperty ;

rdfs:subPropertyOf skos:related ;

owl:inverseOf <cause> .

<A> <cause> <B> .

は、次を含意する。

<A> skos:related <B> .

<B> <effect> <A> ; skos:related <A> .

SKOSの拡張のベスト・プラクティスの推奨に関しては、[SKOS-PRIMER]も参照してください。

skos:relatedが推移的なプロパティーではないことに注意してください。したがって、SKOSデータ・モデルは、次の例で示すように、含意をサポートしません。

<A> skos:related <B> .
<B> skos:related <C> .

は、次を含意しない。

<A> skos:related <C> .

この仕様書は、skos:relatedが反射的なプロパティーであるとも、非反射的なプロパティーであるとも述べません。

skos:relatedが非反射的なプロパティーであると定義されていないため、次のグラフは、SKOSデータ・モデルと整合性があります。

<A> skos:related <A> .

しかし、知識組織化体系を利用する多くのアプリケーションにとって、X skos:related Xという形式のステートメントは問題になりえます。このような場合に、アプリケーションがそのようなステートメントをいかに処理すべきかはこの仕様では定義されておらず、アプリケーションによって異なるかもしれませんが、アプリケーションは、SKOSデータを処理する前にそのようなステートメントを探したいかもしれません。

skos:broaderが推移的なプロパティーではないことに注意してください。同様に、skos:narrowerは、推移的なプロパティーではありません。したがって、次の例で示すように、SKOSデータ・モデルは含意をサポートしません。

<A> skos:broader <B> .
<B> skos:broader <C> .

は、次を含意しない。

<A> skos:broader <C> .

しかし、skos:broaderは、skos:broaderTransitiveのサブプロパティーで、推移的なプロパティーです。同様に、skos:narrowerは、skos:narrowerTransitiveのサブプロパティーで、推移的なプロパティーです。したがって、SKOSデータ・モデルは、次に例示する含意をサポートします。

<A> skos:broader <B> .
<B> skos:broader <C> .

は、次を含意する。

<A> skos:broaderTransitive <B> .
<B> skos:broaderTransitive <C> .
<A> skos:broaderTransitive <C> .

慣習上、skos:broaderとskos:narrowerが、2つのSKOS概念間の直近の（つまり、直接的な）階層リンクを言明するためにのみ用いられることに特に注意してください。慣習上、skos:broaderTransitiveとskos:narrowerTransitiveは、言明を行うために用いられず、推論を行うためにのみ用いられます。

このパターンにより、直接的な（つまり、直近の）階層リンクに関する情報を保持可能になりますが、これは、多くのタスク（例えば、各種の知識組織化体系の視覚的な表示を組み込む）に必要です。一方で、それらの階層リンク（直接的なリンクと間接的なリンクの両方を含む）の推移閉包に便利に問合わせを行うメカニズムも提供し、これは、他の状況（例えば、クエリ拡張アルゴリズム）で有用です。

推移的なプロパティーのサブプロパティーが、必ずしも推移的であるわけではないことにも注意してください。

下記の代替パスに関する注記も参照してください。

この仕様が、skos:broader関係の反射的なプロパティーに関するステートメントを出さないことに注意してください。これは、skos:broaderが反射的なプロパティーであるとも、非反射的なプロパティーであるとも述べません。したがって、任意のグラフと資源<A>に関し、次のトリプル

<A> skos:broader <A> .

は、存在しえるかも、しえないかもしれません。この保守的な位置付けにより、SKOSは、skos:broaderの解釈が反射的な（例えば、推論されるOWLサブクラス階層の直接変換）KOSと、skos:broaderが非反射的（ほとんどのシソーラスまたは分類表に適するような）と考えられるKOSの両方をモデル化するために使用できます。

同様に、skos:narrowerの反射性または非反射性に関して行われた言明はありません。

しかし、知識組織化体系を利用する多くのアプリケーションにとって、X skos:broader X、またはY skos:narrower Yという形式は問題になりえます。このような場合に、アプリケーションがそのようなステートメントをいかに処理すべきかはこの仕様では定義されておらず、アプリケーションによって異なるかもしれませんが、アプリケーションは、SKOSデータを処理する前にそのようなステートメントを探したいかもしれません。

次のグラフでは、階層関係内に循環が記述されています。このグラフがSKOSデータ・モデルと整合性がある、すなわち、skos:broaderTransitiveが反射的でないことを要する条件がないことに注意してください。

<A> skos:broader <B> .
<B> skos:broader <A> .

しかし、知識組織化体系が使用されている多くのアプリケーションにとって、階層関係における循環は問題になりえます。これらのアプリケーションでは、skos:broaderTransitiveの推移閉包をコンピュータ処理し、その後に、X skos:broaderTransitive Xという形式のステートメントを探すのが、階層関係内の循環を発見するための便利な方法です。アプリケーションがそのようなステートメントをいかに処理すべきかは、この仕様では定義されておらず、アプリケーションによって異なるかもしれません。

次のグラフには、階層関係にAからCの2つの代替パスがあります。

<A> skos:broader <B> , <C> .
<B> skos:broader <C> .

次のグラフには、階層関係にAからDの2つの代替パスがあります。

<A> skos:broader <B> , <C> .
<B> skos:broader <D> .
<C> skos:broader <D> .

これは、多重階層の知識組織化体系に自然に発生するパターンです。

これらのグラフは両方とも、SKOSデータ・モデルと整合性があります。すなわち、階層関係の任意の2つのノード間に、唯一のパスがあることを要する条件はありません。

この仕様は、階層関係と関連関係を、全く根本的に異なるものとして扱います。したがって、階層リンクと関連リンク間の衝突は、SKOSデータ・モデルと整合性がありません。上記の例は、衝突の発生が見られるいくつかの状況を示しています。

この位置づけは、シソーラス規格[ISO2788] [BS8723-2]の階層関係と関連関係に与えられた普通の定義に従い、多くの既存の知識組織化体系の一般的な慣習をサポートします。

この仕様が、直近（つまり、直接的な）階層リンクと関連リンクが互いに素であるだけではなく、関連リンクが間接的な階層リンクとも素であるという、より強い立場を取ることに注意してください。これは、skos:relatedとskos:broaderTransitiveが互いに素のプロパティーであると言明する完全性条件で形式的に得られます。

SKOS概念集合は、ラベル付け、および/または順序付けされたKOS概念のグループです。

集合は、概念のグループが共通する何かを共有し、それらを共通のラベルでグルーピングすると便利な場合や、いくつかの概念を意味のある順序に配置できる場合に有用です。

次のグラフは、3つのメンバーを持つSKOS集合を例示しています。

<MyCollection> rdf:type skos:Collection ;
  skos:member <X> , <Y> , <Z> .

次のグラフは、3つのメンバーを持つ順序付きのSKOS集合を例示しています。Turtle構文(...)を用いて、RDF集合（リスト）を表していることに注意してください。

<MyOrderedCollection> rdf:type skos:OrderedCollection ;
  skos:memberList ( <X> <Y> <Z> ) .

ステートメントS36は、skos:memberListとskos:memberのプロパティー間の論理関係を述べています。この関係は、順序付きの集合から集合を推論できることを意味します。これは、次の例で示しています。

<MyOrderedCollection> rdf:type skos:OrderedCollection ;
  skos:memberList ( <X> <Y> <Z> ) .

は、次を含意する。

<MyOrderedCollection> rdf:type skos:Collection ;
  skos:member <X> , <Y> , <Z> .

SKOSが、集合が順序付けされていないと明示的に述べる方法を提供しないことに注意してください。

skos:memberListが関数型プロパティーである、すなわち、1つ以上の値を持たないことに注意してください。これは、SKOSデータ・モデル内では、順序付き集合が1つ以上のメンバー・リストを持つことは不合理であることを捉えるためのものです。残念ながら、2つのリストが異なる対象であると明示的に述べずに、この条件を完全性条件として用いることはできせん。言い換えれば、次のグラフは、SKOSデータ・モデルと整合性がありますが、不合理（最初の要素が2つあり、末尾が分岐したリスト）を含意します。

<OrderedCollectionResource>
  skos:memberList ( <A> <B> ) , ( <X> <Y> ) .

は、次を含意する。

<OrderedCollectionResource>
  skos:memberList [ rdf:first <A> , <X> ; rdf:rest [ rdf:first <B> ; rdf:rest rdf:nil ] , [ rdf:first <Y> ; rdf:rest rdf:nil ] ] .

しかし、[RDF-SEMANTICS]3.3.3項で述べているように、RDFの意味拡張では、このようなグラフを排除するために、RDF集合語彙（rdf:first、rdf:rest、rdf:nil）の使用に構文上の整形式の制約を加えるかもしれません。

次の例では、集合は別の集合内で入れ子にされています。

<MyCollection> rdf:type skos:Collection ;

skos:member <A> , <B> , <MyNestedCollection> .

<MyNestedCollection> rdf:type skos:Collection ;

skos:member <X> , <Y> , <Z> .

skos:memberの値域はskos:Conceptとskos:Collectionの和集合であるため、この例は、SKOSデータ・モデルと整合性があります。

SKOSデータ・モデルでは、skos:Conceptとskos:Collectionは互いに素のクラスです。SKOSの意味関係プロパティーの定義域と値域はskos:Conceptです。したがって、SKOSの意味関係プロパティーのどれか（例えば、skos:narrower）が、集合に、または集合からリンクするために用いられていれば、そのグラフは、SKOSデータ・モデルと整合性がないでしょう。

これは、次の例で示しており、SKOSデータ・モデルと整合性がありません。

<A> skos:narrower <B> .
<B> rdf:type skos:Collection .

同様に、次のグラフは、SKOSデータ・モデルと整合性がありません。

<A> skos:broader <B> .
<B> rdf:type skos:Collection .

同様に、次のグラフは、SKOSデータ・モデルと整合性がありません。

<A> skos:related <B> .
<B> rdf:type skos:Collection .

しかし、次のグラフは、SKOSデータ・モデルと整合性があります。

<A> skos:narrower <B> , <C> , <D> .

<ResourceCollection> rdfs:label "Resource Collection"@en ;

skos:member <B> , <C> , <D> .

これは、シソーラスやその他の知識組織化体系では、そのシソーラスの体系表示にノードラベルが用いられている場合、適切なSKOS表現には注意深い検討が必要であることを意味します。さらに、体系表示にノード・ラベルを用いる場合、SKOS表現のみから体系表示を完全に再構築することは、常に可能であるわけではありません。レイアウトと見栄えの詳細を含む、シソーラスやその他の知識組織化体系の体系表示で表された情報のすべてを完全に表すことは、SKOSの範囲を超えています。

SKOSマッピング・プロパティーは、skos:closeMatch、skos:exactMatch, skos:broadMatch、skos:narrowMatch、およびskos:relatedMatchです。これらのプロパティーは、異なる概念体系のSKOS概念間のマッピング（アラインメント）リンクを記述するために用いられ、その場合、リンクは、リンクされた概念の意味に内在しています。

プロパティーskos:broadMatchとskos:narrowMatchは、2つの概念間の階層マッピング・リンクを記述るために用いられます。

プロパティーskos:relatedMatchは、2つの概念間の関連マッピング・リンクを記述するために用いられます。

プロパティーskos:closeMatchは、一部の情報検索アプリケーションで交換して使用できるほど同じである2つの概念をリンクするために用いられます。2つ以上の概念体系にまたがるマッピングを結合するときには、「複合エラー」の可能性を避けるために、skos:closeMatchは、推移的なプロパティーであると宣言されません。

プロパティーskos:exactMatchは、2つの概念をリンクするために用いられ、その概念は幅広い情報検索アプリケーションにまたがって交換して使用できるほどの高い信頼性を示します。skos:exactMatchは、推移的なプロパティーであり、skos:closeMatchのサブプロパティーです。

skos:exactMatchが対称的なプロパティーであり、skos:broadMatchとskos:narrowMatchが逆であるため、skos:exactMatchは、skos:narrowMatchと互いに素でもあることに注意してください。

次のグラフは、<A>と<B>との完全同等性マッピング・リンクを言明します。

<A> skos:exactMatch <B> .

次のグラフは、<A>と<B>との類似同等性マッピング・リンクを言明します。

<A> skos:closeMatch <B> .

次のグラフは、<A>と<B>（<B>が<A>より広義）との階層マッピング・リンクと、<A>と<C>との関連マッピング・リンクを言明します。

<A> skos:broadMatch <B> ; skos:relatedMatch <C> .

次のグラフは、完全マッピング・リンクと階層マッピング・リンクの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<A> skos:exactMatch <B> ; skos:broadMatch <B> .

次のグラフは、完全マッピング・リンクと関連マッピング・リンクの間に衝突があるため、SKOSデータ・モデルと整合性がありません。

<A> skos:exactMatch <B> ; skos:relatedMatch <B> .

慣習上、SKOSマッピング・プロパティーは、異なる概念体系の概念をリンクするためにのみ用いられます。しかし、異なる概念体系の概念をリンクするために、SKOS意味関係プロパティー（skos:broader、skos:narrower、skos:related）を用いることもSKOSデータ・モデルと整合性があることに注意してください（8項を参照してください）。

マッピング・プロパティーskos:broadMatch、skos:narrowMatch、およびskos:relatedMatchは、データの来歴が分かっている状況に対し、便宜のために提供されます。そして、概念体系の内部リンクと概念体系間のマッピング・リンクとの違いが一見して分かることは有用です。

しかし、SKOSマッピング・プロパティーの使用は、RDFグラフの慎重な管理や、来歴メカニズムの使用の代りにはなりません。

この設計の論理的根拠は、概念体系の内部リンクと概念体系間のマッピング・リンクとを完全に区別するのは困難であるということです。これは特に、違う人が違う方法で概念を概念体系に再編成しうるオープンな環境に当てはまります。ある人がマッピング・リンクを持つ2つの概念体系と見なすことを、他の人は、内部リンクのみを持つ唯一の概念と見なすことがありえます。この仕様では、両方の視点の共存を許し、（望むらくは）ウェブ上でのSKOSデータの再使用における柔軟性と革新を促進します。

したがって、SKOS意味関係プロパティーとSKOSマッピング・プロパティーとの間には親密な関係があります。プロパティーskos:broadMatchは、skos:broaderのサブプロパティー、skos:narrowMatchは、skos:narrowerのサブプロパティー、skos:relatedMatchは、skos:relatedのサブプロパティーです。以下に、サブプロパティー関係の全ての集合を例示しています。

skos:semanticRelation
 |
 +- skos:related
 |   |
 |   +- skos:relatedMatch
 |
 +- skos:broaderTransitive
 |   |
 |   +- skos:broader
 |       |
 |       +- skos:broadMatch
 |
 +- skos:narrowerTransitive
 |   |
 |   +- skos:narrower
 |       |
 |       +- skos:narrowMatch
 |
 +- skos:mappingRelation
     |
     +- skos:closeMatch
     |   |
     |   +- skos:exactMatch
     |
     +- skos:relatedMatch
     |
     +- skos:broadMatch
     |
     +- skos:narrowMatch 

次の例では、このサブプロパティーのツリーと、skos:semanticRelationの定義域と値域に従ったいくつかの含意を示しています。

<A> skos:broadMatch <B> .

は、次を含意する。

<A> skos:mappingRelation <B> .
<A> skos:broader <B> .
<A> skos:broaderTransitive <B> .
<A> skos:semanticRelation <B> .
<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

<A> skos:narrowMatch <B> .

は、次を含意する。

<A> skos:mappingRelation <B> .
<A> skos:narrower <B> .
<A> skos:narrowerTransitive <B> .
<A> skos:semanticRelation <B> .
<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

<A> skos:relatedMatch <B> .

は、次を含意する。

<A> skos:mappingRelation <B> .
<A> skos:related <B> .
<A> skos:semanticRelation <B> .
<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

<A> skos:exactMatch <B> .

は、次を含意する。

<A> skos:closeMatch <B> .
<A> skos:mappingRelation <B> .
<A> skos:semanticRelation <B> .
<A> rdf:type skos:Concept .
<B> rdf:type skos:Concept .

違う人が違う方法で概念を概念体系に再編成するかもしれないため、グラフは、同じ概念体系の概念間のマッピング・リンクを言明するかもしれず、そのようなグラフを不整合にするSKOSデータ・モデルには、形式的な完全性条件はないことにも注意してください。例えば、下記のグラフはSKOSデータ・モデルと整合性があります。しかし、実際には、そのようなグラフは、異なる情報源を持つ2つ以上のグラフの結合からのみ生じると予想されます。

<A> skos:broadMatch <B> ; skos:relatedMatch <C> .

<A> skos:inScheme <MyScheme> .

<B> skos:inScheme <MyScheme> .

<C> skos:inScheme <MyScheme> .

次の例は、階層マッピング・リンクと関連マッピング・リンクとの「衝突」を示しており、SKOSデータ・モデルと整合性がありません（上で例示したサブプロパティー関係と、8項で定義されているSKOS意味関係プロパティーのデータ・モデルのせいで）。

<A> skos:broadMatch <B> ; skos:relatedMatch <B> .

<A> skos:narrowMatch <B> ; skos:relatedMatch <B> .

<A> skos:broadMatch <B> .
<B> skos:broadMatch <C> .
<A> skos:relatedMatch <C> .

推移的であると宣言される唯一のSKOSマッピング・プロパティーは、skos:exactMatchです。以下に、含意の例を示しています。

<A> skos:exactMatch <B> .
<B> skos:exactMatch <C> .

は、次を含意する。

<A> skos:exactMatch <C> .

他のすべてのSKOSマッピング・プロパティーは、推移的ではありません。したがって、次の例で示している含意は、SKOSデータ・モデルではサポートされていません。

<A> skos:broadMatch <B> .
<B> skos:broadMatch <C> .

は、次を含意しない。

<A> skos:broadMatch <C> .

<A> skos:relatedMatch <B> .
<B> skos:relatedMatch <C> .

は、次を含意しない。

<A> skos:relatedMatch <C> .

<A> skos:closeMatch <B> .
<B> skos:closeMatch <C> .

は、次を含意しない。

<A> skos:closeMatch <C> .

すべてのSKOSマッピング・プロパティーは、反射的でなく、非反射的でもありません。

skos:exactMatch、skos:broadMatch、およびskos:relatedMatchは、非反射的ではないため、次のグラフはSKOSデータ・モデルと整合性があります。

<A> skos:exactMatch <A> .
<B> skos:broadMatch <B> .
<C> skos:relatedMatch <C> .

しかし、SKOS意味関係プロパティーの反射性に関しては、8項も参照してください。

階層マッピング・リンクのグラフには、循環または代替パスのどちらかを阻止する形式的な完全性条件はありません。

次のグラフには、skos:broadMatchを伴った2つの循環があります。このグラフは、SKOSデータ・モデルと整合性があります。

<A> skos:broadMatch <B> .

<B> skos:broadMatch <A> .

<X> skos:broadMatch <Y> .

<Y> skos:broadMatch <Z> .

<Z> skos:broadMatch <X> .

次のグラフには、skos:broadMatchを伴った2つの代替パスがあります。このグラフは、SKOSデータ・モデルと整合性があります。

<A> skos:broadMatch <B> .
<B> skos:broadMatch <C> .
<A> skos:broadMatch <C> .

しかし、skos:broaderを伴った循環と代替パスに関しては、8項を参照してください。

<A> skos:exactMatch <B>

は、次を含意する。

<A> skos:exactMatch <A> .
<A> skos:closeMatch <A> .

上記の含意のため（S42、S44、およびS45の組み合わせで生じる）、アプリケーションは、skos:exactMatchとskos:closeMatchの循環に対応できなければなりません。

SKOSデータ・モデルには、skos:exactMatchまたはskos:closeMatchのプロパティーを伴ったサブプロパティー連鎖公理はありません。したがって、次に例示する含意は、サポートされません。

<A> skos:exactMatch <B> .
<B> skos:broadMatch <C> .

は、次を含意しない。

<A> skos:broadMatch <C> .

<A> skos:exactMatch <B> .
<B> skos:relatedMatch <C> .

は、次を含意しない。

<A> skos:relatedMatch <C> .

<A> skos:closeMatch <B> .
<B> skos:broadMatch <C> .

は、次を含意しない。

<A> skos:broadMatch <C> .

<A> skos:closeMatch <B> .
<B> skos:relatedMatch <C> .

は、次を含意しない。

<A> skos:relatedMatch <C> .

OWLは、一見したところではskos:closeMatchやskos:exactMatchと同じに見えるかもしれない3つのプロパティーを提供します。owl:sameAsは、オントロジーの2つの個体をリンクするために用いられ、それらが同じ個体（すなわち、同じ資源）であることを示します。owl:equivalentClassは、オントロジーの2つのクラスをリンクするために用いられ、それらのクラスが同じクラス拡張を持つことを示します。owl:equivalentPropertyは、オントロジーの2つのプロパティーをリンクするために用いられ、両方のプロパティーが同じプロパティー拡張を持つことを示します。

skos:closeMatchとskos:exactMatchは、異なる体系のSKOS概念をリンクするために用いられます。skos:closeMatchリンクは、2つの概念が十分に同じであるため、一部の情報検索アプリケーションで交換して使用できることを示します。skos:exactMatchリンクは、2つの概念を幅広い情報検索アプリケーションにまたがって交換して使用できるほどの高い信頼性を示します。

owl:sameAs、owl:equivalentClass、またはowl:equivalentPropertyは、形式的な結果が望ましくないかもしれないため、異なる概念体系のSKOS概念をリンクするためには通常、不適切でしょう。

次の例は、この方法でのowl:sameAsの使用から得られるいくつかの望ましくない含意を示します。

<A> rdf:type skos:Concept ;

skos:prefLabel "love"@en ;

skos:inScheme <MyScheme> .

<B> rdf:type skos:Concept ;

skos:prefLabel "adoration"@en ;

skos:inScheme <AnotherScheme> .

<A> owl:sameAs <B> .

は、次を含意する。

<A>

skos:prefLabel "love"@en ;

skos:prefLabel "adoration"@en ;

skos:inScheme <MyScheme> ;

skos:inScheme <AnotherScheme> .

<B>   

skos:prefLabel "love"@en ;

skos:prefLabel "adoration"@en ;

skos:inScheme <MyScheme> ;

skos:inScheme <AnotherScheme> .

この例では、異なる概念体系の2つのSKOS概念をリンクするためにowl:sameAsを用いると、<A>と<B>の両方が、ここでは同じ言語による2つの優先語彙ラベルを持つため、実際には、SKOSデータ・モデルとの不整合につながります。しかし、いつもそうとは限らないでしょう。

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4