Discuție:Flexiuni LOC

De la dexonline wiki
Versiunea din 4 februarie 2019 15:15, autor: Cătălin.Frâncu (discuție | contribuții)
(dif) ← Versiunea anterioară | Versiunea curentă (dif) | Versiunea următoare → (dif)
Sari la navigare Sari la căutare

Aceasta este vechea discuție din vremea când foloseam MediaWiki, trecută prin Trac și înapoi la discuție MediaWiki. :-)

Această schemă a fost adoptată. -- CătălinFrâncu 26 februarie 2007 10:03 (PST)

Propunere tabele

Tipuri modele

CREATE TABLE IF NOT EXISTS model_types (
  mt_id 	int(10) 	unsigned NOT NULL default 0,
  mt_value	char(2)		NOT NULL default '',
  mt_descr	char(255) 	default NULL,
  PRIMARY KEY  (mt_id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Explicaţii:

  • va conţine tipurile de modele: M, F, N, MF, A, P, V, VT...

Observaţie:

  • MF ar trebui să dispară, ea fiind numai o combinare a două cuvinte;
  • probabil că se poate face tranformarea automat, cu ajutorul unui script


Lista de modele

CREATE TABLE IF NOT EXISTS models (
  model_id 	int(10) 	unsigned NOT NULL default 0,
  model_type 	int(10) 	unsigned NOT NULL default 0,
  model_no	int(10) 	unsigned NOT NULL,
  model_descr 	text 		default NULL,
  PRIMARY KEY  (model_id),
  KEY morf_index (model_type,model_no)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Observaţii:

  • Probabil că model_id e bine să fie autoincrement, chestie valabilă pentru cam toate id-urile de aici;
  • model_description conţine exact exemplificarea din preambulul LOC, pentru clarificare;

Constrîngeri:

  • models.model_type -> model_types.mt_id

Explicaţii:

  • va conţine lista cu modelele împreună cu un exemplu; din această tabelă să se poată reface lista de modele!
  • pentru consistenţă ar trebui băgate şi modele invariabile (cel puţin unul general, dar cred că ar fi preferabil cîte unul pentur fiecare parte de vorbire posibilă)

Lista de flexiuni

CREATE TABLE IF NOT EXISTS inflections(
  infl_id 	int(10) 	unsigned NOT NULL default '0',
  infl_descr	char(255)	NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Explicaţii:

  • va conţine lista cu toate analizele posibile (gen: substantiv masculin singular genitiv/dativ articulat şamd)
  • le conţine numai pe cele formate dintr-un singur cuvînt
  • se poate face uşor o extensie care să spună ce forme sînt "sinonime"

Lista transformărilor

CREATE TABLE IF NOT EXISTS transforms (
  transf_id 	int(10) unsigned NOT NULL default '0',
  transf_descr 	char(10) collate utf8_romanian_ci NOT NULL,
  PRIMARY KEY (transf_id)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Explicaţii:

  • conţine lista transformărilor posibile - ar putea conţine
    • expresia regulată care se aplică
    • numele funcţiei care se aplică pentru expandare
    • codul efectiv al funcţiei care se aplică
    • şamd
  • nu cred că are sens să folosim cuvinte "model", ci mai curînd să folosim
  • pe viitor se poate normaliza şi mai bine, de exemplu aplicînd separat alternanţele fonetice, regulile fonetice şi respectiv sufixarea cu terminaţii specifice

Descrierea modelelor

CREATE TABLE IF NOT EXISTS model_description (
  md_model 	int(10) unsigned NOT NULL default '0',
  md_infl	int(10) unsigned NOT NULL default '0',
  md_transf 	int(10) unsigned default NULL,
  PRIMARY KEY (md_model,md_infl),
  KEY md_transf (md_transf)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Constrîngeri:

  • model_description.md_model -> models.model_id
  • model_description.md_infl -> inflections.infl_id
  • model_description.md_transf -> transforms.transf_id

Explicaţii:

  • va conţine desfăşurarea modelelor

Observaţii:

  • ordinea de "calcul" nu contează, deci nu e nevoie de un cîmp de ordine; dacă totuşi e nevoie pentru re-generarea modelelor, se poate pune şi un cîmp order...

Lista de lexeme

CREATE TABLE IF NOT EXISTS lexems (
  lexem_id 	int(10) 	unsigned NOT NULL default '0',
  lexem_forma 	char(50) 	default NULL,
  lexem_model 	int(10) 	unsigned NOT NULL default 0,
  PRIMARY KEY  (lexem_id),
  KEY lexem_model (lexem_model)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Constrîngeri:

  • lexems.lexem_model -> models.model_id

Explicaţii:

  • aceasta ar fi lista de cuvinte LOC 3 în variantă dexonline
  • ? ar trebui şi tulpina ?

Lista desfăşurată de forme

CREATE TABLE IF NOT EXISTS wordlist (
  wl_form 	char(50) 	NOT NULL default '',
  wl_lexem	int(10) unsigned default NULL,
  wl_analyse	int(10) unsigned default NULL,
  KEY wl_lexem (wl_lexem),
  KEY wl_analyse (wl_analyse),
  KEY wl_analyse (wl_analyse)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_romanian_ci;

Explicaţie:

  • conţine paradigmele tuturor cuvintelor


Constrîngeri:

  • wordlist.wl_lexem -> lexems.lexem_id
  • wordlist.wl_analyse -> inflections.infl_id

Alte observaţii

Referitoare la tabele

  • deocamdată numai pentru cele generate prin flexare
  • se poate extinde uşor, wl_analyse putînd să pointeze, de exemplu către nomenclatoarele de botanică, zoologie, chimie şamd
  • wl_analyse poate oferi şi informaţii despre variante (acceptate sau nu, dar care apar în dicţionare)
  • LOC 3 conţine numai forme utilizabile la scrabble, adică dintr-un singur cuvînt
  • LOC 3 NU conţine forme neaccentuate, enclitice şamd - exemplu: l- (l-am), spunîndu- (spunîndu-i)
  • cu puţin efort, se poate extinde la forme de mai multe cuvinte (gen: "a capella")
  • nu am studiat, dar probabil poate include şi expresii
  • am deja făcut un exemplu (transformările sînt de fapt o listă ordonată de modificări atomice pentru cuvînt - din păcate încă nu am normalizat extinderea cu minitransformările)

Propuneri generale

Aş avea cîteva propuneri:

  • să existe un "cluster" total separat pentru generatorul de forme / analizorul lexical
  • să îi definim de la bun început funcţionalităţile posibile şi abia apoi să lucrăm la el
  • să folosim de la bun început ADODB sau altă interfaţă pentru DB (sigur, dacă Cătălin va vrea să o utilizeze)
  • este foarte probabil să fie folosit şi de alţii (eu sper să iasă bine)

Opinii despre schemă

În cea mai mare parte, sunt de acord! Principala mea obiecţie este legată de tabela transforms. Ştiu că ar fi bine să stocăm, de exemplu, o expresie regulată, pentru că atunci am fi mai aproape de o gramatică în sensul informatic al cuvântului. Totuşi, până la urmă depindem de voluntari pentru introducerea datelor (după preluarea LOC3) şi cred că o listă de forme ar fi mai simplu de înţeles pentru toată lumea. Ce-i drept, codul pentru a flexiona un cuvânt după un model dat va face ceva în genul unei expresii regulate (se va uita cum s-a modificat forma derivată în cazul modelului şi va aplica aceeaşi transformare cuvântului de flexionat).

Propun deci să renunţăm la transforms pentru început şi să stocăm, în model_description.md_transf, direct forma derivată. Ulterior, putem introduce această tabelă cu acelaşi efort pe care l-am depune acum dacă ar fi.

  • -- RaduBorza 13 decembrie 2006 09:32 (PST) Cînd spui "introdus" la ce te gîndeşti? Eu nu prea văd ce trebuie introdus. Practic trebuie un parser care să citească fişierul cu descrierea modelelor care există deja asociat LOC-3. De aici se generează lista cu descrierile, care vor fi introduse automat în baza de date. Să zicem că facem un pas intermediar în care vom avea lista desfăşurată, după care eventual facem un generator de regexp-uri din cele cuvîntul de bază şi cel modificat. După aceea, mai trebuie făcute legăturile, fie cu tabela words, fie cu "concepte"-le. De astea ziceam că o mare parte se pot face automat. Vor mai trebui dezambiguizate anumite legături făcute automat şi, sigur, de văzut ce se întîmplă cu cele rămase fără model. Spun asta pentru că mai multe modele se pot mula pe acelaşi cuvînt ca să dea rezultatul respectiv, deci ar trebui ales modelul minimal!
  • -- CătălinFrâncu Aş prefera pasul intermediar, pentru că e mai puţin cod de scris dintr-o dată (întotdeauna apar probleme când fac un commit prea mare dintr-o dată). Codul care ar extrage regexp-ul va exista deja, pentru că trebuie să aplic acelaşi regexp pentru a eticheta cuvintele care se flexionază ca modelul dat. Dar aş prefera să nu stocăm acest regexp pentru început.
  • -- RaduBorza 14 decembrie 2006 10:41 (PST) Deci hai să stabilim paşii. În primul rînd e nevoie de un script care să desfăşoare fişierul cu modele. Cred că sîntem ambii de acord cu asta, nu? Practic, dacă am transforma lista de exemple la forma: "model_id,formă,analiză[,nr_ordine]" ar fi OK? Promit să mă ocup eu cu treaba asta, avînd în vedere că zici că ai făcut tu extractorul de regexpuri. Încep cu cel de substantive/adjective şi îmi dau termen pentru un beta cel tîrziu duminică seară. E ok? Dacă totul merge coerent, stabilim şi nişte specificaţii :P
  • CătălinFrâncu 14 decembrie 2006 11:11 (PST) Ar fi superb :) Dar să ştii că eu nu am făcut extractorul de regexp-uri. O să-l fac când o să scriu scriptul care să desfăşoare lista de cuvinte (probabil va fi pe încercate). Dacă tu scrii scriptul ăla, eu îmi scot pălăria, că fişierul pare imposibil de parsat (cel puţin doc-ul). Eu am început, fără prea mult elan, să implementez schema şi să o elimin pe cea veche.
  • -- RaduBorza 18 decembrie 2006 01:54 (PST) Hai că am făcut practic motoraşul care preia din exemple şi re-creează tabela. Două întrebări:
    • Care să fie formatul? Mă gîndeam la două fişiere csv/tabele, unul cu analizele (tip, id_analiză, analiză, forma_baza) şi altul cu desfăşurătorul propriu zis (tip, subtip, formă, id_analiză). Exemplu: (M, 1, 'substantiv masculin N/Ac singular nearticulat', 'da') şamd şi respectiv (M, 1, 'lup', 1) şamd. E ok aşa? Sau preferi un format de tip xml? NB forma_baza e necesar pentru a sti care e forma la care ma refer cind voi "calcula" regexpurile (practic e cel mai mic id din grup, dar nu-mi plac hack-urile de genul ăsta).
    • Unde le salvez? Nu există o bază de date accesibilă din exterior? De asemenea, mă gîndeam că astea ar trebui să apară şi pe dexonline.ro, ca o pagină separată (sau mai multe).
  • CătălinFrâncu 20 decembrie 2006 13:59 (PST) Formatul propus de tine e perfect. CSV e mai simplu de parsat, ca să nu caut un XML parser pentru PHP. Le putem publica ulterior şi pe DEX online, dar aş prefera să le generăm dinamic din baza de date (nu neapărat în timp real, putem regenera pagina o dată pe zi). Baza de date, din păcate, nu e accesibilă din exterior, că am zis să nu deschid încă un port în plus (mai ales că două din mirror-uri sunt găzduite de alţii).

Şi nişte întrebări:

  • ce conţine infl_descr? De exemplu, dacă mt_descr conţine substantiv masculin, atunci în infl_descr punem numai singular nominativ-acuzativ nearticulat, sau complet substantiv masculin singular nominativ-acuzativ nearticulat?
    • -- RaduBorza 13 decembrie 2006 09:18 (PST) infl_desc ar trebui să conţină datele complete, într-adevăr: pv, gen, număr, caz, articulare pentru substantiv şi adjectiv; pv, mod, timp, persoană, număr etc pentru verb;
  • cred că un câmp md_order în model_description ar fi bun, pentru a ordona în mod consecvent formele acolo unde există mai multe. De exemplu, dacă la mai mult ca perfect, persoana I plural avem ştiusem şi ştiuserăm în această ordine, e bine ca şi la persoana a II-a să avem ştiuseţi şi ştiuserăţi în aceeaşi ordine.
    • -- RaduBorza 13 decembrie 2006 09:18 (PST) da, e ok (cu menţiunea că o singură formă este totuşi cea corectă, cealaltă fiind doar o variantă )
  • cred că putem folosi ADODB, deşi nu sunt foarte sigur. Teoretic, există deja fişierul modelObjects.php, care este singurul care discută cu baza de date (am creat câte o clasă PHP pentru fiecare tabelă MySQL).
    • -- RaduBorza 13 decembrie 2006 09:18 (PST) ziceam de ADO numai dacă faci o structură separată pentru analizorul ăsta (adică dacă separi total dexonline-ul de flexonline). Si normal, dacă tu vrei să îl foloseşti (e bine să începi să-l foloseşti cu un proiect de la zero). Dar
    • CătălinFrâncu 13 decembrie 2006 11:55 (PST) Nu ştiu dacă putem separa cele două module. Adică putem, evident, dar în DEX/phplib/ există o grămadă de cod utilitar la care n-aş vrea să renunţ.
    • -- RaduBorza 14 decembrie 2006 10:41 (PST) Păi de ce nu faci un director pentru utilitare, common, care sa fie accesibil tuturor "sit"-urilor? Acolo ar trebui să îşi aibă locul şi aplicaţiile gen ADODB, pentur că ar fi potenţial folosibil din mai multe părţi.
    • CătălinFrâncu 14 decembrie 2006 11:11 (PST) Dacă la asta te referi când spui separare, atunci cam la aşa ceva mă gândeam şi eu (phplib/ e directorul cu biblioteci, www/flex e cel pentru php-uri şi templates/flex e cel pentru template-uri HTML).
    • -- RaduBorza 18 decembrie 2006 02:04 (PST) Oarecum la asta, numai că gîndeam un grad mai mare de separare, deci să îl pui un nivel mai sus (mă gîndesc că cele două entităţi fiind distincte, vei face separarea inclusiv la directoare virtuale în apache, că nu ar fi rău să ai logurile separate). Dar dacă stau să mă gîndesc, într-adevăr poţi lăsa dexwww pentru dexonline faci flexwww pentru ăsta laşi phplib pentru cele comune şi poţi face un third party dir pentru scule gen ADODB. Dar dacă ai biblioteci de funcţii specializate pe dex sau pe flex unde le pui? Faci subdirectoarele dex şi flex în phplib? :-/
    • CătălinFrâncu 20 decembrie 2006 13:59 (PST) Ce să zic, n-ar fi rău, dar sincer nu mi-aş bate capul cu asta acum. Cele două module sunt interdependente (de exemplu, flex/ depinde de restul DEXului pentru că formele flexionare se ataşează de cuvinte din tabela Word).
  • trebuie să vorbim şi despre integrarea cu tabelele deja existente. De exemplu, lexems pare să se refere la tabela (prost-numită) Concept. Nu ar fi mai bine să ne legăm cumva de tabela Word? Diferenţa este că pot exista mai multe cuvinte pentru un concept.
    • -- RaduBorza 13 decembrie 2006 09:18 (PST) dacă facem cele două entităţi independente, se pot lega oricum, cel puţin aşa mi se pare.