Ontology Export Patterns in OWLGrEd Editor

The OWLGrEd ontology editor allows graphical visualization and authoring of OWL 2.0 ontologies using a compact yet intuitive presentation that combines UML class diagram notation with textual Manchester syntax for expressions. For the full use of the graphical ontology tool, it is important to be able to export the ontology in one of OWL textual standards. We describe the OWLGrEd ontology export implementation using patterns that are ascribed to editor diagram abstract syntax elements. The OWLGrEd export patterns show the relationship between editor visual constructions and ontology textual form elements. The pattern-based method allows a tool end-user to define a custom field semantics in OWLGrEd extensions, and it can be generalized also for the model-to-text transformation within other similarly structured tools.


Introduction
OWL 2 (Motik et al., 2012) is a major logic-based open-world knowledge representation language for the Semantic web. The presentation of OWL ontology in a comprehensible form is essential for both the ontology developers and ontology users. A number of approaches and tools have been developed to achieve better ontology comprehensibility by presenting the ontology graphically, including OWLViz (WEB, i), VOWL (Lohmann et al., 2016), OntoDia (Mouromtsev et al., 2015), ODM (WEB, h), TopBraid Composer (WEB, l), RDF visual graph editor (Chis-Ratiu and Buchmann, 2018) and OWLGrEd (Barzdins et al., 2010c). The benefit of the graphical presentation is that the concepts that are related in the ontology are also visualized together. The article (Dudás et al., 2018) has carried out a broad study on methods and tools for graphical ontology representation.
OWLGrEd is an editor where one can edit OWL 2 ontologies in a visual environment. OWLGrEd combines UML class diagram notation and textual OWL Manchester syntax (Horridge and Peter 2012) for expressions that may occur in ontology definitions. This type of representation ensures that visually related objects are displayed together. So, object properties are connected to the property domain and range classes and data properties are represented as their domain class attributes.
For graphical ontology representation tool such as OWLGrEd, it is important to be able to use the ontology defined therein in other tools as e.g. Protégé (WEB, j), allowing, for instance, the ontology inference by the means of the available reasoners as HermiT (Glimm et al., 2014), Pellet (Sirin et al., 2007) or FaCT++ (Tsarkov and Horrocks, 2006). A variety of other systems, including e.g. a knowledge-based framework OBIS (Zviedris et. al., 2013;Cerans and Romane, 2015) or visual query tool ViziQuer/web (Cerans et al., 2018) use ontology definitions as their input data. For an ontology created in a visual editor to be used elsewhere, an exporter that converts the graphical syntax to some OWL textual syntax is needed.
The goals of this article are: (i) to demonstrate a model-to-text transformation method allowing for modular and extensible OWLGrEd ontology diagram export into textual form; (ii) to show a grammar-based textual mapping language capable of defining correspondence between the graphical presentation of ontology constructs within OWLGrEd editor and their representation in the textual OWL Functional syntax (Motik et al., 2012) form.
The OWLGrEd ontology export is implemented using patterns that are ascribed to graphical abstract syntax elements.
The OWLGrEd tool graphical abstract syntax that is based on the nodes, edges and fields, and OWL ontology axioms in OWL Functional syntax have very different structures. A pattern-based language is one of the methods how to connect this structures. The patterns allow in a natural way to get together the model elements with a static text.
A pattern-based exporter allows to achieve a modular definition of ontology diagram semantics, by linking each ontology axiom to one basic construction in the graphical diagram to which this axiom is directly ascribed (the axiom may use also information from other locations in the graph, this information is gathered by means of path expressions relative to the axiom ascription point).
The pattern-based approach described in this article is also used in OWLGrEd extension definition Cerans et al., 2019), where the person that configures the extension (the OWLGrEd tool developers, or any other person) can write an extension field semantics definition in the language described here.
The approach developed here can be also used to translate to the textual representation models created in another graphical syntax within the GrTP/TDA modelling tool building platform (Barzdins et al., 2007) or a conceptually similar platform as ajoo (Sprogis, 2016). For instance, a visual notation for SHACL (Knublauch and Kontokostas, 2017) language for validating RDF graphs could be implemented either in GrTP/TDA or ajoo platform and the pattern-based export approach also could be applied there.
The pattern language has a simple interpreter that handles each of the constructions individually. The chosen pattern-based architecture of the exporter is expected to allow it to be transferred from its current implementation in Lua programing language (WEB, k) with lQuery library (Liepins, 2012) for data model support to another programming environment (such as e.g. JavaScript (WEB, d) with jQuery (WEB, f)).
The method of pattern-driven export described in this article can be alternatively implemented in frameworks such as Spoofax (Kats and Visser 2010) and Xtext (Voelter, 2006) that are intended for domain specific language development. This paper demonstrates the possibility and the involved structures for using the grammar-based mapping definition principles in practice without invoking a general-purpose framework and staying with the language means that are integrated within OWLGrEd technological environment.
The OWLGrEd editor export implementation is a typical Model-to-text solution. There are existing Model-to-text languages and tools such as Acceleo Query Language (AQL) (WEB, a), Epsilon Generation Language (WEB, b), Xpand (WEB, m), JET (WEB, e), MOFScript (WEB, g). Our Model-to-text transformation works directly within the environment OWLGrEd editor is implemented in. It can also serve as illustration for the constructs needed for the transformation in a practical example. The OWLGrEd export pattern notation has been announced in (Ovcinnikova and Cerans, 2016); it has not been explained in detail until this paper.
In the rest of the paper Section 2 reviews the OWLGrEd ontology editor together with its concrete and abstract syntax; Section 3 describes OWLGrEd editor export process and pattern language; Section 4 describes OWLGrEd extensions and their export, then Section 5 concludes the paper.

