Temporal ontologies, knowledge graphs, and conceptual data models persist as requirements, since much data collected is temporal and constraints must hold to ensure data quality. Temporal conceptual modelling and ontology development face various challenges in uptake, notably the cognitive load and then extra eforts to squeeze it into an atemporal OWL, and once represented, to convert it into something concretely useful in applications. We introduce the TRENDy tool, which ofers browser-based diagrammatic modelling of the logicbased temporal conceptual data modelling language Trend, and subsequent automated conversion into SQL statements to create the corresponding relational database. The evaluation showed the tool to outperform the baseline modelling tool in usability. Software availability: https://github.com/richietaylor/trendy
The visual paradigm for ontology authoring is well-known, and for conceptual data models such as
UML and EER, it is considered essential. For temporal ontologies and conceptual models, this is even
more important, because the extra set of constraints impose a higher cognitive demand, especially
when ternary relations have to be reified in OWL [
To address the temporal modelling and deployment hurdles, we developed the TRENDy tool. It
provides, first, a graphical editor front end, which uses the syntax and semantics of the Trend
modelling language [
Second, we designed and implemented transformation algorithms from Trend models into SQL such that all constraints are preserved. Efectively, columns for time are added and then triggers to ensure data integrity. This is, to the best of our knowledge, the first implementation of a conversion from a temporal conceptual model into a relational database.
The remainder of this demo paper presents the front-end with the graphical modelling of logic-based temporal models in Section 2 and the transformation into SQL in Section 3. We then conclude, look ahead, and outline what can be expected at the demo in Section 4.
TRENDy is built using the Model-View-Controller (MVC) design pattern, ensuring a robust and scalable framework. The Model serialisation is implemented as a JSON object, maintaining separate lists for nodes (the implementation of entities, attributes) and edges (the implementation of temporal constraints). Said lists contain all necessary information for on-screen rendering and integration with the SQL schema generation component (described in the next section). The View and Controller are managed by ReactFlow, a React library optimised for node-based UI design, enabling features like drag-and-drop, resizing, and an infinitely expanding canvas. The architecture allows easy long-term maintainability and adaptability of the codebase.
The interface with full layout is shown in Fig. 1. Key components include state management (therewith allowing the user to undo and redo changes on the model), basic syntax checking and explanation of errors, a verbalisation feature that provides natural language renderings of selected temporal constraints (see Fig. 2), and other features, such as snap-to-grid, panning, and saving.
TRENDy was evaluated through a user study involving 16 computer science students that had
completed a database course including EER two years before. They were divided equally between
TRENDy and the control tool Draw.io. The learning curve for TRENDy compared to the relatively
well-known Draw.io was not factored into the experiment set-up. Participants were tasked with creating
temporal models based on Trend’s controlled natural language [
The scatter plot in Fig. 3 shows the results for each participant. For Draw.io, the average mark was 12.63/21 (60.12%) and the average time to complete the tasks was 25:10 minutes; for TRENDy, they were A. Example of temporal constraint verbalisation and of the contextual menu B. Example of basic validation. Top: error display; Bottom: explanation upon selecting the line. 17.13/21 (81.55%) and 21:07 minutes, respectively. Thus, TRENDy users were 16.01% faster with a 21.43% improvement in their model correctness, on average. The average SUS score was 43.13 (“poor”) for Draw.io and 75.63 (“good”) for TRENDy. The downside of familiarising oneself with a new tool of good quality was thus ofset by faster, and better, modelling. Future interface evaluations might elucidate whether this can be attributed to the specific and guided options, cf. a flexible Draw.io palette, and/or additional model explanations in TRENDy.
This component of the tool converts Trend models into functional SQL databases. The SQL files are
designed to work for MariaDB [
All standard features present in Extended Entity Relationship Diagrams are implemented, as well as the temporal logics and transition constraints of Trend. This was achieved by developing an algorithm that takes a serialised Trend model from the graphical editor and generates an SQL file containing the tables and triggers specified according to the model. The algorithm scales log linearly with input size converting a list of nodes and edges into data structures representing the finalised tables. Each of these data structures are then used to generate SQL strings which are appended to the output file.
For the temporal entities, it adds ‘start’ and ‘end’ columns for the valid time. The temporal constraints in Trend are converted into SQL triggers. The triggers for the temporal transition constraints prevent the insertion of any tuple that violates the formal semantics of Trend. Each temporal constraint in Trend maps to a trigger pattern, which is then completed with the relevant elements from the Trend model that is being converted. For instance, given two entities, A and B with identifiers, AID and BID respectively, the trigger to enforce an optional dynamic evolution in the past (chg, with a dotted arrow in the diagram) is the following: A. Each bonus customer was already a loyal customer B. TREND syntax
LoyalCustomer ISAC Customer BonusCustomer ISAC Customer ID(Customer) = CustID mextLoyalCustomer,BonusCustomer
C. Semantics of ‘mandatory ext’ D. Section of the SQL code generated
where C1 is the Loyal Customer and C2 the Bonus Customer and EXT is defined as:
This trigger prevents entries being made in B’s table that overlap with existing entries with the same identifier in A, enforcing the rule that “each object in B could have been in A, but is not in A anymore”, by preventing an object from being in both A and B. An example with generated SQL code for the ‘mandatory extension in the past’ is shown in Fig. 4.
Thorough testing has shown that the tool can accurately generate schemas based on the user’s models, and that these models obey Trend’s semantics. This schema generation feature is expected to decrease the barrier to entry of developing temporal databases by reducing the time and costs associated with it, solving the problem of needing to manually implement all temporal features in the application logic. This demo paper introduced the Web-based TRENDy tool, with which a user can develop temporal conceptual data models in Trend notation and convert it into a temporal relational database that also enforces the temporal constraints specified in the model. The small-scale evaluation with typical novice modellers showed the tool to outperform the baseline modelling tool.
This proof-of-concept constitutes enabling infrastructure, not only to simplify temporal modelling, but also for future experiments regarding uptake of temporal constraints, how a transformation-based OBDA pipeline may be designed, and to what extent that may overlap with requirements for temporal knowledge graphs. Either temporal SQL-to-RDF or a direct conversion to RDF with SHACL is another avenue of future work.
The demo will showcase all features and participants can try it themselves, be it from scratch or based on examples, such as those used in the user evaluation of the front-end. The machine will also run an instance of MariaDB so that the TRENDy-generated SQL can be executed to create the temporal database where the correct functioning of the temporal constraints can be verified.
We thank the participants in the evaluation.