An Intelligent Management Framework for Cooperative Digital Library Systems

1. Introduction

This paper presents an intelligent framework to facilitate the management of cooperative, intelligent Digital Library Systems (DLSs) in government organizations.

In recent years, metadata interoperability between DLSs has been characterized as not being sufficient for the type of cooperative environment where these systems need to operate to improve user experience [1,2,3]. And there have been novel solutions to try to handle this issue using application services that are shareable across organizational information systems [4,5] either in combination or coordinating their activities [6]. However, these solutions lack integral and complete management models for current government organizations where complex collaboration among related digital libraries is critical for successful digital transformations [7,8].

Additionally, current developments with DLSs seem to be focused on the integration of Artificial Intelligence (AI) technology, adding new personalized experiences to final users. Basically, these investigations transform traditional DLS services using AI recommendation techniques [9,10] as well as new generative AI models that simplify library procedures [11,12]. But there is no complete management solution either to integrate, maintain and administer all these new services within the traditional DLS software architecture. Indeed, new scalable solutions are needed to integrate, for example, generative AI with current open-source library management software [13], once the privacy and ethical concerns with AI have been resolved.

In this paper, we explore the design and use of an Intelligent Management Framework (IMF) (initially introduced in our previous work [14]) based on original cooperative models, system behaviours, traditional and AI-driven services, software architecture and ITIL-oriented processes to facilitate the management of these cooperative, intelligent DLSs. As we shall see, the framework that we propose offers significant benefits in terms of cooperation management and intelligent services integration. And to demonstrate this, we will look at two different scenarios:

• Cooperation between two DLSs where new intelligent decision-making mechanisms are required.
• Cooperation between two DLSs where new intelligent recommendation mechanisms are required.

Then we will focus on the concrete management problems for these two scenarios like the lack of architectural support for integrating new cooperative actions and new intelligent services as well as appropriate management processes based on this architecture. And we will describe how our IMF can solve these problems through:

• the top-down design of high-level cooperative models, introducing cooperative system behaviours within the software architecture of the management system,
• the scalable integration of new AI-driven (intelligent) services using architecture-oriented elements like service delivery, and service management modules and,
• the definition of flexible processes to manage these system behaviours and services within the software architecture and its functional modules.

Further, this paper will show how all these models, architectural modules and processes can be obtained through the top-down design approach characterizing our IMFs.

To evaluate our IMF solution, we will present a case study for a government organization where the management problems mentioned arise. This case study focuses on DLS cooperation and intelligent services integration needed for current digital transformation. With this case study, we intend to continue proving the feasibility of our IMF approach. Further, this paper provides the results of qualitative and statistical studies based on a large questionnaire that we have distributed in several government organizations to evaluate our IMF solution for DLSs.

The structure of the rest of the paper is as follows. Section 2.1 will summarize the current state of the art in management systems for digital collections. Section 2.2 will present some investigations related to ours. In section 2.3, we will provide two scenarios that we will use to illustrate our framework. Section 2.4 will analyze and describe the management problems and the major needs in these scenarios. Section 2.5 will illustrate the major features of our framework to solve these problems. In section 3.1 we will evaluate the framework with a concrete design to manage intelligent DLS cooperation in the digital transformation of a government organization. A qualitative and statistical analysis methodology will be used in section 3.2 to collect and discuss relevant data about this case study using a survey questionnaire. The limitations of this qualitative analysis will be described in section 3.2.3. Finally, discussions and future work will be explained in sections 4 and 5, respectively.

2. Investigations, Materials and Methods

The following sections summarize the investigations, materials and methods characterizing our research work.

2.1. Management Systems for Digital Libraries

Current management systems for Digital Libraries are called Digital Collection Management Systems (DCMS). They are software systems that help to access, preserve, organize, publish and maintain the contents (digital objects and metadata describing these objects) and services of digital collections.

2.1.1. Advantages and Services

Some of the advantages of using these software systems include (see also [15]):

• Time and labor saving (the software system makes functions of the library automatically).
• Improved staff productivity (almost all the library tasks are supported by the software system).
• Improved content accuracy (content developers can use the DCMS through collaboration).
• Increased flexibility and accessibility (these software systems can be used for different collections).
• Reduced system security problems (the software system can be integrated with LDAP technology for user authentication).
• Reduced system maintenance (the digital objects registry and the metadata registry are maintained through appropriate services).
• Improved data management (the data of the collection becomes more easily managed).

Some of the traditional services of DCMS are:

• Services for end users: search, browse, filter, navigation, gather, evaluation, etc.
• Services for administrators: cataloguing, reports, importing/exporting data, assessment, etc.
• Services for other information systems: preservation, access and sharing of information, etc.

2.1.2. Management Lifecycle

The management lifecycle with digital collections being facilitated by these software systems is commonly reduced to (see more complete explanations in, for example, [16]):

• Planning for digital collection projects.
• Content selection, creation, submission, and ingestion (including, for example, checking intellectual property or cataloguing processes).
• Access, search, navigation and retrieval of digital objects (using end user services).
• Archiving, inventory and preservation (keeping all digital objects up to date).
• Evaluation and assessment (about, for example, visibility and accessibility of the library).
• Interoperation and licensing (supporting basic institutional collaborations).

With the exponential growth of digital content, this management lifecycle becomes almost impossible for “in-depth human intervention” [17]. This management requires more investment in IT (Information Technology) to automate most of the processes and services being involved [18]. Indeed, the management software system must become the major “facilitator and enabler” of the services of the library [19].

2.1.3. Intelligent Information Systems

The management of library activities and services have also been automated through the adoption of Intelligent Information Systems like classical Expert Systems [20]. Basically, these systems provide knowledge-based services, making intelligent decisions for the retrieval and final use of the library contents. Further investigations with these services have revealed that “analyzing the user´s behaviour” is a very good way to design the intelligence of the management systems for digital libraries [21].

For the rest of the paper, we call all these software systems Digital Library Systems (DLSs), incorporating major management functions for the services and for the repositories (digital object data and metadata) of the system.

2.2. Related Works

Two main research areas in IT developments for current cooperative intelligence have been “the design of collaborative tools” and “management” [22]. And current DLSs have also evolved with this globalization in trying to facilitate:

• the interoperability between DLSs and/or other information systems,
• collaboration between end users and/or administrators of digital collections,
• the management of the repositories (object data and metadata).

For example, in healthcare ecosystems there have been numerous investigations in trying to define data exchange specifications for advanced interoperability [23]. In educational environments, there has been an especial emphasis on providing collaborative learning, allowing the students to work together, improving their communication skills and social interaction [24]. And robust metadata management solutions have been crucial for current multidisciplinary contexts in scientist ecosystems where sample data needs to be identified, characterized and linked [25].

Although all these investigations and solutions are relevant, the long-term use and success of the digital collections can only be ensured through more “adaptation, flexibility and collaboration” [26].

2.2.1. Interoperability and Management

Some DLSs interoperate with one another using low-level protocols like, for example, OAI-PMH and DIDL, or low-level technologies like OAI-PMH, using XML-based data exchange [27]. And, more recently, higher cooperative levels have been obtained through the adoption of Web 2.0, publishing content through “syndication” or “re-using data services of others” [28]. But DLS users cannot cooperate to mean global, cooperative intelligence (as we initially introduce in [29]) using these low-level protocols and mechanisms. “Greater cooperation is a major challenge” [19]. Further, current DLSs cannot offer and manage high quality, intelligent services operating just over current data collections [27,30,31]. Thus, we propose starting the design of the management model for DLSs at a higher cooperative abstraction, enabling collaborations and related intelligent services executions in the wide DLS community.

The management and support of these complex, heterogeneous environments have demonstrated the complexity of the IT involved, suggesting the need of “more efficient services” [19] and “integral management solutions” [32,33]. Further, it is necessary to continue evaluating and improving the “quality of these services” and solutions [34].

2.2.2. ITIL Processes

The ITIL (IT Infrastructure Library) framework has been explored to develop and deliver these services in IT organizations that support the digital libraries [35]. Basically, this framework provides a global process-oriented standard or, more recently, a practice-oriented standard, for robust IT service management with best performance and quality [36,37,38].

