Copyright © 2010 Epimorphics Ltd
This work is licensed under a Creative Commons License.
This document describes a core ontology for organizational structures, aimed at supporting linked-data publishing of organizational information across a number of domains. It is designed to allow domain-specific extensions to add classification of organzations and roles, as well as extensions to support neighbouring information such as organizational activities.
This is an editor's draft without any formal standing. It is not endorsed by any organisation and is not, at present, part of any standards track process. Its use of the W3C namespace does not imply W3C endorsement.
Changes to the ontology will be announced on the public-lod mail list.
This ontology was original motivated by a need to publish information relating to government organizational structure as part of the data.gov.uk initiative. We felt that the best approach was to develop a small, generic, reusable core ontology for organizational information and then let developers extend and specialize it to particular domains.
The ontology gives minimal basic terms to support representation of:
This coverage corresponds to the type of information typically found in organizational charts. As such it does not offer a complete representation for all the nuances of organizational control structures and flows of accountability and empowerment. Developers are encouraged to create extension vocabularies for such purposes, building upon this generic foundation.
The ontology does not provide category structures for organization type, organization purpose or roles. Different domains will have different requirements for classification of such concepts. Instead the ontology provides just the core base concepts needed to allow extensions to add specific sub-class structures or classification schemes as required.
The namespace for the ontology is: http://www.w3.org/ns/org#
For background to the approach taken in developing the ontology see: blog notes
Use of inverses: authorities 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 storage or use of run-time inference. 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.
org:Organization
(subClassOf foaf:Agent
)skos:prefLabel
for the primary (e.g. legally recognized name), skos:altLabel
for alternative names (trading names, colloquial names) and skos:notation
to denote codes from a code list. Alternative names: Collective Body Org Group
org:FormalOrganization
(subClassOf org:Organization
, foaf:Organization
; superClassOf gr:BusinessEntity
)gr:BusinessEntity
and it is recommended to use the GoodRelations vocabulary to denote Business classifications such as DUNS or NAICS.
org:OrganizationalUnit
(subClassOf org:Organization
)
org:subOrganizationOf
(org:Organization
-> org:Organization
)org:hasSubOrganization
. Alternative names: subOrgOf
org:transitiveSubOrganizationOf
(org:Organization
-> org:Organization
, Transitive super property of org:subOrganizationOf
)
org:hasSubOrganization
(org:Organization
-> org:Organization
)org:subOrganizationOf
. Alternative names: hasSubOrg
org:purpose
(org:Organization
-> *)skos:Concept
. However, the range is left open to allow for other types of descriptive schemes. It is expected that specializations or application profiles of this vocabulary will constrain the range of the purpose. Alternative names: remit responsibility (esp. if applied to OrganizationalUnits such as Government Departments).
org:hasUnit
(org:Organization
-> org:OrganizationalUnit
, subPropertyOf hasSubOrganization
)org:unitOf
.
org:unitOf
(org:OrganizationalUnit
-> org:Organization
, subPropertyOf subOrganizationOf
)org:hasUnit
.
org:classification
(org:Organization
-> skos:Concept
)skos:ConceptScheme
. This property is under discussion and may be revised or removed - in many cases organizations are best categorized by defining a sub-class hierarchy in an extension vocabulary.
org:identifier
(org:Organization
->, subPropertyOf skos:notation
)skos:notation
of which this property is a specialization.
org:linkedTo
(org:Organization
-> org:Organization
)Note that the subclass hierarchy
below org:Organization
is not a full covering. There
can be org:Organization
s which are in
neither org:FormalOrganization
nor org:OrganizationalUnit
. The distinction between
an externally recognized organization and one which only has
meaning in the context of a larger organization is a common one
which we support to simplify the mapping to existing practice. Note
that the containment hierarchy is completely open
- org:FormalOrganization
s are free to contain
other org:FormalOrganization
s (e.g. subsidiaries of
large corporations). We invite feedback from users of the ontology as to
whether this distinction useful in practice.
In many organizations there is a hierarchy of unit structures. For example we might see a containment hierarchy like:
Corporation BusinessUnit Division Function
The intention is that this would be added in custom extensions since they are specific to the
organization at hand. This can easily be done by subclassing org:OrganizationalUnit
,
specializing org:hasSubOrganization
and/or using owl:allValuesFrom
restrictions on the new subclasses.
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 (public, private) etc that can be used as a basis for classification. Alternatively organizations can be classified by the service they provide (e.g. Educational, Manufacturing, LegalService etc).
The core organization ontology is neutral with respect to such choices.
It is anticipated that applications to particular domains will introduce
subclasses of org:Organization
to reflect the domain requirements.
Note that the core supports labelling an organization according to some
external classification scheme through use of the org:classification
property.
This is appropriate for cases where the labelling is not intrinsic to the organization
and doesn't affect other aspects of the modelling.
This is not always appropriate.
For example, only Charities have CharityNumbers so it would be better to represent a
Charity as a subClassOf FormalOrganization rather than via a taxonomic labelling.
org:memberOf
(foaf:Agent
-> org:Organization
)
org:hasMember
(org:Organization
-> foaf:Agent
, equivalent property to foaf:member
)
org:reportsTo
(foaf:Agent
-> foaf:Agent
)
org:Role
subClassOf skos:Concept
org:Membership
. It is common for roles to be arranged in some taxonomic structure and we use SKOS to represent that. The normal SKOS lexical properties should be used when labelling the Role. Additional descriptive properties for the Role, such as a Salary band, may be added by extension vocabularies.
org:Membership
org:memberOf
property.
org:member
(org:Membership
-> foaf:Agent
)org:hasMembership
org:organization
(org:Membership
-> org:Organization
)
org:role
(org:Membership
-> org:Role
)
org:hasMembership
(foaf:Agent
-> org:Membership
)org:member
.
org:memberDuring
(org:Membership
-> owlTime:Interval
)
org:roleProperty
(org:Role
-> rdf:Property
)org:Role
instance with a sub-property of org:memberOf
that can be used to directly indicate the role for easy of query. The intended semantics is a Membership relation involving the Role implies the existence of a direct property relationship through an inference rule of the form: { [] org:member ?p; org:organization ?o; org:role [org:roleProperty ?r] } -> {?p ?r ?o}
.
org:headOf
(foaf:Agent
-> org:Organization
) subPropertyOf org:memberOf
org:reportsTo
(acyclic) graph, though an organization may have more than one head.
org:remuneration
(org:Membership
->)gr:PriceSpecification
but the range is left open to allow applications to specialize it (e.g. to remunerationInGBP).In some applications then it is sufficient to represent the role of an individual
within an Organization by specializations of org:memberOf
, as in the
builtin example org:headOf
.
However, in general it is advantageous to have an explicit representation of the organizational role (e.g.
to enable advertising of a post or for publication of salary ranges 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 relation. 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://www.epimorphics.com/public/org#epimorphics> a org:FormalOrganization; skos:prefLabel "Epimorphics Ltd" . eg:ctoRole a org:Role; rdfs:label "CTO" . [] a org:Membership; org:member <http://www.amberdown.net/rdf/foaf.rdf#der> ; org:organization <http://www.epimorphics.com/public/org#epimorphics> ; org:role eg:ctoRole; org:memberDuring [a owlTime:Interval; owlTime:hasBeginning [ owlTime:inXSDDateTime "2009-11-01T09:00:00Z"^^xsd:dateTime]] .
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 ; rdfs:label "CTO" ; rdfs:subPropertyOf org:memberOf . <http://www.amberdown.net/rdf/foaf.rdf#der> eg:ctoOf <http://www.epimorphics.com/public/org#epimorphics> .
In practice we antipate tool chains generating the org:Membership
instances
and a simple closure rule being used to add any corresponding short-cut specializations of org:memberOf
.
org:Site
org:siteAddress
(org:Site
-> vcard:VCard
)
org:hasSite
(org:Organization
-> org:Site
)org:siteOf
.
org:siteOf
(org:Site
-> org:Organization
)org:hasSite
.
org:hasPrimarySite
(org:Organization
-> org:Site
) subPropertyOf org:hasSite
org:hasRegisteredSite
(org:FormalOrganization
-> org:Site
) subPropertyOf org:hasPrimarySite
org:basedAt
(foaf:Person
-> org:Site
)
org:location
(foaf:Person
-> xsd:string)org:OrganizationalCollaboration
(subClassOf org:Organization
)org:Organization
s rather than individuals and those Organizations can play particular roles within the venture. Alternative names: Project Venture Endeavour ConsortiumAny 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 and we need some vocabulary to describe that change over time and the relationship between the original and resulting resouces. The Event mechanism here gives a generic hook for this, building upon the OPMV Provenance Vocabulary.
org:ChangeEvent
(subClassOf opmv:Process)
org:originalOrganization
(org:ChangeEvent
-> org:Organization
) subPropertyOf opmv:used
org:changedBy
(org:Organization
-> org:ChangeEvent
)
org:resultedFrom
(org:Organization
-> org:ChangeEvent
) subPropertyOf opmv:wasGeneratedBy
org:resultingOrganization
(org:ChangeEvent
-> org:Organization
)This ontology was developed as part of the UK Linked Data Kernel project under the leadership and guidance of John Sheridan (The National Archives). Jeni Tennison provided immensely useful feedback and suggestions on the first draft, which greatly improved its design. The work also took inspiration from a number of other ontologies, particularly the thoughtfully designed Gazette Organization ontology and Proton-top.
The ontology source is made available under the Public Domain Dedication and License v1.0 whose full text can be found at: http://www.opendatacommons.org/licenses/pddl/1.0/.
This work, the documentation page, is licensed under the Creative Commons Attribution 2.0 UK: England & Wales License.
Changes since previous version 0.3 2010-06-09:
org:identifier
to support generic use of organization identifier schemes, including local and national schemes.Changes since previous version 0.2 2010-06-07:
org:changedBy
and org:resultingOrganization
as inverses to
the OMPV compatible properties and added a note on use of inverses.Changes since previous version 0.1 2010-05-28:
org:Organization
equivalent to foaf:Organization
following clarifying discussions with Dan Brickley.org:hasMember
as an inverse of org:memberOf
in order to be able to declare the equivalent to foaf:member
, thanks to Dan Brickley for the suggestion.org:unitOf/hasUnit
sub properties of org:subOrganizationOf/hasSubOrganization
, thanks to Dave Challis for prompting this clarification.
org:transitiveSubOrganizationOf
, thanks to Damian Steer for the suggestion.org:role
and org:organization
to correspond to the documentation and intent, thanks to Bernard Vatant for spotting that problem.org:memberOf
to clarify that the notion of membership is very broad and not meant to be limited to formal notions of membership.org:FormalOrganization
.
org:OrganizationalCollaboration
, thanks to Start Williams for point out the problem.org:resultingOrganization
to org:resultedFrom
for compatibility with OPMV, thanks to Jeni Tennison for pointing out the problem.rdfs:isDefinedBy
declarations, thanks to Kingsley Idehen for pointing out the lack of those.