Adopting MOD-API in a Modern Dataset Catalog Platform: Opportunities, Challenges and Limitations

Abstract

As data exploitation continues to demonstrate its value, ontologies, thesauri, and other semantic datasets are increasingly recognized for enabling semantically meaningful data integration across disparate domains. With the proliferation of dataset catalogs, the MOD ontology (Metadata for Ontology Description and publication) was adopted, and an associated API was developed to support the future European Open Science Cloud (EOSC). Their aim is to harmonize catalogs of semantic datasets with respect to metadata vocabularies and access mechanisms, thereby ensuring compliance with the FAIR principles. Within an implementation action involving developers of prominent dataset catalogs, we were selected to integrate the MOD-API into ShowVoc, our platform for publishing and consuming ontologies, thesauri, lexicons, and other Semantic Web datasets. However, ShowVoc already relied on an expressive metadata model, the MDR (acronym for “Metadata Registry”), named after the component responsible for managing the platform’s internal catalog. Due to precise dissemination requirements, the MDR provides multiple abstraction levels and detailed specifications concerning the distributions and formats in which a dataset may be made available. In this article, we report on the challenges that we faced and the trade-offs that we made while reconciling these metadata models, highlighting limitations in the current MOD standard that may inform future enhancements.

1. Introduction

Data collection and analysis have long been two fundamental components of the scientific process, supporting both the formulation and the validation of hypotheses. The advent of computers has significantly enhanced analytical capabilities, increasing both the resolution and the speed of data processing, while computer-based simulations have progressively complemented traditional empirical methods. In the early 2000s, however, the emergence of Big Data triggered a paradigm shift toward exploratory, data-intensive science, characterized by the use of large-scale statistical techniques and data mining approaches [1]. The full implications of this shift are still not completely understood and continue to be debated within the scientific community [2,3].

Lowering the barriers to data reuse across seemingly disparate domains is critical to modern data-driven science and is one of the key motivations behind the formulation of the FAIR principles [4,5], which offer guidance to data stewards to ensure that relevant data can be found (F), accessed (A), interoperated (I) with and, ultimately, reused (R). A common means to comply with these principles is to publish data, tools, and services on established catalogs, which enable prospective users to discover relevant resources more effectively. To achieve this, catalogs are often designed to structure the metadata that describes their items, relying on ontologies, thesauri, and other semantic datasets for this purpose. Since these semantic datasets are also required to be FAIR, the adoption of semantic dataset catalogs has increased, with metadata-related features and access mechanisms emerging as two prominent dimensions for their assessment [6].

The harmonization, if not full federation, of semantic dataset catalogs is necessary to overcome the proliferation of competing catalogs and ensure semantic interoperability across adjacent scientific communities. Adapting the categorization proposed in [7], we illustrate the main approaches to achieve this in Figure 1. These approaches differ in whether the burden of achieving, and indeed committing to, interoperability falls entirely on a third party wishing to expose content from multiple catalogs, on the catalogs themselves, or somewhere in between.

The API gateway approach (a) places the entire burden on the gateway owner, who must implement adapters for each catalog technology. This strategy is adopted, for example, by the TS4NFDI’s API Gateway [8], which retrieves metadata from different catalogs using dedicated adapters that harmonize the retrieved metadata. The aggregated catalogs may not even be aware of this effort, as it is performed entirely by the gateway, which manages every aspect of the process. Therefore, this strategy imposes a high cost on the party operating the gateway as the number of different technologies increases, and it may be susceptible to failure whenever non-backward-compatible changes are introduced, potentially breaking the adapters. The frontend federation approach (b), exemplified by the OntoPortal Federation [7], requires each catalog frontend to interact not only with its own backend but also with the backends of multiple federated catalogs that rely on the same technology and thus expose the same API. This strategy is indeed effective, but its scope is inherently limited because it cannot support the federation of catalogs built on heterogeneous technologies. Finally, the shared-API approach (c) requires each catalog to implement the same agreed-upon API. This strategy clearly shifts the burden of interoperability to the catalogs themselves, which must commit to the shared API and take responsibility for its implementation. Without requiring any additional harmonization or federation infrastructure, this approach allows serendipitous access to any compliant catalog by clients that happen to encounter it. Nonetheless, it is also compatible with deploying a gateway over a predefined set of catalogs, with sustainability and robustness issues mitigated by the commitment of catalogs to a shared, stable API. In fact, the latter may also enable a minimal degree of frontend federation, regardless of the underlying technology stack of the catalogs.

These interoperability concerns clearly need to be addressed in the ongoing construction of the European Open Science Cloud (EOSC) [9], which aims to “provide researchers and innovators in Europe with an open and trusted multi-disciplinary environment where they can publish, find and reuse data, tools and services for research and innovation”. Frontend federation clearly falls short in this context, as the adoption of a single catalog technology is not attainable in such an open and diverse environment. Similarly, a pure API gateway approach would be overly brittle and costly to maintain. By contrast, the shared-API approach addresses these challenges at their root, as it requires different catalogs to commit to a shared metadata model and shared access mechanisms.

The FAIR-IMPACT [10] project is helping make the envisioned EOSC concrete through the development of the MOD-API [11,12], which builds on the MOD (Metadata for Ontology Description and publication) [13] ontology. The MOD ontology has undergone several iterations, informed both by the practices adopted by actual catalogs and by the consensus reached among stakeholders who participated in several workshops. Widespread adoption of the MOD-API by the community is now crucial to realizing its value proposition. FAIR-IMPACT supported progress in this direction through an open call to engage catalog developers interested in implementing the API [14]. As developers of ShowVoc [15], a platform for publishing ontologies, thesauri, lexicons, and Semantic Web datasets in general, and which can be considered a generic catalog technology, we applied to the open call with a proposal to implement MOD-API within ShowVoc, which was eventually selected.

ShowVoc already relied on a sophisticated metadata model called MDR [16,17] (Metadata Registry), named after the component that manages the platform’s internal dataset catalog. The model relies on DCAT and extends it by providing a ladder of abstractions that captures a semantic dataset per se, independently of its multiple realizations, each of which may be expressed through several distributions and delivered via different access channels. Because the model captures dimensions not covered by the MOD ontology (and even less by the subset of MOD exposed through the MOD-API), replacing it entirely with the MOD ontology or even realizing a full one-to-one mapping was not viable. We embraced the challenge by examining how the two models could be aligned, identifying semantic mismatches and potential limitations, assessing whether these issues might affect the goal of implementing the MOD-API, and, where necessary, determining how they could be mitigated. While we value the specificity of the MDR, we are not advocating it over the MOD ontology and its API. It is also not our aim to motivate the design of the latter. We take both as given and, acknowledging our role in supporting these emerging standards, we adopted them to provide a complementary access layer to the catalog managed by ShowVoc. In doing so, we help ensure that ShowVoc can continue to thrive within the future EOSC ecosystem, should the MOD-API ultimately succeed in delivering the intended interoperability across semantic dataset catalogs.