This standard has been used, for example, to conceptualize preservation services in digital libraries [17] and, more generally, to manage current digital transformations in government organizations due to the automation of most of the processes involved [39]. Indeed, the automation of ITIL processes is very advantageous for “planning, monitoring and evaluating” all the IT involved in these organizations [37]. However, these ITIL solutions for DLSs do not seem to incorporate cooperation-oriented processes since most ITIL tools support the work of individual actors rather than supporting the cooperation among “all the parties involved in the processes” [40]. Indeed, ITIL “lacks cooperative perspectives” [41].

2.2.3. AI Technology Integration

In the last few years, there have been many research efforts in trying to integrate DLSs with current AI technology [20]. And there are many problems with this integration like legal and ethical considerations, technical complexities or job replacement [42]. For example, some of the technical complexities reported are integration issues and interoperability problems with other systems that require innovative solutions [43]. But there are also clear research “foundations” in how to make automatic classification systems based on Neural Networks techniques and Learning Algorithms [44]. Further, AI technology has been integrated into DLSs to analyze vast amounts of data and to predict user´s preferences [45].

Another successful application of AI in the context of DLSs is the use of Recommender Systems [1,46]. Basically, these systems use content-based filtering based on interests of the users, and collaborative filtering based on ratings from different users [10]. And some of these systems have been implemented using Fuzzy Logic [47], Deep Learning [9] or Agent Technology [46], incorporating some personalization capabilities into the DLSs. However, it is not clear how these recommendation techniques can be used in combination with cooperative processes between DLSs, as we investigate in our paper. Although some basic aggregation mechanisms based on multiple user´s opinions, or user´s experiences, have been proposed to infer system recommendations [48,49].

There are also very recent investigations in how to integrate DLSs with Generative AI [11,12], opening new technological advances in how to automate “human-to-human” communications using conversational AI and related language models [50]. Current chatbots like ChatGPT can make personalized recommendations to DLS final users while acting as “virtualized assistants” [50,51].

However, very little has been done in trying to find integral and complete management solutions to try to handle all these new aspects for DLSs developments related to the required cooperative intelligence and AI technology integration. And it is in this dual context where our IMF approach can be especially relevant.

2.3. Cooperative Scenarios

In Figure 1 we illustrate a simple, representative cooperative environment with two scenarios facing the different management problems addressed with this paper. In these scenarios, there are two cooperative DLSs (DLS1 and DLS2) that need to exchange information using the services of one another.

We suppose that DLS1 and DLS2 have traditional services for end users, administrators and other information systems.

The two cooperative scenarios are as follows (see Figure 1):

• Scenario 1: the end user accesses DLS1 and wants to search for some information that could be available in DLS2. Then DLS1 must decide whether to cooperate with DLS2 to search for this information.
• Scenario 2: the end user accesses DLS1 to find some information, DLS1 wants to make a recommendation and needs to share information with DLS2 to do this recommendation.

Obviously, the high-level cooperation drawn with these two scenarios requires that DLS1 implements two cooperative actions using the following AI-driven mechanisms:

• Decision making mechanism based on shared information with DLS2.
• Recommendation mechanism based on shared information with DLS2.

The first mechanism can be further designed combining the following services of DLS1 and DLS2:

• Search service in DLS1.
• AI-driven decision-making in DLS1.
• Search service in DLS2.

And the second mechanism can be designed combining the following services of DLS1 and DLS2:

• AI-driven recommendation in DLS1.
• AI-driven recommendation in DLS2.

2.4. Management Problems

The previous cooperative scenarios face at least the following management problems:

• Problem 1. The low-level interoperability between DLS1 and DLS2 does not solve the high-level cooperation drawn with both scenarios.
• Problem 2. It is very difficult to integrate new cooperative actions into the traditional software architecture of DLS1 and DLS2.
• Problem 3. DLS1 requires new AI-driven services implementing decision-making and recommendation mechanisms. However, these intelligent services are outside the scope of traditional management systems for digital collections [46].
• Problem 4. Current architectural support for open-source management in DLS1 and DLS2 does not solve cooperative integration (see, for example, [33]).
• Problem 5. Current AI integration in digital libraries implies transforming traditional services of the library and there are no AI-driven services that can be used in combination with traditional services for higher cooperative scenarios like the ones we are analyzing.
• Problem 6. It is very difficult to integrate and manage these new AI-driven services within the traditional DLS1 software architecture.
• Problem 7. It is difficult for DLS1 to share these new AI-driven services with DLS2 since there is no common software architecture.
• Problem 8. With the integration and combination of new services, the management lifecycle with DLS1 must be evolved to be an integral management solution based on IT service-oriented processes like ITIL v4 processes. But the DLS1 software platform does not facilitate the definition of these processes and ITIL v4 does not support cooperative processes.

2.5. Our Intelligent Management Framework

With our IMF approach (see [14]), we integrate five major design elements for the final management solution of DLSs:

• Intelligent Models from top-level cooperation to cooperative actions that need to be integrated and managed within DLSs.
• System Behaviours that implement simple and cooperative actions based on possible service activation, combinations and/or coordination.
• Traditional Services and Intelligent (AI-driven) Services for final users, administrators and other information systems (like other DLSs).
• Software Architecture to support top-level cooperation and lower-level integration through system behaviours executions as well as services management and services delivery.
• Management Processes identifying roles, activities, responsibilities and tools around the management of all the architectural elements i.e. all the services, system behaviours and repositories.

We use a top-down approach to design all these elements, having the management processes and the required technologies as the final objectives. More generally, this paper brings six abstractions to support intelligent cooperation of DLSs from a management perspective.

With our top-down approach, we move from one abstraction to another using some refinement technique based on pre-selected aspects of design like “architecture”. The six abstractions help to model abstract levels of cooperative intelligence of DLSs focusing on organizational aspects of development like, for example, “service”. The four refinement techniques facilitate the design of lower-level, more detailed structures, methods and mechanisms like, for example, architectural modules and process activities.

The six abstractions of our IMF for DLSs are:

• First abstraction: generic cooperative model of DLSs.
• Second abstraction: DLS network and cooperative actions.
• Third abstraction: first approximation of the computational model with services and system behaviours.
• Fourth abstraction: software architecture as the last approximation of the computational model.
• Fifth abstraction: service-oriented processes, cooperation-oriented processes and common processes.
• Sixth abstraction: operative model based on final technologies.

The four refinement techniques used to move from one abstraction to another are:

• Service-oriented refinement (moving from second to third abstraction, focusing on “service”).
• Cooperation-oriented refinement (moving from second to third abstraction, focusing on “cooperation”).
• Architecture-oriented refinement (moving from third to fourth abstraction, focusing on “integration, delivery and management”).
• Process-oriented refinement (moving from fourth to fifth abstraction, focusing on “methodological” aspects of design for the previous abstractions).

The following sections describe all these abstractions and refinement techniques characterizing our top-down approach to design IMFs for cooperative, intelligent DLSs. At the end of each section, we describe how we solve scenarios 1 and 2, focusing on the management problems discussed in section 2.4. But before we move into all these explanations, we briefly describe the generic, computational and operative models used in our abstractions (see also [52]).

2.5.1. From Generic to Operative Models

We conceptualize top-level cooperative intelligence and extract our generic, computational and operative models (that we presented in [52]) while we design the management framework (IMF) supporting the appropriate functioning of all these models at appropriate levels of abstraction.

We start the design of our IMF with a top-level abstraction representing a generic model of cooperative intelligence. And the more we refine this first abstraction, the more we can achieve lower management models where to combine computational intelligence with concrete structures, mechanisms and activities. This facilitates and supports the management of intelligent, cooperative DLSs.

In general, we can design computational models of intelligence based on generic DLSs (as organizational entities) and their cooperative, manageable links. More complete computational models refine this top-level, generic model using concrete AI techniques and Software Engineering methods (as we describe in, for example, [53]). Indeed, we look at the cooperative interactions between DLSs at the top-level whereas we focus on the services, the software architecture, the AI techniques and the Software Engineering methods at the computational level of abstraction. As we shall see later, the software architecture supporting our IMF represents the latest approximation of our computational model.

