Domain-Specific Data Quality Analysis Using Technology-Independent Query Templates Arno Kesper1,2*, Lukas Sebastian Hofmann2 , Markus Matoni1 , Gabriele Taentzer2 1 Verbundszentrale der GBV, Göttingen, Germany.
arXiv:2607.24151v1 [cs.DB] 27 Jul 2026
2 Philipps-Universität Marburg, Germany.
*Corresponding author(s). E-mail(s): [email protected]; Contributing authors: [email protected]; [email protected]; [email protected]; Abstract In an increasingly data-driven world, effectively working with data depends heavily on its quality. Quality analysis is a central aspect of data quality management. As data quality is typically domain- and context-specific, the definition of quality requirements is primarily the responsibility of domain experts. However, domain experts often lack the query language expertise needed to implement quality analyses. Therefore, the process of defining quality analyses results in a resourceintensive workflow that requires the involvement of technical experts, effectively excluding domain experts from independently managing data quality. To address this challenge, we present the Quality Pattern Model framework (QPM), a model-driven approach to define templates for data quality analyses that are independent of specific database technologies and application domains. QPM can eliminate the need for deep technical expertise and prevent the need for defining quality analyses several times for different database technologies. We present a proof-of-concept implementation of this approach for three database technologies: XML, RDF, and Neo4j. We evaluate the expressiveness of our approach, its applicability in the cultural heritage domain, and its usability by domain experts. For this purpose, we conducted a qualitative user study and empirically collected quality problems in a catalog. Our findings suggest that QPM matches and even exceeds the expressiveness of common database query languages. Furthermore, the results indicate that our tool enables domain experts to define template-based quality analyses independently, without requiring support of IT experts.
1
Keywords: Data Quality, Model-Driven Engineering, Generic Template, Natural Language Templates, Quality Assessment, Quality Requirements, Quality Constraints, Query Language, Database Technologies, Pattern, XML, Graph Database, RDF, Neo4j
1 Introduction In today’s data-driven world, working effectively with data depends heavily on its quality, understood as ’fitness for use’ [1]. As the amount of data continues to grow across all domains, ensuring data quality has become a fundamental challenge [1, 2]. Regular quality analyses are indispensable to maintaining high-quality data [3]. However, data quality can vary significantly, depending on the domain of interest and the context of use [4]. Data quality requirements are criteria that characterize highquality data [1, 3]. A data quality requirement can be operationalized through one or more constraints that specify measurable conditions for assessing compliance [3, 5]. As data quality is inherently domain-specific [4], domain experts with detailed knowledge of the data are primarily responsible for deriving constraints based on data quality requirements [6]. Although domain experts usually know the quality requirements for their domain-specific data, they are often unable to express them in a machine-readable form. In addition, domains such as cultural heritage comprise a variety of projects that utilize different database technologies. Although the quality requirements are often similar across several projects, they frequently need to be specified again for each database technology, as there is no overarching approach for defining domain-specific data quality that is independent of specific database technologies. Requirements are specific to each database technology, domain, and database schema. Sometimes, they must even be tailored to individual databases. This is tedious since the same quality requirements often have to be specified for several database technologies. In summary, there is no out-of-the-box solution for data quality assessment that can easily be adapted to any database technology or domain [1, 3]. Common database technologies come with the following query languages: For example, XQuery1 is used for XML [7], SQL [8] for relational databases (RDB), SPARQL2 for RDF [9], and Cypher3 for property graph databases, primarily for Neo4j4 . Thus, domain experts need to coordinate with data engineers who have the technical knowledge necessary to define quality analyses [10]. This leads to costly, time-consuming and error-prone workflows requiring intensive, precise communication about dynamic quality requirements between stakeholders. To address these challenges, our goal is to close the skill gap between domain experts and data engineers by providing a systematic approach to defining domainspecific data quality analyses. This approach is independent of specific database
1
https://www.w3.org/TR/xquery/ (2026-06-25) https://www.w3.org/TR/sparql11-query/ (2026-06-25) https://neo4j.com/docs/cypher-manual (2026-06-25) 4 https://neo4j.com/ (2026-06-25) 2 3
2
technologies so that it does not require in-depth technical expertise. In addition, quality analyses need to be defined only once so that domain experts will be able to adapt them to different database technologies. To achieve this goal, we developed a model-driven approach, the Quality Pattern Model (QPM) framework, that defines domain-specific quality analyses independent of database technology. QPM builds on the observation that many data quality analyses follow reoccurring patterns, since similar quality dimensions and data validation mechanisms recur across domains and data models [11, 12]. Quality issues can be identified by searching for constraint violations. The QPM approach starts with formulating abstract quality analyses as QPM templates. Domain experts can use these QPM templates to specify concrete quality analyses, called QPM instances, for specific database technologies and database schemas. These QPM instances are then automatically translated into specific database queries. Data analysts can use these queries to perform quality analyses on specific databases. We present the following new contributions: 1. We first examine the database technologies RDB, XML, RDF, and Neo4j. For each database technology we examine a query language that is specifically optimized for its structure and characteristics. 2. We present QPM, a model-driven approach to define domain-specific data quality analysis independent of database technologies and data formats. The proof-ofconcept implementation of QPM supports three database technologies, namely XML, RDF and Neo4j. This implementation includes an API and a web frontend to serve as a user interface for domain experts. 3. We evaluate QPM in terms of its expressiveness, applicability and usability for domain experts. The implementation was applied to four concrete databases with different database schemas and three different database technologies using research data from the cultural heritage domain. We found that this approach is widely applicable and more expressive than standard query languages. It is also easy for domain experts to use, thanks to its intuitive user interface. In an earlier paper [13], we presented the initial concept of our approach and a proof-of-concept for QPM that only supported XML technology. Since then, we have reworked the approach, extending its expressiveness, support for RDF and Neo4j data, and a UI for domain experts. The structure of the paper is as follows: We motivate our work and present a running example in Sec. 2. In Sec. 3, we compare several database technologies and their query languages. The framework QPM is described in Sec. 4. In Sec. 5, we describe our tool support for three different database technologies, namely XML, RDF, and Neo4j. In Sec. 6, we evaluate the applicability, expressiveness, and usability of our tool support. We discuss related work in Sec. 7. Finally, we conclude our paper in Sec. 8.
3
2 Quality Assessment of Cultural Heritage Data Data quality is a multifaceted concept that is typically described by a number of quality dimensions [1, 4, 14–18]. Data quality assessment can find specific quality problems in one or more data quality dimensions. Quality assessment includes quality analysis, typically implemented as queries formulated in a language matching the database technology used. For example, XQuery is used to query XML data. The development of new database technologies and the increasing prevalence of databases within and between institutions has made it common to manage multiple databases with different technologies within an institution. This requires domain experts to have expertise in different query languages. However, these experts often lack the knowledge necessary to define queries independently. Therefore, they depend on data experts to perform the necessary analyses in the query languages of the technologies used. This dependency on others can lead to complex and inefficient workflows. To avoid this, a technology-light approach is needed to support domain experts in defining quality analyses independently.
2.1 Quality Problems in Cultural Heritage Data As an example, we examine data quality analyses in the cultural heritage domain. Data is collected from several different institutions, and later integrated for harvesting. Prior to integration, the data must be analyzed for quality problems. To learn about the quality problems in description data of cultural heritage objects, we conducted six qualitative interviews and a workshop with 19 domain experts who deal with the acquisition, modeling, management and usage of various types of cultural heritage data from large institutions, such as the German Documentation Center for Cultural Heritage (DDK)5 and the German Digital Library (DDB)6 . In the context of cultural heritage, a database collects descriptive data about human-made objects, such as books, paintings, photos, and videos. We compiled a comprehensive catalog of data quality problems by systematically documenting various aspects of each problem, such as its impact on data quality, possible causes, and identification possibilities [19]. The catalog includes 73 intrinsic data quality problems; simple examples are illegal values, invalid links, imprecise data and misplaced information. The resulting catalog matches the problems described in the literature [20–25]. The catalog suggests that the majority of quality problems manifest recurring patterns. Table 1 presents simple examples of quality constraints expressed in natural language. Domain experts typically do not possess the technical skills required to define data quality analyses directly using query languages. Therefore, an approach is needed that enables domain experts to define quality constraints based on natural language. The table shows example constraints with recurring logical structures, where only a small amount of information (underlined in the examples) must be adapted for different scenarios. This observation led to the idea of providing reusable patterns that can be instantiated to constraints as needed. To illustrate this idea, we first present 5 6
https://www.uni-marburg.de/de/fotomarburg (2026-06-25) https://www.deutsche-digitale-bibliothek.de/?lang=en (2026-06-25)
4
Table 1: Below are some textual examples of specific quality constraints for a cultural heritage database that includes artists and paintings. Similar structural constraints also occur in different scenarios when only the underlined values are changed. Each painting must have an associated artist. Each artist must have a first and a last name. There should not be multiple persons with the same name, birthdate and birthplace as they are most likely duplicates. A painting must have at least one artist associated. A person has at most two biological parents. The death date of a person must be within 120 years of the birth date. The height of a painting must be between 0.01 meter and 100 meters. A date must conform to the format YYYY/MM/DD. The relationship from paintings to artists must be consistent with the relationship in the opposite direction. The identifier for each artist and painting must be unique in the database.
a concrete example. Then, we examine the query languages of common database technologies to identify recurring concepts and structures.
2.2 Running Example In the following, we will examine the first example for a quality constraint from Table 1 in more detail. The following simple quality constraint is intended to prevent one specific case of incomplete information. Listing 1: Quality constraint example from cultural heritage Every painting must have at least one associated artist . Introducing parameters allows the constraint to be abstracted from the underlying data format: Every < type > must have at least one associated < type2 >. This constraint template can be instantiated for a whole group of completeness constraints. The example constraint in Lst. 1 is an instantiation with the types “paintings” and “artists”. To find violations of this constraint in a dataset, the following search query is used. It will be automatically deduced from the given constraint. Search for < type > , that has no associated < type2 >. The query analyzes data to identify particular elements that are missing mandatory information. In this example, the query searches for an element representing a painting element that lacks artist information. To identify this type of completeness violation, 5
we can define a query that searches for all painting nodes in the database without a link to an artist node. Now, an approach is required to map such templates using natural language to different query languages. As a prerequisite, we next compare the query languages of common database technologies.
3 Database Technologies Database technologies are (semi-)structured formats for storing and managing data [26]. The interpretation of the data values is determined by the data fields present in a database and how they are linked. How this structure is implemented depends on the structural paradigm of the database technology. Each database technology has a different way of specifying relationships and querying specific values. Thus, each database technology has its own query language that fits its specific concepts. Hence, each query language has its own features and syntax. To determine which details can be abstracted, it is important to compare the database structures and query languages to identify commonalities. To our knowledge, no prior comparisons have addressed the fundamental structural design of different database technologies. Instead, existing comparisons emphasize database operations and their performance.
3.1 Comparison of Database Technologies This paper focuses on the following database technologies: relational databases, XML [7], RDF [9], and Neo4j4 . In Fig. 1 we present a general overview over the structures of these technologies using examples. Specifically, we examine how the structure is defined by comparing its components, identifying data containers, data values, and relationships. Elements are interconnected with each other by relationships, and data values are assigned to the elements. Typically, types are assigned to elements and relations to ensure data integrity and efficient querying.
(a) RDB
(b) XML
(c) RDF
(d) Neo4j
Fig. 1: Comparison of database technology structures by example, showing structure elements in blue, values in orange, and relations in green.
6
Relational Databases “A relational database (RDB) is a collection of data items organized in formally described tables from which data can be accessed or reorganized in many different ways” [27]. MySQL and Oracle Database are two of the most popular database management systems for RDBs [27]. Due to their tabular structure, RDBs require rigid schemas. This results in high consistency and high performance for searches [27]. However, if the data is incompatible with a rigid schema, namely, if the data is semistructured or unstructured, then significant performance and scalability losses occur compared to non-relational databases [28]. RDBs are based on tables, i.e., columns and rows. A column specifies the values of a certain type of data. Each row contains related values. Rows are often referred to as records or tuples, and columns are referred to as attributes or fields7 . A record functions as a structure element, and its fields contain the values. Each record is identified by a key, which can be a unique ID. A relationship between records, possibly in different tables, is expressed through key references [29]. The most commonly used query language for RDBs is the Structured Query Language (SQL) [8]. XML The Extensible Markup Language (XML) [7] defines a data format structured in a hierarchical way. XML is primarily used for data interchange and web services because it is “self-describing”, human-readable, and more concise and flexible than RDBs [30]. The structure of an XML document forms a rooted tree structured by named elements called tags. Tags can contain values as attributes or as a leaf element. XML supports two kinds of relationships: First, there are navigational relationships between elements via their relative location in the tree structure. Second, XML provides the concept of key references (keyref s) that use identifiers to point to specific nodes within the XML tree. These references are similar to the relationships in a relational database that use foreign keys [29]. Query languages for XML include XQuery, which specializes in data extraction, and XSLT8 , which specializes in data transformation. RDF Graph databases are optimized for highly interconnected data. They offer very flexible schemas and efficient handling of complex relationships, though they sacrifice scalability and performance [31]. The Resource Description Framework (RDF) [9] is a graph database technology based on triples in the subject-predicate-object format. Subjects refer to nodes, or structural elements, that are identified by Internationalized Resource Identifiers (IRIs). Objects can be either nodes or values. They are connected via predicates, which are referred to as relationships. These predicates connect nodes and values to a graph structure with values as leaf nodes. The query language for RDF data is SPARQL (SPARQL Protocol and RDF Query Language). SPARQL can query “required and optional graph patterns along with their conjunctions and disjunctions”2 . 7 8
https://docs.oracle.com/javase/tutorial/jdbc/ (2025-12-18) https://www.w3.org/TR/xslt/ (2025-12-18)
7
Neo4j Another popular technology for graph databases is Neo4j4 . A Neo4j database contains nodes as basic structure elements that are connected to each other via edges (specifying relationships). Nodes and edges can be assigned values in the form of named properties. A notable feature of this database technology is edge properties, which allow assigning values to relationships. Neo4j databases and other property graph databases are queried using the Cypher language. Although ISO is developing GQL [32] as a standardized, vendor-neutral alternative with similar syntax, limited adoption means Cypher remains the de facto standard in practice. Comparison A feature-based comparison of the database technology structures is presented in Table 2. The following features were identified: structure, structure element, data value, and relationship. Each database technology defines a structure for organizing data (values) [33]. This is accomplished using structure elements, such as columns in RDBs, tags in XML, IRIs in RDF, and nodes in Neo4j. Data values are assigned to the structure elements as properties or attributes. Neo4j also offers the option of assigning values to relationships using edge properties. However, since our approach focuses on the commonalities between different technologies, we do not consider this feature further. Table 2: Feature-based comparison of database technology structures to highlight commonalities RDB
XML
RDF
Neo4j
Structure Structure element Data value
set of tables table row (tuple)
hierarchical XML element
directed graph IRI element
directed graph node
table entry
value in tag or attribute
value element
Relationship
tuple or reference
structure navigation keyref reference
predicate
property at a node or relationship labeled relationship
keyref
or
3.2 Comparison of Query Languages Database technologies come with specific query languages appropriate for their supported data structures. Query languages allow users to define queries for data retrieval with various features. Data quality analysis is a specific form of data retrieval queries. Looking at the running example from Sec. 2.2, we reconsidered the following constraint template: Every < type > must have at least one associated < type2 >. This constraint template can be instantiated for different database technologies, using different query languages. For example, looking at a fictitious database file 8
database.xml in XML format, the constraint could be instantiated to the XQuery expression in Lst. 2. Listing 2: XML/XQuery query for the running example in Sec. 2.2 for $painting in doc(database.xml) // painting where not { some $artist in $painting / artist satisfies true() } return $painting Considering Neo4j databases, it could be instantiated to the Cypher query language in Lst. 3. This constraint can also be expressed in other query languages, such as SPARQL (for RDF) and SQL (for RDB), depending on the database technology and format. Listing 3: Neo4j/Cypher query for the running example in Sec. 2.2 match (painting:Painting) where not ( exists { match (painting)-[:created_by]-(artist:Artist) }) return painting In Table 3, we compare query features that are important for data quality analyses across the languages.
Table 3: Feature-based comparison of different query languages regarding conditional data analysis SQL
XQuery
SPARQL
Cypher
✓ tree algebra
Traversal
✓ relational algebra joins
Count Comparison RE EA NLP
✓ ✓ ✓ x x
✓ SPARQL algebra property paths ✓ ✓ ✓ x x
✓ property graph algebra pattern matching ✓ ✓ ✓ x x
FOL-Exp. Algebra
XPath ✓ ✓ ✓ x x
RE: regular expressions, FOL-Exp.: first-order logic expressiveness, EA: external access, NLP: natural language processing 9
The four considered query languages are all based on different algebras using different data traversal techniques, fitting to their supported data structures. SQL (for relational databases) is based on relational algebra using tabular joins to access different parts of the data. XQuery traverses XML data using XPath-expressions using tree algebra. SPARQL defines its own algebra using property paths. Lastly, Cypher is based on property graph algebra while relying on pattern matching for data traversal. The expressiveness of all these different algebras strictly exceeds first-order logic. Conditional data retrieval is based on defining strict conditions using operators. Key operators for data quality analysis include the count operator, e.g., for cardinality constraints, and comparison operators for matching values against fixed thresholds. To check the format (e.g., URLs, IRIs) of specific values, typically a regular expression operator is used. Each of these operator types is completely covered by all considered query languages. Further operators are required for comprehensive quality analyses. For example, values must be compared to external data, and the semantic understanding of the data must be checked using NLP techniques. These capabilities exceed those of the query languages under consideration. In summary, query languages have nearly equal expressive power regarding data retrieval.
4 Approach In our work with experts in the cultural heritage domain, we found that these experts typically have limited knowledge of database technologies. Consequently, they need the IT support from data engineers to perform domain-specific data quality analysis, which can result in time-consuming and error-prone workflows. Our analysis of popular database technologies revealed significant similarities in their query languages (Sec. 3). Furthermore, many data quality problems have similar structures (see Sec. 2). We concluded that a template-based approach to domainspecific data quality analysis is promising. With this in mind, we present the Quality Pattern Model framework (QPM). This framework allows templates to be defined generically, i.e., independently of any specific database technology. With QPM, domain experts should be able to define domainspecific data quality analysis without extensive technical knowledge. The overarching goal of QPM is to provide an accessible framework that enables domain experts to define quality analyses while reducing the necessary expertise in query languages, database technologies, and formats. Furthermore, QPM supports the specification of domain-specific data analyses in a technology-independent manner, so they need only be created once and can be instantiated across different database technologies as needed.
4.1 Workflow We propose the following workflow for the template-based generation and application of domain-specific queries. The workflow consists of three main use cases that 10
Fig. 2: Workflow for the creation and application of QPM templates
are executed by different roles. These three use cases are ’Template Creation’, ’Analysis Definition’ (based on previously defined templates) and ’Quality Analysis’ (using defined analyses). Note that these use cases are not usually executed sequentially; however, the order above indicates their causal order. E.g., the Template Creation use case only needs to be executed, if no fitting template exists yet for operationalization of a novel requirement. The workflow is visualized in Fig. 2. Use Case: Template Creation In this use case, a data engineer creates a generic QPM template. A generic QPM template specifies a reusable query logic for quality analyses tailored to a specific type of data quality constraints independent of the database technology. Quality analyses specified by an instantiated template can detect specific constraint violations and, consequently, quality problems. Comprehensive domain-specific quality analyses require identifying various types of quality problems, so a variety of generic QPM templates are necessary. New generic QPM templates need to be created by data engineers only if a novel kind of quality requirement occurs, minimizing the need for additional generic QPM templates over time. Generic QPM templates are automatically adapted to specific database technologies, such as XML, becoming technology-specific QPM templates. For this purpose, technology-specific parameters are integrated into the structure of a generic QPM template. These parameters specify the data nodes and relationships within the selected technology. The result can be stored in a QPM template library. Starting with a prebuilt library of QPM templates (e.g. [34]) can reduce initial work. To create generic QPM templates, data engineers must have a comprehensive understanding of first-order logic and data organization. In addition, they must be able to think abstractly, structurally, and analytically. 11
Use Case: Analysis Definition This use case is intended for domain experts (e.g. cultural historians) who want to identify domain-specific data quality problems without requiring technical knowledge. To specify a quality analysis, domain experts select a QPM template from the template library. The selection process requires only an informal understanding of the QPM templates. If no fitting QPM template exists, a data engineer needs to be consulted to initiate the Template Creation use case. As long as the parameters are not set, a QPM template remains independent of a specific database schema (such as an XML schema). Consequently, QPM templates cannot yet be applied to a database. Next, the domain experts specify how the QPM templates are concretized to a selected domain-specific database schema. Each parameter of the QPM template must be set, fitting the database schema to become executable. During this process, users must specify the values of all parameters as well as the metadata for the QPM template, such as its name and description. The result is a QPM instance, which represents a specific data quality constraint. A QPM instance is ready to analyze databases of a specific format by compiling database-specific queries to detect these types of quality problems. Rather than creating a new quality analysis, an existing QPM instance can be edited or duplicated. Concretizing a QPM template requires an understanding of the database schema and relevant domain knowledge. Based on the selected database schema and parameters, assisting information can be provided to minimize the required technical knowledge, such as suggesting values for specific data fields. To create a comprehensive, domain-specific quality analysis for a specific database schema, a set of QPM instances can be created and stored in a library of QPM instances. Use Case: Quality Analysis In this use case, a data analyst applies a domain-specific data quality analysis to a specific database. The data analyst specifies the database to be analyzed and selects one or more constraints, which are represented by QPM instances from the QPM instance library. The analysis searches for constraint violations, i.e. quality problems, in the data. For the analysis, QPM automatically compiles a query in a traditional query language and applies it to the selected database. The analysis result is a report of all matches of the compiled queries, i.e., a list of all constraint violations. Based on this report, a data analyst can start the data improvement process.
4.2 Concept To realize this proposed workflow, we have created a three-level modeling approach for domain-specific queries. The three levels model the dependency between database technologies, database formats and concrete quality constraints. This concept is visualized in Fig. 3. QPM provides a modeling language for defining generic QPM templates. This language can be used to create reusable query logic that can be customized and tailored to specific constraints. Specifically, the generic QPM templates represent the logic of the quality analysis to identify certain types of constraint violations (cf. Sec. 2). 12
Fig. 3: Concept structure
They abstract from the database technology and the database format (i.e. schema) and are therefore completely independent of technology-specific features. A generic QPM template is instantiated to a QPM template by adapting it to a specific database technology. infers parameters regarding the addressing of structure elements in relation to the root of an XML document. To adapt a QPM template to a specific database schema, the parameters are set to concrete values. The result is a fully parameterized QPM instance that is used to compile an analysis query in a selected query language.
4.3 Example In this section, we illustrate the approach presented above using the example presented in Sec. 2.2. To check for completeness violations, we search for all painting nodes in the database that do not have a link to an artist node. In Sec. 3.2, we presented two queries in XQuery and Cypher for this specific data quality problem. The logical structure behind these queries is similar. Both search for paintings, for which the specification of an associated artist is missing. In abstract terms, they search for nodes of a specific type under the condition that they have no relationships with nodes of another specific type. Next, we show how these queries are specified using our workflow for the technology XML. The generic QPM template in Fig. 4a specifies a suitable abstract query structure. It consists of a search for part, which specifies the query result, and an under the condition part, which formulates the condition to be checked. For this problem, a domain expert selects this generic QPM template and instantiates it for XML. The result is an XML-specific QPM template (see Fig. 4b). During the automatic adaptation process, an XML root element is added, and all nodes and relations are made XML-specific. In the next step, the domain expert adapts this XML-specific QPM template to a particular database schema. The concrete adaptation with respect to our running example is shown in Fig. 4c. This QPM instance specifies painting as the XmlElement that plays the role of a dataset, and artist as the XmlElement that plays the role of the mandatory node, as well as a suitable XmlRelation. As a result, this QPM instance searches for all nodes of type painting without an associated artist in XML data. Once the QPM instance is specified, it can then be automatically translated into the XQuery expression shown in Lst. 2.
5 Tool Support To validate the approach of QPM, we present a proof-of-concept tool implementing the workflow in Fig. 3. The multi-layer modeling approach forms the backend of a web 13
(a) Generic QPM template (b) XML-specific QPM tem- (c) XML-specific QPM plate instance for the query in Lst. 2
Fig. 4: QPM templates and instance for the running example in Sec. 2.2 application and is implemented based on the Eclipse Modeling Framework9 (EMF), a quasi-standard framework for model-driven development. The tool currently supports the database technologies XML, RDF, and Neo4j. The backend provides a RESTful web API to communicate with other components, especially the user interface. For the two main use cases of the tool, namely the definition and the application of domainspecific data quality analysis, there is a web frontend called Constrainify. The entire tool, including the Constrainify frontend, can be found on Zenodo [35] and GitLab10 . The implementation of the QPM backend is available on Zenodo [36] and GitHub11 .
5.1 Architecture Fig. 5 provides an overview of the system architecture of our application Constrainify. The core of the architecture is the Quality Pattern Model (QPM ). This component manages and stores predefined and user-defined QPM templates and QPM instances in a library. Its Pattern Metamodel defines the abstract structure and supported functionalities of the (generic) QPM templates and QPM instances. QPM also includes the Query Execution System. It is used to identify constraint violations, by executing the generated queries of QPM via established query processors (e.g. Saxon12 for XML) against the provided database. The components at the top of Fig. 5 form the frontend components of our architecture, called constrainify-core. They interact with the QPM backend exclusively through APIs to ensure loose coupling, consistency, and maintainability. The frontend is structured in three components, corresponding to the use cases in Sec. 4.1: The Template Creation System is designed as a graphical modeling workbench for defining new generic QPM templates. A concrete example is shown in Fig. 4a. All 9
https://projects.eclipse.org/projects/modeling.emf.emf (2026-06-25) https://gitlab.gwdg.de/aqinda/constrainify (2026-06-25) https://github.com/Project-KONDA/pattern-based-quality-analysis (2026-06-25) 12 https://www.saxonica.com (2026-12-18) 10 11
14
Fig. 5: System architecture of the QPM Framework
generic QPM templates can be automatically adapted to a specified database technology to become technology-specific QPM templates. See Fig. 4b for a concrete example. This graphical modeling workbench currently only exists as a rough prototype. The Analysis Definition System provides a form-based view for entering parameter values into the adapted QPM template. This results in a fully specified QPM instance. See Fig. 4c for a concrete example. The Quality Analysis System enables users to upload data and select a subset of valid QPM instances. This component uses the Query Execution System for the specified quality analysis on the uploaded data. Identified quality problems are presented to the user in an analysis report.
5.2 Quality Pattern Metamodel At the core of QPM is the metamodel that defines the abstract structure of quality analyses using a Java class structure. This metamodel implements how different (generic) QPM templates and QPM instances can be built (such as the examples in the figures 4a, 4b, and 4c). It also defines their functionalities, including adaptation to technologies, parameterization, and translation into technology-specific query languages, namely XQuery, SPARQL and Cypher. Note that the adaptation to relational databases is planned but not yet implemented. QPM Metamodel The metamodel of QPM is split across four main packages, as illustrated in Fig. 6: The patternstructure package deals with the definition of the formal logic of QPM templates. It contains the general structure, quantifiers and formulas of the quality analyses. The graphstructure package is used to specify graphs that map to specific data substructures, such as nodes and relations. The operators specified in the operators package are used to define additional conditions within QPM templates, such as regular expression matching predicates. Finally, the parameters package defines the types of parameters that enable the concretization of QPM templates to QPM instances. The packages for technology-specific adaptations are shown on the right side of Fig. 6. These packages provide the functionality to adapt the generic QPM templates to the particularities of each database technology, primarily the different database structures and navigational operators. 15
Fig. 6: Package structure of the QPM metamodel including dependencies and example classes
QPM Language The QPM metamodel defines the abstract syntax for database queries across multiple levels of abstraction. According to Kleppe [37], a domain-specific language requires an abstract syntax, a concrete syntax, and semantics. The QPM metamodel defines the abstract syntax. The concrete syntax is a graphical one as shown in e.g. Fig. 4. The semantics are given via interpretability as executable quality analyses. The QPM language is organized into multiple layers. The technology-independent core, as defined by the four packages marked as generic in Fig. 6, defines the generic QPM language. This core comprises generic, reusable data analysis templates. The technology-specific packages extend this core to form technology-specific abstract, parameterized QPM languages. By binding the parameters, fully specified QPM instances are obtained. The set of all well-formed QPM instances over a given technology forms a concrete, technology-specific QPM language.
5.3 RESTful Web API To facilitate communication with other components, especially the user interface (cf. Fig. 5), we implemented a REST API in the OpenAPI format13 . The API allows specifying QPM templates with parameters and executing the resulting queries. For this purpose, the API can manage multiple libraries of QPM templates, following the specified workflow (cf. Fig. 2). One library contains all generic QPM templates. For each supported database technology, it handles a library of technology-specific QPM templates and specified QPM instances. The libraries can be accessed with different retrieval criteria (filters and groups) to efficiently narrow down results. For the use case ’Analysis Definition’, the API supports the creation of new analyses by instantiating QPM templates. It also enables the loading, duplicating, modifying 13 https://raw.githubusercontent.com/Project-KONDA/pattern-based-quality-analysis/refs/heads/ main/qualitypatternmodel/openapi.yaml (2026-06-25)
16
and deleting of existing analyses. Editing and resetting parameter values and metadata of analyses is also possible. Metadata includes the name, description, tags and an optional mapping to specific data formats or databases. Custom metadata can also be added. For the use case ’Quality Analysis’, the API supports the selection of one or more domain-specific quality analyses from a library. These analyses can either be compiled into queries or applied directly to selected data. The analysis results, which represent identified quality problems, are returned in a structured report.
5.4 Custom Operator Extension Relying only on the expressiveness of query languages can cover a substantial amount of constraints through quality analyses. However, query languages are limited to intrinsic operators for data analysis. This does not include features such as data verification or spell checks. To enhance the expressiveness of QPM, we introduce custom operators into QPM templates based on functions written in a high-level programming language. Thus, we extend the operator package of Fig. 6 with operators using custom functions. In accordance with QPM, we have chosen Java as programming language for this tool extension. As presented in Fig. 7, the extension is based on evaluating as much of each QPM instance as possible by leveraging technology-specific query languages for predicate filtering, thereby maximizing database pushdown optimization [38]. The entire process is automated.
Fig. 7: Concept for supporting custom operators in Fig. 8: XML-specific QPM QPM by using externally programmed functions. instance checking URL validity
A quality analysis is generated from the QPM instance and evaluated to the extent that the expressiveness of the query languages allows, producing intermediate results. These intermediate results contain all possible results, accompanied by values for indicating whether each result is true. Finally, a filter is applied to the intermediate 17
results. This filter identifies the true results from the intermediate results by assessing the additional values. This process uses external functions from higher-level languages. Because the structure of the intermediate results must fit the expected filter input, they must also adhere to a defined, common structure. Thus, a specific structure is generated for the quality analysis of the QPM instance. We have proven this concept by implementing it using XQuery and Java. This allows the database query to produce intermediate results that provide a string as input to a Java method. The method must return a boolean as output. This enables quality analyses, such as searching for invalid URLs (as string) in a dataset, which goes beyond the capabilities of query languages. This concept is also useful for verifying addresses, email addresses, and ISBN numbers, as well as language and spelling checks. However, note that these features may require a network connection and external services, such as geocoding, registry lookup, and natural language processing. Next, we will present an example of how to analyze XML data by validating all source URLs of the metadata present in a painting data record. The goal is to check the validity of all URLs that substantiate the metadata of paintings in an XML dataset. Given a suitable pattern, such as the one in Fig. 8, QPM generates an intermediate result structure, an XQuery, and a filter method. When analyzing a dataset, the generated query is executed first. The query extracts all painting records from the dataset and complements each one with a list of all source URLs of the record. The query output structure combines these into a small XML structure that conforms to the specified intermediate result structure. The filter then iterates over all intermediate results and evaluates all URLs. If an invalid URL is identified, the associated painting record is flagged as a data quality problem. The identified painting records are then returned as quality problems in the quality report.
5.5 Web Frontend Constrainify While data engineers possess the skills to define templates using code, domain experts and data analysts need a user interface (UI) to be able to define and execute data quality analyses. For this we provide a web UI Constrainify [39]. Constrainify implements the frontend components Analysis Definition System and Quality Analysis System presented in Sec. 5.1. Given a set of QPM templates and QPM instances, Constrainify currently supports two of the three use cases of QPM described in Sec. 4.1. The Quality Analysis System implements the primary use case ’Quality Analysis’, where a data analyst can select one or more QPM instances, which represent predefined quality analyses to analyze a given database. This use case is complemented by the use case ’Analysis Definition’, implemented in the Quality Analysis System, where new QPM instances can be specified from QPM templates. Currently, as long as the Template Creation System is lacking, QPM also provides an extensive list of pre-defined XML-specific QPM templates [34]. Currently, Constrainify is limited to analyses for the technology XML, since XML is a common harvesting format for institutions, such as those in the cultural heritage domain. Extending Constrainify to other database technologies is left to future work. We expect this to be straightforwardly 18
Fig. 9: Use Case: Quality analysis by a data analyst
achievable. The missing support relates to modules that specify technology-specific parameters, namely paths and node types. The frontend Constrainify presents the quality analyses as constraints (see Sec. 2.2), defined by QPM templates and QPM instances. This is important because domain experts think in terms of quality requirements instead of quality problems. It allows them to focus on the expected state of the data rather than how to detect data quality problems. Use Case: Quality Analysis Fig. 9 illustrates the workflow for the primary use case of performing a quality analysis. A data analyst begins by uploading their data to the Constrainify frontend. Based on the uploaded data, the data analyst is presented with a list of available constraints that match the database technology and data model. Each constraint represents a QPM instance in the QPM backend that specifies a quality analysis. The data analyst must select at least one constraint. Once the selection has been made, Constrainify initializes a data analysis by the QPM backend. Constrainify can then present the results in the form of a quality report. This quality report shows which constraints are violated and where the violations occur in the data. The data analyst can then interpret the results and start improving their data. Fig. 13 presents an example report. Use Case: Analysis Definition The secondary use case involves a domain expert specifying a constraint for a data analysis. This workflow is represented by Fig. 10. Constrainify provides three options for specifying a new constraint in the form of a QPM instance: editing or duplicating an existing QPM instance or creating a new QPM instance based on a QPM template. When creating a constraint, Constrainify presents a list of available QPM instances to instantiate. Constrainify provides supporting features to abstract from technical details. For example, users do not need to fully understand the underlying data model. Instead, a natural language input is possible, which is automatically interpreted and mapped to technical parameters. QPM then validates the specified parameters and updates the quality analysis accordingly. An example constraint similar to the one in our running example for the Lido 1.1 data model is shown in Fig. 11. This example has 19
Fig. 10: Use Case: Analysis definition by a domain expert
Fig. 11: Screenshot of a constraint in Constrainify
Fig. 12: Screenshot of a parameterization view in Constrainify
two parameters to set, a “LIDO Record” and an “Actor”. In the parameterization view (in Fig. 12), these parameters can be specified by a domain expert using natural language. For example, the expert could use the words “person” or “painter” to search for the LIDO field with the name “actor”. Constrainify then maps the entries to the appropriate fields of the selected data format, here LIDO. 20
Fig. 13: Screenshot of a quality report in Constrainify
6 Evaluation The general goal of our model-driven approach QPM is to enable domain experts to define domain-specific data quality analyses in a technology-independent manner. This eliminates the need for database technology expertise and avoids defining quality analyses several times for different database technologies. To achieve this goal, the approach must be comprehensive to ensure its applicability in real-world scenarios and its practical usability for domain experts. Comprehensibility encompasses soundness, applicability, and expressiveness. The soundness of the implementation is guaranteed by a broad test suite of JUnit tests. Since QPM has been implemented for the database technologies XML, RDF, and Neo4j, we conducted an evaluation that demonstrates the broad applicability of QPM through real-world case studies using these technologies. We compared the expressiveness of QPM with that of the traditional query languages, namely XQuery, SPARQL, and Cypher. Furthermore, we evaluated expressiveness in terms of data quality problems collected from practice that can be addressed (cf. Sec. 2.1). Finally, to demonstrate the usability, we conducted a qualitative user study with the Constrainify frontend. This raises the following research questions: RQ1: To what extent is QPM applicable in practice? (Sec. 6.1) RQ2: How expressive is the quality analysis language of QPM? (Sec. 6.2) a) How expressive is the QPM language compared to other query languages? b) How expressive is the QPM language for data problem detection? RQ3: Given the Constrainify user interface, how usable is QPM for domain experts? (Sec. 6.3) 21
6.1 Applicability in Practice (RQ1) To demonstrate the applicability of QPM in practice, we tested two scenarios: In Sec. 6.1.1, we select an existing data quality requirement document from practice and use it as basis to define templates for data quality analysis. The result is a set of 30 generic QPM templates. We instantiated the templates accordingly to create a set of QPM instances to cover the requirements catalog. In Sec. 6.1.2, we tested the technology-independent applicability of 30 generic QPM templates, by applying them to three large collections in the three QPM-supported database technologies: XML, RDF, and Neo4j.
6.1.1 Use-case-specific Applicability Our project partner, the Deutsche Digitale Bibliothek (DDB), collects data from various institutions, including museums, media libraries, and heritage preservation organizations, and makes it available online. This delivered data mainly uses the LIDO XML format. The DDB provided us with multiple documents that outline requirements for data quality in natural language and define quality guidelines for data deliveries. These requirements were collected manually during the DDB’s continuous process of integrating data into its online portal. The requirements are specific to the LIDO14 XML format. Specifically, the documents contained requirements for delivery data15 and format-specific requirements for DDB-LIDO16 . Additionally, we received documents regarding the requirements for a minimum record17 and from the MQ project18 . We formalized the requirements from these documents into a set of 130 data quality constraints. This was done in close consultation with the DDB, resulting in some modifications and additional constraints. Nine of the constraints were identified as ’out-of-scope’ because they were formulated too abstractly to be checked computationally (e.g. ’the title must be meaningful’) or because they described constraints targeting the system rather than the data (e.g. ’the identifier must not be changeable’). Based on the resulting natural language requirements, we developed 30 QPM templates that encompass different types of data quality problems and analysis techniques. During development, we added additional QPM templates and variants to our template library and we will continue to do so. An overview over the implemented pattern templates can be found in our repository19 . While not all of these QPM templates were required to realize the constraint set, they seem useful for future applications. These 30 QPM templates were sufficient to realize 116 constraints as a set of QPM instances [40], which specify 96% of the requirements of the DDB documents. Only five constraints remained unrealized due to the absence of two features: the full 14 “Lightweight Information Describing Objects” https://icom-documentation.mini.icom.museum/ working-groups/lido/lido-overview/about-lido/what-is-lido/ (2026-06-25) 15 https://deutsche-digitale-bibliothek.atlassian.net/wiki/spaces/DFD/pages/48103977/ Anforderungen+an+die+Lieferdaten (2026-06-25) 16 https://deutsche-digitale-bibliothek.atlassian.net/wiki/spaces/DFD/pages/48104132/DDB-LIDO (2026-06-25) 17 https://www.minimaldatensatz.de/ (2026-06-25) 18 http://ddb.qa-catalogue.eu/ddb-qa-2.0/?lang=en (2026-06-25) 19 Pattern Overview https://github.com/Project-KONDA/pattern-based-quality-analysis/blob/develop/ qualitypatternmodel/src/qualitypatternmodel/newservlets/patterns/PatternOverview.xlsx (2026-06-25)
22
Table 4: Key data of real-world case studies using different database technologies with 30 generic templates
Technology Governance Database size # Generic Templates # Abstract Templates # Constraints
DDK / DDB Lido
Wikidata
Regesta Imperii
XML/XQuery institutional 700,000 records 30 30 116
RDF/SPARQL scholarly-academic 120 million entities 30 21 21
Neo4j/Cypher crowd-sourced 145,000 records 30 21 21
integration of an external service and the ability to span analyses across multiple files. We reviewed the defined QPM instances in detail with domain experts. The resulting set of QPM instances enables a comprehensive analysis of multiple real-world datasets.
6.1.2 Technology-independent Applicability Secondly, we tested the applicability of the 30 generic QPM templates created to all supported database technologies. We instantiated the generic QPM templates for three collections involving the three database technologies that QPM supports: XML, RDF, and Neo4j. To validate the technology-specific QPM templates for quality analyses, we instantiated them for the following real-world data collections. The German Documentation Center for Art History – Bildarchiv Foto Marburg20 provided us with an XML dataset in the LIDO format. This cultural heritage data is a part of the largest image archive of European art and architecture. The dataset contains over 700,000 data records of cultural heritage objects and over 47 million XML elements. Since the DDK uses the same data format as the DDB, we could apply the constraints specified in Sec. 6.1.1. For RDF, we used the public Wikidata21 database. It is the largest open, collaborative knowledge base, governed by crowdsourcing and currently contains over 120 million data items. The Neo4j use case is covered by the Neo4j graph database, which is provided by the scholarly Regesta Imperii project22 , which contains approximately 145,000 regesta numbers describing chronologically ordered historical documents. This is one of the first advancements to use a graph database for cultural heritage research. Table 4 shows the key metadata for each selected collection. These data collections are representative of applications for QPM because they differ fundamentally in terms of technology, use, and governance. Nevertheless, significant data quality problems are evident in all of them, underscoring the need for quality analysis tools. While all 30 generic templates can be adapted to XML data, only 21 of them are applicable to RDF and Neo4j data. The remaining templates rely on custom operators that are currently XML-exclusive (see Sec. 5.4). We found at least one useful instance of each template for each dataset. 20 21 22
https://www.uni-marburg.de/de/fotomarburg (2026-06-25) https://www.wikidata.org (2026-06-25) http://www.regesta-imperii.de/en/ (2026-06-25)
23
6.1.3 Answer to RQ1 We demonstrated that QPM can be used to formulate templates for conducting comprehensive, domain-specific data quality analyses. We achieved 96% of the constraints for XML data using 30 generic QPM templates. 70% of the QPM templates were adaptable to all three database technologies: XML, RDF, and Neo4j. The only limitation is the current state of implementation (see Sec. 6.1.1). Representative real-world case studies show the practical applicability of QPM for domain-specific data quality analysis.
6.2 Expressiveness (RQ2) Our model-driven approach to defining domain-specific quality analyses is based on the assumption that common database query languages, such as XQuery1 , SPARQL2 , and Cypher3 , have similar levels of expressiveness and key features. As shown in Sec. 3.1, there are many similarities between common database technologies and their respective query languages. The generic QPM templates defined with QPM can be translated into different query languages. Sec. 6.2.2 investigates the expressiveness of QPM in addressing the quality problems identified in the cultural heritage domain (see Sec. 2.1). In Sec. 6.2.1, we investigate the expressiveness of QPM in terms of the query language features that are supported, those that are feasible but will be addressed in the future, and those that are potentially feasible.
6.2.1 Expressiveness in Terms of Query Language Features (RQ2.a) In answering RQ2.a, we compare the expressiveness of QPM with that of common database query languages. We focus on XQuery, SPARQL, and Cypher because they are supported by our proof-of-concept implementation. However, we also consider other query languages, such as SQL. Language Features for Data Querying Sec. 3.2 discusses the features of query languages that are important for a comprehensive quality analysis. Table 3 shows an overview over the features across query languages. The QPM language can express first-order logic expressions using existential and universal quantifiers. All traversal operators are supported, including path expressions and property access. These operators are essential for extracting information from a database. QPM supports count operators that express cardinality constraints using subpatterns and numerical conditions. The QPM language supports logical operators and value comparators. Additionally, QPM supports type conversions to interpret values as different data types, such as numbers or timestamps, and compare them. For strings, the Contains operator checks whether a string contains a substring. There is also a Match operator that checks a string against a regular expression. A major challenge is that some analyses require a semantic understanding of the data, which goes beyond the capabilities of traditional query languages (cf. Sec. 3.2). Our extension to custom operators (see Sec. 5.4) enables the integration of further analysis techniques, 24
including Natural Language Processing (NLP) techniques as well as access to external databases and ontologies. Further Operator Categories Apart from the features mentioned in Sec. 3.2, query languages support additional operators that are not essential for data analysis. To this end, we analyzed the language documentations of query languages1,2,3 [8] and extracted some additional operator categories. For this paper, we focus on data querying, despite the fact that all of these languages also include data transformation capabilities. Currently, arithmetic operators are not supported because they are unnecessary for identifying quality issues. However, the QPM design allows for straightforward extension, which will enable future integration to support use cases such as metric calculations. Query languages implement function call operators that can be both predefined methods or custom functions. Since predefined methods are specific to query languages, QPM cannot support them universally. Furthermore, not all common query languages support custom functions. Nevertheless, we have developed a general solution for QPM that uses predicate filtering to extract parameters using query languages and execute such functions in a higher-level programming language (see Sec. 5.4). This approach enables QPM to support a wide range of custom functions, including validating external links, DOIs, IP addresses, and spelling. Our proof-of-concept implementation currently supports Java methods of the form string → boolean, an important class of custom methods for value validation. Future work includes adding more options. The result of a query is either a list of values or a list of structured elements. The QPM language supports aggregation and filtering operators for these lists. However, operators for grouping and ordering are not yet supported, since there has been no identified need for grouping quality issues. QPM queries are written so that they always require the complete set of findings. The chronological default ordering is useful for the data improvement process and eliminates the need for ordering operators. Once the analysis is finished, additional ordering and filtering can be handled at the application layer, where user-specific representations can be managed appropriately.
6.2.2 Expressiveness with Respect to the Detection of Quality Problems (RQ2.b) In Sec. 2.1, we reported on our catalog of data quality problems in the cultural heritage domain in [19]. From this catalog, we extracted categories of data quality problems, such as missing data, heterogeneity of data, and wrong data. In the following, we discuss how well QPM is able to detect these data quality problems. Table 5 lists these data quality problem categories and maps them to the query language features needed to specify quality analyses for identifying such data quality problems. Sec. 6.2.1 shows that our approach is able to analyze each problem category from this list with the current implementation. Navigating through the data and evaluating first-order logic is essential for identifying structural data patterns in the data. For filtering data, our approach provides 25
Table 5: Mapping of data quality problems from the catalog in [19] to query language features. Problem Missing Data Heterogeneity Wrong data Misspelling Inconsistency Dependency V. Redundancy Imprecision Format V.
FOL Co Cm RE EA NLP Catalog IDs from [19]
✓ ✓ ✓
✓ ✓
✓ ✓ ✓ ✓ ✓
✓
✓ ✓ ✓ ✓ ✓
✓ ✓ ✓
✓ ✓
✓ ✓
✓ ✓ ✓
✓ ✓
✓ ✓
D1, D4.2, D5, D6.7, D7.1, D7.2 D1.3, D6.8 D2, D7.3 D2.1 D2.5, D4.1 D2.5, D5 D3 D6 D2.3, D10, D11, D12
V.: violation, FOL: first-order logic, Co: count (metric), Cm: comparisons, RE: regular expressions, EA: external access, NLP: natural language processing (EA and NLP are not supported by common query languages) regular expressions and comparators. QPM also supports counting the occurrences of elements and substructures, just as traditional query languages.
6.2.3 Answer to RQ2 For pure data retrieval, QPM matches and exceeds the expressiveness of basic query languages. Our approach excels at expressing first-order logic conditions over graph structures of any complexity. All query language features that are required for identifying quality problems are supported by QPM. A comprehensive data quality analysis requires more than just the expressiveness of query languages; external access and natural language processing are also needed. QPM surpasses this level of expressiveness by supporting custom Java functions, which enables these features.
6.3 Usability (RQ3) To evaluate the usability of our approach, we conducted a qualitative usability study to explore the experiences of domain experts using our Constrainify frontend. Our study focused on the quality analysis of the supported LIDO XML format; therefore, we sought domain experts from the cultural heritage field who were familiar with the format. Using a user-centric approach adopted from Lazar et al. [41], we tasked eight domain experts to define two specific new constraints for given data and perform a corresponding data quality analysis in scenario-based exercises [42]. The domain experts were data curators from different organizations with at least one year of experience handling LIDO data. The domain experts had to define two constraints using Constrainify: One constraint was required to verify the existence of an identifier, and the other was required to verify the references of an image file. We observed task interactions and results 26
during the exercises and followed up with a structured questionnaire [43] and openended interviews. The questionnaire focused on the understandability and ease of use of Constrainify, while the interviews targeted usability and institutional fit. The participants completed the workflows for both tasks and specified correct constraints. Observations and questionnaires revealed minor hesitations when selecting QPM templates for instantiation, searching for elements, and reviewing data excerpts of identified quality problems. Usability emerged as a central theme, with participants emphasizing the modern UI and ease of use. One participant noted that “quality reports are designed very intuitively and are clearly arranged”. Rather than identifying barriers, the participants noticed two minor bugs in the UI that were resolved using our issue tracker. They also suggested multiple features, including UI improvements and the addition of new QPM templates. Key feature requests include providing hints on how to solve quality issues and advanced QPM templates using an if-then-else approach. All suggestions have been prioritized for implementation in preparation for the productive operation of our tool. The main threats to the validity of this study design [44] concern construct, conclusion, and external validity. Evaluating our own tool in a non-anonymous online setting may have introduced hypothesis guessing, evaluation apprehension, and experimenter expectancy effects. The small sample size of eight participants reduces statistical power; however, this is less of an issue in qualitative studies. The generalizability of the results is also restricted because the domain experts were selected as a homogeneous sample of only German organizations in the cultural heritage domain. Future studies should include participants from different backgrounds and domains. Additionally, a larger sample size would enable representative metrics.
6.3.1 Answer to RQ3 The user study indicates, that the tool effectively enables domain experts to define constraints and perform quality analyses. Participants were able to complete the specified workflows according to the specifications and highlighted the modern interface. Although there were some minor hesitations, no significant usability barriers were identified. The feedback mainly consisted of suggestions for enhancements rather than issues. Based on these findings, we cautiously conclude that the interface can effectively support domain experts in defining constraints and performing quality analyses.
7 Related Work We aim to develop an approach that can enable domain experts to define domainspecific data quality analyses independently of specific database technologies. This approach would eliminate the need for deep technical expertise and prevent the need for defining quality analyses several times for different database technologies. Considering related work, this goal raises the following questions: RQ4: What other generic query languages are available for querying databases? RQ5: What other template- and pattern-based approaches exist for analyzing data quality? 27
In this section, we analyze the related work to answer these questions.
7.1 Generic Query Languages Generic query languages are applicable to more than one database technology. We found two generic query languages in the literature. Ong et al. [45] note that data in NoSQL databases is typically modeled in JSON format. Therefore, they developed SQL++ [45], which is a query language designed to work with schema-optional data stored in JSON format. The syntax of SQL++ is based on SQL syntax, but it was extended to include the FROM, WHERE, GROUP BY and SELECT clauses, inspired by XQuery. The semantics of SQL++ extend the expressiveness of SQL by removing semantic constraints regarding purely relational data structures. In addition,“SQL++ semantics do not require schema or any homogeneity on the input data” [45]. GraphQ is an approach that defines a “unified intermediate representation for graph query languages”. Nie et al. [46] defined a new textual graph query language that incorporates modern English while maintaining fundamental graph structures. A dedicated compiler can translate queries from this language into established graph query languages, such as SPARQL and Cypher. In summary, although there are two query languages that show some degree of generality with respect to database technology, neither is truly generic. Both only support true subsets of common database technologies: SQL++ uses the SQL syntax only to query JSON files, and GraphQ is limited to graph query languages. In contrast, QPM is designed to support all common database technologies, focusing on XML, RDF, Neo4j, and RDB. With these, QPM covers three types of database technologies: hierarchical, graph, and relational.
7.2 Template-based Approaches We have found the following template-based approach: The Wikidata Query Service offers an approach to defining query templates using natural language for SPARQL templates23 , which can be applied to Wikidata24 . A SPARQL template is defined by providing a query and a natural language phrase containing the same variables. An example regarding paintings without an artist (creator) is presented in Fig. 14. It starts by defining the template text using variables (here ?type and ?trait). The following query defines the search logic. The Wikidata user interface provides a query helper that renders the template sentence with a drop-down menu, as shown below the query. It is possible to narrow down the options in the drop-down menu by providing additional queries per variable. However, this approach is limited to the Wikidata RDF database and can exclusively be used via their website. Furthermore, the syntax of the templates is very restricted, which leads to inefficient querying. This demonstrates the viability and practicality of template-based query specification, but only for very limited use cases. We identified no approaches in the scientific literature regarding natural language templates for query specification. 23 24
https://en.wikibooks.org/wiki/SPARQL/Templates (2026-06-25) https://query.wikidata.org (2026-06-25)
28
Fig. 14: A Wikidata SPARQL template query to find photographs without creator, https://w.wiki/GC4B.
In summary, QPM extends the template concept of the Wikidata user interface by offering support for flexible templates, multiple databases, and database technologies.
7.3 Pattern-Based Approaches for Data Quality Analysis We have found several approaches that use pattern-based analysis to detect data quality problems. In general, patterns define the structures to be searched for and serve the same function as templates in identifying constraint violations. For each pattern-based approach, we determine the level of abstraction and measure the expressiveness using the features discussed in Sec. 6.2.2. We also consider the language used to define the patterns. Regarding the levels of abstraction, we consider the three levels: “Concrete” approaches define specific queries, “abstract” approaches define query templates specific to a database technology, and “generic” approaches that additionally abstract from the technologies result in technology-independent query templates. An overview is given in Table 6. The approaches are discussed below. Both Kontokostas et al. [47] and Fürber et al. [22, 48] presented similar approaches to detect quality problems in Linked Data. These approaches are based on parameterized query templates for SPARQL and SPIN [49]. Each of these pattern-based approaches is designed for a specific database technology. These approaches have similar potential and limitations to ours. However, both approaches require abstract patterns (i.e. queries) to be written manually in SPARQL or SPIN. Thus, the queries contain more implementation details than queries in QPM. Bizer et al. [50] presented a policy framework for quality-driven information filtering in graph-based data. They only consider patterns at the concrete level. The approach is limited to propositional logic and does not support counting pattern occurrences in the data. Patterns are expressed using a custom SPARQL-based language. Bicevska et al. [51] proposed using a domain-specific language (DSL) to specify data quality requirements for specific database technologies and formats. Thus, only concrete patterns are considered. This approach differs slightly from the above in terms of the features supported. The pattern language, i.e., the DSL, is not presented in the paper. Instead, informal explanations are used to describe examples for quality specifications. The authors proposed to translate them into a query language, such as 29
Table 6: Comparison of pattern-based approaches with query languages (c.f. Sec. 3.2) and QPM Approach
Abstraction concrete
FOL Co Cm RE EA NLP Language
✓
✓
✓
✓ ✓
✓ ✓
✓ ✓
✓ ✓
SPARQL SPIN
✓
WIQA-PL
Kontokostas et al. [47] abstract (RDF) Fürber et al. [22, 48] abstract (RDF) concrete Bizer et al. [50] (Named Graphs) concrete Bicevska et al. [51] (relational)
PL
QPM
✓
generic
SQL, XQuery, SPARQL,
✓
✓
Cypher (cf. Table 3)
✓ ✓
✓
graphical DSL, SQL
✓
✓
✓
DSL
FOL: first-order logic, PL: propositional logic (< FOL), Co: count (metric), Cm: comparisons, RE: regular expressions, EA: external access, NLP: natural language processing, DSL: domain-specific language
SQL, but did not present an algorithm. To motivate their approach, Bicevska et al. discussed the use of the object constraint language (OCL) to define data quality. OCL is powerful enough to specify constraints in first-order logic and beyond. However, it is not well-suited for domain experts without good skills in object-oriented programming. In addition, OCL is fully typed, making it well-suited for structured data; however, research data is often semi-structured [52]. When comparing the expressiveness of these approaches to the query languages (cf. Sec. 3.2), we find that the approaches do not surpass the features. In fact, some approaches even have limited expressiveness compared to the base query language. They do not offer custom operators, and especially not access to external data or NLP techniques. Furthermore, all approaches are limited to one specific database technology. In summary, QPM is the only approach that supports the definition of data quality analysis at a generic level, making it highly flexible with respect to underlying database technologies. The proof-of-concept implementation of QPM already demonstrates the applicability to XML, RDF and Neo4j databases. This establishes the basis for a user-friendly representation of quality analysis at different levels of abstraction. Additionally, QPM incorporates access to external data and NLP techniques (see Sec. 5.4). In this way, QPM exceeds the expressiveness of all pattern-based approaches and query languages.
7.4 Model-Driven Approaches to Data Quality Analysis There are a few approaches to data quality analysis using model-driven engineering (MDE). In Sec. 7.3, we discussed the approach by Bicevska et al. [51], which uses a DSL to specify data quality requirements. 30
Nikiforova et al. [53] also propose an MDE approach for specifying data quality requirements. They present a two-step model, in which the requirements are first specified in terms of an informal platform-independent model (PIM) using natural language and a graphical flowchart-based diagram. Then, a platform-specific model (PSM) is created by manually translating these requirements into executable artifacts. Compared to our approach, theirs does not require any formalization at the platformindependent level, but the instantiation must be done manually. Karkouch et al. [54] propose an MDE approach to generate a customized infrastructure for data quality management. Using an Eclipse-based model editor, domain experts can specify data quality requirements. From the defined requirements, a complete database management system is automatically generated that ensures “the capture, computing and persisting or/and streaming of [data quality] information” [54]. The implementation includes the generation of a relational database in Oracle and a JavaSE application for monitoring data quality. However, this work is not suitable for our scenario because it requires an existing application before data can be collected. It is also limited to certain Oracle databases and cannot be applied retrospectively. Multi-level modeling (MLM) [55–59] also seems promising in the context of data quality analysis, as it can correctly represent the different levels of abstraction of database technologies and schemas. To the best of our knowledge, ours is the only approach that strictly models different abstraction levels using MLM for template-based quality assessment.
7.5 Summary To compare QPM with related work, we examined several lines of research. Now, we can answer the questions we raised at the beginning of this section.
7.5.1 Answer to RQ4 There are approaches to extending the expressiveness of specific database query languages to additional database technologies. However, we found no other query language as generic as QPM in terms of underlying database technologies and data models. Additionally, QPM’s extension to custom operators significantly increases its expressiveness compared to the approaches we considered.
7.5.2 Answer to RQ5 Regarding template-based approaches, we only found SPARQL templates for Wikidata, which are used to specify data queries. However, these templates are limited in functionality. There are also related pattern-based approaches; however, none of them are independent of database technology, nor do they provide effective means for domain experts to define quality analyses. These are two key problems that QPM aims to solve. 31
8 Conclusion Quality analysis is central to data management, since ensuring the quality of data is essential for its effective use. There is no general definition of data quality, as it is typically domain-specific. Domain experts are primarily responsible for defining quality requirements for their type of data. However, domain experts often lack the skills to realize domain-specific quality analyses independently and must therefore coordinate with data engineers. To empower domain experts, we present QPM, a model-driven approach to defining domain-specific data quality constraints independent of specific database technologies. This approach can eliminate the need for deep technical expertise and prevent the need for defining quality analyses several times for different database technologies. The QPM framework supports various data models and even several database technologies for data analysis. Domain experts can specify their own data quality analyses and also update them as needed. They can choose from a set of predefined QPM templates to define new domain-specific quality analyses. QPM assists domain experts in instantiating selected QPM templates to meet their domain-specific needs, so only limited technical expertise is required. This model-driven approach is realized as a proof-of-concept tool with the QPM backend that supports the database technologies XML, RDF, and Neo4j. To define and perform domain-specific data quality analyses, we added a frontend called Constrainify. Constrainify currently works with XML data and provides specific support for the LIDO and TEI data formats. We evaluated our approach in terms of applicability, expressiveness, and userfriendliness by defining domain-specific data quality analyses in the cultural heritage domain and applying them to real-world databases with up to 120 million data records. Regarding data quality analysis, our approach matches the expressiveness of common data query languages, such as XQuery, SPARQL, and Cypher. As an extension, QPM provides the facility to define custom functions using an external programming language, such as Java, for specifying advanced data quality analyses. These functions allow for data analyses that are not native to query languages. Examples include URL validation, natural language processing techniques, and access to external databases and ontologies. We evaluated the usability of our tool with domain experts, who reported that it is user-friendly and allows them to specify comprehensive quality analyses on their data. The framework is currently being integrated into real-world data processing workflows. We are collaborating with domain experts from the Head Office of the GBV Common Library Network25 (VZG) and the German Digital Library26 . Before integrating new data into these platforms, our tool ensures the quality of the data. We help these institutions analyze and improve their data by providing them with up-todate, domain-specific quality assessment techniques and tools. We are extending our
25 26
https://en.gbv.de/ (2026-06-25) https://www.deutsche-digitale-bibliothek.de (2026-06-25)
32
investigation to promising applications in other well-established collaborative platforms, with a current focus on cultural heritage domains, such as Europeana27 and the National Research Data Initiative consortia28 . In the future, we plan to expand the implementation, particularly the frontend, to support additional data formats and technologies. We will extend QPM to also support relational database technologies and JSON. Furthermore, we plan to expand to other types of data beyond cultural heritage. Thus, we aim to support other formats as well, such as the ABCD schema [60] from the biodiversity domain.
Acknowledgement This paper was written as part of two projects: KONDA29 and AQinDa30 . KONDA was funded by the German Federal Ministry of Education and Research (BMBF). AQinDa is funded by the German Research Foundation (DFG). The goal of these projects is to develop a continuous management process for improving data quality, with a focus on cultural heritage data.
References [1] Wang, R.Y., Strong, D.M.: Beyond Accuracy: What Data Quality Means to Data Consumers. Journal of Management Information Systems 12(4), 5–33 (1996) https://doi.org/10.1080/07421222.1996.11518099 [2] Manyika, J., Chui, M., Brown, B., Bughin, J., Dobbs, R., Roxburgh, C., Byers, A.H., Chui, M., Brown, B., Bughin, J., et al.: Big data: The next frontier for innovation, competition, and productivity (2011) [3] Pipino, L.L., Lee, Y.W., Wang, R.Y.: Data quality assessment. Communications of the ACM 45(4), 211–218 (2002) https://doi.org/10.1145/505248.506010 [4] Strong, D.M., Lee, Y.W., Wang, R.Y.: Data quality in context. Commun. ACM 40(5), 103–110 (1997) https://doi.org/10.1145/253769.253804 [5] Abiteboul, S., Hull, R., Vianu, V.: Foundations of Databases, (1995) [6] Pham Thi, T.T., Helfert, M.: Discovering dynamic integrity rules with a rulesbased tool for data quality analyzing. In: Proceedings of the 11th International Conference on Computer Systems and Technologies and Workshop for PhD Students in Computing on International Conference on Computer Systems and Technologies, pp. 89–94 (2010) 27
https://www.europeana.eu (2026-06-25) https://www.nfdi.de/consortia/ (2026-06-25) “Kontinuierliches Qualitätsmanagement von dynamischen Forschungsdaten zu Objekten der materiellen Kultur unter Nutzung des LIDO Standards” (KONDA, 2019-2023) https://zenodo.org/communities/ konda-project/about 30 “Agile Qualitätssicherung von Metadaten zu kulturellen Objekten im Kontext von Datenintegrationsprozessen” (AQinDa, 2023-2027) zenodo.org/communities/aqinda/about 28 29
33
[7] Bourret, R., et al.: Xml and databases (1999) [8] Date, C.J., Darwen, H.: A Guide to SQL Standard, 4th Edition. Addison-Wesley, Reading, MA, USA (1997) [9] Arenas, M., Gutierrez, C., Pérez, J.: Foundations of rdf databases. In: Reasoning Web International Summer School, pp. 158–204. Springer, Berlin, Heidelberg (2009) [10] Dormehl, J.A., Andrews, R., Kratsch, W., Röglinger, M., Wynn, M.T., Zetzsche, F.: Domain experts in the loop: Leveraging generative artificial intelligence for interactive data validation in process mining. Information Systems 140, 102715 (2026) https://doi.org/10.1016/j.is.2026.102715 [11] Fox, C., Levitin, A., Redman, T.: The notion of data and its quality dimensions. Information Processing & Management 30(1), 9–19 (1994) https://doi.org/10. 1016/0306-4573(94)90020-5 [12] Haug, A.: Understanding the differences across data quality classifications: A literature review and guidelines for future research. Industrial Management & Data Systems 121(12), 2651–2671 (2021) https://doi.org/10.1108/ IMDS-12-2020-0756 [13] Kesper, A., Wenz, V., Taentzer, G.: Detecting quality problems in research data: A model-driven approach. In: Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems. MODELS ’20, pp. 354–364. Association for Computing Machinery, New York, NY, USA (2020). https://doi.org/10.1145/3365438.3410987 [14] Matoni, M., Kesper, A., Taentzer, G.: How to Define the Quality of Data? A Feature-Based Literature Survey (2025). https://arxiv.org/abs/2504.01491 [15] Matoni, M., Kesper, A., Taentzer, G.: Quality of Descriptive Information on Cultural Heritage Objects: Definition and Empirical Evaluation (2026). https: //arxiv.org/abs/2602.21249 [16] Wand, Y., Wang, R.Y.: Anchoring data quality dimensions in ontological foundations. Communications of the ACM 39(11), 86–95 (1996) https://doi.org/10. 1145/240455.240479 [17] Batini, C., Cappiello, C., Francalanci, C., Maurino, A.: Methodologies for data quality assessment and improvement. ACM Computing Surveys 41(3), 1–52 (2009) https://doi.org/10.1145/1541880.1541883 [18] Cai, L., Zhu, Y.: The challenges of data quality and data quality assessment in the big data era. Data science journal 14, 2–2 (2015)
34
[19] Kesper, A., Matoni, M., Rössel, J., Weidling, M., Wenz, V.: Catalog of Quality Problems for Data, Data Models and Data Transformations. Zenodo (2020). https://doi.org/10.5281/zenodo.3955500 [20] Rahm, E., Do, H.H.: Data cleaning: Problems and current approaches. IEEE Data Eng. Bull. 23(4), 3–13 (2000) [21] Laranjeiro, N., Soydemir, S.N., Bernardino, J.: A survey on data quality: Classifying poor data. In: Wang, G., Tsuchiya, T., Xiang, D. (eds.) 2015 IEEE 21st Pacific Rim International Symposium on Dependable Computing (PRDC), pp. 179–188. IEEE Computer Society, Los Alamitos, CA, USA (2015). https: //doi.org/10.1109/PRDC.2015.41 [22] Fürber, C., Hepp, M.: Using SPARQL and SPIN for data quality management on the semantic web. In: Abramowicz, W., Tolksdorf, R. (eds.) Business Information Systems, 13th International Conference, BIS 2010, Berlin, Germany, May 3-5, 2010. Proceedings. Lecture Notes in Business Information Processing, vol. 47, pp. 35–46. Springer, Berlin, Germany (2010). https://doi.org/10.1007/ 978-3-642-12814-1 4 [23] Oliveira, P., Rodrigues, F., Henriques, P., Galhardas, H.: A taxonomy of data quality problems. In: 2nd Int. Workshop on Data and Information Quality, pp. 219–233 (2005) [24] Oliveira, P., Rodrigues, F., Rangel Henriques, P.: A formal definition of data quality problems. (2005) [25] Kim, W.Y., Choi, B., Hong, E.K., Kim, S., Lee, D.: A taxonomy of dirty data. Data Min. Knowl. Discov. 7(1), 81–99 (2003) https://doi.org/10.1023/A: 1021564703268 [26] Introduction to Databases, pp. 1–39. Springer, Singapore (2023). https://doi.org/ 10.1007/978-981-19-3032-4 1 . Huawei Technologies Co., Ltd. [27] Jatana, N., Puri, S., Ahuja, M., Kathuria, I., Gosain, D.: A survey and comparison of relational and non-relational database. International Journal of Engineering Research & Technology 1(6), 1–5 (2012) [28] Malik, A., Burney, A., Ahmed, F.: A comparative study of unstructured data with sql and no-sql database management systems. Journal of Computer and Communications 8(4), 59–71 (2020) [29] Kappel, G., Kapsammer, E., Retschitzegger, W.: Xml and relational database systems-a comparison of concepts. In: International Conference on Internet Computing (1), pp. 199–205 (2001) [30] Kheder, M., Rahman, C., Jamal, S.: A comparison of concepts between native
35
xml and relational database systems. Asian Journal of Natural & Applied Science 4, 49–62 (2015) [31] Lupu, E., Olteanu, A., Ionita, A.D.: Concurrent access performance comparison between relational databases and graph nosql databases for complex algorithms. Applied Sciences (2076-3417) 14(21) (2024) [32] International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC): Information technology — database languages — graph query language (gql). International Standard ISO/IEC 39075:2024, ISO/IEC (2024). Published April 2024. https://www.iso.org/standard/76120. html [33] Radoev, M.: A comparison between characteristics of nosql databases and traditional databases. Computer Science and Information Technology 5(5), 149–153 (2017) [34] Kesper, A.: Constrainify: Template Collection. Zenodo (2026). https://doi.org/ 10.5281/zenodo.20718082 [35] Matoni, M., Kesper, A.: Constrainify: Environment. Zenodo (2026). https://doi. org/10.5281/zenodo.20560540 [36] Kesper, A., Wenz, V., Hofmann, L.S., Voß, J.: Project-KONDA/pattern-basedquality-analysis: Quality Pattern Model v1.5.0. Zenodo (2026). https://doi.org/ 10.5281/zenodo.20643230 [37] Kleppe, A.: Software language engineering: creating domain-specific languages using metamodels (2008) [38] Yan, C., Lin, Y., He, Y.: Predicate pushdown for data science pipelines. Proc. ACM Manag. Data 1(2) (2023) https://doi.org/10.1145/3589281 [39] Matoni, M., Kesper, A., Hofmann, L., Király, P., Schäfer, D., Voß, J., Taentzer, G.: Constrainify: Web Application to Specify and Analyze Data Quality. Zenodo (2026). https://doi.org/10.5281/zenodo.18861823 [40] Schäfer, D., Matoni, M., Kesper, A.: Constrainify: Constraint Collections für die DDB. Zenodo (2026). https://doi.org/10.5281/zenodo.20303799 [41] Lazar, J., Feng, J., Hochheiser, H.: Research Methods in Human-Computer Interaction, 2nd Edition. Morgan Kaufmann, Cambridge, MA, USA (2017). https: //www.sciencedirect.com/science/book/9780128053904 [42] Matoni, M.: Constrainify User Study: Reference Data. Zenodo (2026). https:// doi.org/10.5281/zenodo.19856977 [43] Matoni, M.: Constrainify User Study: Questionnaire. Zenodo (2026). https://doi. 36
org/10.5281/zenodo.20400437 [44] Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A., et al.: Experimentation in Software Engineering vol. 236. Springer, Berlin, Heidelberg, Germany (2012). https://link.springer.com/book/10.1007/978-3-662-69306-3 [45] Ong, K.W., Papakonstantinou, Y., Vernoux, R.: The SQL++ semi-structured data model and query language: A capabilities survey of sql-on-hadoop, nosql and newsql databases. CoRR abs/1405.3631 (2014) https://doi.org/10.48550/ arXiv.1405.3631 [46] Nie, L., Cao, S., Shi, J., Sun, J., Tian, Q., Hou, L., Li, J., Zhai, J.: GraphQ IR: Unifying the semantic parsing of graph query languages with one intermediate representation. In: Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing, pp. 5848–5865. Association for Computational Linguistics, Abu Dhabi, United Arab Emirates (2022). https://doi.org/10.18653/ v1/2022.emnlp-main.394 [47] Kontokostas, D., Westphal, P., Auer, S., Hellmann, S., Lehmann, J., Cornelissen, R., Zaveri, A.: Test-driven evaluation of linked data quality. In: Chung, C., Broder, A.Z., Shim, K., Suel, T. (eds.) 23rd International World Wide Web Conference, WWW ’14, Seoul, Republic of Korea, April 7-11, 2014, pp. 747–758. ACM, New York, NY, USA (2014). https://doi.org/10.1145/2566486.2568002 [48] Fürber, C., Hepp, M.: Swiqa - a semantic web information quality assessment framework. In: Tuunainen, V.K., Rossi, M., Nandhakumar, J. (eds.) 19th European Conference on Information Systems, ECIS 2011, Helsinki, Finland, June 9-11, 2011, p. 76 (2011). http://aisel.aisnet.org/ecis2011/76 [49] Knublauch, H.: SPIN – SPARQL Inferencing Notation. http://spinrdf.org/ (2009) [50] Bizer, C., Cyganiak, R.: Quality-driven information filtering using the WIQA policy framework. J. Web Semant. 7(1), 1–10 (2009) https://doi.org/10.1016/j. websem.2008.02.005 [51] Oditis, I., Bicevskis, J., Bicevska, Z.: Domain-specific characteristics of data quality. In: Ganzha, M., Maciaszek, L.A., Paprzycki, M. (eds.) Proceedings of the 2017 Federated Conference on Computer Science and Information Systems, FedCSIS 2017, Prague, Czech Republic, September 3-6, 2017. Annals of Computer Science and Information Systems, vol. 11, pp. 999–1003 (2017). https: //doi.org/10.15439/2017F279 [52] Abiteboul, S.: Querying semi-structured data. In: Afrati, F.N., Kolaitis, P.G. (eds.) Database Theory - ICDT ’97, 6th International Conference, Delphi, Greece, January 8-10, 1997, Proceedings. Lecture Notes in Computer Science, vol. 1186, pp. 1–18. Springer, Berlin, Germany (1997). https://doi.org/10.1007/
37
3-540-62222-5 33 [53] Nikiforova, A., Bicevskis, J., Bicevska, Z., Oditis, I.: User-oriented approach to data quality evaluation. J. Univers. Comput. Sci. 26(1), 107–126 (2020) [54] Karkouch, A., Mousannif, H., Al Moatassime, H., Noel, T.: A model-driven framework for data quality management in the internet of things. Journal of Ambient Intelligence and Humanized Computing 9(4), 977–998 (2018) https: //doi.org/10.1007/s12652-017-0498-0 [55] Jácome, S., Lara, J.: Totem: Reconciling multi-level modelling with standard two-level modelling. Computer Standards and Interfaces 69, 103390 (2019) https: //doi.org/10.1016/j.csi.2019.103390 [56] Igamberdiev, M., Grossmann, G., Selway, M., Stumptner, M.: An integrated multi-level modeling approach for industrial-scale data interoperability. Software & Systems Modeling 17(1), 269–294 (2018) https://doi.org/10.1007/ s10270-016-0520-6 [57] Lara, J., Guerra, E., Cobos, R., Moreno-Llorena, J.: Extending deep metamodelling for practical model-driven engineering. The Computer Journal 57(1), 36–58 (2012) https://doi.org/10.1093/comjnl/bxs144 [58] Lara, J.D., Guerra, E., Cuadrado, J.S.: When and how to use multilevel modelling. ACM Trans. Softw. Eng. Methodol. 24(2) (2014) https://doi.org/10.1145/ 2685615 [59] Balaban, M., Khitron, I., Kifer, M., Maraee, A.: Formal executable theory of multilevel modeling. In: Krogstie, J., Reijers, H.A. (eds.) Advanced Information Systems Engineering, pp. 391–406. Springer, Cham, Switzerland (2018) [60] Biological Collections Data Task Group, A.: Access to biological collection data (abcd). Technical report, Biodiversity Information Standards (TDWG) (2005). TDWG Standard. http://www.tdwg.org/standards/115
38