L’applicazione MuseoTorino è stata selezionata sia nella sezione Applicazioni (col Navigatore della collezione del museo) che nella sezione Dataset (con MuseoTorino API).

Un grande esempio di cultura al servizio del cittadino e di come anche in Italia si può innovare, sia nelle tecnologie che nelle idee.

In attesa di conoscere i vincitori, la premiazione a Roma il 19 Maggio presso il ForumPA.

La prima, che rappresenta il primo esempio di utilizzo del dataset di cui sopra, è una RIA sviluppata in linguaggio Adobe Flex che tramite un normale visualizzatore Flash, presente su tutti i desktop browser del mondo (in futuro è prevista una versione mobile della stessa), visualizza la collezione di MuseoTorino in maniera geoposizionale usando GoogleMap : opportuni selettori permettono poi di filtrare il contenuto per temi, categorie, scala temporale oppure eseguire una ricerca basata su una chiave testuale.

Il dataset “MuseoTorino API” è recentemente diventato completamente Open grazie all’adozione della licenza IODL 2.0: è uno dei primi (se non, al momento, l’unico) esempi di Open Data basati su WebService completamente aperti, sia nell’accesso che nella licenza sui dati. Il servizio è basato su tecnologia REST e restituisce i dati in formato JSON, facilmente interpretabile anche da un umano. Un facile accesso per un facile riuso. Che permette a questo dataset di potersi fregiare delle 4 stelle definite dal W3C per gli Open Data.

MuseoTorino e la Città di Torino, diventano una delle prime istituzioni e città ad esporre in maniera aperta il proprio patrimonio culturale e storico a disposizione di coloro che vorranno riusali, integrarli, manipolari, trasformarli. L’uso dei WebService, a differenza di quanto si è soliti trovare nel resto dei dati open, permette di avere la certezza che i dati siano sempre quelli più aggiornati e certificati, grazie anche al fatto che il repository dei dati è quello usato dal sito principale.

Tutto questo potrebbe permettere, per esempio, di riutilizzare i dati in un contesto di portale turistico dove il contenuto di MuseoTorino diventa un canale di approfondimento, il tutto restando all’interno del contesto del portale di partenza.

Immaginate il sito dell’albergo Cavour, una semplice modifica al suo sito permetterebbe, in poco tempo, di creare una sezione “storica” legata al personaggio e a tutte le altre informazioni ad esso collegate.

MuseoTorino è uno splendido esempio di come i soldi della comunità tornano alla comunità stessa, creando valore aggiunto verso coloro che useranno o integreranno questi dati in contesti diversi da quelli in cui sono nati. Ma in questo modo anche MuseoTorino assumerà nuovo valore e importanza, dandogli un motivo per migliorarsi in futuro, giorno dopo giorno, rafforzando (se mai ce ne fosse la necessità) le motivazioni che hanno decretato la sua nascita ed esistenza.

Uno dei prossimi obbiettivi, per esempio, sarà quello di realizzare e quindi implementare le regole che permetteranno ai dati di MuseoTorino di potersi fregiare delle 5 stelle, ovvero di essere veri e propri Linked Open Data, così come profetizzato poco più di un anno fa da Titti Cimmino in un articolo dedicato a MuseoTorino.

Si è svolta il 29 ottobre, a Siena, presso il Complesso Museale di Santa Maria della Scala, la cerimonia di premiazione del “Premio ICOM Italia – Musei dell’anno 2011”, giunto alla II edizione. Anche quest’anno Banca Monte dei Paschi di Siena ha scelto di sostenere la prestigiosa iniziativa per testimoniare ancora una volta il suo impegno nella cultura e nell’arte.

MuseoTorino si è aggiudicato il premio Information Comunication Tecnology, uno dei tre riconoscimenti. La giuria internazionale ha così motivato la vittoria: “Il progetto MuseoTorino costituisce una delle più avanzate interpretazioni dell’ecomuseologia internazionale, in cui una grande metropoli – Torino – si fa letteralmente museo di se stessa, scoprendo patrimoni segreti, censiti in modo partecipato e resi disponibili attraverso un incrocio efficace di tutte le nuove tecnologie oggi disponibili, dal web alle tecnologie “mobile”.

MuseoTorino in tale senso risulta un superamento del concetto classico di “museo della città”, ovvero di un luogo deputato a raccontare la vicende storiche di uno spazio urbano, a vantaggio di un’idea che fonde abilmente il concetto tutto italiano di “museo diffuso” con quello internazionale di “ecomuseo”. Lo strumento tecnologico nel progetto MuseoTorino non è quindi un accessorio, un mezzo di comunicazione di massa, ma è il vero medium del museo stesso. In tale senso apre nuove frontiere all’applicazione delle nuove tecnologie al patrimonio culturale, mirando al superamento dell’idea enciclopedica che stava alla base della nascita del museo moderno e prevedeva lo spostamento fisico degli oggetti, in una logica di rispetto delle connessioni spazio temporali in cui il contesto arricchisce di senso ogni incontro.”

MuseoTorino è il Museo della Città inaugurato in occasione delle celebrazioni del 150° anniversario dell’Unità d’Italia. Un progetto innovativo di museo virtuale, unico nel panorama nazionale ed europeo, nato per raccogliere, conservare e comunicare la conoscenza della città.

MuseoTorino è un sito, www.museotorino.it, pensato e strutturato come un museo dove è possibile trovare informazioni sui luoghi, sulla loro storia, sulle persone che li hanno abitati, sugli eventi di cui sono stati teatro e dove è possibile esplorare, attraverso la mappa della città presente, l’intero spazio urbano o seguire percorsi a tema.

Ogni luogo, evento, personaggio, tema è corredato da un breve cartellino identificativo e da una scheda di catalogo, con note e apparati archivistici, bibliografici e sitografici sulle fonti utilizzate, sulla letteratura esistente sull’argomento e sugli enti e le istituzioni a cui far riferimento per un approfondimento delle conoscenze.

MuseoTorino è dotato di un proprio archivio, di una mediateca e di una biblioteca digitale che conta attualmente circa 6.000 schede bibliografiche e 150 libri digitalizzati.

www.museotorino.it utilizza tecnologie e piattaforme di ultima generazione che permettono di applicare la filosofia del web 3.0 (web semantico) e dei Linked Open Data, basata sulla condivisione dei dati, in un formato aperto e standard, con tutta la comunità della rete. MuseoTorino intende essere non solo un museo per tutti, ma di tutti. MuseoTorino si propone di coinvolgere un sempre maggior numero di soggetti e in particolare tutti i cittadini interessati e disponibili a partecipare alla crescita del Museo condividendo conoscenze, saperi, memorie e proponendo idee, iniziative e progetti.

Maggiori Info: ICOM Italia

Nella giornata del 14 ho avuto l’onore di intervenire al Team 2 con un intervento con tema “Interoperabilità fra sistemi informativi disomogenei e innovazione strategica nella gestione delle risorse culturali”. Centrale è stata l’esperienza acquisita con MuseoTorino e di come un “prodotto” di questo categoria, anche se inizialmente pensato per l’ambito culturale, può diventare un ottimo veicolo di promozione (prima) e accoglienza (poi) turistica, nel tentativo di approcciare in maniera nuova, la motivazione che spinge un turista ad frequentare un certo territorio e a restarci il più possibile.

Ovvero a come trasformare un visitatore da Looker a Booker (ovvero da persona che “si guarda intorno” a “che prenota”): sempre di più i turisti hanno dei forti constraint di tempo e di budget, e sempre di più il turista è spinto da un interesse motivazionale che è sempre più specialistico.
Da qui la necessità di creare una proposta interessante per il (futuro) turista, grazie a contenuti sempre più targetizzati sulla base del suo profilo, con una proposta di micro-turismo allettante e flessibile.