Finally, we can integrate appropriate technological solutions (standards, protocols, AI technologies, etc.) into our computational models to produce our final operative models ready for production environments where to combine the operative functionality of our abstractions with the methodological basis of our processes.

2.5.2. Generic DLS Cooperation

Our first abstraction represents a generic, high-level cooperative model between DLSs. It is a qualitative network where the nodes represent DLSs, and the edges show their possible cooperative links. Basically, this abstraction helps us identify all the DLSs that need to cooperate in our working scenarios like scenario 1 and scenario 2 described in section 2.3.

In this first abstraction, the related entities (organization 1 and organization 2) encapsulate some organizational functions with cooperative values. Further, they incorporate some kind of knowledge as well as important moral/ethical behaviours and computational models to support these. We assume that these computational models will be approximated throw the next abstractions being incorporated into the DLSs.

In the second level of abstraction (see Figure 2), we map the top-level cooperation into simple and cooperative actions that need to be developed, integrated and managed in our working environment with DLSs. For example, in our scenarios 1 and 2, DLS1 requires at least the following cooperative actions with DLS2:

• Searching for shared information.
• Making shared recommendations.

But we can be flexible in the way that we design these cooperative actions for our organizations. Indeed, we can design more detailed collaborations inside and outside the organizations before starting with the following service-oriented refinement.

2.5.3. Service-Oriented Refinement

We use a service-oriented refinement technique to create traditional and intelligent (AI-driven) services in the third level of abstraction.

The traditional services include those available at traditional DLSs for final users, administrators and other information systems, as previously described in section 2.1.

Intelligent services complement and expand these traditional services, adding new computational values to facilitate and personalize user´s access to information (digital objects). They can exploit the available metadata (describing the digital objects) and the grammatical structure of digital objects to generate new digital content based on higher classification processes. Further, they can automate many administrative tasks of DLSs through efficient trained models. Indeed, these intelligent services can make decisions and recommendations based on secure data inputs and trained models, as we describe in the technology abstraction.

We divide these new intelligent services into four main groups:

• Knowledge-Based AI Services (KBAI Services).
• Behavior-Based AI Services (BBAI Services).
• Hybrid AI Services (HAI Services).
• Generative AI Services (GenAI Services).

KBAI Services are mapped to KBAI Applications to implement decision making and recommendation processes using classical Reasoning Techniques and Fuzzy Control Rules. These classical AI techniques and rules are applied to the knowledge of the system being mainly represented in the Digital Object Registry and the Metadata Registry (see Figure 3).

BBAI Services are mapped to BBAI Applications to implement decision making and recommendation processes using trained models based on Neural Networks and fast Learning Algorithms. This is described in more detail in the technology abstraction, once the AI technologies have been selected. These BBAI Applications can also be defined over the behaviours of the system, adding new interactions and low-level actions. Furthermore, the DLS can be trained to:

• learn new system behaviours based on its experience and,
• to analyze performance data and preferences from end users and DLSs acting as users.

HAI Services integrate knowledge and system behaviours interactions. These services are mapped to HAI Applications which can transform, for example, some knowledge of the system through new classification processes based on trained models.

GenAI Services are mapped to GenAI Application for DLS-chatbots integrations. These applications can use conversational agents and new language models to facilitate personalized access to final users.

The set of traditional services includes:

• Search, Browse and Navigation, which allow final users to find information and explore this within the main registries of the system.
• Help and User Support Services, which can be combined with AI-driven services like GenAI services implementing conversational chat-bots.
• Ratings. Evaluations and Corrections, which can add value to digital objects for improving digital content according to internal/external qualifications.

There are four major aspects related to the life cycle of all these services:

• Service Design.
• Service Management.
• Service Development.
• Service Operations.

All our new services (obtained once the IMF solution is operative) are obtained throw Service Design as part of the processes described later. They are managed throw Service Portfolio Management, Service Availability Management and Resource Capacity Management. Service Development makes all the services available for final users (and DLSs acting as users) throw other processes like Change Management and Deployment Management. Finally, Service Operations maintain the services to ensure that they operate correctly throw processes like Incident Management and Problem Management. But before we describe all these processes related to our services, we complete the computational model of our IMF designing the software architecture of this management solution. This architecture is described later.

With this third level abstraction (first approximation of our computational model), a DLS can act as a Service Provider of another, interconnected DLS. Thus, in our working scenarios 1 and 2, DLS1 can use DLS2´s services and, similarly, DLS2 can act as a user of DLS1. This interconnection, between DLSs acting as service providers and DLSs acting as users, is designed with more detail in the architecture-oriented abstraction (fourth abstraction).

2.5.4. Cooperation-Oriented Refinement

In the third abstraction (see Figure 3), the previous cooperative actions are mapped into cooperative system behaviours that can activate and/or use any of the traditional services and AI-driven services, either in isolation or in combination. There are also single (non-cooperative) system behaviours (or system behaviour units) that can also activate and use any of the available services. And, in the same way, the BBAI services of the previous abstraction can execute system behaviour interactions driving, for example, low-level actions like any application interaction with Metadata Registry or Digital Object Registry. Indeed, these low-level actions also support top-level cooperation since we need information exchange with our DLSs registries.

There are important management aspects with the system behaviours of our IMF. Once traditional services and intelligent services have been designed, it is necessary to design the system behaviours establishing, for example, the way they activate and use the available services. This design is clearly approached with our process-oriented refinement. Further, there are important concerns regarding how these systems behaviours, and especially cooperative system behaviours, must be implemented with available technologies running, for example, low-level interoperability. This final development is solved with our technological abstraction.

In our working scenarios 1 and 2, the required cooperative system´s behaviours for our DLS1 would be:

• Scenario 1: combine search service in DLS1 + AI-driven decision making in DLS1 + search service in DLS2.
• Scenario 2: combine AI-driven recommendation in DLS1 + AI-driven recommendation in DLS2.

All the AI-driven services required in these cooperative system behaviours can be either classical KBAI services or BBAI services. The final development depends on the AI techniques that are selected in this third abstraction.

Furthermore, the computational model of our organizations 1 and 2 require some kind of functional mechanisms to support knowledge acquisition and rendering, and cooperative system behaviour executions. These mechanisms are obtained throw the following architecture-oriented refinement.

2.5.5. Architecture-Oriented Refinement

The fourth abstraction of our top-down approach represents an architectural approach to systems design (see Figure 4). In this level, we design fundamentally service-oriented architecture incorporating all the low-level functional components that facilitate the integration, management and execution of the previous abstractions. This software architecture includes more detailed knowledge-based and system-behaviour-based structures and modules.

Basically, our software architecture abstraction controls:

• creation, organization, publication, access and assessment of knowledge,
• integration and execution of simple and cooperative system behaviours and,
• management and delivery of traditional services and AI-driven services.

Following Figure 4, the major software components designed within this architecture are:

• Web Interfaces: allow end users, DLS administrators and DLS managers to use the system.
• DLS Comm: allows other DLSs acting as users to communicate with DLS for system behaviour executions and other possible services accesses.
• DLS Authen: allows end users being authenticated within the system using, for example, LDAP technology.
• Services Registry: stores all services (traditional and AI-driven services) descriptions (templates).
• Service Controller: communicates the Web Interface and DLS Comm components with Service Management Module and Service Delivery Module.
• Service Delivery Module: delivers the selected services (traditional and AI-driven services) to final users and DLSs acting as users. It collects service descriptions (templates) from the Services Registry to execute the required applications interactions.
• Service Management Module: allows DLS administrators and DLS managers to register, publish and manage new services (traditional and AI-driven services) within the system using, for example, Web Services technologies. This module is highly used in process-orientation.
• System Behaviour Controller: controls the execution of the system behaviours (or system behaviour network) on behalf of the end users (and DLSs acting as users). This controller is fundamentally designed to control the processing of the cooperative actions integrated within the system.
• System Behaviours: cooperative system behaviours and single system behaviour that are mapped, for example, into low-level actions of the system activating, combining and/or coordinating any of the available services (traditional services and AI-driven services).
• AI-driven Services: these services are incorporated from the third abstraction and communicate the Service Delivery Module with the AI-driven Applications.
• Traditional Services: these services are also incorporated from the third abstraction and communicate the Service Delivery Module with the Traditional Applications.
• AI-driven Applications: functional components providing all the functionality to AI-driven services (see also the technology abstraction).
• Traditional Applications: functional components providing all the functionality to traditional DLS services. They access, explore and use the Metadata Registry and the Digital Object Registry. Some of these applications connect the DLS with other DLSs acting as service providers.
• Digital Object Registry: traditional collection of digital objects.
• Metadata Registry: digital objects descriptions.

