{"id":5913,"date":"2017-01-11T16:52:55","date_gmt":"2017-01-11T21:52:55","guid":{"rendered":"https:\/\/enterprise-knowledge.com\/?p=5913"},"modified":"2017-05-31T18:12:44","modified_gmt":"2017-05-31T22:12:44","slug":"ontology-design-best-practices-part-ii","status":"publish","type":"post","link":"https:\/\/enterprise-knowledge.com\/ontology-design-best-practices-part-ii\/","title":{"rendered":"Ontology Design Best Practices – Part II"},"content":{"rendered":"

This is the second in a two part blog series, sharing our best practices collected through our efforts in ontology consulting. The <\/span>first part of the series<\/span><\/a> described 5 key recommendations for any new ontology project. These recommendations need to be in place for any ontology project to be successful. This second blog provides specific methods for designing a business ontology (that being, one that will be intuitive, manageable, and usable to those who need it).<\/span><\/p>\n

As a reminder, our most successful ontology projects deliver business users new and meaningful ways to see relationships between content and information. The complexity of the ontology is hidden from the business users who are able to discover related content without the need for formal or rigid navigation between content. The content owners\/administrators are able to manage the relationships between content at a much more granular level with minimal additional effort. Often, these changes give our customers new ways to consolidate and present content and information both internal and external to their organization. Most importantly the value of these changes is visible to the project stakeholders and sponsors.<\/span><\/p>\n

The design recommendations in this post assume that the project recommendations in <\/span>Part I<\/span><\/a> have already been implemented. These recommendations are focused on maximizing business value and usability.<\/span><\/p>\n

Use Non-Technical Terms<\/b><\/h2>\n


\n\"Non-TechnicalMost ontology designers use terms like graphs, classes, nodes, and edges. Though these are accurate descriptions of what we are designing, they make ontologies seem unapproachable and difficult. Make a point of replacing these highly technical terms with terms that are more recognizable to your stakeholders.<\/span><\/p>\n

 <\/p>\n\n\n\n\n\n\n\n\n
Technical Term<\/b><\/td>\nBusiness Term<\/b><\/td>\n<\/tr>\n
Class<\/span><\/td>\nEntity or Thing<\/span><\/td>\n<\/tr>\n
Domain<\/span><\/td>\nCategory<\/span><\/td>\n<\/tr>\n
Attributes<\/span><\/td>\nProperties or Features<\/span><\/td>\n<\/tr>\n
Edge<\/span><\/td>\nRelationship<\/span><\/td>\n<\/tr>\n
SparQL<\/span><\/td>\nQuery language like SQL<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nIt is important that you communicate regularly with your stakeholders. Using non-technical terms will make the project feel more approachable and more business focused. As a result, it will be easier to get feedback from your stakeholders on their wants and needs.<\/span><\/p>\n

Identify Your Domain<\/b>\u00a0<\/span><\/h2>\n

\"IdentifyThe first step in creating an ontology is to identify the domain to which it belongs. By this, I mean the category or topical area the ontology describes. This cannot be done in a vacuum. Review your content and then come up with 3-4 terms that describe your domain. Use these terms to search for public ontologies with similar domains. To find similar domains that are publicly available,\u00a0look in places like the following:\u00a0<\/span><\/p>\n

 <\/p>\n