Organization Service Description and Assumptions

Description

Unknown macro: {multi-excerpt}

Describes an entity for an organization or any contextually-meaningful organizational unit. Organizations may be structured so that there are organizational units (also departments, subdivisions) within an Organization. For example, there may be a Conservation Department within a museum; or museums and organized research units (ORUs) within a university. An organization may be modeled in multiple hierarchies, e.g., structural vs. financial within a larger institution, and also in various membership relations (e.g., an organization of regional museums).

The Organization (or Institution) entity is similar to Person, and often is the object of the same relations as Person. However, Organizations are also hierarchical in nature, and so grouping relations exist for Organizations that do not for people. In addition, Contact and Annotation info may differ between Organizations and Persons. Finally, Persons can be associated to Organizations, with named functions or titles.

Assumptions

Unknown macro: {multi-excerpt}

Organizations group hierarchically, e.g., departments into divisions, divisions into museums, museums into an umbrella institution.
Organizations may participate in more than one hierarchy. E.g., a given museum may be structurally defined as part of a university department, but be financially part of a collection of research units. It may also be part of a consortium of affiliated museums. We want to represent multi-hierarchy, and may need to name the different hierarchies.

** The KSS model also models multiple organization hierarchies with types. E.g., a department may have one parent from an organizational perspective, and another parent from a financial perspective. We need to determine from our community whether this is overly-complex, or useful. Note: We could wrap the KSS model inside a simplified model that just uses a single default hierarchy (and type).

Persons often hold specific titles or functions for an organization. We need to model this.
Organizations have contact info much like Persons. Subsumed organizations may at least partially inherit contact information (e.g., a department has the same street address, phone numbers, etc., but has a mail-stop or something that should be appended somewhere).
In a collections context, parties to insurance contracts, transfers of collections objects, etc., tend to be Organizations rather than people.

Key Concepts

An Organization is just a named entity, to which we can associate other entities like Person and Contact information.
An Organization can be a referent in something like Insurance information.
Unlike Persons, an Organization will not have a Principle associated to it. Organizations do not authenticate. We may in future consider credential exchanges for authentication and authorization, but that is a separate issue and will be modeled as such.
An Affiliation describes the association of a Person to an Organization. This has an optional title and text description, and is modeled with temporal extent.
KSS make a distinction between relatively abstract organizations and Authorization Groups (requires KSS auth), which group principles (authorized entities) for access control. Auth.Groups have a single hierarchy, and a single type of association (membership).
Organizations have multiple names and orthographies. KSS defines a long and a short name, but does not provide for multiple names (e.g., internal abbreviations vs. external short names), translations across languages, etc.
KSS models the concept of org-codes, but it is not clear how these would be used in our context.

Scope issues

KSS defines much more here than we need, and we must narrow the scope to reflect our needs. Current proposed scope would initially define non-hierarchic Org entities, Org-Contact info, Affiliations (associating Persons to Orgs with some title). Later we can add structure, etc., as needed.

Dependencies

Organizations may reference Organizations to define hierarchy (self-dependency).
Contact Info can be associated to Organizations.
Affiliations associate Persons to Organizations.
Activities like Loans and Insurance information may reference Organizations. The dependency is largely just one of valid reference.

Background Documentation

There are no direct notes from the meetings on this. Orgs are mentioned only as referents in things like insurance.
Organizations are however mentioned in the context of Name Authorities. Unfortunately, the precedents such as CDWA conflate actors and depicted persons and organizations, provide no structural support for hierarchy (only via textual notes), and suffer from other modeling deficiencies. We can map to these if need be, but import of CDWA would lack sufficient information to reasonably build a meaningful structure.
No known references that are not to Name Authorities, which are different for us.
KSS Organization Service

Key Team Members

(Name(s) of members) is/are the primary tech team member(s) for this service
Need to identify the community members acting as Domain Experts.