{"id":5886,"date":"2017-01-04T16:59:02","date_gmt":"2017-01-04T21:59:02","guid":{"rendered":"https:\/\/enterprise-knowledge.com\/?p=5886"},"modified":"2020-01-08T15:11:45","modified_gmt":"2020-01-08T20:11:45","slug":"ontology-design-best-practices-part","status":"publish","type":"post","link":"https:\/\/enterprise-knowledge.com\/ontology-design-best-practices-part\/","title":{"rendered":"Ontology Design Best Practices – Part I"},"content":{"rendered":"

EK provides extensive Ontology Design services for our customers. Much of what we know comes from lessons learned on a wide variety of projects. Over time we\u2019ve developed a library of best practices regarding what to do and what not to do when creating an ontology. Though this topic is already covered elsewhere, I\u2019ve found much of the existing writing to be overly academic or theoretical. My goal in this article is to provide practical advice on how to design a business ontology (that being one that will be intuitive, manageable, and usable to those who need it).<\/span><\/p>\n

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

I have divided this blog into two parts. In this, the first part of this blog, I list 5 key recommendations that should be implemented as part of any Ontology project. In part II of the series<\/a>, I will describe specific methods that we use to design an effective business ontology.<\/span><\/p>\n

1. Set Measurable Goals<\/b><\/h2>\n

\"Target\"Ontologies come in many forms and can serve many purposes. It is important that you have a plan in mind as to how you will use your ontology. This plan has to be specific with measurable outcomes tied to it. We often hear our clients say they want to create an ontology that will support a semantic web application so that their users can discover relationships between content. While this goal sounds good, it is not measurable and as a result puts very few limits as to what the ontology should support. Ontologies based on open ended goals frequently lead to poor performance and failure. <\/span><\/p>\n

We help our clients avoid this through our Ontology Workshop. As part of the workshop we meet with key stakeholders to identify practical actions that the ontology needs to support. We define user personas, use cases, and identify exemplar content types and topics, all of which provides a targeted focus for the overall design. At the end of the workshop we have an agreed upon set of use cases that will inform the design of the ontology. This approach allows us to put specific boundaries around what the ontology should support and allows us to measure success along the way so that we can purposefully evolve the ontology design over time.<\/span><\/p>\n

2. Select from an Existing Specification<\/b><\/h2>\n

\"W3CThere are a large number of ontology specifications (SKOS, OWL, RDF, etc.). Take advantage of these existing specifications when designing your ontology. The specifications make it easy to transfer your ontology from one tool to another. They also make it easy to borrow from other existing ontologies. Finally, there are many libraries that automatically implement features for ontologies using standard ontologies.<\/span><\/p>\n

It is important to select the right one for your needs. There are a number of factors that play into this selection, including:<\/span><\/p>\n