The NIVOMAX Builder accepts data in various formats, including ATA100, iSpec2200 datasets, and S1000D Data Dispatch Notes (DDNs). These raw data archives typically consist of PDF, SGML, XML, and other media file types with internal linking. XML documents may be used to create advanced tables of contents for each manual in ATA100 and iSpec2200 datasets, while the PMC and BREX are used to process S1000D data imported using Data Dispatch Notes (DDNs). The diagram below shows the data path as well as how data is organized and published for use.

Table 1 Data Structure and Libraries in the NIVOMAX Builder Explained

Label	Description
A	Input data layer. Data is input into the system via ZIP archive import or direct import from an external system. – ZIP Archive: Used by publisher users to import data into a CDR. – API Interface: Used to interact with third-party systems to import data into an EDR. – Third-party system: Accessible over the network where EDR data resides.
B	– Raw Data Repository in the form of a CDR, CMR, or EDR.
C	– Data Container (DC) created from a Raw Data Repository. This container may have the entire Raw Data Repository or a subset of the manuals. When working with an EDR, the DC contains all the data exported into the EDR. API integration can be set up to import data into a CDR in more complex setups, where a more fine-grained integration between the NIVOMAX Builder and the content authoring system is possible and configured.
D	– NIVOMAX Libraries that are distributed to end users.

Central Data Repositories and Data Containers

1. Central Data Repositories (CDRs)

Raw data archives are imported into the Builder as Central Data Repositories (CDRs). Each repository adheres to a pre-defined standard, such as ATA100 or S1000D. Once established, CDRs receive a descriptive name and acronym, allowing publisher users to manage updates effectively. These updates can include adding new manuals, removing existing ones, and revising content within the manuals.

2. Data Containers (DCs)

Created from CDRs, Data Containers can encompass the entire CDR or selected parts of it. For example, a publisher might create a CDR for all flight and maintenance manuals of an aircraft model and then decide to split these into separate DCs for flight manuals and maintenance manuals. Within the DC creation process, publishers have the tools to organize manuals into sections, assign custom names, and determine their display order for end users.

Common Manuals Repository (CMR)

The CMR is maintained alongside the CDRs to centrally manage manuals common across multiple CDRs. This centralized management enables publishers to update manuals in one location, simultaneously or incrementally affecting multiple CDRs. The CMR includes tools for managing manual revisions and ensuring consistency across different CDRs.

Features of CMR Include

• Common Manual Title or Name: The official name of the manual, e.g., “Aircraft Recovery Manual.”
• Common Manual Acronym: A shortened form of the name, e.g., “ARM.”
• Common Manual Instance: A unique identifier for a manual instance, linked to its title and acronym.
• Common Manual Assignments: Associations of the common manual with specific CDRs.
• Common Manual in Libraries: Descriptive notes by publishers to clarify which libraries include the manual, aiding in differentiation of instances with identical titles and acronyms.

External Data Repositories (EDRs)

External Data Repositories differ from CDRs and CMRs in that they are not imported by the user via a zip archive. Instead, they are pulled or imported into the Builder using the system, typically through API integration or a web crawler setup. The system extracts a content repository (often a static HTML data set) and uses it as a raw data repository and creates a single Data Container. These repositories are pre-configured in the system and require third-party integration. Unlike CDRs and CMRs, where users can create new repositories, users can only update existing configured raw data repositories.

Data Libraries

Data Containers are combined to create Data Libraries, which are the final outputs from the NIVOMAX Builder. These libraries are encrypted and formatted to be compatible with NIVOMAX Viewer Applications and represent the digital products sold by ePubs Suppliers to customers. The library creation process is designed to be flexible, allowing publishers to incorporate data from various CDRs into a single library, thus supporting diverse content standards within a single Digital Product or Data Library.

Naming Conventions for CDR, CM, Libraries, and Manuals

Publishers can assign a long title and a short code to Central Data Repositories (CDRs), Common Manuals (CM), Libraries, and manuals (publications).

Long Title (Name):

• A descriptive title for humans.
• Example: “Supersonic Jet 405A Maintenance Manual”

Short Code:

• A quick reference indicator used by the system.
• Example: “SSJ405A”

Guidelines:

1. The long title should be descriptive and easy to understand.
2. The short code should be concise and easy to remember.
3. Use alphanumeric characters, spaces, and dashes for both long titles and short codes.
4. The system will convert all short codes to uppercase.