In quest’ottica diventa fondamentale aver la possibilità di creare contenuti che siano dinamici, agili e flessibili nel tempo. La possibilità di attingere da varie fonti dati per creare contenuti “quasi” in tempo reale può essere fondamentale per attrarre il turista o per tenerlo sul territorio, ancor più se su questi contenuti è sviluppata la “e-travel integration”, cioè la possibilità di prenotare il proprio soggiorno, fondamentale per trasformare il “looker in booker”.

MuseoTorino è un ottimo esempio di come poter realizzare questo scenario: all’indirizzo

http://www.museotorino.it/api

è possibile attingere in tempo reale le informazioni relative alle schede presenti nel museo. Ad esempio un albergo intitolato a Cavour potrebbe agevolmente integrare nel proprio sito una zona di “approfondimento” dedicata a Camillo Benso, oppure un sito che parla di un particolare evento potrebbe incorporare informazioni storiche dal sito che riguarda l’evento stesso.
Al contrario un sito come MuseoTorino potrebbe, nella pagina dedicata a, per esempio, Palazzo Madama, visualizzare gli eventi che sono in corso nel Palazzo prelevandoli dal relativo sito che li propone sotto forma di dati strutturati (o api).

Ho notato con piacere che i partecipanti al mio intervento hanno mostrato molto interesse quando ho iniziato ad accennare al concetto degli Open (o Public) Data e a come si possono valorizzare i propri dati anche quando vengono rilasciati in modalità aperta. Il valore del proprio lavoro aumenta quando i dati prodotti vengono riusati il più possibile: un pò come Google con GoogleMaps o il data set di IMDB, ma gli esempi potrebbero essere tantissimi.

Riconciliare i dati frammentati lungo tutta l’Italia è un obbiettivo ambizioso ma necessario: alla base di questo processo deve essere necessario costruire una lingua franca che venga interpretata allo stesso modo in tutta la penisola. Per fare questo, informaticamente parlando, è necessario condividere un vocabolario che accomuni tutti i sistemi che espongono dati o i siti che li visualizzano.
Ho già accennato in un precedente post come l’uso della taggatura delle pagine web secondo i criteri di schema.org possa rendere i propri contenuti semanticamente accettati dai maggiori player (google, microsoft, yahoo). Ma grazie alla possibilità di estendere i dizionari predefiniti e avendo già “di serie” una tassonomia dedicata al turismo è già ora possibile definire un dizionario comune per il turismo italiano affinché termini come “baita”, “rifugio”, “chalet” siamo sempre riconosciuti e taggati in maniera univoca indicando, concettualmente, la stessa cosa ma declinandola in maniera diversa a seconda delle regione; in questo modo i motori di ricerca potranno indicizzare coerentemente i contenuti esposti su internet e le integrazioni fra sistemi potranno essere più concrete. L’uso di schema.org e del relativo dizionario non comporta l’uso di nuovi sistemi … i sistemi interni potranno continuare a catalogare le informazioni (i dati) come già ora fanno: sarà poi necessario un lavoro di iniezione dei microdati che potrà essere automatizzato esternamente (ma localmente alle rispettive farm) o addirittura esternizzato tramite un service centrale.

Schema.org al momento è legato al web e per quanto riguarda i dati (open o public non importa) bisogna ancora lavorarci su. Lo standard normalmente usato è RDF, ma su questo formato c’è molto fermento e bisognerà vedere dove si approderà con futuri standard che semplifichino l’esposizione e la gestione delle informazioni in questo formato.

In ogni caso da subito è urgente definire un modo comune di “taggare” i contenuti turistici: il lavoro sarà lungo e quando sarà terminato sono sicuro che gli standard saranno pronti per essere usati al meglio.

Di seguito le slide presentate all’Assise dell’Ospitalità.

A 21Style è stata riconosciuta la competenza nel creare innovazione nel settore ICT e per tutto il nostro team questo è motivo di grande orgoglio.

In questa occasione 21Style presenta la nuova versione del suo prodotto di punta, HOSS® Semantic Storage. HOSS® 2.0 è ancora in fase di rilascio (beta) e anche il relativo sito è ancora in costruzione. Nelle prossime settimane verrà rilasciata la versione finale anche nella versione PaaS.

