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

Secure Collaboration and Intel's Reliance Point

Intel posted a blog article in mid February, about a research project that they call "Reliance Point". Based on the article, it appears that they are working on ways to selectively share data (addressing privacy and IP rights concerns), and provide integrity and isolation for that data. Intel refers to Reliance Point as a "trustworthy execution environment".

The environment is interesting in that it will bring together data from multiple providers, and allow the providers to perform calculations over the complete set. The providers have to agree on the algorithm that will be used to do the calculations and trust that the infrastructure will protect their data (and not allow other uses or algorithms to be executed, or the data to be revealed).

"Letting Data Breathe" is the name of the blog post. That title seems a bit exaggerated to me. For data to "breathe" (i.e., be integrated from multiple providers), there must be some standard set of semantics and structure that is supported by the providers, or there must a way to map between the syntax and (more importantly) the semantics of the different providers. Otherwise, what do calculations mean when run against data with unknown structure, and/or unknown and disparate semantics?

There is no mention of data integration in the article, just trustworthy data availability and negotiated algorithms. But, it seems to me that the project will not work if the problem of semantics is left to the data providers to solve out-of-band. In particular, how does one provider obtain the semantics of another's available data? How is this revealed while still protecting the IP rights of the provider? If proprietary data is shared, then it is likely proprietary all the way down to the layout and syntax of the data (perhaps defined by SQL). But, I have known companies that are reluctant to share even partial db structures since that information may reveal data or IP details.

To make Reliance Point work, something along the lines of OWL and RDF are needed - a way to specify semantics (OWL + SWRL/RIF, which I will discuss in another post) along with a way to handle multiple schemas (RDF). RDF defines a subject-predicate-object structure for data, which is very flexible. All databases can be translated into it. OWL and SWRL/RIF let you define equivalences, logical statements, disjointness and more, which are necessary to actually (semantically) integrate the data.

In theory, Reliance Point seems good, but Intel is working on the easier part of the problem (the infrastructure) and not the deeper problems that will prevent usage (integrating the data).

Andrea

More on modular ontologies and tying them together

There is a short email dialog on this topic on the Ontology Summit 2014 mail list. I thought that I would add the reply from Amanda Vizedom as a blog post (to keep everything in one place).

Amanda added:

The style of modularity you mention, with what another summit poster (forgive me for forgetting who at the moment) referred to as 'placeholder' concepts within modules, can be very effective. The most effective technique I've found to date, for some cases.

