This is the fourth in our series of postings on the design of an organization ontology. The focus this time is on revising the ontology in the light of feedback and reflection.

Review

Reviewing the results of our draft with respect to the various design guides then we notice that we have failed to follow Alan Rector’s advice on modularity. We actually have a very simple class structure, as required by our goals:

Organization
  FormalOrganization
  OrganizationalUnit
  Endeavour      
Role   
Site   
ChangeEvent

However, we fail the modularity guidelines on two counts.

First, the backbone classes are distinct concepts but we failed to explicitly label them as disjoint, that’s easy to fix.

Secondly, the addition of Endeavour has broken the homogeneity of the little Class tree under Organization. The first two split the concept by how the Organization is recognized but Endeavour is about the makeup of the Organization. That can be fixed by following the guidelines to make this a defined instead of a primitive class. Which in turn reinforces how bad a choice of name that was. Which leads us to the revised structure:

Organization
  FormalOrganization
  OrganizationalUnit
Role  
Membership  (see later) 
Site   
ChangeEvent

OrganizationalCollaboration  = Organization AND (memberOf allValuesFrom Organization)

Note that those particular modularity guidelines are based on experience with large ontologies and exploit the expressivity of DL reasoners. We are aiming at a very simple vocabulary which is also usable with plain RDFS tools. Nevertheless, checking the guidelines has helped us clarify our thinking even if it doesn’t affect the design from an RDFS point of view.

Arguably the distinction between the Organization and its subclasses could be better modularized by having a notion of recognition and a Context in which an organization can be recognized. Then a FormalOrganization would be a defined- instead of a primitive- class. If we wanted to talk about the recognition of organizations in different legislative regimes that would be appropriate. Since our competency questions make no mention of that we decide that this is out of scope for our goals.

Feedback

The main source of improvement is feedback from other people, especially potential users. In this case we are fortunate enough to be working with Jeni Tennison who can always be relied up to given detailed and insightful comments!

Apart from several smaller (but still useful) comments and suggestions Jeni pointed out issues around the proposed representation of Roles. On reflection the root problem is that in our requirements capture we failed to note that there is a need to talk about Roles as first class things. For example we might want to be able to ask:

• what salary band are UK Govenment Minsters paid on?

This is a question about the Role rather than the instance of the Role. In our first design this was possible by annotating the Role Class but forces us into using Classes as Individuals in a way that can be confusing and isn’t DL-friendly (unless one relies on so called punning as supported in OWL 2).

A better design is to bite the bullet and have a direct representation of the abstract Role which can have salary bands or job descriptions attached. Then we represent the n-ary relationship between an Organization, an Agent and a Role using instances of a new org:Membership class. This avoids the class-as-individuals issue, makes Roles a first class object but still lets us use the org:roleProperty trick to allow shortcut direct properties to simplify navigation over a role graphs.

This is all easy to implement (see below).

Comparing this to the ontologies in our survey we see that most fail to represent Roles at all, Proton Top uses our previous design (Role-instance-is-specific-membership) whereas the Gazette Person ontology supports a separation between abstract role (there called Position) and relationship instance (there called Role).

Incidentally the latter gives us a chance to illustrate the OntoClean guidelines and why Ontologies are different from Object Oriented data modelling. There we have a hierarchy:

Position        props: isMemberOfOrganization ...
  Employment    
  Role          props: undertakenBy ...

From an object oriented view point that’s is fine – Role is a subclass that specializes Position by adding another property (the person who undertakes the role). From an ontology view point the identity criteria are tricky, at least if I understand the meaning of those classes correctly. If the same Position could be undertaken by different people then two things could be the same when regarded as a Position but different if regarded as a Role. This is analogous to why TimeInterval isn’t a sub-class of TimeDuration.

Updated design

So the following is an updated version of the first pass design with various changes made:

• add the disjointness axioms, rename Endeavour and make it a defined class
• structure Role into Role and Membership with associated changes to properties
• improve some descriptions
• change the recommendation on lexical labeling of Organizations to suggest use of SKOS lexical terms
• removed org:classificationCode both due to the range issues noted in the original discussion and because it is largely out of scope, more appropriate to recommend direct use of GoodRelations for DUNS codes etc
• remove some of the open discussion points that have now been settled

Spelling

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. 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: 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. 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. 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 OrganizationalUnits; indicates an Organization which contains this Organization. Inverse of org:subOrganizationOf. 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. Inverse of org:unitOf.

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:classification (org:Organization -> skos:Concept) subPropertyOf org:classificationCode

Indicates a classification for this Organization within some classification scheme. Extension vocabularies may wish to specialize this property to have a range corresponding to a specific 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.

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.

Discussion

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.

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

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

It would be possible to build in a minimal base classification such as:

FormalOrganization
  CommercialOrganization
  PublicServiceOrganization
  EducationalOrganization
  GovernmentOrganization
  JudicialOrganization
  PoliticalOrganization
  ReligiousOrganization

However, it is not easy to find one that is sufficiently generic yet still offers useful clear distinctions. So our preferred approach is to keep the core minimal and expect domain-specific extensions to provide appropriate specializations of the base concept.

Note that the core also allows us to label an organization according to some external classification scheme through use of the org:classification property. This is appropriate for cases where the labeling 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.

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

Class: org:Role subClassOf skos:Concept

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

Class: org:Membership

Indicates the nature of an Agent’s membership of an organization. Represents an n-ary relation between an Agent, an Organzation and a Role. It is possible to directly indicate membership, independent of the specific Role, through use of the org:memberOf property.

Property: org:member (org:Membership -> foaf:Agent)

Indicates the Person (or other Agent including Organization) involved in the Membership relationship. Inverse of org:hasMembership

Property: org:organization (org:Membership -> org:Organization)

Indicates Organization in which the Agent is a member.

Property: org:role (org:Membership -> org:role)

Indicates the Role that the Agent plays in a Membership relationship with an Organization.

Property: org:hasMembership (foaf:Agent -> org:Membership)

Indicates a membership relationship that the Agent plays. Inverse of org:member.

Property: org:memberDuring (org:Membership -> owlTime:Interval)

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

Property: org:roleProperty (org:Role -> rdf:Property)

This is a metalevel property which is used to annotate an 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}.

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.

Property: org:remuneration (org:Membership ->)

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

Discussion

So the difficult thing here is Role/Membership. 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 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). 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 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 memberDuring 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.

Location

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 https://www.w3.org/TR/vcard-rdf/ 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). Inverse of org:siteOf.

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.

Discussion

• 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:OrganizationalCollaboration (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 Endeavour 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.

Discussion

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 data.gov.uk 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.

#TechTalk