Szarym od mżawki świtem Thu, 22 May 2014 21:48:04 +0200, Sebastian Biały
wyrzucił pustą ćwiartkę i oznajmił:

> Mam takie zagadnienie abstrakcyjne.

Nie ty pierwszy - poczytaj zanim się zabierzesz do tematu.
Oprogramowanie potrafiące "przeczytać" książkę w miarę techniczną
potrafiło zbudować bazę faktów i na jej podstawie odpowiadać
na proste pytania przed albo około 2000, zależnie od wymaganych
możliwości. Od tego czasu powstał cały olbrzymi temat semantyki
wraz z formatami danych i implementacjami, czyli bardzo się rozwinął.
Ontologie mają wiele mniej ścisłych problemów, trzeba wybrać
co da się zastosować. Ontologie, wiedza semantyczna, język
naturalny mniej - jakoś tak jest że algorytmy semantyczne
z ludzkim sposobem wysławiania się i myślenia mają zazwyczaj niewiele
wspólnego. Przynajmniej w rejonach tego problemu.

> Jest baza faktów. Ma ona budowę bardziej hierarchiczną niż typowe
> tabelki. Obrazowo mogę ją mniej więcej przedstawić tak:
>
> a) Są domy
> b) W domach siedzą ludzie w róznych ilościach
> c) Ludzie mają znajomych ludzi (relacje jeden-do-wielu)
> d) Ludzie siedzą u siebie, u znajomych, na ulicy
> e) Ludzie mają różne dobra
> f) Ludzie czasem są rodzinami, mają przodków, dzieci itd
> g) Ludzie współdzielą dobra w rodzinie i nie tylko
> h) Dobra naleą do wielu kategorii

Hierarchiczną? Czy punkt a jest b czy b nad a i dlaczego? Sformułuj
najpierw problem. Nie ja jedyny chętnie bym zobaczył drobny przykład,
albo kilka, które pokazywałyby w czym jest problem. Domena nie gra
roli, może być "jakie kfiatki rosną nad rzeczką w której pływał
pstrąg którego zjadł złodziej kradnąc go z marketu".

Bo sam fakt zdefiniowania ogólnie problemu jest za szeroki i za
wąski. Za szeroki, bo można tu się doszukiwać wielu rodzajów
koncepcji, (relacje, relacje relacji, rodzaje obiektów i relacji,
w ogóle "siedzą" wprowadza czynności ze swoją masą zmian; w ontologiach i
semantykach jest tego masa). Za wąski, bo brakuje mi kwantyfikatorów
(patrz punkt d. ci sami jednocześnie?) co się wiąże z constraints.
Pewnie to wszystko jest niepotrzebne, takie mam przeczucie.

Co widzę, jeżeli dobrze zformułowałeś relacje powyżej:
- to jest graf. Nie chce mi się uzasadniać.
- to jest graf, w którym zarówno węzły jak i połączenia są różnych
typów. Typów, właściwości, oznaczeń - w każdym razie węzeł "okulary"
ma inne właściwości niż domy, a domy niż punkt d). W ogóle idąc
w górę grupowania rodzajów relacji zaryzykowałbym, że masz drzewo
rodzajów relacji (pewnie nieistotny fakt że to jest drzewo) i kilka
rodzajów węzłów
- nie widzę hierarchii
- widzę powiązania pomiędzy rodzajami relacji ( f) i g) definiują
jedną relację "dzielą z" za pomocą drugiej "rodzina i nie tylko"/
Chciałem powiedzieć, że istnieje hierarchia rodzajów relacji, ale
się ugryzłem w język, choć wcześniej twierdziłem że to jest drzewo.
Czy taka analiza rodzajów powiązań jest potrzebna czy nie - może
jakiś konkretny przykład problemu?

Zresztą, wszystko nie rozwiązuje problemu. Jeżeli mamy tylko:
- węzły, kilku niezależnych rodzajów
- relacje, kilku niezależnych rodzajów
- nic więcej nam nie potrzeba
...to mamy labelled graph i jeżeli są znane rozwiązania nie ma sensu
się dłużej zastanawiać poza doborem narzędzi. Gorzej i ciekawiej się
robi, gdy są powiązania między rodzajami obiektów i relacji, nie
wspominając o kwantyfikatorach czy zmianach stanu (czynnościach).

Przydałby się real-life problem albo dwa, żeby pokazać o co tak
naprawdę chodzi.

> ....
> Można tak dużo pisać. Baza ba bardzo wiele ukrytych relacji
> hierachicznych typu "dziadek sąsiada co ma telewizor pacujący z moją
> matką ma na imię Heniek".
>
> Potrzebuje przekopać taką bazę pod kontem zapytań w stylu:
> "Ilu moich sąsiadów ma tostery?"

