W3C Organization Ontology


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.

RDFS Class: org:Organization
subClassOf: foaf:Agent
equivalentClass: foaf:Organization
Usage note: It is recommended that SKOS lexical labels should be used to label the Organization. In particular 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: CollectiveBodyGroup.
Property: identifier

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

RDF Property: org:identifier
Domain: org:Organization
subPropertyOf: skos:notation
Usage note: Many different national and international identifier schemes are available from other vocabularies. The ORG ontology is neutral to which schemes are used. The particular identifier scheme should be indicated by the datatype of the identifier value. Using datatypes to distinguish the notation scheme used is consistent with recommended best practice for skos:notation of which this property is a specialization.
DO WE NEED TO MARKUP classification & purpose?
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.

RDF Property: org:classification
Domain: org:Organization
Range: skos:Concept
Usage note: Extension vocabularies may wish to specialize this property to have a range corresponding to a specific skos:ConceptScheme
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.

RDF Property: org:purpose
Domain: org:Organization
Usage note: 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 profiles of this vocabulary will constrain the range of org:purpose. Alternative names: remitresponsibility (esp. if applied to OrganizationalUnits such as Government Departments).
Property: hasSubOrganization

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

RDF Property: org:hasSubOrganization
Domain and Range: org:Organization
Usage note: Inverse of org:subOrganizationOf.
Property: subOrganizationOf

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

RDF Property: org:subOrganizationOf
Domain and Range: org:Organization
Usage note: Inverse of org:hasSubOrganization.

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.

RDFS Class: org:OrganizationalUnit
subClassOf: org:Organization
Usage note: Units can be large and complex containing other Units. Alternative names: Department
Property: hasUnit

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

RDF Property: org:hasUnit
Domain: org:Organization
Range: org:OrganizationalUnit
subPropertyOf: org:hasSubOrganization
Usage note: Inverse of org:unitOf.
Property: unitOf

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

RDF Property: org:unitOf
Domain: org:OrganizationalUnit
Range: org:Organization
subPropertyOf: org:subOrganizationOf
Usage note: This is the inverse of org:hasUnit.

5.2.2 Class: FormalOrganization

Dioceses & Religious Orders as 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.

RDFS Class: org:FormalOrganization
subClassOf: org:Organization
Usage note: Note that this is a super class of gr:BusinessEntity and it is recommended to use the GoodRelations vocabulary to denote Business classifications such as DUNS or NAICS.

IRS as OrganizationalCollaboration

  • has identity and purpose independent of its members
  • all members are Organizations

5.3 Membership, roles, posts and reporting — use later with Principals, Bishops etc

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.

RDFS Class: org:Site
Usage note: 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 sub-classes to denote particular types of site.
Property: siteAddress

Indicates an addess for the site in a suitable encoding. Use of a well known address encoding such as the vCard [vcard-rdf] vocabulary is encouraged but the range is left open to allow other encodings to be used. The address may include email, telephone, and geo-location information and is not restricted to a physical address.

RDF Property: org:siteAddress
Domain: org:Site
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).

RDF Property: org:hasSite
Domain: org:Organization
Range: org:Site
inverseOf: org:siteOf
Property: siteOf

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

RDF Property: org:siteOf
Domain: org:Site
Range: org:Organization
inverseOf: org:hasSite
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.

RDF Property: org:hasPrimarySite
Domain: org:Organization
Range: org:Site
subPropertyOf: org:hasSite

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.

RDFS Class: org:OrganizationalCollaboration
subClassOf: org:Organization
Usage note: All members are org:Organizations rather than individuals and those Organizations can play particular roles within the venture. Alternative names: ProjectVentureEndeavourConsortium

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.

RDFS Class: org:ChangeEvent
subClassOf: prov:Activity
Usage note: Extension vocabularies should define sub-classes of this to denote particular categories of event. The time period over which the event occurred should be expressed using prov:startedAtTime and prov:endedAtTime. A textual description of the event may be given by dct:description.
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.

RDF Property: org:originalOrganization
Domain: org:ChangeEvent
Range: org:Organization
inverseOf: org:changedBy
subpropertyOf: prov:used
Property: changedBy

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

RDF Property: org:changedBy
Domain: org:Organization
Range: org:ChangeEvent
inverseOf: org:originalOrganization
Usage note: Depending on the event the organization may or may not have continued to exist after the event.
Property: resultedFrom

Indicates an event which resulted in (led to, generated) this organization.

RDF Property: org:resultedFrom
Domain: org:Organization
Range: org:ChangeEvent
subpropertyOf: prov:wasGeneratedBy
inverseOf: org:resultingOrganization
Property: resultingOrganization

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

RDF Property: org:resultingOrganization
Domain: org:ChangeEvent
Range: org:Organization
inverseOf: org:resultedFrom

Property chain axiom

In addition the ontology defines the following relationship between org:resultedFromorg:originalOrganization and prov:wasDerivedFrom :

   SubObjectPropertyOf( ObjectPropertyChain( org:resultedFrom org:originalOrganization ) prov:wasDerivedFrom )


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.

The namespace for all terms in this ontology is: http://www.w3.org/ns/org#

The vocabulary defined in this document is also available in Turtle.

1. Overview

This ontology is designed to enable publication of information on organizations and organizational structures. 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:

This coverage corresponds to the type of information typically found in organizational charts. Developers are encouraged to create extension vocabularies to represent the nuances of organizational control structures and flows of accountability and empowerment, building upon this generic foundation.

The ontology does not provide category structures for organization type, organization purpose or roles. 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.


1.1 Example

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

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

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

2. Description

2.1 Organizational structure

The core class in the ontology is org:Organization which represents a collection of people organized together into a community or other social, commercial or political structure.

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:


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 or 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 introduce sub-classes of org:Organization when the classification is a reflection of the intrinsic nature of the organization and affects other properties.

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

  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]:

    ?agent   org:memberOf  ?org.
  [] 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.
  eg:ctoOf <http://example.com/org#id>. 

The semantics of org:roleProperty can be expressed using a second closure rule:

    ?agent   ?roleprop  ?org.
  [] 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.


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:

  ?agent  org:memberOf ?org.
  ?agent org:holds  ?post.
  ?post  org:postIn ?org.
  [] a org:Membership;
    org:member       ?agent;
    org:organization ?org;
    org:role         ?role.
  ?agent org:holds  ?post.
  ?post  org:postIn ?org.
  ?post  org:role   ?role.

2.3 Location information

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

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

  ?orgR prov:wasDerivedFrom ?orgO .
   ?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> .

2.5 Notes on modelling style

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

See Organization – Roman Catholic Church in Canada.



, , ,



%d bloggers like this: