internet.pro

RSS: arriva l'aggregatore con il brand

Più o meno nello stesso giorno, il Guardian e il Los Angeles Times hanno annunciato il lancio di un aggregatore RSS da offrire ai propri lettori. L'applicazione si chiama NewsPoint ed è sviluppata da Consenda, una startup svizzero-americana che opera esclusivamente con partner commerciali provenienti dal settore dei media. Al momento l'aggregatore (in versione beta) è stato distribuito con la formula dell'invito ad un ristretto gruppo di utenti.

Fin qui la notizia. Ora le domande: non era abbastanza ampia un'offerta che, stando ai dati pubblicati dai responsabili di Feedburner, ammonterebbe ad oltre 400 client (tra applicazioni web e desktop)? C'era davvero bisogno di un altro feed reader? La risposta sarebbe un no secco e istintivo se stessimo parlando di un aggregatore come gli altri. Oppure se il punto di vista fosse quello dell'utente avanzato e ormai avvezzo al consumo quotidiano di RSS. In realtà, NewsPoint non è un aggregatore come gli altri. E per comprenderne le peculiarità, faremmo bene a sentire prima d'ogni cosa la voce di chi ha voluto l'esperimento.

NewsPoint è un feed reader 'brandizzato'. Non esiste, cioè, come applicazione generica. C'è il Guardian Unlimited NewsPoint e il Los Angeles Times NewsPoint. Magari un giorno vedremo il Reuters NewsPoint o il Repubblica NewsPoint. Si installa come programma stand-alone (solo su Windows XP), collegato al browser solo per la lettura degli articoli completi. Cosa l'utente ci trova dentro lo decide l'editore che commissiona il lavoro a Consenda. La versione del Guardian contiene tutti i feed pubblicati dalla testata inglese e, ovviamente, feed pubblicitari. Quella del LAT, invece, è centrata sulla distribuzione tramite RSS di inserzioni di lavoro o immobiliari: l'utente può creare feed personalizzati e tagliati sulle proprie esigenze, con un meccansimo simile alle watchlist di Technorati. Il sistema non è comunque chiuso: si possono aggiungere senza problemi feed di altre fonti, anche se mi sembra che l'interfaccia a tutto si presti meno che alla gestione di un numero elevato di sottoscrizioni.

Sul lancio dell'iniziativa, Editorsweblog ha sentito Simon Waldman, il responsabile delle attività online del Guardian. È un'intervista molto interessante. Ne distillo i punti più significativi:

1. Newspoint è solo un tassello della nostra strategia intorno a RSS.
2. Non guardiamo solo a RSS. Ciò che ci interessa soprattutto è quel concetto di internet decentralizzata e distribuita con cui presto tutti gli editori dovranno confrontarsi.
3. Vogliamo portare più gente ad usare RSS. E per conquistare l'utente medio crediamo che il modo migliore sia fare leva sulla relazione di fiducia verso il nostro brand.
4. Con un'applicazione come NewsPoint abbiamo più controllo sulle modalità di fruizione di RSS. Molto più di quanto sia possibile con altri aggregatori.
5. È normale consentire l'aggiunta di altre fonti: se vuoi un controllo rigido sul consumo dei tuoi contenuti, non offri feed RSS.
6. I feed rappresentano al momento, per il Guardian, una piccola ma crescente fonte di traffico.
7. Stiamo entrando in una fase in cui l'accesso ai nostri contenuti avverrà sempre di più tramite RSS, aggregatori, blog e motori di ricerca. Più impariamo e sperimentiamo ora, più saremo pronti domani.

