Ontology conceptualization is a crucial task within the ontology development process. During this activity, developers should generate a conceptual model of the ontology based on the requirements that the ontology should meet. Very often, this activity is carried out by producing diagrams to represent the ontology structure and main elements; to do this, paper, blackboard, or digital drawing tools could be used. From this point on, the generated models drive the implementation of the ontology. Therefore, the closer the diagrams are to the OWL constructs, the easier the ontology developer would be to generate the ontology code. However, up to now, there is no standard notation for OWL that reduces the freedom of modelling between custom diagramming styles and the OWL code. For this reason, in this paper we introduce the Chowlk notation for the OWL language based on UML. This notation is being adopted in several projects including ontologies developed by standardization bodies.
(R. García-Castro)
The Chowlk visual notation1 presented in this paper is based on the UML_Ont profile [
icdnlaadtsiavstiydepsue,alpsroperties, cdueoinqsmiujooivpninal,etlienmcntleeatrnscsstleaecssts,ioens, object properties ccdpllroaaomsspssaeidmrntey,esrrmcaernbliapgetteirioso,nhnsisph,ips, object properties, datatype properties one of, all different 1More detailed information about the notation is provided at https://chowlk.linkeddata.es/notation.html.
Named classes are represented by a rectangle that includes the class URI (Figure 2 (a)). “Subclass of” is represented by an empty arrow (Figure 2 (b.1)) or using the rdfs:subClassOf stereotype within a dashed arrow (Figure 2 (b.2)). Anonymous classes are defined by an empty rectangle (Figure 2 (h.2)) or circles representing owl:intersectionOf or owl:unionOf (Figure 2 (c) and (d)). Equivalence and disjointness between classes are represented by circles as shown in Figure 2 (e) and (f). The circles with the logic operators inside them represent the axioms, meanwhile the classes connected to those circle using arrows are the concepts involved in the relationship. Classes enumerations are defined using the hexagon linking to the involved individuals (Figure 2 (g)).
Classes defined using property restrictions can be represented concisely by including the operators used in the arrows representing the object properties (Figure 2 (h.1), (j), (l)) or before the datatype properties (Figure 2 (i), (k), (m)). As shown in Figure 2, the tags (all) and (some) indicate existential and universal restrictions, respectively. The tag (N1..N2) represents cardinality. If the user wants to specify an exact cardinality, the numbers N1 and N2 should be equal. The notation has the “N” letter reserved for the cases in which no maximum cardinality is needed. For instance, the tag (2..N) will indicate a minimum cardinality restriction of 2, and a nonexistent maximum cardinality restriction.
As the notation used in Figure 2 (h.1), (j) and (l) for object properties (and (i) (k) and (m) for datatype properties) could be combined with subclass of and equivalent class axioms, it should be defined to which OWL construct it would correspond. The decision was to understand these options as “subclass of” because the logical commitment is less strong than an equivalent class in terms of reasoning and because it is more likely to find that pattern in existing ontologies. In order to allow for having equivalent classes with the universal, existential and cardinality constraints, the tag “(eq)” is added before the constraint, as shown in Figure 2 (n.1), (o) and (p). It should be mentioned that options (h.1) represent the same modelling as (h.2) and the same holds between (n.1) and (n.2).
Object properties are represented by labeled directed arrows where the head of the arrow indicates the possible domain and range of the property. Several variations can be applied to the style of the arrow depending on their individual particularities. Figure 3 options (a.1) to (d.2), provides a summary of the possible combinations. More precisely, if the property domain is the attached class, the dot at the origin of the arrow is filled (Figure 3 (a.2) and (b)), otherwise it is empty (Figure 3 (c) and (d.2)). If the property range is the attached class, the arrow is solid (Figure 3 (a.2) and (c)), otherwise it is dashed (Figure 3 (b) and (d.2)). To simplify the cases where both the domain and the range are defined, the plain arrow without a circle at the origin could be used as a shortcut (Figure 3 (a.1)) and the same could be used for cases where neither the domain nor the range are defined using the dashed arrow (Figure 3 (d.1)). This notation feature is designed to allow the developer to state between which classes the property intended is to be used, even though there is no domain and range declared. This graphical information is very valuable to a potential user when starting reading an ontology as it is not explicitly declared in (a) ns:Class1 (c) (d) ⨅ ⨆ the code.
The property characteristics are also indicated by special tags in the labels. The tags (F), (S), (IF), (T) indicate if a property is owl:FunctionalProperty (e), owl:SymmetricProperty (f), owl:InverseFunctionalProperty (g) or owl:TransitiveProperty (h) respectively. One of the advantages of using tags to declare things like property restrictions (Figure 2 (h.1) to (n.2)) and property types is that they do not interfere with other definitions of properties, such as the domain and range, which control the style of the arrow. The inclusion of concise tags avoids the use of additional elements that will clutter the conceptualization.
The notation also provides an alternative representation for properties using the diamond
block (see Figure 1). This shape, reused from UML_Ont profile [
Visually, datatype properties or attributes are shown as complementary rectangles below classes, as shown in Figure 4. A rectangle can contain more than one attribute. As in the case of object properties, the user can modify the style and text inside those rectangles in order to represent whether domain and ranges are defined. A solid border line of the rectangle indicates that the domain of that set of attributes is the class defined above them (Figure 4 (a) and (b)). A dashed line indicates that the attribute is intended to be used for instances of the attached class; however, the domain is not declared (Figure 4 (c) and (d)). The range is indicated by declaring a datatype in the text of the attribute (Figure 4 (a) and (c)).
Restrictions over the attributes are also possible using the same tags explained for the object properties in and shown in Figure 2 (i) (universal), (k) (existential) and (m) (cardinality). In the case of property types, only the functional tag (F) applies to attributes, according to the OWL specification. If a datatype is functional, it is defined using a tag as shown in Figure 4 (e).
The notation also allows representing the datatype relations using the diamond block to define rdfs:subPropertyOf (Figure 4 (f)), owl:equivalentProperty (Figure 4 (g)) and owl:propertyDisjointWith (Figure 4 (h)). aR ecd eTNO lraed (b) ang ecd R
Domain declared
Domain NOT declared ns:Class1
ns:Class1 ns:datatypeProperty1: datatype
ns:datatypeProperty1: ns:datatype (c) (d) ns:Class1 ns:datatypeProperty1
ns:Class1 ns:datatypeProperty1 (f) (g)
(e) (h)
The Chowlk notation uses the same rectangular visual block to represent classes and individuals; however, the individuals have their labels underlined (Figure 5 (a)). Figure 5 shows four options to state the class membership of an individual (b.1 to b.4)). The first option (b.1) where the individual is attached to the class it belongs to is the preferred one, as it is more compact and reduces the number of arrows. If an individual belongs to more than one class, (b.1) and (b.3) are recommended.
(a)
The notation also allows for the definition of individuals’ identity axioms. Two equal individuals can be represented by a solid arrow connecting them with the owl:sameAs construct (Figure 5 (c)) and to state that two individuals cannot represent the same entity the owl:differentFrom construct can be declared (Figure 5 (d)). To indicate that a set of individuals are all diferent, the hexagonal visual block shown in Figure 5 (e) could be used. In this case, the hexagonal label contains the axiom owl:AllDifferent and is connected to all individuals involved in the axiom using dashed arrows.
It is also possible to instantiate the property values as shown in Figure 5. In the case of object properties, the individuals are connected by arrows stating the relation in the label (f.1). In the case of datatype properties, the same artifact is used, but now the destination of the arrow is connected to a datatype value (f.2) and (f.3).
During the last decades, ontology visualization and graphical edition have attracted researchers attention. For example, the systematic literature review provided by [4] in which the relation between UML and ontology based formalisms is investigated through the analysis of 66 works. In addition, a comprehensive analysis of visualization methods and tools and their capabilities is provided by [5]. However, in this paper we focus on the notation aspect independently of the technology transforming the conceptualization into code.
In this sense, we can compare our work to existing notations which could be broadly classified in directed graphs oriented or UML alike. One of the well-known of the former type is WebVOWL [6]. In this case, the type of notation used makes it more complex to state a number of object properties between the same two classes. It also generates less compact diagrams as the datatype properties are also arcs to new nodes (therefore, more nodes are needed than in UML-alike visualizations). Finally, the hierarchies cannot be placed in a tree-oriented way as the visualization approach follows a circular shape. A closer notation to UML is the Grafoo specification. In this case, the issue with more cluttered diagrams because datatype properties are also represented with nodes remains. In addition, the class constraints are also represented by an additional box, in contrast to reusing the object properties arrows as proposed by the Chowlk notation, generating cleaner diagrams.
Both WebVOWL and Grafoo use colours in the shapes to convey information about the model, which can be lost, for example, when printing in black and white or for people with diferent colour perception. In the case of the Chowlk notation, the colour of the classes are meaningless from the conceptualization point of view but it is advisable to use diferent colours for diferent namespaces so that the user can easily identify in which ontology is every concept defined. See, for example, the SAREF4CITY ontology. 2
Another notation following UML is OWLGrEd [7]. However, from its notation description3 it is not clear which OWL features are supported, for example imports, class equivalence, property equivalences, cardinality constraints, etc.
This paper has presented foremost characteristics of the Chowlk notation and major advantages over existing ones. Also, the main rationales for some notation characteristics, such as domain and ranges options and the use of tags for property characteristics and class constraints, have been explained. This notation is provided within the Chowlk framework and two diagrams.net libraries are available containing a complete version or a subset of the notation elements.4 2https://saref.etsi.org/saref4city/ 3http://owlgred.lumii.lv/notation 4The lightweight and complete libraries are available at https://chowlk.linkeddata.es/notation.html
The notation has been used in a number of projects including ontologies developed by standarization bodies as, for example, the ETSI SAREF ontologies5 as it can be seen in the SAREF4AGRI ontology6 among others. Furthermore, by W3C communities, such as the RML ontologies7 and the WoT discovery ontology.8 Other examples are European projects as BIMERR,9 and COGITO.10 It is being adopted by projects carried out by organizations not related to the authors of this paper as BIM4EEB11, CosWOT 12, D2KAB13, and Mat-o-Lab.14
The main future line of work involves the detailed comparison with existing notations in terms of capabilities, clarity, and ability to generate compact diagrams. The notation documentation is planned to be improved overall incorporating more examples. The generation of examples for well-known ontologies is part of the Chowlk roadmap in order to ease their reuse.
Finally, as the notation is used by the Chowlk converter to generate OWL code, it is needed to define notation characteristics to indicate the converter from where to start reading axioms in order to reduce the complexity when processing the notation underlying graph. However, this need is oriented to the technological side of the framework rather than to the visualization capabilities to represent OWL ontologies.
This work has been supported by COGITO funded by the European Union’s Horizon 2020 research and innovation programme under grant agreement no. 958310 and by the Madrid Government (Comunidad de Madrid-Spain) under the Multiannual Agreement with the Universidad Politécnica de Madrid in the Excellence Programme for University Teaching Staf, in the context of the V PRICIT (Regional Programme of Research and Technological Innovation). 5https://saref.etsi.org/extensions.html 6https://saref.etsi.org/saref4agri/ 7https://kg-construct.github.io/rml-resources/portal/ 8https://github.com/w3c/wot-discovery/tree/main/context 9https://bimerr.iot.linkeddata.es/ 10https://cogito.iot.linkeddata.es/ 11https://digitalconstruction.github.io/v/0.5/index.html 12https://coswot.gitlab.io/ 13http://www.elzeard.co/ontologies/c3po/plant# 14https://github.com/Mat-O-Lab/MSEO [4] M. Mejhed Mkhinini, O. Labbani-Narsis, C. Nicolle, Combining uml and ontology: An exploratory survey, Computer Science Review 35 (2020) 100223. doi:https://doi.org/10. 1016/j.cosrev.2019.100223. [5] M. Dudás, S. Lohmann, V. Svátek, D. Pavlov, Ontology visualization methods and tools: a survey of the state of the art, The Knowledge Engineering Review (2018) 33. [6] V. Wiens, S. Lohmann, S. Auer, Webvowl editor: Device-independent visual ontology modeling, International Semantic Web Conference (2018). [7] J. Barzdins, G. Barzdins, K. Cerans, R. Liepins, A. Sprogis, UML style graphical notation and editor for OWL 2, in: Perspectives in Business Informatics Research - 9th International Conference, BIR 2010, Rostock Germany, September 29-October 1, 2010. Proceedings, volume 64 of Lecture Notes in Business Information Processing, Springer, 2010, pp. 102–114. doi:10.1007/978- 3- 642- 16101- 8\_9.