Wsparcie #3586

Co chcemy docelowo zrobić z wyjściem klasyfikacji?

Added by Adam Radziszewski almost 12 years ago. Updated almost 12 years ago.

Status:NowyStart date:03 Jan 2012
Priority:NormalnyDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Nasze moduły powinno dać się złączyć w potok przetwarzania, więc zakładam, że każdy z nas zamierza zrobić narzędzie, które czyta wejście (najlepiej w formacie CCL + opcjonalnie relacje), ładuje swoje zasoby i generuje wyjście w formacie CCL + opcjonalnie relacje. Pytanie, ile potrzebujemy wspólnych elementów poza formatem we, wy, użyciem fextora i klasyfikatorów. Warto sprawdzić, w jakim stopniu wszyscy zamierzamy zrobić to samo. Proponuję opisać przewidywane scenariusze użycia klasyfikatora (oczywiście to może się potem zmienić).

Rozpoznawacz relacji składniowych — dość naiwna wersja.

Wejście: plik CCL oznakowany chunkami i ich headami (przynajmniej NP, VP, AdjP).
  1. Z iteratora dostajemy wszystkie pary fraz VP–NP i VP–AdjP występujące w każdym zdaniu.
  2. Klasyfikator klasyfikuje każdą z osobna — jaka to relacja albo dla każdej relacji R — czy zachodzi ona między (któryś wariant trza wybrać); wersja ciut lepsza zakłada klasyfikację probabilistyczną (klasa + prawdop. na wyjściu klasyfikatora)
  3. Odpalamy proste reguły, które odrzucają niektóre odpowiedzi klasyfikatora (np. że relacje OBJ nie może zachodzić odnośnie NP, którego head jest w mianowniku)
  4. Odpalamy reguły rozwiązywania konfliktów, które odrzucają niektóre odpowiedzi, jeśli miałyby zachodzić sprzeczne ze sobą relacje (np. poza szczególnymi przypadkami VP nie może mieć dwóch podmiotów). Gdyby użyć klasyfikatorów z prawdopodobieństwem, tutaj by się ono przydało.
  5. Znakujemy pozostałe jako prawidłowe relacje.

History

#1 Updated by Michał Marcińczuk almost 12 years ago

Rozpoznawanie relacji semantycznych

Będzie przebiegało bardzo podobnie do rozpoznawania relacji składniowych, z drobnymi różnicami.

  1. Iterator przechodzi po wszystkich parach nazw własnych występujących w obrębie zdania. Opcja definiowania wszystkich możliwych par nazw własnych zdecydowanie odpada.
  2. Tak samo, tj. każda para jest klasyfikowana.
  3. Reguły filtrujące/uzupełniające --- być może, ale na poziomie wszystkich relacji rozpoznanych w zdaniu. Reguły do relacji będą w stylu, jeżeli zachodzi LOCATION (A,B) i LOCATION (B,C) to musi też być LOCATION (A,C). Jeszcze nie wiem, co dokładnie w takich sytuacjach robić, ale zakładam, że jakieś proste reguły wejdą w użycie.
  4. Znakowanie.

#2 Updated by Bartosz Broda almost 12 years ago

Adam Radziszewski wrote:

zakładam, że każdy z nas zamierza zrobić narzędzie, które czyta wejście

Najlepiej używając po drodze Fextora :)

Ujednoznacznienia znaczeń

  1. Iterator skacze po wszystkich słowach do ujednoznaczniania (identyfikowane po formach podstawowych)
  2. Dla każdego znalezionego miejsca podejmowana jest decyzja o klasie
  3. Brak reguł, a jeżeli będą to ukryje je jako klasyfikator (e.g., tablice decyzyjne)
  4. Zapis decyzji klasyfikatora (ów) do pliku CCL.

#3 Updated by Bartosz Broda almost 12 years ago

Bartosz Broda wrote:

  1. Zapis decyzji klasyfikatora (ów) do pliku.

-> do pliku CCL

Also available in: Atom PDF