Patron Type

Names

Name

Guidance / Context

Reference

Name

Guidance / Context

Reference

Common Name

Patron Type

Alternative Names

  • PTYPE

  • Patron Group (FOLIO)

DCB Technical Name

 

Provision

Information

Note

 

Information

Note

 

Scope

 

Owner

 

Purpose

 

DCB Implementation

DCB Service and Client Adaptors

How is this mapping used by DCB, and what to expect when it’s not right

  • Workflows: what use cases or workflows use the mapping and to what end

  • Technical: principal classes (or other technical elements) that apply in this case

  • Missing: what to expect when the mapping is missing

  • Incorrect: what to expect when the mapping is present but wrong

FOLIO uses the DCB Reciprocal mappings facility to work out what the canonical patron type is for a patron record.

  • This lowers the burden for configuring FOLIO but can be counterintuitive at first.

  • The following row (fromContext, fromCategory, fromValue, toContext, toCategory, toValue) is used both to determine that the FOLIO patron type undergrad is mapped to canonical 240 but ALSO that canonical 240 is mapped to cs00000int_0004:undergrad.

fromContext

fromCategory

fromValue

toContext

toCategory

toValue

fromContext

fromCategory

fromValue

toContext

toCategory

toValue

cs00000int_0004

patronType

undergrad

DCB

patronType

240

 

Workflow / Use Case

Technical Reference

Missing

Incorrect

Workflow / Use Case

Technical Reference

Missing

Incorrect

 

 

 

 

 

 

 

 

DCB Admin

  • Integration status: Not Integrated Viewable importable Editable

  • Tracking issue link: <LINK>

  • Admin page link: <LINK>

Mapping Model

  • Type: Reference Numeric Range

  • Target Mapping Scope: System Spine DCB

  • Link to import template: <LINK>

Mapping Structure

  • Fields: list expected source and destination fields, including additional fields.

  • Description: what the field represents, and where values may be sourced

  • Validation: describe expected data formats any validation expected applied

  • Example: provide good and bad examples in expected format and case

Field

Description

Validation

Example

Field

Description

Validation

Example

fromContext

 

 

Valid:

Invalid:

fromCategory

 

 

Valid:

Invalid:

fromValue

The value encoded as a STRING

 

Valid:

Invalid:

toContext

 

 

Valid:

Invalid:

toCategory

The category, for PatronType mappings must be “PatronType”

Must match DCB Canonical

Valid: STAFF, PATRON, YOUNGADULT

Invalid: UNDERGRAD, 240

toValue

 

 

Valid:

Invalid:

reciprocal

 

 

Valid:

Invalid:

DCB Canonicals

  • Authorative Codebase Referent:

  • ANSI/NISOZ39.83-2-2012 v2.0.2 (NCIP) defines the two categories of user

    • Academic

      • Faculty

      • Graduate

      • Postdoc

      • Staff

      • Undergraduate

    • Public

      • Adult

      • Child

      • Senior

      • Staff

      • Young Adult

    • Staff is in common, leaving us with 4 levels of delineation

      • The challenge with Adult, Child and Senior is that these categories are derived from a property of the patron and are likely not good classifiers in their own right. They do exist nonetheless and form a reasonable “Spine” of values. Institutions will likely map them all onto “Adult”

Value

Interpretation

Value

Interpretation

STAFF

A member of an institution

FACULTY

 

GRADUATE

 

POSTDOC

 

UNDERGRADUATE

 

ADULT

 

CHILD

 

SENIOR

 

YOUNG_ADULT

 

PATRON

Any “standard” user if the identity providing org prefers a non-discriminating type

NOT_ELIGIBLE

 

Operated as a Community Resource by the Open Library Foundation