2.1 組織構造

この項は非規範的です。

オントロジーのコア・クラスは、非常に広範囲の組織に適用できることを目的としたorg:Organizationです。それは、コミュニティーや、その他の社会、商業、政治的な構造に共に編入された人々の集合を表します。グループには、そこに属する人々を超えた、存在に対するある共通の目的や理由があります。組織自体は、エージェント（代理）を務めることができるかもしれません。

関連する権利と責任を有する（特に法的管轄区域において）世界中に広く認識されている組織を示すために、組織の特定のサブクラスorg:FormalOrganizationを識別します。例には、企業、慈善団体、政府や教会が含まれます。

その後、オントロジーは、ある階層構造のもとに他の複数の組織で編成されている組織の概念をサポートします。org:subOrganizationOfとorg:hasSubOrganizationという関係は、これらの階層的リンクを確立します。

下部組織を単体と見なすことができる場合もあります。例えば、法律上認識されているある企業は、より大きなグループや持ち株会社の一部でありえます。IT部門などの、それを含んでいる組織という脈絡でのみ意味を有する、部局や組織単位を参照することが有用である場合もあります。このオントロジーでは、org:OrganizationalUnitと呼ばれるorg:Organizationの特殊化により、この状況をサポートします。便宜上、汎用的な下部組織リンクの特殊化であるorg:hasUnitとorg:unitOfという関係も提供しています。

包含階層が完全にオープンであることに注意してください。例えば、org:FormalOrganizationは、他のorg:FormalOrganizationを自由に含むことができます。

組織階層

多くの組織では、単位構造の階層があります。例えば、次のような包含階層がありえます。

Corporation
  BusinessUnit
    Division
      Function

このような階層は、特定の組織、またはモデル化された組織のクラスに固有のものです。ORGのプロファイルは、そのような構造を表すために、org:Organizationとorg:OrganizationalUnitというサブクラスを含むことができ、望ましい階層に合うようにorg:hasSubOrganizationの使用を特殊化または制限することができます。

組織の分類

多くの状況で、組織を分類したい場合があります。このために取ることができるアプローチはたくさんあります。組織が活動する法的な構造に基づくことができます。例えば、英国の法律には、分類の基礎として使用できる共同経営（Partnership）、有限会社（Limited Company）などの確定した概念があります。あるいは、組織は、提供するサービス（例えば、教育、製造、法的サービスなど）で分類できます。

ORGはそのような選択に関しては中立的です。プロファイルがorg:Organizationのサブクラスを導入するか、組織の分類表を定義するだろうと予想されます。後者をサポートするために、オントロジーは、SKOS[SKOS-REFERENCE]の概念スキームを用いて組織を分類するために使用できるorg:classificationというプロパティーを提供します。

これらのメカニズムのどれを用いるかは、状況によります。分類がその組織に固有のものではなく、例えば、単に名簿の一部として組織をグループ化するための何らかの方法であれば、org:classificationを使用すべきです。分類が組織の固有の本質を現したものであり、他のプロパティーに影響を与える場合、サブクラスのアプローチを使用すべきです。例えば、慈善団体のみが慈善団体番号（charity number）を持っています。したがって、タクソノミーのラベル付けによってではなく、org:FormalOrganizationのサブクラスとして慈善団体を表すほうがよいでしょう。

2.2 構成員および上下構造

この項は非規範的です。

ORGは、組織内部の上下構造とともに、人と組織の関係を表す多くの方法を提供します。オントロジーの初期バージョンでの経験により、「何にでもあてはまる方法はない」ことが実証されました。利用しやすいように、非常に単純で直接的な表現が望ましい場合があります。また、状況のニュアンスを捕捉するために、より複雑な表現が必要である場合もあります。ORGプロファイルは、これらのメカニズムの特定のサブセットを用いるように指示するかもしれません。

直接的な構成員関係

ORGが提供するこの最も単純な表現は、ある個人（foaf:Agentとして表される）が組織のorg:memberOfであると直接述べるものです。人が担う特定の役割を表すために、ORGプロファイルは、org:memberOfのサブプロパティーを定義できます。特に、組織のリーダーやトップの概念は非常に一般的であるため、ORGは、org:memberOfの組み込み済みプロパティー特殊化、すなわち、この目的の場合はorg:headOfを提供します。

例:

<http://example.com/people#ceo> 
  org:headOf    <http://example.com/org#id>. 

構成員のn項関係

