--- pl:miw:2009:miw09_prolog_sbvr [2009/03/26 11:20]
jsi08
+++ pl:miw:2009:miw09_prolog_sbvr [2019/06/27 15:50] (aktualna)
@@ Linia 1: / Linia 1: @@
-====== Opis ======
+~~ODT~~
-Patryk Łuczyński , <tapirat@gmail.com> \\
+====== MIW 2009 Prolog_SBVR ======
-==== Prolog_SBVR ====
+**Zrealizował: [[tapirat@gmail.com|Patryk Łuczyński]] (4RI)
   * Look at the [[http://www.omg.org/spec/SBVR/|SBVR]].
   * Prepare a concise desc/present.
@@ Linia 8: / Linia 10: @@
   * provide simple analysis of the SBVR knowledge base on top of the parser
-====== Spotkania ======
-===== 200903126 ====
+====== Spotkania ======
-  * rulexpress, opis + sshot
+[[pl:miw:2009:miw09_prolog_sbvr:spotkania|Spotkania]]
-===== 20090312 ====
-  * czy ktos cos robil do SBVR w prologu?
-===== 20090225 ====
+====== Sprawozdanie ======
-  * nie pakujemy sie w modal logic
-====== Projekt ======
 ===== Opis SBVR =====
 ==== SBVR w architekturze MDA (Model Driven Architecture) ====
@@ Linia 57: / Linia 53: @@
   * Vocabulary for Describing Business Rules – zależne od Vocabulary for Describing Business Vocabularies więc i pośrednio od Meaning and Representation Vocabulary. Definiuje pojęcia potrzebne przy definiowaniu reguł biznesowych (np. reguła strukturalna, reguła operatywna).\\ \\
-{{:pl:miw:2009:miw09_prolog_sbvr:pliki:SBVR_voc_constr.gif?600|Metodyka definiowania nowych słowników i zestawów reguł w standardzie SBVR}}
-\\ Powyższy schemat przedstawia kolejne kroki definiowania nowego słownika i zestawu reguł. Sposób ten wynika bezpośrednio z zależności pomiędzy sześcioma słownikami zdefiniowanymi w oficjalnej specyfikacji SBVR. Terminologia użyta na schemacie zostanie omówiona przy okazji dyskusji nad SBVR Structured English. \\ \\
 Z punktu widzenia osoby pragnącej zdefiniować nowe słownictwo oraz reguły na nim oparte, najistotniejsze wydają się być 2 ostatnie słowniki. Przed ich opisaniem warto przedstawić ideę SBVR Structured English. Jest to pewien standard (definiujący różne czcionki do formalnego opisu elementów słownka, oraz wprowadzający nowe słowa kluczowe) opisywania słowników oraz reguł z wykorzystaniem Vocabulary for Describing Business Vocabularies oraz Vocabulary for Describing Business Rules. Jako ciekawostka, warto zaznaczyć, że w oficjalnej specyfikacji SBVR wszystkie sześć uprzednio wymienionych słowników zostało opatrzonych czionkami SBVR Structured English. Tworzy nam się więc pętla definicji, która oznacza, że SBVR (Structured English) jest własnym meta-językiem (jest językiem reflektywnym z czym wiążą się pewne problemy semantyczne jak wymaganie podstawowej wiedzy na temat języka – najbardziej znany problem to antynomia kłamcy. \\ \\
@@ Linia 74: / Linia 69: @@
 ====Reguły w SBVR====
-Za pomocą termór oraz wyrazów które opisuje się za pomocą czcionki 'verb' jesteśmy w stanie skonstruować koncept czasownikowy (verb concept). Takie konstrukcje pozwalają na opisywanie zależności pomiędzy wcześniej zdefiniowanymi pojęciami. Następnie w celu zdefiniowania reguły należy taki koncept czasownikowy obłożyć jednym z czterech dostępnych operatorów modalnych:
+Za pomocą termów oraz wyrazów które opisuje się za pomocą czcionki 'verb' jesteśmy w stanie skonstruować koncept czasownikowy (verb concept). Takie konstrukcje pozwalają na opisywanie zależności pomiędzy wcześniej zdefiniowanymi pojęciami. Następnie w celu zdefiniowania reguły należy taki koncept czasownikowy obłożyć jednym z czterech dostępnych operatorów modalnych:
  \\ \\
 Aletyczne (używane do tworzenia reguł strukturalnych):
@@ Linia 84: / Linia 79: @@
   * It is permitted that ... (Zezwala się by) oraz negacja (It is prohibited that... - Zabrania się by ...)
-Reguły strukturalne są prawdziwe z definicji. Są jakby aksjomatami całej działalności, opisują znaczenie i zależności elementów występujących w tych regułach(np. "Jest możliwe by zamówienie posiadało więcej niż jedną pozycję".). Tego rodzaju reguł nie zalicza się do reguł biznesowych. Do takich należą reguły operatywne (np. "Istnieje obowiązek by każde zamówienie zostało opłacone w ciągu 24 godzin"), które wyznaczają zasady zachowania w danych sytuacjach. Reguły takie mogą być łamane przez ludzi, dlatego wprowadza się pojęcia egzekwowania reguł (enforcement).
+Reguły strukturalne są prawdziwe z definicji. Są jakby aksjomatami całej działalności, opisują znaczenie i zależności elementów występujących w tych regułach(np. "Jest możliwe by zamówienie posiadało więcej niż jedną pozycję".). Tego rodzaju reguł nie zalicza się do reguł biznesowych. Do takich należą reguły operatywne (np. "Istnieje obowiązek by każde zamówienie zostało opłacone w ciągu 24 godzin"), które wyznaczają zasady zachowania w danych sytuacjach. Reguły takie mogą być łamane przez ludzi, dlatego wprowadza się pojęcia poziomu egzekwowania reguł (enforcement level).
 \\  \\
 Po dodaniu operatora modalnego należy dodać wszelkie konieczne kwantyfikatory jak np: każdy, co najmniej n, itp. \\
@@ Linia 91: / Linia 86: @@
-Parsowanie reguł (rozbiór logiczny): \\
-{{:pl:miw:2009:miw09_prolog_sbvr:pliki:sbvr_rule_parsing.gif}}
 Parsowanie reguł:
@@ Linia 98: / Linia 92: @@
 {{:pl:miw:2009:miw09_prolog_sbvr:pliki:sbvr_rule_parsing2.jpg}}
-CDN
 ===== Narzędzia zgodne z SBVR =====
@@ Linia 108: / Linia 103: @@
 Donald Chapin (OMG SBVR Project Leader) w swojej prezentacji wymienia jeszcze kilka programów, które opierają się na słownikach i regułach aczkolwiek żadne z nich nie jest zgodne z SBVR w takim stopniu co dwa powyższe.
+==== Narzędzia zgodne z SBVR na etapie tworzenia ====
+  * [[http://wiki.eclipse.org/MDT-SBVR_0.7_Project_Plan|MDT-SBVR]] - Model Development Tools obsługujące specyfikację SBVR
+  * [[http://sourceforge.net/projects/orm|NORMA]] - Natural ORM (Object Role Modelling) Architect for Visual Studio
+===== Parser =====
+===Pierwsze podejście===
+Specyfikacja SBVR nie wspomina ani słowem o regułach gramatycznych rządzących zapisem reguł. Wynika to z faktu, że SBVR (jak sama nazwa wskazuje) dotyczy semantyki czyli powiązania znaczenia z jego reprezentacją. Istotny jest również brak narzuconego zapisu reguł w specyfikacji SBVR (stawia ona na równi wszystkie możliwe formaty).
+\\
+[[https://ai.ia.agh.edu.pl/wiki/_media/pl:miw:2009:miw09_prolog_sbvr:pliki:parser.txt|KOD]]
+\\
+Powyższy kod był testowany na implementacji SWI Prolog (Windows). Realizuje on (oczywiście w minimalnym zakresie) rozbiór logiczny reguł, który opisany jest w specyfikacji SBVR w rodziale 9 (zwłaszcza 9.2). "Korzeniem" drzewa pokonywanego przy parsowaniu jest dla uproszczenia (zamiast "rule") nieterminal "Logical_formulation". Dla uproszczenia pominięty został rodział 8 "Meaning and Representation Vocabulary", który wprowadza powiązania między termami i faktami.
+===Specyfikacja SBVR pod kątem parsowania reguł===
-====== Sprawozdanie ======
+Jeżeli mówimy o parsowaniu SBVR to należy przyjąć parsowanie konkretnej notacji będącej zgodną ze [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf|specyfikacją SBVR]]. W tym wypadku przyjmujemy notację SBVR Structured English, która jest reprezentacją tekstową słowników oraz reguł. Jak więc wygląda tworzenie reguł?\\ \\
-====== Prezentacja ======
+{{:pl:miw:2009:miw09_prolog_sbvr:pliki:SBVR_voc_constr.gif?600|Metodyka definiowania nowych słowników i zestawów reguł w standardzie SBVR}}
-====== Materiały ======
+\\ Powyższy schemat przedstawia kolejne kroki definiowania nowego słownika i zestawu reguł. Sposób ten wynika bezpośrednio z zależności pomiędzy sześcioma słownikami zdefiniowanymi w oficjalnej specyfikacji SBVR. Pierwszym krokiem jest zdefiniowanie zbioru konceptów tzw. noun concepts([[http://pl.wikipedia.org/wiki/Poj%C4%99cie|"Pojęcie – abstrakcyjny, myślowy odpowiednik przedmiotu. Po zdefiniowaniu pojęcie staje się terminem." - Wikipedia]]) za pomocą termów (reprezentacji -  w tym wypadku tekstowych), który to zbiór będzie fundamentem do definiowania bardziej złożonych struktur. Kolejnymi elementami jakie należy zdefinować to fakty tzw. verb concepts definiujące zależności pomiędzy znaczeniami poszczególnych konceptów. Należy tu zaznaczyć rozdzielenie pomiędzy reprezentacją konceptu (termem) a jego znaczeniem. W specyfikacji SBVR zależnościom pomiędzy znaczeniami konceptów poświęcony jest [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf#page=31|podrozdział 8.1 Meaning (str 31)]].
+\\ \\
+Przykład [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf#page=295|EU-Rent Example (str 295)]]:
+\\
+branch type
+\\
+Definition: concept that specializes the concept ‘branch’ and that classifies a branch based on hours of operation and car storage capacity
+\\ \\
+airport branch
+\\
+Concept Type: branch type
+\\
+Definition: branch that has an EU-Rent location and has large car storage and has 24-7 operation
+\\
+Note: This kind of branch is usually at or near a major airport or rail terminal and has sufficient staff to have specialized roles in the workflow.
+\\
+Necessity: the concept ‘airport branch’ is included in Branches by Type.
+\\ \\
-==== Modal Logic ====
+Poza zdefiniowaniem samej reprezentacji tekstowej pojęć branch type oraz airport branch, określane są zależności pomiędzy nimi. Zależność jest reprezentowana linią tekstu: "Concept Type: branch type" przy wpisie airport branch. Napotykając w regule wpis airport branch wiadomo, że jest to instancją bardziej ogólnego konceptu branch type. Rodzaje zależności między konceptami są zdefiniowane w [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf#page=31|rozdziale 8.1.1 Concepts (str 31)]]. Te dwa rodzaje wpisów składają się na słownik dotyczący danej dziedziny.
+\\
+Parsowanie reguł (rozbiór logiczny): \\
+{{:pl:miw:2009:miw09_prolog_sbvr:pliki:sbvr_rule_parsing3.jpg}}
+\\
-□     It is necessary that ..\\
+Aby możliwe było przeparsowanie powyższej reguły nie wystarczy słownik zawierający wpisy termów : driver, rental, barred driver. Konieczna jest jeszcze definicja zależności pomiędzy konceptami driver oraz barred driver (prawdopodobnie przez dodanie linii "Concept Type: driver") mówiąca, że barred driver jest konceptem będącym podkategorią bardziej ogólnego konceptu driver. \\
-◊     It is possible that …\\ \\
+\\
- The most familiar logics in the modal family are constructed from a weak logic called K (after Saul Kripke). Under the narrow reading, modal logic concerns necessity and possibility. A variety of different systems may be developed for such logics using K as a foundation. The symbols of K include ‘~’ for ‘not’, ‘→’ for ‘if…then’, and ‘□’ for the modal operator ‘it is necessary that’. (The connectives ‘&’, ‘∨’, and ‘↔’ may be defined from ‘~’ and ‘→’ as is done in propositional logic.) K results from adding the following to the principles of propositional logic.
+Zależności definiowane są również przez fakty. Noun concepts występujące w fakcie zwane są rolami w fakcie i są uwzględniane podczas analizy logicznej sformułowań. O rodzajach sformułowań logicznych zawartych w wyrażeniach mówi [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf#page=61|rozdział 9.2 Logical formulations]]. Definiuje on również zależności logiczne pomiędzy sformułowaniami. W rodziale tym nie występuje żadna wzmianka o gramatyce zapisu tych sformułowań (wszak gramatyka może dotyczyć konkretnego zapisu a nie specyfikacji semantyki dopuszczającej różne zapisy - nawet w postaci diagramów).
+\\ \\
+Pewne namiastki gramatyki wprowadza [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf#page=249|rozdział opisujący notację SBVR Structured English (str 249)]], a zwłaszcza fragment przedstawiający  [[http://student.agh.edu.pl/~tapir/MIW/08-01-02.pdf#page=251|słowa kluczowe tej notacji (str 251)]].Znajdujemy tam wpisy typu "it is obligatory that p - obligation formulation". Niestety nie jest zdefiniowana "dolna"(dalsza od korzenia) część drzewa syntaktycznego w tym wypadku odzwierciedlona przez literę p, która ma reprezentować "expressions of propositions" czyli wyrażenie stwierdzenia. Przeszukując całą specyfikacją SBVR nie natrafiłem na reguły gramatyczne tworzenia takich właśnie wyrażeń. \\ \\
-    Necessitation Rule:   If A is a theorem of K, then so is □A.
+SBVR posiada dobrze zdefiniowane narzędzia do definiowania zależności semantycznych oraz zależności logicznych. Niestety brak tu gramatyki wymaganej do klasycznego parsowania przy użyciu drzewa syntaktycznego.
-    Distribution Axiom:  □(A→B) → (□A→□B).
+===Kolorowanie napisu na podstawie słownika (Prolog) ===
-(In these principles we use ‘A’ and ‘B’ as metavariables ranging over formulas of the language.) According to the Necessitation Rule, any theorem of logic is necessary. The Distribution Axiom says that if it is necessary that if A then B, then if necessarily A then necessarily B.
+[[https://ai.ia.agh.edu.pl/wiki/_media/pl:miw:2009:miw09_prolog_sbvr:pliki:koloruj.txt|KOD w Prologu]]
+\\ \\
+Powyższy kod był tworzony i sprawdzany za pomocą SWI Prolog (Windows). W celu kolorowania napisu należy skompilować powyższy plik i wprowadzić cel typu:
+\\ \\
+go([it,is,obligatory,that,a,rental,has,a,rental,period]).
+\\ \\
+Na wyjściu stworzony zostanie plik HTML z odpowiednio stylizowanym napisem wejściowym. UWAGA! Program wypisuje wyjście do pierwszego nierozpoznanego napisu lub przetworzenia całego napisu wejściowego.
+\\ \\
+[[http://student.agh.edu.pl/~tapir/MIW/output.html|Przykładowy plik wyjściowy]]
-The operator ◊ (for ‘possibly’) can be defined from □ by letting ◊A = ~□~A. In K, the operators □ and ◊ behave very much like the quantifiers ∀ (all) and ∃ (some). For example, the definition of ◊ from □ mirrors the equivalence of ∀xA with ~∃x~A in predicate logic. Furthermore, □(A&B) entails □A&□B and vice versa; while □A∨□B entails □(A∨B), but not vice versa. This reflects the patterns exhibited by the universal quantifier: ∀x(A&B) entails ∀xA&∀xB and vice versa, while ∀xA ∨ ∀xB entails ∀x(A ∨ B) but not vice versa. Similar parallels between ◊ and ∃ can be drawn. The basis for this correspondence between the modal operators and the quantifiers will emerge more clearly in the section on Possible Worlds Semantics.
-The system K is too weak to provide an adequate account of necessity. The following axiom is not provable in K, but it is clearly desirable.
+====== Prezentacja ======
+[[pl:miw:2009:miw09_prolog_sbvr:prezentacja|Prezentacja projektu]]
-    (M)  □A→A
-(M) claims that whatever is necessary is the case. Notice that (M) would be incorrect were □ to be read ‘it ought to be that’, or ‘it was the case that’. So the presence of axiom (M) distinguishes modal from other logics in the modal family. A basic modal logic M results from adding (M) to K. (Some authors call this system T.)
+====== Materiały ======
 ====Linki====
   *[[http://home.btconnect.com/BusinessSemantic/How_SBVR_Adds_Knowledge_Richness_to_ISO_TC_37_Terminology_Standards.pps]] - pokaz slajdów Donalda Chapina (Project Leader for SBVR) dobrze tłumaczący ideę SBVR
@@ Linia 166: / Linia 200: @@
   * [[http://c4i.gmu.edu/events/reviews/2008/papers/6_Loaiza.pdf]] -
   * [[http://www.eclipse.org/modeling/mdt/?project=sbvr#sbvr]]
+==Prolog parsing==
+  * [[http://www.csupomona.edu/~jrfisher/www/prolog_tutorial/contents.html#7]] - Prolog Natural Language Parsing
+  * [[http://www.dai.ed.ac.uk/groups/ssp/bookpages/quickprolog/quickprolog.html]] - Prolog DCG's
+  * [[http://www.im.pwr.wroc.pl/~przemko/prolog/m4s4.html]] - Prolog gramatyki
+  * [[http://www.oopweb.com/Prolog/Documents/prologbook/Volume/node101.html]]
+  * [[http://www.ling.helsinki.fi/kit/2004k/ctl272/Bangor/clbook_56.html]] - prolog DCG features

pl/miw/2009/miw09_prolog_sbvr.1238062837.txt.gz · ostatnio zmienione: 2019/06/27 15:57 (edycja zewnętrzna)

Pokaż stronę Poprzednie wersje

Menadżer multimediów Do góry

AIwiki

Menu

Dla Studentów

Old specialized AI courses

SMaDA/SMaIDA/AIDA

Informatyka (EAIiIB)

Studia Dr

Inne materialy dydaktyczne

Archiwum

Dyplomanci

Geist Season of Code

HeKatE

Public

Różnice