Ontologia jako narzę­dzie two­rze­nia mode­li świa­ta”, jest bar­dzo dobrym narzę­dziem do pro­jek­to­wa­nia danych, zor­ga­ni­zo­wa­nych – w łatwe do zarzą­dza­nia w bazach NoSQL – dokumenty. 

Wstęp

Niedawno napi­sa­łem:

Czy opra­co­wa­nie onto­lo­gii jest łatwe? Nie, nie jest. Czy zła onto­lo­gia szko­dzi? Tak, potra­fi dopro­wa­dzić do fia­ska pro­jek­tu informatycznego.

źr.;: Ontologia czy­li jak się to robi

Po co to wszyst­ko? Obecnie czę­sto mówi­my o Big Data, czy­li o maso­wo gro­ma­dzo­nych danych. Ich gro­ma­dze­nie wyma­ga opra­co­wa­nia struk­tu­ry ich gro­ma­dze­nia i zarzą­dza­nia nimi, bez tego powsta­nie stos nie­ska­ta­lo­go­wa­nych doku­men­tów”. Proces gro­ma­dze­nia danych jest strat­ny, więc dane te moż­na zgro­ma­dzić raz, prze­pi­sa­nie ich do nowej struk­tu­ry jest moż­li­we tyl­ko gdy nowa struk­tu­ra jest prost­sza (prze­pi­sy­wa­nie do iden­tycz­nej nie ma sen­su) więc każ­da migra­cja to utra­ta infor­ma­cji. Innymi sło­wy: archi­tekt danych, podob­nie jak saper, myli się tyl­ko raz. 

Ontologia

Przypomnijmy defi­ni­cję:

onto­lo­gia: lista pojęć i kate­go­rii z jakie­goś obsza­ru tema­tycz­ne­go, któ­ra poka­zu­je związ­ki mię­dzy nimi

Generalnie, zgod­nie z zasa­dą wyłą­czo­ne­go środ­ka, każ­de dwa poję­cia mozna połą­czyć w zda­nie albo gene­ra­li­za­cją albo pre­dy­ka­tem. Kolejna zasa­da: w popraw­nej onto­lo­gii, wsta­wie­nie w zda­niu, w miej­sce poję­cia, jego typu (spe­cja­li­za­cja), zacho­wu­je praw­dzi­wość tego zda­nia. Trzecia: zda­nie two­rzą tak­że jed­no poję­cie i pre­dy­kat. Przykłady odpowiednio:

  1. jeże­li ratler to rasa (typ) psa”
  2. a tak­że mały pies to tak­że pies”
  3. oraz pies szcze­ka na listonosza”
  4. więc ratler szcze­ka na listonosza”
  5. tak­że mały pies szcze­ka na listonosza”
  6. oraz pies szczeka”

Wszystkie powyż­sze zda­nia to zda­nia praw­dzi­we i sen­sow­ne w języ­ku pol­skim. Są to zda­nia praw­dzi­we w sen­sie tak sią (gene­ral­nie) dzie­je, że… „, są to fak­ty jeże­li zda­nie jest rela­cją. Patrz:

W The Philosophy of Logical Atomism Russell pisze: Jeśli mówię Pada”, to to, co ja mówię jest praw­dzi­we przy pew­nych warun­kach pogo­do­wych a jest fał­szy­we przy innych. Warunki pogo­do­we, któ­re czy­nią moje stwier­dze­nie praw­dzi­wym (lub fał­szy­wym w innym przy­pad­ku), są tym, co nazy­wam faktem”

Modelowanie

Wśród wie­lu zna­nych metod mode­lo­wa­nia onto­lo­gii jest OntoUML . Moim zda­niem ma pew­ne wady: auto­rzy wpro­wa­dza­ją poję­cie «event» mają­ce takie cechy jak począ­tek i koniec (war­to­ścią tych atry­bu­tów jest czas: time­stamp). Uważam, że stwa­rza to pewien pro­blem z kla­sy­fi­ka­cją tre­ści takie­go komu­ni­ka­tu. Po dru­gie, jeże­li uzna­my, że prze­strze­ga­my zasa­dy nie lubi­my pustych pól” (bazy danych nie zawie­ra­ją pól/atrybutów bez war­to­ści) to «event» łamie tę zasa­dę, bo war­tość zade­kla­ro­wa­ne­go pola end event” będzie pusta do momen­ty zakoń­cze­nia zda­rze­nia”. Jednym z cie­kaw­szych podejść do onto­lo­gii, jej mode­lo­wa­nie i inte­gra­cją z mode­la­mi sys­te­mów (MDA, SysML, UML) opi­sa­li w swo­jej pra­cy Devedzic i inni z cze­go tak­że tu korzystam. 

