In some cases, it is relevant to represent the organizational structure independently of the people within that structure; for example, it is relevant to represent the position of the Member of Parliament for Avalon even when no one holds that position. A post is such a position that exists independently of the person holding it.
A post should not be confused with a role, which describes a function that a person can fulfill. For example, many people fulfill the role of “CEO” in different organizations, but only one person holds the post of “CEO at Apple Inc.” Indeed, the post of the MP for Avalon could be described as having the role of MP.
The Post class should have properties for:
Member of Parliament for Avalon
“CEO” is an abbreviation of “Chief Executive Officer”.
the function that the holder of the post fulfills
Member of Parliament
the organization in which the post is held
House of Commons
the geographic area to which the post is related
date of creation
The Canadian federal electoral district of Westmount—Ville Marie was established in 1996, thereby creating the post of Member of Parliament for Westmount—Ville Marie.
date of elimination
The Canadian federal electoral district of Annapolis was abolished in 1914, thereby eliminating the post of Member of Parliament for Annapolis.
the means of contacting the holder of the post
1 Main Street
Briefly, the survey of existing specifications concludes that:
dct:validare the only properties for creation dates and elimination dates.
The Organization ontology’s data model is unsuitable for representing:
a previously held post
Michael Ignatieff was Member of Parliament for Etobicoke—Lakeshore until 2011.
the date on which the person currently holding a post started holding it
Barack Obama assumed office January 20, 2009.
Within the Organization ontology, there is also significant overlap in responsibility between the Membership and Post classes, leading to confusion as to when one, the other, or both is required or recommended for a particular use case.
According to the Organization ontology, people hold posts directly; in order to resolve the above issues, in this data specification, people hold posts indirectly through memberships. Therefore, the properties
org:holds should not be used.
According to the Organization ontology, either a person or an organization can hold a post in an organization; in this data specification, only a person can hold a post in an organization.
||A position that exists independent of the person holding it|
||A label describing the post|
||An alternate label, such as an abbreviation|
||The function that the holder of the post fulfills|
||The organization in which the post is held|
||The geographic area to which the post is related|
|date of creation||
||A date of creation|
|date of elimination||
||A date of elimination|
||A means of contacting the holder of the post|
||A URL to a document about the post|
role property appears on both the Post and Membership classes, as there are uses cases where you will have no posts (e.g. describing club membership) and others where you will have no memberships (e.g. describing organizational structure).
2. The Organization ontology defines the inverse property
A post cannot exist outside an organization. All posts must assign a value to either
JSON differences from other RDF serializations:
labelis used instead of
prefLabel, to be consistent with the ContactDetail class.
other_labelis used instead of
altLabelto be consistent with other classes using
roleproperty is a string, instead of an
organizationis used instead of
postInto be consistent with the Membership class.
end_dateare used instead of
validUntil, to be consistent with the Membership class.
linksis used instead of
seeAlsoand is serialized as an array of link objects.