Sage Journals: Discover world-class research

Abstract

Although the Semantic Web Rule Language (SWRL) is not a W3C standard, it is widely used for semantic web-based projects as well as for innovative rule-based applications. Thereby, it is used to infer new knowledge from a given fact base. Today, SWRL rules are developed and managed by technical experts in text-based editors using software applications such as the Stanford Protégé toolkit. In this paper we present a visual approach which allows users to analyse and modify SWRL rules. By building upon a visual modeling language, the approach includes validation mechanisms and layouting algorithms for visually representing new as well as existing rules. The approach further provides import and export interfaces to common SWRL exchange formats. In this way, its compatibility with widely-used reasoners and semantic web platforms is guaranteed. For ensuring its feasibility, the approach has been prototypically realized using the SeMFIS platform and evaluated using the sample rules as provided in the SWRL specification.

Keywords

SWRL OWL modeling language semantic processing SeMFIS

1. Introduction

Rule-based systems as well as the corresponding formalisms constituted for a long time an important research area for expert systems [61]. Today, they have become popular again, especially for semantic web-based applications and for enterprise information systems [60]. For example, in the domain of enterprise information systems, rules are today being applied for specifying business process decisions and constraints as well as for compliance checking, e.g. [18,54]. The Semantic Web Rule Language (SWRL) is thereby considered as a prominent technology towards the semantic web that is adequate for many types of information systems [52]. So, it is supported by reasoners, e.g. Pellet [29] and HermiT [30], rule engines, e.g. Jess1

¹
https://www.jessrules.com/links/
and Drools2 ²
https://github.com/protegeproject/swrlapi-drools-engine/wiki/SWRLAPI-Drools-Engine
and semantic web applications, e.g. Stanford Protégé [50]. In particular, SWRL is a sound and well-established technique for deriving new facts from a given fact base. Hence, the need for comprehensive SWRL editors is obvious and explicitly mentioned in the scientific community, e.g. [29,39,59]. Today, SWRL rules are usually developed and modified using text-based editors such as the Protégé SWRL tab [52]. The text-based representation is convenient for technical experts but comes in a mathematical notation, which is not common to many domain experts. The representation thus obviously impedes a more wide-spread adoption of SWRL. Recently, Skillen et al. developed a visual approach for defining SWRL rules and presented a first empirical evaluation of it which shows that both, business users and technical experts could benefit from it in terms of understandability and development time [59]. The subsequently developed visual modeling language shows a strong focus on usability but does not support all SWRL concepts [59]. Further, the import function as well as the handling of the underlying OWL ontology is limited – see Section 2 for an in-depth discussion.

In a previous paper we therefore proposed a first idea for a visual modeling language that covers all concepts of SWRL [22]. The paper at hand extends this idea and contains an in-depth description of a comprehensive, visual modeling approach for SWRL. A main goal is to realize a modeling language that includes all necessary constructs in a visual form. In more detail, this led us to the following list of requirements for such a modeling approach: (i) Visual modeling of all atoms as defined in the SWRL specification, (ii) Explicit visual representation of variables and data values, (iii) Linkage to visually represented OWL ontologies using the previously developed SeMFIS modeling language [19,26], (iv) Serialization and De-serialization of visual SWRL models in OWL-XML syntax, (v) Prototypical implementation of the approach to evaluate its feasibility.

In this paper we describe how we met these requirements. In particular, the contributions are as follows:

Detailed description of the metamodel of the visual modeling language,

Formalization of the modeling language for an implementation-independent representation,

Development of implementation-independent rules for transforming the model to concrete syntax representations and vice versa,

Description of the prototypical implementation using the SeMFIS platform based on ADOxx [21]

This work is driven by the vision of creating a visual modeling language for SWRL that can be used both for use cases dealing with the analysis of existing SWRL rules, e.g. to enhance the understanding of a rule, as well as for use cases where SWRL rules have to be specified by non-technical experts, e.g. to conduct compliance checking by business users [54]. While the visual approach might boost understandability (see [59]), a systematic empirical evaluation of the usability will be part of our future research.

The remainder of the paper is structured as follows: In Section 2 foundations of conceptual modeling and SWRL as well as related work is analyzed. The modeling language for SWRL is introduced in Section 3. In Section 4 the transformation from the SWRL model to a SWRL syntax and vice versa is introduced. The technical implementation of the approach is introduced in Section 5 followed by a use case which is presented in Section 6. In Section 7 the limitations of the approach are discussed. The paper ends with a conclusion in Section 8.
2. Foundations and related work

In this section we discuss at first foundations of conceptual modeling that are necessary for describing our approach. This includes a characterization of modeling methods as it is typically used in the area of enterprise modeling and the formalization of modeling languages. Second, we regard the contents of the W3C SWRL proposal that is the basis for the subsequently presented modeling language.

2.1. Foundations of conceptual modeling methods

According to Karagiannis and Kühn, a modeling method consists of (i) a modeling language, which encompasses a visual notation, syntax and semantics, (ii) a modeling procedure, which describes how to use a modeling language, and (iii) algorithms and mechanisms, which can be applied to the models [38]. In the paper at hand we focus on the description of the modeling language as well as on algorithms and mechanisms.

For describing modeling languages, specific formalisms have been designed in the past [11,63]. Examples include EMF [58] or a specific formalism for the UML OCL specification.3

³
http://www.omg.org/spec/OCL/2.0/
Each modeling tool usually uses a meta-metamodel, e.g. Eclipse-based modeling tools use ECore,4 ⁴
https://www.eclipse.org/modeling/emf/
Meta-Edit-based modeling tools use GOPRR5 ⁵
http://www.metacase.com/support/45/manuals/graphical%20metamodeling.pdf
and ADOxx-based modeling tools use the ADOxx meta-metamodel. Hence, the selection of an appropriate formalism for describing a metamodel is mainly driven by the modeling tool which is used for its implementation. For our purposes, we decided to use the F ormalism for D escribing ADOxx M eta Models and M odels (FDMM) [23]. It has been used for formalizing a wide variety of modeling languages in the past, e.g. [20,28,37]. FDMM supports the core concepts of the ADOxx metamodeling platform, which we use in Sections 5 and 6 of this paper for the implementation and evaluation of our approach. A main benefit of the ADOxx metamodeling platform is that it provides algorithms out of the box with the ADOscript language6 ⁶
https://www.adoxx.org/live/adoscript-documentation
– we leverage this feature for the algorithms described in Section 5. Additionally, we worked in previous projects with this platform (see e.g. [56]) which encouraged us to continue working with ADOxx.

In FDMM, a metamodel $MM$ of a modeling language is described using four components, i.e. $MM = ⟨ MT, ⪯, domain, range, card ⟩$ . Each metamodel consists of a set model types $MT$ which are used to create a set of models $mt$ . Each model type $M T_{i}$ consists of a set of object types $O_{i}^{T}$ , a set of attributes $A_{i}$ and a set of datatypes $D_{i}^{T}$ . A model type is thus described in FDMM by $M T_{i} = ⟨ O_{i}^{T}, D_{i}^{T} A_{i} ⟩$ . The operator ⪯ is an ordering on the set of object types $O_{i}^{T}$ that is used to define an object type hierarchy similar to inheritance hierarchies in object oriented software languages.

$domain$ is a function which assigns attributes to object types. The $range$ function assigns datatypes, other object types and model types to attributes, while the card function defines the cardinality, i.e. the number of allowed values for an attribute. For describing the instantiation of model types to models, object types to objects, and data types to concrete data values, the functions $μ_{mt}$ , $μ_{O}$ , and $μ_{D}$ are used, which basically take a type from the metamodel as input and map it to a set of instances of this type.

A model $m t_{i}$ is an instance of a particular model type and consists of so-called triple statements $τ_{j} : (o_{j} a_{j} d_{j})$ representing the model content. The first element $o_{j}$ of a triple $τ_{j}$ represents an instance of an object type, the second component $a_{j}$ represents an attribute and the last component $d_{j}$ represents the value for the attribute $a_{j}$ . The assignment of triples to models is accomplished via the map $β : mt \to P (τ)$ . For further details on FDMM especially regarding instantiation functions and additional constraints and correctness criteria we refer to [23].
2.2. Concepts of the Semantic Web Rule Language

The specification of the Semantic Web Rule Language (SWRL) is available as a proposal by Horrocks et al. on the W3C website [35]. SWRL is defined as an ontology – called SWRL ontology – which integrates RuleML7

⁷
http://ruleml.org/index.html
and OWL. Due to the strong reference to OWL, SWRL can be rather seen as an OWL-extension [17]. SWRL rules have several benefits over existing OWL axioms such as higher expressiveness and less restrictions [29]. The SWRL proposal introduces an XML- and RDF-based syntax [35], whereby it refers to the OWL specification [45] for the corresponding syntax of the underlying OWL elements. In 2006, Brockmans et al. introduced in [14] the first metamodel for the proposed SWRL using the Meta Object Facility (MOF) to foster the usage of the SWRL in UML tools and thus align it to standards. However, even today the SWRL [35] is still no W3C standard.

A SWRL rule consists of an antecedent – denoted as body – and a consequent – denoted as head. Both, the antecedent and the consequent consist of a possibly empty set of atoms, which are connected using conjunctions. Therefore, the order of the atoms belonging either to the consequent or the antecedent has no semantic implication for a rule. The SWRL proposal distinguishes between seven different atoms. All atoms have parameters, which are either OWL constructs – such as references to OWL classes, variables or data values. For example, the Class atom of the SWRL specification has a parameter which refers to an OWL class. Also, the IndidvidualProperty atom has a parameter which refers to an OWL property.

The proposal for OWL 2 [49] was published a few years later after the release of the SWRL proposal in 2004. Thereby, SWRL rules were not added to the OWL 2 proposal. Rather, the introduction of OWL 2 raised compatibility issues with the SWRL proposal. Glimm et. al. [29] state that the existing rule syntax of the SWRL proposal is “not very well aligned with the new OWL 2 syntax”.

So, they developed an updated SWRL version to align it with the OWL 2 proposal [29]. The updated version is intended as a substitute of the SWRL proposal issued by the W3C [35]. For ensuring decidability, primarily two restrictions are introduced – for more details we refer to [29]: (i) Safety: Variables which occur in the consequent have to occur in the antecedent (ii) DL Safety: Individuals which are used in rules have to bind to existing individuals of the ontology. Further, each data variable in a data range atom has to occur in a data property atom in the antecedent.

For describing the syntax of the updated SWRL, Glimm et. al. reverted to the generic functional syntax. The updated SWRL – which we will use as foundation for our subsequent elaborations – is widely supported by reasoners, e.g. Pellet [29] and HermiT [30].

