MOKA: Knowledge Engineering Methodology

• MOKA methodology is a structured approach that captures and formalizes domain-specific know-how using a clearly defined set of ICARE forms.
• It employs a dual staged process—transitioning from informal knowledge capture to formal model construction—to ensure semantic fidelity and traceability.
• Practical applications include design and manufacturing (e.g., aircraft process planning), though its focus is limited to the capture and formalization phases of KBE.

MOKA Methodology

MOKA (Methodology and tools Oriented to Knowledge-based engineering Applications) is a structured knowledge engineering methodology devised for the capture, structuring, and formalization of domain-specific know-how, primarily within knowledge-based engineering (KBE) systems deployed in design and manufacturing environments. Its principal objective is to enable the scalable, traceable, and semantically-rigorous integration of expert knowledge into computer-aided design (CAD), computer-aided manufacturing (CAM), and product lifecycle management (PLM) platforms. The MOKA framework emphasizes ontology-driven modeling, staged capture and formalization, and collaborative knowledge capitalization cycles among heterogeneous stakeholders (Perry et al., 2012, 0712.1994).

1. Foundational Principles and Lifecycle Position

MOKA was developed to address the bottlenecks in eliciting tacit and explicit engineering expertise and in translating heterogeneous, often informal knowledge sources into implementable models for automated systems. It addresses two main phases of the KBE development lifecycle—Capture and Formalize—within a broader six-phase KBE workflow: Identify, Justify, Capture, Formalize, Package, Activate (0712.1994):

KBE Phase	MOKA Coverage	Typical Activities
Identify	Not addressed by core MOKA	Scope domain, define coverage
Justify	Not addressed by core MOKA	Economic/technical feasibility assessment
Capture	Fully addressed	Knowledge elicitation, ICARE sheet fabrication
Formalize	Fully addressed	Formal model construction, code/schema generation
Package	Not addressed by core MOKA	System assembly, documentation
Activate	Not addressed by core MOKA	Roll-out, training, maintenance

MOKA's tight focus on knowledge capture and formal representation, while highly effective for engineering contexts, constrains its applicability to organization-wide knowledge scenarios or business process improvement tasks where upstream scoping and downstream deployment phases are critical (0712.1994).

2. Ontology Structure: The ICARE Object Model

At the methodological core of MOKA is an ontology based on a limited—yet highly expressive—set of five primary object types, collectively known as ICARE forms (Perry et al., 2012, 0712.1994):

• Entity: Models product geometry, parts, or logical groupings (e.g., "Bracket," "Hole").
• Constraint: Captures design or resource limitations (e.g., tool diameter, material limits).
• Activity: Encodes process steps or decision nodes (e.g., "Select machining strategy").
• Rule: Implements domain heuristics and conditional logic, typically in "IF–THEN" format.
• Illustration: Provides supporting examples, past cases, diagrams, or supplementary explanations.

Each ICARE form instantiates attributes (e.g., for Entity: geometric parameters, material), along with standardized relations (e.g., Entity hasConstraint, Activity usesResource). The ontology is designed for human validation and downstream mapping to formal schemas.

Formally, the informal ICARE repository is structured as:

$M_I = \{ E, C, A, R, I \}$

Where $E$ = Entities, $C$ = Constraints, $A$ = Activities, $R$ = Rules, $I$ = Illustrations.

3. Staged Knowledge Capitalization Process

MOKA formalizes a two-level knowledge modeling strategy (Perry et al., 2012):

1. Informal Level (Capture):

• Knowledge is coded in near-natural language, filling ICARE sheets through expert interviews, document mining, or workshops.
• The informal model serves as a communication bridge among domain experts, engineers, and software specialists.
• Early-stage consistency and semantic completeness are validated via discussion and class/activity diagrams.

2. Formal Level (Formalize):

• Informal ICARE forms are systematically translated into executable representations, such as XML-encoded schemas, UML diagrams, or rule-base languages.
• Mapping and consistency checking between informal and formal models are performed to ensure computability, unambiguity, and semantic fidelity.
• The mapping is denoted as:

