Monday, October 23, 2017

OntoGraph Server

In order to make everyone's life easier, we (Nine Points Solutions) are sponsoring a hosted server running the latest release of OntoGraph and Stardog.

Feel free to give it a try by uploading your ontology, and generating a graph.

Anything that is uploaded is used only in generating the graph and then all details are deleted.

Andrea

P.S. Maintenance will be done (if needed) on Saturdays, noon-4pm Eastern time.

Graphing with OWL Reasoning

Another version of OntoGraph (V1.0.2) was released today. The main goal was to add OWL reasoning to determine individuals' types. Why might this be important? Well, an individual might be referenced in an ontology, but not defined with a rdfs:type. Or, the individual might be defined with a type, and then also used as the subject or object in a triple. If the predicate of the triple (the relating property) is defined with domains and/or ranges, then a reasoner can infer the type(s) of the individual. This is also useful to find errors in the ontology, its logic and its semantics (more on that later).

Here is a simple example:
@prefix ninepts: <http://purl.org/ninepts/test#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

<http://purl.org/ninepts/test> rdf:type owl:Ontology .

<http://purl.org/ninepts/test#class1> rdf:type owl:Class .

<http://purl.org/ninepts/test#class2> rdf:type owl:Class .

<http://purl.org/ninepts/test#class3> rdf:type owl:Class .

<http://purl.org/ninepts/test#class4> rdf:type owl:Class .

<http://purl.org/ninepts/test#objProp1> rdf:type owl:ObjectProperty ;
   rdfs:domain ninepts:class3, ninepts:class4.

<http://purl.org/ninepts/test#objProp2> rdf:type owl:ObjectProperty ;
   rdfs:range ninepts:class1, ninepts:class2 .

<http://purl.org/ninepts/test#individual1> ninepts:objProp1 ninepts:individual2.

<http://purl.org/ninepts/test#individual3> ninepts:objProp2 ninepts:individual4.
This example is written in using the Turtle syntax, and basically defines 4 classes (class1 - class4), 2 properties (objProp1 and objProp2), and 4 individuals (individual1 - individual4). The property, objProp1, is defined with 2 classes as its domain (and no range), while objProp2 is defined with 2 classes as its range (and no domain). (No domain or no range for an object property means that there is no intended semantic - that anything, any "owl:Thing", is the domain or range.) The individuals are defined in 2 triples indicating that individual1 is related to individual2 (via objProp1), and individual3 is related to individual4 (via objProp2).

Without OWL reasoning, the individuals have no types. In fact, OntoGraph does not even find any individuals since it "locates" individuals by querying for any entity that has an explicit type of owl:NamedIndividual, or that has a type that begins with a prefix other than OWL or RDF/RDFS. (The query allows us to avoid returning classes (type owl:Class) and properties (type owl:ObjectProperty or owl:DatatypeProperty) when searching for individuals and their types.)

But, if we run OntoGraph with reasoning turned on, then we find that there are indeed 4 individuals, and that individual1 has the types defined for the domain of objProp1, and individual2 has the types defined for the range of objProp2. This is shown in the figure below, which was generated by OntoGraph.



If this seems odd, think about how the reasoner works ... The ontology defined individual1 as the subject of a triple with the predicate, objProp1. We know that any subject (the domain of the property) of objProp1 is defined to be of types, class3 and class4. So, individual1 is "reasoned" to be of those 2 types. Similarly, individual4 is the object of a triple with the predicate, objProp2. And, we know from the ontology that any object (the range of the property) of objProp2 is defined to be of types, class1 and class2. There you have it ...

The reasoner can't determine anything about individual2 or individual3, except that they are themselves individuals. The reasoner figures this out since they are an object and subject (respectively) in triples whose predicates are object properties. By the way, the reasoner also determined that they are of type, owl:Thing, which doesn't tell you much (everything is of type, owl:Thing, unless there is a logical inconsistency in the ontology). OntoGraph does not bother to show that detail since it adds no information to the graph (but does clutter it up).

Now, why did I talk earlier, about illustrating errors in the ontology? If you look at the ontology definition above, you see that the domain of objProp1 is "ninepts:class3, ninepts:class4". Many people writing ontologies mistakenly think that the definition means that the domain is EITHER class3 OR class4. But, that is incorrect. The definition actually means that the domain is BOTH class3 AND class4. Therefore, an individual must be of BOTH types (multiple inheritance), or stated another way, is defined as the intersection of both types. There are some ways to get around this, as discussed in these two posts from StackOverflow (using one property with multiple domains and how to define multiple domains and ranges). I am not going to repeat the answers (which are both very good), but will talk more about reasoning and errors in my next post.

As always, let me know if you have any questions.

Andrea

Friday, October 6, 2017

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