ShareDoc:Glossary

THIS PAGE IS A WORK IN PROGRESS

This page includes the specific terminology used for some technological components and other key terms in use in the Share Family documentation. Below follows a list of terms that help the reader understand the concepts underlying those terms. Only the components original to the Share Family technical tools and activities are listed below; other technical terms used throughout the Share Family documentation refer to standard technical terminology.

For specific details about these terms and concepts, see the public documentation and the LOD Platform technology extensive description.

APIs: Application Programming Interface (API) is a way for two or more computer programs or components to communicate with each other. It is a type of software interface, offering a service to other pieces of software. In contrast to a user interface, which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a person (the end user) other than a computer programmer who is incorporating it into the software. LOD Platform APIs serve as the backbone of our platform, facilitating seamless integration, data retrieval, and interaction with Share Family services and resources.

LOD Platform: the innovative framework managing diverse catalogues, converting them into linked data. It automates the creation and publication of linked open data across different LAM domains and source formats.

Tenant: separate instance of the LOD Platform in which a library’s/a network of libraries’ data is stored in the same infrastructure. Each branch operates independently within its designated tenant, with its own Cluster Knowledge Base and dedicated web entity discovery portal. Tenants serve to compartmentalize and manage distinct branches under the overarching LOD Platform technology.

Discovery Portal: every Share Family website is referred to as a “discovery portal” or “portal”. It’s an advanced entity discovery system built on the BIBFRAME framework. It features a customized user interface (UI), integrates with local APIs, and it is the entity discovery tool of a tenant. The discovery portal can be configured at several layers: for individual institutions, for a single consortium / group of institution, for a network of consortia.

Portal group: every portal is a part of one “Portal group”. Portals are grouped around a shared database. For example: https://svde.org is a portal group collecting the data of several institutions members of Share-VDE initiative. While the portal group shows the data of all the institutions feeding the database, the institutional portal gives the ability to filter only the data of the institution that it has been designed for (see below). The portal URL can be configured and it will also be the base URI, ie. the prefix of URIs created by the system to uniquely identify its entities. For example: the Share-VDE portal base URI is https://svde.org.

Primary and secondary/institutional/skin portal: each portal group has one “primary” portal, which is the main entity discovery portal of a tenant. This is the non-branded version of the portal that represents the project as a whole, and not a particular institution or variation of the website. All other portals in a group are “secondary” or institutional portals (also informally called “skin portals” in Share Family jargon). The primary portal has certain minor differences compared to secondary portals. “Secondary” is the term used to configure features in the back-office, and in this context is synonym of “institutional”. For example: the primary portal of Share-VDE portal group is https://svde.org; institutional secondary portals are available for member institutions.

Local system: the local library environment at the library, referring generically to any of its components (eg. ILS/LSP, local OPAC etc.).

Cluster / Entity: consolidated grouping of metadata representing various kinds of linked data descriptions about agents/contributors, intellectual works, and specific publications, created through a process that reconciles variations and assigns unique identifiers. This helps in managing and presenting data from different sources in a coherent and organized manner. Each cluster is identified by a URI.

Cluster Knowledge Base – CKB (also named Entity Knowledge Base): a collaborative source of high quality data, the CKB includes the clusters of entities created in the reconciliation and conversion of bibliographic and authority data to linked data. It’s the LOD Platform database of linked data entities.

Entity registry: tool in which the association between clusters and the URIs that identify such clusters is registered, and where all the changes affecting this association are reported.

JCricket: is the tool for collaborative linked data entity management. It enables - according to the BIBFRAME ontology - the entity curation (e.g. creation of new entities, entity modification, the application of entity merge and split functions). The scope is to improve the quality of the Entity Knowledge Base that is a live source produced through clustering and daily update processes. JCricket is a manual application that makes it possible to manage bibliography data in the form of entities. It empowers professional librarians to enhance the quality of machine-generated data output of MARC to BIBFRAME transformation.

Clusterization tool: the tool includes the clustering logics of the data coming from different sources often non-homogeneous in order to create the entity as Real-World-Object (RWO) and assign a unique identifier. By clustering we mean the mechanism of identification of the entities with Large Scale Fuzzy Name Matching Techniques, through different text analysis methods.

Authify: a RESTFul module that provides search and full-text services of external datasets (downloaded, stored and indexed in the system), mainly related to Authority files (VIAF, Library of Congress Name Authority files etc.) that can also be extended to other types of datasets. It consists of two main parts: a SOLR infrastructure for indexing the datasets and related search services, and a logical level that orchestrates these services to find a match within the clusters of the entities.

RDFizer: a RESTFul module that automates the entire process of converting and publishing data in RDF according to the BIBFRAME 2.0 ontology in a linear and scalable way. It is flexible and can be adapted to multiple situations: it allows, therefore, to manage the classes and properties not only of BIBFRAME but also of other ontologies as needed.

URI: a URI is a unique identifier for an entity (author, resource etc.):

·       Local URI: assigned exclusively to entities within a specific tenant (ie. SVDE URIs for entities within the SVDE tenant);

·      External URI: URI from external authoritative sources added in the data processing phase (eg. VIAF, ISNI, etc.);

SVDE Ontology: an extension to BIBFRAME modelled within the Share Family initiative. While the ontology supports the discovery functionality of the Share Family search systems, it may be re-used in any system requiring a bridge among BIBFRAME, IFLA LRM and RDA. The preliminary version of the SVDE Ontology has been published and can be consulted at https://doi.org/10.5281/zenodo.8332350.