Vai a “The Best of” Innovazione ICT

Il motore di MuseoTorino, HOSS Semantic Storage (precedentemente conosciuto come Karmig Engine), memorizza le informazioni all’interno di un GraphDB e prevede l’indicizzazione delle informazioni stesse all’interno di una istanza di Apache Lucene, un motore di indicizzazione usato in decine di prodotti e universalmente riconosciuto come fra i più performanti ed efficaci.

Il problema:

Purtroppo, nella gestione degli apostrofi, Lucene non si è dimostrato molto flessibile. E sulla rete non ho trovato molti casi similari che mi aiutassero a risolvere la cosa definitivamente.

Lucene (la versione da noi usata è la 3.0), quando analizza le parole da indicizzare, usa delle classi che estendono da org.apache.lucene.analysis.Analyzer. Le più usate sono:

• SimpleAnalyzer: esegue un semplice string tokenizing sul testo
• StopAnalyzer: elimina dal testo alcune parole non interessanti ai fini dell’indicizzazione. Di default è basato su un dizionario in inglese, quindi troviamo parole come and, it, the.
• StandardAnalyzer: quello più usato perchè incorpora le funzioni di StopAnalyzer e rende le parole minuscole

All’interno di queste classi, il cuore del processamento è nel metodo tokenStream(String fieldName, Reader reader). All’interno di questo metodo, usando le classi di tipo Filter (sottoclassi di org.apache.lucene.analysis.TokenFilter), si processa in concreto il testo originale.

Dopo vari tentativi abbiamo purtroppo scoperto che non c’era modo, usando i filtri standard, di eliminare l’apostrofo dal testo o comunque di usarli in maniera tale da gestire opportunamente le singole parole.

I singoli Analyzer davano risultati non utili al nostro scopo. Utilizzando la frase

La chiesa fu dedicata a Sant'Agostino soltanto nel 1551, città che quando fu ceduta ai padri Agostiniani scalzi. Prima di questa data era intitolata ai santi Filippo e Giacomo ed era già attestata in un diploma dell'imperatore Enrico III del 1047.

i risultati, utilizzando vari Analyzer, sono stati i seguenti:

WhitespaceAnalyzer:

[La] [chiesa] [fu] [dedicata] [a] [Sant'Agostino] [soltanto] [nel] [1551,] [città] [che] [quando] [fu] [ceduta] [ai] [padri] [Agostiniani] [scalzi.] [Prima] [di] [questa] [data] [era] [intitolata] [ai] [santi] [Filippo] [e] [Giacomo] [ed] [era] [già] [attestata] [in] [un] [diploma] [dell'imperatore] [Enrico] [III] [del] [1047.]

SimpleAnalyzer

[la] [chiesa] [fu] [dedicata] [a] [sant] [agostino] [soltanto] [nel] [città] [che] [quando] [fu] [ceduta] [ai] [padri] [agostiniani] [scalzi] [prima] [di] [questa] [data] [era] [intitolata] [ai] [santi] [filippo] [e] [giacomo] [ed] [era] [già] [attestata] [in] [un] [diploma] [dell] [imperatore] [enrico] [iii] [del]

StopAnalyzer

[la] [chiesa] [fu] [dedicata] [sant] [agostino] [soltanto] [nel] [città] [che] [quando] [fu] [ceduta] [ai] [padri] [agostiniani] [scalzi] [prima] [di] [questa] [data] [era] [intitolata] [ai] [santi] [filippo] [e] [giacomo] [ed] [era] [già] [attestata] [un] [diploma] [dell] [imperatore] [enrico] [iii] [del]

StandardAnalyzer

[la] [chiesa] [fu] [dedicata] [sant'agostino] [soltanto] [nel] [1551] [città] [che] [quando] [fu] [ceduta] [ai] [padri] [agostiniani] [scalzi] [prima] [di] [questa] [data] [era] [intitolata] [ai] [santi] [filippo] [e] [giacomo] [ed] [era] [già] [attestata] [un] [diploma] [dell'imperatore] [enrico] [iii] [del] [1047]

