On 2014-05-27 23:52, Edek wrote:
> Nie ty pierwszy - poczytaj zanim się zabierzesz do tematu.
> Oprogramowanie potrafiące "przeczytać" książkę w miarę techniczną

Nie analizuje języka naturalnego.

> Hierarchiczną? Czy punkt a jest b czy b nad a i dlaczego?

Ponieważ niezygle czesto wystepują tam zalezności "coś jest wewnątrz
czegoś". Z programowania to oznacza częste relacje parent<->child
wyrażone z relacji między obiektami w pamięci. Myślę że to dość istotna
obsewacja.

> Sformułuj
> najpierw problem. Nie ja jedyny chętnie bym zobaczył drobny przykład,
> albo kilka, które pokazywałyby w czym jest problem.

To nie jest trywialne. Rzeczywisty problem jest - powiedzmy - komercyjny
i nie bardzo mogę go przedstawić w naturalnej postaci.

> 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".

Sprawdze czy mogę przygotowac probkę danych.

> - to jest graf. Nie chce mi się uzasadniać.

Zgadzam sie, jednak przypuszczam że sensowniej będzie powiedzieć: to
wiele grafów, niekoniecznie zaleznych od siebie, pracujące na wspólnych
węzłach.

> - nie widzę hierarchii

"hierarchia" oznacza że mam taką strukture wejściową w formie relacji
elementów wlasnie tak zapisaną (dla bardzo ciekawskich: obiekty w C++
mające "iteratory na dzieci", oraz relacje przez indeksy w mapach). Mogę
ją przekształcić do dowolnej postaci oczywiście.

> 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.

Danych jest *bardzo* dużo, powiedzmy ze zajmuja solidne gigabajty w
pamięci. Jednak relacji nie ma za wiele, w dodatku mają taką cechę że
raczej układają się w gęste grupy powiązane dość luźno między sobą.
Istnieje widoczne lokalne zagęszczenie.

> 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.

Szukam metod wielowątkowo. Z mojej strony zrobiłem już pewne fragmenty w
C++ (oryginalne struktury pamięciowe są w nim wlasnie), w javascripcie,
zrzuciłem do standardowej bazy danych SQL. Te etapy mam wstepnie za
sobą. Przy czym *bardzo* istotny element to wlasnie umozliwienie
koncowemu userowi grzebanie w "zapytaniach".

> 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.

Zgadza się, wiele przeszukałem sieci zanim zadałem pytanie, ale utopiłem
się w ilości zagadnień o ktorych mam nikłe pojęcie. Interesuje mnie
głównie filtr który pozwoli mi zawężyć zakres literatury. Przypuszczam
że prologowcy mają o tym największe pojęcie.

> Powiedz od razu, że chcesz się nauczyć Prologa

Nie chcę :). Ale mam wrażenie, że ten język będzie po prostu godny uwagi
w tym zastosowaniu.

>, po co zarzucasz jakiś
> abstrakcyjny temat... żartuję, ale może najpierw problem potem narzędzie.

Problem już został wstepnie rozwiązany w C++ i tam mam najbardziej
rozbudowane "zapytania" eksperymentalne. Niestety wygląd kodu ukrywa
intencje (więcej emulacji logiki niż sensu zapytania). Chcę zrobić
eksperyment z językiem zorientowanym logicznie aby sprawdzić czy będzie
bardziej czytelny. Nie jestem tez zadowolony z mojej "bazy danych" i mam
przeczucie że zmiene jej organizacji może coś pomóc. Tu muszę szeroko
poczytać o innych organizacjach baz danych.

Nie jestem ograniczony czasowo.