Some ideas for ontology graphical representations

After a long time of inactivity, I’ve decided to write this blog post to share some practices I usually follow when generating diagrams to represent ontologies. During the last months I’ve been sharing some materials with different persons and I just thought it would be nice to have one place to gather them, and maybe provide some explanations if that is the case. By no means aims this post to be a good practices guide or reference, in addition it is not even complete, there are issues out of scope as cardinalities and complex axioms.

First of all, I must acknowledge the UML_Ont profile developed within the NeOn project as it has been so far my reference notation for representing ontologies. However, as I’ll explain later, sometimes I adapt the profile as I find more convenience.

It should be mentioned that the original UML_Ont profile utilizes custom stereotypes and dependencies to cover OWL 1 constructs. In this thesis (yes, some of this content comes from my thesis) post, we align the stereotypes used in the profile to OWL and RDF(S) constructs as follows:

UML_Ont profile OWL primitives adaptation
ObjectAllValuesFrom owl:allValuesFrom
ObjectSomeValuesFrom owl:someValuesFrom
ObjectIntersectionOf owl:intersectionOf
ObjectUnionOf owl:unionOf
SubClassOf rdfs:subClassOf
EquivalentClasses owl:equivalentClass
DisjointClasses owl:disjointWith
ObjectPropertyDomain rdfs:domain
DataPropertyDomain rdfs:domain
ObjectPropertyRange rdfs:range
DataPropertyRange rdfs:range
EquivalentObjectProperties owl:equivalentProperty
EquivalentDataProperties owl:equivalentProperty
InverseObjectProperties owl:inverseOf
Transitive owl:TransitiveProperty
Symmetric owl:SymmetricProperty
ClassType rdf:type
not owl:complementOf

Alternatives and additional notations for properties, axioms and individuals are defined in UML_Ont profile.

Based on this UML_Ont profile, here they go some ways of representing classes, object properties, datatype properties and individuals,  as well as some of their axioms or characteristics. For the sake of readability, specific element notations in the following figures are labelled in correspondence to the enumeration items listed below.

Notation for classes, class restrictions and class axioms

  • 1) Classes: the graphical representations for classes, class restrictions and class axioms are depicted in the figure 1. The constructs included in such figure are:
    • 1.a) Named classes are represented by labelled boxes.
    • 1.b) Class restrictions or anonymous classes are represented by empty boxes.
    • 1.c) Universal restrictions are represented by means of the «owl:allValuesFrom» stereotype together with the property on which the restriction is applied.
    • 1.d) Existential restrictions are represented by means of the «owl:someValuesFrom» stereotype together with the property on which the restriction is applied.
    • 1.e) Intersection class descriptions could be represented by means of:
      • 1.e.i) Empty circle together with the «owl:intersectionOf» stereotype.
      • 1.e.ii) Icon including the symbol “⊓”.
    • 1.f) Union class descriptions could be represented by means of:
      • 1.f.i.) Empty circle together with the «owl:unionOf» stereotype.
      • 1.f.ii.) Icon including the symbol “⊔”.
    • 1.g) Subclass of axioms could be represented by means of:
      • 1.g.i) Generalization arrow.
      • 1.g.ii) UML dependency arrow with the «rdfs:subClassOf» stereotype.
    • 1.h) Equivalent class axioms could be represented by means of:
      • 1.h.i) Double-sided UML dependency with the «owl:equivalentClass» stereotype.
      • 1.h.ii) Circle including the symbol “≣”.
    • 1.i) Disjoint class axioms could be represented by means of:
      • 1.i.i) Double-sided UML dependency with the «owl:disjointWith» stereotype.
      • 1.i.ii) Circle including the symbol “⊥”.
notationClass

Figure 1. Notation for classes, class restrictions and class axioms

Notation for properties, relations between properties and property characteristics

  • 2) Properties: the graphical representation for properties, relations between properties and property characteristics are depicted in the next figure The constructs included in such figure are:
    • 2.a) Object properties (relationships): object properties are represented by:
      • 2.a.i) Labelled arrows: in this case the domain and range of the property are indicated by the origin and target of the arrow respectively. The name of the object property is represented by a label close to it.
      • 2.a.ii) Labelled diamonds: in this case the domain and range of the property are indicated by dotted arrows labelled with the «rdfs:domain» and «rdfs:range» stereotypes respectively. The name of the object property is represented by a label within the diamond.
    • 2.b) Datatype properties (attributes): datatype properties are represented by:
      • 2.b.i) Labelled boxes: datatype properties can be represented as labelled boxed attached to boxes representing classes. The range might be included following the character “:” after the datatype label.
      • 2.b.ii) Labelled diamonds: in this case the domain and range of the property are indicated by dotted arrows labelled with the «rdfs:domain» and «rdfs:range» stereotypes respectively. The name of the datatype property is represented by a label within the diamond.
    • 2.c) Equivalent object properties could be represented by means of:
      • 2.c.i) Double-sided UML dependency with the «owl:equivalentProperty» stereotype linking the arrows that represent the involved object properties.
      • 2.c.ii) Double-sided UML dependency with the «owl:equivalentProperty» stereotype linking the diamonds that represent the involved object properties.
    • 2.d) Inverse object properties could be represented by means of:
      • 2.d.i) Double-sided UML dependency with the «owl:inverseOf» stereotype linking the arrows that represent the involved object properties.
      • 2.d.ii) Double-sided UML dependency with the «owl:inverseOf» stereotype linking the diamonds that represent the involved object properties.
    • 2.e) Equivalent datatype properties are represented by a double-sided dependency with the «owl:equivalentProperty» stereotype linking the diamonds that represent the datatype properties.
    • 2.f) Transitive properties are represented by a labelled diamond, which represents the property itself, including the «owl:TransitiveProperty» stereotype.
    • 2.g) Symmetric properties are represented by a labelled diamond, which represents the property itself, including the «owl:SymmetricProperty» stereotype.