W publi­ka­cji na temat kla­sy­fi­ka­cji i jed­no­znacz­no­ści opi­su opi­sy­wa­łem meto­dę dzie­le­nia infor­ma­cji wg. kon­tek­stu, jakim jest skla­sy­fi­ko­wa­nie tre­ści jako opi­su obiek­tu (ten trwa w cza­sie) oraz fak­tu (nie trwa w cza­sie). Zdanie Dom ma czte­ry okna i czer­wo­ny dach” jest praw­dzi­we mimo upły­wu cza­su, zawsze będzie wypo­wia­da­ne w cza­sie teraź­niej­szym. Zdanie w Dom ude­rzył pio­run” jest praw­dzi­we ale zawsze będzie wypo­wia­da­ne w cza­sie prze­szłym. Obiekty trwa­ją w cza­sie, ich stan może się zmie­niać: Po prze­ma­lo­wa­niu (fakt) dom ma zie­lo­ny dach” (i to trwa). Wszystko to co trwa w cza­sie, jest ogra­ni­cza­ne fak­ta­mi, w szcze­gól­no­ści fakt powsta­nia rze­czy (obiek­tu) i fakt jego znisz­cze­nia”, w mię­dzy­cza­sie mogą mieć miej­sce fak­ty zmie­nia­ją­ce stan rze­czy (obiek­tu, np. zmia­na koloru). 

Generalizując: obiek­ty trwa­ją w cza­sie zaś fak­ty nie. Początek i koniec trwa­nia obiek­tu to dwa klu­czo­we fak­ty z jego życia” (cykl życia obiek­tu) a nie event” mają­cy począ­tek i koniec. W życiu” obiek­tu mogą wystą­pić inne fak­ty. Cechy obiek­tu to jego wła­sno­ści (kolor, waga i wie­le innych itp.), cecha­mi fak­tów są moment w cza­sie (time stamp) oraz to jakie­go obiek­tu (obiek­tów) dotyczyły.

Ontologia (SBVR, dia­gram faktów)

W sys­te­mach infor­ma­cyj­nych mamy do czy­nie­nia z gro­ma­dze­niem wie­dzy o świe­cie oraz z gro­ma­dze­niem spra­woz­dań. Powyżej onto­lo­gia czy­li poję­cio­wy model wycin­ka świa­ta. Zdanie pies szcze­ka na listo­no­sza” a tak­że pies szcze­ka” to ogól­na wie­dza o psach. Zdanie listo­nosz boi się psa” to ogól­na wie­dza o listo­no­szach. Sprawozdaniem było by tu zda­nie: mały pies, pudel, szcze­kał na listo­no­sza od godzo­ny 16:16 do godzi­ny 16:18” (moż­na by jesz­cze podać adres). 

Ontologia, jako języ­ko­wy opis świa­ta, to meta­mo­del zdań opi­su­ją­cych pew­ną kla­sę obiek­tów i zda­rzeń. Sprawozdanie mówią­ce, że kon­kret­ny pies, w okre­ślo­nym okre­sie cza­su, szcze­kał na kon­kret­ne­go listo­no­sza (w kon­kret­nym miej­scu) to taka wła­śnie instan­cja (wystą­pie­nie).

Projektowanie architektury danych

Jaką archi­tek­tu­rę powi­nien mieć doku­ment” będą­cy tre­ścią tego sprawozdania? 

Poniżej trzy eta­py analizy.

Modele wie­dzy opar­te na onto­lo­gii (dia­gra­my klas, UML, opra­co­wa­nie wła­sne autora).