Today, a variety of syntaxes for OWL 2 ontologies exist. For example, the current version of Stanford Protégé [50] offers eight different syntaxes for serializing ontologies. However, the OWL-XML syntax of the W3C SWRL proposal [35] is currently not supported by this platform.8 ⁸
The files provided at https://www.w3.org/Submission/SWRL/ can therefore not be imported to the Protégé default setup (Status: 17/08/2017).
A good overview of the different OWL syntaxes and their development is given by Horridge in his Ontogenesis blog [34], who stresses the fact that the definition of OWL does not rest on a particular concrete syntax but is rather based on a high level structural specification that is subsequently mapped into different concrete syntaxes. Such a structural description for the OWL 2 is given in [49], where the W3C proposal reverts to the functional syntax – a simple text-based syntax that operates as a bridge to concrete syntaxes [34]. A derivation from the functional to a concrete syntax is then for example described in [8], where the development of the OWL-XML syntax based on OWL 2’s functional syntax is explained. Each of the syntaxes has strengths and weaknesses [34]. E.g., the OWL-XML syntax – which we used in our use case – benefits from a strong support of existing XML-tools. Similar to the approaches used for OWL 2, concrete syntaxes can be derived from the functional SWRL syntax specified in [29].

In addition to SWRL, a couple of related rule languages exist, which are summarized in the following – a good overview is presented e.g. in [3]. In 2009, the W3C released the first working draft on the Rule Interchange Format (RIF)9 ⁹
https://www.w3.org/TR/2009/WD-rif-overview-20091001/
and today parts of RIF are available as a W3C recommendation.10 ¹⁰
https://www.w3.org/TR/rif-overview/
The corresponding RIF working group aims for describing a standard for exchanging rules among rule systems, in particular among Web rule engines. Due to the wide variety of rules (first-order, logic-programming, and action rules), the creation of such an exchange format is challenging. SPARQL Inferencing Notation (SPIN) is as W3C member submission11 ¹¹
https://www.w3.org/Submission/spin-overview/
released in 2011. It is directed towards merging the ontology query language SPARQL with rule-based approaches. SPIN rules can be executed directly on databases and have a higher expressiveness than SWRL [7]. Recently, the Shapes Constraint Language (SHACL) was accepted as W3C recommendation.12 ¹²
https://www.w3.org/TR/shacl/
It can be considered as an extension to SPIN with a couple of additional features such as support for user defined JavaScript functions. A detailed comparison between SPIN and SHCAL has recently been issued by Holger Knublauch.13 ¹³
http://spinrdf.org/spin-shacl.html
There are a couple of approaches which try to improve interoperability between the different rule languages. For example, Bassiliades describes a tool which enables the transformation from SWRL to SPIN [7], whereas the before mentioned RIF tries to establish an interchange format between different rule languages.

SWRL rules are heavily used in industry and in the scientific community. Recently, SWRL rules were used for language processing [40], food selection systems [51], health care [16], annotation of media data [10,44], communication protocols [2] and risk management [56]. Applications and frameworks which use or support SWRL rules are e.g. Menthor Editor [48], RuQAR [6], or i-RM [41]. SWRL also served as a starting point for novel rule-based formalisms and approaches. For example, a fuzzy extension for SWRL was introduced in [64]. Jajaga et al. developed a SWRL-based language called C-SWRL for reasoning over stream data [36] and in [12] an approach was introduced for identifying dependencies between SWRL rules.
2.3. Visualization approaches of SWRL rules

To the best of the authors knowledge, a comprehensive visual language for SWRL rules has so far not been made available. Although a generic metamodel for supporting the creation of visual rules was introduced in [15], this approach does not support all SWRL atoms. A visual language for SWRL was introduced in [42,43] which neither supports the import of existing SWRL models nor the different built-in types defined in SWRL.

A further implementation presented in [5] neglects export functionalities, the visualization of SWRL atoms as well as OWL constructs. The SWRLTab bundled with Stanford Protégé allows a text-based modification of rules. In the same way, the ORE editor offers a text-based editing of rules.14

¹⁴
https://sourceforge.net/projects/ore/files/?source=navbar
Mei and Boley interpret SWRL rules as RDF graphs, which can also be used for their visualization [46]. Following this approach, a couple of challenges occur, e.g. as the RDF semantics does not allow variables as predicates. With a focus on the adaption of the model-theoretic semantics of SWRL, the approach does not introduce a concrete metamodel or visualization tool for SWRL. Axiome is a Protégé plugin for the visualization of SWRL rules [33]. Modifications of rules are not supported. Akbari et al. present a two step transformation process – from SWRL to PSOA RuleML rules and then to the Graphviz DOT language – so that the rule can be rendered as Grailog graph by Graphviz [1]. With a focus on the transformation process, a modification of the visual representation as well as a backward-transformation to SWRL is not foreseen. Skillen et al. [59] presented a tool for the visual programming of SWRL rules. With a strong focus on usability, that approach does not support all atoms, e.g. it misses the BuiltIn atoms. Further, the import of SWRL rules was not considered in this work and the modification of OWL ontologies is not supported. Rule editing using REST webservices was introduced in [39]. In [57] a plugin is presented which allows to create OWL ontologies by entering textual rules. As summary of further tools is given in [59]. An excellent paper on visualization approaches of ontologies and rules was published by Harold Boley in [9]: here different visualization approaches are elaborated. In [55] the authors describe an approach for transforming enterprise models to linked data.

In summary, our related work analysis shows that a tool for the visual creation and editing of SWRL rules does not exist yet. Although certain attempts have been made in this direction, a more complete and systematic approach for a visual, model-based representation of SWRL is needed.
3. A visual modeling approach for SWRL

The visual modeling approach for SWRL that we present in the following is structured along three layers as depicted in Fig. 1. The configuration layer contains the SWRL model – a visual representation of SWRL rules – as well as the ontologies which are referenced by the SWRL model. The transformation layer is responsible for generating the SWRL rules from the SWRL model and for integrating them with the ontology. The result of this step are SWRL rules in a certain syntax, e.g. OWL-XML, including an ontology which can be processed in the execution layer.

The ontology can either be stored as a file, as an in-memory data structure or as a visual model. In this section we focus on the visual modeling language for SWRL rules which consists of the (i) syntax, (ii) a visual notation, (iii) and semantics [38].

Fig. 1.

Layers of the visual modeling approach for SWRL.

3.1. Syntax

The syntax describes the model elements and valid combinations of them [31]. For the description of the syntax of visual modeling languages, it is often reverted to semi-formal visual metamodels [24,27].

For the development of the modeling language we tried to balance the trade-offs between expressiveness and usability. For example, a large number of object types simplifies the transformation of the model on the transformation layer. On the contrary, large numbers of object types aggravate modeling. Moody denotes this trade-off as Graph Economy, which is further affected by the usage of attributes [47]. Modeling languages without attributes have to provide additional object types as well as references in order to encode the corresponding information. In practice, both approaches exist. Prominent languages such as ArchiMate [4] use only object types without attributes, while other languages such as UML [62] or BPMN [13] employ object types together with attributes extensively. Usually, these attributes are not displayed in models so that modeling tools offer property windows for accessing them – see for example the modeling tools in the OMiLAB.org repository.15

¹⁵
See http://www.omilab.org/psm/modelling-tools.

Fig. 2.
Excerpt of the SWRL metamodel which is integrated with the OWL metamodel, bottom shows an excerpt of the metamodel of the serialization.

An excerpt of the metamodel of the SWRL modeling language in UML class diagram notation is depicted in Fig. 2. It is grouped into three parts: an OWL part, a SWRL part, and a SWRL serialization part. The OWL part and the SWRL part correspond to the configuration layer. The SWRL serialization part in the bottom of the figure belongs to the transformation layer and will be discussed later on. The boxes are UML classes, which are used to represent object types. The classes with names in italics are abstract. These classes do not have a visual representation and can therefore not be instantiated by modelers. The solid connector which has an unfilled triangle (⊲) at its end is used to establish a hierarchy between classes similar to inheritance in object oriented programming languages such as Java. It corresponds to the ⪯ operator in FDMM as described in Section 2.1.

The classes ClassAtom or IndividualPropertyAtom are therefore sub-classes of the class Atom. The UML associations which end with an arrow (←) and which are annotated with the tag [ConnectorType] represent object types that connect other object types. Instances of this type thus stand for edges between objects in a model instance. Finally, the UML associations which are annotated with the tag [ModelHyperlink] represent reference attributes. Such reference attributes can be considered as model hyperlinks to other model elements or models. They are not necessarily displayed in a model but are used to navigate between model elements. In the following, we summarize the most important design decisions for developing the metamodel:

Classes/object types To ensure semiotic clarity (cf. [47]) we mapped each core concept of SWRL to one object type. Therefore, each atom defined in the SWRL standard is represented by a single object type in the visual language and vice versa. Indeed, we splitted the SWRL atom DataRangeAtom up in two atoms: DataRangeAtom and DataRangeAtomList. This is because these two datarange atoms, which contain a datatype or data values, are semantically related, but their syntax is different. Hence, we distinguish between a DataRangeAtom object type containing a data type and a DataRangeAtomList object type containing a list of data values.

Attributes We decided to use the attributes in our metamodel to reduce the number of object types and thereby enhance usability. In the excerpt of the metamodel depicted in Fig. 2, we do not show all the attributes of the object types which we used in order to improve readability. Therefore, only a small set of the actually available attributes are included.

Terms Similar to the generic rule definition metamodel by Brockmans et al. [15], we represented the possible terms – IndividualVariable, IndividualConstant, DataVariable and DataConstant – as separate classes/object types, which may be more convenient for model users than a solution based on attributes. Using this approach, syntactical modeling errors can already be avoided at design time. For example, the use of data variables for atoms that do not have data parameters is thereby prohibited.

Placeholders If the ontology underlying a SWRL rule is also to be stored as a visual model, its metamodel has to be integrated with the one for the SWRL. To support this, we integrated the SWRL metamodel with the SeMFIS metamodel [19] for OWL, which we will require for the use case presented later in Section 6.

