Ontology development is an iterative process. Now that a first draft of the Yaffle Knowledge Mobilization Ontology (KMY) is finished, a next logical step is to review or evaluate the work thus far. To do this we borrow from the methodology outlined in Ontology Development 101: A Guide to Creating Your First Ontology (Natalya F. Noy  and Deborah L. McGuinness). The principles of ontology design are three:

  1. There is no one correct way to model a domain— there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate.
  2. Ontology development is necessarily an iterative process.
  3. Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.

The seven step methodology follows from these principles and are:

  1. Determine the domain and scope of the ontology
  2. Consider reusing existing ontologies
  3. Enumerate important terms in the ontology
  4. Define the classes and the class hierarchy
  5. Define the properties of classes
  6. Define the facets of the slots
  7. Create instances

In the KMY Working Group meetings, held February through June, 2013, a first draft  terms or concepts relating to the Knowledge Mobilization domain were listed and agreed upon. These concepts or classes, are listed in the Knowledge Mobilization Ontology v.0 page in this wiki.  Next, the scope of that domain was identified. A critical question in that process deserves revisiting.

For what types of questions the information in the ontology should provide answers?

Next, what are some competency questions that we can identify in order to assess the scope of the KMY?

"One of the ways to determine the scope of the ontology is to sketch a list of questions that a knowledge base based on the ontology should be able to answer, competency questions (Gruninger and Fox 1995). These questions will serve as the litmus test later: Does the ontology contain enough information to answer these types of questions? Do the answers require a particular level of detail or representation of a particular area? These competency questions are just a sketch and do not need to be exhaustive."

What are our competency questions? 

Steps two through seven were followed in designing KMY. We will (quickly) review these steps and complete the review exercise by re-examining KMY Use Cases, and moving through the application (as various users) to determine what classes are redundant, what classes require refining, or do not meet our needs. The same assessment will be applied to properties.

NOTES:

  1. class: kmyBrokeringProcess Is this a property or a class?
  2. class: kmy:LeadPartnerRole A subclass of PartnerRole. To be renamed KeyPartner, in alignment with KMb terminology. 
  3. class: kmy:CollaboratorPartnerRole (Public sitting on advisory committee); Do we need this? To find out how many non-university people are engaged with university on committees, etc. Would the project class have contributors that are external and on committees? What benefit are we getting by naming the "flavour" of the association?
  4. kmy:LaySummary Should this be in KMY or VIVO Core as part of the Overview property group.

 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.