Dalle parole di Waldman sembrano emergere due esigenze. Prima: semplificare la vita degli utenti, aiutarli a fare il salto. Oggi, tutte le edizioni online di giornali e magazine che offrono feed RSS, hanno la loro bella paginetta con le istruzioni d'uso. In genere, alla premessa 'teorica' (cosa sono i feed, a cosa servono), fa seguito un processo a 3 fasi: scarica un aggregatore, sottoscrivi i feed, leggili come e quando vuoi. Per chi non è proprio un esperto, i punti critici di questo percorso, quelli che possono farti recedere e rimandare ad un'occasione migliore, sono più di uno. Con un NewsPoint, invece, il discorso avrebbe probabilmente questo tono: "Caro e affezionato Lettore, vuoi seguire facilmente le nostre news? Scarica il nostro programmino (guarda, ci abbiamo messo pure la testatina che ti piace tanto), è facile facile, pronto all'uso...". Insomma, se sei bravo e hai tempo le lasagnette al pesto te le puoi fare da solo. Sennò ci sono sempre i Quattro salti in padella....

Poi c'è la storia del 'controllo'. Sono troppo malizioso se penso che parlando di 'controllo' si parli essenzialmente di pubblicità? Leggendo le parole di Waldman mi sono ricordato di questo post di Mauro Lupi, ma anche di questo articolo di Martina Zavagno. Scrive Lupi:

Ovviamente, appena inizia a diffondersi un canale di comunicazione, si scatenano i pubblicitari per cercare di utilizzarlo (bisogna pur campare... ). È successo con tutti i media, internet compreso, per cui ritengo che a breve troveremo spazi pubblicitari anche sui feed RSS.
Tuttavia, l'advertising sui feed ha ancora qualche problema tecnico, primo su tutti la difficoltà ad identificare in modo preciso il numero di contatti, ossia quanti lettori effettivamente leggono le informazioni elaborate con questo formato.

Ribadisce Martina:

Il primo dei problemi che si pone con l’RSS è che non si può misurare con precisione quante persone effettivamente hanno ricevuto il feed. Ovvero, non si può sapere quanti utenti, e con quale frequenza, scaricano le informazioni pubblicate nel feed.

Compresa la pubblicità, aggiungo io. Ora, Steve Yelvington, che parla dell'esperimento del Guardian su Poynter (e che ha evidentemente provato il programma) mi informa che NewsPoint richiede un'autenticazione con username e password (presumo quindi che ci sia bisogno di una sorta registrazione). La conclusione è che un tool di questo tipo consente a editori e inserzionisti di superare, in buona parte, i 'problemi tecnici' cui si accennava. La strategia, mi pare, è molto diversa da altri approcci, soprattutto da quelli che prevedono l'inserimento di advertising nel feed, indiscriminatamente, per tutti. In pratica, il Guardian la pubblicità la mette nell'aggregatore, nel suo: "Non ti piace? Usa il tuo programma preferito". È diverso da "Non ti piace? Smetti di leggere i miei feed", no? L'esperimento va comunque seguito. Secondo me, però, di questi aggregatori con il brand ne vedremo sempre di più. Il rischio? Superata la tentazione del walled garden, potrebbe nascerne uno di segno diverso. Vi lascio con le parole di Mitch Ratcliff: "The branded newsreader argument and analogous 'My' services represent the portalization of an otherwise distributed medium".

Amazon Web Services

"Pronto, Amazon? Sono in libreria. Vorrei sapere quanto costa da voi questo volume. E già che ci siamo, potreste dirmi anche cosa ne pensano i vostri utenti?". OK, non avviene esattamente così, non c'è in realtà una conversazione, a rispondere non è una gentile operatrice della più grande libreria online del mondo, ma la voce anonima che sta a dietro ad Amabuddy. Provare è facile e costa quanto una telefonata di un minuto verso gli Stati Uniti. Il numero: 001 617 712 3574. Vi verrà chiesto di inserire il codice ISBN del libro che vi interessa (o quello UPC di un CD musicale): questione di secondi e Amabuddy vi darà tutte le notizie che cercate. Se volete risparmiare un paio di euro, fidatevi: funziona.

