All articles

An organization ontology: First draft

This is the third in our series of posts recording the (currently ongoing) process of developing an organization ontology. Here we sketch an initial design. Taking the initial requirements we now look at each part of the domain scope and identify the core classes, properties and design patterns.

This sketch is designed to cover all of the requirements with a minimum core set of concepts. The intention is that particular applications would extend and specialize this core. The next step is to get feedback on both the structure and the naming and associated definitions.


Let’s get this one out of the way – are we organized or organised? American English demands -ize but both are correct in British English; -ize is preferred by the OED (the “Oxford spelling”); -ise is preferred by Fowler, The Times and is 50% more common in the British National Corpus. If we want to strive for broad uptake then picking one which is acceptable for all versions of English is the obvious choice so we’ll go for -ize. After all, being on the same side as the OED can’t be all bad.

Organizational structure

At the core we need the concept of an Organization which can be recursively composed of other (sub) Organizations.

A starting minimal proposal is:

Class: org:Organization (subClassOf foaf:Agent)
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. They should be labeled using rdfs:label and described using dct:description. Alternative names: Collective Body Org Group
Class: org:FormalOrganization (subClassOf org:Organization, foaf:Organization; superClassOf gr:BusinessEntity)
An Organization which is also a Legal Entity, it is recognized as having rights and responsibilities in the world at large, in particular legal jurisdictions. Examples include a Corporation, Charity, Government or Church. Alternative names: LegalOrg LegalEntity Organization
Class: org:OrganizationalUnit (subClassOf org:Organization)
An Organization such as Government Department or University Support Unit which is part of some larger FormalOrganization and only has full recognition within the context of that FormalOrganization, it is not a Legal Entity in its own right. Units can be large and complex containing other Units and even FormalOrganizations. Alternative names: OU Unit Department
Property: org:subOrganizationOf (org:Organization -> org:Organization)
Represents hierarchical containment of Organizations or Organizational Units; indicates an organization which is a sub-part or child of this organization. Inverse of org:hasSubOrganization. Alternative names: subOrgOf
Property: org:hasSubOrganization (org:Organization -> org:Organization)
Represents hierarchical containment of Organizations or OrganizationalUnitd; indicates an Organization which contains this Organization. Alternative names: hasSubOrg
Property: org:purpose (org:Organization -> *)
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. It is recommended that the purpose be denoted by a controlled term or code list, ideally a 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).
Property: org:hasUnit (org:Organization -> org:OrganizationalUnit)
Indicates a unit which is part of this Organization, e.g. a Department within a larger Organization.
Property: org:unitOf (org:OrganizationalUnit -> org:Organization)
Indicates an Organization which is part of this Unit is a part, e.g. a Department within a larger Organization. This is the inverse of org:hasUnit.
Property: org:classificationCode (org:Organization -> ) superPropertyOf gr:hasDUNS, gr:hasGlobalLocationNumber, gr:hasISICv4, gr:hasNAICS
Indicates a classification for this Organization within some classification scheme. Recommended practice is to use SKOS to represent classification schemes. However, we also want to be able to reuse existing literal code schemes such as GLN directly. For for this reason we leave the range open.
Property: org:classification (org:Organization -> skos:Concept) subPropertyOf org:classificationCode
Indicates a classification for this Organization within some classification scheme using SKOS.
Property: org:linkedTo (org:Organization -> org:Organization)
Indicates an arbitrary relationship between two organizations. Specializations of this can be used to, for example, denote funding or supply chain relationships.


  • The distinction between a legal entity type of Organization and an internal unit is very common across the ontologies we survey and is a well-defined notion which is intrinsic to the organization and affects relevance of other properties. For all those reasons we include it in the core. However, by labelling the root class Organization we make it easy for application profiles to restrict themselves to just the root class and not make use of the Unit/Legal distinction.
  • Could add specializations of the org:hasSubOrganization/org:subOrganizationOf properties to OrganizationalUnit.
  • One lesson so far is that writing discussion sections is really useful. My first pass was to have org:Group at the top level and use org:Organization for only legal entities. After several attempts to write an explanation for that and for why Group wasn’t just a random GroupOfPeople and why applications could just use the top level class even though it had an odd name I gave in and renamed and everything.
  • The range of org:classificationCode is problematic. By leaving it open applications don’t know whether to expect a Literal or a Resource as we are placed firmly in owl:Full. We could have a property just to denote literal codes and have that as a sibling to org:classification.
  • Is it worth providing a predefined core set of org:linkedTo relationships? We start by erring on the side of simplicity but sufficiently common uses might emerge from applications to suggest moving them into the base vocabulary.