Some of these components have already been presented in our software architecture design for DLSs in sustainable education [53]. The current version of these components can be described in more detail as follows.

Our current architecture incorporates a Services Registry (that can be implemented using, for example, Web Services technologies, as we describe later) to describe all the applications interactions involved in traditional services and AI-driven services. For example, this Services Registry can include XML-based service templates describing applications interactions for service delivery. And, in the case of HAI services, these service templates can describe the integration of knowledge structures (from Digital Object Registry and Metadata Registry) with application interactions.

This software architecture also defines the precise mapping of all the services to their applications. Some of these applications are local. But they can also be remote. For example, an AI-driven recommendation application can be trained as a remote model that can be accessed from a HAI service using the corresponding service template stored in the Services Registry.

The Digital Object Repository of our software architecture allows storing traditional content as well as interrelated digital content with clear cooperative objectives. The Metadata Registry can be used to describe these objects to later organize and classify them for simple and cooperative actions. The use of this Metadata Registry depends on the services and system behaviours designed in the third abstraction.

Further, our software architecture incorporates service-related components like, for example, Service Controller, Service Management Module and Service Delivery Module. The Service Controller receives all the user´s requests (from the Web Interface and DLS Comm) and calls the Service Delivery Module to deliver the services. The Service Management Module facilitates the creation, registration, administration and maintenance of the services (traditional and AI-driven services) of the system. Indeed, the DLS administrators can incorporate new service templates within the Service Registries using this Service Management Module. The Service Delivery Module finds and executes these service templates provoking the interaction of the related applications, registries and possible databases. Some of these services like, for example, traditional services access and use the Digital Object Registry and the Metadata Registry on behalf of the final user.

The Metadata Registry incorporates various kinds of information about digital objects like low-level interoperability between DLSs. This Metadata Registry has inspired the use of tags and tag clouds to enhance, for example, traditional services like browsing, searching or navigation. These tags make new associations among digital objects using, for example, user´s vocabulary.

All these functional components also facilitate the definition of the subsequent service-oriented and cooperation-oriented processes of our management solution. All these processes are described later.

Once all the architectural components have been designed, the resulting DLS software architecture supports the top cooperative model through appropriate system behaviours executions and services delivery mechanisms. Further, the related management solution facilitates how to integrate new system behaviours as well as new intelligent services within the system, as we describe later. Finally, thanks to our software architecture, the DLSs being communicated share the same functional components and modules, facilitating high-level cooperation.

With our working scenarios 1 and 2, the end user would use the Web Interface of DLS1 to execute the cooperative system behaviours (designed in the third abstraction) available though the System Behaviour Controller. Then, these cooperative system behaviours would execute the required services combinations, accessing some of the services of DLS2 (acting as a service provider) when required.

2.5.6. Process-Oriented Refinement

The fifth abstraction is based on process orientation. Here we incorporate methodological aspects of design describing how to use the architectural abstraction and how to support the top-level cooperation between DLSs. Indeed, in this abstraction, we identify the main roles, responsibilities and activities that complete our DLS management framework using and improving some ITIL v4 processes.

Basically, an ITIL process defines a structured set of activities to accomplish a specific objective. And an ITIL process model includes the required control mechanisms to obtain efficient performance as well as the process enablers (mainly, resources and capabilities). Then the process manager ensures that the process is executed correctly.

We have simplified these process definitions since our IMF processes do not incorporate technological abstractions. Indeed, our IMF processes help to convert the computational model of the DLS cooperation into the operative model based on specific technologies.

In our management framework, an IMF process is a set of roles (like the Process Manager), responsibilities and activities. The roles and responsibilities of an IMF process define who is responsible for doing what in terms of creating, integrating, or administering the services, the system behaviours and the architectural modules of our software architecture. And the activities formally describe the methods of all the processes. They represent the most methodological design of our framework.

The most important roles and responsibilities included in our IMF approach for DLSs are:

• IMF Manager. Overall responsible for the IMF solution.
• DLS Manager. Person responsible for a DLS. This manager reports to the IMF Manager.
• Service Owner. Person responsible for one specific service supervising all activities around service design, management and delivery. This owner reports to the IMF Manager.
• Process Manager. Supervises all activities of a specific process and is responsible for maintaining an appropriate level of competence in all people involved in the process. This manager reports to the IMF Manager.
• Architecture Manager. Supervises all process activities involving the design, configuration, implementation, exploitation and maintenance of the software architecture. This manager reports to the IMF Manager.
• Cooperation Manager. Supervises all process activities around the design, integration and administration of cooperative system behaviours being incorporated into the software architecture from top-level cooperative actions. This manager reports to the Architecture Manager.
• Process Staff. They are responsible for performing all the activities of the assigned process and report to the Process Manager.
• DLS Administrators. They are responsible for creating and registering new service templates as well as system behaviours configurations within the DLS software architecture.

The activities of each process are described in the following paragraphs.

The major processes around Services Design and Management and their activities are as follows:

• Service Portfolio Management. Creating and administering new services using the Service Management Module. Each service must be identified, defined, approved, evaluated and integrated into the software architecture using the Service Management Module.
• Service Availability Management. When and how to make the services available through the Service Delivery Module.
• Resource Capacity Management. Administering the capacity of all the resources of the services.

Some of the processes for Services Development and Operations and their activities include:

• Service Architecture Management. To integrate and manage all the services within the software architecture.
• Service Deployment Management. To deploy all the services within the software architecture.
• Service Configuration Management. To complete service design with appropriate configurations, including final service templates setups describing how to interact with the service applications.
• Service Validation and Testing. To validate and test both functionality and performance of all the services with the software architecture.

There are also cooperation-oriented (not ITIL supported) processes around the design, integration and administration of system behaviours within our software architecture. These processes and their activities are as follows:

• System Behaviours Development. To design and implement single and cooperative system behaviours within the software architecture.
• System Behaviour Architecture Management. To integrate and manage the system behaviours within the software architecture.
• System Behaviours Management. To administer and maintain the single and cooperative system behaviours according to the simple and cooperative actions designed in the second abstraction of our IMF.

There are also other common processes affecting both services and system behaviours. These processes and their activities are as follows:

• Change Management. To administer all the changes involved with new and/or evolved services and system behaviours.
• Incident Management. To administer all possible incidents in the operative model of our software architecture, once the technology abstraction has been resolved. Each incident must be identified, categorized, prioritized as required, scaled and resolved. The possible services restoration must be completed in a timely efficient manner and with minor customer disruption.
• Problem Management. To solve any possible problem with the operative model of our software architecture. Each possible problem must be investigated and handled, adding possible incident reviews prior to final resolution.
• Infrastructure and Platform Management. To administer all the infrastructure software and hardware platform. These processes are defined in more detail once the next technology abstraction has been completed. They include fine tuning and configuration management across the final architecture platform.
• Release Management. To control the final release of all the software architecture components, services and system behaviours.

2.5.7. Technology Abstraction

In the final (sixth) abstraction we introduce technological aspects of development to continue supporting our top-level intelligent cooperation of DLSs. Indeed, in this last abstraction we provide more architecture-oriented and process-oriented definitions based on concrete technologies, methods, standards and tools for cooperative DLS management. Indeed, we create, adapt and/or evolve special purpose technologies based on, for example, Web Services or AI Data-Driven methods. But we can be flexible in the way that we adjust our technologies and related standards to our previous abstractions.