We specify model hyperlinks/references from the SWRL metamodel to the OWL metamodel for keeping the SWRL model self contained. This means that the transformation layer should be able to produce valid SWRL rules of the SWRL model, even if no OWL model exists. In total, four classes contain model hyperlinks to the OWL metamodel: (i) ClassAtom, (ii) IndividualPropertyAtom, (iii) DatavaluedPropertyAtom, (iv) IndividualConstant. IndividualPropertyAtom and DatavaluedPropertyAtom atoms may have a model hyperlink to the Property object type in the OWL model. The object type Atom references an OWL Class, which can either be anonymous or non-anonymous. All these elements have an attribute of data type String called Name. This string is used if no model hyperlink exists. An IndividualConstant can represent an OWL Individual via the model hyperlink RepresentsIndividual. The individual constant can be considered as a placeholder. If the OWL model does not exist, the constant can still be used by the atoms. An alternative to using model hyperlinks to individual constants would be to remove the individual constant from our metamodel and add model hyperlinks from the atoms directly to the OWL model. However this approach has the following drawback: if the OWL model does not exist, the atoms have an empty model hyperlink. The information that two atoms may use the same individual in the OWL model is lost. By using an individual constant object type, the atoms can reference the same individual constant, which in turn can reference an individual in the OWL model.
3.2. Notation

The visual notation of the most important object types is shown in Table 1. For the design of the visual notation we took into account the principles of Moody, in particular Dual Theory and Semantic Transparency [47]. Dual theory requires that graphical elements are enriched with a textual description. For high semantic transparency we used meaningful symbols or abbreviations for the notation. This resulted in the visual notation shown in Table 1.

For improving the readability of the notation we use dynamic notation. Such a notation changes based on certain attribute states of model elements [21,25]. I.e., textual information is dynamically added to symbols at run-time, as shown in Fig. 4. In the example, the names of the OWL elements are dynamically displayed below the atoms based on the current state of the reference attributes.

Table 1
Excerpt of the elements used for the SWRL modeling language [22]

3.3. Semantics

The modeling language was developed in order to create SWRL rules. Hence, the semantics of the model elements is identical to the corresponding concepts of the SWRL proposal and the updated version – see [35] and [29] for a detailed semantic description.

In the modeling method itself, no operational SWRL or OWL semantics are included, e.g. in the form of algorithms [32]. It is rather reverted to transformations from the model information to machine-processable representations as will be shown in the next section.

4. Transformation of SWRL models

The transformation layer is responsible for generating machine-processable SWRL rules from the SWRL models on the configuration layer. Therefore, transformation rules as well as a transformation engine is necessary as depicted in Fig. 3. The transformation rules describe how to transform the models to a concrete syntax. The transformation engine processes the models according to the given transformation rules.

Fig. 3.

Transformation rules and the transformation engine as parts of the transformation layer.

An example transformation is shown in Fig. 4, which represents Example 5.1-1 of the SWRL proposal [35]. The arrows between the atoms (round symbols with the letter ‘A’) and the properties (yellow symbols with the letter ‘P’) represent the model hyperlinks, which were added to the figure in order to improve readability. The visual SWRL rule is identical to the SWRL rule in the textual notation shown at the bottom of the figure. Such a textual notation is typically used on platforms such as Stanford Protégé. Each atom of the visual SWRL rule is transformed to the corresponding string in the textual SWRL rule.

Fig. 4.

Transformation of a visual SWRL rule to a textual SWRL rule.

In the following, we describe the core transformation rules for transforming visual SWRL models. Therefore, we first define both, the SWRL model as well as the serialization using a formalism. Based on the description, the transformation rules are introduced. The description of the serialization is based on the functional rule syntax of [29] and therefore independent of concrete syntaxes. With a focus on SWRL, we do not describe the transformation of OWL constructs such as OWL individuals or OWL properties in the following subsections. We also neglect the description of exception cases where e.g. referenced OWL concepts are missing in the model. However, we support these transformations in our prototype described in Section 6.

A description of the SWRL modeling language as well as it’s serialization using FDMM is given in Appendix A and B. For the following transformation rules we will only require a subset of this formalization. In particular, we will refer to the model type for OWL as ${MT}_{OWL}$ and the model type for the visual SWRL rules as ${MT}_{SWRL}$ . In addition, the serialization is also represented in FDMM via the model type ${MT}_{\overline{SWRL}}$ .

For navigating to an attribute, the FDMM formalism requires the use of triple statements. For example, consider an instance of an OWL Class $o_{Class} \in μ_{o} (Class, {MT}_{OWL})$ and an instance of ClassAtom $o_{ClassAtom} \in μ_{o} (ClassAtom, {MT}_{SWRL})$ . The ClassAtom instance shall now be part of an instance of a SWRL model $m_{SWRL} \in {MT}_{SWRL}$ and reference the OWL Class instance, i.e. $(o_{ClassAtom} RepresentsClass o_{Class}) \in β (m_{SWRL})$ . It shall also be ensured that for the OWL Class instance, the attribute IsAnonymous is set to the value ‘Y’ – which indicates to the user that the class instance is anonymous. I.e., $(o_{Class} IsAnonymous^{'} Y^{'}) \in β (m_{OWL})$ .

In the following we use an abbreviation for the navigation via triples by using a dot syntax similar to the Object Constraint Language (OCL) in UML. Thereby, the previously described two triples are summarized as follows: $o_{ClassAtom}$ .RepresentsClass.IsAnonmyous=‘Y’: the first element is an instance of an object type, while the elements are attribute names which are used to access the attribute value of the last attribute.

For the description of the rules, we will use the following arrow types. The left side of the arrow ⇒ shows the input value which the rule receives while the right side of the arrow shows the return value of the rule. The arrow ↦ is used as an operator to assign values to attributes. If the attribute is a set, then the value on the left side is added to the set. Even if the rules are independent from its concrete serialization, we use OWL-XML serialization examples to improve understandability.

4.1. Transformation rules

When designing transformation rules for the serialization of the visual SWRL models to OWL, some differences have to be taken into account beforehand. This concerns the following four aspects: i. Anonymous Classes, ii. Model Hyperlinks, iii. BuiltIn Terms, and iv. Variables. This will be discussed in more detail in the following.

(i) Anonymous Classes. In OWL ontologies, anonymous classes are classes without a name. In the model type ${MT}_{OWL}$ , Class elements have an attribute IsAnonymous which indicates whether the model element representing an OWL class is anonymous. An example is depicted in Fig. 5a which shows that class a is a subclass of b. Class $b^{A}$ is anonymous and defined as an intersection of the classes c and d.

Fig. 5.

OWL class hierarchy in schematic overview (left) and in the model (right).

Figure 5b shows the corresponding visual model of the OWL ontology using the SeMFIS modeling language for OWL [19]. Thereby, the class b is anonymous. Such properties are typically set by the user by reverting to property windows in a modeling tool. We will use this for the prototypical implementation of the modeling language – see Fig. 9. In the serialization ${MT}_{\overline{SWRL}}$ , such an attribute however does not exist. Hence, as shown for the corresponding serialization in OWL-XML in Listing 1, the anonymous class does not appear any more. Instead, its content is copied directly to the position where it is referenced. However, such an anonymous class could e.g. be referenced in ClassAtom elements. (ii) Model Hyperlinks. While the visual model makes use of model hyperlinks, e.g. for connecting OWL classes with class atoms or for defining hierarchies as described in the previous example, such hyperlinks do not exist in the serialization. For connecting e.g. OWL classes with class atoms, the ClassAtom element links to the corresponding OWL Class element via a reference attribute type. (iii) Variables. While in the model it is distinguished between different variables – IndividualVariable and DataVariable – the serialization does not distinguish between them.16 ¹⁶

The paper introducing the syntax we use here [29] is available at http://webont.org/owled/2009/papers/owled2009_submission_16.pdf were it does not distinguish between the variable, while the paper available at https://www.cs.ox.ac.uk/files/2445/rulesyntaxTR.pdf does make a distinction.

In the visual model, the variables are defined using separate object types to which the atoms refer using model hyperlinks. On the contrary, in the serialization variables are not defined separately – they are used directly in the atoms. (iv) BuiltIn Terms. The visual model provides a separate model element for BuiltIn terms to define an order of the terms. Similarly to the variables, the terms are not separately defined in the serialization, but they are used directly in the BuiltIn atom.

Listing 1:

Example for the serialization of an anonymous class in OWL-XML using the subclass axiom

Serialization of SWRL models With these considerations we can now advance to the transformation from visual SWRL models to a serialization. Thereby we focus on the description of the transformation of SWRL constructs. We will neglect OWL constructs such as individuals in the following rules.

The following rule ( $R 1$ ) describes the serialization of a ClassAtom element in a visual SWRL model:

If the referenced OWL Class is anonymous, then the content of the anonymous class becomes part of the class atom in the serialization. On the contrary, if the referenced class is not anonymous, then the corresponding OWL class is referenced in the serialization using its IRI. During the serialization, references to anonymous classes are usually resolved and the content of the anonymous class is inserted at the position it was referenced. However, complex anonymous classes require a special handling. For example, the ontology depicted in Fig. 6 results in the serialization shown in Listing 2 – assuming that the anonymous class $b^{A}$ is referenced by a ClassAtom element in the model.

Fig. 6.

Schematic overview of the model elements (class $b^{A}$ is anonymous).

As class atoms, but also complement of and sub class of class description axioms are allowed to contain only a single axiom such as intersection of or union of [29,35], the resolving strategy which puts the content of an anonymous class to the place it was referenced leads to invalid serializations – the class atom shown in listing 2 contains two axioms.

Listing 2:

Serialization of a class atom

This issue originates from a structural problem: anonymous classes can have multiple axioms but a class atom can only contain a single axiom. In order to create valid SWRL serializations even in such scenarios, we wrap the content of anonymous classes into an intersection of axiom in cases in which the class contains several class description axioms. However, this wrapping leads to a loss of information.

The following rule describes the transformation of the IndividualProperty atom. No anonymous properties are considered in the existing OWL metamodel.

For the serialization of the DatavaluedProperty atom, the data values need to be serialized either to a variable or to a literal:

The serialization of the DataRange atom is similar to the one of the DatavaluedProperty atom. However, the data type has to be considered:

For the DifferentIndividuals atom all individuals of the list individuals have to be serialized:

The transformation rule for the SameIndividuals atom is identical to the one of the DifferentIndividuals atom:

The model element DataRangeAtomList was introduced to simplify modeling – it is a special type of the DataRangeAtom:

The BuiltIn atom makes use of special term elements in the model:

The following rule is called within other rules for the serialization of OWL Class elements:

This rule is called to resolve the referenced OWL classes, e.g. in intersection of axioms:

With the following rule a helper rule for creating variables and literals is provided:

This rule is called for creating a wrapping intersection of axiom for other axioms:

This Rule is used for creating a variable used within atoms:

The following rule is called within other rules for the serialization of the OWL Class elements:

The following rule is called for creating a list of values used in DataRangeAtoms:

Deserialization to SWRL models When rule descriptions that already exist in a serialized format shall be transformed into visual models, further transformation rules for this deserialization are required. These will be described in the following.

Due to the serialization, a loss of information occurs: the references to anonymous classes are replaced by the content of the class. If an anonymous class is called several times, its content is inserted several times in the serialization. In the serialization it is not possible to find out if two identical anonymous code sections result from the same class or from two different anonymous classes of the visual model. Further, it is not possible to find out if two class description axioms such as intersection of and union of, which are siblings (i.e. they belong to the same hierarchical level), occur from a single anonymous class or from two anonymous classes in the visual model.

Fig. 7.

Schematic OWL class relations (of the visual model) with identical serializations.

An example is depicted in Fig. 7. The classes $b^{A}$ , $b 1^{A}$ and $b 2^{A}$ are anonymous. The serialization of both ontologies is identical – see the corresponding Listing 4, which will be discussed later on. Given the serialization, it is not possible to identify the original model from which the serialization was generated as both models are valid for generating the given serialization. Therefore, we distinguish between two strategies for deserializing classes. These are denoted Non-anonymous Class Deserialization Strategy and Anonymous Class Deserialization Strategy.

Listing 3:

Non-anonymous class deserialization strategy

(i) Non-anonymous Class Deserialization Strategy. This strategy is used for deserializing non-anonymous classes to class elements of the visual model. We use an example for describing this strategy. Consider the serialization given in Listing 3. Class a is a non-anonymous class as it has a name (attribute IRI). The deserialization strategy creates for this serialization a visual model with a class element a representing the non-anonymous OWL class. It has model hyperlinks to the other classes to which it is related with the equivalent class axioms. For the given example, class a has hyperlinks to the classes b and c which represent the intersection of axiom. This strategy is also applied for other axioms such as union axioms or subclass axioms.

However, if the serialization has two identical axioms17 ¹⁷

Two axioms with the same name and which belong to the same class.

– such as the union axiom in the given example – then two anonymous classes are created in the model in order to avoid blurring the intended meaning. Instead of having direct hyperlinks to the classes d, e, f, and g, the class element a has hyperlinks to two anonymous class elements and the anonymous class elements reference to the classes d, e, f, and g. Hence, the resulting model element which represents class a, has a hyperlink to the two anonymous classes i, j which point to the model elements contained in the axioms:

a, i, j, d, e, f, g \in μ_{o} (OWLClass, {MT}_{OWL})

a . UnionOf = {i, j}

i . UnionOf = {d, e}

j . UnionOf = {f, g}

Listing 4:

Anonymous class deserialization strategy

(ii) Anonymous Class Deserialization Strategy. We identified two different resolution strategies for anonymous classes which we want to illustrate using the serialization shown in Listing 4. The content of the first ObjectIntersectionOf element contains anonymous classes – class description axioms within other class description axioms.

We identified two fundamental strategies for their deserialization: (a) Single Class Strategy . This strategy creates a single anonymous class i for the class description axioms which occur in other class description axioms. So we get a class element which has two lists of model hyperlinks representing the intersection axiom as well as the union axiom: $i, a, c, d, e \in μ_{o} (OWLClass, {MT}_{OWL})$ , $a . IntersectionOf = {i}$ , $i . UnionOf = {e, f}$ , $i . IntersectionOf = {c, d}$ . In other words, the strategy groups the axioms to a single class. Thereby, it makes the implicit assumption that all axioms belong to a single class. (b) Multiple Class Strategy . Unlike the single class strategy, this strategy does not group the axioms to a single class. For each axiom, a separate anonymous class is created. So, for the given listing, two anonymous classes i, j are created: $i, j, a, c, d, e, f \in μ_{o} (OWLClass, {MT}_{OWL})$ , $a . IntersectionOf = {i, j}$ , $i . UnionOf = {e, f}$ , $j . IntersectionOf = {c, d}$ .

As the example illustrates, the multiple class strategy usually results in the creation of more anonymous classes than the single class strategy. In the following rules, we revert to the multiple class strategy as it does not make any assumptions regarding the grouping.

Our metamodel distinguishes between four different types of terms. However, in the serialization only variables can be explicitly defined without distinguishing between individual variables and data variables. The atom which contains the variable has to be analyzed in order to find out if the variable is an individual variable or a data variable. If e.g. the defined variable is used as individual in a class atom, then this variable is an individual variable. If the variable is used in a BuiltIn atom, then the variable is a data variable.

The following rule describes the transformation of the Class atom. The serialized class atom either refers to an existing OWL class or it contains an anonymous class. The function rand() stands for a function that generates a random, unique string similar to the concept of UUIDs, which is used to distinguish the created model elements.

The following rule describes the deserialization of an IndividualProperty atom. Thereby, the individuals are transformed to variables due to the negligence of individual constants. Further, the reference to the property – using the name of the property – is resolved.

For the serialization of the DatavaluedProperty atom, the datavalues need to be serialized either to a variable or to a literal:

The introduced modeling language distinguishes between DataRangeAtom and DataRangeAtomList. Therefore, the following rule checks if a datatype exists in order to make a correct transformation:

For the DifferentIndividuals atom all individuals have to be serialized:

The transformation rule for the SameIndividuals atom is identical to the one of the DifferentIndividuals atom:

The BuiltIn atom makes use of special term elements in the model which are transformed separately:

The following rule is a helper rule for creating BuiltIn terms:

The following rule is a helper rule which creates either a non-anonymous class or an anonymous class. The latter is done in the empty else branch – we neglected it here with a focus on the serialization/deserialization of SWRL constructs:

The following transformation rule describes the creation of a variable that is created based on a name:

This rule creates or finds an OWL property based on a given string which contains the string:

The following transformation rule describes the creation of a variable which is created based on a name:

The following rule creates a dataconstant whereby the name is created randomly:

5. Prototypical technical implementation

In order to evaluate the feasibility of the presented approach, we created a prototypical technical implementation. This comprised the implementation of the visual modeling language as well as the transformation rules for the serialization and deserialization of the models. Figure 8 shows technologies and syntaxes used for the implementation.

Fig. 8.

Technologies used for implementing the configuration, transformation, and execution layer.

On the configuration layer we reverted to the SeMFIS platform, which offers a generic import and export interface for models in the ADOxml format. The transformation layer was realized using XSLT, and for the execution layer we used Stanford Protégé and the included APIs. In the following we will discuss the used technologies and platforms as well as the developed mechanisms and algorithms in more detail.

5.1. Technology and platforms

The modeling language was implemented by extending the SeMFIS platform [19], which is based on the metamodeling platform ADOxx [21]. The modeling languages for OWL ontologies as well as for frames ontologies are already part of SeMFIS. The introduced modeling language for SWRL references to constructs of the OWL modeling language. The attributes of the model elements can be accessed using a property window in SeMFIS. An excerpt of the property window of a class from the ontology model (see Fig. 5b) is depicted in Fig. 9. The entries of the listbox represent model hyperlinks to the class elements c and d.

Fig. 9.

Property window in SeMFIS for accessing attributes of model elements – example of class element b from the ontology model depicted in Fig. 5b.

In SeMFIS, each model can be exported to a generic, standardized XML format called ADOxml,18 ¹⁸

The schema is defined in https://www.adoxx.org/AdoScriptDoc/files/Message_Ports/Component_APIs/Documentation/XML_MODELS-js.html, accessed: 14.08.2017.

which is provided by the underlying metamodeling platform. ADOxml has a flat structure (limited hierarchy) and serves as input for the transformation layer.

The transformation layer has been realized with XSLT. It transforms ADOxml to OWL-XML and vice versa. The transformation layer has been integrated into the SeMFIS platform to ensure a seamless user experience.

For the implementation, the XSLT transformation engine Saxon19 ¹⁹

http://saxon.sourceforge.net/

was used. The resulting ontology together with the rules is stored in the OWL-XML syntax and can be processed in the execution layer. We used Stanford Protégé20 ²⁰

http://protege.stanford.edu/

for executing the generated ontology including the rules. Based on the transformation rules for the deserialization, also the import of existing rules in OWL-XML to the SeMFIS platform is supported.

5.2. Model algorithms and mechanisms

In addition to the import and export functionalities, we implemented further algorithms and mechanisms for the SWRL modeling language. In the following we focus on a layout and a validation algorithm.

Layouting OWL serializations do not contain any positioning information due to their lack of a graphical representation. To compensate for this, we used a layout algorithm that had been developed to ensure a proper positioning of model elements when importing SWRL rules [22,56]. An example is shown in Fig. 10, where a rule model is shown before and after the layout algorithm is applied.

Fig. 10.

Layout of imported models.

The basic working of the algorithm is as follows. For every serialization that is imported, the algorithm first positions the Antecedent and the Consequent elements at the top of the model so that the edge of type HasConsequent is positioned between them. Next, the atoms connected to the antecedent are positioned in a row below the antecedent, followed by atoms that are connected both to the antecedent and the consequent. The atoms that are only connected to the consequent are placed at the end of the row. In addition, separate rows of elements are created below for the variables and constant terms.

Table 2

Evaluation of the approach along the examples provided by the W3C

W3C Example	Rule	Supported by our Approach
Example 5.1-1	hasParent(?x1, ?x2) ^ hasBrother(?x2, ?x3) -> hasUncle(?x1, ?x3)	✓
Example 5.1-2	hasParent(?x1, ?x2) ^ hasSibling(?x2, ?x3) ^ hasSex(?x3, male) -> hasUncle(?x1, ?x3)	✓
Example 5.1-3	Artist(?x) ^ Style(?y) ^ artistStyle(?x, ?y) ^ creator(?x, ?z) -> period(?z, ?y)	✓
Example 5.1-4	Excerpt: LocationClass(?maploc) ^ psameLocation(?loc, ?maploc) ^ latitude(?loc, ?lat) ^ longitude(?loc, ?lon) -> latitude(?maploc, ?lat) ^ longitude(?maploc, ?lon)	✓
Example 5.1-5	lengthInFeet(?instance,?feet) -> swrlb:multiply(?inches,?feet) ^ lengthInInches(?instance,?inches)	✓
Example 5.1-6	hasStatus(?customer, Gold) ^ hasTotalPurchase(?customer, ?total) ^ swrlb:greaterThanOrEqual(?total, 500) -> hasDiscount(?customer, 10)	✓

In the ontology model, a separate row is created for all instances of a certain metaclass, the order is the following: Namespace, Class, Property, Instance, Predicate, AllDifferent and Package. The algorithm works in a responsive way, which means that if an entire row is being deleted, the objects below will “move up” one row if the layout algorithm is applied again.