Ogólnie moż­na powie­dzieć, że pre­dy­ka­ty (fak­ty zda­nio­twór­cze) doty­czą obiek­tów: zbie­ra­my infor­ma­cje (wie­dzę) o tym, kie­dy pies szcze­kał na ludzi, jaki pies i na jakich ludzi szcze­kał. To rysu­nek a. powy­żej, może­my go nazwać kon­cep­cją. Zapisanie takiej infor­ma­cji wyma­ga zapro­jek­to­wa­nia trzech repo­zy­to­riów: pies, czło­wiek, pre­dy­kat. Powiązanie psa z czło­wie­kiem jest zapi­sa­ne jako atry­bu­ty pre­dy­ka­tu (rys. b.). To pro­jekt archi­tek­tu­ry danych i logi­ki ich wią­za­nia. Bardziej uni­wer­sal­ny model poka­za­no na rys. c., wyma­gał by on uzu­peł­nie­nia bazą sza­blo­nów obiek­tów” (struk­tu­ry agre­ga­tów opi­su­ja­cych róż­ne typy obiek­tów) z uwa­gi na to, że róż­ne obiek­ty mogą mieć róż­ne cechy. Tu poka­za­no je w uprosz­cze­niu jako atry­bu­ty, jed­nak real­ny pro­jekt dzie­dzi­no­wy były już bar­dziej pre­cy­zyj­ny i rozbudowany. 

Powyższe moż­na zapi­sać w bazie NoSQL, w w bazie gra­fo­wej obiek­ty były by węzła­mi a pre­dy­ka­ty kra­wę­dzia­mi. Detale obiek­tów mogą być agre­ga­ta­mi w bazie dokumentowej. 

Rola ontologii w projektach 

Kluczową rolą i celem two­rze­nia onto­lo­gii jest wspól­ny słow­nik i zro­zu­mie­nie pojęć. Ontologia peł­ni rolę cen­tral­nej współ­dzie­lo­nej prze­strze­ni poję­cio­wej (name­spa­ce) i wie­dzy dzie­dzi­no­wej (np. regu­ły biz­ne­so­we). Wszystkie sys­te­my w orga­ni­za­cji (bar­dzo czę­sto od róż­nych pro­du­cen­tów) mają – każ­dy swój – wewnętrz­ny i lokal­nie spój­ny sys­tem poję­cio­wy (name­spa­ce). Jakakolwiek ich inte­gra­cja (wymia­na komu­ni­ka­tów mię­dzy sys­te­ma­mi) wyma­ga mapo­wa­nia syno­ni­mów w komu­ni­ka­tach (nazwy pój, ich war­to­ści, robi to adap­ter, bar­dzo czę­sto jest to imple­men­to­wa­ne jako szy­na inte­gra­cyj­na ESB):.

Zarządzanie sys­te­mem pojęć

Podsumowanie

Uważam, że onto­lo­gie nie wyma­ga­ją skom­pli­ko­wa­nych meta­mo­de­li takich jak ww. OntoUML czy bar­dziej skom­pli­ko­wa­nych, opar­tych na roz­bu­do­wa­nych tak­so­no­miach i mode­lu UFO .

Gromadzenie wie­dzy to albo wie­dza gene­ral­na” opi­su­ją­ca świat (wła­ści­wa onto­lo­gia) albo spra­woz­da­nia (opi­sy), dla któ­rych onto­lo­gia jest meta­mo­de­lem (onto­lo­gia tu, to meta­da­ne spra­woz­dań). Tak więc może­my powie­dzieć, że gro­ma­dze­nie wie­dzy wyma­ga dzie­dzi­no­we­go (spe­cy­ficz­ne­go dla dzie­dzi­ny) mode­lu poję­cio­we­go: onto­lo­gii. Na tej pod­sta­wie moż­na zbu­do­wać model struk­tu­ry danych. Pokazano, że obec­nie naj­bar­dziej ade­kwat­ny do opi­sów był­by model doku­men­to­wy, gdyż opi­sy obiek­tów będą skom­pli­ko­wa­ny­mi agre­ga­ta­mi o zmie­nia­ją­cej się w cza­sie struk­tu­rze, zależ­nej od typu obiek­tu, ale też odwzo­ro­wu­ją­cej wie­dzę o nim. Predykaty są znacz­nie prost­sze i prze­cho­wy­wa­nie ich w posta­ci samych pro­stych meta­da­nych wyda­je się wystar­cza­ją­ce. Całość two­rzy sieć, w któ­rej węzły są obiek­ta­mi a kra­wę­dzie faktami. 

