An organization ontology (original) (raw)

Abstract

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 organizations and roles, as well as extensions to support neighbouring information such as organizational activities.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This ontology was originally developed and published outside of

W3C

, but has been extended and further developed within the Government Linked Data Working group.

This document was published by the Government Linked Data Working Group as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-gld-wg@w3.org (subscribe , archives ). The Last Call period ends 25 November 2012. All feedback is welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

• 1. Overview of ontology
  • 1.1 Example
• 2. Description and commentary
  • 2.1 Organizational structure
  • 2.2 Membership and Reporting structure
  • 2.3 Location information
  • 2.4 Organizational history
  • 2.5 Notes on modelling style
• 3. Conformance
• 4. Namespaces
• 5. Ontology Reference
  • 5.1 Index of classes and properties
  • 5.2 Organizational structure
    * 5.2.1 Class: Organization
    * 5.2.2 Class: FormalOrganization
    * 5.2.3 Class: OrganizationalUnit
  • 5.3 Membership, roles, posts and reporting
    * 5.3.1 Property: memberOf
    * 5.3.2 Property: hasMember
    * 5.3.3 Property: headOf
    * 5.3.4 Class: Membership
    * 5.3.5 Class: Role
    * 5.3.6 Class: Post
    * 5.3.7 Property: reportsTo
  • 5.4 Location
    * 5.4.1 Class: Site
    * 5.4.2 Property: location
  • 5.5 Projects and other activities
    * 5.5.1 Class: OrganizationalCollaboration
  • 5.6 Historical information
    * 5.6.1 Class: ChangeEvent
• A. Change history
• B. Acknowledgements
• C. References
  • C.1 Normative references
  • C.2 Informative references

Introduction

This document describes a core ontology (ORG) 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 organizations and roles, as well as extensions to support neighbouring information such as organizational activities.

This document does not prescribe any particular method of deploying data expressed in ORG. ORG is applicable in many contexts including RDF accessible via SPARQL endpoints, embedded in HTML pages, or serialized as an RDF/XML or Turtle. The examples in this document use Turtle [ TURTLE ] in the interests of readability.

1. Overview of ontology

This section is non-normative.

This ontology is designed to enable publication of information on organizations and organizational structures including governmental organizations. It is intended to provide a generic, reusable core ontology that can be extended or specialized for use in particular situations.

The ontology gives terms to support the representation of:

• organizational structure
  • notion of an organization
  • decomposition into sub-organizations and units
  • purpose and classification of organizations
• reporting structure
  • membership and reporting structure within an organization
  • roles, posts, and the relationship between people and organizations
• location information
  • sites or buildings, locations within sites
• organizational history (merger, renaming)

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. Users of the ontology are encouraged to define profiles which strengthen interoperability by specifying particular controlled vocabularies to use for these concepts.

A pictorial illustration of the main classes and relationships in ORG is shown below. All terms are within the ORG namespace (http://www.w3.org/ns/org# , preferred prefix org: ) unless an explicit prefix is given. The namespaces for all referenced vocabularies are giving in the section on Namespaces .

1.1 Example

This section is non-normative.

This example illustrates a small fragment of the organizational structure of the UK Cabinet Office:

http://reference.data.gov.uk/id/department/co rdf:type org:Organization , central-government:Department; skos:prefLabel "Cabinet Office" ; org:hasUnit http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications .

http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications rdf:type org:OrganizationalUnit ; skos:prefLabel "Cabinet Office Communications" ; org:unitOf http://reference.data.gov.uk/id/department/co ; org:hasPost http://reference.data.gov.uk/id/department/co/post/246 .

http://reference.data.gov.uk/id/department/co/post/246 skos:prefLabel "Deputy Director, Deputy Prime Minister's Spokesperson/Head of Communications" . org:postIn http://reference.data.gov.uk/id/department/co/unit/cabinet-office-communications ; org:heldBy <#person161> .

2. Description and commentary

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:FormalOrganization s are free to contain other org:FormalOrganization s.

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 , namelyorg: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.

A org:Post is also defined as a sub-class of org:Organization to allow for cases where a Post is actually held by a group of people (whether as a timeshare, as a team or as a formal group such as a committee).

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 providesorg:Site to represent locations at which organizations exist. The relations org:siteOf and org:hasSite establish links between aorg: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 the vCard [ VCARD ] 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 ].

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.

3. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must , must not , required , should , should not , recommended , may , and optional in this specification are to be interpreted as described in [ RFC2119 ].

A data interchange, however that interchange occurs, is conformant with ORG if:

