W3C Organization Ontology

2.1 Organizational structure

The core class in the ontology is org:Organization which represents a collection of people organized together into a community or other social, commercial or political structure.

We distinguish a particular sub-class of organization org:FormalOrganization to indicate organizations that are recognized in the world at large, in particular in legal jurisdictions, with associated rights and responsibilities. Examples include a corporation, charity, government or church.

The ontology then supports the notion of organizations being composed of other organizations in some hierarchy. The relations org:subOrganizationOf and org:hasSubOrganization establish these hierarchical links.

In some cases the sub-organization can be regarded as standalone – for example a legally recognized business may be part of a larger group or holding company. In other cases it is useful to refer to departments or organizational units such as the IT department which only have meaning within the context of the containing organization. The ontology supports that situation through a specialization of org:Organization called org:OrganizationalUnit. For convenience it also provides the relations org:hasUnit and org:unitOf which are specializations of the generic sub-organization links.

Note that the containment hierarchy is completely open. For example, org:FormalOrganizations are free to contain other org:FormalOrganizations.

Organizational hierarchy

In many organizations there is a hierarchy of unit structures. For example we might see a containment hierarchy like:

Corporation
  BusinessUnit
    Division
      Function

Such hierarchies are specific to the particular organization, or class of organization being modelled. Profiles of ORG may include sub-classes of org:Organization and org:OrganizationalUnit to represent such structures and specialize or restrict the use of org:hasSubOrganization to match the desired hierarchy.

Organizational classification

In a number of circumstances we wish to classify organizations. There are many approaches that could be taken for this. It can be based on the legal structure under which the organization operates or by the service they provide (e.g. educational, manufacturing, legal service etc).

ORG is neutral with respect to such choices. It is anticipated that profiles will introduce sub-classes of org:Organization when the classification is a reflection of the intrinsic nature of the organization and affects other properties.

2.2 Membership and Reporting structure

ORG provides a number of ways to represent the relationship between people and organizations, together with the internal reporting structure of an organization. In some cases a very simple direct representation is preferred for ease of consumption. In other cases a more complex representation is needed to capture the nuances of the situation. An ORG profile may specify that a particular subset of these mechanisms be used.

Direct membership relation

This simplest representation provided by ORG is to directly state that some individual (represented as a foaf:Agent) is org:memberOf an organization. To represent specific roles that the person plays, ORG profiles may define sub-properties of org:memberOf. In particular, the notion of a leader or head of a organization is so common that ORG provides a built in property specialization of org:memberOf, namely org:headOf for this purpose.

For example:

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

Membership n-ary relationship

However, in general it is advantageous to have an explicit representation of the organizational role that the person fulfils (e.g. for publication of responsibilities associated with the role). This is supported by the org:Role class. The situation of an Agent fulfilling that role within an organization is then expressed through instances of the org:Membership n-ary relationship. This also makes it possible to annotate the relationship with qualifying information such as duration, salary, reference to the employment contract and so forth.

For example:

<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]].

The relationship between this full n-ary relationship and the direct org:memberOf property can be expressed as an entailment rule, using SPARQL Construct [RDF-SPARQL-QUERY]:

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

Since this representation can be a little less convenient to query and explore via linked data browsing tools the core allows both explicit roles and simple direct relations to be used simultaneously. The relationship between the Role resource and the corresponding property can be indicated through the org:roleProperty annotation. Thus we might extend the above example with:

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>. 

The semantics of org:roleProperty can be expressed using a second closure rule:

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

Tool chains may generate org:Membership instances and then apply this closure rule to add any corresponding short-cut specializations of org:memberOf.

Posts

The third representation that is provided by ORG is that of a org:Post which represents some position in the organization that may or may not be currently filled. Posts enable reporting structures and organization charts to be represented independently of the individuals holding those posts. Posts can report to other Posts.

So a org:Post can exist without someone holding that post. In contrast, a org:Membership represents the relationship between a particular individual (Agent) and the organization and does not exist unless there is an Agent to partake of the relationship.

While commonly a Post would be held by a single person there are situations in government organizations where a Post may itself be, or be treated as, an Organization. There are no disjointness constraints precluding an application of ORG from treating an entity as both a org:Post and an org:Organization simultaneously, if that is an appropriate modelling of the situation.

A post can have an associated org:Role.

Relationship between Posts and Memberships

In many situations only one of Post or Membership is needed, and ORG profiles may specify that use of one of the two is preferred. In cases where the structure of the organization is to be given, independently of the people within that structure, then org:Post is the appropriate representation to choose. In cases where the aim is to record the people who make up the organization and those memberships are likely to be annotated (e.g. with duration of the membership) then org:Membership is appropriate.

We can state a formal relationship between these representations in the form of two entailment rules:

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 Location information

ORG provides org:Site to represent locations at which organizations exist. The relations org:siteOf and org:hasSite establish links between a org:Site and an organization. We distinguish a primary site (org:hasPrimarySite) to indicate the default means by which an organization can be contacted, and a registered site (org:hasRegisteredSite) to indicate a legally registered site for the organization.

The ontology provides org:siteAddress to define the address of a site using a vocabulary such as the vCard [vcard-rdf] vocabulary.

2.4 Organizational history

Any aspect of organizational structure is subject to change over time. For the most part this should be handled by an external mechanism such as named graphs. When Organizations change substantially (not simply a change of personnel or internal structure), for example a merger to create a new organization, then the new Organization will typically be denoted by a new URI. In that case we need some vocabulary to describe that change over time and the relationship between the original and resulting resources. ORG provides org:ChangeEvent and associated properties as a foundation for this, building upon the PROV-O Provenance Vocabulary [prov-o].

For example to indicate that an organization now called “Department for Education” was formed as a result of rebranding and restructuring and organization called “Department for Children Schools and Family” we might state:

    <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> .

An application can use terms from the PROV-O vocabulary to further describe the change event, for example the period of time over which it occurred. Such usage of PROV-O terms should take into account the semantic constraints [prov-constraints] of the PROV model.

It is sometimes convenient to be able to directly link from an organization to a previous organization from which it descended. This is supported by using the prov:wasDerivedFrom relationship. ORG declares the property chain axiom:

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

Which can also be expressed using a SPARQL CONSTRUCT

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

Thus in our previous example, given that org:resultedFrom and org:resultingOrganization are inverse of each other, we can deduce:

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

2.5 Notes on modelling style