notationProp

Figure 2. Notation for properties, relations between properties and property characteristics

Notation for individuals and class membership

  • 3) Individuals: the graphical representation for individuals and class assertions are depicted in the next figure.
    • 3.a) Individuals are represented by labelled boxes with underlined names.
    • 3.b) Class membership:
      • 3.b.i) Labelled box with the individual name followed by the character “:” and the class name, all underlined.
      • 3.b.ii) UML dependency arrow with the stereotype «rdf:type».
notationInd

Figure 3. Notation for individuals and class membership

Figure 4 shows an example of diagram for the VICINITY core ontology. This example includes some of the elements shown and some variations detailed in the following.

CoreOntology

Figure 4. Example diagram for the VICINITY core ontology

Problems, modifications and other ideas…

Even though the UML_Ont profile is quite complete, for OWL 1, some doubts about how to represent specific situations might arise. In other cases some simplifications can be done to have a cleaner diagram. Let’s see some examples:

  • Variation for properties without domain and ranges defined when using the arrow notation (that is 2.a.i and 2.b.i for object properties and datatype properties respectively). Using an arrow with the name of the object property (or a box in the case of datatype properties) usually means that the classes/datatypes attached to such properties are stated as domain or range of the property. However, sometimes that axiom is not explicit in the ontology and we want to represent that a given property is expected to be used between two particular classes in our model or in our dataset. In this case, I alter the arrow or boxes (for datatype properties) representing the property for a dashed one. The meaning of these dashed arrows with the name of an object property or a dashed box for the datatype means that such property can be stated for individuals of the class attached. See figure 4 for examples of this variation. This variation has become handy for me so far, however I haven’t come up with a variation for the cases in which only one of the domain or range is stated for an object property.
  • Simplify «rdf:type» statements: the stereotype could be removed and keep the dependency arrow without label to represent «rdf:type» statements between individuals and classes in order to have a cleaner diagram. See figure 5 for examples of this variation.
    • Sometimes it is also advisable to remove the arrow between the box representing the instance and the class. In this case, when there are too many individuals in a diagram, I place a box representing the class to which the instance belongs to on top of the box of the instance. However, I only do this when the instance belongs only to one class to avoid misunderstandings with a stack of boxes. See figure 5 for examples of this variation.
CERTH_thermometer_02

Figure 5. Example of instances of VICINITY core and WoT ontologies

  • Some times it helps to organized and group ontology elements within a same domain or topic. See figure 5 for an example of an ontology divided by areas. This ontology was built within the Smart Developer Hub project to model the Issue Trackers domain.
ITv10

Figure 6. Issue Tracker ontology.

  • Ontologies and prefixes. I found helpful to use ontology prefixes in each ontology element included in the diagram so that I see at a glance in which ontology (the one being documented or a reused one) is the element define. I sometimes also use different colours for classes defined in different ontologies, however the colour does not replace the use of a prefix. I also include the ontologies being referenced or imported and their prefixes in the legend. See figure 4 for an example.
  • Finally, theses days we came up with a “map” of  an ontology network in which only the main classes in each ontology are represented and they are linked by lines meaning that the are related, somehow. Main hierarchical relations are also included. This relationships are detailed in each ontology diagram. See figure 7 for the example of the “map” of the VICINITY ontologies. The first idea of generating this map was only for internal management but it resulted so useful to have a quick overview of the network and it is now part of the network documentation.
OntologyNetwork

Figure 7. VICINITY ontology network map

Conclusions

In summary what I find it is useful for the others, who needs to understand our models, and what I try to follow is:

  1. Be consistent with the selected notation (of course within a document but also across projects when possible)
  2. Include a legend, including all symbols used
  3. Do not use the same symbol (without distinctions) for more than one meaning
  4. (Try to) keep it simple

I hope you find something useful on this post. If you have any suggestion, comment or contribution it will be more than welcome.

