Knowledge validation is still a challenge when constructing knowledge-based systems. It is one of the major reasons for user rejection and disagreement between project participants. Systematic and periodic reviews of the domain ontology, with a formal agreement of the whole development team (including the experts) are a recommended good practice. Nevertheless, these reviews do not guarantee system success. This paper presents a case study of the construction process of a knowledge-based system. The process involved a group of experts with varied work experience. A great deal of negotiation happened during knowledge acquisition meetings, which took place during a 6-month period. After each meeting, changes in the ontology were verified through a web-based questionnaire, from which either consensual agreement was reached (and changes implemented) or the need for a new meeting was ascertained. An explanatory review at the beginning of each meeting further solidified the understanding of all participants. This cyclic process led to a final version of the ontology, ratified by all participants. This model supports diagnosis and prediction of failures in mechanical drilling rigs in oil exploration sites. Unexpectedly, during system trials, experts disagreed with results, which raised questions about the validity of the domain ontology. The system’s explanation module provided a cornerstone for a reflective process that helped identify inconsistencies and corrections needed. These reflections led to adjustments to the ontology, and a reflection about previous decisions and element definitions. Explanations, derived from the ontology and instantiated using real scenarios, shed light on knowledge gaps and semantic inconsistencies of the domain model. In this paper we have three main goals: (1) to present our ontology construction process; (2) to highlight a particular situation where results were inadequate; and (3) to show how the explanation system helped experts and knowledge engineers identify gaps. We also present lessons learned from the whole process, that may apply in other situations.

在构建基于知识的系统时，知识验证仍然是一个挑战。这是项目参与者之间用户拒绝和意见分歧的主要原因之一。建议在整个开发团队（包括专家）的正式同意下，对领域本体进行系统和定期的审查。但是，这些审查不能保证系统成功。本文介绍了一个基于知识的系统的构建过程的案例研究。该过程涉及一组具有不同工作经验的专家。在为期六个月的知识获取会议期间，进行了大量谈判。每次会议后，都会通过基于网络的问卷调查来验证本体的变化，从中达成共识（并进行更改）或确定需要召开新会议。每次会议开始时进行的解释性审查进一步巩固了所有与会者的理解。这个循环过程导致了所有参与者都认可的本体的最终版本。该模型支持石油勘探现场机械钻机故障的诊断和预测。出乎意料的是，在系统试验期间，专家们不同意结果，这引发了有关域本体有效性的问题。该系统的解释模块为反思过程提供了基石，该过程有助于识别不一致之处和所需的更正。这些反思导致对本体的调整，以及对先前决策和元素定义的反思。说明，从本体派生并使用实际场景实例化，揭示了领域模型的知识差距和语义不一致。在本文中，我们有三个主要目标：（1）介绍我们的本体构建过程；（2）强调结果不足的特定情况；（3）展示解释系统如何帮助专家和知识工程师识别差距。我们还将介绍从整个过程中学到的经验教训，这些经验教训可能适用于其他情况。（3）展示解释系统如何帮助专家和知识工程师识别差距。我们还将介绍从整个过程中学到的经验教训，这些经验教训可能适用于其他情况。（3）展示解释系统如何帮助专家和知识工程师识别差距。我们还将介绍从整个过程中学到的经验教训，这些经验教训可能适用于其他情况。