Come si può vedere, a seconda dell’Analyzer, il testo viene interpretato diversamente.
Se ad una prima analisi, il SimpleAnalyzer e lo StopAnalyzer sembrano quello più adatti perchè eliminano l’apostrofo fra sant e agostino e fra dell e imperatore, in realtà eliminano anche altre informazioni utili, ad esempio le date (in formato numerico).
Lo StandardAnalyzer è decisamente quello più indicato ma gestisce l’apostrofo in maniera non corretta, indicizzando l’intera parola sant’agostino comprensiva di apostrofo. E la riconosce anche, visto che il suo tokenizzatore la individua in questo modo (dal suo token.type()):

[sant'agostino:24->37:<APOSTROPHE>]

Però dopo averlo riconosciuto non fa niente per gestirlo in maniera opportuna.

La soluzione:

Per risolvere questo problema abbiamo dovuto fare in modo che all’Analyzer arrivasse un flusso di dati già pulito e senza apostrofi.
Purtroppo non è possibile individuare il momento in cui viene richiamato l’Analyzer e quindi è impossibile sapere quando elaborare la nuova stringa. Si poteva modificarne direttamente il contenuto all’origine, ma poi non avremmo mai più saputo come era nella sua forma iniziale.
Per fortuna è possibile indicare a Lucene di usare un Analyzer specifico e di estenderne facilmente uno già esistente.
Nel nostro caso abbiamo esteso StandardAnayzer e il suo metodo tokenStream(String fieldName, Reader reader).

Ecco il codice della nuova classe:

	public TokenStream tokenStream(String fieldName, Reader reader) {

		final Set stopWords = StopFilter.makeStopSet(ItalianStopWords.getStopWords());

    	Reader filtered = new HOSSFilterReader(reader);

        TokenStream result = new StandardTokenizer(Version.LUCENE_30, filtered); 

        result = new StandardFilter(result);
        result = new LowerCaseFilter(result);
        result = new StopFilter(true, result, stopWords);

    	return result;
	}
 

Abbiamo usato i filtri già usati nello StandardAnalyzer di serie con Lucene, ma allo StandardFilter arriva già un flusso ripulito dalla nostra classe create ad-hoc per l’occasione: HOSSFilterReader.

HOSSFilterReader non è altro che una estensione di FilterReader che wrappa il Reader in arrivo in tokenStream() e restituisce spazi bianchi al posto di caratteri predefiniti, in questo apostrofi. In questo modo lo StandardTokenier riceverà testo privo di apostrofi e, al loro posto, spazi. HOSSFilterReader prevede l’impostazione anche di altri caratteri: nel nostro caso ci siamo accontentati degli apostrofi.

Ecco il codice completo della classe.

class HOSSFilterReader extends FilterReader{

    	// Add in charToBlank any char to be render as blank (white space)
    	private String charToBlank = "'";

        protected HOSSFilterReader(Reader arg0) {
			super(arg0);
		}

        @Override
        public int read(char[] cbuf, int off, int len) throws IOException{
            int read = super.read(cbuf, off, len);

            if (read == -1) {
                return -1;
            }

            int pos = off - 1;
            for (int readPos = off; readPos < off + read; readPos++) {

            	if (charToBlank.indexOf(cbuf[readPos]) != -1) {
                	cbuf[readPos] = ' ';
                }
                pos++;
                if (pos < readPos) {
                    cbuf[pos] = cbuf[readPos];
                }
            }
            return pos - off + 1;
        }
    }

ItalianStopWords invece è un contenitore di caratteri da escludere dall’indicizzazione. Ai fini del problema degli apostrofi è ininfluente, ma la sua utilità è indubbia in quanto elimina dall’indice caratteri e parole di uso comune che in alcuni casi potrebbero generare risultati non utili. Parole come il, lo, la, del, dell, delle …. ecc non sono sicuramente utili. Fare una ricerca per del (o tua, vostra, egli) sarà anche interessante ma stressante per il sistema.

Pertanto allo StopFilter viene passato un set ad-hoc (ricordate che in StardardAnalyzer usa già lo StopWord ma basato su un vocabolario inglese) di parole da non considerare.

Ecco il codice della classe:

public static class ItalianStopWords {

		static String[] stopWords = null;

		public static String[] getStopWords() {
			if (stopWords != null) {
				return stopWords;
			} else {
				return elaborateStopWords();
			}
		}

		// By glfp.
		static String[] elaborateStopWords() {

			StringTokenizer st = new StringTokenizer(
					"a b c d e f g h i j k l m n o p q r s t u v w x y z il lo la gli " +
					 "le un uno una di da in su per con tra fra al allo alla ai agli alle dal " +
					 "dallo dalla dai dagli dalle del dello della dei degli delle nel nello nella " +
					 "nei negli nelle sul sullo sulla sui sugli sulle avanti dietro stante durante " +
					 "sopra sotto salvo accanto avanti verso presso contro circa intorno fuori " +
					 "malgrado vicino lontano dentro indietro insieme assieme oltre senza attraverso " +
					 "nondimeno mio mia miei mie tuo tua tuoi tue suo sua suoi sue nostro nostra nostri " +
					 "nostre vostro vostra vostri vostre loro questo codesto cotesto quello ciò questa " +
					 "codesta cotesta quella io tu egli esso ella essa noi voi essi esse me mi te ti lui " +
					 "lei ce ci ve vi se si ne che colui colei cui chi sono sei è siamo siete sarebbe sarà " +
					 "essendo ho hai ha abbiamo avete hanno avrebbe avrà avendo avuto l' un' all' dall' dell' " +
					 "sull' nell' quell' c' v' po' può potrà potrebbe potuto deve dovrà dovrebbe dovuto " +
					 "ma però anzi tuttavia pure invece perciò quindi dunque pertanto ebbene orbene né nè neppure " +
					 "neanche nemmeno sia oppure ossia altrimenti cioè infatti invero difatti perchè perché poichè poiché " +
					 "giacchè giacché quando mentre finchè finché affinchè affinché acciocchè acciocché qualora purchè purché sebbene quantunque benchè benché " +
					 "nonostante come quasi fuorchè fuorché tranne eccetto laddove ah oh eh orsù urrà ahimè suvvia basta " +
					 "insomma così qui qua lì là già allora prima dopo ora poi sempre mai presto tardi intanto " +
					 "frattanto talvolta spesso molto troppo poco più meno assai niente nulla alquanto altrettanto " +
					 "anche perfino persino altresì finanche abbastanza almeno ancora appunto attualmente certamente " +
					 "comunque altrove dove dovunque effettivamente forse generalmente inoltre insufficientemente " +
					 "inutilmente naturalmente no non nuovamente ovunque ovviamente piuttosto precedentemente " +
					 "probabilmente realmente realmente semplicemente sì solitamente soprattutto specificamente " +
					 "successivamente sufficientemente veramente alcune alcuni alcuno altri altro certo chiunque ciascuno molti nessun nessuno ogni ognuno " +
					 "parecchi parecchio pochi qualche qualcosa qualcuno qualunque tanto tutti tutto qual quale quali " +
					 "quanto bene cosa cose data esempio male scelta " +
					 "differente difficile dissimile diverso entrambe entrambi facile inusuale " +
					 "inutile impossibile improbabile insolito insufficiente "+
					 "possibile probabile pronto semplice siffatto simile sufficiente usuale utile vuoto interno " +
					 "mediante modo ovvio precedente propri proprio prossimo scelto soli solito solo soltanto " +
					 "specifico stessi stesso subito successivo super tale totale totali uguale uguali ulteriore " +
					 "vari vario verso fu ed dell dall");
			String temp[] = new String[st.countTokens()];
		    int i=0;
			while(st.hasMoreTokens()) {
				temp[i]=st.nextToken();
			    i++;
			}

			return temp;
		}
	}

Il set principale l’ho trovato qui, modificato poi, in collaborazione col personale di MuseoTorino, per adattarlo meglio alle esigenze di business del progetto, e mettendoci anche del mio in alcune altre parti.

Il risultato del nostro nuovo Analyzer è il seguente:

[chiesa] [dedicata] [sant] [agostino] [1551] [città] [ceduta] [padri] [agostiniani] [scalzi] [intitolata] [santi] [filippo] [giacomo] [già] [attestata] [diploma] [imperatore] [enrico] [iii] [1047]

Ha tutto quello che ci serve, gli apostrofi sono spariti, le parole non utili sparite.

Ricordatevi solo, durante le ricerce, di eliminare dalla parole di ricerca sia gli apostrofi che le stesse parole inutili, altrimenti potreste non trovare i risultati desiderati !

Per concludere il codice completo dell’Analyzer personalizzato:

public class Analyzer extends StandardAnalyzer {

	public Analyzer() {
		super(Version.LUCENE_30);
	}

	public TokenStream tokenStream(String fieldName, Reader reader) {

		final Set stopWords = StopFilter.makeStopSet(ItalianStopWords.getStopWords());

    	Reader filtered = new HOSSFilterReader(reader);

        TokenStream result = new StandardTokenizer(Version.LUCENE_30, filtered); 

        result = new StandardFilter(result);
        result = new LowerCaseFilter(result);
        result = new StopFilter(true, result, stopWords); 

    	return result;
	}
}

Se qualcuno ha suggerimenti sono lieto di accoglierli. Non si finisce mai di migliorare il proprio codice !

Con la nascita di schema.org i tre big del web (ma Facebook dov’era ?) hanno riunito i loro sforzi nel tentativo di creare una ontologia condivisa che gli permettesse di semplificargli il compito nell’interpretazione dei contenuti presenti nella rete.

Mauro Lupi da una breve e semplice spiegazione su come funziona, mentre Matteo Brunati entra più a fondo con valide riflessioni sul tema.

Peter Mika, uno degli autori, presso Yahoo, di questo standard, spiega come si sia giunti a questo formalismo a scapito dello standard emergente RDFa che, benchè formalizzasse in maniera chiara come strutturare le informazioni all’interno delle pagine HTML, peccava in una troppa libertà nel formalismo delle ontologie. Anche schema.org è estendibile e permette di creare e/o usare ontologie diverse da quelle standard: schema.org va oltre in quanto formalizza in maniera univoca, all’interno dell’accordo dei tre fondatori, una ontologia chiara, completa e semplice da usare restando, ovviamente, ad alto livello.

Sono curioso di verificare quanto l’ontologia di Freebase abbia influenzato quella di schema.org …. secondo me tanta, il che non sarebbe male visto il rodaggio, ormai terminato, del vasto archivio di conoscenza di Freebase.

Benvenuto schema.org !

• nuova homepage ristilizzata
• completamento dei 150 libri digitalizzati (e molti altri in arrivo)
• nuovo numero della rivista MuseoTorino intitolata: “Torino nel Risorgimento“
• nuovo e fiammante mostra “Il Risorgimento è qui! 150 luoghi dove si è fatta l’Italia a Torino“
• aggiornamento dell’applicazione “Il Museo” (versione 1.1), il navigatore basato su GoogleMap per la consultazione, su mappa, di tutti i luoghi della collezione di MuseoTorino.
• Nuove e aggiornate API

Lo trovate qui di seguito: buona visione !

UPDATE:
A questo indirizzo

http://www.slideshare.net/21Style/museotorino-il-primo-progetto-in-italia-ad-utilizzare-graphdb-rdfa-linked-open-data

le slide della presentazione.

Verrà descritto il progetto MuseoTorino dal punto di vista tecnologico, le problematiche emerse in fase di analisi e le soluzione trovate ad esse. In particolare si giustificherà la scelta di un db engine quale un GraphDB e  l’architettura aperta agli Open Data. Inoltre si evidenzierà il futuro lavoro previsto sul progetto per farlo diventare uno dei primi siti 100% Web 3.0 in Italia.