OWLGrEd Editor Syntax
OWLGrEd 1 provides a complete graphical notation for OWL 2, based on UML class diagrams. It visualizes OWL classes as UML classes, data properties as class attributes, object properties as associations, individuals as objects, cardinality restrictions on association domain class as UML cardinalities, etc. We enrich the UML class diagrams with the new extension notations, e.g. (cf. (Barzdins et al., 2010a;Barzdins et al., 2010c)) to provide visual notations for OWL constructs that do not have corresponding UML counterparts:  fields in classes for equivalent class, superclass and disjoint class expressions written in Manchester OWL syntax (Horridge and Peter 2012);  fields in associations and attributes for equivalent, disjoint and super properties and fields for property characteristics, e.g., functional, transitive, etc.;  connectors (as lines) for visualizing binary disjoint, equivalent, etc. axioms;  boxes with connectors for n-ary disjoint, equivalent, etc. axioms;  connectors (lines) for visualizing object property restrictions some, only, exactly, as well as cardinality restrictions. Figure 1 illustrates some basic OWLGrEd constructs of simple mini-University ontology. The notation is explained in more detail in (Barzdins et al., 2010a). The same ontology in OWL Functional syntax is can be found in Appendix 1. OWLGrEd provides option to specify class expressions in compact textual form rather than using separate graphical element for each logical item within a class expression. Expression can optionally be shown as an anonymous class (e.g. Student or Teacher in Figure 1). An anonymous class is also used as a base for property domain/range specification, if this domain/range is not a named class.

Fig. 1. A simple mini-University ontology in OWLGrEd
The OWLGrEd tool allows both for ontology authoring (with option to save the ontology in a standard textual format) and ontology visualization that includes automated ontology diagram formation and layouting step, followed by optional manual diagram fine tuning to obtain the highest quality rendering of the ontology.

