Monday, January 25, 2016

Ontologies for Reuse Versus Integration

There is ongoing email discussion in preparation for this year's Ontology Summit on "semantic integration". I thought that I would share one of my recent posts to that discussion here, on my blog. The issue is reuse versus integration ...

For me, designing for general reuse is a valid goal and valuable (if you have the time, which is not always true). (Also it was the subject of the Summit 2 yrs ago and many of my posts from that time - March-May 2014!) But reusing an ontology or design pattern in multiple places is not semantic integration. Reuse and integration are different beasts, although they are complimentary.

I have designed ontologies for both uses (reuse and integration), but my approach to the two is different. Designing for reuse is usually focused on a small domain that is well understood. There are general problem areas (such as creating ontologies/design patterns for events, or to support Allen's time interval algebra) that are generally applicable. In these areas, general design and reuse makes sense.

Over the years, however, I have been much more focused on designing for integration (especially in the commercial space). In my experience, companies are always trying to combine different systems together - whether these systems are legacy vs new, systems that come into the mix due to acquisition, internal (company-centric) vs external (customer-driven), dictated by the problem space (combining systems from different vendors or different parts of an organization to solve a business problem), ...

It is ok to try to be forward-thinking in designing these integration ontologies ... anticipating areas of integration. But, I have been wrong in my guesses (of what was needed in the "future" ontology) probably more than I have been right - unless it was indeed in general problem domains.

So, my integration "rules of thumb" are:
  • Get the SMEs in a particular domain to define the problem space and their solution (don't ever ask the SMEs about integrating their domains)
  • Don't ever give favor to one domain over another in influencing the ontology (you are sure to not be future-proof)
  • Focus on the biggest problem areas first, and find the commonalities/general concepts (superclasses)
  • Place the domain details "under" these superclasses
  • Never try to change the vocabulary of a domain, just map to/from the domains to the "integration" ontology
  • Never map everything in a domain, just what needs to be integrated
  • Look for smaller areas of "general patterns" that can be broadly reused
  • Have new work start from the integrating ontology instead of creating a totally new model
  • Update the integrating ontology based on mapping problems and new work (never claim that the ontology is immutable)
  • Utilize OWL's equivalentClass/disjointFrom/intersectionOf/unionOf/... (for classes), sameAs/differentFrom (for individuals) and class and property restrictions to tie concepts together in the "mapped" space
  • Be focused on concept diagrams and descriptions, documenting mapping details, ... and not that you are using an ontology
  • Clearly document ontology/concept, relationship, ... evolution
Let me know if this resonates with you or if you have different "rules of thumb".


Sunday, January 3, 2016

2016 and continuing posts on ontologies

Well, 2015 seems to have gotten away from me. Over the last year, I have been working to design and implement several ontologies for policy-based management. The work is based on Complexible's Stardog graph database, with services accessed through a RESTful API, and with a front-end, single-page web application created with Bootstrap and Backbone. It has been a blast working with and learning all these technologies, and my new year's resolution is to get back into writing my blog and share some of my learnings.

Another thing that I am doing is related to the International Association for Ontology and Its Applications (IAOA). More specifically, I am a part of the Semantic Web Applied Ontologies Special Interest Group (SWAO SIG). The SIG is continuing the work of the 2014 Ontology Summit and facilitating discussions of ontologies and their development and application. I will be contributing to those discussions in 2016, and started with a short post on the various definitions of the term, ontology. Check out the SWAO link above for the discussion!

That's it for now. Happy 2016!