MathTextOntology-pasek

    Wyobraźmy sobie klasyczną, relacyjną bazę danych. Załóżmy że zawiera ona informacje o produktach kilku firm. Relacyjna baza danych zawierająca tego typu informacje będzie zapewne zawierać kilka tabel – tabele z informacjami o nazwach produktów, o firmach które je wyprodukowały, o cenach, rozmiarach czy dostępności towaru. Każda asocjacja, czy zbiór dotyczący jakiejś cechy będzie musiał odwoływać się do pewnego unikalnego numeru – klucza – pozwalającego powiązać własność opisywaną przez tą asocjację z konkretnym produktem. Tego typu informacje przechowuje sie w tabelach relacyjnej bazy danych i na przykład tabela „kolor” może zawierać kolumny „IDProduktu” i „IDKoloru”. Tego typu związek – pomiędzy IDProduktu i jego kolorem nazywamy relacją. Relacje mogą być oczywiście bardziej złożone, wszakże idea jest ta sama – tabela to relacja – czyli – związek – pomiędzy pewną własnością ( kolor) a jakimś identyfikatorem mówiącym w sposób jednoznaczny czego owa własność dotyczy. Oczywiście konstrukcja złożonej bazy danych zawierającej wiele rozmaitych relacji może być bardzo złożona, zaś wymogi jej bezpiecznej i wydajnej eksploatacji sprawiają że organizacja danych w tabelach bynajmniej nie jest prosta. Proces uzyskiwania optymalnej struktury tabel dla zadanego zbioru relacji nazywa się normalizacją. Relacyjne bazy danych spełniają rozmaite wymogi dotyczące w szczególności wydajności uzyskiwania informacji i bezpieczeństwa danych. Wszakże należy być świadomym, ze dodawanie nowych informacji w takiej bazie jest złożonym zagadnieniem. Po pierwsze nowe relacje wymagają nowych tabel. Po drugie nowe tabele wymagają znajomości organizacji pozostałych danych bowiem powiązanie nowych informacji ze starymi wymaga budowania lub uzupełniania słowników spinających nowe cechy ze starymi identyfikatorami. Na koniec relacyjne bazy danych optymalizowane sa dla odpowiadania na zapytania w języku algebry zbiorów – za pomocą języka SQL. Podejście takie świetnie sprawdza się w wypadku centralnie zarządzanych systemów w których stosowne służby dbają o poprawność danych w bazie.

    W poprzednim wpisie pisałem o instalacji hybrydowego serwera baz danych Virtuoso. Pora wyjaśnić co znaczy słowo hybrydowy. Ma ono w tym wypadku wiele znaczeń, obejmuje możliwość przechowywania w motorze Virtuoso danych w wielu modelach w tym relacyjnym i obiektowym. Właśnie to ostatnie znaczenie nas interesuje. Obiekty w tym kontekście, nieco podobne do tych znanych z programowania obiektowego, to struktury danych budowane przez „opisywanie własności”. Obiekt „krzesło” ma rozmaite części składowe i cechy: „nogi”, „oparcie’, „ciężar”, „kolor”, „model”, „materiał” i wiele innych cech. Niektóre z tych cech są właściwe tylko dla mebli do siedzenia ( „oparcie”) a inne są wspólne z wieloma innymi obiektami („kolor” i „ciężar” możemy przypisać bardzo wielu przedmiotom). Konstruując obiektowa bazę danych musimy zbudować model obiektów o których będziemy gromadzić dane, taki „model rzeczy” o których mówimy. Model taki musi zawierać zarówno charakterystykę cech obiektów, jak i może zawierać informacje o wzajemnych powiązaniach pomiędzy „rzeczami”. Na przykład możemy budować model danych wychodząc od jakiegoś ogólnego i elementarnego obiektu ( „Rzecz”) i wypisać pewne generyczne cechy ( „kolor”, „waga”, „materiał” ) a następnie precyzować model podając bardziej szczegółowe rodzaje obiektów: „Rzecz” zwana „mebel” ma dodatkowe cechy – „producent”, „sposób użycia”, „cena”, „pomieszczenie”. Mebel do siedzenia to „krzesło” i kolejne konkretne cechy . Konstruowanie tego typu modelu określa sie terminem budowania ontologii.

    Ontologie to forma opisu relacji jakie zachodzą pomiędzy obiektami, o których informacje zgromadzimy w bazie danych. Opis ontologii może być bardzo skomplikowany ( bo relacje o których mowa mogą być złożone). Może być to forma prostej hierarchii ( czyli drzewo w którym każdy obiekt dziedziczy cechy gałęzi bliższych niż on do korzenia, tych z których „wyrasta” ) ale może być tez i tak, ze obiekty sa wielorakich rodzajów i ontologia ma strukturę niebanalnego grafu. W szczególności cechy jakie przypiszemy obiektom nie muszą się ograniczać do cech konkretnych ( „fizycznych”) jak waga czy kolor, ale mogą opisywać także cechy abstrakcyjne. Proszę sobie wyobrazić obiekty opisujące ludzi, ich wzajemne relacje ( „rodzic” – „dziecko”). Opis relacji abstrakcyjnych jak „bycie dziadkiem” oznacza, że obiekt który jest „dzieckiem” ma własne „dzieci”. Własność „bycia ciotka” oznacza posiadanie płci „kobieta” oraz posiadanie wspólnego „ojca” z kimś kto ma „dziecko”. Tego typu relacje mogą być opisane w ontologii i motory baz danych czy aplikacje mogłyby wykonywać w oparciu o nie  proste wnioskowania w logice ( a więc wyliczyć dziadków z bazy danych, pomimo że żadne obiekt nie ma cechy „dziadek” zapisanej w swoich własnościach). Co więcej specyfikacja modelowania w ontologii pozwala na to, że w wypadku relacji pomiędzy obiektami, podajemy jakiego typu są to relacje – funkcyjne, zwrotne, symetryczne, antysymetryczne, przechodnie itp. Pojawia się tu olbrzymia ilość możliwości wykorzystania tych informacji. Obiektowe bazy danych w naturalny sposób stanowią środowisko do przechowywania i łączenia modeli danych – ontologii – z samymi danymi – będącymi opisami konkretnych obiektów. Można powiedzieć, że ontologie to słowniki własności ( i własności własności!), zaś dane to zapisy cech dostępnych w tych słownikach łączące je z realnymi rzeczami opisywanymi baza danych. Warto pamiętać, ze obiekt nie jest zbiorem cech – lepiej jest myśleć w tym kontekście ze obiekt to realna rzecz czy pojęcie, a ontologia to jej – z konieczności niepełny – model.

    Przedstawmy przykładową ontologię. Jako ze pisałem trochę o matematyce, poniżej obrazek przedstawiający fragment grafu ontologii tekstów matematycznych:

MathTextOntology

    A poniżej fragment pliku w którym tą ontologię opisano ( jest to pewna forma xml-a, konkretnie rdf – o czym więcej – poniżej – opisujący nic innego jak cechy  o których wspomniałem. Ontologia sama w sobie jest formą opisów obiektów, czy „rzeczy” jakimi sa pojęcia, o których mówimy kiedy mówimy o innych „rzeczach”. W tym sensie ontologie mogą podlegać modelowaniu wyższego rzędu itp.):

<rdf:Description rdf:about=”http://www.omdoc.org/ontology#NonconstitutiveStatement„>
<rdf:type rdf:resource=”http://www.w3.org/2002/07/owl#Class„/>
<rdfs:subClassOf rdf:resource=”http://www.omdoc.org/ontology#Statement„/>
<dc:description>An OMDoc statement, which is not theory-constitutive, as defined in the OMDoc specification, chapter 15.1 (Types of Statements in Mathematics).</dc:description>
<owl:disjointWith rdf:resource=”http://www.omdoc.org/ontology#ConstitutiveStatement„/>

    Cały plik można pobrać stąd,  warto jednak odwiedzić też stronę na której go opublikowano.  Nadmieńmy tu, że nie istnieje nić takiego jak „jedyna obiektywnie poprawna ontologia” w tym sensie w jakim nie ma niczego takiego jak „jedyny poprawny model rzeczywistości”. Powyższa ontologia, jak wszystkie inne, ma jakieś ograniczone zastosowania, i właśnie do nich została przykrojona. Brak jakichś elementów – tu służących do opisu tekstu matematycznego – na przykład artykułu z dowodem twierdzenia – nie jest żadnym problemem. Po pierwsze łatwo ontologię uzupełnić po prostu dodają dalsze cechy, powiązania, relacje i własności, tak by spełniała nasze potrzeby. W założeniu ontologię maja postać pozwalającą na inkrementalne uzupełnianie o potrzebne elementy. Po drugie ten sam fragment rzeczywistości może być opisywany kilkoma ontologiami, a specyficzna zawartość danej ontologii nie wpływa właściwie w żaden sposób na organizację danych – ale o tym nieco później.

    Rysunek powyżej wykonałem programem Protege4.3 – edytorem służącym do analizowania, tworzenia, obrazowania, rozumowania i dłubania w ontologii. O ontologiach wiele więcej nie powiem, jest to jednak zagadnienie fascynujące, w którym widać jak z pozoru trywialna praca ( wypisanie wszystkich „cech” krzesła, która może wykonać dziecko), w efekcie kumulacji i mądrej klasyfikacji przeradza sie w wiedzę, którą można użyć w całkowicie niespotykany sposób. Ontologia powyżej – tekstów matematycznych- mogłaby być użyta do klasyfikacji treści dokumentów matematycznych, w szczególności o odnotowywania powiązań pomiędzy ich elementami. Na stronie można znaleźć ( niezbyt imponującą) listę aplikacji i witryn które rozumieją tą ontologie i jej używają. Bardziej praktycznymi przykładami mogą być ontologie związane z Wikipedią i z CIA World Fact Book opis jest tu  – a kawałek obrazka poniżej ( proszę kliknąć, aby zobaczyć większy obrazek):