Fig. 2. OWLGrEd abstract syntax metamodel (fragment)
OWLGrEd editor is implemented in the GrTP platform (Barzdins et al., 2007). The platform hosts both a visual diagramming engine (Barzdins et al., 2009) and a model repository with a model transformation environment for holding both the editor (e.g. OWLGrEd) configuration and the ontology diagram abstract syntax structure. An essential repository structure fragment for the OWLGrEd editor is shown in Figure 2. OWLGrEd diagram visual elements correspond to the classes Node and Edge, together with Compartment class that corresponds to the text fields placed in nodes and attached to edges. On the configuration side, NodeType and EdgeType classes correspond to the types of nodes and edges that are allowed in diagrams of the respective type. Every element type has an ordered collection of CompartType class instances attached to it. These instances correspond to the list of compartment types of the diagram elements of this type. Each compartment type may consist of one or several sub-compartment types. Element and compartment types have Tag class linked to them. OWLGrEd export patterns for the specific element or compartment types are stored in the Tag class instances. The full tool platform metamodel is best explained in detail in (Barzdins et al., 2010b). Figure 3 illustrates OWL class Person definition in OWLGrEd visual syntax, and the corresponding abstract syntax structure. The Person class box is represented in the OWLGrEd abstract structure as Node instance with NodeType equals to "Class". The Node instance has one compartment, with compartment type "Name", containing class name. Compartment type "Name" has Tag class instance, attached to it. This Tag instance contains export pattern for class declaration (export patterns are explained in Section 3). Name compartment has two sub-compartments with types "Name" and "Namespace", as well.

Fig. 3. OWLGrEd concrete and abstract syntax structures for a named class element (Person)
Another, wider OWLGrEd syntax example can be found in the Appendix 2. Full compartment type structure for the class element is in the Appendix 3. There are similarly organized structures for other visual OWLGrEd diagram elements, as well.

Ontology export process and patterns
Graphical ontology diagram translation into the textual format, includes rendering of the graphical ontology diagram, from Figure 1, into OWLGrEd abstract syntax (performed while editing the diagram) corresponding to Figure 2 and explicit abstract syntax translation into the text. In this section the way, how the abstract syntax translation into the text is realized in the OWLGrEd tool, is described. :CompartType id = "Name" :CompartType id = "Name" :CompartType id = "Namespace" :Tag key = "ExportAxiom" value = "Declaration(Class($getUri(/Name /Namespace)))"