Validating A basic validation algorithm has also been implemented for the SWRL modeling language. Before a rule is exported, it is checked if e.g. an antecedent and a consequent exists and if they are connected. Further, it is checked if the atoms are connected to either an antecedent or a consequent. In cases in which such a possible invalidity is detected, the modeler is shown a warning.

Currently, we are working together with ADOxx in order to create an installer which allows to use our software. Please visit our project page21 ²¹

http://austria.omilab.org/psm/content/semfis/info?view=home

were you can find the installer as soon as it is available.

Fig. 11.

Use case – export of model, processing and import of model.

6. Evaluation

For the evaluation of our approach, we took two directions. First, we evaluated our approach along the examples provided by the W3C in the SWRL proposal. These are used to illustrate the capabilities of SWRL and can therefore serve as examples that are easily accessible and well documented. Second, we applied our approach to a use case to assess how the approach would behave for an existing comprehensive rule set.

6.1. W3C examples

From a general perspective, artifacts in design-oriented and engineering research can be evaluated using different approaches [53]. In the case of the introduced visual modeling language for SWRL, the most important aspect was to assess, whether the models created with it conform to the recommendation by W3C for SWRL and its extension introduced [29]. We evaluated the completeness by modeling the example rules introduced in the SWRL recommendation.22

²²
https://www.w3.org/Submission/SWRL: examples 5.1-1–5.1-6
Each example was modeled using the introduced modeling method. Afterwards, we exported the SWRL model and manually inspected its serialization. The serialization was imported to Stanford Protégé in order find out if the widely used components such as the SWRLAPI23 ²³
https://github.com/protegeproject/swrlapi
and the OWLAPI24 ²⁴
https://github.com/owlcs/owlapi
are able to read the serialization. Finally, the SWRL ontology was exported using Protégé and re-imported to the extended SeMFIS platform. Table 2 shows that our approach supports also the other examples provided by the W3C.

We then modeled the SWRL rule presented in Example 5.1-3 of the SWRL recommendation25 ²⁵
https://www.w3.org/Submission/SWRL/#5.1
in Fig. 11. Moreover, we added an anonymous class to the referenced OWL model in order to illustrate how our serialization/deserialization approach works for anonymous classes. The top left corner of the figure shows the SWRL model, which has model hyperlinks to the OWL model. These two models are serialized to OWL-XML. An excerpt of the serialized code is shown in Listing 5. This serialization can e.g. be imported to Stanford Protégé, which offers a rule engine as well as a text-based editor for modifying and writing rules. Rules stored in a standardized syntax can be imported to our modeling toolkit as excerpts of the models depicted on the right upper corner show. The used layout algorithm determines the position of the modeling elements. This figure also reveals, that three anonymous classes are in the OWL ontology, while the initial model contains two anonymous classes. This is a result of the introduced multi-class strategy which we described before. Listing 5 shows the three axioms which result in an anonymous class: the two axioms contained in the ObjectIntersectionOf and the ObjectIntersectionOf axiom, which is contained in the UnionOf axiom in the second EquivalentClass axiom. In the use case, we did not use an anonymous class in e.g. the class atom, as it is not supported by the SWRLtab of Stanford Protégé.26 ²⁶
https://github.com/protegeproject/swrlapi/wiki/SWRLAPISWRLSyntax

Listing 5:
Excerpt of the serialization of the use case
6.2. Use case

In this section we describe how to use our approach for modifying an existing set of rules. Therefore we reverted to the SWRL rule set published within the Protégé project.27

²⁷
http://swrl.stanford.edu/ontologies/examples/family.swrl.owl
One of these rules is depicted on the top of Fig. 12. We imported the OWL-XML serialization of this rule set with our application. The visualizations of the rules are depicted in the center of Fig. 12. We removed other rules to improve the readability of the figure. In the extended SeMFIS modeling toolkit we added inter-alia an individual-valued property atom, termed hasParent, to a rule – the newly added atom is highlighted in Fig. 12. After adding the atom, we serialized the model so that it can be processed by SWRL rule engines. We exported the model to OWL-XML and re-imported it to Protégé where we added individuals in order to infer and test the modified set of rules. Figure 13 shows the modified rule in the Protégé SWRLTab editor before it was processed by a rule engine. In this way the round-trip from an existing rule set to our visual modeling approach and back to another platform could be positively tested.

Fig. 12.
Extended visualization of the rules (excerpt).

We plan further evaluations for assessing the performance of the introduced transformation rules. Additionally, usability tests and empirical studies are planned for testing the usability of the developed approach, e.g. to assess the ease of use of the modeling language and the features for manipulating SWRL rules in the form of models. This will have to include different stakeholder groups and domains to receive profound empirical evidence.
6.3. Feature comparison

In this section we present an initial feature comparison with TopBraid28

²⁸
https://www.topquadrant.com/products/, Trial Version, Accessed 14/08/2018.
and Gruff from AllegroGraph.29 ²⁹
https://franz.com/agraph/gruff/download/, Accessed 13/08/2018.
TopBraid is a tool supporting the creation and execution of SPIN and SHACL rules while Gruff is a universal tool for editing triples. In contrast to that, our implementation is a pure modelling approach.

TopBraid offers a tree-based modification and visualization approach for ontologies similar to Stanford Protégé. It further offers a graph and a diagram tab for the visualization of the relationships between entities such as OWL classes but not a visualization of rules. For the visualization of the relationships – which can be represented as a graph – three layouting options exist: (i) Layouting from top-to-bottom (ii) Layouting from bottom-to-top (iii) Layouting from left-to-right. Currently, we introduced a single layouting algorithm.

In TopBraid the rules have to be formalized in a textual way as the screenshot of Fig. 14 shows. As depicted in Fig. 15 TopBraid supports a visualization mechanism for a better analysis of SHACL rules. However, a mechanism which supports the construction of rules in a drag-and-drop manner was not identified within our analysis and correspondence with TopBraid.

AllegroGraph offers the Gruff toolkit (A Grapher-Based Triple-Store Browser for AllegroGraph) inter-alia for visually constructing SPARQL queries – we were unable to identify an approach for the visual construction of rules during our analysis and correspondence with AllegroGraph. The construction of the SPARQL queries is done via the context menu which allows to add e.g. predicates and variables and so complete SPARQL queries can be constructed as e.g. depicted in Fig. 16. A property window as e.g. shown in Fig. 9 does not exist as well as a drag-and-drop mechanism. Gruff offers a couple of layouting options such as a re-organization of the displayed graph which represents a SPARQL query. All tools allow to refer to existing ontologies. Syntactical validations and export/import functionalities are offered in our approach as well as in the two analyzed tools. Table 3 summarizes our findings.

Fig. 13.
Screenshot of a rule in the stanford protégé editor.

Fig. 14.
Screenshot of a rule-construction in the TopBraid editor.

Fig. 15.
Screenshot of a rule visualization in the TopBraid editor.

Fig. 16.
Creation of a visual SPARQL query using gruff.
7. Discussion and limitations

In industrial settings, the support of non-technical users for managing complex formalisms and formal systems is essential [22]. An initial empirical study, which identified a possible usability benefit of visualized rules, was introduced in [59]. In the study, it was found that the visual approach outperforms the text-based approach in all measured categories in both user groups – experts and novices. However, further empirical evaluation will be necessary due to the small sample size. With the presented visual modeling language for SWRL, domain experts can use the predefined modeling elements and algorithms for composing rules. In this way, the modeling language can be considered as a substitution for the widely-used text-based syntax for SWRL rules. The described visual approach is also useful for visualizing existing rules to domain experts which have to document, improve and inspect them.

Compared to the textual syntax, the introduced modeling language is able to re-use existing rule parts. The independence of our tool requires the usage of standardized serialization formats. Therefore, we implemented in addition to the validation and layout algorithms, import and export facilities for the standardized OWL-XML syntax. This enables compatibility with semantic web platforms such as Stanford Proégé and other industry applications.

The introduced visual modeling approach does not exempt the modelers from understanding the basic concepts of SWRL. For large rules, e.g. with thousands of atoms, advanced visualization techniques such as groupings will have to be introduced.

While we considered an inclusion of a SWRL engine to our modeling toolkit, we rather decided to support standardized SWRL syntaxes so that external rule engines can process them. This is because we see the modeling tool as a platform- and engine- independent application.

Currently, the support of annotations in the SWRL modeling language is limited. We will add this functionality within the next SeMFIS release.

Table 3
Feature comparison of tools

Features Our Approach TopBraid Gruff (AllegroGraph)

Visual Representation of Rules ✓ ✗ ✗

Ontology Referencing ✓ ✓ ✓

Validation ✓ ✓ ✓

Layouting ✓ ✓ ✓

Export/Import Support ✓ ✓ ✓

Features	Our Approach	TopBraid	Gruff (AllegroGraph)
Visual Representation of Rules	✓	✗	✗
Ontology Referencing	✓	✓	✓
Validation	✓	✓	✓
Layouting	✓	✓	✓
Export/Import Support	✓	✓	✓

In the current implementation, a visual ontology model has to be created or imported. While the introduced import function allows to import already existing ontologies, there are several use cases for which direct references to OWL serializations – not to the visual model – might be beneficial. For example in cases, in which the ontology is gathered from the web.

The current implementation focuses on the support of the OWL-XML syntax. Libraries such as OWLAPI or SWRLAPI can be used to convert OWL-XML serializations to other concrete syntaxes.

8. Conclusion and further research

In this paper we conceptualized a visual modeling language for SWRL rules. Instead of programming SWRL using a text-based editor such as used in the SWRLtab of Stanford Protégé, our modeling approach allows constructing SWRL rules using predefined modeling classes. Domain experts can use these predefined classes – by drag and drop and thus construct the rule. Validation algorithms support the users during the creation of the rules.

For visualizing and modifying already existing rules, our approach provides an import functionality. Additionally, the rule models can be exported in order to process the rules using rule engines. Therefore, we introduced generic transformation rules in the paper which can be adapted for syntaxes such as RDF-XML. We also discussed issues which occur during the transformations and strategies for handling them.

The introduced approach has been implemented by extending the SeMFIS platform. The transformation was realized with XSLT whereby we support the OWL-XML syntax for importing and exporting rules.

In our further research we plan to add support for further syntaxes such as RDF-XML. With a special aim on assisting business users we want to improve validation algorithms (e.g. by making suggestions for solving validity issues). We also consider providing mechanisms which allow direct references from SWRL atoms to OWL ontology concepts – currently OWL ontologies have to be imported as a model in order to reference their concepts. An empirical evaluation of the benefits of the introduced visual approach as well as a comparison to text-based rules is necessary and will be a main pillar for further improvements.

