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?
- 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)
- 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
No comments:
Post a Comment