$\varphi: M_I \rightarrow M_F$

where $M_F$ is the formal model.

This staged process is further refined into two sub-phases in some enrichments:

• Capture/Elicitation/Structuring: Content-focused, culminating in trees and diagrams.
• Formalization: Form-focused, resulting in implementation artifacts (Perry et al., 2012).

4. Ontology Enrichment and the ICARREF Extension

In application contexts such as process planning or manufacturing, vanilla ICARE is insufficient to represent domain idiosyncrasies. The USIQUICK project introduced an enriched ICARREF ontology with extended types (Perry et al., 2012):

Object Type	Description	Relation Examples
Resource	Physical tooling, machines, or fixtures	Activity usesResource; Entity isProcessedBy
Function	Intent of an activity (e.g., "optimize cycle time")	Activity hasFunction
Expert_Rule	Individual- or org-specific heuristics	Activity hasExpertRule
Domain_Rule	Consensus constraints valid across the domain	Activity hasDomainRule
Product_Constraint	Physical or design-imposed limitations	Entity hasProductConstraint
Representation_Constraint	Visualization or knowledge presentation rule	Entity hasRepresentationConstraint

This enriched object model enables the precise specification of not only "what" is to be known (content) but also "how" it is to be used and represented (form and context). Additionally, knowledge objects carry a "State" attribute (e.g., implemented, in_progress, dismissed) for traceability and coverage assessment.

5. Formalization Artifacts and Representational Approaches

While the core MOKA methodology is not reliant on mathematical formalisms, it operationalizes knowledge integration through a suite of graphical and tabular artifacts (Perry et al., 2012, 0712.1994):

• UML/ICARE class diagrams (entities, attributes, associations)
• Activity/sequence diagrams (control and data flow)
• Concept maps (ontology relationships, ICARREF enrichment)
• Tabular exports (Excel/XML field mapping for implementation)

The formalization phase typically involves mapping the informal ICARE/ICARREF knowledge base into a domain-specific object-oriented data schema, rule engine, or process-automation codebase. No formal transformation or automated consistency checking is included in baseline MOKA—translation and validation remain manual.

6. Practical Applications and Case Studies

MOKA and its enrichments have been extensively deployed in engineering-intensive, collaborative environments:

• Aircraft Manufacturing Process Planning (USIQUICK Project):
  • Supported modules: feature recognition, process plan generation, and optimization.
  • Knowledge flow: entity decomposition → rule/constraint mapping → activity/function/resource assignment.
  • Example: Each 3D CAD face is linked to applicable domain and expert rules, with visualization overlays aiding user inspection and validation.
  • All contributing stakeholders utilize and update a shared knowledge repository with traceability for each object’s life-cycle status.

Impact and Observations:

• Garnering explicit separation of knowledge content and form enables parallel, modular system construction and rapid coverage assessment.
• Ontology enrichment increases modeling expressiveness, especially for process-centric domains.
• Empirical evidence (e.g., visual rule overlays, coverage monitoring) demonstrates improved collaboration and traceability in multidisciplinary teams (Perry et al., 2012).

7. Limitations, Comparative Context, and Adoption Issues

Despite its strengths in knowledge structuring and formalization, MOKA is limited by:

• Insufficient scope for full KBE lifecycle (scoping, deployment, maintenance phases unaddressed).
• Lack of automated consistency or completeness checking, which imposes validation burden on knowledge engineers.
• Manual translation from informal to formal representations.
• The initial learning curve required for ontology extension in new domains (Perry et al., 2012, 0712.1994).

In comparative studies, SPEDE and CommonKADS offer broader KBE lifecycle coverage, with CommonKADS being favored in contexts involving distributed, inter-organizational knowledge or cross-functional process mapping. MOKA’s engineering-centric focus is best suited for design-manufacturing integration, rather than multi-firm or policy-level knowledge engineering (0712.1994).

---

References

• "A Knowledge Engineering Method for New Product Development" (Perry et al., 2012)
• "Knowledge Engineering Technique for Cluster Development" (0712.1994)