The Local KB consists of:

Works
Identifiers
Title Instances (TIs)
Platforms
Platform Title Instances (PTIs)
Packages
Package Content Items (PCIs)
Coverage statements

A domain model of the Agreements application including the Local KB is available on Github.

Works

A work in the Local KB is intended to represent a Bibframe work, but in terms of data structure, it is a way of linking together multiple title instances. So where a single published work (such as a journal) has multiple instances (typically print and electronic versions), the work links together the titles instances that represent each of those different versions of the work. The Work record is used to organise the data in the local KB but is not typically exposed to the end user.

Identifiers

Identifiers can be linked to different resources in the knowledge base, but most often are used in relation to Title Instances and Packages. Each identifier belongs to a 'namespace' which indicates the type of identifier (e.g. ISSN, ISBN, etc.) and identifiers are unique within the namespace (i.e. you can't have two separate identifiers in the ISSN namespace with the same value.)

Title Instances (TIs)

Title Instances are intended to represent a Bibframe Instance. Within the agreements local KB they are the entity that stores the basic descriptive metadata (such as title and identifiers) for a bibliographic item. Each title instance has a type which can be monograph or serial (in line with KBART guidelines) and a subtype that can be print or electronic. The subtype is very important aspect of the title and in particular:

Identifiers such as ISSNs and ISBNs are linked to the title instance, and so identify the appropriate subtype. This means there is no concept of an 'eISSN' (or pISSN, eISBN, pISBN etc.) in the knowledge base but instead you have the ISSN which identifies the electronic title instance (which you can think of as an eISSN) and the ISSN that identifies the print title instance (of the same work)
The title instances with electronic subtype are the only ones that are directly interacted with by users of Agreements (because Agreements is intended for electronic resource management), and other entities such as PTIs and PCIs relate only to electronic title instances (as these are the only ones that can have an online presence)
When data is loaded into the local KB, whatever title data is loaded an electronic title instance is always created, but a print title instance will only be created where necessary to store data unique to the print instance (specifically the identifiers which identify the print instance of the work)

When users view bibliographic descriptive information such as a resource title in the Agreements local KB, this will come from a title instance (in some cases information from multiple title instances that are part of the same Work will be displayed - specifically identifiers)

Platforms

Platforms represent an online location that can be used to access electronic resources. Typically these correspond to electronic resource platforms used by a publisher or content provider to provide access to their content (e.g. ScienceDirect, Springer Link, etc.) However because platforms are not always directly identified when data is loaded into the local KB (in particular the KBART guidelines do not offer the option to specify a platform for content) the domain from the resource URL is sometimes used to derive the platform record for a resource - which can lead to platforms such as 'doi.org' being created because KBART files can sometimes use the DOI URL as the online location (title_url) of a resource.

Platform Title Instances (PTIs)

PTIs represent a title instance available in a particular location online and link together a title instance and a platform. The PTI is also where the specific URL for a resource on a platform is stored. So if the journal Nature is available on the Springer Link platform, there will be a PTI record reflecting this and it will contain the specific URL for Nature on the Springer Link platform. This is the URL displayed to the user of the local knowledge base to provide a link to the title online.

Packages

Packages represent groups of resources which are typically made available as a group. For example JSTOR Arts and Sciences I is a package containing a set of resources, and would be represented as a package in the local knowledge base. The details of what resources are in a particular Packages are recorded via Package Content Items (PCIs)

Package Content Items (PCIs)

Package Content Items represent the availability of a resource, on a particular platform, in a particular package. They link together a PTI, Package and for serials, one or more coverage statements. Ultimately it is the PCI that shows what content is available via a particular package, and (by linking to the PTI) where that content is available online. PCIs have "access start" and "access end" dates that indicate when a particular resource joined (access start) or left (access end) a package. This means that it is possible for the changing content of a package over time to be recorded and shown in the local knowledge base.

Coverage statements

Coverage statements can record start and end dates or volume/issue numbers of serials to be able to record exactly what content is available through a particular package. This is important because the nature of serial publications and the way they are offered through online platforms means that it is possible to have different content (e.g. different issues) from the same serial in different packages.

Browser not supported