1. Use cases & requirements

The Organization class should have properties for:

  1. name

    Acme Corporation

  2. alternate names

    The Department of Natural Resources operates under the FIP title Natural Resources Canada (NRCan).

  3. former names

    In 2003, Philip Morris Companies Inc. changed its name to Altria Group, Inc.

  4. identifiers

    Chrinon Ltd has company number 07444723.

  5. classification

    The Standing Committee on Finance is a committee.

  6. parent organization

    The Standing Committee on Finance is part of the House of Commons.

  7. the geographic area to which the organization is related

    Parliament of the United Kingdom

  8. date of founding

    To provide historical detail.

  9. date of dissolution

    To determine whether an organization exists, e.g. in order to disable related functionality.

  10. image

    To identify the organization visually.

  11. the means of contacting the organization

    1 Main Street
    Anytown, USA
    555-555-0100
    info@example.com

  12. external links

    http://house.gov/

2. Standard reuse

Briefly, the survey of existing specifications concludes that:

  • No vocabulary has a property for former names.
  • schema:foundingDate and OrganizationEstablishmentDate are the only properties for founding dates.
  • vcard:deathDate and OrganizationTerminationDate are the only properties for dissolution dates.
  • The Organization ontology is the only vocabulary to meet all other requirements.

This data specification is a profile of the W3C organization ontology.

2.1. Cardinality restrictions

Unlike the Organization ontology, an organization may have only one classification in this data specification; implementations must choose a unique classification scheme.

3. Classes and properties

Term Mapping Definition
Organization org:Organization1 A group with a common purpose or reason for existence that goes beyond the set of people belonging to it, e.g. a social, commercial or political structure
name skos:prefLabel A primary name, e.g. a legally recognized name
alternate name skos:altLabel An alternate name, e.g. a trading or colloquial name
former name opengov:otherName A former name, e.g. a pre-merger name
identifier org:identifier An issued identifier, e.g. a DUNS number, GLN, etc.
classification org:classification An organizational category, e.g. charity, committee, etc.
parent organization org:subOrganizationOf2 The organization that contains this organization
geographic area opengov:area The geographic area to which the organization is related
date of founding schema:foundingDate A date of founding
date of dissolution opengov:dissolutionDate3 A date of dissolution, termination, expiry, etc.
image schema:image A URL of an image
contact detail opengov:contactDetail A means of contacting the organization
external links rdfs:seeAlso A URL to a document about the organization

1. According to a developer blog, the United Kingdom chose the spelling "organization", despite the common usage of the "s" spelling in British English, because it is the spelling that is acceptable to all versions of English. American English uses a "z", whereas both "z" and "s" spellings are correct in British English. The "z" spelling is preferred by the OED.

2. The Organization ontology defines the inverse property org:hasSubOrganization.

3. vcard:deathDate could have been used for date of dissolution, but deathDate is an unusual term for an organization.

3.1. Classification

The Organization ontology has a section on organizational classification. It proposes two strategies for classification: either create subclasses of Organization, or use the classification property. It provides guidance on when to use one or the other strategy:

If the classification is not intrinsic to the organization but simply some way to group organizations, for example as part of a directory, then org:classification should be used. If the classification is a reflection of the intrinsic nature of the organization and affects other properties then the sub-class approach should be used. For example, only charities have charity numbers so it would be better to represent a charity as a sub-class of org:FormalOrganization rather than via a taxonomic labelling.

In general, subclasses should only be used if the benefits outweigh the complexity. It is of no use to create the classes Partnership, LimitedCompany, UnlimitedCompany, etc. if all these classes behave the same way in your use case. It is simpler to use the classification property in that case.

4. Serialization

JSON differences from other RDF serializations:

  • The term name is used instead of prefLabel, to be consistent with the Person class.
  • The former name and alternate name properties are serialized as a single other_names property, whose value is an array of name objects.
  • The term identifiers is used instead of identifier and is serialized as an array of identifier objects.
  • The value of the classification property is a string, instead of a skos:Concept.
  • The term parent_id4 is used instead of subOrganizationOf, due to its popularity among ORMs.
  • A new dissolution_date term is used for the date of dissolution, for which there is no RDF term.
  • The term links is used instead of seeAlso and is serialized as an array of link objects.

4. With respect to reuse, mongoid-tree, awesome_nested_set and acts_as_tree use parent_id.

5. Code lists

None.