This technology abstraction is especially relevant to implementing the traditional services within our software architecture since they must be standard components for final users, administrators and other information systems. Further, the DLS cooperation implemented with our system behaviours must also be constructed as a distributed network of extended standards. And we must use appropriate Web technologies to implement our Web Interfaces communicating with the DLS service components.

All our services (traditional and AI-driven services) can be integrated into our software architecture using XML Web Services technology such as JAX-WS (Java API for XML Web Services). This programming interface uses annotations, from Java SE 5, to simplify the development and final deployment of the Web Services.

Using current AI technology, the development of intelligent services would take advantage of current Data-Driven methods based on large datasets, Neural Networks and Learning Algorithms. Indeed, some of the AI applications related to our AI-driven services could be trained using these techniques, reducing the computational efforts in developing these applications, at the cost of energy and computational resources in applying the learning methods. Most AI applications result from these training methods rather than programming system code. They require secure, large and suitable data sets to train the applications (models) during system testing. Learning Algorithms can exploit Digital Object Registry and Metadata Registry to generate new digital content. Further, some of the intelligent services can be implemented using Autonomous Agents technologies to make intelligent decisions for sharing and retrieving DLS data supporting the top cooperative abstraction. This type of implementation can optimize personalization services through, for example, collaboration agents.

Generative AI technology can also be incorporated into our IMF integrating, for example, chat-bots that support intelligent language models and conversations for user-oriented services.

In the resulting technology-based operative model, it is important to establish all the legal and ethical aspects (regulations) that constrain the final application of the AI technology within the DLSs. For example, it is necessary to establish privacy and data security aspects in the datasets and data inputs used for our decision making and recommendation processes. Further, any possible application of Autonomous Agent technology must guarantee that there is no human replacement and/or human behaviour control. Although this last aspect has been carefully considered since we clearly distinguish between “system behaviour” and “human behaviour”.

3. Results

The following sections present the major results and discussions of our research work.

3.1. Evaluation Case Study

Here we evaluate our proposed IMF through a design case study involving a generic government organization in which multiple Digital Library Systems (DLSs) must collaborate and integrate new AI-driven services. The case study demonstrates how the IMF addresses the management challenges identified in Section 2.4, emphasizing critical needs, operational requirements, and available resources.

Modern government organizations are increasingly expected to provide efficient, effective, and transparent public services such as social security, justice, universities, defense, healthcare, and education. Achieving this goal requires a flexible and robust management framework that supports the integration and operation of diverse services across various DLSs.

The public sector has undergone significant transformation with the adoption of digital technologies, which have reshaped how services are delivered and managed. Traditional services are rapidly evolving into digital formats accessible from any location at any time. The success of this digital transformation relies heavily on the quality and interoperability of services provided by different DLSs.

Furthermore, digital service transformation must support agile, cooperative, and intelligent digital governance. This evolution enables faster, smarter, and more reliable service delivery with fewer individual errors. To this end, DLSs must work collaboratively to provide AI-enhanced services. Government organizations can benefit significantly when both internal and external DLSs align around shared objectives, operating under the principle of non-competition. In this context, digital transformation represents a form of collective action, as service evolution in one DLS is intrinsically linked to developments in others.

In our case study, we consider DLS1 and DLS2 as the primary digital library systems of a generic government organization. These systems are complementary, supporting the delivery of integrated public services. For instance, DLS1 may focus on health service records and AI-based diagnostics, while DLS2 may manage educational content and citizen feedback. The integration of both DLSs enables cross-domain services such as personalized health-education programs or AI-supported community initiatives.

3.1.1. Formal Agreement and Project Plan

A formal cooperation agreement defines the terms, specific conditions, and financial arrangements of this joint effort. The underlying assumption is that this collective endeavor will reduce the complexity of digital transformation and support data-driven decision-making across the organization. A key outcome of the agreement is enabling cooperation not only in DLS operations but also in their respective digitalization processes.

The next logical step involves developing a comprehensive project plan and dividing it into distinct phases. If citizens primarily access DLS1, which in turn relies on DLS2 for specific services (as outlined in working scenarios 1 and 2), we propose the following project phases:

• Phase 1: Define a high-level proposal outlining the public services to be offered from DLS1, the structure of the cooperation agreement, and associated digitalization efforts in DLS1 and DLS2.
• Phase 2: Complete the digitalization of traditional services currently handled by DLS1 and DLS2 independently.
• Phase 3: Develop specific integration strategies to enable interoperability between DLS1 and DLS2 in support of the proposed public services.
• Phase 4: Design the IMF architecture to orchestrate the cooperation and intelligent service management between DLS1 and DLS2.
• Phase 5: Implement and operationalize the IMF solution, ensuring continuous monitoring, evaluation, and adaptation to new service demands.

3.1.2. Cooperation Scenarios

To ground the IMF proposal in a realistic setting, we define two cooperation scenarios between DLS1 and DLS2 within a generic government organization. These scenarios illustrate typical interactions between public services and highlight how IMF supports intelligent coordination, interoperability, and service orchestration.

Scenario 1: Cross-service Citizen Access

In this scenario, a citizen accesses DLS1 to request a health-related service (e.g., vaccination record retrieval, AI-supported medical advice). However, the fulfillment of this request requires additional information or services managed by DLS2, such as eligibility validation from civil registries or educational background from public training systems. Without an integrated framework, this process would involve manual data exchange or delayed communication between departments. IMF addresses this by offering a semantic interoperability layer that allows DLS1 to trigger intelligent service requests to DLS2, automatically gathering and aligning the required data through pre-defined AI-driven service connectors.

Scenario 2: Predictive Service Adaptation

In this case, DLS2 manages citizen feedback and behavioral data from public platforms related to education and social participation. By analyzing this data, DLS2 identifies emerging needs (e.g., digital literacy programs or targeted health interventions). Through the IMF, DLS2 can initiate cooperation with DLS1 to dynamically co-design or adjust services that combine educational and health components—such as personalized preventive health programs based on educational level and risk factors. The IMF facilitates this cooperation by offering shared policy enforcement rules, real-time data flow monitoring, and autonomous coordination mechanisms based on AI policy agents.

3.1.3. Intelligent Management Framework Design and Functional Layers

The Intelligent Management Framework (IMF) that we have described in section 2.5 consists of several modular layers that support the seamless and intelligent integration of services across DLSs. These include:

• Service Registry and Discovery Layer: Maintains updated metadata about all available services, capabilities, and access constraints across DLS1 and DLS2. This layer enables automatic discovery and composition of cross-organizational services.
• Policy and Governance Layer: Manages digital governance rules, compliance requirements, and cooperation policies. It ensures that inter-DLS interactions align with institutional regulations and public service standards.
• AI Coordination and Decision Layer: Hosts intelligent agents and decision-support mechanisms. This layer interprets service requests, optimizes resource allocation, and resolves conflicts in service workflows using techniques such as reinforcement learning or case-based reasoning.
• Data Mediation and Semantics Layer: Ensures semantic alignment and data transformation between heterogeneous DLS schemas, enabling consistent and meaningful information exchange.
• Monitoring and Adaptation Layer: Tracks service performance, user satisfaction, and system integrity. It uses this data to recommend adjustments in workflows or service orchestration strategies.

Overall, the IMF allows DLS1 and DLS2 not only to cooperate efficiently but to evolve towards a responsive, intelligent, and citizen-centric service ecosystem. Through continuous learning, feedback, and alignment with public sector goals, the IMF empowers government organizations to manage complexity and innovation in their digital transformation journey.

3.1.4. Addressing Management Problems

Throw the six abstractions and four refinement techniques of our IMF design process, we can address the eight management challenges outlined in section 2.4 for our new scenarios 1 and 2.

