Ragazzi, mi spiace ma io non ho abbastanza tempo da dedicare al progetto vista la tesi, il mio lavoro (10 ore al giorno) e i miei siti da portare avanti.

Di sicuro seguirò l'evolversi e se potrò darò una mano.

In culo al lupo (o si dice in bocca alla balena? :bho: )

Ciao ciao!

@LowLevel said:

Il crawling può attendere, all'inizio i documenti da indicizzare magari glieli fate trovare in una directory o in un database.

Si, credo sia la soluzione migliore.

Per database di documenti usiamo pure tutti i documenti di Gt.it, poi possiamo farci cosa ci pare. Lo mettiamo anche a disposizione degli utenti per vedere come si comportano.

@LowLevel said:

Un piccolo motore che usa i term vector, il calcolo della similarità col coseno ed una semplice attribuzione di pesi con un generico tf*idf, sarebbe un buon punto di partenza.

Premetto che devo studiare molto e sto già leggendo moltissimo, dobbiamo identificare delle zone dei documenti da dividere in più parti?

La prima cosa da studiare non è come è melgio organizzare i dati nel nostro database?

@Mamilu said:

Si parlava ad esempio in questi giorni di realizzare un qualcosa, un robottino da mettere sul ForumGT col quale fosse possibile dialogare, capace insomma di rispondere a query dirette degli utenti con il nostro FAQ-Glossario già esistente e debitamente sviluppato.

Questo è un bellissimo progetto, il robotino semanticamente "intelligente".
Con il Vector model non dovrebbe essere difficile da creare ed inoltre poi possiamo riempirlo di domande e immagazzinare i passi dell'utente per fornire risposte sempre migliori.

Si, credo che questi due progetti ci possano aiutare a capire meglio i motori di ricerca.

Che il nostro obiettivo è quello

Per fare un crawler che analizza i file di una directory o uno che li prende dal web dal punto di vista della programmazione i tempi sono gli stessi, quindi io partirei direttamente ad usare i socket !

@Giorgiotave said:

La prima cosa da studiare non è come è melgio organizzare i dati nel nostro database?

la prima cosa è progettare un DB adeguato e preparare un minimo di analisi per giustificare/confermare le scelte della progettazione del DB

l'analisi del progetto è fondamentale, partire in fretta o con il piede sbagliato moltiplica le fatiche di sviluppo successivamente

Io stavo già facendo delle prove per conto mio con OpenWebSpider...qualche tempo fa poi ho smesso, ma ora riprendo più che volentieri...
Stavo pensando di lanciarlo su GT e poi postare qui un dump del db (MySQL). Può essere utile come base su cui lavorare?
Essendo OpenSource è anche modificabile a piacimento...

mh...chi ha 5 minuti dovrebbe stilare una serie di regole antispam.
questo permette di detrarre dal peso di una pagina il punteggio....

Beh su quello non è difficile, io ho 1000 parametri da consigliare !

Io come suggerito, ma era gia' quello che volevo fare, parto dalla fine

Analisi del testo:

• rimozioni dei termini non significativi confrontandoli con una lista:

• rimozione dei suffissi o stemming: permette di risalire alla radice di una parola. Permettendo di analizzare in maniera più semplice, attribuendo un significato comune, molti termini ottenuti dalla stessa radice, ad esempio elimina la distinzione tra singolari e plurali.

• consultazione di un database di sinonimi

• individuazione dei termini significativi: la tecnica più usata e' quella basata sulla frequenza con cui una key compare.
  A tal proposito si indica con TF (term frequency) la frequenza di tali parole nel testo. Si stabilisce un numero massimo di volte che puo' essere ripetuta una key. Le key ripetute più volte rispetto a tale valore limite tendono ad assumere significati diversi.
  Con IDF si indica del raporto il numero tatale di documenti e il numero di documenti contenenti la key (espresso in logaritmo). I termini comuni a molti documenti hanno un IDF basso.