Footnotes

Acknowledgements

The authors would like to thank the reviewers for their valuable comments which helped to improve the paper. We also want to thank TopQuadrat for their fast response to our questions. Further, we are very pleased that FanzInc (creator of Gruff) created a demo account for us and answered our questions quickly.

SWRL modeling language in FDMM

In the following we list the details of the SWRL modeling language as expressed in the FDMM formalism [23]. The visual modeling language for the SWRL consists of a single model type MT SWRL . This model type has a set of object types O SWRL T which have a set of attributes A SWRL which have in turn data types D SWRL T . The object types used in the model type are described in the following equation. In FDMM connectors such as HasAtom and HasConsequent are also considered as object types. We focused on the core elements and therefore we neglected the metaclasses MetaInfo and Annotation. O SWRL T = { Consequent , Antecedent , RulePart , Atom , ClassAtom , IndividualPropertyAtom , DataValuedPropertyAtom , DataRangeAtom , DifferentIndividualsAtom , BuiltInAtom , SameIndividualsAtom , DataRangeAtomList , IndividualVariable , IndividualConstant , DataVariable , DataConstant , BuildInTerm , (1) HasAtom , HasConsequent } All attributes used in the object types are part of the set A SWRL . In the following, only the most important attributes are given. A SWRL = { Name , RepresentsClass , RepresentsProperty , Datatype , Individualvalue 1 , Individualvalue 2 , Classname , Propertyname , Datavalue , Individuals , Literallist , BuiltInName , HasConsequent _ from , HasConsequent _ to , HasAtom _ from , HasAtom _ to , BuildInTerms , Value , (2) RepresentsIndividual } The datatypes of the attributes are summarized in the set D SWRL T . Enum builtIn represents a enumeration list. Due to the space constraints we do not list all its values. D SWRL T = { String , IndividualVariable , OWLClass , Enum builtIn = { greaterThan , smallerThan , … } , OWLProperty , DataConstant , Data , Enum datatype = { string , integer , … } , Consequent , Atom , IndividualConstant , BuildInTerm , DataVariable , (3) Individual }

The ordering of the object types is described in the following: (4) Consequent ⪯ RulePart Antecedent ⪯ RulePart ClassAtom ⪯ Atom IndividualVariable ⪯ Individual IndividualConstant ⪯ Individual DataConstant ⪯ Data DataVariable ⪯ Data IndividualPropertyAtom ⪯ Atom DataValuedPropertyAtom ⪯ Atom DataRangeAtom ⪯ Atom DifferntIndividualAtom ⪯ Atom SameIndividualAtom ⪯ Atom BuiltInAtom ⪯ Atom DataRangeAtom ⪯ Atom In the following, the domain functions are used to establish a mapping between the attributes and the object types: domain ( Name ) = { Atom , RulePart , IndividualConstant , IndividualVariable , DataVariable , DataConstant , BuiltInTerm } , domain ( RepresentsClass ) = { ClassAtom } , domain ( RepresentsProperty ) = { IndividualPropertyAtom , DataValuedPropertyAtom } , domain ( Datatype ) = { DataConstant , DataRangeAtom } , domain ( Individualvalue 1 ) = { ClassAtom , IndividualPropertyAtom , DataValuedPropertyAtom } , domain ( Individualvalue 2 ) = { IndividualPropertyAtom } , domain ( Classname ) = { ClassAtom } , domain ( Propertyname ) = { IndividualPropertyAtom , DataValuedPropertyAtom } , domain ( Datavalue ) = { DataValuedPropertyAtom , DataRangeAtom , DataRangeAtomList , BuiltInTerm } , domain ( Individuals ) = { DifferntIndividualAtom , SameIndividualAtom } , domain ( Literallist ) = { DataRangeAtomList } , domain ( BuiltInName ) = { BuildInAtom } , domain ( BuildInTerms ) = { BuildInAtom } , domain ( HasConsequent _ to ) = { HasConsequent } , domain ( HasConsequent _ from ) = { HasConsequent } , domain ( HasAtom _ from ) = { HasAtom } , domain ( HasAtom _ to ) = { HasAtom } , (5) domain ( Value ) = { DataConstant } .

The range function assigns datatypes to attributes used in object types. The range functions are listed in the following: range ( Name ) = { String } , range ( RepresentsClass ) = { OWLClass } , range ( RepresentsProperty ) = { OWLProperty } , range ( Datatype ) = { Enum datatype } , range ( Individualvalue1 ) = { IndividualConstant , IndividualVariable } , range ( Individualvalue2 ) = { IndividualConstant , IndividualVariable } , range ( Classname ) = { String } , range ( Propertyname ) = { String } , range ( Datavalue ) = { DataConstant , DataVariable } , range ( Individuals ) = { IndividalConstant , IndividualVariable } , range ( Literallist ) = { DataConstant } , range ( BuiltInName ) = { String } , range ( BuildInTerms ) = { BuildInTerm } , range ( HasConsequent _ to ) = { Consequent } , range ( HasConsequent _ from ) = { Antecedent } , range ( HasAtom _ from ) = { Antecedent } , range ( HasAtom _ to ) = { Consequent } , (6) range ( Value ) = { String } . In FDMM the cardinality function – abbreviated with card – defines how many attribute values a object type can have. In our modeling type all attributes have at most one value except the attributes Individuals, Literallist and BuildInTerms which can have an infinite number of parameters. Therefore, we do not show the cardinality functions in this paper.

In the following we describe an excerpt of the visual OWL model using the FDMM which we require for formalizing the model transformation. (7) O OWL T = { OWLClass , OWLProperty } A OWL = { Name , IntersectionOf , UnionOf , IsAnonymous , … } D OWL T = { String , OWLClass , … }

The domain functions are then described in the following. domain ( Name ) = { OWLClass , OWLProperty } , domain ( IntersectionOf ) = { OWLClass } , domain ( UnionOf ) = { OWLClass } , (8) domain ( IsAnonymous ) = { OWLClass } The corresponding range functions are: (9) range ( Name ) = { String } , range ( IntersectionOf ) = { OWLClass } , range ( UnionOf ) = { OWLClass } , range ( IsAnonymous ) = { Boolean } . The cardinality functions are not formally described here. The attributes Name and IsAnonymous can have at most one value while the attributes IntersectionOf and unionOf can have multiple values.

SWRL serialization in FDMM

For a clear description of the transformation from the model to the serialization and vice versa we mapped the functional syntax described in [29] – which references to OWL 2 elements described in [49] – to the FDMM. The functional syntax is described using production rules and the mapping to FDMM was done as follows: (i) For each terminal symbol an object type in the FDMM was created except for the single brackets which are used in the functional syntax for grouping. An excerpt of a production rule used in [29] and [8] is shown in the following: For example, the FDMM object types Body, Head, ClassAtom, DataRangeAtom, SameIndividualAtom and Variable are created for the corresponding terminals. (ii) For all terminals a corresponding attribute in the FDMM is created for each non-terminal it contains using the prefix Has. So for the previous example, the object type Body and Head get the attribute HasAtom. The object type ClassAtom gets two attributes HasClassExpression and HasIArg. Similarly, for the object type DataRangeAtom the attributes HasDataRange and HasDArg are created while the object type SameIndividualAtom gets the attribute HasIArg. For the object type Variable the attribute HasIRI is created. (iii) The range of the attributes are the object types created within the non-terminal for which the attribute was created. For example, the range of the previous used attribute HasIArg consists of the object type Variable. Some contained production rules do not result into object types because the production rule refers to simple datatypes which are used instead as range for attributes in the FDMM. (iv) The non-terminals which are not grouped by a terminal are replaced in the mapping process to the FDMM by their content. So production rules which do not consist of terminals do not result into an object type in the FDMM. So e.g. the range of the attribute HasIRI is a string as the production rule IRI refers finally to string representing a IRI.30 ³⁰

A distinction between the different string content is not done in the given transformation.

The following description using the FDMM starts with the production rule DLSafeRule. To stay compliant with the SWRL modeling language we did not consider annotations as well as all OWL constructs e.g. we simplified production rules of the OWL Literal.

The serialization of the rules is described using the model type MT SWRL ‾ . The model type has a set of object types O SWRL ‾ T which have a set of attributes A SWRL ‾ which have in turn data types D SWRL ‾ T .

The object types used in the model type are described in the following equation. O SWRL ‾ T = { Head , Body , ClassAtom , ObjectPropertyAtom , DataPropertyAtom , DataRangeAtom , DifferentIndividualsAtom , BuiltInAtom , SameIndividualsAtom , Variable , Literal ObjectItersectionOf , DataOneOf , (10) ObjectUnionOf , … } Unlike in the model where model instances exist independent of other instances, in the serialization model atoms can only occur within a single head or body. Similarly, variables and class expressions such as instances of the object type ObjectInstersectionOf can only occur within a single atom leading to the following conditions whereby k is a placeholder for the atoms: ∀ k ∈ { ClassAtom , … } ∀ i ∈ μ o ( k , MT SWRL ‾ ) : ∃ j ∈ { μ o ( Head , MT SWRL ‾ ) ∪ μ o ( Body , MT SWRL ‾ ) } | i ∈ j . HasAtom ∧ ∄ m ∈ { μ o ( Head , MT SWRL ‾ ) ∪ μ o ( Body , MT SWRL ‾ ) } | i ∈ m . HasAtom (11) ∧ m ≠ j ∀ g ∈ { Variable , ObjectUnionOf , … } ∀ i ∈ μ o ( g , MT SWRL ‾ ) : ∃ j ∈ { μ o ( ClassAtom , MT SWRL ‾ ) ∪ μ o ( ObjectPropertyAtom , MT SWRL ‾ ) ∪ … } | i ∈ { j . HasIArg ∪ j . HasDArg … } ∧ ∄ m ∈ { μ o ( ClassAtom , MT SWRL ‾ ) ∪ μ o ( ObjectPropertyAtom , MT SWRL ‾ ) ∪ … } | i ∈ { m . HasIArg ∪ m . HasDArg … } (12) ∧ m ≠ j

All attributes used in the object types are part of the set A SWRL ‾ . In the following, only the most important attributes are described. A SWRL ‾ = { HasAtom , HasClassExpression , HasDataRange , HasIArg , HasDArg HasIRI , HasDataProperty , HasClassExpression , HasValue , HasDatatype , (13) HasObjectProperty } The datatypes of the attributes are summarized in the set D SWRL ‾ T . D SWRL ‾ T = { String , ClassDescriptionExpression Variable , Literal , ClassAtom , DataRangeAtom , ObjectPropertyAtom , DataPropertyAtom , SameIndividualAtom , BuiltInAtom , (14) DifferentIndividualsAtom }