• Problem 1. The high-level cooperation outlined in our first abstraction is designed and implemented in the following abstractions, including possible metadata interoperability between DLS1 and DLS2.
• Problem 2. The IMF software architecture and the proposed layers allow the integration of new cooperative actions from superior to later abstractions.
• Problem 3. DLS1 and DLS2 can incorporate appropriate AI-driven services, implementing new decision-making and recommendation mechanisms.
• Problem 4. Our IMF software architecture supports open-source management in DLS1 and DLS2 while solving cooperative integration through the design, implementation and execution of cooperative system behaviours.
• Problem 5. Our IMF proposal integrates AI-driven services instead of transforming traditional DLS services. These AI-driven services can be used in combination with traditional DLS services.
• Problem 6. The IMF software architecture represents a scalable solution that can easily integrate and manage new AI-driven services.
• Problem 7. Our DLS1 can easily share these new AI-driven services with DLS2 since both share a common software architecture. The functional modules of these software architectures (e.g. the Service Delivery Module accessing the Services Registry) also facilitate this usability.
• Problem 8. Through our cooperation project outlined in section 3.1., the management lifecycle of DLS1 and DLS2 can be evolved into an integral management solution based on ITIL-like service processes as well as new cooperation processes.

3.2. Qualitative and Statistical Analysis

To complement the design and technical evaluation of our Intelligent Management Framework (IMF), a qualitative and statistical study was conducted to capture the perceptions of public sector professionals regarding the applicability and appropriateness of the proposal. The structured questionnaire gathered valuable information on the relevance of the research, the critical points of current management models, the perceived usefulness of the IMF, and potential challenges to its adoption. However, the results should be interpreted with caution. The sample size was small, with only six valid responses, selected through convenience sampling, which limits the representativeness of the findings and hinders generalization to broader contexts. Furthermore, participants' familiarity with frameworks such as ITIL or artificial intelligence integration processes was uneven, which may have influenced their perceptions and responses. Despite this, the results offer a valuable preliminary insight, revealing common ground regarding the need for cooperation between digital systems in key areas such as education and healthcare, as well as a largely positive assessment of the proposal's clarity and potential impact. The statistical analysis focused on basic descriptive measures that allowed us to identify general trends, while the qualitative study gathered specific insights into the shortcomings of current models, highlighting the lack of interoperability, the absence of advanced AI-based services, and deficiencies in institutional coordination. Although this is an exploratory analysis, these observations provide an initial validation of the relevance of the IMF and guide future research toward a broader and more systematic evaluation.

A structured survey questionnaire was developed to gather insights and evaluations from professionals working in or with the public sector. The questionnaire focused on analyzing the relevance of our investigation, identifying critical pain points, assessing the perceived utility and relevance of the IMF, and exploring opportunities for future evolutions. It was structured into the following key sections:

• General demographic and professional background of the participants like role, years of experience and sector affiliation (3 questions).
• Types of public sector services that currently require cooperation between intelligent Digital Library Systems (DLSs) (4 questions).
• Perceived limitations and inefficiencies in current service management models (3 questions).
• Prior experience with ITIL-based frameworks and AI integration in public administration (4 questions).
• Evaluation of the proposed IMF in terms of clarity, relevance, feasibility, and potential impact (11 questions).
• Anticipated organizational, technical, or legal constraints for IMF adoption (4 questions).
• Suggestions for further improvement or adaptation of the IMF approach (2 questions).

The content validation procedure we used to validate this questionnaire was based on exploring and reviewing its structure and items with relevant research papers that effectively capture topics under investigation.

Participants for the survey questionnaire were selected from a targeted sample of professionals working in government IT departments, digital transformation offices, and AI-related policy and infrastructure units. The method we used to select this targeted sample was convenience sampling. The main criteria we followed for including/excluding participants in our targeted sample were suitability, availability and willingness to participate. We selected relevant government offices, units and departments for our research and sent a “request to collaborate” email to our potential candidates providing precise information about our investigation.

The questionnaire was distributed to our selected participants, and we received six valid responses. The data gathering occurred in June 2025 and September 2025. These responses were compiled and processed using Google Forms, Microsoft Excel and basic statistical tools to identify trends and summarize key findings and conclusions.

3.2.1. Qualitative Study Results

The results of our qualitative study are presented in the next paragraphs following the structure of our survey questionnaire. They include both quantitative summaries (e.g., percentage of respondents agreeing or disagreeing with specific statements), profound qualitative interpretations based on these, and thematic analysis of open-ended responses. This triple approach allows us to evaluate not only the level of significance of our investigation and the functional strengths of the IMF, but also the perceived alignment of our IMF proposal with real-world needs, priorities, and future challenges faced by public organizations.

Due to the sensitive nature of our questionnaire and aiming to maintain the privacy of our data sample, the results described in the following sections do not include direct quotes with the identities of the respondents.

General demographic and professional background (section 1)

The selected participants willing to collaborate were five government officials who serve as heads of IT-related units, and one AI-related full professor. The government officials belong to several governmental institutions in Spain, namely Complutense University of Madrid and University Hospital Infanta Leonor. And their positions rank Dean, two Vice Dean, Vice-Chancellor, Chief of Urology and Head of Urology Service.

The major job responsibilities of these participants outlined in our questionnaire are:

• University school management.
• Interaction with student associations, improvement of internal management support applications and enhancement of internal communication at a university school.
• Chief of services.
• Technology and sustainability at the university.
• Teaching and research.
• Healthcare work in the service, research work and comprehensive management and organization of the service and its professionals.

About the time that these participants have been working in their institutions, the responses are displayed in Figure 5. These responses show that 83,3% have been working in their institutions for longer than 10 years whereas only 16,7% have been working for 5 to 10 years.

Public sector services that require cooperation between intelligent DLSs (section 2)

Regarding the type of public sector services that the participants consider require current cooperation between intelligent DLS, we obtained the following results.

First, we asked the participants if current public sector services require urgent cooperation between intelligent DLSs, and the responses can be seen in Figure 6. 50% of the participants totally agree with this research statement whereas only 16,7% are neutral and none of them totally disagree.

We also asked what are the main public services that currently require “cooperation between DLSs” and the responses can be seen in Figure 7. Most of the participants said that these public services are in Education and Healthcare (33,3%). The rest find these services in Universities and Justice (16,7%). So, all of them agree with our research statement about the public services of their institutions.

In our next question, we asked the participants what public services require “cooperation between intelligent DLSs” and their responses are drawn in Figure 8. According to their responses, 50% of the responders consider that these services belong to healthcare, 33,3% belong to education and 16,7% to universities. So, again, they find that our research statement is true in their institutions.

In the seventh question, we asked the participants for examples of such public services and the responders suggested, for example,

• Cooperation between EHRs in the healthcare sector.
• Cooperation between university libraries in the education sector.
• Undergraduate and graduate university education.
• Development of care protocols.

Perceived limitations and inefficiencies in service management models (section 3)

The next three questions of our questionnaire focused on the limitations and inefficiencies in current service management models in government organizations, and the results can be summarized as follows.

First, we asked whether the participants perceive major limitations in current service management models in their organizations and the responses can be seen in Figure 9. As you can see, 66,7% of the responders consider that our research findings are true.

Second, we asked whether the participants perceive major inefficiencies in current service management models in their organizations (see Figure 10). And, again, 66,7% of the responders consider that we are right with our research findings.

Finally, we asked the participants what the major limitations and inefficiencies in the service management model of their organizations are. The responders provided the following answers:

• No differences between professionals in similar range.
• Uploading content, searching content.
• Lack of interoperability with other organizations.
• Lack of advanced services based on current advances in AI.
• Lack of coordination between teaching and research activities.
• Lack of communication between the University and Hospitals.

Therefore, the major limitations that we have found with our preliminary investigations (like the lack of advanced services based on AI and the lack of cooperation between government organizations) are also perceived by our questionnaire participants.

Prior experience with ITIL-based frameworks and AI integration (section 4)

In the next four questions, we asked the participants about their experience with two relevant areas for our investigations: ITIL-based frameworks and AI integration in public administration. In doing so, we attempted to find if ITIL has been widely adopted in Spain and if current government organizations of this country are involved with AI integrations.

Regarding the first question (ITIL experience), the participants responded (see Figure 11) that none of them are familiar with ITIL standard.

In the next question, and for those who were familiar with ITIL, we asked if the participants have worked with this standard. Obviously, as you can see from Figure 12, none of the participants have worked with this standard in their organizations.