Organizational hierarchy

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


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 allValuesFrom restrictions on the new subclasses.

Organizational classification

In a number of circumstances we wish to classify organizations. For example in UK legislation there are defined notions of Partnership, Limited Company (public, private) etc. Alternatively organizations can be classified by the service they provide (e.g. Educational, Manufacturing, LegalService etc).

The core provides for labelling Organizations by their purpose (e.g. one could imagine a skos:ConceptScheme which covers Education of different forms) and by an explicit classification scheme. However, in some applications we would regard the classification as intrinsic the entity, affecting relevance of other properties (e.g. only Charities have CharityNumbers) and so better modelled as Classes. In general we would expect extensions to define subClasses of Organization to denote such distinctions.

One question is whether we should provide a basic root classification in the core. Looking at the survey then we could extract a common substructure such as (based mostly on Sumo):


The distinction is based on the purpose of the organization but the classes are not disjoint. This is not a complete or fully satisfactory classification. For example, a Public Information Service (such as some broadcasters) might be another category. The PublicServiceOrganization might be specialized to CharitableOrganization or generalized to NotForProfit.

In general we are trying to keep detailed classification schemes out of the core to enable broad reuse and maintain simplicity. So for this first pass we don’t include a upper level distinction like this but will revisit the choice in the light of feedback and application experience.

Reporting relationships and roles

Property: org:memberOf (foaf:Agent -> org:Organization)
Indicates that a person is a member of the Organization with no indication of the nature of that membership or the role played. Extensions can specialize this relationship to indicate particular roles with the organization.
Property: org:reportsTo (foaf:Person -> foaf:Person)
Indicates a reporting relationship as might be depicted on an organizational chart. The precise semantics of the reporting relationship will vary by organization but is intended to encompass both direct supervisory relationships (e.g. carrying objective and salary setting authority) and more general reporting or accountability relationships (e.g. so called dotted line reporting).
Property: org:headOf (foaf:Person -> org:Organization) subPropertyOf org:memberOf
Indicates that a person is the leader or formal head of the Organization. This will normally mean that they are the root of the org:reportsTo (acyclic) graph, though an organization may have more than one head.
Class: org:Role
Denotes a role that a Person or other Agent can take in an organization or other endeavour. Subclasses are used to denote types of role (for example Minister, Employee). Instances should be labeled using rdfs:label and described using dct:description. Superficially this is an n-ary relationship between an Agent, an Organization and other information about the role such as remuneration or duration. However, Role instances can be used directly as concepts. For examples roles can be advertised or they can be arranged on abstract org charts during organizational design. For some purposes it is convenient to indicate the existence of a role instance linking an Agent and an Organization by a simple direct property which is easy to query, the shortcut property for the rule can be indicated using the metalevel annotation org:roleProperty.
Property: org:roleOf (org:Role -> foaf:Agent)
Indicates the Person (or other Agent including Organization) which plays this role within some organization.
Property: org:hasRole (foaf:Agent -> org:Role)
Indicates a role that the person or other Agent plays. Inverse of org:roleOf.
Property: org:roleIn (org:Role -> org:Organization)
Indicates the Organization in which the role is played.
Property: org:roleDuring (org:Role -> owlTime:Interval)
Optional property to indicate the interval for which the role is/was valid.
Property: org:roleProperty (rdfs:Class -> rdf:Property)
This is a metalevel property which is used to annotate an org:Role class with a sub-property of org:memberOf. The intended semantics is that an instance of the Role implies the existence of a direct property relationship through an inference rule of the form: {?x a ?r; :roleOf ?person; :inOrganization ?org . ?r :roleProperty ?role } -> {?person ?role ?org}.
Property: org:remuneration (org:Role ->)
Indicates a salary or other reward associated with the role. Typically this will be denoted using an existing representation scheme such as gr:PriceSpecification but the range is left open to allow applications to specialize it (e.g. to remunerationInGBP).


So the difficult thing here is Role. Many of the requirements and competence questions can be handled by simple binary relationships between the person and the organization. This is easier to query than the reified n-ary relationship, and as is much preferred by some key stakeholders 🙂 so we wanted to support this mode of use.

Unfortunately not everything can be handled this way. It would be possible to carry role category information via property annotations (e.g. salary band which is uniform to the role and not instance specific) could be handled by property annotation. However, a specific salary can’t be handled that way (without using RDF reification which is even worse than n-ary relationships). Plus there is an argument that a Role is something one needs to talk directly about (e.g. the advertising or organizational design examples cited in the description). The compromise is to provide for both.

