This shows you the differences between two versions of the page.
|
hekate:ardplus [2009/03/19 10:25] kinio |
hekate:ardplus [2019/06/27 15:49] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== The ARD+ Knowledge Representation ====== | ||
| - | **Author**: Grzegorz J. Nalepa and Igor Wojnicki | ||
| - | |||
| - | **Version**: Draft 2008Q3 | ||
| - | |||
| - | //ARD+// stands for //Attribute Relationship Diagrams//. | ||
| - | It is aimed to be as the final ARD version for the official HeKatE project (grant). | ||
| - | |||
| - | FIXME | ||
| - | |||
| - | ===== Introduction ===== | ||
| - | |||
| - | The basic goal of rule design is to build a rule-based knowledge base from system specification. | ||
| - | This process is a case of knowledge engineering (KE). | ||
| - | In general, the KE process is different in many aspects to the classic software engineering (SE) process. | ||
| - | The most important difference between SE and KE is that the former tries to model how the system works, while the latter tries to capture and represent what is known about the system. | ||
| - | The KE approach assumes that information about how the system works can be inferred automatically from what is known about the system. | ||
| - | |||
| - | In real life the **design** process support (as a process of building the design) is much more important than just providing means to visualize and construct the **design** (which is a kind of knowledge snapshot about the system). | ||
| - | Another observation can be also made: **designing** is in fact | ||
| - | a knowledge-based process, where the **design** is often | ||
| - | considered a structure with procedures needed to build it (it is at least | ||
| - | often the case in the SE). | ||
| - | |||
| - | In case of rules, the design stage usually consists in writing actual rules, based on knowledge provided by an expert. | ||
| - | The rules can be expressed in a natural language, this is often the case with informal approaches such as business rules. | ||
| - | However, it is worth pointing out that using some kind of formalization as early as possible in the design process improves design quality significantly. | ||
| - | |||
| - | The next stage is the rule implementation. | ||
| - | It is usually targeted at specific rule engine. | ||
| - | Some examples of such engines are: **CLIPS**, **Jess**, and **JBoss Rules** (formerly **Drools**). | ||
| - | The rule engine enforces a strict syntax on the rule language. | ||
| - | |||
| - | Another aspect of the design - in a very broad sense - is a rule encoding, in a machine readable format. | ||
| - | In most cases it uses an XML-based representation. | ||
| - | There are some well-established standards for rule markup languages:, e.g. **RuleML** and notably **RIF** (see [[http://www.w3.org/2005/rules]]). | ||
| - | |||
| - | The focus of this paper is the design stage, and the initial transition from user-provided specification (often in natural language) | ||
| - | that includes some **concepts**, to rule specification that connects rules with these **concepts**. | ||
| - | This stage is often referred to as a **conceptual design**. | ||
| - | It is also addressed with some recent representations, such as the **SBVR** | ||
| - | by the OMG and business rules communities. | ||
| - | |||
| - | ===== Motivation ===== | ||
| - | |||
| - | ===== ARD+ Method ===== | ||
| - | |||
| - | ==== Preliminary Concepts ==== | ||
| - | |||
| - | ==== Syntax ==== | ||
| - | |||
| - | ==== Transformations ==== | ||
| - | |||
| - | ==== Refactoring ==== | ||
| - | |||
| - | ==== Semantics ==== | ||
| - | |||
| - | ==== Hierarchical Model ==== | ||
| - | |||
| - | ===== Rule Prototyping Algorithm ===== | ||
| - | |||
| - | ===== Design Tool Prototype ===== | ||
| - | |||
| - | ===== SPOOL ===== | ||