Biorąc pod uwa­gę ogrom­ne ilo­ści zbie­ra­nych danych oraz to, że nie moż­na sie pomy­lić”, mode­le SQL/RDBMS, z ich sztyw­no­ścią i bra­kiem redun­dan­cji, wyda­ją się nie­ade­kwat­ne. Ontologie jako wie­dza o isto­cie świa­ta (np. w sys­te­mach sztucz­nej inte­li­gen­cji) bar­dzo dobrze pasu­ją do baz gra­fo­wych. Ogromne ilo­ści danych spra­woz­daw­czych dosko­na­le pasu­ją do baz doku­men­to­wych. Wyzwaniem w pro­jek­tach tego typu jest zbu­do­wa­nie dzie­dzi­no­wej onto­lo­gii, a potem zapro­jek­to­wa­nie agre­ga­tów (doku­men­tów) prze­cho­wu­ją­cych dane spra­woz­daw­cze. Przykładem takich agre­ga­tów są np. opi­sy zmie­nia­ją­cych się pro­duk­tów jako obiek­tów oraz fak­tu­ry jako fak­ty doko­na­nia trans­ak­cji ich sprze­da­ży (co, kto komu, za ile, kie­dy). Zdanie Jan sprze­dał Krzysztofowi rower” to wie­dza o tym, że pewien fakt (moment doko­na­nia trans­ak­cji) połą­czył trzy obiek­ty: sprze­daw­cę, nabyw­cę, sprze­da­ny produkt.

Dalsze prace

Dalsze pra­ce pro­wa­dzo­ne są w kie­run­ku stwo­rze­nia ogól­nej uni­wer­sal­nej meto­dy ana­li­zy i pro­jek­to­wa­nia sys­te­mów zarzą­dza­nia infor­ma­cją na bazie onto­lo­gii i struk­tur doku­men­to­wych i wdra­ża­nie ich w sys­te­mach zarza­dza­nia infor­ma­cją zarów­no ERP jak AI. 

Dodatek

Pojęcia kla­sy obiek­tów, kla­sy­fi­ka­to­ra, war­to­ści a tak­że poję­cia repre­zen­tu­ją­ce­go obiek­ty, któ­re mogę repre­zen­to­wać war­tość cze­go to zbio­ry, defi­ni­cje ele­men­tów i ele­men­ty. Z ele­men­tów zbio­ru, za pomo­cą pre­dy­ka­tów, mozna budo­wać zda­nia praw­dzi­we” czy­li opi­sy. Poniżej cie­ka­wa pre­zen­ta­cja o teo­rii zbio­rów i rachun­ku pre­dy­ka­tów. Bardzo waż­na dla zro­zu­mie­nia tego czym tak na praw­de jest ana­li­za pojęciowa. 

Źródła

