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
Andrea
Posts