About AI integration within Spanish government organizations (see Figure 13), only 33,3% of the participants responded that they were familiar with this integration.

Finally, as you can see in Figure 14, the same 33,3% of participants responded that they have worked on AI integration in the public services of their organizations. Therefore, it seems clear that our IMF proposal for AI integration in the public sector represents a new challenge.

Evaluation of the proposed IMF (section 5)

For the general evaluation of our IMF solution, we asked the following 11 questions to our participants. With all these questions we tried to cover all the major features and design elements of our management framework.

First, we asked whether the participants consider that our IMF is a clear solution for government organizations and their digital transformations. As you can see from Figure 15, 80 % of the participants consider that this statement is true whereas only 20% of the participants do not find IMF a clear solution for government organizations.

Next, we asked the participants whether our IMF could be relevant for current digital transformation in their government organizations. In this case (see Figure 16), 80% of the participants were neutral and 20% totally agreed.

In the following question, we asked the participants if they consider that our IMF framework is a feasible solution. As you can see, in Figure 17, 60% of the participants agreed, 20% were neutral and 20% totally agreed. So, none of them totally disagreed with this statement.

For the next question, we asked the participants if the design and implementation of our proposed IMF could produce a potential impact in current digital transformation in their organizations. In this case (see Figure 18), 80% agreed with our statement and 20% totally agreed. So, again, none of them totally disagreed with our assumption.

Regarding the main design elements of our management framework, we asked the participants what the most relevant ones are according to their opinion. The responses to this question can be seen in Figure 19: The most relevant design elements are cooperative models and AI-driven services (40% each) and cooperative system behaviours (20%).

Next, we asked the participants about their opinion regarding the abstractions and refinement techniques of our design approach for IMF-DLS solutions. As you can see from Figure 20, 20% considered that they were very interesting, 60% considered that they could be useful and only 20% responded that they were not sure.

In Figure 21 you can see the opinion of our participants regarding the services that we propose for their government organizations. 20% considered them very interesting, 40% considered them useful and 40% responded that they were not sure.

In the next question, we asked the participants their opinion regarding the cooperative system behaviours of our solution (see Figure 22). In this case, 40% responded that they were very interesting, 20% responded that they could be useful and 40% said that they were not sure.

In Figure 23, we show the opinion of our participants regarding the proposed software architecture for our solution. As you can see, 20% consider that it is very interesting, 40% consider that it could be useful and 40% consider that they are not sure.

Regarding the management processes of our IMF solution for the DLSs of their government organizations (see Figure 24), 60% considered they could be useful and 40% considered that they were not sure.

Finally, we asked the participants if they would recommend the adoption of our IMF solution in other government organizations. As you can see in Figure 25, all of them (100%) said yes.

Anticipated organizational, technical, or legal constraints for IMF adoption (section 6)

In the next group of questions, we asked the participants about possible constraints for IMF adoption in their organizations.

In Figure 26, you can see the responses of the participants for the existence of possible organizational, technical and/or legal constraints. 20% totally disagree, 40% agree and 40% totally agree.

In the next question, we asked the participants about these possible constraints. The participants responded with the following answers.

• Bureaucracy.
• Public system.
• Work overload, too many tasks.
• I am not familiar with the FMI, so I have no clear criteria.
• Bureaucracy and lack of investment.

Therefore, even though they all found possible constraints with IMF adoption, none of them criticized the technical aspects of our solution.

Precisely this was our next question: “what are the major technical constraints for the IMF adoption in your organization?”. The answers were as follows.