CIA---Pipeline

    Trochę dla żartu zwrócę uwagę, ze w ontologii dosyć szczególne miejsce, bo wyszczególnione od głównego pnia, zajmuje PipelineDistance co sugeruje wagę tego pojęcia w stosunku do reszty, i rzuca pewne światło na tym czym interesuje sie CIA.

    Model relacyjny jest na tyle ogólny by opisać opisaną powyżej strukturę. I w wielu bazach danych na niskim poziomie mamy do czynienia z relacyjnym opisem cech obiektów. Nie wszystkie bazy działają w taki sposób. Z najbardziej znanych przyjdzie mi tu wymienić Lotus Notes, w którym obiektami są dokumenty, zaś sposób operowania na nich określony jest przez metody przypisane do typów które reprezentują. Nie jest to jednak baza relacyjna – nie ma tam tabel, obiekty siedzą sobie „w worku” zaś o sposobie interakcji z nimi decydują zaimplementowane metody oraz „widoki” pozwalające oglądać w przygotowanych „formularzach” wybrane cechy obiektów. Celowo „formularz” i „widok” umieszczam w cudzysłowowy gdyż choć pojęcia te brzmią podobnie do tych używanych w relacyjnych bazach danych, mechanika systemu jest w wypadku Lotus Notes inna, co w wyniku daje olbrzymią łatwość budowania np. przepływów workflow, znacznie trudniejszych do uzyskania w modelu relacyjnym. Obiekty pewne działania znacząco ułatwiają, gdyż pewne ich cechy są opisane mniej lub bardziej hierarchiczną ontologią, zas konstrukcja obiektów pozwala odwoływać się do ich własności niejako wprost, a nie poprzez skomplikowany – a konieczny w modelu relacyjnym – zestaw słowników.

    Przyjmijmy że ktoś nie zna i nie chce znać koncepcji obiektowej bazy danych. Wyobraźmy sobie że chcemy zanalizować pewne dane pochodzące z internetu, cześć z nich pochodzi z witryn producentów (a więc każda z tych części zawiera dane właściwe dla sposobu prezentacji danego producenta, jeden produkuje buty i odwołuje sie do nich po fantazyjnej nazwie, a inny produkuje komputery i odwołuje sie do nich po numerycznym symbolu modelu) i powiązać je z opiniami użytkowników z których każdy na jakimś forum ocenia to co kupił lub o czym tylko czytał pod dosyć dowolnie wybranymi kryteriami. Oczywiście konieczne jest – tak samo jak w wypadku relacyjnej bazy danych – jakieś powiązanie tego o czym mówią jedni i drudzy. Wszakże budowanie bazy danych i tworzenie struktury tabel, w tym ich normalizacja, mogą być działaniami dalece zbyt pracochłonnymi i nieefektywnymi. Zwłaszcza jeśli naszym celem jest poszerzanie zakresu analizowanych danych – a tym samym integracja danych z coraz bardziej różnorodnymi kryteriami oceny dotyczącymi coraz mniej podobnych produktów. Wyobraźmy sobie zadanie napisania systemu który automatycznie uzupełniałby brakujące słowniki. Koszmar.

    Innym przykładem może być próba budowania słownika pozwalającego na prostą analizę języka naturalnego. Nie wystarczy znać tylko znaczenia słów w dwóch językach. Aby zrozumieć strukturę wypowiedzi przydałoby sie mieć jakieś informacje o jej znaczeniu – a jak subtelna mogą być tu różnice łatwo przekona sie każdy kto używa translatora google. Być może interesują nas nie tylko relacje typu „Po Polsku” -> „góra”, ‚po Angielsku” -> „mountain”, ale na przykład „Słowo: -> „ciemny” -> „przeciwstawne” ->”jasny” co wykracza poza zwykle tłumaczenie słów, i zawiera dodatkowe informacje dotyczące języka. Oczywiście możemy budować dla każdej tego typu relacji kolejna tabelę. Będziemy mieli zatem tabele wyrazów bliskoznacznych, przeciwstawnych, mylonych, nic nieznaczących itp. Takich tabel możemy mieć dużo, a i tak próba dodania nowej informacji np. o wyrazach dźwiękonaśladowczych, pejoratywnych lub wulgarnych – będzie wymagała dodania nowej tabeli.

    Każda nowa tabela zwykle wymaga zmian w aplikacji, w mechanice zapytań, uzyskiwanie informacji wymaga złączeń.

    Na poziomie relacyjnej bazy danych, a więc technologii najlepiej znanej na rynku, idea Semantic Web, tak jak ja ją widzę, polega na prostej konstatacji, że relacja między danymi, może być zapisana jako dana w tabeli. Zamiast zatem w określonej tabeli ( relacji) zapisywać dane, możemy zapisać w jednej tabeli, rekordy o strukturze Subject, Predicate, Object – w skrócie <S,P,O>. Subject to identyfikator odnoszący sie do „tematu” czy przedmiotu sprawy. Predykat to określenie relacji, może być to np. ciąg znaków numerycznych ze słownika relacji, zwykle jednak zachęca sie do używania czytelnych dla człowieka, i dla maszyny identyfikatorów URI odnoszących sie do zasobów w internecie, które zawierają informację o jakiej relacji Subject i Obekt mowa. Temat ten blisko zahacza o konstrukcję ontologii i wrócimy do niego niebawem. Trzecia dana – Object jest „realizacją” cechy o której mówimy. Tak więc w wypadku przykładu o którym wspomniałem powyżej moglibyśmy mieć trójki:

<123567> <Type:Nazwa> <„Pizza peperoni”>
<QW234> <OcenaProduktu> <8.5>
<77886y66> <Wpis:ID> <QW234>
<77886y66> <Name> <Tomek>
<QW234> <Wpis:Type> <OcenaProduktu>
<QW234><Dotyczy> <123567>

I tak dalej.

    Jak więc widać i tego typu model danych da sie rozumieć i zapisywać w formie relacyjnej. Semantic Web jest zespołem technik i pojęć budowanych powyżej takiej abstrakcji. Nie interesuje nas sposób realizacji zapisu trójek <S,P,O>. nie będziemy także wspominać o bardziej złożonych strukturach ( np. <S,P,O,L> gdzie L to label – etykieta, struktura taka zwana jest N-quadem ). Interesuje nas taka charakterystyka obiektów w której elementarna forma krotki danych zapisana jest jako trójka ( ang. triple) w postaci <S,P,O> zaś znaczenie predykatów i ich wzajemne relacje opisane sa ( lub nie! ) w podanym mniej lub bardziej formalnie modelu danych zwanym ontologia, który opisuje co najmniej wyjaśnienie znaczenia używanych predykatów, a czasami także ich logiczno-matematyczne własności. Właśnie owo odwołanie sie do znaczenia predykatu jest powodem używania nazwy Semantic Web. Dane zorganizowane w trójki przechowywane sa w plikach RDF, zwanych także N-triples. Pliki RDF mogą mieć wiele równoważnych formatów, od tak banalnej jak pokazana powyżej ( i niezbyt użytecznej) po pliki xml o skomplikowanej strukturze. Nie format, ale zawartość danych, ich organizacja – opis związków miedzy rzeczami, predykatami i wartościami cech – decyduje że mamy do czynienia z danymi związanymi z tematem o którym mowa. Jak widać odskoczyliśmy w stronę abstrakcji, proszę jednak czytelnika by sie nie zniechęcał.W kolejnym wpisie opiszę jak zaimportować do Virtuoso dane z pliku rdf z project Gutenberg i jak zacząć zabawę z tymi danymi.

    Na koniec taki może komentarz.Gdzie używane sa ontologie i trójki?
