SOFTWARE AND KNOWLEDGE REuse have generated considerable interest because they reduce development time and the resources that projects require. For knowledge-based systems, in particular, the high cost of knowledge acquisition makes reuse essential. However, reuse involves these challenges: heterogeneity of representation formalisms, languages, and tools; lexical and semantic problems; assumptions implicit in each system; and commonsense-knowledge losses. Ontologies are a way around these obstacles. They are useful for unifying database, data-warehouse, and knowledge-base vocabularies and even for maintaining consistency when updating corporate memories used in knowledge management.To meet the challenge of building ontologies, we've developed Methontology, 1,2 a framework for specifying ontologies at the knowledge level, 3 and the Ontology Development Environment. This article presents our experience in using Methontology and ODE to build the Chemicals ontology. 4 The challenge of building ontologiesOntology building is a craft rather than an engineering activity. Each development team usually follows its own set of principles, design criteria, and phases. The absence of structured guidelines and methods hinders the development of shared and consensual ontologies within and between teams, the extension of an ontology by others, and its reuse in other ontologies and final applications. We believe that the source of these problems is the absence of an explicit and fully documented conceptual model upon which to formalize the ontology.Like knowledge-based-system development, ontology development faces a knowledge-acquisition bottleneck. Unlike KBS developers, ontology developers (ontologists) lack sufficiently tested and generalized methodologies recommending what activities should be performed and at what stage of ontology development. (For descriptions of related work, see the sidebar.)Ontology developers often switch directly from knowledge acquisition to implementation, which poses these problems:First, the conceptual models are implicit in the implementation codes. Making the conceptual models explicit usually requires reengineering.Second, ontological commitments 5 and design criteria are implicit and explicit in the ontology code.Third, domain experts and human end users have no understanding of formal ontologies codified in ontology languages. 6 Research has shown that, using the Ontology Server browser tools, 7 experts and users could gain a full understanding of and validate taxonomies and partially understand instances. However, they were unable to