In the following, the domain functions are used to establish a mapping between the attributes and the object types: domain ( HasAtom ) = { Body , Head } , domain ( HasClassExpression ) = { ClassAtom , ObjectIntersectionOf , ObjectUnionOf } , domain ( HasDataRange ) = { DataRangeAtom } , domain ( HasIArg ) = { ClassAtom , ObjectPropertyAtom , DataPropertyAtom , BuiltInAtom , SameIndividualAtom , DifferentIndividualsAtom } , domain ( HasDArg ) = { DataRangeAtom , DataPropertyAtom , BuiltInAtom , DataOneOf } , domain ( HasIRI ) = { Variable } , domain ( HasDataProperty ) = { DataPropertyAtom } , domain ( HasValue ) = { Literal } , domain ( HasDatatype ) = { Literal } , (15) domain ( HasObjectProperty ) = { ObjectPropertyAtom } . The range function assigns datatypes to attributes used in object types. The range functions are listed in the following: range ( HasAtom ) = { ClassAtom , DataRangeAtom , ObjectPropertyAtom , DataPropertyAtom , BuiltInAtom , SameIndividualAtom , DifferentIndividualsAtom } , range ( HasClassExpression ) = { ObjectIntersectionOf , ObjectUnionOf , String } , range ( HasDataRange ) = { String , DataOneOf } , range ( HasIArg ) = { Variable } , range ( HasDArg ) = { Variable , Literal } , range ( HasIRI ) = { String } , range ( HasDataProperty ) = { String } , range ( HasValue ) = { String } , range ( HasDatatype ) = { String } , (16) range ( HasObjectProperty ) = { String } . To save space we did not describe the cardinality function here. All attributes except HasIRI, HasDatatype and HasValue have an infinite number of values.

References

Akbari ,

Yan ,

Zhang and

Boley , Visualizing SWRL rules: From unary/binary datalog and PSOA RuleML to graphviz and grailog, in: Proceedings of the 4th Canadian Semantic Web Symposium Part of the Semantic Trilogy 2013, Montreal, QC, Canada, July 10th, 2013, 2013, pp. 56–57.

E.F.

Aminu ,

O.N.

Oyelade and

I.S.

Shehu , Rule based communication protocol between social networks using semantic web rule language (SWRL), International Journal of Modern Education and Computer Science8(2) (2016), 22. doi:10.5815/ijmecs.2016.02.03.

Anderson ,

Athan and

Paschke , Rules and RDF streams – A position paper, in: Supplementary Proceedings of the RuleML 2016 Challenge, Doctoral Consortium and Industry Track Hosted by the 10th International Web Rule Symposium, RuleML 2016, New York, USA, July 6–9, 2016, 2016.

ArchiMate , The Open Group, 2016, https://www2.opengroup.org/ogsys/catalog/C162. Accessed on 2017-07-10.

Bak ,

Nowak and

Jedrzejek , Graph-based editor for SWRL rule bases, in: Joint Proceedings of the 7th International Rule Challenge, the Special Track on Human Language Technology and the 3rd RuleML Doctoral Consortium, Seattle, USA, July 11–13, 2013, 2013.

Bak ,

Nowak and

Jedrzejek , RuQAR: Reasoning framework for OWL 2 RL ontologies, in: The Semantic Web: ESWC 2014 Satellite Events – ESWC 2014 Satellite Events, Anissaras, Crete, Greece, May 25–29, 2014, 2014, pp. 195–198, Revised Selected Papers. doi:10.1007/978-3-319-11955-7_17.

Bassiliades , SWRL2SPIN: Converting SWRL to SPIN, in: Proceedings of the Doctoral Consortium and Challenge at RuleML+RR 2018 Hosted by 2nd International Joint Conference on Rules and Reasoning,

Faber ,

Fodor ,

G.D.

Gasperis ,

Giurca and

Teymourian , eds, Vol. 2204, CEUR, 2018.

Bechhofer ,

B.C.

Grau ,

Fokoue ,

Hoekstra and

Parsia , OWL 2 web ontology language XML serialization, W3C recommendation27(65) (2009), 159, https://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/#Appendix:_The_Derivation_from_the_Functional_Syntax_.28Informative.29. Accessed on 2017-07-10.

Boley , Grailog 1.0: Graph-logic visualization of ontologies and rules, in: Theory, Practice, and Applications of Rules on the Web – 7th International Symposium, RuleML 2013, Seattle, WA, USA, July 11–13, 2013, 2013, pp. 52–67. doi:10.1007/978-3-642-39617-5_9.

10.

Bonte ,

Ongenae ,

Schaballie ,

Arndt ,

Leroux ,

Verborgh ,

Mannens ,

F.D.

Turck and

Wauters , Semantic intelligence for real-time automated media production, in: Proceedings of the ISWC 2015 Posters & Demonstrations Track Co-Located with the 14th International Semantic Web Conference (ISWC-2015), Bethlehem, PA, USA, October 11, 2015, 2015.

11.

Bork and

Fill , Formal aspects of enterprise modeling methods: A comparison framework, in: 47th Hawaii International Conference on System Sciences, HICSS 2014, Waikoloa, HI, USA, January 6–9, 2014, 2014, pp. 3400–3409. doi:10.1109/HICSS.2014.422.

12.

Boujelben ,

Chaari and

Amous , Towards better SWRL rules dependency extraction, in: Intelligent Systems Design and Applications – 16th International Conference on Intelligent Systems Design and Applications (ISDA 2016) Held in Porto, Portugal, December 16–18, 2016, 2016, pp. 781–790. doi:10.1007/978-3-319-53480-0_77.

13.

BPMN, Business Process Model and Notation (BPMN), OMG, 2013, http://www.omg.org/spec/BPMN/2.0.2/PDF/. Accessed on 2017-07-10.

14.

Brockmans ,

Haase ,

Hitzler and

Studer , A metamodel and UML profile for rule-extended OWL DL ontologies, in: The Semantic Web: Research and Applications, 3rd European Semantic Web Conference, ESWC 2006, Budva, Montenegro, June 11–14, 2006, 2006, pp. 303–316. doi:10.1007/11762256_24.

15.

Brockmans ,

Haase and

Stuckenschmidt , Formalism-independent specification of ontology mappings – A metamodeling approach, in: On the Move to Meaningful Internet Systems 2006: CoopIS, DOA, GADA, and ODBASE, OTM Confederated International Conferences, CoopIS, DOA, GADA, and ODBASE 2006, Montpellier, France, October 29 – November 3, 2006, Proceedings, Part I, 2006, pp. 901–908. doi:10.1007/11914853_56.

16.

Cardillo ,

M.T.

Chiaravalloti ,

Eccher ,

Pasceri ,

V.D.

Mea ,

Frattura and

Guarasci , Towards a rule-based support system for the coding of health conditions in the patient summary, in: Proceedings of International Workshop on Biomedical Data Mining, Modeling, and Semantic Integration: A Promising Approach to Solving Unmet Medical Needs (BDM2I2015) Co-Located with the 14th International Semantic Web Conference (ISWC 2015), Bethlehem, United States, October 11th, 2015, 2015.

17.

Eiter ,

Ianni ,

Krennwallner and

Polleres , Rules and ontologies for the semantic web, in: Reasoning Web, 4th International Summer School 2008, Venice, Italy, September 7–11, 2008, 2008, pp. 1–53. doi:10.1007/978-3-540-85658-0_1.

18.

Feldkamp ,

Hinkelmann and

Thönssen , KISS – knowledge-intensive service support for agile process management, in: Proceedings of the Workshop on Semantic Business Process and Product Lifecycle Management SBPM 2007, Held in Conjunction with the 3rd European Semantic Web Conference (ESWC 2007), Vol. 7, Innsbruck, Austria, June 7, 2007, 2007.

19.

Fill , SeMFIS: A flexible engineering platform for semantic annotations of conceptual models, Semantic Web8(5) (2017), 747–763. doi:10.3233/SW-160235.

20.

Fill ,

Hickl ,

Karagiannis ,

Oberweis and

Schoknecht , A formal specification of the horus modeling language using FDMM, in: 11. Internationale Tagung Wirtschaftsinformatik, Leipzig, Germany, February 27 – March 1, 2013, 2013, p. 73.

21.

Fill and

Karagiannis , On the conceptualisation of modelling methods using the ADOxx meta modelling platform, Enterprise Modelling and Information Systems Architectures8(1) (2013), 4–25. doi:10.1007/BF03345926.

22.

Fill ,

Pittl and

Honegger , A modeling environment for visual SWRL rules based on the SeMFIS platform, in: Designing the Digital Transformation – 12th International Conference, DESRIST 2017, Karlsruhe, Germany, May 30 – June 1, 2017, 2017, pp. 452–456. doi:10.1007/978-3-319-59144-5_30.

23.

Fill ,

Redmond and

Karagiannis , FDMM: A formalism for describing ADOxx meta models and models, in: ICEIS 2012 – Proceedings of the 14th International Conference on Enterprise Information Systems, Vol. 3, Wroclaw, Poland, 28 June – 1 July, 2012, 2012, pp. 133–144.

24.

H.-G.

Fill , Design of semantic information systems using a model-based approach, in: AAAI Spring Symposium, AAAI, 2009.

25.

H.-G.

Fill , in: Visualisation for Semantic Information Systems, Gabler, 2009. doi:10.1007/978-3-8349-9514-8.

26.

H.-G.

Fill , On the conceptualization of a modeling language for semantic model annotations, in: Advanced Information Systems Engineering Workshops, CAiSE 2011,

Salinesi and

Pastor , eds, Springer, 2011, pp. 134–148.

27.

H.-G.

Fill and

Burzynski , Integrating ontology models and conceptual models using a meta modeling approach, in: 11th International Protégé Conference, 2009.

28.

T.M.

Glässner ,

Heumann ,

Keßler ,

Härer ,

Steffan and

Fill , Experiences from the implementation of a structured-entity-relationship modeling method in a student project, in: Proceedings of the 1st International Workshop on Practicing Open Enterprise Modeling Within OMiLAB (PrOse 2017) Co-Located with 10th IFIP WG 8.1 Working Conference on the Practice of Enterprise Modelling (PoEM 2017), Leuven, Belgium, November 22, 2017, 2017.

29.

Glimm ,

Horridge ,

Parsia and

P.F.

