This shows you the differences between two versions of the page.
|
hekate:ardplus [2009/03/19 11:27] 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]]). | ||
| - | |||
| - | ==== History and Related Documents ==== | ||
| - | |||
| - | The original ARD method was first proposed by A. Ligęza in [[hekate:bib:hekate_bibliography#ali-book|(ali-book)]] and later on developed and described by G. J. Nalepa and A. Ligęza in [[hekate:bib:hekate_bibliography#gjn2005:kkio|(gjn2005:kkio)]], (ali-book-springer). | ||
| - | It was a supportive, and potentially optional, design method for XTT [[hekate:bib:hekate_bibliography#gjn2005:syssci:xtt|(gjn2005:syssci:xtt)]]. | ||
| - | It provided simple means of attribute identification for the XTT method. | ||
| - | |||
| - | The first version of ARD was applied to simple cases only, and had no practical prototype implementation. | ||
| - | The evolution of XTT, as well as larger complexity of systems designed with it, gave motivation for the major rework, and reformulation of ARD, which resulted in the version called ARD+. | ||
| - | ARD+ was defined by G. J. Nalepa and I. Wojnicki in [[hekate:bib:hekate_bibliography#gjn2008flairs-ardformal|(gjn2008flairs-ardformal)]] and [[hekate:bib:hekate_bibliography#gjn2008aaia|(gjn2008aaia)]]. | ||
| - | |||
| - | ===== Motivation ===== | ||
| - | |||
| - | The primary motivation for this research is an apparent lack of standard prototyping method for rules, | ||
| - | that would support the hierarchical and gradual design aspect covering the entire process. | ||
| - | Such a method should be formalized with use of some logic-based calculus in order to allow a formal analysis. | ||
| - | The research presented in this paper is a part of the //HeKatE// project, | ||
| - | that aims at providing an integrated and hierarchical | ||
| - | rule design and implementation method for rule-based systems. | ||
| - | The actual rule design is carried out with a flexible rule design method called XTT (eXtended Tabular Trees) [[hekate:bib:hekate_bibliography#gjn2005sysscixtt|(gjn2005sysscixtt)]]. | ||
| - | The method introduces a structured rulebase. | ||
| - | So one of the main requirements for the new prototyping method should be the support for XTT. | ||
| - | |||
| - | ===== ARD+ Method ===== | ||
| - | |||
| - | ==== Preliminary Concepts ==== | ||
| - | |||
| - | The ARD+ method aims at supporting the rule designer at a very general design level, where the conceptualization of the design takes place [[hekate:bib:hekate_bibliography#gjn2008flairs-ardformal|(gjn2008flairs-ardformal)]], [[hekate:bib:hekate_bibliography#gjn2008aaia|(gjn2008aaia)]]. | ||
| - | It is a knowledge-based approach, based on some classic AI methods (norvig). | ||
| - | ARD+ covers //requirements specification// stage. | ||
| - | Its //input// is a general systems description in the natural language. | ||
| - | Its //output// is a model capturing knowledge about relationships among attributes describing system properties. | ||
| - | The model is subsequently used in the next design stage, where the actual logical design with //rules// is carried out. | ||
| - | |||
| - | The main concepts behind ARD+ are: | ||
| - | * **attributive logic** based on the use of //attributes// for denoting certain properties in a system (ali-book-springer),[[hekate:bib:hekate_bibliography#ali2007flairs-granular|ali2007flairs-granular)]]. | ||
| - | * **functional dependency** is a general relation between two or more attributes (or attribute sets), called "dependent" and "independent"; the relation is such as in order to determine the values of the dependent attributes, the values of the independent ones are needed. | ||
| - | * **graph notation** provides simple, standard, yet expressive means for knowledge specification, and transformation. | ||
| - | * **visualization** is the key concept in the practical design support, provided by this method. | ||
| - | * **gradual refinement** is the main design approach, where the design is being specified in number of steps, each step being more detailed than the previous one. | ||
| - | * **structural transformations** are //formalized//, with well defined syntax and semantics. | ||
| - | * **hierarchical model** captures all of the subsequent design steps, with no semantic gaps; it holds knowledge about the system on the different abstraction levels [[hekate:bib:hekate_bibliography#gjn2007iwk|(gjn2007iwk)]]. | ||
| - | * **knowledge-based approach** provides means of the //declarative// model specification. | ||
| - | Based on these concepts, a formalization of the method is put forward in the following section. | ||
| - | |||
| - | ==== Syntax ==== | ||
| - | |||
| - | The ARD+ method aims at capturing relations between //attributes// in terms of //Attributive Logic// (AL)~\cite{ali-book-springer,ali2007flairs-granular,gjn2008ruleapps}. | ||
| - | It is based on the use of //attributes// for expressing knowledge about facts regarding world under consideration. | ||
| - | A typical atomic formula (fact) takes the form ''A(o) = d'', where ''A'' is an attribute, ''o'' is an object | ||
| - | and ''d'' is the current value of ''A'' for ''o''. | ||
| - | More complex descriptions take usually the form of conjunctions of such atoms and are omnipresent in the AI literature. | ||
| - | Please read the separate [[.:ardplus:ardplussyntax|ARD+ SYNTAX]] page for details. | ||
| - | |||
| - | ==== Transformations ==== | ||
| - | |||
| - | ==== Refactoring ==== | ||
| - | |||
| - | ==== Semantics ==== | ||
| - | |||
| - | ==== Hierarchical Model ==== | ||
| - | |||
| - | ===== Rule Prototyping Algorithm ===== | ||
| - | |||
| - | ===== Design Tool Prototype ===== | ||
| - | |||
| - | ===== SPOOL ===== | ||
