# Technical concepts

**Extended Metadata management** **in the interface**

Based on the type of metadata, LIBSAFE has specific interface components to manage the content and even allows editing previously processed data. These data can be of two types: **Structured**, which are based on the key and value model and are cemented in the XML web interchange data type model that is defined under the same concept, or **Free**, which are texts in which no prior validation of value constraints is done. The latter can have three subtypes, JSON, XML or Free, which further specialize the information so that LIBSAFE can support data management.

In structured values there must be a clear relationship between the schema code (LXM) defined in the type and the content of the block. If this is not the case, the block will not be presented or will not be functional for further editing. For this reason, special care must be taken when defining the schema from the data that the block is known to contain. Similarly, if defined, the style sheet that applies to a block conditioned by a type must be perfectly defined if the data is to be displayed. Otherwise, the system cannot generate the resulting value if, when applying the sheet, it obtains no result or an unsuccessful one.

The correct management of the data and definition of the structures, which are the responsibility of the user(s) of the system, must be very well defined and tested. LIBSAFE has all the mechanisms to ensure that the information is correctly presented, but cannot guarantee results if the content is not well defined; this responsibility falls directly on the end user.

**eXtended Metadata visualisation on the interface**

Based on the look and feel of the application, the extended metadata section presents the related information, right after the simple metadata; with this the user visualizes the entire metadata section of the object in the same area of the catalog.

**Block classes in eXtended Metadata**

Although the extended metadata classes are defined in the DB, it is not possible to edit them or add new ones.

**Block storaging of eXtended Metadata**

The blocks are stored in files based on a series of technical specifications. A relevant concept for this process are the GUIDs (unique process keys) that guarantee that the resulting value can only be generated in this process with this environment and in no other even if the environment is managed by multiple nodes:

* The file name will have the structure: block GUID, character ( . ) and Unix timestamp in format (YYYYYYMMDDDHHIISS)
* The directory that will host all the blocks of a set will have the following name: Set GUID
* The sets of an object will be stored in a directory named LUOI of the object
* The LUOI's of objects will be stored in blocks of 1000 ingestion processes based on the **id** of the ingestion process The process blocks shall be stored in a directory named after the name defined in a LIBSAFE system variable which by default is called "MetadataBlocks"