Having two ways to do one thing is rarely a good idea. We mitigate it two ways. Firstly we expect particular specializations of this vocabulary to define application profiles which will include guidance on role structure. Secondly we provide a means to link reified Roles with simple properties so that supporting tools could enable information to be authored purely using Role instances and automatically add the corresponding direct links to the closure for ease of query.

Other notes:

  • We reuse FOAF rather than defining yet another notion of Agent/Person. Note that by using Agent rather than Person we allow the possibility of Organizations playing the Agent role – this is appropriate for cases where organizations collaborate in a Project or Consortium and we want to denote the roles the organizations themselves play in that grouping.
  • Arguably reportsTo is contextual and should be an n-ary relationship between two people and an organization. We could take a similar approach to that in Roles but the arguments for a reified reporting relationship are much weaker and no ontology we surveyed did this so simplicity wins out.
  • It is not clear whether remuneration should really go in here or in specialized vocabularies. It will often not be present in public information and without enforcing a specific currency representation it is not well defined). However, it is in our presenting competency questions so we’ve put it in for now and seek feedback.
  • By using OWL Time for roleDuring we allow for open ended intervals and for interval relationships (e.g. we can say that one role followed from another without knowing the precise time at which that occurred). The cost of this is that the encoding of a simple start date is complex (Role -> Interval -> Instant -> dateTime). An alternative would be to omit the range abd let application profiles choose, or to have a simple startDate/endDate pair.


Class: org: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. In most cases a Site will be a physical location. However, we don’t exclude the possibility of non-physical sites such as a virtual office with an associated post box and phone reception service. Extensions may provide subclasses to denote particular types of site.
Property: org:siteAddress (org:Site -> vcard:VCard)
Indicates a VCard (using the vocabulary) for the site. This can include email, telephone, and geo-location details as well as an address.
Property: org:hasSite (org:Organization -> org:Site)
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: org:siteOf (org:Site -> org:Organization)
Indicates an Organization which has some presence at the given site. This is the inverse of org:hasSite.
Property: org:hasPrimarySite (org:Organization -> org:Site) subPropertyOf org:hasSite
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: org:hasRegisteredSite (org:FormalOrganization -> org:Site) subPropertyOf org:hasPrimarySite
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: org:basedAt (foaf:Person -> org:Site)
Indicates the site at which a person is based. We do not restrict the possibility that a person is based at multiple sites.
Property: org:location (foaf:Person -> xsd:string)
Gives a location description for a person within the organization, for example a Mail Stop for internal posting purposes.


  • The org:location property is not well structured. For some internal address schemes the address may be relative to the org:basedAt value which thus doesn’t work if a person can be based at multiple locations. The obvious alternative is to have an org:InternalLocation which combines site and location information. For this first pass simplicity and desire to avoid n-ary relations won out over cleanliness.
  • If it proves common for people to be based at multiple sites we might need a org:primarilyBasedAt specialization, but this could be added in extension vocabularies.

Projects and other activities

Class: org:Endeavour (subClassOf org:Organization)
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. All members are org:Organizations rather than individuals and those Organizations can play particular roles within the venture. Alternative names: Project Venture OrganizationalCollaboration Consortium

Historical information

Class: org: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 sufficient distinct from the original organizations that it has a distinct identity and distinct URI. Extension vocabularies should define sub-classes of this to denote particular categories of event. The date of the event should be indicated, when known, via dct:date, a description should be given by dct:description.
Property: org:originalOrganization (org:ChangeEvent -> org:Organization)
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: org:resultingOrganization (org:ChangeEvent -> org:Organization)
Indicates the organization that resulted from the event.


Any aspect of organizational structure is subject to change over time. For the most part this should be handled by an external mechanism. In the case of that mechanism uses 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 describ3 that change over time. The Event mechanism here (which is similar in spirit to that of ABC/Harmony and CIDOC/CRM) gives a generic hook for this.

  • Alternatively a generic ChangeEvent vocabulary could be factored out independent of its application to organizations.
  • Could also have a org:formallyKnownAs link direct to the original Organization for those cases where there is a simple 1-1 relationship across the event.
  • Events may take place over a protracted period which could be denoted by an an owlTime:Interval again. However, on balance it seems that the events we wish to recognize typically have a formally specified instant at which the new organization comes into effect that the simple date stamp approach is more appropriate.