Nie widzę definicji, z której wynikałoby sąsiedztwo. Czepiam się,
bo przydałby się pełny wykrojony z domeny przykład.

> "Kim jest ten koleś co ma psa i pracuje z moją ciotką?"
> "Kto był wczoraj na imprezie łysego w okularach?"
> "Czy którykolwiek z informatyków ma dziewczynę?"
> "Czy ta dziewczyna z domu obok pracowała z moim kolegą ze studiów?"
>
> Bazę mam w postaci zywych struktur w pamięci i mogę je zserializować
> praktycznie do dowolnej postaci. Pomyślałem: może prolog? W zasadzie
> powinien móc mi tą bazę przekopać w sposób sprawniejszy niż SQL badź
> jakieś rękodzieło. Zaznaczam że pomimo że w prologu trochę pisałem,
> jestem technicznie zerem.

Sam SQL nie, ale tak w kwestii technicznej zacząłbym (co już było) od
pytania "co trzeba zrobić i jak" a potem wybrał narzędzia. Może SQL,
który sam w sobie nie ma takich możliwości, da się użyć tworząc serię
zapytań a wtedy podstawową strukturę grafu ma się za free. Pytanie
też ile tych danych jest i czy trzeba trzymać je na dysku. Czyli aspekty
techniczne, w tym kopanie się z koniem Prologiem, którego się nie zna.

> Pytanie: jaką literaturę mam przeczytać, aby rzucić światło na
> rozwiązania tego typu problemów w Prologu? Wydaje mi się że wszelkie
> ogólne ksiązki Prologowe jakoś niespecjalnie zajmują się tego typu
> tematyką, przynajmniej w tych do których mam obecnie dostęp nie znajduje
> odpowiedzi na pytanie jak taki temat ugryźć. Danych jest bardzo dużo,
> relacje są skomplikowane i robienie tego bez wskazówek kogoś
> doświadczonego raczej nie jest dobrym pomysłem.

Jeżeli nauczenie się Prologu zajmuje 12-18 miesięcy do tego przeczytanie
książki, pytanie jest: czy problem jest na tyle rozbudowany, żeby poświęcać
na niego tyle czasu. Drugie: nawet jeżeli tak, to czy nie lepiej odpuścić
Prolog i zaimplementować struktury danych i algorytmy samemu z pomocą
dostępnych bibliotek, a czas poświęcić na przeszukanie dostępnych źródeł
wiedzy na temat problemu. Trywialny nie jest, ale 6 miesięcy wydaje mi się
na wyrost żeby znaleźć wszystko co jest dostępne publicznie na ten temat
i ma bezpośrednie przełożenie na problem. Powinno wszystko być publicznie
dostępne, zostaje kwestia opanowania sporej dawki wiedzy.

Bilbioteki grafowe i algorytmy operujące na nich albo ich elementy są
dostępne w każdej możliwej formie. Martwiłbym się raczej tematem "jak
ich użyć" i "ile muszę sam z książki/publikacji przepisać".

Niestety nie znam dostępnej literatury, ale google scholar wypluwa
po kilkadziesiąć tysi publikacji, trzeba poświęcić trochę czasu na
dospracowanie zapytań, wybrać przeglądowe prace na początek, albo
dać konkretny przykład Panu A.L.

> Dlaczego Prolog? Nie wiem, to jeden z eksperymentów. I co ważne: to nie
> jest problem akademicki: jeśli Prolog ułatwi mi życie to zostanie
> zaembedowany w aplikacji. I nie, baza nie zawiera *takich* danych, ale
> myślę że podobne, na tyle by róznice nie wpływały istotnie na sens
> problemu. Na szczęscie dane są ścisłe, czyli nie interesuje mnie obraz
> statystyczny tylko *fakty*.

Powiedz od razu, że chcesz się nauczyć Prologa, po co zarzucasz jakiś
abstrakcyjny temat... żartuję, ale może najpierw problem potem narzędzie.
Disclaimer: nie znam Prologa, nawet teoretycznie, na tyle, żeby się
poważnie wypowiadać.

> Dlaczego nazywam to hierarchiczną bazą danych? Też nie jestem pewny tej
> nazwy, wydaje mi się że dane są uporządkowane bardziej "kto jest czyim
> wlascicielem" przy czym na róznych płaszczyznach. Byc może jestem w błędzie.

Ulica jest właścicielem ludzi na ulicy, czy ludzie są właścicielami ulicy
i którzy? Albo podane rodzaje relacji są niedokładne, albo istnieją częściowe
hierarchie, albo tak generalnie dołączam się do prośby o kompletny mały przykład.

--
Edek