Processing semantically enriched data in RDF or Turtle format is not trivial for traditional development teams, who usually consume data in XML or JSON format. To improve the developers' experience of using the Semantic Web serialization formats, e.g., RDF or Turtle, an intermediate solution might be beneficial. This work presents a way for dynamic serialization of ontology metadata graphs, the possible structure, with ontology mapping paths, the required structure, to be later used by software development teams. Presented idea is implemented as a tool, RDF2JSON-OM, and is demonstrated as a web service endpoint.
As the amount of the data processed and stored by companies is rising in the last decades [
JSON-LD [
CEUR
ceur-ws.org using Semantic Web technologies for their core activities, because the masses of software developers are not willing to adopt it [8]. Here is where it makes sense to use the presented hybrid solution: linked data, but in a JSON tree structure with a simple context, as can be seen in Figure 3 - right. For external interoperability, generating JSON-LD out of consumed JSON with context is easier than consuming it.
RDF/JSON [9] is also a root-oriented structure. The presented solution algorithm extends and
improves the one described in the W3C Note. It does not require branches of the tree to be arrays; that
is optional based on the modeled reality. Also, the cited algorithm does not ofer any solution to cyclic
structures, not even mentioning them. RDF/JSON did not become a W3C recommendation in favour of
JSON-LD. Reasoning included opinions about the purpose and the final target group of such format
[
Ekaputra et al. proposed a modelling framework called SOyA [8] for modeling more interoperable structures with JSON-LD in scope. The work concentrates on modelling activities, mostly of a metadata graph, but is not going further to discuss the usage of JSON-LD structures by software developers, therefore not helping to bridge the adoption gap.
The presented solution (see Figure 1) shows a way of delivering semantically enriched data to consuming components in a more developer friendly format: JSON [12]. The data/domain expert is responsible for modeling the ontology and the desired structures to be serialized. The software developer then receives that structure in JSON format and uses it to implement further business logic. Although there are already several standardized JSON serialization formats [13], their main purpose it to publish data via services [12]. They deliver information in a graph-like structure, mocking the original graph. At the same time, structures representing a graph do not have one key limitation that JSON tree structure has: cycles / circular structures. This issue is solved by using newly introduced mapping paths over the ontology metadata graph. It also concentrates on separating the concerns of data modeling, where data structures are often not modeled by data/domain experts, but by software developers. This can speed up the adoption of mentioned SOyA framework among the consumers of data, not only the creators. This is a crucial step towards clean data delivery and interoperability.
The presented tool, which we call RDF2JSON-OM (where OM stands for ontology mapping), together with the demo service implementation can be found on Github [14].
A very simple Person ontology can be seen in Figure 2. The section highlighted in blue represents a cycle. When attempting to serialize such an ontology graph into a tree structure, an infinite loop of operations is created, since no end of cycle is specified. Also, let’s think of the use-case where the Spouse object should not have the isIdentifiedBy property, because that is not part of the requirement (e.g. lack of datasets, legislation constraints, etc.).
A JSON tree is a 2-dimensional key-value structure that is easy to consume, parse, and get the content from. The keys have to be unique on the same level of the tree, and values can be either a simple literal, an object or an array of objects that can expand further internally. An example of a possible JSON tree structure can be seen in Figure 3 - left.
In the presented solution, the generated structure is a tree with a root, the serialized object; see Figure 3 right. This serialization process is based on the ontology it is meant to serialize. There is no hard-coded pattern, therefore the whole process is dynamic towards the modeled reality, preferably created by data/domain experts. Software developers then get the JSON structure they can work with. It provides them with the keys, that are IRIs, pointing to the ontology for further metadata discovery, if needed. The populated datatype properties (e.g. hasFamilyName), can carry any relevant information, e.g. the datatype of the value, which the developers should use.
Ontologies can be provided as a parameter, but can also be stored in a triple store. That is a big benefit, since multiple ontologies complementing each other, e.g., Ontology network, can be stored in the same graph, and the structure generator will create a JSON consisting of classes and properties from all ontologies touching any of the elements in the desired tree of the serialized object. The storage can be either persistent, or virtual, built during the generation.
The solution implements the RDF2JSON-OM structure generator using the JENA API library, which loads the ontology model as RDF triples and populates a generic Map<Object,Object> object based on the selected root. Afterwards, it creates the corresponding branches based on the modeled datatype and object properties. Datatype property ends with a leaf to store only the final value, whereas the above creation is repeated in recursion for object properties, until the final ontology class has no more object properties. It takes subClasses, subProperties and restrictions into consideration as well. The required part of the generated structure is the context, which carries all prefixes used in the structure. The implemented demo service is a REST endpoint accepting an ontology in RDF/XML format and root object IRI, returning the generated structure [14].
One of the biggest challenges to overcome was the unavailability to convert circular structures to JSON, although an IETF draft exists [ 15]. When there is a cycle in the ontology, e.g., objects are pointing to each other, the JSON generator would enter an endless loop. There are several non-semantic techniques to overcome this, e.g., content replacements or substitutions, but that leads to the need for content restoration and adds more complexity.
Instead, the presented solution involves more descriptive techniques and also benefits the content creators, as they now have the power to specify what the final structure is supposed to look like. The creator of the model uses restricted paths to draw only the relevant branches of the final tree structure. For the infinite loop to happen, the creator would need to create an infinite path, which is impossible in the real world and also impossible to draw. Generic JSON-LD serialization would include the property isIdentifiedBy for Spouse object, since it is part of the ontology. With mapping paths we generate only what we draw to be generated, thus fulfilling the requirements set by stakeholders, yet still keeping the model as designed by data experts. Moreover, the modeled paths can be re-used in various structures. They are interoperable, as long as they are logically correct.
An example of mapping paths is highlighted in Figure 4.
This work describes the idea and implementation of the ontology graph serialization into a JSON tree structure, including overcoming the problem with circular structures. It allows the content creators to explicitly restrict parts of the graph from being serialized and gives them the power to specify how deep the circular nesting should go. The structure is generated automatically and dynamically, without any further configuration. These structures are to be sent out as serialized data structures to consumers, who can either read them with semantics in mind and populate with content for further event based message processing or decompose them and store them in any arbitrary structure, which raises the possibility of adopting Semantic Web technologies in a broader community. The final generated structure also conforms to most of the best practices listed by JSON-LD creators [12] at the moment of writing this paper, therefore foreseeing the pitfalls of data consumption and thus confirming the maturity of the solution.
We plan to include the restriction validation functionality in our tool. OWL axioms themselves can assure some level of validation, e.g. Person can be declared as disjoint from Vehicle, which then makes a reasoner trigger an inconsistency even if the data experts makes a mistake and tries to model the mapping path that way. For much extensive validation, this can be then complemented with SHACL [16] shapes modelled by data experts.
Another benefit and usage of the proposed solution is that the same algorithm can be used to generate a JSON schema in parallel. This schema can be later used for the structures validation during the future data transfer process, where they will be validated before they reach the software developers, efectively lowering the amount of tests needed to be prepared.
To improve developers’ experience with consuming and understanding the delivered structures, we plan to include the generation of Swagger documentation out of RDF, solely based on data experts’ models. This is another step towards Semantic Web technologies adoption.
This work has been supported by the EU’s Horizon Europe grant no. 101058682 (Onto-DESIDE).