しかし、一般的に、人が遂行する組織上の役割の明示的な表現を持っていることは有益です（例えば、役割に関連する責任の公開のために）。これはorg:Roleというクラスでサポートされます。その後、組織内でその役割を遂行するエージェントの状況がorg:Membershipn項関係のインスタンスで表されます。これにより、時間長、給料、雇用契約への参照などの資格情報との関係にアノテーションを付与することも可能になります。

例:

<http://example.com/org#id> a org:FormalOrganization;
    skos:prefLabel "Example Ltd".

eg:ctoRole a org:Role;
    skos:prefLabel "CTO".
        
[] a org:Membership;
    org:member <http://example.com/people#jo>;
    org:organization <http://example.com/org#id>;
    org:role eg:ctoRole;
    org:memberDuring [a time:Interval; time:hasBeginning [
                      time:inXSDDateTime "2009-11-01T09:00:00Z"^^xsd:dateTime]].

この完全なn項関係と直接的なorg:memberOfプロパティーとの関係は、SPARQL構成子[RDF-SPARQL-QUERY]を用いて、含意規則として表現できます。

CONSTRUCT {
    ?agent   org:memberOf  ?org.
} WHERE {
  [] a org:Membership;
    org:member       ?agent;
    org:organization ?org.
}

この表現は、リンクト・データのブラウジング・ツールでクエリと探求を行うにはあまり便利ではないため、コアによって、明示的な役割とシンプルな直接関係の両方を同時に用いることが可能となります。役割資源と対応するプロパティーの関係は、org:rolePropertyアノテーションで示すことができます。したがって、次の記述は上記の例を拡張するかもしれません。

eg:ctoRole a org:Role;
    org:roleProperty eg:ctoOf.
    
eg:ctoOf a owl:ObjectProperty, rdf:Property;
    skos:prefLabel "CTO";
    rdfs:subPropertyOf org:memberOf.
        
<http://example.com/people#jo> 
  eg:ctoOf <http://example.com/org#id>. 

org:rolePropertyのセマンティクスは、別の閉包規則を用いて表現できます。

CONSTRUCT {
    ?agent   ?roleprop  ?org.
} WHERE {
  [] a org:Membership;
    org:member       ?agent;
    org:organization ?org;
    org:role         [ org:roleProperty ?roleprop ].
}

ツールの連鎖は、org:Membershipというインスタンスを生成し、次に、この閉包規則を適用して、対応するorg:memberOfの省略形の特殊化を追加できます。

ポスト

この項は非規範的です。

ORGが提供する3番目の表現は、現在就任しているかもしていないかもしれない、組織におけるあるポストを表すorg:Postです。ポストにより、そのポストに就いている個人とは無関係に、上下構造と組織図を表すことができます。ポストは、他のポストの管理下に入ることができます。

したがって、org:Postは、そのポストを保持している人がなくても存在できます。対照的に、org:Membershipは、特定の個人（エージェント）と組織との関係を表し、もしその関係を共有するエージェントがいなければ存在しません。

一般的に、ポストは1人の人が保持するものですが、政府機関には、ポスト自体が組織であったり、ポストが組織として扱われるような状況もあります。モデリングがその状況に適したものであれば、ORGのアプリケーションがエンティティーをorg:Postとorg:Organizationの両方として同時に扱うことを排除する素の制約はありません。

ポストは、関連するorg:Roleを持つことができます。

ポストと構成員との関係

多くの状況では、ポストまたは構成員のうちの1つのみが必要で、ORGプロファイルには、2つのうちの1つの使用が望ましいと規定されているかもしれません。組織の構造が、その構造内の人々と無関係に与えられている場合、選択に適している表現はorg:Postです。組織を構成する人々を記録することが目的であり、その構成員にアノテーションを付与できる可能性が高い場合（例えば、構成員の年限）には、org:Membershipが適切です。

これらの表現の正式な関係は、次の2つの含意規則の形で述べることができます。

CONSTRUCT {
  ?agent  org:memberOf ?org.
} WHERE {
  ?agent org:holds  ?post.
  ?post  org:postIn ?org.
}

CONSTRUCT {
  [] a org:Membership;
    org:member       ?agent;
    org:organization ?org;
    org:role         ?role.
} WHERE {
  ?agent org:holds  ?post.
  ?post  org:postIn ?org.
  ?post  org:role   ?role.
}

2.3 位置情報

この項は非規範的です。

