IDEF5

IDEF5 (Integrated Definition for Ontology Description Capture Method) is a software engineering method to develop and maintain usable, accurate domain ontologies.[1] This standard is part of the IDEF family of modeling languages in the field of software engineering.

Example of an IDEF5 Composition Schematic for a Ballpoint Pen.

Overview

In the field of computer science ontologies are used to capture the concept and objects in a specific domain, along with associated relationships and meanings. In addition, ontology capture helps coordinate projects by standardizing terminology and creates opportunities for information reuse. The lDEF5 Ontology Capture Method has been developed to reliably construct ontologies in a way that closely reflects human understanding of the specific domain.[1]

In the IDEF5 method, an ontology is constructed by capturing the content of certain assertions about real-world objects, their properties, and their interrelationships and representing that content in an intuitive and natural form. The IDEF5 method has three main components:[2]

  • A graphical language to support conceptual ontology analysis
  • A structured text language for detailed ontology characterization, and
  • A systematic procedure that provides guidelines for effective ontology capture.

Topics

Ontology

In IDEF5 the meaning of the term ontology is characterized to include a catalog of terms used in a domain, the rules governing how those terms can be combined to make valid statements about situations in that domain, and the “sanctioned inferences” that can be made when such statements are used in that domain. In every domain, there are phenomena that the humans in that domain discriminate as (conceptual or physical) objects, associations, and situations. Through various language mechanisms, one associates definite descriptors (e.g., names, noun phrases, etc.) to those phenomena.[1]

Central concepts of ontology

The construction of ontologies for human engineered systems is the focus of the IDEF5. In the context of such systems, the nature of ontological knowledge involves several modifications to the more traditional conception. The first of these modifications has to do with the notion of a kind. Historically, a kind is an objective category of objects that are bound together by a common nature, a set of properties shared by all and only the members of the kind.[1]

While there is an attempt to divide the world at its joints in the construction of enterprise ontologies, those divisions are not determined by the natures of things in the enterprise so much as the roles those things are to play in the enterprise from some perspective or other. Because those roles might be filled in any of a number of ways by objects that differ in various ways, and because legitimate perspectives on a domain can vary widely, it is too restrictive to require that the instances of each identifiable kind in an enterprise share a common nature, let alone that the properties constituting that nature be essential to their bearers. Consequently, enterprise ontologies require a more flexible notion of kind.[1]

Ontology development process

Ontology development requires extensive iterations, discussions, reviews, and introspection. Knowledge extraction is usually a discovery process and requires considerable introspection. It requires a process that incorporates both significant expert involvement as well as the dynamics of a group effort. Given the open-ended nature of ontological analyses, it is not prudent to adopt a “cookbook” approach to ontology development. In brief, the IDEF5 ontology development process consists of the following five activities:[1]

  1. Organizing and Scoping: This activity involves establishing the purpose, viewpoint, and context for the ontology development project and assigning roles to the team members.
  2. Data Collection: This activity involves acquiring the raw data needed for ontology development.
  3. Data Analysis: This activity involves analyzing the data to facilitate ontology extraction.
  4. Initial Ontology Development: This activity involves developing a preliminary ontology from the acquired data.
  5. Ontology Refinement and Validation: This activity involves refining and validating the ontology to complete the development process.

Although the above activities are listed sequentially, there is a significant amount of overlap and iteration between the activities.

Ontological analysis

Ontological analysis is accomplished by examining the vocabulary that is used to discuss the characteristic objects and processes that compose the domain, developing rigorous definitions of the basic terms in that vocabulary, and characterizing the logical connections among those terms. The product of this analysis, an ontology, is a domain vocabulary complete with a set of precise definitions, or axioms, that constrain the meanings of the terms sufficiently to enable consistent interpretation of the data that use that vocabulary.[3]

IDEF5 Building blocks

Definitions

Some of the key terms in IDEF5 and the basic IDEF5 Schematic Language Symbols, see figure.:[1]

Kind
Informally, a group of individuals that share some set of distinguished characteristics. More formally, kinds are properties typically expressed by common nouns such as ‘employee’, ‘machine’, and ‘lathe’.
Individual
The most logically basic kind of real world object. Prominent examples include human persons, concrete physical objects, and certain abstract objects such as programs. Unlike objects of higher logical orders such as properties and relations, individuals essentially are not multiply instantiable. Individuals are also known as first-order objects.
Referent
A construct in the IDEF5 elaboration language used to refer to a kind, object, property, relation, or process kind in another ontology or an IDEF model.
Relation
An abstract, general association or connection that holds between two or more objects. Like properties, relations are multiply instantiable. The objects among which a relation holds in a particular instance are known as its arguments.
State
A property, generally indicated by an adjective rather than a common noun, that is characteristic of objects of a certain kind at a certain point within a process. For example, water can be in frozen, liquid, or gaseous states.
Process
A real world event or state of affairs involving one or more individuals over some (possibly instantaneous) interval of time. Typically, a process involves some sort of change in the properties of one or more of the individuals within the process. Because of the ambiguity in the term “process”, sometimes referred to as process instance.

Diagram types

Various diagram types, or schematics, can be constructed in the IDEF5 Schematic Language. The purpose of these schematics, like that of any representation, is to represent information visually. Thus, semantic rules must be provided for interpreting every possible schematic. These rules are provided by outlining the rules for interpreting the most basic constructs of the language, then applying them recursively to more complex constructs. There are four primary schematic types derived from the basic IDEF5 Schematic Language which can be used to capture ontology information directly in a form that is intuitive to the domain expert.[3]

  • Classification Schematics : Classification schematics provide mechanisms for humans to organize knowledge into logical taxonomies. Of particular merit are two types of classification: description subsumption and natural kind classification.
  • Composition Schematics : Composition schematics serve as mechanisms to represent graphically the "part-of" relation that is so common among components of an ontology.
  • Relation Schematics : Relation schematics allow ontology developers to visualize and understand relations among kinds in a domain, and can also be used to capture and display relations between first-order relations.
  • Object State Schematics : Because there is no clean division between information about kinds and states and information about processes, the IDEF5 schematic language enables modelers to express fairly detailed object-centered process information (i.e., information about kinds of objects and the various states they can be in relative to certain processes). Diagrams built from these constructs are known as Object-State Schematics.
  • Classification Schematics
  • Composition Schematics
  • Relation Schematics
  • Object State Schematics
gollark: You mean "you need to cognitive-dissonance yourself into believing it 'tastes good'".
gollark: I know it's expected to consume alcohol a lot of the time. But you can just not.
gollark: I disagree.
gollark: Just don't?
gollark: SignNet™ is probably limited by the annoying nonmonospacedness of the MC font.

See also

References
  1. Perakath C. Benjamin et al. (1994). IDEF5 Method Report. Knowledge Based Systems, Inc.
  2. Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.176-178
  3. KBSI (2006). IDEF5 Overview at idef.com
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.