Automatic Generation of NGSI-LD Data Models from RDF Ontologies: Developmental Studies of Children and Adolescents Use Case

Abstract

In the era of ever-greater data production and collection, public health research is often limited by the scarcity of data. To improve this, we propose data sharing in the form of Data Spaces, which provide technical, business, and legal conditions for an easier and trustworthy data exchange for all the participants. The data must be described in a commonly understandable way, which can be assured by machine-readable ontologies. We compared the semantic interoperability technologies used in the European Data Spaces initiatives and adopted them in our use case of physical development in children and youth. We propose an ontology describing data from the Analysis of Children’s Development in Slovenia (ACDSi) study in the Resource Description Framework (RDF) format and a corresponding Next Generation Systems Interface-Linked Data (NGSI-LD) data model. For this purpose, we have developed a tool to generate an NGSI-LD data model using information from an ontology in RDF format. The tool builds on the declaration from the standard that the NGSI-LD information model follows the graph structure of RDF, so that such translation is feasible. The source RDF ontology is analyzed using the standardized SPARQL Protocol and RDF Query Language (SPARQL), specifically using Property Path queries. The NGSI-LD data model is generated from the definitions collected in the analysis. The translation has been verified on Smart Applications REFerence (SAREF) ontology SAREF4BLDG and its corresponding Smart Data Models (52 models at the time). The generated artifacts have been tested on a Context Broker reference implementation. The tool supports basic ontology structures, and for it to translate more complex structures, further development is needed.

1. Introduction

Several countries collect data about physical development in children and youth [1,2], including the Analysis of Children’s Development in Slovenia (ACDSi) study [3,4]. Studies in this field from the pre-big data era describe problems arising from the scarcity of data needed to conduct such research [5,6]. Nowadays, the same problem remains, at least with data from high-quality and representative surveys. These data are sensitive, and public sharing is limited. Researchers are generally entitled to the procurement of such data, but problems with technical incompatibility may hinder their usage.

To overcome these obstacles, we propose a solution initially developed in the manufacturing industry, where various stakeholders decided to organize a regime of sharing their data, which would guarantee the rights of all involved entities, called Sovereign Data Sharing [7]. It has since been promoted by European institutions all over Europe and worldwide. It has been implemented in other branches of human activity, such as transportation, logistics, mobility, tourism, etc., and is intended to be used among different branches. It is embodied in Data Spaces [8,9]. This approach breaks “data silos” where data are constrained inside a single organization or a single branch. On the other hand, many existing data exchanges operate bilaterally, which, however, do not scale well, so novel approaches to multilateral associations of stakeholders are needed [10]. The technical, organizational, legal, and ethical aspects of data sharing are being addressed to overcome obstacles to data sharing [11]. Though the final goal is to have a single European Data Space, current steps are still made at the sectoral level. The ACDSi data could, based on the fact that they describe the developmental status of young people and are therefore personal data, be shared inside the European Health Data Space [12]. Therefore, they would benefit from the same governance, protection, and support as other, predominantly medical data.

In this work, we are interested in one of the technical aspects of Data Spaces, which is called semantic interoperability. To achieve this goal, all the needed standards and technologies already exist. Therefore, the novelty of the Data Spaces approach is in the combination of means necessary to solve all the technical problems that may hinder efficient data sharing. The adoption process (e.g., selection of standards, protocols, and tools) runs in parallel on the standardization level in formal bodies (e.g., in standardization institutes, like European Telecommunications Standardization Institute (ETSI)) and on the informal level, which means intense inclusion and well-steered collaboration of scientific, developer, and user communities. The output of this process is specifications of the necessary tools and procedures. The reference implementations of the tools are the software components, which cover the needs that have been identified in the specification phase and include at least the minimal required capabilities. They are being developed under open-source licenses to lower the barrier to acquiring the technologies. These implementations are often mature enough to be used in production, at least in less demanding environments (e.g., participants with small quantities of data). If needed, they can be adapted to the specific needs due to the openness of their source code.

To leverage the potential of the data, Europe has initiated a process of enabling participants to share their data in a trustworthy manner. This will encourage those entities in possession of the data (data providers), who are hesitant to share it due to concerns of giving away trade secrets or other sensitive information, to offer the data for the common good, benefiting them on one side and the consumers of the data on the other side, and also society as a whole. Data providers must know that data will be used in accordance with the conditions they set in advance and that all the relevant regulations will be respected. Data consumers, on the other hand, must be assured that the data came from valid sources and its contents are trustworthy. This is also needed in our use case and in public health data in general. The data in these cases come from physical persons and is protected by important European and national legislation that both data providers and data consumers must abide by.