This work is structured as follows: Section 2 illustrates related work; Section 3 provides background on the MOD ontology and the MDR metadata model that already powers ShowVoc; Section 4 describes the MOD-API; Section 5 contrasts the two metadata models (in Section 5.1), illustrates the approach to integrate the MOD-API within ShowVoc (in Section 5.2), and explores how the two models can be reconciliated (in Section 5.3); Section 6 provides more implementation details; Section 7 addresses the verification and validation of the proposed solution; Section 8 offers a discussion; and Section 9 concludes the work.

2. Related Work

The Semantic Web is an extension of the document-oriented Web in which “information is given well-defined meaning, better enabling computers and people to work in cooperation” [18]. The Linked Open Data paradigm (https://www.w3.org/DesignIssues/LinkedData.html, accessed on 6 March 2026) clarified the roots of the Semantic Web by grounding it in the same architectural principles that made the original Web successful, evolving it into a global data space [19] that supports the publication, discovery, and meaningful integration of datasets originating from unfamiliar and distant domains [20,21]. In this regard, the primary mechanism for information retrieval is the follow-your-nose strategy, which consists of traversing links between resources, possibly jumping from one dataset to another, each published independently.

Nevertheless, the need emerged for a coarse-grained perspective of this giant global graph, one that acknowledges the boundaries and identities of datasets, their general attributes (including licensing, provenance, and theme), their structure, metrics, and the range of access mechanisms (beyond HTTP dereferencing), as well as their interrelations. This need motivated the development of the VoID [22,23] (Vocabulary of Interlinked Datasets), which enables the description of linked datasets. VoID also standardized the metadata discovery process, including a scenario in which each resource within a dataset is linked to the VoID description of that dataset, which can be found by anyone who comes across it by “following their nose”. A concrete example of VoID in practice is the VoID description [24] of AGROVOC [25], the multilingual thesaurus developed by the Food and Agriculture Organization (FAO) of the United Nations, comprising more than 41,000 concepts across 42 languages and covering domains such as food, nutrition, agriculture, fisheries, forestry and environment.

VoID has also been significantly extended by the community. As previously noted, VoID supports dataset metrics, including the number of triples, subjects, and similar indicators. It also allows describing partitions of a dataset defined according to specific criteria, such as identifying the subset of resources belonging to a given class. The void-ext [26] extension broadens the scope of statistical descriptions by introducing additional metrics (e.g., the average subject IRI length) together with new partitioning criteria (e.g., subsets defined by resources appearing in predicate or object position). VOAF [27] is another extension focused on ontologies and other vocabularies used in the LOD cloud. Finally, LIME [28] provides a vocabulary for describing language resources published as LOD [29], as well as linguistic information available within ontologies, thesauri, and datasets.

Despite the distributed publication model at the heart of the Web, it is undeniable that most interactions with it now begin through Google and similar search engines, which have effectively become gatekeepers to the Web. The situation worsened with the rise of conversational agents such as ChatGPT and Microsoft Copilot, which retrieve, analyze, and re-elaborate information on behalf of users, motivating new concerns about anticompetitive behavior [30] and contributing to the rise in zero-click searches that threaten the open web [31]. Without search engines with comparably dominant positions, the Semantic Web, possibly fueled by the widespread adoption of the FAIR principles, has seen a surge in the number and relevance of semantic dataset catalogs. These range from the LOD Cloud [32] to Linked Open Vocabularies [33,34] (LOV), along with a multitude of domain-specific catalogs, such as those built on the OntoPortal [35,36] software stack (e.g., AgroPortal [37,38], EcoPortal [39,40], BiodivPortal [41,42], EarthPortal [43,44], MedPortal [45], TechnoPortal [46]), originally developed for BioPortal [47,48].

The reach of the Semantic Web in data catalogs is broader, as “more research on combining data catalogs with data models of high semantic expressiveness is needed” [49].

DCAT [50] (Data Catalog Vocabulary) enhances interoperability between dataset catalogs through a shared RDF vocabulary that describes datasets (i.e., dcat:Dataset), their accessible forms (i.e., dcat:Distribution), such as downloadable files or data services (i.e., dcat:DataService), as well as the catalog itself (via dcat:Catalog) and the dataset records (via dcat:CatalogRecord). Figure 2 provides a high-level overview of the DCAT model as presented in its third revision. Indeed, data services were added only in DCAT 2 [51], when its scope was broadened beyond cataloging datasets exclusively.

Unlike VoID, which specializes in the description of RDF datasets, DCAT can describe catalogs comprising resources of any kind, thus serving as a foundation for interoperability between catalogs in general. Application profiles of DCAT have been proposed to capture community practices and to address requirements not covered by the core model available at any given time. For example, ADMS [52] and the HCLS Community Profile [53] addressed versioning, which has since been incorporated into DCAT 3.

Figure 3 illustrates a portion of the ADMS model, showing how the main concepts (asset repository, asset, and asset distribution) correspond to elements in DCAT, and demonstrating the simple yet effective approach used to model different versions of an asset as a linked list of adms:Asset resources, one for each version.

The figure refers to the now-retired W3C specifications; ADMS has since transitioned under SEMIC [54] and has been decoupled from DCAT, which continues to play a significant role in ADMS use cases (https://semiceu.github.io/ADMS/releases/2.00/#interpretation-of-adms-in-the-context-of-dcat, accessed on 6 March 2026).

As shown in Figure 4, HCLS introduces a summary-level description that characterizes a dataset independently of its evolution over time. Each version is explicitly linked both to the summary-level description (following a hierarchical approach) and to the preceding version (following a chaining approach similar to ADMS).

Heavily influenced by these works, DCAT 3 supports both hierarchical and chaining representations of versions—see Figure 5. Notably, DCAT 3 introduces properties in its own namespace for the relations isVersionOf and hasVersion, since the seemingly corresponding properties in Dublin Core Metadata Terms have a much broader scope: they can describe any kind of versioning relationship, including, for example, considering an animated film adaptation as a version of the original book.

In 2018, Google launched its Dataset Search service [55], which harvests datasets available on the Web by exploiting associated metadata represented using a variety of formats, including DCAT, schema.org [56], and CSVW (CSV on the Web) [57].

DCAT is, in general, non-prescriptive, accommodating different and occasionally contrasting detailed modeling approaches, while delegating to interested communities the task of defining shared cataloging practices encoded as application profiles. One notable example is DCAT-AP [58], which has been defined to increase interoperability among data catalogs in the European Union. One particularly contentious matter is how DCAT should be combined with VoID when structuring catalogs of RDF datasets, a question that has led to divergent models, such as those adopted in the aforementioned HCLS profile, as well as in DataID [59] and our own MDR.

3. Metadata Models

In this section, we first describe the MOD (Metadata for Ontology Description and publication) ontology, including a brief overview of its evolution. We then illustrate the MDR, discussing its approach to combining DCAT with VoID, as well as highlighting its reliance on additional vocabularies such as LIME.

3.1. MOD (Metadata for Ontology Description and Publication)

First proposed [60] in 2015, the MOD ontology has since been maintained within the RDA’s (Research Data Alliance) [61] Vocabulary Services Interest Group [62] and subsequently adopted by the FAIRsFAIR [63] and FAIR-IMPACT European projects, which have positioned it as a building block of the future EOSC. The MOD ontology has undergone several revisions, reflecting the inherent complexity of defining a concise yet effective metadata model capable of meeting the needs of diverse stakeholders. We summarize the evolution of MOD to provide insight into its underlying methodology, main design decisions, and rationale.

The development of MOD 1.2 [64] was informed by an analysis of metadata vocabulary usage across 13 “ontology libraries”. The inclusion of descriptive properties in the model was guided by several principles: brevity, clarity, simplicity, authority, standardization, extensibility, usability, and interoperability. In 2018, MOD 1.4 had 128 properties, each representing a cluster of properties drawn from 15 metadata vocabularies that were mapped to one another. MOD became a “maximal metadata model” that satisfied the need for comprehensive coverage, yet lacked guidance on how to prioritize metadata properties. MOD 2.0 [65] greatly enhanced interoperability by defining its main concepts on top of the foundation provided by DCAT. The lack of prioritization among the properties was addressed by indicating which FAIR principles they support, the relevant MIRO [66] guidelines, and, above all, the requirement level in the FAIRsFAIR minimum metadata profile. The latter was defined through the consensus of 30 participants representing about 20 communities who convened at a workshop held in June 2021. Finally, FAIR-IMPACT developed MOD 3 as an application profile of DCAT 2.

Figure 6 provides an overview of the MOD ontology, focusing on its main entities: the semantic artefacts and their distributions, as well as the semantic artefact catalog itself and the records therein. As illustrated, these entities derive from their corresponding DCAT classes, except for the semantic artefact, which rather extends dcat:Resource to emphasize a distinction from datasets conceived as factual data. Nonetheless, since semantic artefacts are typically linked to one or more distributions, they can still be regarded as instances of the class dcat:Dataset. This was a compromise between different propositions that emerged during the development of the third revision of MOD.

MOD enriches DCAT by adding numerous metadata descriptors drawn from existing vocabularies whenever appropriate.

Table 1. Distribution of the properties adopted in MOD 3.2 across metadata vocabularies .

	Vocabulary	Count
	https://w3id.org/mod	40
	http://purl.org/dc/terms/	33
	http://omv.ontoware.org/2005/05/ontology	15
	http://www.w3.org/TR/vocab-dcat/	13
	http://schema.org/	8
	http://vocab.deri.ie/void	7
	http://www.w3.org/2002/07/owl#	5
	http://xmlns.com/foaf/0.1/	5
	http://purl.org/vocab/vann/	4
	http://usefulinc.com/ns/doap#	3
	http://www.w3.org/ns/prov-o#	3
	http://purl.org/pav/	3
	http://purl.org/vocommons/voaf	2
	http://creativecommons.org/ns#	2
	http://www.w3.org/2000/01/rdf-schema#	1
	http://www.w3.org/2004/02/skos/core	1
	http://www.w3.org/ns/odrl/2/	1
	http://www.w3.org/TR/vocab-adms	1
	http://www.w3.org/ns/sparql-service-description	1
	https://w3id.org/mod/2.0	1
total	20	149

shows that MOD adopts 149 properties for the description of the main entities discussed earlier.

The properties are drawn from 20 vocabularies: 18 of them are widely used, standard vocabularies, as required by the FAIR principles. The remaining two correspond to MOD itself, which defines 41 properties (28%). These are not necessarily new properties; in some cases, they originate from vocabularies that are no longer maintained, which requires MOD to redefine them locally. Unsurprisingly, the DCMI Metadata Terms [67] is the second most adopted vocabulary, followed, with a noticeable gap, by OMV [68] (Ontology Metadata Vocabulary) and DCAT, each contributing roughly half as much. The breadth of available properties is illustrated in Figure 7, which shows that only 41 of the 149 properties are part of the FAIRsFAIR minimum metadata profile. Moreover, only 19 properties are mandatory, representing 13% of the total and 46% of the FAIRsFAIR profile, thereby making the metadata curation more manageable. Additionally, 13 properties (representing 9% of the total and 32% of the FAIRsFAIR profile) are still recommended for inclusion.

Figure 8 breaks down these numbers by showing how many properties in the minimum metadata profile fall into each of the three requirement levels, across the main entities defined by the MOD ontology.

3.2. MDR (Metadata Registry)

The MDR (Metadata Registry) ontology (Figure 9) extends DCAT in a more fine-grained manner than MOD, introducing additional semantic distinctions and integrating the VoID vocabulary to describe linked RDF datasets. Its development was primarily motivated by the need to enhance machine actionability across various Semantic Web application scenarios. Among these, ontology matching is a prominent example. In this context, we initially developed a metadata-driven platform [69] to support the semi-automatic configuration of ontology matching workflows, potentially leveraging existing language resources. Subsequent improvements [70,71] regarding the standardization of the LIME vocabulary and better integration within our ecosystem led the MDR to depend on the LIME extension of VoID.

The class dcat:Dataset is specialized into two subclasses: DatasetArchectype and DatasetRealization. The former captures a dataset’s persistent identity as it evolves over time, while the latter represents a concrete instantiation of the dataset, without yet detailing its specific distributions. A dataset realization can correspond to a particular revision of the dataset at a given moment, linked through the properties dcat:hasVersion and dcat:hasCurrentVersion, and abstracts over multiple possible distributions. They may vary not only in their serialization format (e.g., RDF/XML vs. Turtle), expressed through the property dcat:mediaType (potentially combined with dcat:compressFormat to indicate a compressed container), but also in how triples are structured (for example, whether SKOS-XL reified labels are accompanied by plain SKOS counterparts). This variability is handled by linking each distribution to the appropriate instance of the class DistributionScheme via the property distributionScheme.

A MutableDatasetRealization can instead represent either the development copy of a dataset (usually deployed in a knowledge-engineering environment) or its LOD publication made accessible through dereferenceable URIs. These are linked to the underlying archetype via the master and lod properties, respectively.

Both a development environment and a triple store are then modeled as instances of dcat:DataService, and they typically serve a special MDR-defined distribution type called RDFDataset. This class, which extends both void:Dataset and dcat:Distribution, captures the abstract notion of a set of triples, independent of its serialization. It is therefore the place where most VoID metrics should reside and the source from which other file-based distributions can be generated, with PROV-O metadata documenting the derivation process. The Deployment class was also introduced to further detail how a data service is linked to a distribution, for instance, by indicating, through the locator property, where a specific distribution can be found within a service that hosts multiple ones. The MDR also provides a subclass of dcat:DataService, named SPARQLEndpoint, to represent data services that are compliant with the SPARQL protocol.

Figure 10 illustrates the extended dataset hierarchy of the MDR, which also introduces two additional subclasses of dcat:Dataset to represent linksets (between datasets) and changesets (typically between two RDFDataset instances associated with different versions of the same dataset archetype). These classes are further specialized into artefact-level and realization-level subclasses, following the general logic described earlier. Finally, each of them also includes a dedicated subclass of RDFDataset.

Since an RDFDataset is a void:Dataset, the full range of VoID features can be used to describe it. These include various metrics, as well as the ability to specify subsets through the void:subset property). Moreover, the MDR relies on LIME, which extends VoID with additional vocabulary for modeling specialized subsets related to linguistic content.

Figure 11 illustrates some of the possibilities enabled by combining VoID with the LIME extension, using the EuroVoc [72,73] thesaurus as an example. The complete description is available online in the void.ttl file [74]. We first observe the use of VoID to report basic metrics, such as the number of triples (4,211,719), entities (7615), distinct subjects (472,321), and distinct objects (956,233). VoID class partitions are also used to indicate the number of concept schemes (129), concepts (7486), and collections (0). Beyond a simple rdfs:label, the description includes a dcterms:title and uses dcterms:conformsTo to specify the semantic model, in this case SKOS.

The RDF dataset is linked to multiple subsets via the void:subset property. Among these, we focus on one type, lime:LexicalizationSet, a subclass of void:Dataset designed to describe the lexicalization of a reference dataset in a given natural language, using a lexicalization model and, when applicable, a separate lexicon resource. In this example, all resources in EuroVoc have German values for the rdfs:label property, with an average of 2.413 labels per resource.

4. MOD-API

The MOD-API is structured as a resource-oriented API, where each resource type (and its collections), corresponding to specific classes in the MOD ontology, is assigned a dedicated URL. These URLs can be accessed via standard GET requests using the HTTP protocol to obtain the representation of the associated resource.

Figure 12 shows the resources related to artefacts. The first represents the complete collection of artefacts, while the second corresponds to a specific artefact, expressed as a URI template parameterized by the artefact identifier in the catalog. The subpaths introduced under/distributions follow the same logic, identifying the distributions associated with the artefact referenced in the preceding part of the URL. The/distribution/latest path provides a permanent address for retrieving the latest distribution of an artefact. This distribution is special, as it is the one assumed to be accessed through the/resources subpaths, enabling the browsing of classes, properties, and other types of entities depending on the nature of the artefact.

Figure 13 illustrates similar endpoints for catalog records. The figure also shows that the API base URL (i.e., the root “/” path) returns a description of the catalog itself. Other relevant endpoints include the search-related ones, which represent a class of purpose-built resources specifically designed to model operations, in this case, search functionalities. Finally, the/doc/api endpoint can be used to access interactive documentation for the API, which also allows users to invoke and experiment with the API directly from the web browser without requiring additional tools.

The default representation format is JSON-LD [75], which is RDF disguised as a plain JSON object, thanks to a JSON-LD context providing proper mapping from JSON properties to RDF properties (along with other mapping information).

Both metadata-related and data-oriented endpoints may return a large number of resources. This can be challenging for users who are unable to manage so many results or are simply not interested in all of them. In fact, they may prefer retrieving the results in chunks, which can be processed or displayed as they arrive, thereby reducing the perceived latency.

The MOD-API addresses these problems by adopting pagination of the resource collections and search results. It achieves this using the Hydra Core Vocabulary [76].

Figure 14 illustrates the approach using a fictional/artefacts resource. The overall resource is a hydra:Collection, whose members are introduced by the member property in the Hydra vocabulary. This representation is only partial, as indicated in the view property. As users navigate through the different pages, the overall resource’s @id remains the same, while the view’s @id reflects the current page. In particular, the page number appears as a query-string parameter (e.g., ?page=3). The view object also provides links to the first, previous, next, and last pages, enabling clients to traverse the collection without manually composing URLs with the query parameter. The API additionally supports the pagesize parameter to control the number of items included on each page.

5. Adopting the MOD-API in ShowVoc

Relying on the background provided by Section 3 and Section 4, the following subsections detail the steps required to integrate the MOD-API within ShowVoc.

5.1. Comparison Between the MOD Ontology and the MDR Metadata Model

We first examined the extent of semantic discrepancies between the MOD ontology and the MDR metadata model used in ShowVoc, without attempting a full or formal alignment between the two. Instead,

Table 2. Conceptual correspondence between (classes defined in) the MOD ontology and the MDR metadata model.

MOD	MDR
mod:SemanticArtefactCatalog	dcat:Catalog
mod:SemanticArtefactCatalogRecord	dcat:CatalogRecord
mod:SemanticArtefact └ mod:Terminology, mod:Taxonomy, mod:Thesaurus	mdr:DatasetArchetype, mdr:DatasetRealization
	mdr:MutableDatasetRealization
mod:SemanticArtefactDistribution	dcat:Distribution
	mdr:RDFDataset
mod:SemanticArtefactDataService	dcat:DataService, mdr:SPARQLEndpoint
	mdr:Deployment
	mdr:DistributionScheme
	mdr:Linkset, mdr:LinksetArchetype, mdr:LinksetRealization, mdr:RDFLinkset
	mdr:Changeset, mdr:ChangesetArchetype, mdr:ChangesetRealization, mdr:RDFChangeset
mod:Analytics
mod:EngineeringMethodology
mod:Evaluation
mod:Group
mod:KnowledgeRepresentationParadigm
mod:SemanticArtefactTask

presents the results of a conceptual comparison, showing that there are indeed some discrepancies, an unsurprising outcome given the distinct contexts in which they were developed.

As a starting point, we note a straightforward correspondence between mod:SemanticArtefactCatalog, mod:SemanticArtefactCatalogRecord, and mod:SemanticArtefactDistribution and their counterparts in the MDR, which, in fact, does not subclass DCAT at all. Conversely, the correspondence for mod:SemanticArtefact is less straightforward, as the MDR introduces a finer distinction between mdr:DatasetArchetype and mdr:DatasetRealization. The reduced level of detail in MOD is likely a consequence of its foundation on DCAT 2, which, as previously noted, provides limited guidance on versioning. Moreover, the MDR includes several classes that introduce concepts not represented in the MOD ontology, such as those enabling a detailed characterization of linksets, changesets, deployments, or RDF datasets. SPARQL endpoints could, in principle, be modeled as instances of mod:SemanticArtefactDataService augmented with properties specifying that it uses the SPARQL protocol. The MOD ontology also defines additional (sub)classes that have no counterpart in the MDR. However, since these do not represent core concepts in the MOD-API or the MDR, their absence within the MDR can be accommodated by incorporating them as is when required for the description of these types of resources.

5.2. Integration Approach

The analysis conducted in the previous section indicates that a one-to-one mapping between the MDR metadata model and the MOD ontology is not feasible. Nevertheless, this does not hinder the use of the MOD-API as an additional access layer for the semantic dataset catalog managed by the MDR component within ShowVoc (see Figure 15).

Recalling that the MOD-API associates its various endpoints with specific classes of the MOD ontology, implementing this strategy merely requires the ability to retrieve the corresponding instances by issuing suitable queries against the MDR. Since the MOD ontology is intended to serve as the global schema supporting interoperability within the future EOSC, this integration approach aligns with the Global-as-View (GAV) paradigm for data integration [77]. Conversely, the Local-as-View (LAV) paradigm would have required expressing the MDR entities in terms of the MOD ontology. However, as noted earlier, this would not have allowed a complete instantiation of the MDR model, given that the MOD ontology provides a less detailed representation. Such an approach would have been necessary only if we had chosen to adopt MOD as the foundational model and then re-implement, atop this new foundation, the MDR-based native API to preserve backward compatibility with existing use cases.

5.3. Mapping the MOD Ontology onto the MDR Metadata Model

The key idea underpinning the mapping of the MOD ontology onto the MDR metadata model is to associate each mdr:DatasetArchetype with a corresponding mod:SemanticArtefact. Since the MOD-API targets Semantic Artefact Catalogs (SACs) that expose actual data rather than merely providing metadata, the mapping considers only those archetypes for which ShowVoc manages at least one locally hosted copy that is accessible to the current user (including non-logged-in users).

Figure 16 illustrates a SPARQL query that performs this task, returning one solution for each dataset archetype eligible for the mapping. It should be noted that the MOD ontology specifies certain properties for a semantic artefact, such as owl:versionIRI in the minimum metadata profile and owl:versionInfo, which the MDR represents on the current version of the dataset archetype, potentially using different properties (e.g., dcat:version instead of owl:versionInfo). For this reason, the query retrieves this information together with the dataset archetype in each solution.

To reconcile the two models, the solution is to retrieve this additional metadata from the realization linked to the archetype via the dcat:hasCurrentVersion property. In this regard, it is noteworthy that each pair consisting of an archetype and its current version—which together represent the semantic artefact—is unique at any given time. Updating the reference to a different dataset realization, cataloged as the new current version, corresponds, in MOD, to a semantic artefact updating its versioning information to reflect the latest version.

Figure 17 provides a running example used throughout this section to illustrate the mapping. As shown in the upper part of the figure, an mdr:DatasetArchetype and an mdr:DatasetRealization represent AGROVOC itself and its latest (known) version (which is unique). These entities, highlighted in green, are then combined to generate a single mod:SemanticArtefact (also highlighted in green), which synthesizes information drawn from both.

Concerning the metadata properties to be used on a semantic artefact,

Table 3. Metadata about a mod:SemanticArtefact: properties with requirement “mandatory” in the FAIRsFAIR minimum metadata profile (column “MOD”) and correspondence in the MDR (column “MDR”). Concerning the latter, we use the following convention: = indicates that the same property is used, ← indicates a different property used in the MDR, while means that the MDR does not have a corresponding property, but the same property can be used in the user-supplied metadata .

MOD	MDR
http://purl.org/dc/terms/accessRights
https://w3id.org/mod#acronym	← mdr:shortName
http://www.w3.org/ns/dcat#contactPoint
http://purl.org/dc/terms/creator
http://purl.org/dc/terms/description	=
http://purl.org/dc/terms/identifier
http://www.w3.org/ns/dcat#keyword
http://www.w3.org/ns/dcat#landingPage
http://purl.org/dc/terms/license
http://purl.org/dc/terms/rightsHolder
http://purl.org/dc/terms/subject
http://purl.org/dc/terms/title	=
http://purl.org/dc/terms/type
http://www.w3.org/2002/07/owl#versionIRI

reveals a very small overlap between the mandatory properties in the FAIRsFAIR minimum metadata profile and the MDR.

The properties dcterms:title and dcterms:description are used as they are, while the property mod:acronym, which provides the identifier of a semantic artefact within a catalog, can be mapped to mdr:shortName. The remaining properties do not have a direct counterpart in the MDR; however, the MDR can accommodate them, provided that the user has supplied values for them in the “main” graph associated with the dataset archetype in the catalog (see Section 6 for more details).

Once the correspondence between MOD and the MDR has been established for semantic artefacts, the corresponding mod:SemanticArtefactCatalogRecord is generated from the archetype’s record in the MDR. As shown in

Table 4. Metadata about a mod:SemanticArtefactCatalogRecord: properties with requirement “mandatory” in the FAIRsFAIR minimum metadata profile (column “MOD”) and correspondence in the MDR (column “MDR”). Concerning the latter, ‘=’ indicates that the same property is used.

MOD	MDR
http://purl.org/dc/terms/created	=
http://purl.org/dc/terms/modified	=

, the only mandatory properties in this case are dcterms:created and dcterms:modified, both of which are already managed by the MDR.

While the mapping of distributions appears straightforward, given that we identified a 1-to-1 correspondence between mod:SemanticArtefactDistribution and dcat:Distribution used in the MDR, a subtle discrepancy between the two models must be noted. In MOD, the same class is used to manage both multiple distribution schemes (e.g., a “core” distribution including only SKOS-XL labels and a “lod” distribution containing plain SKOS labels and other materialized redundancies) and different versions, all of which are linked to the same semantic artefact resource. By contrast, the MDR would represent the latter (i.e., different versions) as distributions belonging to distinct dataset realizations associated with the same semantic artefact as different versions. Therefore, we generated the distributions of a mod:SemanticArtefact originating from a given mdr:DatasetArchetype in the MDR by considering all archived distributions (i.e., downloadable files, represented as plain dcat:Distribution instances) reachable from the dataset archetype via the property path (dcat:hasCurrentVersion|dcat:hasVersion)/dcat:distribution.

As discussed earlier concerning semantic artefacts, some metadata describing a distribution are stored in the corresponding mdr:RDFDataset, which represents the abstract triple set and can be identified by matching the property mdr:distributionScheme. This abstract triple set, which is a type of void:Dataset, is used to represent metrics and other characteristics of a dataset’s informational content (including LIME metadata) that are independent of its specific file-level serialization. Returning to our running example in Figure 17, we note the dcat:Distribution and the corresponding mdr:RDFDataset in the MDR (highlighted in blue) that were used to generate the SKOS core distribution of version “20250702” of AGROVOC in TURTLE format. The figure also illustrates the property mapping, which follows the correspondences summarized in

Table 5. Metadata about a mod:SemanticArtefactDistribution: properties with requirement “mandatory” in the FAIRsFAIR minimum metadata profile (column “MOD”) and correspondence in the MDR (column “MDR”). Concerning the latter, we use the following convention: = indicates that the same property is used, ← indicates a different property used in the MDR.

MOD	MDR
http://www.w3.org/ns/dcat#accessURL	=
http://purl.org/dc/terms/created	=
http://purl.org/dc/terms/description	=
https://w3id.org/mod#hasRepresentationLanguage	← dcterms:conformsTo
https://w3id.org/mod#hasSyntax	← dcat:mediaType
http://purl.org/dc/terms/modified	=
http://purl.org/dc/terms/title	=

: most metadata properties are shared between the two models, with mappings required only for those describing the concrete syntax (e.g., TURTLE) and the representation language (e.g., SKOS). We also note that the minimum metadata profile requires the use of dcat:accessURL; however, this property is not appropriate for distributions that are directly downloadable, for which both the MDR and MOD rely on the dcat:downloadURL property.

As can be seen, the mandatory properties of dataset distributions (and the additional ones introduced by MOD) do not record version information or distribution schemes, resulting in the loss of important metadata. For example, MOD provides no explicit indication of which distribution(s) correspond to which version. Moreover, it is not explicitly stated which distribution corresponds to the latest version indicated on the MOD semantic artefact resource. From an operational perspective, this could be approximated by selecting the most recent distribution. A more reliable solution, however, is to use the endpoint/artefacts/{artefactID}/distributions/latest, which returns the single latest distribution.

A potential issue arises from the fact that a unique latest distribution does not accommodate multiple distributions of the same version conforming to different distribution schemes. Fortunately, this is not currently problematic, as we consider only locally deployed distributions of a dataset archetype’s current version when computing the latest distribution, and ShowVoc presently enforces the constraint of deploying only one distribution per version. This behavior is also consistent with the MOD-API, whose data-oriented endpoints are expected to serve the content of a uniquely determined latest distribution.

6. Implementation Details

ShowVoc adopts a conventional three-layer architecture: the presentation layer is implemented as a single-page application (SPA) running in the browser, whereas the business and persistence layers operate server-side within Semantic Turkey [78]. Semantic Turkey is a modular, service-oriented platform for Semantic Web applications. Beyond ShowVoc, a prominent system built on this platform is VocBench 3 [79], a collaborative platform for the development and maintenance of ontologies, thesauri, lexicons, and datasets in general.

Semantic Turkey is not restricted to semantic artefacts as defined by MOD; it can manage multiple versions of general RDF datasets, relying on different knowledge and lexicalization models. The platform includes a Metadata Registry (MDR) component, based on the corresponding metadata ontology introduced earlier. The MDR functions as the central access point from which other system components obtain metadata about both locally hosted and remotely available datasets. In line with the objectives described in [16], this metadata enables the system to effectively adapt to, present, and exploit the available information.

Semantic Turkey already supported the API-gateway approach to catalog interoperability through connectors originally devised for use within VocBench [80]. This form of process-level integration was validated in a scenario where VocBench acted as an intermediary between ShowVoc and OntoPortal [81]. Transitioning to the shared-API approach, we enhanced Semantic Turkey with a new service implementing the MOD-API. The service stubs and their domain model were generated using a code generator [82] configured with the MOD-API’s OpenAPI [83] specifications [84], and Swagger UI [85] was employed to provide interactive documentation.

Unlike MOD, which requires the use of specific descriptive metadata, the MDR is more in the spirit of DCAT, allowing any metadata vocabulary consistent with the MDR. Consequently, the availability of particular metadata properties depends on the metadata profile configured for the Semantic Turkey instance. We also introduced configuration options to support metadata adaptation. Then, for each dataset, the MDR component manages multiple graphs, whose names are generated from the dataset IRI in the catalog by appending the corresponding suffix in the following list:

•

-sys: a graph containing system-managed metadata.

•

-main: a graph containing metadata added to the dataset description, potentially using vocabularies and properties beyond those originally foreseen by the MDR.

•

-stats: a graph containing statistics computed automatically.

7. Evaluation

The MOD-API defines five compliance levels for each API endpoint, ranging from 0 to 4, with higher levels indicating better compliance:

•

Level 0: The endpoint is not implemented.

•

Level 1: The endpoint returns a response of any kind.

•

Level 2: The endpoint returns an object with the correct type according to the MOD ontology.

•

Level 3: As in Level 2, but the object returned by the endpoint includes as many relevant MOD properties as possible.

•

Level 4: As in Level 3, and the returned object additionally satisfies a minimum metadata profile, which is ultimately based on the FAIRsFAIR one.

Through code generation, our implementation can easily satisfy at least Level 1, since a stub for each endpoint is generated. The generated domain model instead facilitates achieving Level 2, as the model objects returned by an endpoint are correctly typed according to the MOD classes. This approach further facilitates reaching Level 3, because it enables the inclusion of as many MOD-defined properties as possible. For catalog records, our system consistently attains Level 4, given that the required metadata properties correspond to predefined descriptors in the MDR. As noted in Section 6, the level of compliance achievable for other endpoints depends on the specific metadata profile adopted in the Semantic Turkey instance.

Table 6. Compliance levels with the MOD-API according to manual code analysis.

Endpoint	Compliance Level
/artefacts	≥Level 3
/artefacts/{artefactID}	≥Level 3
/artefacts/{artefactID}/distributions	≥Level 3
/artefacts/{artefactID}/distributions/{distributionID}	≥Level 3
/artefacts/{artefactID}/distributions/latest/resources	≥Level 3
/artefacts/{artefactID}/record	Level 4
/artefacts/{artefactID}/resources	Level 3
/artefacts/{artefactID}/resources/{resourceID}	Level 3
/artefacts/{artefactID}/resources/classes	Level 3
/artefacts/{artefactID}/resources/concepts	Level 3
/artefacts/{artefactID}/resources/properties	Level 3
/artefacts/{artefactID}/resources/individuals	Level 3
/artefacts/{artefactID}/resources/schemes	Level 3
/artefacts/{artefactID}/resources/collection	Level 3
/artefacts/{artefactID}/resources/labels	Level 3
/	≥Level 3
/records	Level 4
/records/{artefactID}	Level 4
/search	Level 3
/search/content	Level 3
/search/metadata	≥Level 3
/doc/api	Level 1

summarizes the compliance levels achievable for each endpoint. Cells marked as “≥Level 3” indicate that the endpoint is guaranteed to reach at least Level 3, since it returns all relevant properties currently available, with the possibility of reaching Level 4 when the full set of metadata required by the minimum profile is present in the resource description managed by the MDR. Some endpoints inherently reach Level 4, as the minimum metadata profile only includes properties that the MDR always provides. Endpoints under/artefacts/{artefactID}/resources can reach at most Level 3 because MOD does not specify a minimum metadata profile for resource-level entities such as classes or properties within a semantic artefact returned by these operations. The same reasoning applies to/search and/search/content, which may also return resources defined within semantic artefacts and thus fall outside the scope of the minimum metadata profile. Finally,/doc/api only achieves Level 1, since the MOD ontology does not define a dedicated type for this resource.

Toward the end of the FAIR-IMPACT implementation action, we assessed our work using an API compliance and coverage validator, originally developed for the MOD-API implementation in OntoPortal and recommended within the initiative. The validation computed an overall score based on the five compliance levels across all service endpoints. ShowVoc achieved a score of 71%, which at the time exceeded those of other systems still under development, whose scores were 46%, 24%, 21%, and 6%.

We updated the validator to use a revised OpenAPI specification document, mainly to remove a few data-oriented endpoints that have been removed from the specifications, and we then evaluated the current ShowVoc implementation (specifying display=all& as an additional parameter). Across the 22 evaluated endpoints, the system achieved an overall score of 1670/1760 (95%).

Table 7. Detailed validation report returned by the MOD-API validator.

Endpoint	Exist (Level 1)	Good @ Type (Level2)	Properties (Level 3–4)	Valid JSON-LD	Paginated	Score
/	✓	✓	✓	✓		80
/records	✓	✓	N/A	✓	✓	80
/doc/api	✓	N/A	N/A	✗		70
/artefacts	✓	✓	✓	✓	✓	80
/search	✓	N/A	N/A	✓		80
/search/content	✓	N/A	N/A	✓		80
/search/metadata	✓	✓	✓	✓	✓	80
/records/{X}	✓	✓	N/A	✓		80
/artefacts/{X}	✓	✓	✓	✓		80
/artefacts/{X}/distributions	✓	✓	✓	✓	✓	80
/artefacts/{X}/distributions/latest	✓	✓	✓	✓		80
/artefacts/{X}/record	✓	✓	N/A	✓		80
/artefacts/{X}/resources	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/resources/classes	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/resources/concepts	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/resources/properties	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/resources/individuals	✓	N/A	N/A	✓		80
/artefacts/{X}/resources/schemes	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/resources/collections	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/resources/labels	✓	N/A	N/A	✓	✓	80
/artefacts/{X}/distributions/{Y}	✓	✓	✓	✓		80
/artefacts/{X}/resources/{Y}	✗	N/A	N/A	✗		0

details the results, reporting the score obtained for each individual endpoint, assuming a maximum possible score of 80 per endpoint. With respect to our initial assessment reported in Table 6, the only discrepancy concerns the endpoint/artefacts/{X}/resources/{Y}. Although this endpoint could theoretically achieve level 3, the dynamic testing performed by the validator revealed a limitation in the underlying REST framework: the platform is unable to correctly extract the resource URI appended to the endpoint path. This issue is in fact a known limitation of the specification, which had suggested the introduction of an alternative syntax:/artefacts/{X}/resources?resource={Y}. However, this proposal did not make its way into the specification before its finalization.

It is worth noting that the validator is based on the MOD-API’s OpenAPI specification file, yet it adopts a more permissive interpretation of it by accepting both plain property names (e.g., “title”) and prefixed ones (e.g., “dcterms:title”). Although the prefixed form was ultimately agreed upon during the finalization of the MOD-API, the plain form persisted in several implementations, including ours and OntoPortal’s. This discrepancy does not pose practical issues, as both forms are fully equivalent from the perspective of a JSON-LD client that is provided with the appropriate context within the response.

Moreover, the validator does not award additional points to systems, such as ShowVoc, that support content negotiation. This is not particularly problematic, since most systems participating in the implementation call provided only the JSON-LD representation. The other representations—possibly with the exception of the HTML one—merely correspond to alternative serializations of the same RDF triples, which can always be derived from JSON-LD and generally do not offer additional practical benefits, given that most RDF libraries are capable of handling all these serializations.

8. Discussion

As previously noted in Section 5.2, the MOD-API cannot replace the API built on the Metadata Registry that ShowVoc relies on; instead, the two will continue to operate in parallel. Nevertheless, adding this additional access layer, aligned with an emerging standard for the EOSC, enhances the interoperability of ShowVoc’s platform within this strategic infrastructure.

While Section 5.2 and Section 5.3 have already examined the conceptual discrepancies between the MOD ontology and the MDR metadata model, as well as the ways in which these can be reconciled,

Table 8. Functional comparison between the MDR and MOD.

Requirement	MDR	MOD
represent a catalog	✓	✓
versioning	version -> dataset realization	version -> distribution
SPARQL endpoint	mdr:SPARQLEndpoint as a DCAT data service exposing a given distribution	mod:SemanticArtefactDataService as a DCAT data service
SPARQL limitations	✓	✗
express dereferenciation	✓	✗
Linguistic information: lang./model/statistics	✓/✓/✓	✓/~/✗
Structure metadata: knowledge model/statistics	✓/✓	✓/✓
cover lexical resources	✓	✗
linksets	✓	✗
changesets	✓	✗

provides a high-level summary based on the requirements outlined in [16] with some revisions to improve their clarity and reflect recent evolutions. Although these requirements originate from the needs the MDR must satisfy to support complex dissemination use cases targeted by ShowVoc, this discussion also offers insights into the applicability of the MOD ontology and its API in broader contexts and may help inform future directions for their development.

Both MDR and MOD can represent a catalog based on the fundamental distinction, introduced by DCAT, between datasets and their distributions. However, MDR extends this dichotomy by making explicit the concept of a dataset realization, an intermediate construct used to represent different versions of the same dataset, modeled as a dataset archetype. This approach leverages the hierarchical versioning model introduced in DCAT 3, whose specifications do, in fact, refer to abstract datasets without assigning them a distinct class. In contrast, MOD manages both different versions and different distribution schemes simply as multiple distributions of the same semantic artefact. As previously noted, this results in a lossy representation: it is not possible to associate each distribution with the correct version, as version metadata is only expressed on the semantic artefact. Moreover, MDR treats all versions uniformly, and ShowVoc can host multiple browsable versions of a dataset. By contrast, the MOD-API currently allows browsing only the latest distribution of a semantic artefact.

Both MDR and MOD support SPARQL endpoints through specializations of the dcat:DataService class. However, the MOD-API does not treat SPARQL endpoints as first-class citizens, nor does it include them in its minimum metadata profile. MDR instead supports the representation of SPARQL endpoint limitations through the property mdr:sparqlEndpointLimitation, which links an endpoint to an instance of mdr:SPARQLEndpointLimitation, an extensible mechanism for modeling application-specific endpoint limitations.

MDR also includes a dedicated property, mdr:dereferenciationSystem, to express the dereferenciation system supported by a dataset. This property points to an instance of mdr:DereferenciationSystem, which currently includes two predefined values: mdr:standardDereferenciation (identifiers can be dereferenced via standard HTTP lookup) and mdr:noDereferenciation (identifiers cannot be dereferenced).

As previously discussed, MDR leverages LIME to represent details about available linguistic information by describing subsets typed as lime:LexicalizationSet. The description of these subsets includes natural language, lexicalization model, and various statistics. The MOD ontology allows a semantic artefact to be associated with its supported natural languages via dcterms:language, and despite lacking the notion of a lexicalization model, it defines properties on artefact distributions (mod:prefLabelProperty, mod:synonymProperty, mod:definitionProperty) to specify how to retrieve linguistic information encoded using an implicit model. MOD’s support for linguistic metrics is limited to a few properties, mainly mod:numberOfLabels (the number of labels for any resource within a semantic artefact), mod:classesWithNoLabel (the number of classes with no label associated with them), and mod:classesWithNoDefinition (the number of classes with no definition associated with them). MDR’s reliance on LIME also enables the representation of lexical resources encoded in RDF.

Both MDR and MOD represent the knowledge model through dcterms:conformsTo (on the mdr:RDFDataset) and mod:hasRepresentationLanguage (on the mod:SemanticArtefactDistribution), respectively, accompanied by various statistics. MOD additionally defines a few highly specific properties, such as mod:classesWithMoreThan25Children, which may reflect design choices inherited from the catalogs that informed its development. Conversely, MOD introduces properties such as mod:hasFormalityLevel and dedicated subclasses of mod:SemanticArtefact, which can indeed help distinguish between different types of knowledge representation systems (KOSes) created using the same underlying model—for instance, SKOS.

Finally, we observe that MDR also supports the representation of linksets and changesets through dedicated specializations of dcat:Dataset, mdr:DatasetArchetype, and mdr:DatasetRealization.

To conclude this section, we clarify that several of the limitations discussed above are, in practice, easy to overcome. Both MDR and MOD can be readily combined with additional metadata vocabularies, provided that no logical inconsistencies are introduced. For example, nothing prevents the use of selected MOD-defined properties together with MDR, and vice versa. In fact, extending MOD to bring it closer to MDR would likely require an opinionated interpretation of the model, since MOD is inherently less detailed with respect to versioning and is not explicitly aligned with the VoID vocabulary, unlike MDR.

9. Conclusions

The widespread adoption of the FAIR principles has led to the proliferation of numerous data catalogs, ranging from general-domain catalogs to highly specialized ones tailored to specific domains, communities, or even individual organizations. However, despite the availability of generic platforms for building such catalogs, significant differences persist between them, particularly in the APIs they expose and in their metadata models. These discrepancies continue to limit interoperability.

To mitigate these issues, the MOD ontology was adopted and an accompanying API was developed as foundational components of the European Open Science Cloud. Their purpose is to provide a unified framework for structuring and accessing catalogs of so-called semantic artefacts, which include ontologies, thesauri, and related resources, thereby enabling meaningful integration of data annotated with them.

Motivated by the potential benefits of these emerging standards, we participated in an open call aimed at fostering their adoption across relevant cataloging platforms. As with any standard, its real value lies in the breadth of its implementation within the community. To this end, we contributed an implementation of the MOD-API within our cataloging platform ShowVoc.

ShowVoc already relied on a sophisticated catalog managed by its MDR component based on the equally named metadata model. The MOD-API, however, could not replace ShowVoc’s MDR, which offers a richer set of features not yet supported in the MOD ontology under the lens of its API. This can be seen as a consequence of a deliberate design choice: the MOD-API focuses on a minimal common core that captures the functionalities typically shared across most catalogs, allowing systems to achieve progressively higher levels of compliance depending on their metadata profiles.

Using the current MOD-API specification as our reference, we implemented the API in ShowVoc as an additional access layer that operates alongside the existing native API while relying on the same MDR component. Our approach follows the Global-As-View (GAV) paradigm for data integration, which assumes that the MOD ontology can be mapped onto a (possibly more detailed) catalog-specific metadata model. This work is grounded in a careful interpretation of the MOD ontology, its limitations, and the extent to which it can be aligned with our MDR metadata model. The resulting approach, together with the lessons learned through the integration effort, may serve as a useful reference for other catalog providers and could also inform future developments of the MOD-API.

Finally, we provide anecdotal evidence of the relevance and impact of this work on improving interoperability among catalogs, drawing on the ITINERIS project, in which we were involved during the same period. As part of that project, we extended ShowVoc to harvest semantic datasets from 23 different catalogs, based on several heterogeneous technological platforms and APIs. This required the development of multiple dedicated connectors, following the approach described in [81]. As a proof of concept, we implemented a MOD-API connector that allowed us to retrieve semantic datasets from another instance of ShowVoc, as well as from TIB [86], NERC [87], and AgroPortal. The latter is particularly significant, as its implementation of the MOD-API is being integrated into the core OntoPortal code base, which will make it available to all OntoPortal-based catalogs, including the 11 members of the OntoPortal Alliance. This experiment highlights the potential impact of the MOD-API: with a single connector, ShowVoc would be able to interoperate not only with TIB and NERC but also with seven additional OntoPortal-based catalogs (TechnoPortal, MedPortal, EcoPortal, EarthPortal, BioPortal, BiodivPortal, and AgroPortal), reaching 9 out of the 23 catalogs considered (approximately 39%). Once the MOD-API implementation in these catalogs has stabilized and our connector has been finalized with full support for update detection, the latter could serve as a unified solution, substantially reducing the overall maintenance burden.