Person
:Compartment value = "Person" input = "Person" To ensure the OWLGrEd ontology export into OWL 2 syntax, an export pattern language and its parser was created. The parser translates the export patterns into OWL 2 Functional syntax that can be later transformed into any popular OWL 2 syntax using OWL API (Horridge and Bechhofer, 2011). As a result of the mini-University ontology diagram, shown in Figure 1, export OWL Functional syntax representation of the Appendix 1 is obtained.
The patterns are ascribed as Tag class instances to the type elements (cf. Figure 2, 3) and are evaluated in the context of the respective data element.
Each element or compartment type in OWLGrEd editor that represents an OWL 2 axiom has information about defined export patterns stored in Tag instance attached to it. OWLGrEd exporter walks through all diagram elements and compartments, that corresponding type has the export tag connected to it, parses the export pattern, and, using the parsing result and ontology diagram data, generates the OWL Functional syntax axiom. Figure 4 illustrates OWLGrEd export pattern top-level structure. OWL export pattern consists of the following structural constructions:  Text fragment constructionthe part of OWL Functional syntax axiom text, such as axiom name. In the export pattern language these expressions are written in plain text.  Structured Expression constructionstarts with Text fragment (axiom name), followed by the list of expressions. Can be used e.g. as top-level expression constructions for the OWL Functional syntax axiom.  Path expression constructiondefines the path from the current location in the type structure to the required data. Can be used either directly (the result will be the compartment or the compartment set located in the given path) or as path before function or condition construction (function/condition construction will calculate the result from the location the path is pointing to). Each path element construction consists of "/" symbol and the sub-compartment type name. The two dots represent navigation to the parent level in the compartment type structure.  Function constructionretrieves data from repository, calculates and returns axiom fragment (or textual value that can be used otherwise). Function construction starts with "$" symbol, followed by the function name and optional function arguments (path expressions) in brackets.  Condition constructionchecks, whether the axiom or axiom fragment can be applied based on the given data. Condition construction is included in square brackets. Condition may consist of several OR condition parts separated by "||" where each OR condition part consists of a first argument, an operator and a second argument. Each argument can be a path expression, a function or a constant value such as a number or a string. Several conditions can be followed by each other. In this case, all conditions must be true for the axiom or axiom fragment to be generated.  Optional constructiondefines an axiom fragment that is optional in a given axiom. Optional construction starts with "?" symbol, followed by optional axiom definition part in brackets. Optional construction block consists of one or several expressions. Expression may be any export pattern language top-level structure (cf. Figure 4.).  Mandatory constructiondefines an axiom fragment that is mandatory in the axiom. Mandatory expression starts with "!" symbol, followed by several optional constructions in brackets, where exactly one of the optional constructions is required. The OWLGrEd export pattern example with highlighted pattern constructions, is shown in Figure 5. Each element or compartment type may have more than one export pattern. If at least one condition or the mandatory construction in a pattern is not fulfilled, the pattern will not generate the OWL axiom. The classification and description of the functions used in the ontology export pattern definition, is given in the following list: Use context information of the entire diagram (e.g. full namespace URIs, diagram class name list, etc.):  getUri(compartment Name, compartment Namespace). Returns ontology element URI for the given Name and optional Namespace compartments. If Namespace compartment is not specified, the ontology local namespace is used. If both compartments are not specified, the current context compartment is used as Name argument.

Perform a search for another structural element (by a specified path, condition):
 getClassExpr(element Class). Returns a class expression for the given class element. The function can be called without arguments from a class element or its compartment context, or it can be called from explicitly specified (e.g. by a path expression) class element or a class element set. For each class element found, the function goes down to its Name compartment and generates the class URI. If the class is anonymous, i.e. there is no class name, (cf. class Student or Teacher in Figure 1), the function goes down in the compartment structure into the first EquivalentClass compartment and generates the axiom fragment (Barzdins et al., 2010c)  Returns an element type of the current context element.  count. Returns instance count of the given element set.  getContainer. Returns the name of the container where the current element is located.  isURI. Checks, if the compartment value is URI. Used for Annotation generation.  isEmpty. Checks, if the compartment exists. The export pattern language functions uses an information from the so-called aspects the lists of the different sorts of the ontology information.
 Object property listthe list of all object properties in the diagram.   6. Export pattern functions and aspects interconnection Figure 6 shows interconnection of the export pattern functions and aspects. For example, to translate an expression from the OWL Manchester syntax into functional syntax, function getFSExpression uses an ontology prefix definitions, a list of object properties, a list of data types and a built in data type prefixes definitions. Figure 7 illustrates the generation of the Class declaration axiom. Generation of the Class declaration axiom starts from the compartment that is connected to the compartType whose id equal to "Name". This compartment type has an export pattern, stored in a related Tag instance. The export pattern for the class declaration is defined as the following string: "Declaration(Class($getUri(/Name /Namespace)))". The first part of the export pattern: "Declaration(Class(" is a text fragment construction and it will be translated into OWL axiom as it is. The function getUri has two arguments /Name and /Namespace indicating that from the current Name compartment we need to go one level down in the compartment tree structure and find sub-compartments connected to the compartment types whose id are equal to "Name" and "Namespace" respectively. Then function getUri, based on these two compartment values, generates the class URI. Since the namespace compartment is empty, the ontology local namespace is used. The export pattern ends with another text fragment construction "))", and the class declaration axiom is completed. Since the text generation patterns are defined on the level of the abstract syntax of the ontology editor, they could be applied also for other notations that are defined on the basis of GrTP/TDA tool building metamodel. Such notations, besides the OWLGrEd editor, include e.g. UML Class, Activity, UseCase and StateChart diagrams, as developed within the GradeTwo tool (WEB, c)

