Correctly and completely describing the structure and semantics of data is laborious but necessary for complex domains, critical systems, or interoperability at the national and international levels where potential errors from misinterpretation of data could be costly. However, traditional data modeling processes often do not consider more complex approaches where structure and semantics may be designed separately, derived from already existing models, or composed from multiple models from diferent teams. We propose a robust framework inspired by a model-driven approach to support and ease the development and management of data specifications mapped to semantically or structurally richer models and keep them consistent through evolution.
CEUR ceur-ws.org
A data specification describes the structure and semantics of data stored within systems or used for communication between various parties. The structure determines how the data are represented, whereas semantics defines meaning and how the concepts should be interpreted. The degree of explicitness of expressing structure and semantics depends on a specific use case. In the case of small domains, the data itself can implicitly describe its structure, and the structure can describe the semantics if the person knows the domain well.
However, in complex domains where potential design flaws would be costly, the precise
description of both syntax and semantics may be essential [
Manually designing such data specifications is a laborious and error-prone task. It may require monotone work with copying names and definitions, making it easy to miss concepts or misplace texts. The designer needs to know the semantics well and be able to create all necessary parts of the data specification. The latter task can be handled by numerous tools CEUR Workshop Proceedings
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
automatically generating various documents. For the first task, numerous tools have emerged,
typically based on the model-driven approach [
However, there is little availability of tools [
The strict two-level separation of semantic and structural models is not always suficient. In
some cases, it may be beneficial to reuse existing models instead of creating them from scratch.
These are often called application profiles [
An example is DCAT-AP1. DCAT [
Because of the lack of available tools, the application profiles are manually created [
Heery and Patel [
We did not specify the type of models the application profiles work with, as the definition may be interpreted freely. For example, application profiles may extend the semantics or the structure. This leads us to another real-world use of extending a concrete structure (for example, JSON Schema) for more specific applications. See Figure 1b, where the structural model for Subjects reuses Persons.
This motivates us to design a metamodel that can describe various representations of semantic and structural models and mappings between them as they can be derived from each other in the form of application profiles and ensure consistency and change propagation if the model changes. Moreover, the mapping must be robust enough to give designers of the application 1https://joinup.ec.europa.eu/collection/semic-support-centre/solution/dcat-application-profile-data-portals-europe/ release/300 Czechia
conforms to
conforms to
shapes
Core team
concepts maps
shapes Team A Team B
shapes
for Person info reuses
(a) Data Catalog Vocabulary and its Application
Profiles for use in Czechia’s National Open Data Catalog.
(b) Subset of the study information system for
persons and school subjects management modules
with schemas for provided APIs.
profiles enough freedom they have when they follow the now common path of designing a
simple data schema in which they can do whatever they want and is not constrained by external
semantic models. We also plan to design a methodology on how these application profiles
should be properly designed as there are currently no well defined approaches [
To support our research, we will also develop an ecosystem of tools that will support designers
in creating application profiles. As a complete example, consider the following:
1. A domain expert decides to create a semantic model for their domain and derive a few
JSON Schemas from it describing data exchanged between the system. They may create a
semantic model from scratch, but they decide to use Wikidata [
Each structural model is then used to generate schemas for given formats, documentation, examples, and other artifacts. 4. Others may extend the structural models by creating their own or use them as is in other schemas.
This work is inspired by the author’s supervisor and his team’s previous research [
Some European countries are pursuing a similar goal, although more focused on developing
tools, for publishing data specifications to describe open data according to the New European
Interoperability Framework guide [
Many approaches solve the partial problem of this work. Research in model-driven
engineering [
We propose a solution inspired by a model-driven approach. Any semantic or structural model managed atomically by a single entity is a model from a model-driven standpoint. In Figure 1, all rectangles are individual models, and we also consider external models, such as one constructed in Enterprise Architect and stored in an SQL database.
Then, the problems addressed in the previous chapter can be divided into three groups. (i) Change propagation, model derivation from more general models, and model management can be addressed by a generic model-driven framework. (ii) We then build tools for deriving semantic and (iii) structural models on top of this general framework. A high-level representation of our solution is shown in Figure 2.
To generalize the idea, by model, we mean a representation of either structure, semantics, or any other representation of arbitrary data. This allows us to apply the solution to other domains that may benefit from change propagation and model derivation and are not directly related to semantic or structural models. For example, consider a model that represents OpenAPI specifications 4. Although most of the specification consists of data schemas, some operations may change in time and may be necessary to propagate changes between various specifications and other technical artifacts properly.
The aim of the generic framework is to define the metamodel of models, evolution and derivation of models. 2https://tietomallit.suomi.fi/ 3https://joinup.ec.europa.eu/collection/oslo-open-standards-linked-organisations-0/about 4https://swagger.io/specification/ g n li e d o m a m e h c S g n il e d o m c it n a m e S irc rko ene ewm G fra
Model management n o itr a e n e g t c a iftr A
To achieve that models can be extended and modified, we introduce a model derivation as seen in Figure 1. Individual models will refer to each other, creating a rooted model graph with the model of a question as the root. According to the type of reference and based on the context, the information from the referenced models will be interpreted diferently, resulting in a single aggregated model with the desired properties. This does not mean that the base model contains all the content but rather consists of another model. Depending on the situation, we may treat the base model as an aggregation, hence the full model. This would mean, we can generate, for example, a documentation of all concepts with diagrams, or just as a patch that ifxes the included model and generate only the patch documentation. The base model may overwrite, modify or delete entities from the included model in a form of patches or include only explicitly listed entities. This may be beneficial, for example, with the Wikidata model, as it is too large, and only part of it may be relevant in a given situation.
Individual types of entities that will be stored in the model depend on the model type and use, and their exact list and function are out of the scope of this paper. To briefly mention them, the semantic model will contain classes and associations; the structural model will contain objects and their properties, choices and references. If the model modifies an existing concept, it will be a patch. Other useful entities include various types of mappings, such as sameAs, or more complex ones between multiple entities.
Models can be arranged in the model graph in various ways depending of the intent of the modeler. Let us imagine a situation where we will make an application profile to a semantic model. In this case, we have two models - the original model, which may be external, and the model that patches it. The newly created concepts then need to be stored in the new model. However, it may make sense to put any bug fixes into a new model that can be later applied to the original model.
Alternatively, we may have multiple external models as a source. Then it may be helpful to create a model for potential bug fixes for each external model and then one model that aggregates all of them and provides additional entities that do not belong to any of the source models.
If there is a designated model for bug fixes, it should be possible to generate a patch to the original model or directly commit the changes if the model would support this.
Two sub-activities will be addressed regarding the evolution: model versioning and change propagation. Versioning is only possible for models created within the tools and not externally. The purpose is to keep the whole model history and allow the change propagation to be executed later, not immediately, when change occurs. Change propagation will then be handled individually within the semantic and structural models. Each change to the model will have to be made using a predefined operation. With the knowledge of the operations, it will be possible to apply this list of operations to other models or translate them to a diferent set of operations for models of other types.
For external models that are not versioned, we would have to obtain the list of operations manually. We can address this by using another model as a mirror. By comparing these models, we can infer changes that can then be propagated. In some cases, this may not be necessary. Then, if the inconsistency is found, users would have to fix it by themselves.
The individual models may serve as the output if they are in the desired format. Although we plan to introduce a native format for storing the models, users may use adapters for other formats if the given format disposes of the required functionalities. Then we call the model to be external. External models can be a common use case for representing semantic models in various formats, such as Enterprise Architect or Draw.io.
However, in most scenarios, users may want to generate artifacts from models using various generators. For example, a JSON Schema from a structural model, RDFS [21] from a semantic model, documentation, etc. From an architectural perspective, three types of generators can be distinguished.
• single model - generates artifacts from one model in a specific version. Either directly from the model or by aggregating it with all models from the model graph, • evolution - generates from a sequence of changes that are propagated from the model, for example, SQL UPDATE statements or an HTML document with a list of changes in a human-readable form, • dif - the diference between two models, such as transformation scripts that produce data that conforms to one structural model from data that conforms to the other. This, however, is the most challenging part of the project and, in many use cases, unnecessary.
The project started with the author’s master thesis, which aimed to develop a proof-of-concept
tool called Dataspecer [22] to facilitate and improve the work of creating so-called Formal
Open Standards (FOSes) [23] in the Czech Republic. FOSes are data specifications for open
data publishers and public institutions. Currently, the tool can efectively replace most of the
original manual work and is actively used for that. It generates HTML documentation of the
concepts with diagrams, JSON Schema [
A key consideration during the tool’s development was user-friendliness. It reads an external semantic model and suggests concepts that can be used to construct the schema in a graphical bullet list-like format. See Figure 3. It lets users rename keys and move properties in the tree to create schemas that fit their needs. The format is not tied to a specific technology but rather generic. Therefore it is possible to generate JSON, XML, and CSV schemas from the same structural model. Possible format-specific constructs can be added, but our proposed model is suficient for all the FOSes we are working on.
Regarding the graph model described in section 3, the three-layer architecture depicted in Figure 4 is currently embedded in Dataspecter. The user chooses the source of the external semantic model. A new, empty model is created underneath, which is used to patch changes and simultaneously, copies all concepts used in case the external semantic model is unavailable. Underneath are the individual structural models from which the tool generates the artifacts, as mentioned earlier.
(SGoV, RDFS, Wikidata)
patches semantic model shapes
Although this architecture is suficient for many cases, we would like to generalize it for other scenarios, such as instances where the user works with multiple semantic models or wants to create their own model during schema modeling.
We use the Czech Semantic Government Vocabulary (SGoV) [30] as the external semantic model. It contains concepts from Czech laws and important domains, their definitions, and relations. For example, it contains concepts about Tourist destinations that are used in FOS to prescribe a JSON structure for publishing open data about them. A typical publisher is a local city administration that needs to attract visitors by providing standardized data that various online mapping and planning services can consume. It also contains more than 40 diferent properties characterizing the barrier-free accessibility of a public place that requires a deeper understanding of the needs of people with disabilities. Hence it would be too demanding for one person to design a structure without semantics defined in advance.
We are also actively working with several students on other generators such as SHACL, sample application generator, or example data generator. We are also working on a Wikidata adapter as an external semantic model.
In addition to a schema generation tool, we want to focus on a tool that would work primarily with semantic models - load external ones, create application profiles, and publish those in diferent formats and technologies according to section 3.
In the following year (the 2nd year of the author’s Ph.D. studies), the author plans to complete all parts of the generic framework, redesign Dataspecer to support a full model graph, and coordinate the development of the semantic modeling tool. In the next year, we plan to start working on evolution and methodology based on the feedback we get. We will also optimize the developed tools for use in practice. In the last year, we want to analyze and implement mappings between diferent concepts and further work on integrating the tools into practice.
From a publishing point of view, the author wants to describe the structure of the models and how they can be applied in diferent domains, the principle of evolution, and mapping.
The primary part of the evaluation and validation will be the use of the tools, that will use the proposed metamodel, in practice. Specifically, several data experts will actively use the tool for schema generation in the context of FOSes development and management for Czechia. Evolution will also be used in long-term management, as the source semantic models continuously change. Occasionally, the semantic model creation tool will also be used to create application profiles.
The author will be actively using the semantic model management tool to manage concepts from the business analysis as he is involved in the development of a new student information system. Due to the size of the project, multiple semantic models will be created and need to be synchronized. This corresponds to Figure 1b with several semantic models and one main model containing the definition of the core concepts. Subsequently, Dataspecer will be used to create API specifications for the interfaces between the diferent modules of the system. As the system is incrementally rewritten, the semantic model will evolve. The changes will need to be documented, and API updates will need to be issued accordingly. We expect the tools to do most of the work automatically.
We also actively seek involvement in other projects, such as European Union’s SEMIC, where data specifications are being developed.
We then plan to conduct a methodological survey among users to determine whether these tools make their work more efortless than a manual approach, whether all use cases can be covered, and whether manual intervention in the model design process is still needed.
I am grateful to my advisor, doc. Mgr. Martin Nečaský, Ph.D., for his supervision of my research and to other members of our research group for valuable discussions. This research was supported by the Charles University project GAUK no. 262823 and SVV project 260 698.