An organization ontology: Second draft

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.


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:


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:

Membership  (see later) 

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.


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


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.


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:


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:


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


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.


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


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


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.


you might find some of my illustrations in helpful. One of the main benefits I see in an organisation ontology is not only to describe what organisations look like, but also to help describe what they do.

You might also find the OMG's Business Motivation Model useful.

When one is describing government organisations you can be on shaky ground; they are whatever they deem themselves to be at that moment ... they are very pleomorphic changing their names, ranges of activities and management structures on a very frequent basis.


Member since:
16 November 2009
Last activity:
44 weeks 1 day

Hi Peter,

Thanks for that link, interesting indeed, a nice way to build a topic hierarchy for staff as a cross product of sector and activity.

For this core ontology we are focusing at the organizational structure level, so we have a notion of purpose/remit for the organization and roles and role instances for the individual. A directory of activities for individuals wasn't one of the motivating use cases but I can certainly see the value of it. Perhaps we should consider a worksOn (domain foaf:Agent) to act as a hook for such applications - that would allow domain specific applications to separate role from (current) activity. Or perhaps that would be better in a separate extension ontology.

OMG's Business Motivation Model is also interesting, thanks for pointing it out. It is very reminiscent of the Enterprise Ontologies, some of which I referenced in the survey section. In our case we are not trying to capture the decision making process, rationale or outcomes. However, it would be pretty reasonable for a group that wanted to do that to provide a BMM-compatible ontology which extends the base organization ontology.

I agree that government organizations morph frequently but don't think that is distinctive. Having worked in a large corporation, I can assure you that continuous change of name, activity and structure is a fact of life there too! The point of this ontology is to allow organizations, including government ones, to publish their current structure. As it says in the notes, the intention is to use an orthogonal mechanism for handling change over time but org:ChangeEvent gives us a minimal way of making a history trace accessible. In the specific case of the guidelines on version management, based on named graphs, are already reasonably well worked out.

Thanks again,

Hi Dave
Thanks to your tweet, I found these article on the development of this vocab, which looks relevant to the work I've been doing on Election results.

Thanks for writing up the development so thoughtfully.

In order to help my comprehension of the vocab and also to test the tools I've been developing, I coded it up in my modeling language - the result is here:

I think the model captures the vocabulary except for property/subProperty relationships.

A few trivial typos I picked up in the process:

org:Classification is a subProperty of org:ClassificationCode which you removed

property org:role has a range of org:role rather than org:Role

I don't quite understand the rationale of where foaf:Agent and foaf:Person are used - it seemed to me that most uses of foaf:Person, except perhaps in org:headOf would be more usefully replaced by foaf:Agent. For example in the comment on OrganizationalCollaboration you say that memberOf is restricted to Organizations but memberOf has a domain of foaf:Person.

likewise I don't understand why FormalOrganisation is a subClass of foaf:Organisation but Organisation isnt?

The model with these changes made is here:

In your use of skos:Concept, Organizations are related by a property, but Roles by subClass. I don't quite see this difference: Perhaps I don't quite understand what Role is doing: As applied to the election data, representing the House of Commons as an Organization and Leader of the House as a Role, this looks like both could be classified with multiple skos:Concepts but subClassing allows on one?

On a broader note, is there some naming pattern which determines when property names are prefixed with verbs and when just a noun - as in hasUnit rather than just unit? I'm too casual about this I think (anyway isn't it said there are only two hard problems in computing - cache invalidation and naming? too true)

Meanwhile I'm redoing my Election vocab and the data to reflect these ideas. I'm hitting a problem with vocab reuse because I want to be able to resolve the vocab terms via the model for added value - not sure what the solution is here. Reuse is hard.


Member since:
16 November 2009
Last activity:
44 weeks 1 day

Hi Chris,

Thanks for the comments on typos and ranges but I can't match them up to the version attached to the second draft. When I download that then there isn't a mention of org:ClassifcationCode, org:role does have range org:Role and the only uses of foaf:Person are for org:headOf and org:basedAt (all the rest are indeed foaf:Agent). I'm wondering if there is a caching problem somewhere and you were ending with an older copy. If you try a fresh download and it still looks broken then please me know.

