Lista rozszerzeń

Do każdego rozszerzenia przydałoby się dopisać przykład użycia, w pseudokodzie lub opisać słownie.

Słowo JEST na początku punktu oznacza, że wymaganie uwzględniono w specyfikacji (jest wyspecyfikowane albo przynajmniej jest wzmianka i TODO)

  1. Proste rozszerzenia języka
    1. JEST Komentarze blokowe, wieloliniowe ( /* komentarz */ )
    2. JEST Operator porównujący pozycje — rozszerzyć equal na dziedzinę pozycji.
    3. JEST If (w stylu funkcyjnym) lub switch. Przykładowa składnia if(condition, when_true, when_false), np. if(inter(cas[0],cas[1], cas[0], {}).
    4. JEST Jawne przypisanie wartości zmiennej, np. setvar($V, 2) (tak jest w pytonie).
    5. Operator znajdujący ostatni element spełniający warunek. Doprecyzować.
    6. JEST Odpalenie kilku akcji w jednej regule. Np. and(delete(...), mark(NP...)) :- reszta reguły.
  2. JEST Jasne określenie i rozdzielenie typów danych. Uwaga: chodzi tu o typy, które operator może przyjąć i zwrócić (a więc da się je przekazać np. klasyfikatorowi i możliwa jest ich reprezentacja tekstowa). W wąskim zakresie mogą być używane inne typy, o ile 1) nie można ich zwrócić, 2) nie planujemy zmiennych tego typu, 3) używamy tylko stałych podanych wprost.
    1. Jawny typ "zbiór stringów". Pojedyncze stringi używane tylko jako stałe dla niektórych operatorów (np. regex), string jako taki nie musi być typem języka.
    2. Jawny typ "zbiór wartości z tagsetu". J.w. — chyba tylko zbiór potrzebny. Różnica w stosunku do poprzednich implementacji: nie można utworzyć zbioru {subst, "pies"}, operatory mają określone wymagane typy.
    3. Jawny typ boolowski (w C++ wartości prawdy i fałszu były liczbami, nie do odróżnienia od symboli z tagsetu)
    4. Zachować cukier składniowy: jeśli jednoznaczne, to wartość się sama zamieni w jednoelementowy zbiór (type-raising), np. subst -> {subst}/
    5. Literały true i false (jak w Disasterze).
    6. Zachować jawny typ „pozycja”.
  3. JEST Dostęp z zewnątrz do zmiennych (projekt)
    1. Możliwość pobrania wartości.
    2. Możliwość zmiany wartości zmiennej w skompilowanym operatorze. op = p.parse_sth(...); op.vars["E"] = 2; Potrzebne, by zmienić string (lub pozycję), by przeparsować kilka a nie kilka tysięcy operatorów. Potrzebne do jednostek wielosłowowych. TODO jak odwołujemy się do pozycji? bezwględnie (indeks w tablicy tokenów)?
  4. Mechanizm ustawiania bieżącej pozycji w zdaniu — poza językiem, na poziomie API.
  5. JEST Nowe typy zmiennych (język)
    1. Zmienne po stringach.
    2. Zmienne po symbolach z tagsetu.
  6. (?) Funkcje ze zmiennymi lokalnymi. Uwaga: to dość mocny mechanizm. Może da się zrobić to prościej. Podać przypadki użycia.
  7. Debugger. Uściślić, jak to ma wyglądać. Na pewno jakiś podgląd wartości zmiennych.
  8. Informacja składniowa i MWU w ramach wyrażeń funkcyjnych JOSKIPI (język):
    1. Sprawdzenie, czy przez daną pozycję przechodzi fraza danego typu, czy fraza leży dokładnie między podanymi pozycjami, czy fraza się zaczyna na podanej pozycji, czy się kończy. TODO: co jeszcze?
    2. Operatory sprawdzające indeksy, kanały itp. TODO
  9. JEST Rzutowanie zdania po danym kanale
    1. lub jakiś odpowiednik, jeśli przyjmiemy inny model
    2. Wejście: zdanie
    3. Wyjście: obiekt zachowujący się jak zdanie, którego tokeny są scalone tam, gdzie w kanale wystąpiła fraza. Doprecyzować.

Reguły znakowania anotacji semantycznych i składniowych:

Propozycja: podjęzyk reguł i dopasowań, który korzysta z operatorów JOSKIPI.

Nowe JOSKIPI ma składać się z:
  • podstawowego języka wyrażeń funkcyjnych: każde wyrażenie zwraca wartość, a jedynym skutkiem ubocznym może być zmiana wartości przypisanych zmiennym
  • podjęzyka reguł i dopasowań: korzystamy z języka wyrażeń funkcyjnych, ale definiujemy też nowe operatory, które mogą również zmieniać bieżącą pozycję w zdaniu, anotacje, relacje i oznakowanie morfo-synt.