• assegnazione di un peso a questi termini in base a dei criteri da stabilire.

• rappresentazione delle informazioni mediate opportune corrispondenze

Ora ci poniamo il problema di confrontare una query di un utente e restituire un risultato valido.
Cioe' la query deve essere rappresentata in maniera omogenea a quella usata per immagazinare le informazioni e confrontata con in dati disponibili.

Definiamo alcuni concetti:
Recall e' il rapporto tra il numero di documenti rilevanti individuati e il numero totale di quelli rilevanti effettivi.
Precision e' il rapporto tra il numero di documenti rilevanti individuati e il numero totale di documente individuati.

Un buon sistema di IR (detto anche IRS) deve massimizzare Recall e Precision.

Ci sono diversi modi per effettuare il confronto tra la query e il documento e vederne il grado di similitudine:

• Booleano
• Fuzzy
• Vettoriale
• Cluster

Nel modello spazio vettoriale sia la query che il
documento sono rappresentati come vettori in uno
spazio n-dimensionale:
Di = (di1 di2 ... din)
Qj = (q j1 qj2 ... qjn)

dove dik e qjk: i valori del termine k nel
documento Di e nella query Qj.
I valori di un termine possono essere semplicemente
0 o 1 per indicare la sua presenza/assenza nel
documento/query
Oppure possono rappresentare il peso del termine nel
documento o la query.

Ora si pone il problema di confrontare i due vettori.

[alla prossima puntata... ;)]

Quindi come minimo dobbiamo avere anche un DB di parole da eliminare (termini non significativi), un DB di sinonimi, e un sistema per fare stemming...

Il primo possiamo farlo, il secondo possiamo trovarlo, l'ultimo dobbiamo pensarlo.

Secondo me le prime cose da fare sono:

1)Costruire un DB che contenga i documenti integrali e gli assegni un ID univoco.

2)Costruire un DB (lista inversa) che contenga l'elenco dei termini estratti dal primo DB escludendo quelli meno significativi (le stop word, i più frequenti ed i meno frequenti) e memorizzi per ognuno di questi in quale documento siano contenuti, quante volte, in quali tag e con quale prominenza. Inoltre memorizzi quante volte il termine è presente nell'intero indice.

3)Costruire un DB (database dei vettori di termini) che contenga l'elenco dei documenti e per ognuno di questi memorizzi il vettore degli x termini con maggior peso (TF/IDF) contenuti, il numero di volte in cui appaiono e la lunghezza del documento.

Queste sono le tre strutture fondamentali che permettono di identificare i documenti rilevanti per una query (2) e di confrontarne i vettori di termini con quelli della query o della query espansa (3).

ottimo beke...
noto che dalle parole siamo passati ai fatti.

il nodo principale è dare un peso alle parole nelle pagine, quindi detrarre al peso dei valori che definiscono la pagina "poco genuina" (es. spam).

data la ricerca il termine ORDER BY nella query sql darà i suoi frutti.

Per il peso Low fa riferimento al coseno...questa cosa è da chiarire (valore minimo=0, valore masimo=1).

@Stealth said:

il nodo principale è dare un peso alle parole nelle pagine, quindi detrarre al peso dei valori che definiscono la pagina "poco genuina" (es. spam). Data la ricerca il termine ORDER BY nella query sql darà i suoi frutti.Personalmente agli algoritmi antispam penserei dopo, mi sembra più importante iniziare da un buon modulo di ordinamento basato sul confronto fra i vettori di termini. In ogni caso a mio modo di vedere si tratta di assegnare diversi tipi di punteggi a ciascun documento, ognuno dei quali proveniente da moduli diversi (alcuni "query sensitive", altri no) e poi usarli per computare il punteggio finale che ordinerà le pagine.

Per esempio PunteggioFinale= (M x PunteggioIR) + (N x PunteggioTrust) + (P x PunteggioLP) ecc.

@Stealth said:

Per il peso Low fa riferimento al coseno...questa cosa è da chiarire (valore minimo=0, valore masimo=1).Non c'è moltissimo da chiarire. Una volta che hai il vettore di termini di un documento, hai espanso la query e hai ottenuto il suo vettore di termini confronti gli angoli dei due vettori attraverso il loro coseno che, come hai fatto notare, ha la simpatica proprietà di avere sempre valori compresi fra 0 ed 1.

L'espansione della query è importante perchè nel web le query sono spesso di uno, due o tre termini e sono quindi ambigue. Per poter fare un confronto efficiente fra i vettori di termini la query va espansa. Un sistema per farlo è quello di prendere i documenti "top ranked" per la query e sommarne i testi, scremandoli dai termini poco utili per ottenere la query espansa.

Credo che per molti di voi ( me per primo ) ci siano dei problemi per tradurre dall'inglese la grossa mole d'informazioni trovate in rete riguardanti l'argomento che già difficile e ostico di "suo".

Personalmente ho fatto una ricerca per ** tf*idf** richiedendo solo le pagine in italiano e ho trovato parecchio materiale.

Vi consiglio di provare...

Consiglio mio:
oltre che dare un id univoco alle pagine dategli un md5 e la data di spiderizzazione.

Almeno è facile capire se è stata aggiornata ecc..

indubbiamente ci sono una serie di proprietà (campi in tabella) da attribuire a un documento,

valutiamo insieme

Aggiornato ? Si ! in che modo ?

C'è a mio avviso aggiornare e aggiornare... limitarsi al log dell'ftp non è corretto... anche se i motori sembrerebbero farlo.

Sarebbe interessante trovare un valido sistema per verificare la qualità degli aggiornamenti, sgamare gli autoaggiornamenti e bla bla bla...

limitarsi al log dell'ftp non è corretto... anche se i motori sembrerebbero farlo.

Non so chi ti abbia detto questa cosa ma è totalmente improponibile.
I log dell'ftp NON sono accessibili da un motore di ricerca, come fa dunque a leggerli ?

I motori di ricerca hanno le toolbar.

Per quanto riguarda il discorso del vedere di che tipo di aggiornamento si tratta basta creare un algoritmo che analizza per mettiamo 15 giorni una pagina, vede le modifiche che sono state fatte ai testi, e se sono superiori ad una certa percentuale allora lo ritiene aggiornamento.

Nel database poi si segna un numero (magari per facilitare le cose si normalizza tutto fra 0 e 1) che determina la periodicità degli aggiornamenti (cioè ogni quanto deve passare il bot).

Chiedo venia per aver scritto senza pensare di ricercare la giusta terminologia per esprimere il concetto.

Cerco di farlo utilizzando un linguaggio semplice... che più semplice non si può...

Se tutti giorni ricarichi con ftp una pagina senza variare una virgola, questo semplice passaggio, fa sembrare la pagina aggiornata, anche se in realtà non lo è !

E' vero in parte, perchè aggiornando via ftp viene dato un status 2xx invece che 304 (not modified), però dal punto di vista delle risorse, in ambedue i casi la pagina ti viene spedita (quindi per analizzarla ci vuole qualche millisecondo..).

Inoltre ho un sito che ha 35 pagine non modificate da decenni, che restituiscono un bel 304, e google prontamente le aggiorna di continuo.

Immagino per via del loro valore, quindi non credo che sia vero quel che dici.

Io presumo che sia più reale un controllo da parte della Google Toolbar, infatti casualmente mi è capitato con più di un sito che fa diversi accessi dai motori di ricerca, due giorni dopo che aggiornavo la pagina passava google bot che magari non passava da un mese.

Quando hai un dubbio..

ho trovato in rete questo documento:
http://roquefort.di.unipi.it/~ferrax/Teach/Recdoc_IU/Lezione7e8_IU_2005.pdf

sono diapositive riassuntive di ciò che noi dovremmo analizzare.