2.1 Organizational structure

This section is non-normative.

The core class in the ontology is org:Organization which is intended to be applicable to a very broad range of organizations. It represents a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it. An organization may itself be able to act as an agent.

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. For example in UK legislation there are defined notions of Partnership, Limited Company etc that can be used as a basis for classification. Alternatively organizations can be classified 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 either introduce sub-classes of org:Organization or define a classification scheme for organizations. To support the latter the ontology supplies a property org:classification which can be used the classify an organization using a SKOS [SKOS-REFERENCE] concept scheme.

Which of these mechanisms to use depends on the situation. If the classification is not intrinsic to the organization but simply some way to group organizations, for example as part of a directory, then org:classification should be used. If the classification is a reflection of the intrinsic nature of the organization and affects other properties then the sub-class approach should be used. For example, only charities have charity numbers so it would be better to represent a charity as a sub-class of org:FormalOrganization rather than via a taxonomic labelling.

2.2 Membership and Reporting structure

This section is non-normative.

ORG provides a number of ways to represent the relationship between people and organizations, together with the internal reporting structure of an organization. Experience with early versions of the ontology demonstrated that there is no "one size that fits all". 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

This section is non-normative.

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

This section is non-normative.

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

This section is non-normative.

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

Note

In earlier versions of this ontology the OPMV Provenance Vocabulary was used. We believe that the PROV-O terms used here are equivalent to the corresponding OPMV terms previously used and that this change does not affect the semantics of the ontology.

2.5 Notes on modelling style

This section is non-normative.

Use of inverses: designers differ on whether providing pairs of inverse relationships between concepts is good practice compared to declaring each relationship in just one direction. In this design we provide inverses for most relations (omitting attribute-like relations). This makes it easier to query the data in linked data settings where a (non-symmetric) closed bounded description is often the default description of each resource. This does incur a cost in terms of maintenance of those relationships. Particular applications of the ontology may adopt a profile in which only certain directions are asserted in the data and leave it up to clients to apply any inverseOf reasoning they require.

Naming: some designers prefer to name properties by nouns which describe the object of the property, others prefer to treat property names as names of the link and use a pattern to indicate the direction of the link. Here we adopt the latter approach for those properties which are relational and especially when the direction is ambiguous. We use the URI pattern org:hasFoo/org:fooOf for this but simplify the labels to "foo" and "foo of" to improve readability in linked data viewers.