• it uses terms (classes and properties) from ORG in a way consistent with their semantics as declared in this specification;
• it does not use terms from other vocabularies instead of ones defined in this vocabulary that could reasonably be used (use of such terms in addition to ORG terms is permissible).

A conforming data interchange:

• may include terms from other vocabularies;
• may use only a subset of ORG terms.

An ORG profile is a specification for data interchange that adds additional constraints to ORG. Additional constraints in a profile may include (but are not limited to):

• a minimum set of required terms;
• classes and properties for additional terms not covered in ORG;
• controlled vocabularies or controlled sets of URIs to use as acceptable values for properties;
• guidance on use of pairs of inverse properties (such as selecting only one member of the pair to be included, or requiring that both members be explicitly included);
• guidance on choice of modelling approach for roles (see Membership and Reporting structure ).

5. Ontology Reference

5.2 Organizational structure

5.2.1 Class: Organization

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 and can act as an Agent. Organizations are often decomposable into hierarchical structures.

Property: subOrganizationOf

Represents hierarchical containment of Organizations or OrganizationalUnits; indicates an Organization which contains this Organization.

Property: transitiveSubOrganizationOf

Represents hierarchical containment of Organizations or OrganizationalUnits; indicates an Organization which contains this Organization, directly or indirectly.

Property: hasSubOrganization

Represents hierarchical containment of Organizations or OrganizationalUnits; indicates an organization which is a sub-part or child of this organization.

Property: purpose

Indicates the purpose of this Organization. There can be many purposes at different levels of abstraction but the nature of an organization is to have a reason for existence and this property is a means to document that reason. An Organization may have multiple purposes.

Property: classification

Indicates a classification for this Organization within some classification scheme.

Note that it also permissible for applications to define sub-classes of org:Organization as a means to represent organizational categories.

Property: identifier

Gives an identifier, such as a company registration number, that can be used to used to uniquely identify the organization.

Property: linkedTo

Indicates an arbitrary relationship between two organizations.

5.2.2 Class: FormalOrganization

An Organization which is recognized in the world at large, in particular in legal jurisdictions, with associated rights and responsibilities. Examples include a corporation, charity, government or church.

5.2.3 Class: OrganizationalUnit

An Organization such as a department or support unit which is part of some larger Organization and only has full recognition within the context of that Organization. In particular the unit would not be regarded as a legal entity in its own right.

Property: hasUnit

Indicates a unit which is part of this Organization, e.g. a Department within a larger Organization.

Property: unitOf

Indicates an Organization of which this Unit is a part, e.g. a Department within a larger Organization.

5.3 Membership, roles, posts and reporting

5.3.1 Property: memberOf

Indicates that a person is a member of the Organization with no indication of the nature of that membership or the role played. Note that the choice of property name is not meant to limit the property to only formal membership arrangements, it is also intended to cover related concepts such as affiliation or other involvement in the organization. Extensions can specialize this relationship to indicate particular roles within the organization or more nuanced relationships to the organization.

5.3.2 Property: hasMember

Indicates a person who is a member of the subject Organization. Inverse of org:memberOf , see that property for further clarification.

5.3.3 Property: headOf

Indicates that a person (or other agent) is the leader or formal head of the Organization.

5.3.4 Class: Membership

Indicates the nature of an Agent's membership of an organization.

Property: member

Indicates the Person (or other Agent including Organization) involved in the Membership relationship.

Property: organization

Indicates the organization in which the Agent is a member.

Property: role

Indicates the Role that the Agent plays in a Membership relationship with an Organization. Can also be used on a org:Post to indicate the role that any holder of the Post plays.

Property: hasMembership

Indicates a membership relationship that the Agent plays.

Property: memberDuring

Optional property to indicate the interval for which the membership is/was valid.

5.3.5 Class: Role

Denotes a role that a Person or other Agent can take in an organization. Instances of this class describe the abstract role; to denote a specific instance of a person playing that role in a specific organization use an instance of org:Membership .

Property: roleProperty

This is a metalevel property which is used to annotate a org:Role instance with a sub-property of org:memberOf that can be used to directly indicate the role for ease of query.

Property: remuneration

Indicates a salary or other reward associated with the role.

5.3.6 Class: Post

A Post represents some position within an organization that exists independently of the person or persons filling it. Posts may be used to represent situations where a person is a member of an organization ex officio (for example the Secretary of State for Scotland is part of UK Cabinet by virtue of being Secretary of State for Scotland, not as an individual person). A post can be held by multiple people and hence can be treated as a organization in its own right.

Property: holds

Indicates a Post held by some Agent.

Property: heldBy

Indicates an Agent which holds a Post.

Property: postIn

Indicates the Organization in which the Post exists.