Batista, J. O., Almeida, J. P. A., Zambon, E., & Guizzardi, G. (2022). Ontologically cor­rect taxo­no­mies by con­struc­tion. Data & Knowledge Engineering, 139, 102012. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​d​a​t​a​k​.​2​0​2​2​.​1​0​2​012
Gaševic, D., Djuric, D., & Devedžic, V. (2009). The Ontology UML Profile. In V. Deved¿ic, D. Djuric, & D. Ga¿evic, Model Driven Engineering and Ontology Development (pp. 235 – 243). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 00282-3_9
Gašević, D., Djurić, D., Devedzic, V., & Gašević, D. (2009). Model dri­ven engi­ne­ering and onto­lo­gy deve­lop­ment (2nd ed). Springer.
Guizzardi, G., Fonseca, C. M., Benevides, A. B., Almeida, J. P. A., Porello, D., & Sales, T. P. (2018). Endurant Types in Ontology-Driven Conceptual Modeling: Towards OntoUML 2.0. In J. C. Trujillo, K. C. Davis, X. Du, Z. Li, T. W. Ling, G. Li, & M. L. Lee (Eds.), Conceptual Modeling (Vol. 11157, pp. 136 – 150). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑030 – 00847-5_12
João, P., Almeida, J., Falbo, R., & Guizzardi, G. (2019). Events as Entities in Ontology-Driven Conceptual Modeling.
Kaczmarek, J. (2009). Ontologia sądów i sta­nów rze­czy. Aporie Ontologii Sytuacji, 201 – 232. https://www.academia.edu/35242987/Ontologia_s%C4%85d%C3%B3w_i_stan%C3%B3w_rzeczy

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 4 komentarzy

  1. Anna

    czy man może być zarów­no typu post­man i neigh­bo­ur, ogól­niej czy w mode­lu fak­tów spe­cy­fi­ka­cje typów muszą się wykluczać?

    1. Jarosław Żeliński

      Generalnie poję­cia ozna­cza­ją «coś», roz­róż­nia­nie «tych rze­czy» wyma­ga defi­ni­cji, a te muszę się wza­jem­nie wyklu­czać by to roz­róż­nie­nie było moż­li­we. Problem «post­man i neigh­bo­ur» poja­wia się zawsze, gdy ktoś pró­bu­je sto­so­wać «pro­ste dzie­dzi­cze­nie» jako model taksonomii. 

      «Postmen» to zawód, «neigh­bo­ur» to nazwa for­my rela­cji z oto­cze­niem, a to zna­czy, że są to dwie tak­so­no­mie. Jest to dokład­nie ten sam pro­blem co kla­sy­fi­ka­cja zwie­rząt w arty­ku­le o sys­te­mie dla wete­ry­na­rza: czło­wiek jest jed­no­cze­śnie «Postmen» i «neigh­bo­ur» bo są to odręb­ne kla­sy­fi­ka­cje (w UML i SBVR to się nazy­wa «gene­ra­li­sa­tion set», spec. UML, 9.7 Generalization Sets). Na dia­gra­mie powy­żej: «pies» jest jed­no­cze­nie i «ter­rier» i «lar­ge».

      To jest coś (jed­no poję­cie i jego kil­ka tak­so­no­mii), cze­go nie da się odwzo­ro­wać wprost w bazie relacyjnej.

    2. Jarosław Żeliński

      P.S. dru­ga uwa­ga: w tym przy­kła­dzie «post­man» i neigh­bo­ur» się wyklu­cza­ją, bo w «dome­nie» tego opi­su (kon­tekst) listo­nosz i sąsiad to osob­ne oso­by (w dzie­dzi­nie «na kogo szcze­ka pies» sąsiad i «listo­nosz» są inny­mi ludź­mi). To, że sąsiad może wyko­ny­wać zawód listo­no­sza to praw­da, ale w inny­mi kon­tek­ście. Tu powie­my, że pies szcze­ka i na listo­no­szy i na sąsiadów”. 

      Bardzo łatwo to osią­gnąć w doku­men­to­wych sys­te­mach zarzą­dza­nia dany­mi, bo gra­ni­ca doku­men­tu (trak­to­wa­ne­go jako agre­gat) sepa­ru­je kon­tek­sty danych jakie są w nich zawar­te. W mode­lu rela­cyj­nym jest to nie do uzy­ska­nia co powo­du­je, że pew­ne funk­cjo­nal­no­ści sys­te­mów opar­tych na jed­nej rela­cyj­nej bazie są po pro­stu nie moż­li­we do uzy­ska­nia [https://​mar​tin​fow​ler​.com/​b​l​i​k​i​/​B​o​u​n​d​e​d​C​o​n​t​e​x​t​.​h​tml].

      Tu inny ład­ny opis:
      https://​youtu​.be/​z​l​F​q​j​D​2​L​KlE

  2. Rachunek pre­dy­ka­tów czy rachu­nek zdań to mate­riał wykra­cza­ją­cy poza ten arty­kuł, jed­nak w kwe­stii budo­wa­nia mode­li poję­cio­wych poję­cie pre­dy­ka­tu jako związ­ku zda­nio­twór­cze­go wystar­czy. Predykat to ele­ment aczácy dwa rze­czow­ni­ki (naj­czéciej cza­sow­nik), np.: sowa pies i listo­nosz to rze­czow­ni­ki (a kon­kret­nie poję­cia będą­ce nazwą cze­goś). Aby powstał praw­dzi­we zda­nie (mają­ce sens) potrze­bu­je­my ele­men­ty łączą­ce­go zwa­ne­go pre­dy­ka­tem: pies «szcze­ka na» listonosza.

    Więcej tu:
    Witold Marciszewski. (2003). Rachunek Predykatów słow­nik, skład­nia i seman­ty­ka. LOGIKA, 2002/2003. https://www.calculemus.org/lect/L‑I-MNS/03/lim03.pdf

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.