Ontology Engineering. Elisa F. Kendall

be designed at any level of abstraction, but with reference to Figure 2.1, typically specifies knowledge at the context, conceptual, and/or logical layers. By comparison, entity-relationship models can be designed at a conceptual, logical, or physical layer, and software models at the physical and definition layers. Knowledge bases, content management systems, databases, and other repositories are implemented at the instance layer. In terms of the Zachman Framework™,¹² which is well known in the data engineering community, an ontology is typically specified with respect to at least one of the elements (what, how, where, who, when, why) across the top three rows of the matrix—executive perspective, business perspective, and architect’s perspective. A comprehensive ontology architecture might include some or all of these perspectives, with increasing granularity corresponding to increasingly specific levels in the framework.

Figure 2.1: Abstraction layers.

      An ontology architecture developed to address requirements of a finance application might include:

      1. a foundational layer of reusable and customized ontologies for metadata and provenance description (e.g., based on Dublin Core,¹³ SKOS (Simple Knowledge Organization System),¹⁴ and the PROV Ontology (PROV-O),¹⁵ potentially with extensions that are context-specific);

      2. a domain-independent layer of reusable ontologies covering standard concepts for dates and times, geopolitical entities, languages, and other commonly used concepts, building on the metadata layer—there are standardized and de facto standards that may be used for this purpose;