Advertisements
Tagged , , ,

After the Ontology Summit 2013 hackathon

In this post I am going to briefly talk about and show the outcomes from the Ontology Summit 2013 Hackathon. As I said in my previous post, OOPS! was involved in the projects “HC-03 Evaluation of OOPS!, OQuaRE and Other Tools for FIBO Ontologies” and “HC-07 Ontohub-OOR-OOPS! Integration”.

During the first project, we scanned a merged version of the FIBO OWL ontologies with OOPS! and analyse and discuss every pitfall detected. After this process, FIBO development team established that “most of the metrics were ones we would want to apply to the FIBO Business Conceptual Ontologies, not just operational ontologies.” Next steps were to apply also OQuaRE and OntoQA metrics to FIBO ontologies. Finally, we took another working day to determine how to apply OQuaRE characteristics to FIBO ontologies and map them to OntoQA metrics and OOPS! pitfalls. This set of slides summarizes the good and intensive work that the HC-03 team carried out during the project that was awarded with the “First IAOA Best OntologySummit Hackathon-Clinic Prize” during the Ontology Summit 2013 Symposium.

During the second project, OOPS! was integrated into Ontohub web interface and an API for the Ontohub-OOR integration was proposed. The great work mainly done by Ontohub development team is summarised in these slides. OOPS! team work during this project was overall about supporting and helping the Ontohub-OOPS! integration when needed providing details about the OOPS! RESTful web service.

Finally, here there is an example of an ontology analysed with OOPS! within the Ontohub portal. In the first screenshot there is a “Test with OOPS!” button that is active before the ontology is being scanned.

Example ontology before being scanned

Example ontology before being scanned

While OOPS! is scanning the ontology, the Ontohub interface shows the status information “OOPS State: pending” as in this screenshot:

Example of ontology during the scanning process

Example of ontology during the scanning process

When the process is done, the number of pitfalls detected, if any, is displayed (“5 responses” in this example) and an explanation of them is provided when clicking in the ontology element affected by the pitfall, as shown in the last screenshot:

Example of results for an object property

Example of results for an object property

Finally, these and other results from the Ontology Summit were presented at the Ontology Summit 2013 Symposium together with the Ontology Summit 2013 Comunique.

Tagged , , , ,

Getting involved in the Ontology Summit 2013 hackathon

The Ontolog Forum is “an open, international, virtual community of practice devoted to advancing the field of ontology, ontological engineering and semantic technology, and advocating their adoption into mainstream applications and international standards”.  The forum was reconstituted in 2002 and organizes annual series of events called Ontology Summits since 2006. An Ontology Summit is “an organized thinking machine that work from January to April every year to brain-storm one of a topic of interest for ontology engineering community” (see source). This year’s summit topic is “Ontology Evaluation Across the Ontology Lifecycle”.

Fortunately, I was invited to participate giving a talk at the “Intrinsic Aspects of Ontology Evaluation: Practice and Theory” session about the work done in OOPS! (OntOlogy Pitfall Scanner!). At the end of the session, Ontology Summit organizers proposed all the participants to get involved in the hackathon they were planning to carry out.  At that moment there was little information about it, indeed it was more of a imprecise plan about an event like a “hackathon” without a clear idea of when, who, how… but with the definite aim of creating something ‘real’ and ‘useful’ for ontology evaluation. So we accepted the invitation… or the challenge?

Soon we had some more information. There were three types of projects:

  • Hackathon: its goal is to create some new code, new API, or new ontology that are relevant to this Ontology Summit and/or this year’s “Ontology Evaluation” theme.
  • Ontology Evaluation Clinic” (abbrev. “Ontology Clinic“): aims at evaluating ontologies or gold standard ontologies through the “evaluation tool,” study the results, diagnose problems with the ontology, and see how the ontology, and the tool, may be improved,
  • Ontology-based Application Evaluation Clinic (abbrev. “Application Clinic“): helps the users evaluate whether ontologies the users already had in mind are fit for the intended purpose and whether the quality of those ontologies are satisfactory and provide appropriate recommendations

Participants had to write a proposal for the type of project they were interested in. As result, 8 hackathon projects, 4 ontology clinics and 3 application clinics were proposed.  After aligning proposals and schedule restrictions, 7 projects were selected for being carried out along the three selected weekends. Finally, OOPS! got involved in two of them, one ontology clinic and one hackathon project. The first one, “Evaluation of OOPS!, OQuaRE and Other Tools for FIBO Ontologies”, aims to explore the application of ontology quality measures to ontologies produced under the Financial Industry Business Ontology (FIBO) umbrella, while “Ontohub-OOR-OOPS! Integration” aims at the integration of OOPS! into the Ontohub and OOR ontology repositories. These two projects will take place the 13th of April 2013.

Now it is time for doing real work and getting some tangible outcomes. Results… in next posts.

Tagged , ,
%d bloggers like this: