Skoro klasy zostały już utworzone i mamy wystarczająco pomidorów na pomidorówkę, spaghetti, lazanię, faszerowane pomidory i jajecznicę z pomidorem, czas wziąć się za budowanie relacji naszej armii pomidorów z resztą Gangu Świeżaków.

Idziemy więc do zakładki „Properties". Wyskakuje nam widok bliźniaczo podobny do tego, z którym spotkaliśmy się, gdy pierwszy raz zajrzeliśmy do zakładki „Classes", różni się jednak kilkoma drobnymi szczegółami.

Jak pewnie zauważyliście, opcje „Create" i „Delete" przy tworzeniu klas miały kształt kółek, tutaj natomiast widzimy prostokąty. Pełnią one dokładnie taką samą funkcję, z tą jedynie różnicą, że nie tworzą nam klas, tylko właściwości.

Zmieniła się też nazwa elementu bazowego w naszej hierarchii; tutaj, zamiast klasy „owl:Thing", mamy specyfikację „owl:topObjectProperty" i jest ona dla właściwości dokładnie tym samym, co jego krewniak dla klas w zakładce obok. Co za tym idzie, z tym elementem bazowym również niczego nie kombinujemy. Klikamy więc na niego i klikamy na analogiczną do naszej poprzedniej opcję „Create".

Tutaj wszystko jest tak samo jak w przypadku klas, również możemy tworzyć je pojedynczo lub naraz i, tak samo jak wcześniej, zaznaczam, że ja trzymam tu formę zapisu „turbopoprawną", którą stosowaliśmy na zajęciach, jednak tutaj również możecie spokojnie używać spacji czy polskich znaków i nic strasznego nie powinno się z tego powodu wydarzyć.

Po stworzeniu właściwości, które nas interesują, porządkujemy je w dokładnie taki sam sposób jak klasy (o tym, w jakim celu stworzyłam też właściwości z kategorii „relacje" napiszę za chwilę):

Taa, dałam kształt „inny", żeby nie mordować się z truskawką i gruszką XD

Tutaj, w naszej hierarchii właściwości, mamy dodatkowo trzy zakładki. Nie ma jednak po co zawracać sobie nimi głowy, ponieważ interesuje nas tylko ta pierwsza. Poza tym, tak jak wcześniej, również nasze właściwości możemy okraszać komentarzami w tym samym oknie co wcześniej.

W głównym oknie właściwości (tym pośrodku) wiele robić nie będziemy, chyba że chcemy ustalić jakieś reguły mówiące na przykład o tym, że dana właściwość może zostać przypisana wyłącznie do określonej klasy lub grupy klas (tutaj już mi się wkrada przykład pisarski: zakładając, że tworzycie fantasy i macie ileś ras, które korzystają z magii i ileś, które z niej nie korzystają. Jeśli podzielicie bohaterów – czyli nasze klasy/elementy – według ras, będziecie mogli również stworzyć właściwość „uzywaMagii" i uniemożliwić jej przypisanie do ras, które z niej nie korzystają; tak na zaś, gdyby kiedyś Wam się zapomniało, czy wilkołaki w Waszym świecie mogą czarować, czy też nie).

Zasadniczo wszystkie powtarzające się nazwy i ikony działają tu tak samo jak w klasach, więc nie ma potrzeby tłumaczyć tego samego po raz drugi. „Domain" i „Range" są właśnie tymi ogranicznikami, o którym wspomniałam wcześniej. Część „Range" opiszę za chwilę, bo dotyczy ona zupełnie innego rodzaju relacji, którą najpierw musiałabym zobrazować, żeby wytłumaczyć jej działanie. Na razie zajmijmy się tylko „Domain": jeśli przypiszemy do tej sekcji jakąś klasę, ta właściwość może dotyczyć wyłącznie tej przypisanej klasy i ewentualnych pomniejszych, które są w niej zawarte. Jeśli spróbujemy przypisać taką właściwość do klasy spoza wymienionych, również wyświetli się nam czerwone podkreślenie i ostrzeżenie o możliwym błędzie. Tutaj dla przykładu wrzuciłam „Warzywa" (co jest bez sensu i za chwilę to usunę, bo przecież mamy też pomarańczę, ale potrzebowałam przykładu). Oznacza to, że w tym momencie możemy przypisać kolor pomarańczowy wyłącznie do kategorii „Warzywa" i wszystkiego, co się w niej znajduje, a zatem „Owoce" w całości odpadają.

Zaraz... kolor?

Wróćmy do klas i do naszego pomidora (nieskończoną pętlę pomidorową również teraz usunę, żeby potem przypadkiem nie wywaliła się wizualizacja). Spróbujmy ustalić mu jakąś relację. Pomidor jest czerwony, co nie? Problem w tym, że mamy dwa pola do uzupełnienia. Mamy ten „czerwony", ale czym jest czerwony? Kolorem. A mamy jakąś klasę, którą określiliśmy jako kolor? No nie.

Tutaj z pomocą przychodzi nam zakładka „Individuals" i nasze zmienne pomocnicze; nie mamy potrzeby robić ich bezpośrednio w zakładce, ponieważ możemy ustawić je bezpośrednio z poziomu klasy, wybierając opcję „New Named Individual". Zasadniczo nie są nam potrzebne, bo my wiemy, o co chodzi, jednak komputer to wciąż komputer i się nie domyśla, więc wszystko trzeba mu wyłożyć jak krowie na rowie, żeby ogarnął, czego chcemy.

Skoczmy teraz na chwilę do jabłka. Jabłko może być zarówno zielone, jak i czerwone, nie? Podobnie jak w sekcji „Parents", do sekcji „Relationships" również możemy dodawać wiele linijek, a zatem przypisanie jabłku obu kolorów nie stanowi problemu. Zróbmy jednak jakąś relację z prawdziwego zdarzenia! Przy okazji, zauważyliście pewnie, że z poziomu relacji da się też tworzyć nowe klasy. Stwórzmy więc nową klasę w ten sposób. Hmm... dzieci przeważnie lubią jabłka, ale nie lubią brokułów, więc powiedzmy, że jabłko też nie lubi brokuła. Ta dam!

Brokuł powstał, wyrzucony gdzieś na peryferia, jednak oczywiście możemy ustawić go na właściwym miejscu. Możemy robić dowolną ilość zarówno klas, jak i właściwości oraz relacji, plus możemy tworzyć sobie ograniczenia we wspomnianej sekcji „Domain", żeby się w tym wszystkim nie pogubić. 

Wspomnijmy sobie teraz, o co chodziło z tym „Range" we właściwościach. „Domain", jak wspominałam, określa, która właściwość może opisywać które klasy. Co jednak w sytuacji, w której mamy dwa elementy, które połączyliśmy ze sobą relacją? Wtedy sprawy się nieco komplikują.

Gdy tworzymy relację z użyciem dwóch klas, opisana wcześniej sekcja zmienia swoje znaczenie. Przy pomocy „Domain" możemy określić, które elementy mają prawo używać danej właściwości, żeby opisywać swój stosunek do innych elementów, a „Range" przejmuje wcześniejszą rolę „Domain", czyli mówi, których elementów ten stosunek może dotyczyć. Innymi słowy: jeśli wejdziemy we właściwość „nieLubi" i w „Range" wpiszemy „Warzywa" a do „Domain" wsadzimy „Owoce", będzie to dla programu oznaczało, że każdy z owoców może nie lubić każdego warzywa, ale nigdy na odwrót, a w dodatku ani owoce, ani warzywa nie mogą nie lubić siebie nawzajem. Jeśli natomiast w „Domain" zostawimy „Owoce", natomiast „Range" pozostawimy puste, wtedy tylko owoce będą miały prawo pałać do kogoś niechęcią, zaś warzywa zostaną zmuszone do tego, by kochać cały świat.

Pokazałam Wam właśnie dwa sposoby tworzenia relacji – z użyciem klasy oraz z użyciem named individual, dla którego nie umiem znaleźć wystarczająco ładnie brzmiącego polskiego odpowiednika. Może teraz wyjaśnię, czym to się różni.

Zasadnicza sprawa: kiedy będziemy tworzyć naszą mapę myśli, relacje utworzone z użyciem klasy będą się na niej wyświetlać, a te z named individual nie. Gdybyśmy więc finalnie chcieli zobaczyć na mapie myśli, kto z Gangu Świeżaków ma jaki kolor i kształt, musielibyśmy, przykładowo, stworzyć dodatkową kategorię klas z kolorami i kształtami, a następnie tworzyć relacje za pomocą właściwości „maKolor" i „maKsztalt".

Opcji z named individual używamy wtedy, gdy chcemy przypisać właściwość „dla formalności" i niespecjalnie nam zależy, żeby potem ją widzieć na wizualizacji. Dla komputera ta nasza zmienna pomocnicza jest po prostu latającym sobie gdzieś w przestrzeni ciągiem liter, który właściwie nic nie znaczy, ale sobie jest, ponieważ my tak chcieliśmy. Można to wykorzystać do przypisywania właściwości, które gdzieś tam po prostu sobie są, wiszące na elemencie i z niczym niepowiązane – w taki sposób możemy chociażby przypisywać bohaterom jakieś umiejętności albo spisywać posiadane przez nich przedmioty, które później mogą okazać się istotne.

Relacji z użyciem klasy używamy, gdy jest to coś poważniejszego i chcemy, żeby komputer zdawał sobie sprawę z tego, że to nie jest jakaś pierdoła, którą można traktować po macoszemu. Named individual może być absolutnie wszystkim, choćby różowym słoniem z siedmioma nogami, zębami chomika i uszami kota, ale dla programu będzie to całkowicie bez znaczenia. Klasa jest konkretną jednostką i program już nieco bardziej się interesuje, czym ona jest, więc relacje utworzone z jej pomocą będą uznawane za ważne i, przede wszystkim, będą się później pojawiały na mapie. Oczywiście relacje z użyciem klasy są też używane w takim przypadku jak tu – kiedy chcemy połączyć ze sobą dwa elementy, którymi mogą być chociażby nasi bohaterowie.

Gdybym miała porównać do czegoś to, w jaki sposób program odbiera te dwa rodzaje relacji... Relacje z użyciem klasy to takie małżeństwa z dwudziestoletnim stażem, a relacje z użyciem named individual to pary, które chodzą ze sobą od tygodnia i w sumie jeszcze nic z tego nie wynika.

Dobra, ja teraz uporządkuję to wszystko, pododaję każdemu świeżaczkowi kolory i kształty (z named individual) oraz po jednej sympatii i po jednej antypatii (z klasami), a w następnym wpisie przerzucimy to wszystko na obiecaną mapę myśli.