Description and commentary
Organizational structure
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.
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. 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
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.
}
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> .
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.