The trust is assured by providing common guidelines and trustworthy technical means for executing the data exchange. These guidelines and technical means will allow for automatic compliance with the conditions of data usage proscribed by the data provider without manual intervention. Such tools need to be certified as compliant with the Data Spaces specifications. Recently, two major European associations have undertaken to define the necessary specifications, and these will be briefly presented in this work. The first is the International Data Spaces Association (IDSA) [13] specification with the IDS Rulebook [14] and IDS Reference Architecture Model (IDS RAM) [15,16]. The second is the FIWARE [17] specification with the Generic Enablers for Data Spaces, combined with iSHARE security components [18,19]. These definitions currently have limitations as they were meant to demonstrate participants’ ability, initially in limited numbers, to share data. They have been later included in a definition process of the GAIA-X initiative [20], which currently works to adapt them into a broader infrastructure suitable for large-scale cloud deployments. Both associations are now, along with the GAIA-X initiative and the Big Data Value Association (BDVA) [21], founding members of the Data Spaces Business Alliance (DSBA), which steers these efforts further in a more strictly organized manner [22].

The central components of IDSA and FIWARE associations are the IDS Connector for the former, and the FIWARE Context Broker for the latter. They offer similar features, but each may be more suitable for some use cases than others. In this work, we use Context Broker to verify the generated artifacts, as will be presented in later sections.

Currently, the Data Spaces components are in the early development stages and typically require expert knowledge to install and configure properly. To attract a wider audience to participate in data exchange through Data Spaces (e.g., Small and Medium Enterprises), the usability of these tools will need to be improved so that installation and configuration would only be as demanding as in an ordinary office application.

Other than the technologies that enable machines to communicate and transport the data between them, it is necessary for them and for people to have a common understanding of the data that is being shared. To achieve this, data models are being developed, which organize the data about real-world entities, encompassing as many facets of the real-world entity as possible or necessary. Like the software used in the data-sharing process, the data models are published openly.

A broader and more conceptual notion than data models are ontologies that are used to describe knowledge in terms of concepts and relations among them, and are often defined within a particular field of knowledge. Interesting efforts have been made to enable interoperability at the ontology level by formalizing the ontology-building process with a common set of principles and basic or reference ontologies as foundations. In the biosciences domain, the Open Biological and Biomedical Ontologies (OBO) Foundry has been developed [23]. Another well-known foundation is Dublin Core [24].

The main goal of this work is to present an automatic creation of a Next Generation Systems Interface-Linked Data (NGSI-LD) data model from an existing Resource Description Framework (RDF) ontology. As no tool capable of authoring an NGSI-LD data model from scratch is known to us, and a manual process is always error prone, we decided to use a tool (Protégé) to create an RDF ontology and then perform an automatic generation of an NGSI-LD data model. Another motivation for our work is that many data models exist in the form of RDF ontologies that are not yet translated to the NGSI-LD format. This is due to the fact that the NGSI-LD specification is relatively new compared to the RDF [25]. This also currently makes a reversed translation less necessary, which could possibly change in the future. As the NGSI-LD property graph is more expressive than the RDF graph, the translation from NGSI-LD to RDF would mean constructing a more complex graph to avoid the loss of information [25,26].

The rest of the article is structured as follows: The Section 2 gives an overview of technologies involved in our work and of similar approaches concerning the translations and mappings between RDF and NGSI-LD concepts. In the Section 3, we describe the necessary tools used in our work and the algorithm structure that has been developed. In the Section 4, we demonstrate the products developed and the final result of published fictitious data. In the Section 5, we present the current study’s limitations and envision possible directions for future work. The Section 6 summarizes our contributions.

2. Related Work

Both the IDSA and FIWARE architectures extend the access control mechanisms from the internal information systems inside organizations onto the World Wide Web scale. Data providers can define usage policies (simple or complex rules) that data consumers must follow. If agreed upon by both parties, the technologies involved in these architectures will enforce these policies on data usage without human intervention. Usage policies consist of usual access rights and more complex use cases (e.g., time limiting of the use, an obligation to delete data after use, logging, or notifying about data use, etc.) [27]. Some policies are, at present, only executable on a contractual and juridical level as technical enforcement is not mature enough, or a combination of both measures is needed.