Two additional points are worth making about how two execute this for maximum effectiveness (they may match what you've done, in fact, but are sometimes missed & so worth calling out for others.

Point 1: lots of annotation on the placeholders. The location & connection of the well-defined concepts to link them to is often being saved for later and possibly for someone else. In order to make sure the right external concept is connected, whatever is known or desired of the underspecifies concept shoud be captured (in the location case, for example, may be that it needs to support enough granularit to be used for location at which a person can be contacted at current time, or must be the kind os location that has a shipping address, or is only intended to be the place of business of the enterprise to which Person is assigned & out of which they operate (e.g., embassy, business office, base, campus). That's often known or easily elicitable without leaving the focus of a specialized module, and can be captured in an annotation for use in finding existing, well defined ontology content and mapping.

Point 2: advantages of modules, as you described are best maintained when the import and mapping are done *not* in the specialized module, but in a "lower" mapping module that inherits the specialized module and the mapping-target ontologies. Spindles of ontologies, which can be more or less intricate, allow for independent development and reuse of specialized modules, with lower mapping and integration modules, with a spindle-bottom that imports all in the spindle and effectivle acts as the integrated query, testing, and application module for all the modules contained in that spindle, providing a simplified and integrated interface to a more complex and highly modular system of ontologies. Meanwhile, specialized modules can be developed with SMEs who don't know, care, or have time to think about the stuff they aren't experts about, like distinguishing kinds location or temporal relations or the weather. Using placeholders and doing your mapping elsewhere may sound like extra work, but considering what it can enable, it can be an incredibly effective approach.

Indeed, the second point is exactly my "integrating" ontology, which imports the target ontologies and does the mapping. As to the first point, that is very much worth highlighting. I err on the side of over-documenting and use various different kinds of notes and annotation. For a good example, take a look at the annotation properties in the FIBO Foundations ontology. It includes comment, description, directSource, keyword, definition, various kinds of notes, and much more.

Another set of annotation properties that I use (which I have not seen documented before, but that I think is valuable for future mapping exercises) are WordNet synset references - as direct references or designating them as hyponyms or hypernyms. (For those not familiar with WordNet, check out this page and a previous blog post.)

Andrea

Creating a modular ontology and then tying the pieces together

In my previous post, I talked about creating small, focused "modules" of cohesive semantic content.  And, since these modules have to be small, they can't (and shouldn't) completely define everything that might be referenced.  Some concepts will be under-specified.  

So, how we tie the modules together in an application?

In a recent project, I used the equivalentClass OWL semantic to do this. For example, in a Person ontology, I defined the Person concept with its relevant properties.  When it came to the Person's Location - that was just an under-specified (i.e., empty) Location class.  I then found a Location ontology, developed by another group, and opted to use that.  Lastly, I defined an "integrating" ontology that imported the Person and Location ontologies, and specified an equivalence between the relevant concepts.  So, PersonNamespace:Location was defined as an equivalentClass to LocationNamespace:Location. Obviously, the application covered up all this for the users, and my triple store (with reasoner) handled the rest.

This approach left me with a lot of flexibility for reuse and ontology evolution, and didn't force imports except in my "integrating" ontology.  And, a different application could bring in its own definition of Location and create its own "integrating" ontology.

But, what happens if you can't find a Location ontology that does everything that you need?  You can still integrate/reuse other work, perhaps defined in your integrating ontology as subclasses of the (under-specified) PersonNamespace:Location concept.

This approach also works well when developing and reusing ontologies across groups.  Different groups may use different names for the same semantic, may need to expand on some concept, or want to incorporate different semantics.  If you have a monolithic ontology, these differences will be impossible to overcome.  But, if you can say things like  "my concept X is equivalent to your concept Y" or "my concept X is a kind of your Y with some additional restrictions" - that is very valuable.  Now you get reuse instead of redefinition.

Andrea

Reuse of ontology and model concepts

Reuse is a big topic in this year's Ontology Summit.  In a Summit session last week, I discussed some experiences related to my recent work on a network management ontology.  The complete presentation is available from the Summit wiki.  And, I would encourage you to look at all the talks given that day since they were all very interesting! (The agenda, slides, chat transcript, etc. are accessible from the conference call page.)

But ... I know that you are busy.  So, here are some take-aways from my talk:

• What were the candidates for reuse?  There were actually several ontologies and models that were looked at (and I will talk about them in later posts), but this talk was about two specific standards:  ISO 15926 for the process industry, and FIBO for the financial industry.
• Why did we reuse since there was not perfect overlap of the chosen domain models/ontologies and network management?  Because there was good thought and insight put into the standards, and there also was tooling developed that we want to reuse.  Besides that, we have limited time and money - so jump starting the development was "a good thing". 
• Did we find valuable concepts to reuse?  Definitely.  Details are in the talk but two examples are:
• Defining individuals as possible versus actual.  For anyone that worries about network and capacity planning, inventory management, or staging of new equipment, the distinction between what you have now, what you will have, and what you might have is really important.
• Ontology annotation properties.  Documentation of definitions, sources of information, keywords, notes, etc. are extremely valuable to understand semantics.  I have rarely seen good documentation in an ontology itself (it might be done in a specification that goes with the ontology).  The properties defined and used in FIBO were impressive.
• Was reuse easy?  Not really.  It was difficult to pull apart sets of distinct concepts in ISO 15926, although we should have (and will do) more with templates in the future.  Also, use of OWL was a mapping from the original definition, which made it far less "natural"/native.  FIBO was much more modular and defined in OWL.  But due to ontology imports, we pretty much ended up loading and working through the complete foundational ontology.  

Given all this, what are some suggestions for getting more reuse?

1. Create and publish more discrete, easily understood "modules" that:
• Define a maximum of 12-15 core entities with their relationships (12-15 items is about the limit of what people can visually retain)
• Document the assumptions made in the development (where perhaps short cuts were made, or could be made)
• Capture the axioms (rules) that apply separately from the core entities (this could allow adjustments to the axioms or assumptions for different domains or problem spaces, without invalidating the core concepts and their semantics)
• Encourage evolution and different renderings of the entities and relationships (for example, with and without short cuts)
2. Focus on "necessary and sufficient" semantics when defining the core entities in a module and leave some things under-specified  
• Don't completely define everything just because it touches your semantics (admittedly, you have to bring all the necessary semantics together to create a complete model or ontology, but more on that in the next post)
• A contrived example is that physical hardware is located somewhere in time and space, but it is unlikely that everyone's requirements for spatial and temporal information will be consistent.  So, relate your Hardware entity to a Location and leave it at that.  Let another module (or set of modules) handle the idiosyncrasies of Location.

In my next post, I promise to talk more about how to combine discrete "modules" with under-specified concepts to create a complete solution.

Andrea

Restarting my blog and research

Thanks to everyone who has stuck with me over the past few years as I got consumed in projects and neglected my blog. That phase of my life was officially over in mid-December (2013). I just joined a small consulting firm, Nine Points Solutions. I now have the opportunity to both consult and to continue my research into extracting and managing policies in support of security, configuration and operations. I am very excited to have the opportunity to do this, and will share what I am doing and what I learn (when I can).

As part of restarting the blog, I did go through and clean up my overviews and list of blogs that I read. Please take a look and tell me about any blogs that I missed and that you find valuable. I didn't change the overall design of the site, because it works for me. But, let me know if that is not true for you, my readers.

Lastly, I want to bring everyone up-to-speed (at a very high level) on my work over the last two+ years ... I had the opportunity to architect and create a policy-based management system based on OWL ontologies and using semantic technologies. The system was written in Java and used the Stardog triple store from Clark and Parsia. Needless to say, I made mistakes, got a lot of help from the Stardog developers, and learned a lot. I will be sharing some of that learning in future posts.

Thanks again! I am looking forward to writing more in the coming weeks!

Andrea

What Makes Semantic Web and OWL Useful?

Well, to start with, the answer does NOT involve the use of XML (although that is convenient). XML is just a syntax (in search of a semantic :-). The real value in OWL is in the semantics that you can convey about a concept and its meaning relative to other concepts.

OWL builds on RDF and RDF-Schema (I talked about these briefly in an earlier post). From RDF and RDF-S, you get the ability to define classes (types of things), subclasses (more specific types of things), properties (and tie the applicability of the properties to different classes), and individuals (of a class). You can also label everything, and say where the concepts were defined using standard annotations. Interesting, but not enough, IMHO.

OWL then adds equality/inequality information for classes and properties, various property characteristics and restrictions (including cardinality), union/intersection and complement of classes, versioning information (like what an ontology is incompatibleWith), and other semantic details such as defining a class by an enumeration of its members or by specific values of its properties!

Sounds interesting - but what does this really mean? How about some examples?

• equivalentClass, equivalentProperty - You can say that a class "Dog" and a class "Canine" are equivalent. Therefore any instances of the class, Canine, are reasoned to also be instances of the class, Dog. This is very necessary when aligning databases and different representation schemes!
  
• disjointWith (class-level) - You can say that a class "Man" is disjoint from the class "Woman". Therefore, an instance cannot simultaneously belong to both classes - and a reasoner can infer that an instance that IS a Man, IS NOT a Woman.
  
• sameAs and differentFrom (individual-level) - You can say that the Man named "Frank" is different from the Man named "George". In the Open World Assumption (see my definitions post if this doesn't mean anything to you), the Man Frank and the Man George may be the same person. Sometimes this is useful, and sometimes it is dangerous. Both Open and Closed World Assumptions come in handy.
  
• inverseOf (property-level) - You can say that the property HasHusband is the inverse of HasWife. And, knowing that John's HasWife property is set to Mary, means that Mary's HasHusband property should/could be set to John.
  
• TransitiveProperty, SymmetricProperty and FunctionalProperty - These concepts take you back to your math days in high school. A transitive property means that if a is related to b, and b is related to c, then a is related to c. The most often cited example of this is ancestry. If Mary is the ancestor of Bob, and Bob is the ancestor of Sue, then Mary is the ancestor of Sue. A symmetric property is one that holds in any order. An example of this is friendship - if Mary is friends with Julie, then Julie is friends with Mary (or so we hope). Lastly, a functional property means that there is zero or one unique value for an individual (remember a function has one output for each input). Cool!
  
• allValuesFrom, someValuesFrom (property restrictions) - You can say that all values of the property, HasWife, must come from the class, Woman. Or, using the someValuesFrom restriction, you can indicate that at least one of the values of a property must range over the instances of a particular class. For example, a medical doctor can have a property HasCollegeDegrees, that must include at least one instance of the M.D. degree.
  
• oneOf - A great example of this is the property DaysOfTheWeek, which must be oneOf Sunday, Monday, Tuesday, ... (at least in English). This is your basic enumeration!
  
• hasValue - You can define a class by the value of its properties. For example, a Student is defined as someone with a value in its property, CurrentSchool.
  
• unionOf, complementOf, intersetionOf (class-level) - These allow the combination of classes and restrictions. A great example is the membership of the European Union - which can be defined as the union of all citizens of all the member countries.