OntoGraph V1.0.1 and a Discussion of VOWL

Continuing the evolution of OntoGraph, we published fixes to three minor issues, and updated the README text to address user questions that we received. The README, code, and jar and zip (in the /ontograph-<major.minor.release#> directory) are all updated. The changes are all described in the commit history. In addition, a few new issues were added to our backlog based on feedback and questions. Take a look at the current set of issues and let me know if you have issues to add or want to highlight which ones are important to you. Or, you can just add a comment to the issues directly.

Right now, we are planning on another update (V1.1.0) at the end of October. We will be addressing all the known bugs and adding support for diagramming straight RDF - i.e., to support Linked Data.

Enough of that ... Let's move onto discussing the graph output for a VOWL visualization from OntoGraph versus what is defined in the official specification. First off, per the specification ...

OWL elements such as owl:allValuesFrom, owl:someValuesFrom, owl:hasValue, rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy, and owl:DataRange (rdfs:datatype in OWL 2 which has a representation in the current specification) are not part of the VOWL visualization but could be displayed in another way (e.g. as text information in a tooltip or sidebar). This is also the case for the OWL elements owl:Ontology, owl:differentFrom, owl:AllDifferent, owl:distinctMembers, owl:Restriction, owl:onProperty, owl:AnnotationProperty, and owl:OntologyProperty that serve as containers of other elements, link individuals, or define ontology metadata.

OntoGraph diverges from the specification for annotation properties. These are displayed in a graph, similar to datatype properties. Ignoring these properties can omit valid information (usable constructs) from a graph. For example, the Friend-Of-A-Friend ontology (FOAF) defines annotation properties for information mapped from the Web of Trust (WOT) and Dublin Core schemas. These properties (especially ones from Dublin Core such as "description") are often used on class, property and element declarataions.

For many of the restriction-related elements listed above (such as owl:Restriction, owl:all/someValuesFrom, ...), OntoGraph outputs labeled edges and text in "UML boxes" that define the details. In my experience, when restrictions are used, understanding them is essential to understanding the ontology.

As regards OWL connectives, VOWL easily shows equivalencies, unions, intersections, complements or disjoint definitions between named classes. But, the defined graphing approach fails when one or more of the related classes are blank (anonymous/un-named) nodes. Consider how equivalent classes are shown - as a circle "with a double border... One of the class labels is the main label, while the rest is listed in square brackets (abbreviated if they do not all fit)." Next, consider how connectives (unions, intersections, etc.) are shown - as two or more classes connected via dashed lines (without arrowheads), to an image of a Venn diagram labeled with a union, intersection or complement logical symbol. The Venn diagram image "represents the anonymous class of the owl:unionOf [owl:intersectionOf, ...] statement".

There are two problems with these conventions when dealing with nested blank nodes. For example, consider a class, foo, that is equivalent to the union of two other blank nodes - the complement of a class, bar, and an intersection of the classes, classA and classB. Since the union node (the equivalency) is anonymous/un-named, there is nothing to display on the second line of foo's node label. As for the second problem, although the union, intersection and complement images can be diagrammed and connected to the relevant classes via dashed lines ... there is no way to understand that the complement and intersection definitions are the entities being unioned, unless arrowheads are used. (Without arrowheads, there could be many interpretations - such as, classB is the intersection of classA and a union declaration.) In standard VOWL, there are simply dashed lines running between all the images. This is shown in the image below.

This same ontology is shown as output by OntoGraph:

OntoGraph addresses VOWL's connectives issues by drawing equivalencies similar to "Subclass of" declarations, and by using arrowheads to indicate exactly what is unioned, intersected or complemented. As another example, here is a snippet of a graph of the W3C Turtle Primer, a complex ontology based on union, intersection, complement and disjoint declarations, as well as restrictions. The majority of this detail would be missing in an "official" VOWL diagram.

Another thing that is missing in the VOWL specification is the display of individuals. Whereas many ontologies do indeed focus on the TBox (the concepts and relationships of a domain), the Linked Data and application worlds have to deal with individuals/instances (the ABox). Being able to diagram your instances is important. But, even if you want to restrict yourself to the TBox world, when you have "one-of" definitions (for enumerations and restrictions), graphing these is important. OntoGraph accepts that Abox individuals are not graphed in VOWL, but does support individual diagrams in the custom, Graffoo and UML visualizations. In addition, OntoGraph displays "one-of" declarations using a UML Note format. An example can be seen at the bottom of the image above.

There are two more major (but related) issues to discuss regarding VOWL ... The first issue involves how node and property names are displayed in a graph. VOWL recommends that an implementation display any rdfs:label that may be defined for a class or property. But, "if elements do not have an rdfs:label, it is recommended to take the last part of the URI as label, i.e. the part that follows the last slash (/) or hash (#) character. Labels may be abbreviated if they do not fit in the available space (e.g. "Winnie-the-Pooh" → "Winnie…"). The full label should be shown on demand in these cases (e.g. in a tooltip or sidebar)." Unfortunately, this last aspect is not possible to support in yEd or any static copy of a graph. And, even the Example in the VOWL Specification does not show the full label when an abbreviated name is displayed!

The second, related issue is that because either a label or local name is displayed, VOWL does not include prefixes/full URIs in its graph. Instead, colors are used to distinguish what is "external" to an ontology (i.e., when a declared element uses a different base URI than the ontology URI/IRI). "External" classes and properties are shown in a darker color (darker blue for OWL classes and properties). In addition, the class nodes also carry the word, "external", in brackets, on the second line. There are several problems with this approach:

• It will not be possible to distinguish the source of "external" references, and the problem is compounded if there are multiple imported/referenced vocabularies or ontologies. For example, the FOAF diagram includes a node (Spatial Thing) from the WGS84 Geo Positioning RDF vocabulary (WGS84) and another node (Concept) from the SKOS vocabulary (skos). Both of these are displayed in dark blue in the VOWL graph, with the text, "[external]", under their labels. OntoGraph follows this convention.
• If there are equivalencies to multiple class declarations (from different, external ontologies) but those declarations have the same local name, then the local name will be repeated. For example, FOAF defines equivalent classes for the FOAF Person concept - linking it to the Schema.org Person class and the Person class from Tim Berner-Lee's Contact ontology. The result is a node whose label is "Person [Person, Pe...]". For domain experts reviewing a graph, this would be confusing at best. As above, OntoGraph follows this convention.

That's it for VOWL! Let me know if this information is helpful. Thanks for reading!

Andrea