The technical enforcement of the policies is implemented as the capacity of the IDS Connector component to run a Data App—a certified application that can perform predefined operations on the data received from the Data Provider—inside the Data Consumer’s IDS Connector. Using this technique, it is possible to guarantee that unprocessed data never leaves the internal storage of the IDS Connector.

It has been shown that the Context Broker could play the role of a Data App in the data exchange managed by IDS Connectors. IDS Connectors on both sides of the data exchange would provide the necessary protection, whereas the Context Broker would guarantee the semantic interoperability capabilities [18]. The original approach has been completed with a more scalable execution environment and additional security components [28]. A prototype combining IDS-compliant and FIWARE-provided components in the data exchange infrastructure has been developed by the Engineering Ingegneria Informatica [29] and demonstrated in a Horizon 2020 project, PLATOON [30].

However, despite the protection of the IDS Connector, the data may still be vulnerable to so-called “Side Channel Attacks,” where the attacker can infer the protected data contents from specially crafted interactions with the computer components. A possible solution to this problem is the Trusted Hardware Enclave inside the main processing unit that only the predefined process could access; in our case, the IDS Connector. However, it has been shown that even this solution can be exploited by side-channel attacks. So, a cryptographic method called Oblivious Computing has been proposed to overcome this potential data exposure [31,32].

Enhancing the basic flow of data from the Data Provider to one or more Data Consumers, further ways of data exploitation are envisioned: Federated Learning, Secure Multi-Party Computation, and privacy-preserving techniques (homomorphic encryption, etc.) [33]. These techniques build upon the principle that the data does not need to leave the Data Provider to be analyzed. Instead, if there are multiple Data Providers, the algorithm is trained on each Data Provider’s part of the data inside their infrastructure and then adjusted from learning on data from other Data Providers. Some algorithms can be decoupled to perform selected steps (preferably the first and the last) inside the Data Provider infrastructure. This approach is called Split Learning. According to the IDS architecture, these algorithms, or parts of them, are built as Data Apps [34].

Data sharing principles of Data Spaces can also be implemented in scenarios where no specific data usage limitation is needed, like in publishing open data. Technologies otherwise used to protect and enforce the data usage policies can still be used. Still, the only policy enforced would be the simplest one—everybody can access the data without limitations. This way, the security measures built into the technological components can protect the Data Space from malicious data alteration or deletion. Other infrastructure features, such as federated computing and Data Apps, in general, can also be utilized.

In the World Wide Web domain, the Semantic Web emerged [35]. It aims to specify additional notation elements in HTML for the machines to infer the semantics of data and their relationships (linked data) from the web pages themselves. Several well-known components have been developed that support this concept. The eXtensible Markup Language (XML) has been defined earlier and allows for the definition of custom tags that can supplement additional meaning to the document contents [36].

RDF is a model used to represent the contents by encoding it into statement-like structures (subject-predicate-object) called triples [37]. This allows for any software to discern a meaning regardless of the particular data model that the software is based on. RDF triples (consisting of a subject, a predicate, and an object) are used to express an ontology as a set of statements that describe a given subject and relationships among its inner concepts. RDF can represent a graph structure where subjects and objects represent nodes in a graph, and the predicates represent directed links among nodes. Such a structure is called an RDF graph. RDF Schema (RDFS) is an extension to RDF for describing classes and their relations, and serves as a language to express data models [38]. Web Ontology Language (OWL) is a language for defining and instantiating Web ontologies and is more comprehensive than RDFS in expressing relations among classes and their other characteristics [39]. SPARQL is a query language for searching through the semantic web or databases containing triples [40]. Besides XML as the initial RDF serialization format, the JavaScript Object Notation-Linked Data (JSON-LD) [41] serialization has been developed, providing a more concise serialization of objects and their relationships compared to XML.

In order to facilitate finding particular data on the World Wide Web, special websites emerged that list available data and the associated metadata, called data catalogs. Several tools exist to define data catalogs. CKAN is a tool used to publish open-access data, predominantly by public institutions [42]. It allows for uploading or linking to datasets, which can then be consumed by downloading the file from the CKAN server or from the provided link. Using the DataStore extension, uploading the dataset to a relational database connected to the CKAN server is also possible. This extension allows the user to define a data dictionary describing individual data elements (e.g., columns in a table), which could be regarded as a data model. The data dictionary is also the control mechanism because new data can only be ingested if compliant with this dictionary. However, this extension is not mandatory. The Data Catalog Vocabulary (DCAT) is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web [43]. It provides RDF classes and properties to allow datasets and data services to be described and included in a catalog. However, it defines the metadata to the level of datasets only; the individual data points (features) are not covered.

In the Telecommunications and Internet of Things domain, the research in context management (automatic alignment of data about the same subject from different sources) led to the standardization of Next Generation Systems Interface (NGSI) by Open Mobile Alliance and, in newer versions (extended with linked data capability, hence NGSI-LD), by ETSI and its Context Information Management (CIM) committee [44]. The FIWARE Foundation led the development of NGSI-LD under the European Commission’s support. It is now used in several projects and specifications (Connected Europe Facility, Living-in.eu project, IoT Big Data Framework Architecture by GSM Association, etc.). It has been proposed for use in the GAIA-X initiative [45]. The NGSI-LD API uses JSON-LD as a main serialization format, so the NGSI-LD data payloads are serialized as JSON-LD [46].

The ETSI standard GS CIM 006 defines the NGSI-LD information model as a graph similar to an RDF graph, with a practical difference that in NGSI-LD, not only the entities (vertices) but also the relationships (edges, arcs) can have properties, which means that an RDF graph can be translated to an NGSI-LD one [26].

The use of data models differs in the presented technologies. In the IDSA case, the data model is optional at the time of data provisioning, and a special component to host the model (called Vocabulary Provider) is needed [16]. In the FIWARE case, the data model is mandatory and has to be known in advance. The central component (Context Broker) needs the data model in advance, before the data contents are provided, so the Context Broker ensures that the data provided conform to the data model. Both the data and the model are structured according to the NGSI-LD standard and they are hosted in the Context Broker, so no additional component is needed [47]. In both the IDSA and the FIWARE cases, the model has to be known at the time of data consumption.

To better support the use of the NGSI standard, FIWARE, and TM Forum have established, together with the Indian Urban Data Exchange (IUDX) and Open and Agile Smart Cities (OASC), the Smart Data Models initiative [48], which aims to engage the community to develop and publish data models emanating from real use cases of data exchange. The process is agile and open and based on established standards.

Loebe [49] proposes a fundamental set of elements sufficient to express any ontology, consisting of categories and relations. NGSI-LD defines a similar concept framework where entities (acting as categories) have elementary properties describing them and properties describing relations with other entities.

Data models are a constituent part of Digital Twins (DT), which are comprehensive digital models of (physical or intangible) real-world objects. They add the real-time data to the data model, and so are an accurate digital representation of their physical or otherwise existing counterpart—the entity they describe. They were initially developed in the manufacturing industry to represent the products and the whole manufacturing process [50]. The DT comprises both the real-world object’s structure and the data describing its state in the real or near-real time. This allows for an analysis of the real-world object’s current state and simulation and prediction of its future state. ETSI advocates the use of NGSI-LD property graphs as holistic Digital Twins [51]. They propose several use cases where the NGSI-LD specification is mature enough for use in DTs and provide recommendations for further NGSI-LD specification evolution. Recent research is demonstrating the feasibility of building complex DTs using the NGSI-LD specification [52].

In recent years, a major breakthrough in the field of Artificial Intelligence has been achieved with the development of Large Language Models (LLMs) that are very successful at understanding and following instructions, performing various linguistic tasks (translation, summarization, paraphrasing, etc.), assisting developers with programming, and many others. However, they struggle with performing complex reasoning tasks and with the continuous improvement of their knowledge, among other problems. The current research proposes agentic systems to alleviate these problems. Among others, an Ontology Matching agentic system has been proposed [53]. An important type of agents are memory agents that can manage the knowledge retained from the history of performed tasks and also the information obtained during these tasks from outside of these systems, called external knowledge [54]. An important source of external knowledge can be DT [55] and we are confident that also information about our use case could be exploited in such agentic systems as external knowledge through the data models that we propose.

Similarly to our work, an ontology creation and mapping process to the NGSI-LD data model is presented in [56], yet there is no detailed explanation of the mapping technique, presumably it has been performed manually. An ontology matching tool using Machine Learning that translates the information on sensor data to an NGSI-LD data model has been proposed [57]. However, this process expects existing NGSI-LD data models in advance.

In the following literature, there are propositions of translations of the data. In our work, we are translating data models, however.

There exists already a tool, similar to our proposal: SDMX to JSON-LD Parser [58]. However, it is only capable of translating the data models compliant with the STAT-DCAT-AP 1.0.1 specification. Consequently, it is not applicable to our case. Our approach also makes use of the SPARQL Property Path queries, whereas their tool uses a different algorithm.

A mapping protocol between the oneM2M resource data and NGSI-LD interfaces has been proposed in [59]. The oneM2M resource data can be represented in RDF triples according to the oneM2M specification. This protocol enriches them with a proposed hierarchical structure inherent to oneM2M specification and still requires a human expert to do the mapping of non-semantic data to NGSI-LD, with a limited algorithmic support, including SPARQL.

The reversed principle of translating the NGSI-LD compliant data to RDF format by means of a graph database is studied in [25,60], but with a goal to represent the data contents in a format that could be semantically verified using existing tools. The translation from NGSI-LD data into the CKAN format, and additionally, to DCAT-AP format, is proposed in [61].

An interesting proposal is published stating that it would be feasible to implement an NGSI-LD broker as an interface over the SPARQL Event Processing Architecture (SEPA), which in turn stores the data in an RDF graph store [62]. Here, the translation goes both ways: from NGSI-LD to SPARQL when storing/updating the data and from SPARQL to NGSI-LD when retrieving the data.

3. Materials and Methods

The set of tools used in this work consists of commonly used software systems and applications. The source ontology was developed in the Protégé tool, version 5.6.3 [63]. Next, the translation tool was developed in Python, version 3.10, using the package rdflib, version 7.0.0, and relied on the package pysmartdatamodels (Note that, at the time of writing, the modifications to this package that were necessary to complete our work are still waiting to be incorporated into the official repository and are provisionally available at: https://github.com/fdrobnic/data-models (accessed on 23 November 2025)), version 0.6.3 [64]. After the NGSI-LD data model was constructed, it was tested on the Context Broker that FIWARE recommends as a reference implementation, which is Orion-LD, version 1.4.0 [65].

Data Model for ACDSi Measurements

We propose a data model concerning the subset of the ACDSi data, containing the features assessed as important in the study [66]. These features are part of the EUROFIT [67] and SLOfit [68] test batteries.

The ontology describing the ACDSi data was conceived using the Protégé tool [63]. It consists of one root class named ACDSiMeasurement and two subordinate classes, EUROFIT and SLOfit, each containing measurements from their respective test batteries. The overall structure was conceived similarly to the Smart Applications REFerence ontology (SAREF) ontologies standardized by ETSI [69]. All the numerical data properties (features) were constrained to xsd:decimal datatype, except for the Age, which is assumed to be xsd:integer.

The ontology ACDSi is shown in Figure 1 as presented in the Protégé GUI. The left side shows the class hierarchy, where the base class ACDSi Measurement is divided into four subordinate classes: EUROFIT, SLOfit, Anthropometry, and Person. The right-hand side lists the EUROFIT class’s annotations on the top and its subordinate class structure at the bottom, which consists of the data properties and their restricted data types. The OntoGraf diagram depicting all four classes with their annotations and data properties is shown in Figure 2.

Next, we developed a tool that uses information from this ontology and creates an NGSI-LD data model in a format suitable for publication on the Smart Data Models repository. The publication process, as described on the Smart Data Models web page [48] requires submitting five documents, from which three can be generated from the ontology (schema.json, notes_context.jsonld, and example-normalized.jsonld), and the rest are filled manually. As the ETSI standard GS CIM 006 explains, the NGSI-LD information model follows the graph structure of RDF, so it is feasible to translate the RDF graph to the NGSI-LD graph.

Initially, the RDF ontology is read into a set of triples using the rdflib package. The triples consist of three elements, subject, predicate, and object, in that order. The set of triples can be queried against using the rdflib Graph.triples() function with a triple pattern as an argument. In the pattern, any triple element can be unconstrained using the keyword “None”, or fixed with a constant. Paths in the graph can be searched for using the rdflib paths.eval_path() function that can find paths of variable length when the predicate is constrained with a path pattern equivalent to the SPARQL 1.1 Property path operators [70]. This path search can find all the paths between two given endpoints, including those containing intermediate blank nodes, which are part of the input ontology due to reification.

The algorithm accepts an identification of the root class from the RDF ontology for which the data model will be generated as a parameter of type Internationalized Resource Identifier (IRI). This class constitutes the entity in the NGSI-LD terms. Then, the ontology structure is analyzed, and the necessary intermediate data structures are populated, which will then serve as a basis for the generation of the output files. The algorithm is described in detail in Appendix A.

The data properties’ names, descriptions, and data types and references and their descriptions, which the algorithm collects from the input ontology, are then serialized into the allOf.properties field of the generated schema.json file as a dictionary structure. All the IRIs of the root class and all the data properties are written to the notes_context.jsonld file.

The third file, example-normalized.jsonld, is generated using the ngsi_ld_example_generator_str() function from the pysmartdatamodels package. The function takes the generated schema.json file contents and constructs a fictitious data structure conformant to the specification.

As the model had not yet been published on the smartdatamodels.org website, our local deployment needs to provide the schema.json file as a locally served file. Additionally, a local context.jsonld file is needed. It is generated from the classes and data properties lists from the source RDF ontology in parallel and from the same data structure as the schema.json file.

The translation output verification was performed on the SAREF ontologies published by ETSI. Some of these ontologies have been translated to NGSI-LD format manually by experts and published on the smartdatamodels.org website in the past. We compared the output files from our translation of selected ontologies (e.g., https://saref.etsi.org/saref4bldg/v1.1.2/ (accessed on 21 January 2024)) with the published corresponding Smart Data Models files (e.g., https://github.com/smart-data-models/dataModel.S4BLDG (accessed on 25 January 2024)).

After all the files were generated and the necessary files published locally, the generated example payload was uploaded successfully to a locally deployed Orion-LD Context Broker using the POST command to the “/ngsi-ld/v1/entities” endpoint.

4. Results

We verified the translation in two steps:

• By determining whether the structure of the generated data models was appropriate and whether the entity properties were transferred appropriately. This step was performed on the SAREF4BLDG ontology;
• By publishing the data model and uploading the artificial data to the Context Broker, which successfully accepted it and displayed it in the test implementation upon a query.

We have successfully verified the correctness of the translation process on the SAREF4BLDG ontology v1.1.2, which contains 52 objects that were translated to 52 NGSI-LD entities by comparing the generated files with the corresponding data models in the Smart Data Models repository. The ACDSi ontology is less complex and was translated by means of a subset of the translation tool capabilities. As the structures of both input ontologies are different, the algorithm proved to be independent of the structure and found the necessary elements by using standardized SPARQL Property Path queries. These queries can find the queried elements regardless of the number of intermediate nodes and edges in the graph.

Features that emerged as important in our previous studies about the ACDSi data and were modeled as data properties in the RDF ontology are listed in

Table 1. List of features, modeled as data properties, their RDF data types, converted NGSI-LD data types, and recommended measurement units.

Feature	Class	Data Type	NGSI-LD Data Type	Measurement Unit
20-sDrummingTest	EUROFIT	xsd:decimal	number	one
20-sSit-ups	EUROFIT	xsd:decimal	number	one
30-mDash	EUROFIT	xsd:decimal	number	s
60-mDash	SLOfit	xsd:decimal	number	s
60-sSit-ups	SLOfit	xsd:decimal	number	one
600-mRun	SLOfit	xsd:decimal	number	s
armPlateTapping	SLOfit	xsd:decimal	number	one
backwardsObstacleCourse	SLOfit	xsd:decimal	number	s
bentArm-hang	SLOfit	xsd:decimal	number	s
flamingoBalanceTest	EUROFIT	xsd:decimal	number	s
handgrip	EUROFIT	xsd:decimal	number	kg
shoulderCircumductionTest	EUROFIT	xsd:decimal	number	cm
sitAndReach	EUROFIT	xsd:decimal	number	cm
standAndReach	SLOfit	xsd:decimal	number	cm
standingLongJump	EUROFIT, SLOfit	xsd:decimal	number	cm
vO2Max	EUROFIT	xsd:decimal	number	mL/kg/min
personIdentifier	Person	xsd:string	string	-
sex	Person	xsd:string	string	-
age	Person	xsd:integer	number	years
height	Anthropometry	xsd:decimal	number	cm
weight	Anthropometry	xsd:decimal	number	kg
tricepsSkinfold	Anthropometry	xsd:decimal	number	mm
bodyMassIndex	Anthropometry	xsd:decimal	number	kg/m2

, along with their intermediate classes, data types, NGSI-LD data types after conversion, and recommended measurement units. Measurement unit “one” denotes the number of repetitions in the given time, conforming to the UNECE/CEFACT Trade Facilitation Recommendation No.20 [71]. Currently, no feature has a data type that would require the NGSI-LD date format.

The generated schema.json file is shown in Figure 3. Data properties of all ACDSi Measurement subclasses are converted to the properties inside the schema structure.

After the schema.json and the corresponding context.jsonld files were uploaded to the local web server, and the fictitious data generated in the process were uploaded to the local Orion-LD Context Broker. Figure 4 shows the web browser with the query result obtained from this Context Broker. Querying using a common web browser is possible because no security measures and multitenancy features of the Context Broker were implemented in this simple deployment scenario.

This verification proves that our approach is successful in applying the graph theoretic principles in a translation process. Being independent of the graph structure, it is more versatile compared to approaches with hard-coded ontology structures.

The produced files are published openly. The RDF ontology ACDSi.ttl can be found in the repository https://github.com/fdrobnic/ontologies (accessed on 2 December 2025) and the conversion algorithm, including the generated NGSI-LD ACDSi data model files in the repository https://github.com/fdrobnic/rdf2sdm (accessed on 16 December 2025).

5. Discussion

As a possible measure to remediate the scarcity of high-quality data in the field of studies about physical development in children and youth, we engage the technologies originating in the Semantic Interoperability and Data Spaces initiatives. We developed an ontology to represent such data in the RDF format and conceived an algorithm and tool to generate an equivalent data model in the NGSI-LD format automatically. The algorithm implements the SPARQL Property Path queries to analyze the structure of the input RDF ontology, which makes it independent of the ontology structure. By using the information collected during the analysis, it then builds the output NGSI-LD data model. We have successfully verified the generated NGSI-LD data model by installing the necessary software components, including the generated data model, and uploading fictitious data to this installation.

The developed ontology consists only of the features identified as most important from the ACDSi data in the previous machine learning studies. It is possible to improve this ontology further, which would necessitate the engagement of a broader community of experts in physical development in children and youth.

The conversion algorithm from RDF ontology to NGSI-LD data model can translate the SAREF ontologies and our relatively simple data model. The enhancement to translate a more diverse set of ontology variants remains for future work.

In data sharing, all the participants must have a common understanding, in what measurement units the data is provided. Ontologies often do not provide any proposal or even constraint in this sense. The specification is deferred to the instantiation phase, where the provider can specify the units. In the SAREF ontologies, the measurement values that come from periodic measurements are specified as saref:Measurement object (and are object properties of classes) and the measurement unit can be given using the saref:isMeasuredIn predicate and saref:UnitOfMeasure object. Units are then specified using one of the known measurement unit ontologies [72]. The SAREF ontologies specify also other data about the given object that do not occur periodically. These are specified as data properties. In the NGSI-LD data model, the “unitCode” property is already defined in the API and can be specified together with the data value. The Smart Data Models initiative proposes to use the unit codes from the UNECE/CEFACT Trade Facilitation Recommendation No.20 [71]. The unit can also be specified as part of the description attribute of the properties in the schema.json file. In our case, we decided to model a single instance of all measurements for one person as one root object, and so modeled the measured values as data properties. For simplicity, we did not model the measurement units similarly to the saref:Measurement object and proposed the expected units already in the data properties’ descriptions in the RDF ontology so that they are transferred unchanged to the NGSI-LD data model during translation. This implies that in the current version, the data provider has to ensure that data is published according to the proposed measurement units. Improving the ACDSi RDF ontology to also provide capability similar to the saref:Measurement object remains for future work and would entail additional development and verification of our translation tool.

The NGSI-LD data model cannot be published formally on the Smart Data Models repository yet because the model is not currently being used in real data exchanges. In any case, the data models prepared with our tool can be used in the data sharing scenarios provided that they are published openly so that all the participants in the data sharing can access them and align their data and algorithms to them.

6. Conclusions

As a means of reducing the scarcity of data in the field of developmental studies of children and adolescents, we propose an ontology in the RDF format and a corresponding NGSI-LD data model. We propose a tool that can translate an RDF ontology into an NGSI-LD data model using the SPARQL Property Path queries for analysis and demonstrate its capabilities on two cases: a complex SAREF4BLDG ontology and our simpler ACDSi ontology. We verify the translated NGSI-LD data model by publishing fictitious data on a test FIWARE Context Broker installation.