Cosa facciamo esattamente usando questo servizio? Interroghiamo Amazon dal nostro cellulare. Siamo in grado di compiere da un dispositivo mobile la stessa operazione che faremmo stando davanti a un PC. Niente form da riempire o navigazione tra link, però, e invece di una pagina con testo e immagini, la risposta arriva sotto forma di voce. Gli ingredienti? VoiceXML, MySQL, Apache, Python e soprattutto i Web Services di Amazon. Ecco, un servizio come Amabuddy rende perfettamente l'idea di cosa si possa fare con la piattaforma di sviluppo che la società fondata da Jeff Bezos ha da tempo messo a disposizione di chiunque voglia interagire con i suoi numerosi servizi. Proprio in questi giorni si è conclusa a Seattle la Amazon Developer Conference, occasione in cui è stata annunciata la disponibilità dei servizi per l'e-commerce anche per gli store di Francia e Canada. La cronaca dell'evento è riassunta in una serie di post su AWS Blog. Scorrendo gli archivi, possiamo anche scoprire una serie di applicazioni molto interessanti.

Per prima cosa, però, lasciamo che a spiegare meglio il concetto di Web Service sia la stessa Amazon. Cito e traduco dal sito: "I Web Services di Amazon (AWS) forniscono agli sviluppatori di software un accesso diretto alla piattaforma tecnologica e ai dati sui prodotti di Amazon. Gli sviluppatori sono così in grado di innovare e creare nuove forme di business con siti e applicazioni web dinamiche e altamente efficienti". Dal momento che tutto è tenuto insieme da quella sorta di lingua franca che è XML, non c'è praticamente alcuna barriera d'ingresso relativamente alla piattaforma o al linguaggio di sviluppo. Esistono applicazioni ed esempi in PHP, Java, .Net, Perl, Python, anche in ASP classico. Le funzioni accessibili non si limitano alla ricerca di prodotti, ma si estendono all'utilizzo dello shopping cart e persino al controllo sullo stato dell'ordine. In breve: è possibile creare una 'piccola Amazon' (o una Amazon Light) perfettamente funzionante, anche arricchita di tool che la 'Amazon grande' non mette a disposizione.

Si può facilmente intuire che i Web Services siano perfetti come supporto al sistema di affiliazioni commerciali della società e che possano generare un circolo virtuoso in cui tutti hanno qualcosa da guadagnare. Il signor Barb Henry può così realizzare in pochi minuti lo store da cui vende e promuove articoli scontati di Amazon grazie a Instant Associates Store, un software da $64 prodotto da GMP Services che mette in mano a chi programmatore non è le chiavi per accedere alla potenza e alle funzionalità degli AWS.

Allo stesso modo, TrufSoft può offrire (gratuitamente) Calillona, un'applicazione desktop per Mac OS X che consente di accedere ad Amazon senza browser. E l'inglese Inside Consultancy può sperimentare il suo InsideMessenger, un sistema per interrogare il catalogo tramite MSN Messenger. ACS, invece, è specializzata nello sviluppo di chatbots, "applicazioni web che consentono di dialogare con gli utenti di un sito in forma di chat testuale o vocale". Provate a chiedere ad Halo 'Who wrote Divina Commedia' e indovinate come fa a sapere la risposta....

Che dire, infine, di Delicious Monster? È un programmino che farebbe la gioia di tutti quelli che almeno una volta nella vita hanno provato a costruirsi un archivio dei CD, libri o DVD che tengono in casa. Una fatica frustrante come poche, spesso lasciata incompiuta davanti alla prospettiva di dover riempire a mano centinaia di campi con titolo, autore, casa editrice, anno di pubblicazione.... E invece, avendo un Mac con iSight (la web video-camera della casa di Cupertino), tutto diventa un gioco. Si prende la telecamerina, la si usa come un lettore di codice a barre, Delicious legge l'indicazione del codice (ISBN o UPC), passa i dati ad Amazon che proprio quei codici usa per identificare i suoi prodotti e recupera la risposta del server. Il programma, insomma, sfrutta i Web Services per ricevere tutti i dati necessari all'archiviazione, compresa l'immagine della copertina che rende così bella la vista dello 'scaffale digitale' di Delicious.