Patel-Schneider , A syntax for rules in OWL 2, in: Proceedings of the 5th International Workshop on OWL: Experiences and Directions, 2009, http://ceur-ws.org/Vol-529/owled2009_submission_16.pdf.

30.

Glimm ,

Horrocks ,

Motik ,

Stoilos and

Wang , HermiT: An OWL 2 reasoner, J. Autom. Reasoning53(3) (2014), 245–269. doi:10.1007/s10817-014-9305-1.

31.

Harel and

Rumpe , Modeling Languages: Syntax, Semantics and All That Stu, 2000, http://www4.in.tum.de/publ/papers/HR00.pdf.

32.

Harel and

Rumpe , Meaningful modeling: What’s the semantics of “semantics”?, IEEE Computer37(10) (2004), 64–72. doi:10.1109/MC.2004.172.

33.

Hassanpour ,

M.J.

O’Connor and

A.K.

Das , A rule management and elicitation tool for SWRL rule bases, in: Proceedings of the 3rd International RuleML-2009 Challenge, Collocated with the 3rd International Symposium on Rules, Applications and Interoperability (RuleML-2009), Las Vegas, Nevada, USA, November 5–7, 2009, 2009, pp. 5–7.

34.

Horridge , OWL Syntaxes, Ontogenesis, 2010, http://ontogenesis.knowledgeblog.org/88. Accessed on 2017-07-10.

35.

Horrocks ,

P.F.

Patel-Schneider ,

Boley ,

Tabet ,

Grosof ,

Dean et al., SWRL: A semantic web rule language combining OWL and RuleML, W3C Member submission21 (2004), 79, https://www.w3.org/Submission/SWRL/. Accessed on 2017-07-10.

36.

Jajaga and

Ahmedi , C-SWRL: SWRL for reasoning over stream data, in: 11th IEEE International Conference on Semantic Computing, ICSC 2017, San Diego, CA, USA, January 30 – February 1, 2017, 2017, pp. 395–400. doi:10.1109/ICSC.2017.64.

37.

Johannsen and

Fill , Meta modeling for business process improvement, Business & Information Systems Engineering59(4) (2017), 251–275. doi:10.1007/s12599-017-0477-1.

38.

Karagiannis and

Kühn , Metamodelling platforms, in: E-Commerce and Web Technologies, Third International Conference, EC-Web,

Bauknecht ,

A.M.

Tjoa and

Quirchmayr , eds, 2002, p. 182. doi:10.1007/3-540-45705-4_19.

39.

Keßler , A RESTful SWRL rule editor, in: Web Reasoning and Rule Systems – Fourth International Conference, RR 2010, Bressanone/Brixen, Italy, September 22–24, 2010, 2010, pp. 235–238. doi:10.1007/978-3-642-15918-3_22.

40.

Khan ,

Bellandi ,

Frontini and

Monachini , Using SWRL rules to model noun behaviour in Italian, in: Language, Data, and Knowledge First International Conference, LDK 2017, Galway, Ireland, June 19–20, 2017, 2017, pp. 134–142. doi:10.1007/978-3-319-59888-8_11.

41.

Kim ,

Kim and

Jung , i-RM: An intelligent risk management framework for context-aware ubiquitous cold chain logistics, Expert Syst. Appl.46 (2016), 463–473. doi:10.1016/j.eswa.2015.11.005.

42.

Leutgeb , The Business Rules Method: A Modeling Method for Adaptive Processes – Master Thesis, University of Vienna, Wien, 2007.

43.

Leutgeb ,

Utz ,

Woitsch and

Fill , Adaptive processes in E-government – A field report about semantic-based approaches from the EU-project “FIT”, in: ICEIS 2007 – Proceedings of the Ninth International Conference on Enterprise Information Systems, Volume EIS, Funchal, Madeira, Portugal, June 12–16, 2007, 2007, pp. 264–269.

44.

Lombardo ,

Battaglino ,

Pizzo ,

Damiano and

Lieto , Coupling conceptual modeling and rules for the annotation of dramatic media, Semantic Web6(5) (2015), 503–534. doi:10.3233/SW-140156.

45.

D.L.

McGuinness ,

Van Harmelen et al., OWL web ontology language overview, W3C recommendation10(10) (2004). https://www.w3.org/TR/owl-features/. Accessed on 2017-07-10.

46.

Mei and

Boley , Interpreting SWRL rules in RDF graphs, Electr. Notes Theor. Comput. Sci.151(2) (2006), 53–69. doi:10.1016/j.entcs.2005.07.036.

47.

D.L.

Moody , The ”Physics” of notations: Toward a scientific basis for constructing visual notations in software engineering, IEEE Trans. Software Eng.35(6) (2009), 756–779. doi:10.1109/TSE.2009.67.

48.

J.L.R.

Moreira ,

T.P.

Sales ,

Guerson ,

B.F.B.

Braga ,

Brasileiro and

Sobral , Menthor editor: An ontology-driven conceptual modeling platform, in: Proceedings of the Joint Ontology Workshops 2016 Episode 2: The French Summer of Ontology Co-Located with the 9th International Conference on Formal Ontology in Information Systems (FOIS 2016), Annecy, France, July 6–9, 2016, 2016.

49.

Motik ,

P.F.

Patel-Schneider and

Horrocks , OWL 2 web ontology language: Structural specification and functional-style syntax, W3C recommendation11 (2009). https://www.w3.org/TR/owl2-syntax/. Accessed on 2017-07-10.

50.

M.A.

Musen , The protégé project: A look back and a look forward, AI Matters1(4) (2015), 4–12. doi:10.1145/2757001.2757003.

51.

C.S.

Namahoot ,

Sivilai and

Brückner , An ingredient selection system for patients using SWRL rules optimization and food ontology, in: Cooperative Design, Visualization, and Engineering – 13th International Conference, CDVE 2016, Sydney, NSW, Australia, October 24–27, 2016, 2016, pp. 163–171. doi:10.1007/978-3-319-46771-9_22.

52.

O’Connor ,

Knublauch ,

Tu and

Musen , Writing rules for the semantic web using SWRL and Jess, Protégé With Rules Workshop, Madrid, 2005.

53.

Peffers ,

Tuunanen ,

M.A.

Rothenberger and

Chatterjee , A design science research methodology for information systems research, J. of Management Information Systems24(3) (2008), 45–77. doi:10.2753/MIS0742-1222240302.

54.

T.A.

Pham and

N.L.

Thanh , Checking the compliance of business processes and business rules using OWL 2 ontology and SWRL, in: Proceedings of the Second International Afro-European Conference for Industrial Advancement, AECIA 2015, Villejuif (Paris-Sud), France, 9–11 September 2015, 2015, pp. 11–20. doi:10.1007/978-3-319-29504-6_3.

55.

Pittl and

Fill , Transforming enterprise models to linked data via semantic annotations, in: Modellierung 2018, Braunschweig, Germany, 21–23 Februar 2018, 2018, pp. 55–70.

56.

Pittl ,

Fill and

Honegger , Enabling risk-aware enterprise modeling using semantic annotations and visual rules, in: 25th European Conference on Information Systems, ECIS 2017, Guimarães, Portugal, June 5–10, 2017, 2017, p. 22.

57.

M.K.

Sarker ,

Carral ,

A.A.

Krisnadhi and

Hitzler , Modeling OWL with rules: The ROWL protege plugin, in: Proceedings of the ISWC 2016 Posters & Demonstrations Track Co-Located with 15th International Semantic Web Conference (ISWC 2016), Kobe, Japan, October 19, 2016, 2016.

58.

Schätz , Formalization and rule-based transformation of EMF ecore-based models, in: Software Language Engineering, First International Conference, SLE 2008, Toulouse, France, September 29–30, 2008, 2008, pp. 227–244, Revised Selected Papers. doi:10.1007/978-3-642-00434-6_15.

59.

Skillen ,

Chen and

Burns , VIPR: A visual interface tool for programming semantic web rules, in: 2016 Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), Toulouse, France, July 18–21, 2016, 2016, pp. 277–284. doi:10.1109/UIC-ATC-ScalCom-CBDCom-IoP-SmartWorld.2016.0059.

60.

Stadtmüller ,

Speiser ,

Harth and

Studer , Data-fu: A language and an interpreter for interaction with read/write linked data, in: 22nd International World Wide Web Conference, WWW ’13, Rio de Janeiro, Brazil, May 13–17, 2013, 2013, pp. 1225–1236. doi:10.1145/2488388.2488495.

61.

Studer ,

V.R.

Benjamins and

Fensel , Knowledge engineering: Principles and methods, Data Knowl. Eng.25(1–2) (1998), 161–197. doi:10.1016/S0169-023X(97)00056-6.

62.

UML, Unified Modeling Langague Specification (UML), OMG, 2015, http://www.omg.org/spec/UML/2.5/PDF/. Accessed on 2017-07-10.

63.

Visic ,

Fill ,

R.A.

Buchmann and

Karagiannis , A domain-specific language for modeling method definition: From requirements to grammar, in: 9th IEEE International Conference on Research Challenges in Information Science, RCIS 2015, Athens, Greece, May 13–15, 2015, 2015, pp. 286–297. doi:10.1109/RCIS.2015.7128889.

64.

T.W.

Wlodarczyk ,

Rong ,

M.J.

O’Connor and

M.A.

Musen , SWRL-F: a fuzzy logic extension of the semantic web rule language, in: Proceedings of the International Conference on Web Intelligence, Mining and Semantics, WIMS 2011, Sogndal, Norway, May 25–27, 2011, 2011, p. 39. doi:10.1145/1988688.1988735.

A visual modeling approach for the Semantic Web Rule Language

Abstract

Keywords

1. Introduction

2.1. Foundations of conceptual modeling methods

Table 1 Excerpt of the elements used for the SWRL modeling language [22]

4. Transformation of SWRL models

6.1. W3C examples

Table 3 Feature comparison of tools Features Our Approach TopBraid Gruff (AllegroGraph) Visual Representation of Rules ✓ ✗ ✗ Ontology Referencing ✓ ✓ ✓ Validation ✓ ✓ ✓ Layouting ✓ ✓ ✓ Export/Import Support ✓ ✓ ✓

Footnotes

Acknowledgements

SWRL modeling language in FDMM

SWRL serialization in FDMM

References

Table 1
Excerpt of the elements used for the SWRL modeling language [22]

Table 3
Feature comparison of tools

Features Our Approach TopBraid Gruff (AllegroGraph)

Visual Representation of Rules ✓ ✗ ✗

Ontology Referencing ✓ ✓ ✓

Validation ✓ ✓ ✓

Layouting ✓ ✓ ✓

Export/Import Support ✓ ✓ ✓