Showing posts with label diagramming. Show all posts
Showing posts with label diagramming. Show all posts

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

Wednesday, September 13, 2017

OWL Ontology Graphing Program Available as Open Source

It has been forever since I last blogged on this site (more than a year, for which I feel terrible). I have been wrapped up in work for a customer whose details are proprietary, and I was also slowly working to create (what I hope will be valuable) ontology graphing software. I wished that the work on the graphing software would have been available sooner, but better late than never ... The graphing software is called OntoGraph, is finally at a point where it is acceptable to publish, and I can freely discuss it on the blog! So, here we go ...

You can check out the work at Nine Points Solutions' GitHub repository.

OntoGraph is a Spring Boot application for graphing OWL ontologies (yes, the title says this). It lets you go from XML/RDF, Turtle and several other OWL syntaxes to a custom, Graffoo, VOWL or UML-like diagram. For example, you can go from something like this (this excerpt comes from the Friend of a Friend, FOAF.rdf ontology - you can see the complete FOAF ontology at http://xmlns.com/foaf/spec/index.rdf) ...



To ...



The above image is a VOWL rendering of FOAF.

OntoGraph is designed with a Bootstrap- and Backbone-based GUI (written in Javascript), interfacing with a RESTful API. The main program is written in Java. It operates by creating various GraphML outputs of a user-provided OWL ontology file. (Or, it also accepts a zip file of a set of ontology files). The program stores the ontologies in the Stardog triple store, then runs a series of queries to return the necessary information on the classes, properties, individuals... to be diagrammed. Layout of the resulting GraphML is handled by another program. (We recommend yEd.)

Four visualizations of ontology data can be generated:
  • Custom format (defined to fit existing business or personal preferences)
  • Graffoo
  • UML-like
  • VOWL
And, information can be segmented to display:
  • Class-related information (subclassing, equivalent and disjoint classes, class restrictions, ...)
  • Individual instances, their types, and their datatype and object property information
  • Property information (datatype and object properties, functional/symmetric/... properties, domain and range definitions, ...)
  • Both class and property information
Complete information about OntoGraph, how to run it, and issues and upcoming features are available at the GitHub repository. Also, there is a pre-publication version of a paper there, there explains OntoGraph and why it was created. (The paper will be available in the next issue of the Journal of Applied Ontology, from IOS Press.)

So, now that OntoGraph is finally published, I can start to blog about its components, design and design decisions, testing, and lots of other details. I just needed something concrete!

I hope that you find the program useful!

Andrea

Saturday, July 26, 2014

Another OWL diagramming transform and some more thoughts on writing

With summer in full-tilt and lots going on, I seem to have lost track of time and been delinquent in publishing new posts. I want to get back into writing slowly ... with a small post that builds on two of my previous ones.

First, I wrote a new XSL transform that outputs all NamedIndividuals specified in an ontology file. The purpose was to help with diagramming enumerations. (I made a simplifying assumption that you added individuals into a .owl file in order to create enumerated or exemplary individuals.) The location of the transform is GitHub (check out http://purl.org/NinePts/graphing). And, details on how to use the transform (for example, with the graphical editor, yED) is described in my post, Diagramming an RDF/XML ontology.

If you don't want some individuals included, feel free to refine the transform, or just delete individuals after an initial layout with yEd.

Second, here are some more writing tips, that build on the post, Words and writing .... Most of these I learned in high school (a very long time ago), as editor of the school paper. (And, yes, I still use them today.)
  • My teacher taught us to vary the first letter of each paragraph, and start the paragraphs with interesting words (e.g., not "the", "this", "a", ...). Her point was that people got an impression of the article from glancing at the page, and the first words of the paragraphs made the most impression. If the words were boring, then the article was boring. I don't know if this is true, but it seems like a reasonable thing.
  • Another good practice is to make sure your paragraphs are relatively short, so as not to seem overwhelming. (I try to keep my paragraphs under 5-6 sentences.) Also, each paragraph should have a clear focus and stick to it. It is difficult to read when the main subject of a paragraph wanders.
  • Lastly, use a good opening sentence for each paragraph. It should establish the contents of the paragraph - setting it up for more details to come in the following sentences.
You can check out more writing tips at "Hot 100 News Writing Tips".

Andrea

Tuesday, May 20, 2014

Diagramming an RDF/XML OWL ontology

Over the course of time (many times, in fact), I have been asked to "graph" my ontologies to help visualize the concepts. Anyone who has worked with Protege (or the Neon Toolkit or other tools) knows that none of the tools give you all the images that you really need to document your work. I have often resorted to hand-drawing the ontologies using UML diagrams. This is both painful and a huge time sink.

Recently, I was reading some emails on the Linked Data community distribution list about how they generate the LOD cloud diagram. Omnigraffle is used in the "official" workflow to create this diagram, but that tool costs money to buy. One of the email replies discussed a different approach.

A gentleman from Freenet.de needed to draw a similar diagram for the data cloud for the Open Linguistics Working Group. His team could not use the same code and processing flow as the LOD cloud folks, since they didn't have many Mac users. So, they developed an alternative based on GraphML. To create the basic graph, they developed a Python script. And, ...
Using yed's "organic" layout, a reasonable representation can be achieved which is then manually brought in shape with yed (positioning) and XML (font adjustment). In yed, we augment it with a legend and text and then export it into the graphic format of choice.
Given my propensity to "reuse" good ideas, I decided to investigate GraphML and yEd. And, since GraphML is XML, ontologies can be defined in RDF/XML, and XSLT can be used to transform XML definitions, I used XSLT to generate various GraphML outputs of an ontology file. Once the GraphML outputs were in place, I used yEd to do the layout, as the Freenet.de team did. (It is important to note that the basic yEd tool is free. And, layout is the most difficult piece of doing a graphic.)

So, what did I find? You can be the judge. The XSLTs are found on GitHub (check out http://purl.org/NinePts/graphing). There are four files in the graphing directory:
  • AnnotationProperties.xsl - A transform of any annotation property definitions in an RDF/XML file, drawing them as rectangles connected to a central entity named "Annotation Properties".
  • ClassHierarchies.xsl - A transform of any class definitions in an RDF/XML file, drawing them in a class-superclass hierarchy.
  • ClassProperties.xsl - A transform of any data type and object property definitions in an RDF/XML file, drawing them as rectangles with their types (functional, transitive, etc.) and domains and ranges.
  • PropertyHierarchies.xsl - A transform of any data type and object property definitions in an RDF/XML file, drawing their property-super property relationships.
I executed the transforms using xsltproc. An example invocation is:
xsltproc -o result.graphml ../graphing/ClassProperties.xsl metadata-properties.owl
I then took the result.graphml and opened it in the yEd Graph Editor. (If you do the same, you will find that all the classes, or properties lay on top of each other. I made no attempt to do any kind of layout since I planned to use yEd for that purpose.) For the class properties graph (from the above invocation), I used the Layout->Radial formatting, with the default settings. Here is the result:



I was impressed with how easy this was!

The really great thing is that if you don't like a layout, you can choose another format and even tweak the results. I did some tweaking for the "Property Hierarchies" diagram. In this case, I ran the PropertyHierarchies.xsl against the metadata-properties.owl file and used the Hierarchical Layout on the resulting GraphML file. Then, I selected all the data properties and moved them underneath the object properties. Here is the result:



Admittedly, the diagrams can get quite complex for a large ontology. But, you can easily change/combine/separate the XSLT transforms to include more or less content.

With about a day and half's worth of work (and using standards and free tooling), I think that I saved myself many frustrating and boring hours of diagramming. Let me know if you find this useful, or you have other suggestions for diagramming ontologies.

Andrea