Conceptual models have traditionally been tools for sharing understanding of system's structure and behaviour with others. Although this is still the main use-case, some works have already shown usefulness of their machine readable form to derive data schemata, system documentation, as well as semantic vocabularies of the given system or domain. In this work we present OntoGrapher, a visual web-based tool for conceptual modeling based on the OntoUML conceptual modeling language. The tool accepts and produces machine readable outputs in the form of OWL ontologies and SKOS thesauri. We show its main features, bene ts as well as use-cases in which the tool has been successfully applied and include a hands-on demo of the tool. Finally, we perform user testing evaluating the tool. A roadmap for the tool's future development is laid out based on the testing results and already planned features.
Conceptual modeling is a traditional discipline of system and data engineering.
Although there exist various languages for conceptual modeling (like E-R
models [
Scenario: supporting public sector data management in Czechia The Ministry of the Interior of the Czech Republic and the Department of the eGovernment Chief Architect is responsible for the design and optimization of digital services as well as for the coordination of the design of the data and information architecture across the Czech government. As part of its agenda, it maintains the necessary eGovernment legislation comprising thirteen key acts. These include e.g. the Basic Registry Act No. 111/2009 Coll., the Act No. 365/2000 Coll., on information systems of the public administration, and Act No. 106/1999 Coll. on Free Access to Information. In 2018, they created a non-legal document Information Concept of the Czech Republic, a vision of the Czech public sector data and services, which is further detailed in several other documents { the National Architecture Plan and the National Architecture Framework and also the eGovernment vocabulary. The latter lists selected concepts from the aforementioned laws, as well as from the Czech norms, together with custom concepts de ned by the Department of the Chief Architect.
The terminology in the public sector often stems from the legislation, which contains many well de ned terms. However many others are not well de ned, yet heavily used. Open data stand on the opposite side. Often, they are just selections of data existing in governmental information systems - yet the connection between the open data, the data in the original information systems and the requirements given by legislation is missing. This complicates checking how well they re ect the legislation, whether there is a novel requirement to publish new open data, or what is the correspondence to the data in the original information systems.
To support answering such questions related to auditability of open data, a data schema management process has been designed, as depicted in Figure 1.
The process is based on open semantic web standards, an obvious bene t of which are the (linked) open data principles, so that institutions can communicate not only more e ciently, but also more transparently with citizens and organizations. In order to do so, the meaning of open data (its entities, relations and attributes) needs to be conveyed to the consumers as well. Various legal concepts, requirements, processes, and relationships or distinctions between the aforementioned concepts have to be abided by.
The process expects involvement of domain experts who are able to identify key concepts, knowledge modelers who are able to design a formal ontology on their top, publish it as linked data and create data schemas out of it. Finally, clerks help to ne-tune the automatically generated forms and curate the open data collected through these forms.
For the rest of the paper, let's zoom in to the details of the conceptual model creation with OntoGrapher. 2
With the requirements mentioned in section 1 in mind, we introduce OntoGrapher as a tool for clerks with background in conceptual modeling (or domain experts keen to get it), but not necessarily versed in OWL1. In particular, OntoGrapher has the following goals: { o er a collaborative web-based conceptual modeling environment for domain experts, { accept SKOS terminologies on input and produce OWL ontologies on output without requiring users to understand either of these standards, { track the source of entities, relations and attributes in conceptual models stemming from multiple vocabularies (e.g. laws).
As a result of these requirements, OntoGrapher is implemented as a web application with the following key features: Interaction with online services OntoGrapher uses and manipulates data from triple stores with RDF4J APIs, authenticates the user with OpenID Connect-compatible servers, and is designed to be an online application from the ground-up. This streamlines the overall process of managing, sharing and publishing vocabularies, since users don't have to import them into a dedicated desktop application and any changes are stored on a server - ready to be published whenever the user is ready to do so.
Artifact export In addition to modifying thesauri and ontologies in-place, the application is capable of exporting the view of the model (as arranged by the user) in either PNG or SVG formats.
Customizable visualization options i.e. concepts can be visualized using SKOS preferred or alternative labels. Also, diagrams can be visualized in E-R model syntax or a more compact UML-like syntax.
https://data.gov.cz/english/ or the project's GitHub repositories at
https://github.com/opendata-mvcr. An up-to-date Czech version is available at
https://data.gov.cz.
OntoUML Support The tool supports categorization of concepts using
OntoUML [
Work ow
At its core, OntoGrapher takes SKOS thesauri (representing identi ed concepts for which conceptual models do not exist yet) and OWL ontologies (representing already created conceptual models), visualizes them, and manipulates them. The changes that users make are saved in real-time to a triple store. In addition, OntoGrapher commits its own speci c data (element positions within the graph, diagram names, etc.). OntoGrapher reads the SKOS thesauri and OWL ontologies from the central repository for Czech government vocabularies2. The appendix talks about the vocabulary data structure in more detail.
OntoGrapher modi es these vocabularies in a workspace, which is a copy of a selection of vocabularies, so that changes in the workspace do not modify the original repository. Workspaces can have multiple vocabularies in them, which is useful for modifying vocabularies and their complements together (for example a 2 https://slovn k.gov.cz Civil law vocabulary and a Marriage registry vocabulary). An example work ow with workspaces is described in Figure 2. 3
Of particular note is the interplay between OntoGrapher and UFO (Uni ed
Foundational Ontology; the foundational ontology on which OntoUML is based)
[
OntoGrapher, as of the time of writing, supports concepts with at most two stereotypes4, though at least one is required for the validity of the model (depending on the stereotype) as determined by the validation server; (i) Type stereotypes, which de ne the ontological nature of the concept - e.g. Object Type, Event Type - and (ii) OntoUML stereotypes serving to validate the conceptual model itself (e.g. rigidity). There are plans to support more stereotypes with more varied inferences in the future (see the Future work section below).
To improve the modeling experience, OntoGrapher o ers only valid types of relationships to the user upon relationship creation, based on the stereotypes of the concepts involved in the given relationship. 4
A demo instance of OntoGrapher can be run as described at https://ontographer.github.io/ontographer-demo/. The website contains instructions to build and run the example as well as a walk-through of the prepared scenario. In this scenario, the user has been given a single vocabulary to edit - a vocabulary representing a law regulating the operation of vehicles on public roads. The aim of the editing e ort is to clean up the vocabulary and x any inconsistencies that arise. At the end, they should have a vocabulary that is visually legible, consistent, and comprehensive.
Figure 3 shows the main elements of the user interface. At all times, the user is presented with the canvas where the concepts and relationships are visualized along with a panel showing the vocabularies and concepts within the workspace as well as any concept search results.
An important distinction of concepts is between write-enabled concepts and read-only concepts. The editability of concepts is determined by the way their vocabularies entered the workspace - vocabularies that the workspace itself was created around are write-enabled, but the user can also search and introduce
4 By stereotypes, we mean types de ned in the aforementioned top-level ontology. concepts from the central repository that are outside the workspace. The consequence of the design of workspaces as described in section 2.1 is that these concepts cannot be edited.
In typical usage, therefore, a given workspace has at least one vocabulary designated as write-enabled (all its concepts are write-enabled) and can have other vocabularies that are read-only (all their concepts can be pulled into the model only as read-only). This means that they can be present in diagrams and manipulated visually, but their details or relationships can only be viewed, not edited. The demo uses this to nd possibly redundant concepts that already exist in another vocabulary.
In addition to manipulation of their visual representation, write-enabled concepts allow editing of their various details, such as synonyms, and creation of relationships originating from those concepts. Concepts can of course also be deleted or created as part of a selected vocabulary.
The editing of concept and relationship attributes is done with clicking on the given element, which brings up another panel detailing all information about the element. The user can edit/view cardinalities, labels, display label (a selected pref/altLabel that a concept/relationship is displayed under in OntoGrapher), intrinsic tropes, stereotypes, and more. They can also see the list of all relationships involved with a concept (including outside the workspace) and lter through them or select which concepts related to a concept should be shown. This enables showing only intrinsic tropes of a concept easily in the demo scenario.
Model elements are arranged into one or more diagrams, which are distinct "sections" of the entire model, containing some or all of the concepts and relationships within. It is not necessary for a concept in the model to be in any diagram; also, a single concept can be in multiple diagrams, as it is just an OntoGrapher-speci c construct. Multiple diagrams are used in the demo to organize the large and complicated model into smaller sections.
There are two available views with which to visualize the diagram. Full view shows all connections and concepts as they are present in the data; i.e. all connections and concepts of all stereotypes. This is useful for experienced modelers, but may be undesirable to those who do not necessarily need the complete "behind-the-scenes" description of the model and want to focus on more conceptual modeling that OntoGrapher can provide. Compact view shrinks rei ed relationships into individual edges and aggregates concept tropes into the concepts themselves rather than displaying them as separate concepts connected to the given concept. Figures 3 and 4 display the same model in Compact and Full view, respectively.
During the process of modeling, several concepts and relationships may have
been created, edited and deleted. To ensure validity of the conceptual models,
OntoGrapher uses a validation service to check for consistency of the
resulting model. The validation service uses SHACL[
from an Anti-rigid one (e.g. Role)."@en ; sh:targetClass z-sgov-pojem:rigid; sh:property [ sh:path rdfs:subClassOf ; sh:qualifiedValueShape
[ sh:class z-sgov-pojem:anti-rigid ] ; sh:qualifiedMaxCount 0 ] .
Rigid(x) and AntiRigid(x) are expressed in the data as classes de ned in the z-sgov-pojem top-level ontology for the central repository, which describes all basic classes for concepts as well as connections between concepts. 5
In order to systematically assess the user experience of OntoGrapher, user
testing has been devised. The test consists of three parts: rst, an assessment of
the participant's experience with OntoGrapher, Semantic Web technologies and
conceptual modeling, then, a short scenario (about 10-15 minutes; di erent to
the one in the Demo section) is presented in which participants complete tasks
that demonstrate a vertical slice of the application's functions. Lastly,
participants' impressions are collected. The last part also contains questions through
which the System Usability Scale [
Six participants have been recruited through notices in communication channels of the previously mentioned grant project's members. The number of participants who claimed to have at least some knowledge of OntoGrapher, Semantic Web technologies, or conceptual modeling, is 4, 4, and 5 respectively.
The results of the testing gave OntoGrapher a System Usability Scale score
of 73; as the average SUS score is 68 [
The most mentioned issues were with the way the creation of concepts and relations worked, which two thirds found unintuitive in their impressions after the testing. Another problem was that participants weren't absolutely sure what was being asked of them in the testing. In terms of functions the participants would have liked the most, the most requested one is the ability to undo changes.
Something to note is that this testing strategy only measures the usability of the user interface without considering the usefulness of the application in real-life scenarios - this testing strategy only measures the usability of the application with regards to the creation of the OntoUML-based conceptual model over multiple vocabularies without considering the broader scenario of Figure 1. The whole scenario is currently under testing - together with other tools in the stack by the Ministry of Interior eGovernment department and other governmental partners. 6
This application is not the rst e ort made to simplify the process of
modeling OntoUML conceptual diagrams. A signi cant contribution in this eld is
by Guizzardi and his team at NEMO5 with the OntoUML lightweight editor
(OLED)6. The project was rst released in 2015, along with an accompanying
paper [
In the paper, the authors describe the various features of OLED, such as
patterns and anti-pattern checking, OCL constraints[
However, as the contributions in the repository mostly ended after 2016 and the tool is incompatible with the latest Java version (our testing con rmed that it runs on Java 8, but not 16), the tool seems to be all but abandoned. In addition, while the number of features is impressive, the application's user interface is often unresponsive while using them and sometimes crashes entirely without an error prompt (even with models with as little as two classes, our testing showed).
The NEMO team has largely moved on to making an OntoUML plugin for the software engineering application Visual Paradigm7. This allows them to focus on implementing OntoUML-speci c features directly without having to create a new modeling application base. As a result, the modeling experience is much smoother and more stable than with OLED.
The plugin o ers modeling assistance in UML diagrams, for example ltering invalid stereotype relationships or validating models and diagrams. The models can be imported from JSON or exported to JSON or gUFO (a Turtle ontology le which imports and uses the gUFO base ontology to represent OntoUML constructs). Thanks to Visual Paradigm's ability to store its projects in an online database, users can collaborate on the model (the database contents are proprietary to Visual Paradigm - the aforementioned exports have to be generated by the client locally).
Another plugin for OntoUML modeling is for the OpenPonk modeling platform8, developed by the OpenPonk team itself. The plugin can be downloaded directly with the application. While the application is competent with regards to modeling other classes of diagrams, the OntoUML plugin is quite limited; it o ers the basic stereotypes and relationships with validity and anti-pattern checking, but the model itself cannot be exported to a format that can then be processed by anything other than OpenPonk.
OntoGrapher ful lls slightly di erent needs that the aforementioned solutions currently cannot; perhaps two of the most important are that the application should be connected to online services, where its results can be shared or published directly without the need to export, and have the ability to receive and 5 Ontology and Conceptual Modeling Research Group - website at https://nemo.
inf.ufes.br/en/ 6 The project's repository is at https://github.com/nemo-ufes/ ontouml-lightweight-editor. 7 Visual Paradigm's website is at https://www.visual-paradigm.com/. The plugin is available at https://github.com/OntoUML/ontouml-vp-plugin/. 8 OpenPonk's website is at https://openponk.org/. manipulate vocabularies with the wider Czech eGovernment initiative's specications, which are a expansion of OntoUML with SKOS thesauri and other ontological categories. 7
The user testing and general responses from the users of the application revealed that there are still some issues with regards to the user experience. In addition, as the tool is still in its prototyping phase, there are still many features to implement and many design details to improve in order for the tool to progress to a beta stage. Listed below are several examples of planned features for OntoGrapher: Support for other formal ontologies The tool is currently tied in part to the basic top-level ontology of the Czech government vocabularies' repository, which prevents it from being applied in other domains.
Ontology Design Patterns We are working towards implementing an Ontology Design Pattern (ODP) language in OntoGrapher. ODPs help engineers create models more quickly, avoid certain frequently made ine ciencies and better prepare their models for any future extension or revision. The eld of ODP languages, however, only a few years old and thus support of ODP usage with methodological approaches, classi cation, categorization, standardized distribution or implemented tools is still developing, so implementation of a language requires development of rigorous theoretical foundations rst. Change tracking Seeing the changes made to the vocabularies in the application in a clear and concise way would allow reviewers to work and identify problems faster. In subsequent development, it could also allow rollback of speci c changes without a ecting the rest of the vocabulary/vocabularies. Modeling guidance While the application does feature validation with an accompanying SHACL constraint-checking server, the con ict-resolution and user guidance features are limited to non-existent. In addition, the user has to manually call the validation themselves in order to see possible violations. Some of this could be covered by the implementation of ODPs, but a feature wherein the validation errors can be resolved automatically/with a simple wizard or the user is guided through modeling with automatically setting correct cardinalities/relationships or warning about semantically invalid/antipattern sections (or closing the ability to create such sections in the rst place) would also prove useful.
We believe that OntoGrapher is worth deploying in other contexts, since it enables a work ow in which domain experts do not have to worry themselves with the speci cs of SKOS or OWL, but can focus directly on the creation of conceptual models in their domain without extensive help from conceptual modeling experts while keeping machine readability of the resulting models.
As mentioned in section 2.1, the two main elements representing the model are (i) SKOS concepts (more speci cally, skos:Concept instances9) and (ii) relationships (compiled as OWL restrictions on certain concepts with a certain relationship type and of a certain cardinality, when applicable).
All concepts and all connections also should have a type that is from or is a subclass of the basic top-level ontology to obey validity rules. This ontology mirrors OntoUML's classes and extends it with connections and other classes.
The following examples clarify the details of this arrangement. All of the examples will be represented in Turtle, with syntax highlighting for owl, skos and the z-sgov-pojem basic top-level ontology, which mirrors OntoUML's classes and relationship types.
Example 2. Let's start with one concept, a Record of birth, which will be de ned in the Birth registry vocabulary. gov-birth-registry:record-of-birth a skos:Concept, z-sgov-pojem:typ-objektu; skos:inScheme gov-birth-registry:scheme; rdfs:subClassOf gov-registry-offices:registry-record; skos:prefLabel "Record of birth"@en; skos:description "A record of a birth of a person
stored in the birth registry office."@en.
This describes the concept as an Object type (with z-sgov-pojem:typ-objektu) and as belonging to the gov-birth-registry vocabulary (with a gov-birth-registry:scheme SKOS scheme). The concept is a subclass of Registry record - another concept10.
Example 3. We could assign a trope to this concept, like so: gov-birth-registry:record-of-birth z-sgov-pojem:ma-vlastnost
gov-birth-registry:datetime-of-birth. gov-birth-registry:datetime-of-birth is an Intrinsic trope type class concept connected to our working concept via z-sgov-pojem:ma-vlastnost (has intrinsic trope) - a connection de ned in the basic ontology z-sgov-pojem. Example 4. However, we would also like to describe a more complex connection, with cardinalities and detailed information about the nature of the connection. This is a common pattern with these vocabularies, and is expressed with Relator types and OWL restrictions in the following way: 9 skos: pre x denotes the namespace http://www.w3.org/2004/02/skos/core# 10 All concepts must have at least a preferred label, a SKOS scheme, and a skos:Concept type to be recognized as a concept. Anything else is, from the standpoint of OntoGrapher, optional. Note that having these required attributes does not make a concept or its connections inherently valid with respect to the validation rules. # "Documents birth event" Relator type gov-birth-registry:documents-birth-event a skos:Concept, z-sgov-pojem:typ-vztahu; skos:inScheme gov-registry-office:scheme; skos:prefLabel "documents birth event"@en; skos:altLabel "documents"@en. # Connection from "Documents birth event" to "Record of birth" gov-birth-registry:documents-birth-event rdfs:subClassOf [rdf:type owl:Restriction; owl:onProperty z-sgov-pojem:ma-vztazeny-prvek-1; owl:allValuesFrom gov-birth-registry:record-of-birth], [rdf:type owl:Restriction; owl:onProperty
[owl:inverseOf z-sgov-pojem:ma-vztazeny-prvek-1]; owl:allValuesFrom gov-birth-registry:documents-birth-event], [rdf:type owl:Restriction; owl:onProperty z-sgov-pojem:ma-vztazeny-prvek-1; owl:onClass gov-birth-registry:record-of-birth; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger], [rdf:type owl:Restriction; owl:onProperty
[owl:inverseOf z-sgov-pojem:ma-vztazeny-prvek-1]; owl:onClass gov-birth-registry:documents-birth-event; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger]. # Connection from "Documents birth event" to "Birth of person" gov-birth-registry:documents-birth-event rdfs:subClassOf [rdf:type owl:Restriction; owl:onProperty z-sgov-pojem:ma-vztazeny-prvek-2; owl:allValuesFrom gov-civil-law:birth-of-person], [rdf:type owl:Restriction; owl:onProperty
[owl:inverseOf z-sgov-pojem:ma-vztazeny-prvek-2]; owl:allValuesFrom gov-birth-registry:documents-birth-event], [rdf:type owl:Restriction; owl:onProperty z-sgov-pojem:ma-vztazeny-prvek-2; owl:onClass gov-civil-law:birth-of-person; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger], [rdf:type owl:Restriction; owl:onProperty
[owl:inverseOf z-sgov-pojem:ma-vztazeny-prvek-2]; owl:onClass gov-birth-registry:documents-birth-event; owl:qualifiedCardinality "1"^^xsd:nonNegativeInteger].
The example expresses its cardinalites and relationships through OWL
restrictions, using a Relator type Documents birth event concept mediating between
the two involved concepts. The z-sgov-pojem:typ-vztahu type (Relator)
mirrors the relator class from OntoUML. The Birth of person concept is from the
Civil law vocabulary. Figure 5 show the model from these examples as presented
in OntoGrapher in Compact mode (more on this in section 4). The concepts are
color-coded based on their vocabulary.
Note that the design of these vocabularies predate OntoGrapher entirely and
the application's development does not in uence the core nature of the
vocabularies' architecture in any way; it is merely adapted to it. More details about
the structure and the reasoning behind choosing it are described in a dedicated
paper [