Determine properties/subclasses for categories of item/resource types

[saverkamp]

PROBLEM: There is a need to define different categories of types of items related to their intellectual, functional (for lack of a better word), and physical dimensions to serve various functions of search, browse and display in Discovery. Historically these type categories have been muddled in MARC and other bibliographic schemas to support the functions of older technologies, so defining and mapping to a new model will not be trivial. Ideally our model should consider future incorporation of data beyond the catalog (i.e. Archives stack, TMS, Digital Collections).

Intellectual 1) types related to bibliographic level (issuance): monograph, serial. 2) “item type” related to how information is packaged (units of information): issue, article, dissertation, book, map, song, album, etc.

“Functional” 3) resource types related to the form the information’s content takes, like audio, image, text, etc.

Physical 4) whether or not a nypl:Item represents a physical instance (as opposed to purely intellectual--ex. 5 issue items of a journal may be represented on a single physical volume resulting in 6 nypl:Item instances) 5) physical format of the item, like book, slide, u-matic, VHS tape, microfilm, et.

FUNCTIONAL REQUIREMENTS

• Distinguish between monographic and serial resources to support display, linking relationships (1)
• Identify serial resources to support “Journal title search” (title search filtered on serial) (1)
• Identify the type of intellectual item for faceting and user comprehension (in display--see Brian’s results page wireframe, ex. “Book / Biography”) (2)
• Identify the form the information takes (resource type) to support different item display templates (3)
• Identify the physical format of the item for user understanding and to aid in fulfillment (How should this content be served? What special equipment or space is needed?) (5)
• Determine if a nypl:Item represents the physical item, the intellectual dimensions, or both to support fulfillment. If the nypl:Item only represents the intellectual, the data should indicate a relationship to physical item(s) (4)

Related to this issue is the non-1:1 intellectual:physical item problem (serials, etc.). We should consider what properties are necessary to easily ascertain if an nypl:Item represents intellectual dimensions, physical dimensions, or both.

More detail in notes at: https://docs.google.com/document/d/1HG1ZFovzvz29zwDoKKhFIvQcjweja9CN3GN2f4XkxPw/edit

[saverkamp]

Team met on 10/5 to discuss, and we decided to try the following:

1. (bibliographic level) Use bf:issuance with LC terms (mint our own until they LC does)
2. ("work" types) Create or borrow work types (similar to schema.org) and add as additional classes
3. (resource type) Retain as a property (dcterms:type) with LC terms as values unless/until the need arises to add bf subclasses instead.
4. Add bf:Item as class to nypl:Items that contain information about the copy-specific properties, like barcode and location. Split entities as necessary when intellectual:physical relationship is not 1:1. Use properties bf:itemOf and inverse bf:hasItem to express relationship (unless we find better predicates)
5. Add bf:media and bf:carrier properties to items with bf:Item class. Use corresponding LC terms. (We may decide to mint our own terms if there are values needed outside these vocabularies or to map to Getty or local termes, if we want to interoperate with future special collections systems.

We may decide to change any of these decisions based on performance or indexing requirements, but we'll start here and see how it goes.

Action items:

• update documentation
• map new properties from MARC
• generate list of work type classes and map from MARC
• add new properties to JSON-LD serialization
• enrichment and serialization rules for splitting entities