Pewnie w wielu miejscach. Podałem powyżej przykład OMDOC i CIA Fact Book. W poprzednim wpisie było o Wikipedii i jej bazodanowym end-poincie wikidata. W internecie wiele serwisów pozwala na dostęp do danych w formacie RDF ( Data.gov – gigantyczny zbiór danych rządowych USA, dane rządu UK ponoć też gdzieś sa w takim formacie dostępne ). Warto wiedzieć, ze tematem blisko związanym z tym o czym piszemy sa następujące obszary: bioinformatyka ( ontologie pełnia rolę słowników klasyfikujących zawartość danych i relacje pomiędzy danymi – czy to dotyczące gatunków czy genomu), Web2.0 ;-) i social media jak Facebook ( nie będę linkował bo nie lubię tej platformy, należy jednak wiedzieć że mają oni produkt Open Graph który pozwala na przeszukiwanie grafów czyli w istocie zabawę w mechanikę Semantic Web, bardzo podobną do technik które opisze w kolejnych artykułach. Oczywiście FB zrobił swoje API i opakował całość w user friendly otoczkę dla developerów. U podstaw jednak lezą zbiory trójek o jakich pisałem, zaś już obecnie liczba przetwarzanych krotek w postaci <S,P,O> sięga milionów jeśli nie miliardów. Przyciski LikeIT generują właśnie takie trójki…). Koncepcja SemanticWeb pochodzi od Tima Bernes-Lee ale ma swoje początki w latach 60-tych! jest to więc pomysł równie stary jak web, z tym, że o ile internet skupił sie na użyciu sformalizowanych metod wyświetlania danych ( HTML to język opisu wyglądu strony) o tyle pominął haniebnie koncepcje zapisywania i prezentacji danych tak by zawierały informację o ich znaczeniu ( a więc predykatów i opisu ich znaczenia i własności). Internet był dzieckiem, świat nie był gotowy na takie przetwarzanie danych. Teraz dorasta. Wydaje sie ze z wolna dokonuje sie ewolucja która odświeża ten pomysł, i mam wrażenie ( ale mogę sie całkowicie mylić, jestem po prostu amatorem który coś tam sobie wyczytał. ) że pojawia sie pewna przestrzeń – związana oczywiście z BigData i przetwarzaniem danych w oparciu o grafy, dla mniej lub bardziej zmienionej implementacji tych pomysłów.