|
|
(1) ograniczenie wyników elinkera, wsd (po kwazonie?), filtrowanie wyników (odrzucić jednowyrazowe jednostki, bo urle mogą być nieprawidłowe, ale dla wielowyrazowych powinno być lepiej, więc warto finalnego CCLa przefiltrować :), może w kwazonie?)
|
|
|
[[_TOC_]]
|
|
|
|
|
|
(1) ograniczenie wyników elinkera, wsd (po kwazonie?), filtrowanie wyników (odrzucić jednowyrazowe jednostki, bo urle mogą być nieprawidłowe, ale dla wielowyrazowych powinno być lepiej, więc warto finalnego CCLa przefiltrować :), może w kwazonie?)
|
|
|
**> jednorazowe czy jednowyrazowe? Jeśli jednowyrazowe to tym samym chcemy uwzględniać tylko pojęcia z adnotacją mwe i ne, czy tak?**
|
|
|
|
|
|
(2) przyspieszenie ładowania kwazonu: dużo danych ładowanych jest z plików tekstowych? (chyba) -> zamienić na pickle
|
... | ... | @@ -9,13 +11,13 @@ |
|
|
|
|
|
(6) poprawa buga który wywołuje segfault: https://gitlab.clarin-pl.eu/team-semantics/gtpprmc/issues/1 https://gitlab.clarin-pl.eu/team-semantics/gtpprmc/issues/3
|
|
|
|
|
|
(3) przyspieszenie działania kwazonu poprzez wstępną redukcję analizowanych kategorii (im więcej kategorii, tym gorzej…, bo trzeba wykonać spacery dla większej liczby kategorii); podstawowym założeniem było to, że zajmujemy się wyłącznie istotnymi kategoriami, a nie wszystkimi. Może da się wykonać jakąś wstępną selekcję kategorii wybieranych do analizy?
|
|
|
można wykonać wstępną analizę za pomocą wektorów, tzn. wiem, że liczyliśmy podobieństwo wektora kategorii do tekstu, a także podobieństwo sąsiadów tych kategorii do tekstu -> wytnijmy może te, których odchylenie standardowe podobieństwa sąsiadów jest duże? Jak wpadnie mi coś do głowy to dam jeszcze znać
|
|
|
**> Sądzę że zmniejszenie liczby spacerów nieznacznie wpłynie na całkowity czas przetwarzania, bo czas wykonania algorytmu c++ jest jakąś małą częścią całego czasu zadania. Przede wszystkim powinienem poszukać w pythonowej części narzędzia. Oczywiście, jeśli nie dało by się skrócić czasu do zadowalającego poziomu, to i redukcja liczby spacerów będzie dobrym rozwiązaniem.**
|
|
|
(3) przyspieszenie działania kwazonu poprzez wstępną redukcję analizowanych kategorii (im więcej kategorii, tym gorzej…, bo trzeba wykonać spacery dla większej liczby kategorii); podstawowym założeniem było to, że zajmujemy się wyłącznie istotnymi kategoriami, a nie wszystkimi. Może da się wykonać jakąś wstępną selekcję kategorii wybieranych do analizy?
|
|
|
można wykonać wstępną analizę za pomocą wektorów, tzn. wiem, że liczyliśmy podobieństwo wektora kategorii do tekstu, a także podobieństwo sąsiadów tych kategorii do tekstu -> wytnijmy może te, których odchylenie standardowe podobieństwa sąsiadów jest duże? Jak wpadnie mi coś do głowy to dam jeszcze znać
|
|
|
**> Sądzę że zmniejszenie liczby spacerów nieznacznie wpłynie na całkowity czas przetwarzania, bo czas wykonania algorytmu c++ jest jakąś małą częścią całego czasu zadania. Przede wszystkim powinienem poszukać w pythonowej części narzędzia. Oczywiście, jeśli nie dało by się skrócić czasu do zadowalającego poziomu, to i redukcja liczby spacerów będzie dobrym rozwiązaniem.**
|
|
|
(4) wycięcie bzdurnych kategorii (np. kategorie zawierające nazwę państwa w nazwie)
|
|
|
|
|
|
(8) dołączenie pozostałych pojęć z linked open data! Teraz jest chyba tak, że pojęcia są mocno zależne od struktury Wikipedii. Czy inne pojęcia też są dołączane?
|
|
|
|
|
|
(9) Rozszerzenie grafu kategorii o inne struktury hierarchiczne z linked open data (np. Struktura Gemetu, struktura Eurovocu itd., może te 2 byłyby ok, tylko musimy wiedzieć, jak je dołączyć tzn. w którym miejscu się wpiąć).
|
|
|
|
|
|
(10) ponowna propagacja! błędy rzutowania... PAN -> jako instytucja, nie osoba |
|
|
\ No newline at end of file |
|
|
(10) ponowna propagacja! błędy rzutowania... PAN -> jako instytucja, nie osoba |