Person Service Description and Assumptions

Description

Unknown macro: {multi-excerpt} Captures information about a known person referenced in the system. This models actors in the management of collections (including collections managers, donors, conservators, etc.), as well as persons (real or imaginary) that are depicted or referenced in artwork, reference materials, annotations, etc.

We also (can) associate a type of role or context with each Person, to indicate where in the system we can consider references to a given person. This is mostly for UI conveniences (like drop-down and auto-complete lists) where we need to filter the list of all Persons to some reasonable subset that should be considered.

The Person service behaves like a vocabulary in supporting search support for auto-complete, etc.

KSS models the notions of personType and personUsageType, which seem to align to the idea of contexts, but may also conflate with roles - this is not clear. In addition, there is talk on their site about aligning to KIM, although that does not seem to model the same information about Persons, relations, etc.

Assumptions

Some of the following may best fit under 'Key Concepts' or another section:

Unknown macro: {multi-excerpt}

A Person models both actors in the system, as well as depicted or referenced persons, since a real-world person can be either, or both, and this may change over time. We assume this distinction can be modeled in other ways.
We must model relations between/among persons, organizations, and contact information, and these relations will change over time. As one example, associations of persons to Organizations are time-based.
Person data may need to be pulled from or synced to an external information store, such as an LDAP authority.

Scope issue

Initial versions will likely not support external sync of such information, but we will explore requirements in this area in later versions.

The KSS folks define an elaborate schema with lots of PII that only partially overlaps with our needs. Compare their PersonInfo schema with the various schemas referenced in our functional requirements for NameAuthorities.

Key Concepts

There is a distinction between Person and Principal. A Principal is an abstract entity which represents an internal user of the system, and does not always correspond one-to-one with a particular Person. This is discussed further in the description of the Authentication Service.
Person is not the same as Account, even though a Person may represent someone who is a user or agent in the system. We maintain account information separately.
It is important to separate the information that models a Person from the following related but distinct concepts:
- Contact information, including address as well as email, telephone, etc. These are modeled in the Contact Service.
- Affiliation, especially as an association to an Organization. This is temporal and contextual, and so is modeled as such; see the Organization Service for details.
- Roles (individual) and Group memberships (for policy definition). These are described in the Authorization Service.
The Person service will behave as a vocabulary, in supporting core APIs for filtering, etc., and in the model of references from other entities (e.g., referencing a Person as a value for a field like "Donor" in a service like Acquisition).
The Person service can support multiple namespaces, to separate imported Person-authorities (like Getty's ULAN) from one another and from a local list.
The Person service supports the notion of a role or context that can be associated to Person instances. A Person may have multiple role/contexts. These may be modeled with the role service for Authorization, or we may model this separately.
We associate a number of additional annotation types to Persons, including Life Events and Bibliographic Citations.
Information related solely to the authentication of a user in the system will be maintained in the Account Service, and not here.

Dependencies

The Contact Service depends on this service to the extent that Contact information is defined for a Person or Organization. There is no real dependency, except to define/validate legal Person entity references.

The Organization Service depends on this service to the extent that affiliations are defined for a Person to an Organization. There is no real dependency, except to define/validate legal Person entity references.

The Authentication Service may depend on this service associate Persons to Principles, and provide basic name display of Principles in reports, etc. The Authorization Service has similar dependencies, as does the Account Service.

The UI and application layers may depend upon this service to get information about preferred language, etc. for a Person.

Background Documentation

With "referenced persons," it is often necessary to have an authoritative way of uniquely and uniformly referring to such persons. See Personal and Corporate Name Authority - Functional Requirements for a discussion of requirements around this.
We have little in the way of notes from Community Design workshops.

Key Team Members

Patrick Schmitz
Need to identify the community members acting as Domain Experts.