Property: hasPost

Indicates a Post which exists within the Organization.

5.3.7 Property: reportsTo

Indicates a reporting relationship as might be depicted on an organizational chart. It can be used to indicate a reporting relationship directly between Agents or between Posts that Agents could hold.

5.4 Location

5.4.1 Class: Site

An office or other premise at which the organization is located. Many organizations are spread across multiple sites and many sites will host multiple locations.

Property: siteAddress

Indicates a VCard [ VCARD ] for the site. This can include email, telephone, and geo-location details as well as an address.

Property: hasSite

Indicates a site at which the Organization has some presence even if only indirect (e.g. virtual office or a professional service which is acting as the registered address for a company).

Property: siteOf

Indicates an Organization which has some presence at the given site.

Property: hasPrimarySite

Indicates a primary site for the Organization, this is the default means by which an Organization can be contacted and is not necessarily the formal headquarters.

Property: hasRegisteredSite

Indicates the legally registered site for the organization, in many legal jurisdictions there is a requirement that FormalOrganizations such as Companies or Charities have such a primary designed site.

Property: basedAt

Indicates the site at which a person is based. We do not restrict the possibility that a person is based at multiple sites.

5.4.2 Property: location

Gives a location description for a person within the organization, for example a Mail Stop for internal posting purposes.

5.5 Projects and other activities

5.5.1 Class: OrganizationalCollaboration

A collaboration between two or more Organizations such as a project. It meets the criteria for being an Organization in that it has an identity and defining purpose independent of its particular members but is neither a formally recognized legal entity nor a sub-unit within some larger organization. Might typically have a shorter lifetime than the Organizations within it, but not necessarily.

5.6 Historical information

5.6.1 Class: ChangeEvent

Represents an event which resulted in a major change to an organization such as a merger or complete restructuring. It is intended for situations where the resulting organization is sufficiently distinct from the original organizations that it has a distinct identity and distinct URI.

Property: originalOrganization

Indicates one or more organizations that existed before the change event. Depending on the event they may or may not have continued to exist after the event.

Property: changedBy

Indicates a change event which resulted in a change to this organization.

Property: resultingOrganization

Indicates an organization which was created or changed as a result of the event.

A. Change history

Changes since W3C Working Draft 05 April 2012 :

• Modified org:ChangeEvent , org:originalOrganization andorg:resultedFrom to extend the PROV-O vocabulary instead of OPMV.
• Added org:Post and associated properties.
• Corrected description of org:hasSubOrganization and org:subOrganizationOf .
• Corrected domain of org:remuneration to match ontology.
• Corrected domain/range of org:hasMember to match ontology.
• Added missing entry for org:memberOf to match ontology.
• Rephrasing and restructuring throughout the document to improve clarity.

Changes since previous version 0.3 2010-06-09 :

• Added org:identifier to support generic use of organization identifier schemes, including local and national schemes.

Changes since previous version 0.2 2010-06-07 :

• Added 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 :

• Rephrased the introduction to clarify scoping of the ontology.
• Made org:Organization equivalent to foaf:Organization following clarifying discussions with Dan Brickley.
• Added 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.
• Made org:unitOf /org:hasUnit sub properties of org:subOrganizationOf /org:hasSubOrganization , thanks to Dave Challis for prompting this clarification.
• Added org:transitiveSubOrganizationOf , thanks to Damian Steer for the suggestion.
• Fixed range statements for org:role and org:organization to correspond to the documentation and intent, thanks to Bernard Vatant for spotting that problem.
• Modified description of org:memberOf to clarify that the notion of membership is very broad and not meant to be limited to formal notions of membership.
• Clarified the description of org:FormalOrganization .
• Fixed bug in restriction definition for org:OrganizationalCollaboration , thanks to Start Williams for point out the problem.
• Reversed org:resultingOrganization to org:resultedFrom for compatibility with OPMV, thanks to Jeni Tennison for pointing out the problem.
• Changed labels for has* properties to read as nouns, leaving URIs unchanged.
• Added rdfs:isDefinedBy declarations, thanks to Kingsley Idehen for pointing out the lack of those.
• Clarified license terms, thanks to Dan Brickley for pointing out the lack.

B. Acknowledgements

This ontology was originally developed for use by data.gov.uk 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 designedGazette Organization ontologyand Proton-top .

The editor gratefully acknowledges comments and support from the Government Linked Data Working Group - particularly to Daniel Vila for transcribing the original documentation into W3C format and to Bart van Leeuwen for feedback and discussions that resulted in the addition of org:Post .

The modelling of org:Post is closely based on the work of Jeni Tennison on modelling UK Government.

C. References