Link:

Amazon Web Services: il punto di partenza per accedere a documentazione, esempi e risorse.

AWS FAQs: sempre utili.

AWS Blog: poteva mancare? Notizie, aggiornamenti, cronache dalle conferenze, segnalazioni delle ultime applicazioni.

Usi dei dati EXIF: Flickr e WWMX

Non starò qui a tessere le lodi di Flickr, tutto quello che direi sarebbe un misto di entusiasmo e ammirazione sconfinata. Me la caverò con un 'bravi!'. Bravi, signori di Ludicorp, anche quando a dicembre vi siete finalmente decisi a sfruttare a dovere i dati EXIF che vi arrivano con le nostre foto. Finalmente ho potuto avere una vista del mio archivio basata sulla data in cui la foto è stata scattata. Suvvia, aveva davvero un senso quell'ordinamento basato solo sulla data di upload?

Che da quelle parti si archiviassero i dati EXIF, si sapeva da un pezzo. Sotto le prime immagini che ho inserito, appariva chiaro: "Taken with a Canon Powershot G2". Mi sono detto: se sanno che macchina ho usato, sanno pure quando ho fatto le foto. Perché non usano quel dato? In fin dei conti, tra le informazioni EXIF, è una delle poche davvero significative in contesti come Flickr. Che con l'introduzione di questo parametro ha per certi versi chiuso il cerchio (o quasi). Ora è possibile presentare le nostre foto in base a tutti e quattro i fattori che in genere usiamo per organizzarle, anche mentalmente: un evento, il soggetto, il luogo, il tempo. Per i primi tre abbiamo a disposizione i tag, per l'ultimo sfruttiamo il campo EXIF Date/Time Original che la macchina digitale 'scrive' nell'intestazione del file JPEG. E allora perché quel 'quasi'? Perché per definire il luogo in cui una foto è stata scattata, potremmo contare su un sistema molto più accurato rispetto alle indicazioni generiche contenute in un tag testuale.

Oltre ai campi relativi ai dati più tecnici (distanza focale, uso del flash, apertura, etc.), la specifica EXIF prevede la presenza di due dati relativi alla localizzazione: longitudine e latitudine espresse in forma di coordinate GPS. Ora immaginiamo uno scenario. Le macchine digitali sono munite di un ricevitore GPS, quando scattiamo inseriscono anche le coordinate geografiche, mettiamo le foto su Flickr. I signori di Ludicorp hanno dunque altri metadati su cui lavorare: ci presentano le foto anche su mappe. Ecco Roma. La cartina è piena di pallini rossi o minuscole thumbnail. Zoom sull'area di Piazza Navona: automagicamente (grazie ai dati EXIF su latitudine e longitudine) posso visualizzare tutte le foto scattate in quel luogo.