Przeznaczeniem podjęzyka reguł i dopasowań jest ręczne pisanie reguł. Przeznaczeniem podjęzyka wyrażeń funkcyjnych jest ręczne pisanie wyrażeń, które generują cechy dla klasyfikatora opisują warunki konieczne uznania ciągu za jednostkę wielowyrazową (pewnie coś jeszcze).

Opis języka dopasowań: Dopasowania

Obsługa jednostek wielowyrazowych

Implementacja w starym JOSKIPI i problemy opisano tu: Jednostki_wielowyrazowe

  1. Transparentna obsługa jednostek przez aplikację (np. iteracja po jednostkach wielowyrazowych, a jeżeli w danym miejscu nie ma, to po jednowyrazowych).
    1. Mechanizm rzutowania tutaj pasuje.
    2. Jednostki są reprezentowane tak samo jak chunki, mają określoną głowę i/lub tagi.
    3. Tagi głowy bądź całości stają się tagami jednostki jako tokenu po rzutowaniu.
    4. Lemat też jest przypisany, staje się on nie do odróżneinia od lematów tokenów.
  2. Transparentna obsługa na poziomie JOSKIPI; np. operator wie, że to jest jednostka i np. obecny llook szukając w lewo o 5 pozycji, iteruje też po jednostkach (a np. agrpp sprawdza zgodność pomiędzy jednostką wielowyrazową a jednostką na pozycji 0 w taki sam sposób jak z ze zwykłym tokenem)
    1. Propozycja: ten sam mechanizm rzutowania. Po rzutowaniu llook widzi tam token.
    2. Minus: na etapie oznaczania jednostek są one tylko ciągami tokenów. Gdy świadomie zakończymy ten proces, morzemy utworzyć projekcję zdania po kanale i wtedy mamy jednostki na poziomie tokenów (nie psuje to zdania, to alternatywna reprezentacja).
  3. Zachowanie dotychczas napisanych ograniczeń na jednostki wielowyrazowe.
  4. Obsługa jednostek nieciągłych.
    1. Propozycja: koideksowane chunki/jednostki.
    2. Rzutowanie scala wszystkie części, reprezentantem jednostki jest głowa.
    3. [ Transporter ]/1-HEAD przyjechał [ opancerzony ]/1 -> [ Transporter opancerzony ] przyjechał.
    4. Na etapie znakowania trzeba napisać wyrażenie, które pominie pozostałe części, a fragmenty oznakuje jako dany typ i ten sam indeks.

Wymagania do architektury i implementacji

  1. Wydajność (przetwarzamy miliony zdań)
  2. Brak globalnego stanu. Utrudnia to przetwarzanie rozproszone (np. CWordDictionary). Może da się to wyeliminować bez znacznej straty wydajności? Dodatkowym utrudnieniem przy tym CWordDictionary jest złożoność pamięciowa (wszystkie słowa w korpusach zajmują całą pamięć, teraz: słownik początkowy musi być zapisany i co jakiś czas czyszczony/wczytywany)
  3. Wrappery Pythonowe (najlepiej wykonać je w SWIG, wtedy będzie można też wygenerować w miarę tanim kosztem opakowanie dla np. Javy)
  4. Funkcje, które zamieniają pozycje względne (tj. względem bieżącej w zdaniu) na bezwzględne (indeksy w tablicy) i na odwrót.

Reprezentacja danych (anotacje składniowe i inne)

Główny dokument: Reprezentacja_anotacji

Warto poczytać

Tak czy inaczej polecam lekturę http://www.faqs.org/docs/artu/minilanguageschapter.html z "The Art of Unix Programming" autorstwa E. S. Raymonda. (A dokładniej to ten podrozdział jest najbardziej interesujący: http://www.faqs.org/docs/artu/ch08s03.html)

rozszerzenie_JoSKIPI.pdf - Opis operatorów na potrzeby anotacji semantycznej z przykładami ich zastosowania (181 KB) Michał Marcińczuk, 20 Sep 2010 13:10

rozszerzenie_JoSKIPI_v2.pdf - Rozszerzona lista operatorów (209 KB) Michał Marcińczuk, 28 Sep 2010 13:03

rozszerzenie_JoSKIPI_v3.pdf - Dokładniejszy opis nowych operatorów -- wynik rozmowy przez Skype z 29.09.2010 (269 KB) Michał Marcińczuk, 30 Sep 2010 16:27