• Typically, library platforms are closed (like the one at the UCM), so any development is either impossible (the vendor doesn't allow it) or expensive (in my experience with customizing other ERPs). If the cost-benefit analysis for a real, specific use case for the organization isn't very clear, the implementation of an approach like the one presented is not very clear.
• Public system.
• Required training on behalf of the staff, cost of hiring people with the necessary skills.
• I am not familiar with the FMI, so I have no clear criteria.

Therefore, once again, none of the participants criticized any of the technical features of the design elements of our management framework.

Finally, we asked the participants about the legal constraints for IMF adoption in their organizations. The answers were as follows.

• N/A.
• Author rights management.
• I am not familiar with the FMI, so I have no clear criteria.
• I don't know.

Suggestions for further improvement or adaptation of the IMF approach (section 7)

About the suggestions of the participants for further improvement or adaptation of our IMF proposal, we asked 2 questions.

First, we asked the participants what they suggest for further improvement of the IMF approach. The answers were as follows:

• The main problem I see is that I can't visualize the real benefits of the approach. I also can't see how the integration process can be generalized between any two platforms, since the integration processes I've been involved with have typically been ad hoc due to the nature of the platforms and/or tools.
• Formation.
• Integration with ERP concepts.
• I am not familiar with the FMI, so I have no clear criteria.
• Investment and coordination between levels.

For the last question of our questionnaire, the participants could provide their suggestions for further adaptation of our IMF approach:

• Formation.
• I am not familiar with the FMI, so I have no clear criteria.
• It would be interesting.

3.2.2. Statistical Study Results

For our statistical study, we transformed the subjective opinions of our participants into numerical values, and we used an Excel spreadsheet to obtain the minimum, maximum, mean and standard deviation values for each questionnaire variable.

The questionnaire variables were defined for each of the evaluable questions assigning code (with first character indicating the number of the section) and numerical values in order of appearance (see Figure 5 to Figure 26). For example, the first variable was for the period that the participants worked in their institution, had code “1-TIME”, and the assigned numerical values were 1 (less than 5 years), 2 (between 5 and 10) and 3 (more than 10 years).

The following two tables (Table 1 and Table 2) show all the variables definitions of our study and the statistical calculations for them, respectively.

In Figure 27 we show a graphic built with our statistical results for the first four sections of our questionnaire.

The next figure (Figure 28) displays our statistical results for the evaluation of our IMF solution for DLSs (section 5 of our questionnaire).

According to these graphics, we can confirm that when the possible answers to the questions vary from “totally disagree” to “totally agree” (variables 2-COOP, 5-RELE, 5-FEAS, 5-IMPACT and 5-CONSTR), the mean has high values and there is low variability and low deviation. This clearly indicates that the participants agree with our research statements, with minimal differences in their responses.

In this group of variables, the highest mean values are for the variables 2-COOP and 5-FEAS. Meanwhile, the questions with the lowest mean values are for 5-RELE and 5-IMPACT.

In Figure 28, we can also observe that when the answers to the questions vary from “very interesting” to “I am not sure” (variables 5-DESIGN, 5-SERV, 5-COOP, 5-ARCH and 5-PROC), the mean is low and there is high variability and medium deviation. This indicates that the participants are interested in the design elements of our IMF solution although some of the participants could not form an opinion due to the lack of implementation of this solution. Nevertheless, the medium deviation also indicates that there are not very dispersed perceptions for these evaluations.

In this group of questions, the lowest mean value is for 5-DESIGN and the highest for 5-PROC. Therefore, it seems that the participants are especially interested in the abstractions and refinement techniques of our framework.

When the answers of the questions are “yes” or “no” (variables 3-LIMIT, 3-INEFIC, 4-ITIL, 4-WITIL, 4-AI, 4-WAI, 5-CLEAR and 5-RECOM), the mean is very low and there is very low variability and deviation. This indicates that most of the participants agree with our research statements.

For this group of questions, the lowest means are for the variables 3-LIMIT, 3-INEFIC and 5-RECOM. And the highest means are 4-ITIL, 4-WITIL, 4-AI and 4-WAI since the participants do not have much experience with ITIL standard and AI integration.

Finally, there are also variables associated with questions where we provide an enumeration of values (2-PSCOOP and 2-INTELL). For this last group of questions, the mean has no relevance, and it is important to underline that there is high variability and high deviation. This indicates that most of the participants do not coincide with their responses since they all belong to different sectors (healthcare, education, etc.).

The highest deviation for this last group of questions belongs to PSCOOP and the lowest belongs to 2-INTELL.

All these results are described in more detail in our conclusions (section 10).

3.2.3. Limitations of Results

The results of this study must be understood within the structure of several limitations that affect its scope and validity.

The first of these is the small sample size, which restricts both the statistical robustness of the findings and their generalizability to other organizational and geographical contexts. Added to this is the convenience sampling strategy, which introduces bias into the selection of participants and may have favored more homogeneous responses than would occur in a more diverse set of institutions. Furthermore, the fact that some respondents expressed little familiarity with frameworks such as ITIL or with previous experiences integrating AI in the public sector suggests that their perceptions should be interpreted with caution, as they may reflect their expectations or intuitions rather than consolidated experience. Another aspect to consider is the possible influence of social desirability biases, since the participants held positions of responsibility in public institutions and could have tended to give conservative or more favorable responses to the study's approaches.

Additionally, with our qualitative analysis we have only gathered the perceptions of participants regarding the top-level design elements of our IMF solution for DLSs because we did not want too much time for our participants. But we could have improved our empirical results if we also asked the participants about lower-level design elements such as concrete software modules and/or management processes.

Finally, we could have enriched the perceptions of our participants if we could have provided user guides, service template examples, and concrete measurement tools for our IMF proposal.

Taking together, these limitations suggest that the results are interpreted as a preliminary approximation that provides relevant evidence but requires verification with broader and more in-depth analyses. Future research should address these limitations by expanding the sample, diversifying the geographic area, including experts with proven experience in digital service management, and triangulating with other empirical validation methods.

4. Discussion

In general, digital transformations and related public service delivery can be improved through efficient and effective IT service management that can be achieved with an ITIL-based framework. With our IMF solution initially introduced in [14], we have proposed a more suitable framework for this public sector governance that incorporates:

• new high-level cooperative models to provide a cooperation focus,
• new abstractions and refinement techniques to facilitate the design process of the management framework,
• new generic, computational and operative models to represent all our abstractions,
• new cooperative system behaviours to support top cooperative models,
• new software architecture for the main services systems of the framework and,
• new cooperation-oriented processes.

In this paper, we have used all these elements to design an IMF solution for intelligent, cooperative DLSs being disseminated within current government organizations and facing many management problems that we have analyzed. Basically, this application of our IMF proposal has provided:

• a cooperation-oriented solution for current complex collaborations and lower-level interoperability between digital libraries,
• an easy-to-follow design process for the management framework,
• clear examples of abstractions and refinements for our management framework,
• an integral and complete management framework for current intelligent, cooperative DLSs,
• a clear categorization of AI-driven services (intelligent services) based on knowledge-oriented, behaviour-oriented, generative and hybrid approaches,
• a scalable solution able to integrate current AI techniques to develop these new AI-driven services like recommendation and decision-making services,
• a functional software architecture to register, deliver and manage these AI-driven services as well as traditional services of DLSs and,
• flexible processes to manage all these services and cooperative system behaviours using software architecture.

To support all these conclusions, we have evaluated our IMF-DLS solution in three different ways:

• providing and solving the management problems of concrete cooperation scenarios for which we have used the combination power of our cooperative system behaviours,
• providing an evaluation case study for DLSs, focusing on cooperation and intelligent services integration needed for current digital transformation and,
• realizing qualitative and statistical studies aimed at capturing and analyzing participant perceptions of all our investigations with a large survey questionnaire (31 questions).

The major management problems found with the cooperation scenarios have been analyzed and solved along with the design process of our IMF solution for DLSs. In doing so, we have demonstrated how our cooperative system behaviours can be designed to solve these problems.

With the evaluation case study, we have demonstrated the feasibility of our IMF approach for DLS cooperation management and for the integration and management of both traditional and AI-driven services. In this case study, concrete DLSs from healthcare and education domains have been analyzed, describing formal agreement and project plan definitions as well as concrete cooperation scenarios for these DLSs. Finally, the design of the IMF solution has been summarized, and the solution of the management problems has been addressed.

The major results of our qualitative and statistical studies can be summarized as follows:

• The studies are based on a medium sample of participants from different government institutions and from the same region. This reflects the diversity of the public sector that we have considered evaluating our research.
• The job responsibilities of these participants range from basic IT-related tasks to full governance for technology and sustainability of their organizations. Additionally, there are full professors working with IT and AI subjects.
• Most of the participants have been employed in their organizations for longer than 10 years. Therefore, they have wide experience in their IT-related jobs in the public sector.
• Most of the participants agree with us that current public services in their organizations require cooperation between intelligent DLSs. Mainly, these organizations belong to healthcare, education, universities and justice. And some of the suggested services must support cooperation among university libraries or cooperation between EHRs in the healthcare sector. Therefore, our focus on cooperation-oriented processes was right.
• Most of the participants perceive major limitations and inefficiencies in current service management models in their organizations. They consider these models lack coordination, advanced services and interoperability. So, again, they agree with our research findings.
• The participants had no experience with ITIL-based frameworks for solving these major limitations. But some of them have had experience in AI technology integration in the public services of their organizations. Thus, our proposal for AI integration represents a major innovation.
• Most of the participants consider that our IMF is a clear solution for the digital transformation of government organizations. And, although only a few totally agree that our IMF could be relevant for the digital transformation of their organization, most of them consider that the design and implementation of our IMF could produce a potential impact in current digital transformation in their organizations.
• Most of the participants consider that our IMF is a feasible solution and they encounter that the most relevant design elements of IMF are cooperative models, AI-driven services and cooperative system behaviours.
• About the abstractions, refinement techniques, services, cooperative system behaviours, software architecture and management processes of our IMF, most of the participants consider that they could be useful and only a few say they are very interesting.
• All the participants agreed that they would recommend our IMF adoption in other government organizations. However, most of them find possible organizational, technical and/or legal constraints for this IMF adoption. Bureaucracy, work overload, investment, required cost-benefit analysis, training and author rights management are some of these constraints.
• Finally, the participants suggested ERP concepts integration, investment, coordination and formation for further improvements and/or adaptations of our framework. Only a few said they had no clear criteria for the last questions since they were not familiar with any implementation of IMF. And one of the participants also mentioned that the IMF adoption would be “interesting”.

In summary, the presented research has allowed for the design, justification, and initial evaluation of an intelligent management framework oriented toward cooperation between Digital Library Systems in the public sector. The results of the qualitative and statistical analysis, although preliminary, suggest explicit recognition of the need to move toward cooperation models that integrate traditional services and services based on artificial intelligence. The survey showed that critical areas such as education and healthcare require mechanisms that facilitate interoperability and intelligent service management, and that the proposed IMF is perceived as a clear solution with potential for positive impact. However, the conclusions must be qualified considering the study's limitations, which restrict the generalization of the findings and force them to be considered more as an initial validation than a definitive demonstration. Even so, the work contributes to the field by proposing a methodologically structured framework that combines cooperative models, system behaviors, software architecture, and ITIL-inspired management processes, offering a solid starting point for the integration of intelligent services in cooperative digital environments. Critically, it must be acknowledged that the adoption of this framework will face practical challenges related to institutional resilience, implementation costs, staff training, and the need to ensure technical and semantic interoperability across heterogeneous platforms. Despite this, preliminary results suggest that the IMF represents a novel and relevant contribution, with the potential to evolve into a broader and more robust model as future research expands the empirical base and addresses implementation challenges in real-world digital transformation contexts.

5. Future Work

According to our evaluation results, the limitations of our studies and the suggestions of the responders of our survey questionnaire, we must try to find more investment for our IMF solutions, distribute our framework worldwide, enrich our analytical studies, provide training and facilitate more coordination between government organizations for future implementations of our IMF solution. Further, we must integrate our framework with ERP concepts.

Another clear research direction for our future work will be the definition of a global development methodology for the DLS software architecture embedded in our IMF framework for DLSs.

We will also investigate the use of AI technology to automate some of the service-oriented management processes that characterize our IMF solution. This could improve the accuracy of the management solution as well as the diverse operations of the library. But, following current AI regulations at EU, we must be careful this automation does not provoke complete human displacement and/or human behaviour control.

Finally, we will focus some of our future research work on comparing and evaluating the computational complexity found in AI-driven services integration in current DLS software architectures, with and without our IMF.