[[
✎ pl:miw:2009:piw09_hades_1:hekate_case_hello
]]
aiWiki
Pokaż stronę
Ostatnie zmiany
Indeks
Zaloguj
Ta strona jest tylko do odczytu. Możesz wyświetlić źródła tej strony ale nie możesz ich zmienić.
====== The HeKatE Case HELLO ====== Eliasz Kańtoch Tomasz Michalski This case analysis is based on hekate process. ====== Introduction ====== ====== Stages ====== The process is involves the following the stages described below. ===== Description ===== The aim of the system is to tell greetings based on the time of day and customer's attributes. ===== Conceptualization ===== In this stage some primary concepts are identified. These can be //attributes//, //properties//, //objects// (in the general sense), or //rules//. The output of this stage is a preliminary list of possible //attributes//, //properties//. The list //may be// somehow structured, or formalized. Though, it is not mandatory. ==== Vocabulary ==== *Greeting is a text that consists of salutation and title of the person. *Salutation is one of the following: Good Morning, Good Afternoon, Good Evening, Good Night. *Title of person is based on status of the person. *Status are age,martial status and gender. *Gender – male albo female *Martial status – married i single ==== Original Rules ==== In a case where an already designed system is being modeled, some ready rules can be provided. In the H approach these rules should be considered a mean of conceptualization only. These rules are often informal, or semi-formal. In the [[business rules]] approach number of rule types are identified, that do not map in a straightforward way to the H logical design. <code> Rule: 1 if the Hour is 'between 0 and 11' then Greeting is 'Good morning' Rule: 2 if the Hour is 'between 12 and 17' then Greeting is 'Good afternoon' Rule: 3 if the Hour is 'between 18 and 22' then Greeting is 'Good evening' Rule: 4 if the Hour is 'between 23 and 24' then Greeting is 'Good night' </code> ===== Conceptual design ===== The conceptual design stage is the beginning of the formalized hierarchical process. Based on the concepts, or vocabulary, the ARD properties and attributes are being identified, as well as functional dependencies between them stated. See the [[ARDplus]] design for the detailed specification. The output of this stage is the low-level [[ARDplus]] diagram with //physical attributes//, plus attribute domains, and types description. This output as a whole is [[:hekate:hekate_process#encoding|encoded]] with use of the [[HeKatE Markup Language]]. ==== General Conceptual Design ==== In a general case, the ARD diagram is built using the vocabulary previously identified. ==== Directed Conceptual Design ==== In a case where the [[hekate_process:original rules]] were provided, the physical attributes identified during the design should match the original rules. The lowest ARD level should match the structure of the original rule-base. ==== Refined Conceptual Design ==== This is also a case where the [[hekate_process:original rules]] were provided. However, the design is not aimed at matching the original rule-base. The goal is to improve the original design with the HeKatE approach. ===== Physical Attribute Specification ===== This is actually the partial output of the [[:hekate:hekate_process#conceptual design]] in a //standalone// form, that is only the appropriate [[:hekate:hekate_process#ATTML]] encoding. It is a natural input for the next stage. It is also a point, where the formalized [[attribute specification]] can be shared with other systems, tools and approaches. TBC: at this stage it should be possible to import attributes from other formalized sources, e.g. RIF-based systems. TBC: this should be compatible with the attributive logic concepts and definitions. ===== Structuralization ===== Using a partial output of the [[:hekate:hekate_process#conceptual design]] that is only the apropriate [[hekate markup language|ARDML]] dependencies. In this stage a fully or semi automated generation of the XTT table schemas (rule prototypes) is performed. Using the lowest ARD level XTT schemes are generated. The inference structure (table-to-table links) is also built which serve as a guideline for future XTT processing order. The algorithm is given in the //ECAI submission// FIXME. The //output// of this stages is the XTT schemes structure [[:hekate:hekate_process#encoding|encoded]] with the use of the [[XTTML]]. ===== Logical design ===== In this stage the actual design of the [[XTT]] tables is put forward. Tables are filled with rules, and extra, fine-grained links can be added (row-to-row) links. See the [[XTT]] design for the detailed specification. WIP: The application of the XTT+ a.k.a. GREP extensions should be considered here, with: * grouped attributes * scope operators Things that seem to be needed, in the final verision, but too complex now: * hybrid operators (HOP) Things considered to complex for the first implementation are: FIXME * labeled links * other GREP? The //output// of this stages is the full XTT structure [[:hekate:hekate_process#encoding|encoded]] with the use of the [[XTTML]]. ===== On-Line Analysis ===== In this stage the logical description of the XTT is used to conduct a formal analysis of selected formal properties such as: * completeness * redundancy -> knowledge optimization * determinism * inference -> inference optimization * other? WIP currently only some old experiences form the original XTT are available. TBC Several aspects, cases, classes, levels should be considered, e.g.: * local (table) vs. global (diagram) * relation to scope operators * relation to grouped attributes ===== Physical Design ===== The executable design generation. ==== Prolog Implementation ==== The XTT representation has a clear, well-defined Prolog representation. This representation is fully automatically generated from the XTT design. WIP currently only some old experiences form the original XTT are available. TBC Integration of BLOBS, data structures, lists, etc, has to be considered. So is the use and integration of the HOP. ==== UML Serialization ==== WIP An object-oriented serialization of the XTT is to be provided. It should match UML on the diagram level, and Java on the code level. WIP Current naive idea is to map * tables -> objects * attributes -> attributes * rules -> methods ==== Rule Engine Implementation ==== WIP Generate rules for some well-established rule engines, such as Drools. ====== Integration ====== The stages are integrated with: * knowledge encodings * transformations * other? FIXME This needs filling! ===== Encoding ===== Currently XML encodings to be used: * ATTML * ARDML * XTTML The are now integrated into //HML// the [[Hekate Markup Language]]. ===== Knowledge Markups ===== Aspects: * the stack: XML -> RDF -> RIF -> R2ML * ATTML <-> RDF * RIF <-> ARD * RIF <-> XTT * R2ML <-> XTT * ontologies <-> ATTML * ontologies <-> ARDML ===== Transformations ===== FIXME ====== Tools ====== Current tools: * VARDA * HQed ====== Case Template ====== <code> ====== Introduction ====== ===== Description ===== ===== Conceptualization ===== ==== Vocabulary ==== ==== Original Rules ==== ===== Analysis ===== ===== Conceptual design ===== ==== General Conceptual Design ==== ==== Directed Conceptual Design ==== === Full ARD Model === ==== Refined Conceptual Design ==== ===== Physical Attribute Specification ===== ===== Structuralization ===== ===== Logical design ===== </code>
pl/miw/2009/piw09_hades_1/hekate_case_hello.1244576351.txt.gz
· ostatnio zmienione: 2019/06/27 15:57 (edycja zewnętrzna)
Pokaż stronę
Poprzednie wersje
Menadżer multimediów
Do góry