Non so davvero se su Flickr vedremo mai una cosa del genere (anche se qualcuno ci prova, sfruttando dall'esterno le API e i dati del servizio). I modelli (pochi) di macchina digitale con ricevitore GPS sono confinati al segmento ultra professionale, non è roba amatoriale. L'alternativa è quella di inserire le coordinate manualmente. Si può fare, ci sono programmi e metodi ormai sperimentati. Ma è chiaramente un processo lungo e noioso. Il problema, insomma, è quello identificato da Cory Doctorow in un articolo diventato celebre: la pigrizia come ostacolo primario per la realizzazione di un ambiente informativo basato su metadati accurati e utilizzabili con profitto.

Eppure, lo scenario tracciato qui sopra, non è utopia. Sono tante le applicazioni fondate sulla geolocalizzazione delle immagini. La maggior parte, però, non ha nulla della semplicità d'uso e degli aspetti ludico-sociali di Flickr. Il progetto migliore è forse il World Wide Media Exchange realizzato nei laboratori di ricerca Microsoft. Il sito è ricco di link e documentazione utili all'approfondimento (segnala anche applicazioni alternative). È presente anche una demo che simula sul web il funzionamento del sistema. In realtà, si tratta di un insieme di applicazioni desktop che richiedono l'installazione del framework .Net 1.1.

Il WWMX Client consente la gestione del proprio account e l'aggiunta di immagini, ma soprattutto di navigare tra le foto degli altri utenti a partire dalle mappe che importa dal Web Service di Microsoft MapPoint. Grazie al Location Stamper, è invece possibile aggiungere ad un file JPEG i dati GPS: importandoli da un ricevitore o con un drag and drop della foto sul punto dello scatto che avremo individuato sulla mappa. Con il Travelogue, infine, possiamo creare diari di viaggio sotto forma di pagine web complete di mappe, percorsi e visualizzazione delle foto scattate nei vari punti di interesse. Tutto ben fatto e gratuito, anche se il Client è un'applicazione decisamente 'pesante' per PC poco performanti e con connessioni lente. Un lungo e approfondito paper apparso originariamente su ACM Digital Library, è la lettura consigliata a chi voglia approfondire i dettagli del progetto [PDF, 2,9Mb].

La video-ricerca che verrà

Secondo Steve Outing i giorni dello tsunami hanno segnato un punto di svolta per il cosiddetto citizen journalism. Soprattutto nella prima fase, quando le TV di mezzo mondo non erano ancora presenti in quei luoghi, la presenza massiccia di videocamere e fotocamere digitali ha fatto sì che il materiale di provenienza amatoriale divenisse quello più diffuso, ricercato, l'unico davvero in grado di restituirci il senso di quanto era accaduto.

Quando questo materiale ha iniziato a circolare sul Web, si è immediatamente manifestato il problema di poterlo cercare e individuare con sistemi efficaci. Un senso di frustrazione ben evidenziato in questo post di Andy Baio su Waxy.org. Il problema, insomma, è quello per cui Yahoo! ha iniziato la sperimentazione di Media RSS di cui si parlava un paio di settimana fa. Come accennavo alla fine di quell'intervento, la via che porterà alla nascita di un Google per il multimedia è ancora lunga, ma non è difficile individuare tendenze e tecnologie emergenti.

Un primo approccio è quello che sfrutta come base della ricerca il testo contenuto in un documento video (o audio). La difficoltà maggiore consiste nel riuscire ad 'estrarre' il testo stesso così da poterlo indicizzare convenientemente. I modi per superarla sono essenzialmente due. Il primo sfrutta i cosiddetti closed caption. Si tratta delle didascalie criptate incluse nella traccia di molti video, usate soprattutto come ausilio per i non udenti (sì, sono quelle della pagina 777 del Televideo). Il secondo sistema, invece, utilizza tecniche di riconoscimento vocale e trascrizione automatica del testo. Su questo metodo sono basati Speechbot e Blinkx.tv.

Speechbot è un motore di ricerca per documenti audio creato nei laboratori di ricerca di HP. Registra quotidianamente una ventina di programmi radiofonici americani, effettua una trascrizione 'al volo' del parlato, indicizza il tutto, ed ecco pronto il motore. La cosa più interessante è osservare il modo in cui sono presentati i risultati. Nell'immagine, i punti in viola rappresentano i segmenti della trasmissione in cui è stata pronunciata la keyword usata nella ricerca. Nel box sottostante la parola viene evidenziata all'interno del contesto in cui è stata usata. È possibile, ovviamente, ascoltare il frammento selezionato o l'intera trasmissione.

Quello che Speechbot fa con l'audio, Blinkx.tv lo fa con i video. Indicizza filmati dei principali network e canali televisivi in lingua inglese usando un sofisticato sistema di cattura e riconoscimento vocale e abbinandolo ad un'analisi accurata del contesto in grado di fornire sempre risultati rilevanti. Da leggere, per approfondire, il white paper di presentazione [PDF, 368kb].

Si intuisce facilmente che sistemi di questo tipo si prestano perfettamente per contenuti multimediali centrati sull'informazione, in cui l'elemento cruciale continua ad essere il testo. Mi aiutano a trovare un filmato in cui si è parlato di una cosa, ma non mi aiutano se voglio raffinare la ricerca in base ad altri criteri, per esempio se la parola 'tsunami' l'ha pronunciata l'anchorman di un TG seduto sulla sua comoda poltrona o una vittima del disastro che si aggira tra le macerie. Senza dire che non mi sono affatto utili con video, come quelli amatoriali della catastrofe asiatica, in cui il testo non ha alcuna rilevanza.

In buona sostanza, l'ideale sarebbe un motore in grado di sfruttare la natura multidimensionale di un video, un motore in grado di usare una logica combinatoria che abbracci tutti i possibili parametri applicabili al formato. In questo ambito, il progetto più noto è forse il MARVel di IBM. Attualmente lo si può apprezzare solo con un paio di demo, non particolarmente user friendly, ma sufficienti per farsi un'idea.

Si può navigare e ricercare tra i filmati presentati in base a un numero enorme di criteri: annotazioni e metadati inseriti manualmente, trascrizione del testo, caratteristiche primarie del filmato (è girato in uno studio? all'aperto? è una partita di basket?), filtri per le news (è un telegiornale? è uno spot?), persino in base alle caratteristiche dell'immagine (bianco e nero vs. colore, per esempio), etc. Tutti i criteri possono essere liberamente combinati, per cui è possibile usare query come questa: "Trovami un filmato di uno spot girato in bianco e nero, in cui compare una bicicletta inquadrata dall'alto e in cui il protagonista corre pronunciando la frase 'Ti amo'....".

Tutto splendido? Sono davvero magnifiche le sorti che ci attendono? Tutti gli esempi visti (e le mosse che i colossi della ricerca stanno per intraprendere in questo ambito) si applicano a contenuti provenienti da strutture professionali, editati, con la qualità tecnica necessaria per poter sfruttare a dovere tecniche delicate come il riconoscimento vocale. Ora, per dirne una, se nel processo di 'parificazione' tra media mainstream e weblog, un ruolo cruciale è stato svolto da un motore come Google in grado di premiare in maniera clamorosa i contenuti di questi ultimi, non c'è il rischio, visti questi presupposti tecnici, di tagliare fuori da sistemi siffatti i contenuti amatoriali, non professionali? La vicenda dello tsunami dimostra che non sarebbe un bene.

Yahoo! Media RSS

Nei giorni scorsi Yahoo! ha presentato la versione preliminare di Yahoo! Video Search, un motore per la ricerca di filmati. Niente di rivoluzionario di per sé. Provando il sistema, poi, si ha la netta sensazione di essere ben lontani dalla perfezione, sia in termini di completezza, sia per quel che riguarda la rilevanza dei risultati. Tutto scontato, sempre di una beta si parla.

I primi ad esserne consapevoli sono proprio i creatori del servizio. Al momento, infatti, esso può fare affidamento solo su una delle tre colonne su cui dovrà poggiare nella versione finale: una tecnologia di crawling tradizionale, simile a quella che alimenta motori per la ricerca di immagini come quello della stessa Yahoo! o di Google. Data una keyword, il motore restituisce tra i risultati o filmati in cui essa è presente nel nome del file, o filmati presenti in pagine in cui quella stessa keyword compare come testo rilevante. In questo secondo caso, il risultato è di avere spesso filmati ben poco attinenti con quanto abbiamo cercato.

La seconda colonna portante dovrebbe essere l'inclusione nell'indice di materiale proveniente da fornitori di contenuti, commerciali e non, con cui Yahoo! dovrebbe stringere rapporti di partnership. Una strategia già attuata da anni per altre sezioni del portale come Yahoo! News.

A completare il quadro, il terzo elemento, con cui arriviamo alla seconda novità presentata la scorsa settimana. Proseguendo su una strada già intrapresa con la nuova versione di My Yahoo!, la società di Sunnyvale ha mostrato di credere fortemente nel ruolo di RSS come piattaforma per la distribuzione di contenuti. Il problema è che RSS è nato essenzialmente per il testo. Certo, il podcasting ha fatto scoprire a molti che un feed può essere usato anche per 'trasportare' file audio o video, che esistono le cosiddette enclosures. Ma se l'obiettivo si sposta dalla semplice distribuzione all'indicizzazione dei contenuti multimediali, allora c'è bisogno d'altro.

Ecco dunque Media RSS. Si tratta di un modulo che estende la struttura tradizionale di un feed RSS 2.0 aggiungendo nuovi elementi adatti alla descrizione accurata dei contenuti audio o video. Più metadati, insomma. Facciamo un confronto. Un feed RSS 2.0 con semplice uso di enclosure si presenta più o meno così:

<item>
<title>Conferenza stampa</title>
<link>http://miosito.it/conferenza_stampa.mov</link>
<description>Presentazione alla stampa del nostro prodotto.</description>
<pubDate>Sat, 18 Dec 2004 18:15:00 GMT</pubDate>
<enclosure url="http://miosito.it/conferenza_stampa.mov" type="video/quicktime" length="10917888"/>
</item>

Con gli elementi di Media RSS avremmo questa struttura:

<item>
<title>Conferenza stampa</title>
.............
<media:content url="http://miosito.it/conferenza_stampa.mov" fileSize="10917888" type="video/quicktime" expression="full">
</media:content>
<media:category>video/conferenza stampa</media:category>
<media:text>
P2Pix è il nuovo prodotto della nostra azienda.....
</media:text>
</item>

Gli elementi e gli attributi previsti nella bozza della specifica sono molti. Il semplice schema qui proposto, però, può essere sufficiente a comprendere le potenzialità del sistema. Se si aggiungono altri dati significativi, un motore di ricerca che li indicizzi potrà attingere a questi ultimi per fornire risultati più rilevanti. Si pensi ad un elemento come <media:text>. È riservato, tra l'altro, all'inclusione di una trascrizione del testo del filmato. Mi consentirebbe di effettuare ricerche di video in cui si parla di un certo argomento o in cui viene citato uno specifico prodotto.

Il piano di Yahoo! è proprio quello di usare Media RSS per migliorare la ricerca di file multimediali. Distribuisci audio e video sul web? Fai un feed con Media RSS, arricchiscilo più che puoi di metadati, segnalacelo e sarà incluso nel nostro indice.

Sarà interessante seguire l'evoluzione dell'esperimento. Magari per verificare quando saranno disponibili tool che facilitino la produzione di feed con queste caratteristiche o aggregatori che li supportano.

C'è anche da aspettarsi un'integrazione con modalità di distribuzione emergenti come il podcasting. Mentre il fenomeno cresce e si arricchisce di voci sempre più interessanti, si sta creando una mole di contenuti che per la loro stessa natura (sono documenti audio), sfugge all'occhio dei motori di ricerca. Se si escludono le brevi note di pubblicazione che compaiono sui siti di chi li produce, io non ho modo di sapere di cosa si parla in un podcast, e, in ultima analisi, se vale la pena scaricare un file da 30mb. Non mi aspetto che lo faccia Yahoo!, ma le directory che già oggi indicizzano decine di podcast, potrebbero contare, grazie a Media RSS, su una piattaforma molto più evoluta, in grado di assicurare un servizio migliore. Lo stesso discorso vale per gli aggregatori alla iPodder.

Il fermento intorno alla ricerca di e su file multimediali, non si esaurisce comunque con l'esperimento di Yahoo!. Tra startup e laboratori di ricerca di colossi come IBM e HP, si iniziano a intravedere scorci di futuro davvero interessanti. Ne parleremo nel prossimo appuntamento.