Your modelling picture looks about right though org:hasMembership is only an inverse to org:organization not to org:role and org:member.

Regarding the relationship to foaf:Organization I was playing it safe. FOAF describes that as corresponding to "social institutions such as companies..." and one could construe "institution" as indicating some form of formal external recognition. So I'm confident that org:FormalOrganization is a specialization of foaf:Organization but I'm not confident that all org:Organizations would be described as institutions. Principle of least commitment therefore said to leave that relationship open, at least for now.

Not sure I fully follow your point on Roles v. Organizations. You can categorize organizations using subclasses, the hook for attaching external classification schemes is an optional extra. Roles are skos:Concepts. But there's no cardinality issue there, a resource can be a member of multiple non-disjoint classes just as it can be labelled by multiple SKOS concept labels.

The naming pattern I try to use for the first-class relations is hasFoo/fooOf so that the direction is clear and you can tell from the naming if two are inverse of each other. The exception is with pure n-ary relationships, in this case org:Membership. If you were representing an n-ary relationship in logic you would using something like:

Membership(person1, org1, role1)

then to avoid having to remember the argument ordering you might have named arguments:

Membership( member: person1, organization: org1, role: role1 )

So in that case the binary properties are just the names of arguments within an n-ary relationship rather than interesting relationships in their own right - hence nouns seems appropriate. In this case the problem was also to find names for the membership component relations which weren't confusable with direct org:memberOfrelation - the "noun's for arguments, verbs for relations" pattern helped side step that. Like you say naming is hard and I don't claim to be any good at it but there is a tiny bit of rationale to the choice :)


[Update: Sorry, I see now that you meant the blog text. The org.ttl was correct but there were indeed bits of the text that were out of date. I will fix that in a future posting. Thanks for pointing it out.]

[Update #2: Regarding naming patterns I should have said that the overall pattern is supposed to be nouns for attributes and verbs for relations. So the n-ary relation naming pattern makes sense because the components are being thought of as attributes of the reified relation object. The trouble is that what makes an "attribute" from the point of view of naming choice is subjective, it is not simply an ObjectProperty/DatatypeProperty distinction.]

Re Roles, I guess I need to see some examples of the use of the Vocabulary to see what you mean by Role - is that Chairman (as a Concept) - but then RoleDuring doesn't make sense - or Chairman of Apex Corp (in which case it seems more like to classify this role with a classification relationship to Concept rather than this being a Concept. I do feel that any Vocabulary should come with examples of its use because distinctions like this are not always easy to understand from the vocab definition.

Re naming, Yes that's the naming practice which I thought that you were applying, but as you point out, it harks back to the EAR model where a distinction is made between attributes and relationships. I agree that this is a natural way to develop a model, hence my work on my EAR modeler, where typically attributes have literal values with unbounded ranges and hence no useful inverse, whereas relationships have entity or resource values,. However data models based on logic like RDF model and modeling languages like Alloy, the formal specification language from Daniel Jackson, and indeed OO languages make no such distinction. So my problem is whether the distinction should carry over to RDF modeling. Looking at dbpedia for example I see only occasional use of verbs e.g. 'hasPhotoCollection' but the majority are nouns - 'founder' not 'hasFounder'. I've followed the same practice despite my bias to using EAR as the starting point. I wonder what a review of a range of vocabs would reveal.

Member since:
16 November 2009
Last activity:
44 weeks 1 day

Hi Chris,

Regarding roles then there isn't, with the second draft design, a roleDuring it's memberDuring. The Role is something like Chairman whereas an instance of Membership would bind a person to an organization in the Role of Chairman and that binding can optionally have an associated interval.

I agree that examples would be helpful, as we start to use the ontology that should general material for a companion document on examples. Given that the period from initial request, though investigation, design, refinement and publication was about a week I don't think we've done too badly on the documentation front :)

Regarding names ... one key factor for me in use of just nouns is whether there are cases where the direction is ambiguous. That is unlikely in anything that is "attribute-like" but for something like "subOrganization" which is the smaller one, the subject or the object? To me you really have to disambiguate cases like this, that verb naming style is a good way to do that. My warning case is SKOS. That used to have something skos:broaderThan but it now has skos:broader and I have to look up the specs every time to remember which way round it goes.