ORGは、組織が存在する位置を表すためにorg:Siteを提供しています。org:siteOfとorg:hasSiteという関係は、org:Siteと組織の間のリンクを確立します。ここでは、組織が連絡を受けることができるデフォルトの方法を示す主要サイト（org:hasPrimarySite）と、組織の法律上登録されたサイトを示す登録サイト（org:hasRegisteredSite）とを区別します。

オントロジーは、vCard [vcard-rdf]語彙などの語彙を用いてサイトのアドレスを定義するためにorg:siteAddressを提供します。

2.4 組織の沿革

この項は非規範的です。

組織構造のいかなる側面も、時間と共に変わる可能性があります。ほとんどの場合、これは名前付きグラフなどの外部メカニズムで対応すべきです。新組織を作るための合併など、組織が大幅に変わる時には（単なる人員や内部構造の変更ではなく）、一般的に、新組織は新しいURIで示されるでしょう。その場合、その経時的な変化と、元の資源と結果として生じる資源との関係を記述するためには語彙が必要です。ORGは、この基盤として、PROV-O Provenance Vocabulary[prov-o]に基づいて、org:ChangeEventおよび関連するプロパティーを提供します。

例えば、「教育省」（Department for Education）と現在呼ばれる組織が、「子ども・学校・家庭省」（Department for Children Schools and Family）と呼ばれる組織のブランドを再構築し、再編した結果作られたことを示すために、次のように記述するかもしれません。

    <http://example.com/DfE> a org:Organization;
        skos:prefLabel  "Department for Education"@en .

    <http://example.com/DCSF> a org:Organization;
        skos:prefLabel  "Department for Children Schools and Family"@en .

    <http://example.com/regorgMay2010> a org:ChangeEvent;
        rdfs:comment "Post-election re-organization and rebranding"@en ;
        org:originalOrganization  <http://example.com/DfE> ;
	org:resultingOrganization <http://example.com/DCSF> .

アプリケーションは、さらに変更のきっかけとなった出来事（例えば、それが発生した期間）を記述するためにPROV-O語彙の用語を使用できます。このようなPROV-O用語の使用にあたっては、PROVモデルのセマンティックな制約[prov-constraints]を考慮に入れるべきです。

組織からその変遷前の組織に直接リンクできるとは便利である場合があります。これは、prov:wasDerivedFrom関係を用いることでサポートされます。ORGは、次のプロパティー連鎖公理を宣言します。

   SubObjectPropertyOf( ObjectPropertyChain( org:resultedFrom org:originalOrganization ) prov:wasDerivedFrom )

これは、SPARQL CONSTRUCTを用いて表現することもできます。

CONSTRUCT {
  ?orgR prov:wasDerivedFrom ?orgO .
} WHERE {
   ?orgR org:resultedFrom / org:originalOrganization ?orgO .
}

したがって、前の例において、org:resultedFromとorg:resultingOrganizationが互いの逆であれば、次のように推測できます。

    <http://example.com/DfE> prov:wasDerivedFrom <http://example.com/DCSF> .

注

このオントロジーの初期のバージョンでは、OPMV Provenance Vocabularyが用いられていました。ここで用いているPROV-O用語が以前に用いられていた対応するOPMV用語と同等であり、この変更がオントロジーのセマンティクスには影響しないものと考えています。

2.5 モデル化スタイルに関する注

この項は非規範的です。

逆の使用: 設計者達は、概念間の対の逆の関係の提供が、片方向のみの関係をそれぞれ宣言するのに比べて良いことなのかどうかに関して異なる意見を持っています。このドキュメントの設計では、ほとんどの関係に対して逆を提供しています（属性のような関係は省略して）。これにより、（非対称的な）閉じた有限記述（closed bounded description）がしばしば各資源のデフォルトの記述であるようなリンクト・データの設定でデータにクエリを行うことがより容易になります。これは、それらの関係の維持の点でコストがかかります。オントロジーの特定のアプリケーションは、データ内である方向のみが言明されたプロファイルを採用し、必要なinverseOf推論の適用はすクライアントに任せることができます。

名前付け: 設計者には、プロパティーのオブジェクトを表す名詞でプロパティーを名付けることを好む人もいれば、プロパティ名をリンクの名前として扱い、リンクの方向を示すためにパターンを用いることを好む人もいます。ここでは、リレーショナルなプロパティーに対して、また、特に方向が曖昧な場合に、後者のアプローチを採用します。これに対し、我々はorg:hasFoo/org:fooOfというURIパターンを用いていますが、リンクト・データのビューアーでより読みやすくするために、ラベルを「foo」と「foo of」に単純化しています。