OWLGrEd Extensions
The OWLGrEd ontology editor provides an option to its end users to define extensions to its visual symbol appearance (Cerans et.al., 2013), (Cerans et.al., 2019). The ontology export pattern language, as described in Section 3, can be used in semantics definition for user-defined fields in OWLGrEd editor extensions. The user that configures the extension, writes the semantics expression herself, using the pattern language described here.
In general, the editor extensions with symbol fields and graphical effects enhance the ontology presentation options by introducing domain-specific notations into the ontology presentation; they are handled by a generic User Fields extension  that is currently part of the default OWLGrEd editor configuration.
The available editor enhancements, supported by the User Fields extension include:  custom fields, together with their semantics mappings (e.g. "enumerated class");  custom visual effects for text and choice fields and symbols dependent on concrete text or choice field values (e.g. a brown/darker enumerated class color);  views applying certain visual effects to the entire diagram (e.g. hiding certain information from the presentation).

Fig. 8. User Fields extension dialog for semantic pattern definition
The user-defined fields are created by filling in instances of a User Fields configuration model described in , including for each field user can specify the corresponding semantics expression pattern. Figure 8 demonstrates the User Fields extension dialog for the semantic pattern definition, involving also field semantics definition within the described pattern language. Fig. 9. An ontology example with custom user-defined field Figure 9 shows, an ontology diagram example with the custom user-defined field, as well as OWL Functional syntax axioms generated from it. A Teacher_Level class has check-box field "isEnumerated" for enumerated classes that, when checked, attaches the stereotype <<EnumClass>> to the class symbol and changes its background color to slightly darker (orange-brown). The user-defined field can be associated with the export pattern that is translated into this field during the ontology import and that is produced during the ontology saving in the textual notation. The User Fields extension in the export uses the same pattern language as the basic OWLGrEd export. For instance, the stereotype at the Teacher_Level class has the export pattern attached to it: AnnotationAssertion(owlgred:isEnumerated $subject "true"), and is saved to the: AnnotationAssertion(owlgred:isEnumerated :Teacher_Level "true") OWL axiom.

Conclusions
The article has shown the possibility to create the visual OWLGrEd ontology export into the textual format by means of a structured export process, split over diagram syntactic elements.
For each visual diagram element, the corresponding OWL Functional syntax axiom text is generated by a simple pattern language, built over a small set of implemented context lookup, abstract syntax navigation and text transformation primitives. The principal classes of functions necessary for the transformation have been: use context information of the entire diagram, perform a search for another structural element, perform a syntax transformation, aggregate information from multiple structural elements, perform selection of certain types of information and get supporting information.
Declarative definitions of the correspondence between the OWLGrEd constructs and the OWL axioms relevant parts allows any diagram (even if the diagram is not complete) to be interpreted as an OWL ontology.
The modular architecture of the OWL axiom text exporter is important for further definition of OWLGrEd extensions that are principal in OWLGrEd practical applications (cf. (Cerans et al., 2019)). The architecture enables maintaining the OWLGrEd editor, as well (e.g. by introducing the changes to the configuration structure).
Described pattern-based language can be used outside the OWLGrEd tool, for the translation of other graphical models, like a possible graphical notation of SHACL language, if implemented within GrTP or ajoo platform, into the textual form.
The pattern-based structural OWLGrEd export implementation is expected to support also the envisaged migration of the editor to a more user-friendly web environment: only the generic language interpreter and the specific function implementations would need to be migrated from the current Lua/lQuery environment to the JavaScript/jQuery to achieve the ontology export from the editor in the new environment.

Appendix 2. OWLGrEd abstract syntax example
Appendix 3. OWLGrEd class node type structure