A breve cominceranno a girare i primi scraper, che produrranno un buon numero di feed esposti. Sarebbe utile fin da subito una soluzione che li aggreghi tutti ed esponga un solo feed completo. Magari che vada a prendersi l’elenco dei feed dalla Lista delle fonti e degli scraper e faccia tutto da solo (il che molto probabilmente escluderebbe servizi terzi). Idee? Candidature? 
Aggregatore dei feed degli albi
jenkin
#1
Aggiungo una esigenza, uno strumento ulteriore che permetta una classificazione degli elementi del feed tramite tagging ed aggiunta di annotazioni.
Lo scopo è segnalare un elemento, es. ordinanza di demolizione, che deve essere analizzato leggendo gli allegati e da cui vanno estratte entità, in questa fase manualmente.
jenkin
#3
Ci ho ragionato, purtroppo non ha molto senso farlo, non funzionerebbe come atteso… solitamente un feed ha una lunghezza fissa (es. 25 elementi) e quando viene aggiornato se ne aggiungono alcuni nuovi e se ne eliminano altrettanti più vecchi. La scelta della lunghezza del feed è importante: se l’aggiorno ogni ora e ogni ora ci sono 30 nuovi elementi, 5 si perdono sistematicamente e non sono accessibili ai sottoscrittori. Quindi quel 25 va scelto in base alla frequenza di aggiornamento del feed, alla frequenza supposta o consigliata di verifica dei sottoscrittori e al numero di nuovi elementi a ogni aggiornamento.
Se però ho N feed e ogni volta che li controllo questi hanno in media M nuovi elementi complessivi ognuno, in media avrò NxM nuovi elementi del feed aggregato. Con N ~ 100 vuol dire centinaia di nuovi elementi, quindi esporre un feed aggregato con un migliaio di elementi, troppi. A meno che non si imposti un aggiornamento molto frequente, nell’ordine dei minuti, sia per l’aggregatore che per i sottoscrittori. Anche questo difficilmente fattibile.
Se non ci sono idee migliori, questo mi pare bocci del tutto l’idea di un aggregatore così descritto. Dobbiamo rimandarlo a quando avremo un database vero in cui ci sarà tutto e sarà possibile fare query. Tra l’altro se il sottoscrittore aggiunge una chiave univoca all’indirizzo del feed aggregato, gli si può rispondere con i soli elementi nuovi dall’ultima visita, avendo memorizzato lato server il timestamp associato a quella chiave. Non sarebbe ancora una modalità push, ma avrebbe funzionalità simili (ogni volta che chiedo ottengo solo le novità rispetto alla volta precedente) e sarebbe compatibile con qualsiasi aggregatore di feed già in uso.
jenkin
#4
Questo è un discorso che esula dalla questione dell’aggregazione… si tratta di un task asincrono (prima raccolgo gli elementi nuovi dai feed, li memorizzo e poi in un secondo momento eventualmente li aggiorno con le nuove informazioni) che è possibile affrontare solo quando avremo un database.
@jenkin ho compreso la questione, per il momento pensiamo ad un semplice aggregatore, appena completo il flusso dei feed dovremo pensare all’archiviazione del feed in un db all’archiviazione degli allegati (DB, filesystem?) e poi ad uno strumento per fare questo tramite DB.
@jenkin concordo
vorrei (x il futuro … ) aggiungere una idea/proposta: database presente e un formato unico, si potrebbe creare collezioni di feed items, una sorta di taglia/cuci da vari fonti, x un workflow tematico;
jenkin
#7
Non sono sicuro di aver capito… una volta che il flusso di informazioni dai feed monitorati finisce nel db (con una struttura uniforme, come da specifiche di albopop), da lì si possono fare tutte le query che vuoi, perché a quel punto la fonte di un documento è solo un suo attributo, non una scatola.
Quindi per esempio puoi esporre un feed con documenti che corrispondono a questa query: “i documenti dei comuni del cratere ma della sola regione marche che contengono le parole affidamento e incarico”. Naturalmente meglio sono strutturate le informazioni a monte, meglio puoi strutturare le query. Una volta che hai questo, puoi predefinire una serie di feed tematici e proporli pubblicamente.
Intendevi una cosa così?
@jenkin hai perfettamente ragione rispetto ai query e i feed tematici
pensavo a una cosa più o meno cosi:
ho un interfaccia che mi permette di fare i query e sono un ‘user’ , quando ho trovato qualcosa che mi interessa, lo posso aggiungere ad una delle mie collezioni; poi lavoro sulla collezione per un indagine; un po’ simile a ‘read it later’ o bookmarking;
jenkin
#9
Chiaro, capito, bello! Però mi sa che richiede una gestione delle utenze (account, autenticazione, ecc.), cosa decisamente non fattibile. La soluzione più semplice mi sembra assicurare che ogni singolo elemento nella nostra piattaforma abbia un url univoco associato. Dal punto di vista dell’utente quello che proponi si riduce alla semplice gestione di un archivio di url, quindi qualsiasi strumento di bookmarking funziona, dai preferiti del browser a pocket.
giovannipolimeni
#10
Se la gestione di utenti non è contemplata, allora forse si potrebbe usare il Local Storage del browser? Quantomeno finché l’utente non svuota la cache del browser, avrà a disposizione quei dati salvati precedentemente.
guenter.richter
#11
@jenkin ok, d’accordo; mi piace il concetto del url
@giovannipolimeni ho pensato anch’io al Loca Storage che ho usato già per il bookmarking delle mappe e anche per collezioni; purtroppo la mia applicazione si era bloccata ogni tanto;
in teoria ci sarebbe anche un altra possibilità: creare file JSON via file api del browser nel disco locale (quasi un dump della ricerca) e caricarli quando servono (viewer); sulla falsa riga di Open Refine
jenkin
#12
Lavoro iniziato, qui il repo: https://github.com/RicostruzioneTrasparente/albopop-feed-indexer.