Le seguenti “mind map” offrono uno spaccato delle informazioni disponibili a seconda del soggetto o della tematica di interesse.

• Soggetto/Tematica:
  • Studenti
  • Personale accademico
  • Progetti
    • Europei
    • Italiani (CTN, PRIN 2012)
    • Erasmus+
    • CHAFEA
    • Spin-off accademici
  • Sperimentazioni cliniche
  • Dati sul diritto allo studio
  • Dati sul bilancio di genere

L’idea delle “mind map“ sotto rappresentate è quella di delineare un quadro generale dei dati disponibili su ToscanaOpenResearch, suddividendoli per tematica.

Infatti, la parola che si trova al centro di ogni map (all’interno della casella con il bordo arrotondato) rappresenta il soggetto di interesse, la tematica dalla quale è possibile ottenere le informazioni indicate da ogni freccia.

La fonte del dato viene riportata tra parentesi, ad eccezione dei dati CTN/PRIN 2012 che sono stati ottenuti tramite un protocollo di intesa tra il MIUR e la Regione Toscana.

Ad ogni modo, le mind map sopra rappresentante offrono solo un’idea generale dei dati a disposizione per ogni concetto e/o soggetto. Vedremo ora come analizzare in maggior dettaglio i dati disponibili e come consultarli tramite un’ontologia, ovvero una rappresentazione formale, condivisa ed esplicita di una concettualizzazione di un dominio di interesse.

Lo SPARQL endpoint permette agli utenti di recuperare i dati utilizzando il linguaggio di interrogazione SPARQL, che è uno standard definito dal World Wide Web Consortium (W3C). Lo SPARQL endpoint può essere utilizzato sia dagli utenti umani che dalle macchine. Gli esseri umani interagiscono con esso attraverso un'interfaccia utente grafica, mentre le macchine (script, applicazioni, ecc.) comunicano con l'endpoint utilizzando il protocollo standard SPARQL definito dal W3C.

I dati recuperati da un endpoint SPARQL sono conformi all'approccio Linked Data per la pubblicazione di dati nel contesto del Semantic Web. Ciò significa che il formato dei dati è RDF (Resource Description Framework), in cui le informazioni sono rappresentate come risorse. Ogni risorsa è identificata da un Uniform Resource Identifier (URI), che nella maggior parte dei casi assomiglia a un indirizzo web (ad es. http://unics.cloud/ontology#Project-123). Le risorse sono caratterizzate da proprietà. Alcune proprietà attribuiscono valori di dati a una risorsa, come l'acronimo di un progetto o il suo titolo, mentre altre collegano una risorsa con un'altra risorsa, ad esempio un progetto con uno dei suoi partecipanti. Le proprietà che attribuiscono valori di dati sono chiamate "proprietà dato", mentre le proprietà che collegano le risorse sono chiamate "proprietà oggetto". Le proprietà, come le risorse, sono identificate dagli URI (ad esempio http://unics.cloud/ontology#acronym).

Concettualmente, i dati formattati in RDF sono un grafo, in cui i nodi sono o risorse o valori di dati, e i collegamenti tra i nodi sono o proprietà dato o proprietà oggetto. In termini pratici, tuttavia, i dati formattati in RDF sono normalmente rappresentati come una lista di triple. Una tripla è una frase sotto forma di "soggetto predicato oggetto". Queste triple sono usate per elencare i collegamenti nel grafo, cioè il soggetto di una tripla è sempre una risorsa, il predicato è una proprietà, e l'oggetto è o un valore di dati o un'altra risorsa. Come esempio, un set di dati contenente due progetti di uno stesso bando con il loro titolo e la loro sigla si presenterebbe in questo modo (gli URI sono spesso scritti tra parentesi angolari):

<http://unics.cloud/ontology#Project-1> <http://unics.cloud/ontology#acronym> "Acronym 1"
<http://unics.cloud/ontology#Project-1> <http://unics.cloud/ontology#title> "Title 1"
<http://unics.cloud/ontology#Project-1> <http://unics.cloud/ontology#call> <http://unics.cloud/ontology#Call-A>
<http://unics.cloud/ontology#Project-2> <http://unics.cloud/ontology#acronym> "Acronym 2"
<http://unics.cloud/ontology#Project-2> <http://unics.cloud/ontology#title> "Title 2"
<http://unics.cloud/ontology#Project-2> <http://unics.cloud/ontology#call> <http://unics.cloud/ontology#Call-A> <http://unics.cloud/ontology#Call-A> <http://unics.cloud/ontology#name> "Name of call for projects A"

In RDF e SPARQL è comune utilizzare i prefissi per abbreviare i nomi delle risorse e delle proprietà, cioè gli URI. Come vediamo nell'esempio precedente, tutte le risorse e le proprietà di questo dataset hanno URI che iniziano con "http://unics.cloud/ontology#". Per evitare di scrivere ogni volta questa parte comune, possiamo definire un'abbreviazione per questo prefisso, per esempio "tor:", e scrivere questa abbreviazione al posto del prefisso completo. L'esempio di cui sopra diventerebbe allora:

Prefix tor: <http://unics.cloud/ontology#>
tor:Project-1 tor:acronym “Acronym 1”
tor:Project-1 tor:title “Title 1”
tor:Project-1 tor:call tor:Call-A
tor:Project-2 tor:acronym “Acronym 2”
tor:Project-2 tor:title “Title 2”
tor:Project-1 tor:call tor:Call-A
tor:Call-A tor:name “Name of call for projects A”

In termini di sintassi, l'abbreviazione di un prefisso deve essere in forma di "nome:" (notare il ":" alla fine). L'abbreviazione più breve possibile è quella dove "nome" è vuoto, cioè l'abbreviazione è solo ":". Inoltre, è opportuno notare che quando le abbreviazioni sono usate per i prefissi, gli URI non sono più scritti tra parentesi angolari (questi sono usati solo per gli URI non abbreviati).

Per poter scrivere query su dati RDF utilizzando il linguaggio SPARQL, è necessario sapere quali proprietà possono essere applicate su quali insiemi di risorse. Qui entrano in gioco le ontologie. Un'ontologia è essenzialmente una definizione della struttura dei dati formattati in formato RDF, dove risorse con proprietà simili sono raggruppate in concetti (chiamati anche classi). In questo senso, un'ontologia definisce un insieme di concetti (ad esempio Progetto, Chiamata, Partecipante, Paese, ...) e un insieme di proprietà (sia proprietà dato che proprietà oggetto) che possono essere applicate a questi concetti. I concetti, proprio come le proprietà e le risorse, sono identificati dagli URI (che possono essere abbreviati come visto sopra).

Per l’integrazione dei dati il sistema utilizza l’approccio Ontology-Based Data Access (OBDA) che permette di integrare i dati attraverso un’ontologia di dominio e consente agli utenti di accedere ai dati per mezzo di “interrogazioni”, eliminando la necessità di conoscere i termini tecnici legati all’organizzazione fisica dei database e alla struttura interna.

La documentazione dell’ontologia è disponibile sul sito ToscanaOpenResearch, nella sezione Accesso ai Dati > Documentazione dell’ontologia, al link: http://toscanaopenresearch.it/sparql-endpoint/it/docs/index.html.

Nei diagrammi, le caselle con bordo arrotondato indicano i concetti, con l'elenco dei nomi scritti all'interno di ogni casella che sono le proprietà dato applicabili a questo particolare concetto. Ad esempio, nella parte di ontologia TOR che riguarda i progetti CORDIS, il concetto “Organization” ha le proprietà dato “unicsId”, “extendedName” ed “acronym”. Le frecce con punta aperta tra le caselle rappresentano invece proprietà oggetto. Il nome di una proprietà oggetto viene indicato attraverso un’etichetta apportata sulla freccia, ed il verso di applicazione della proprietà è dato dal verso della freccia stessa. Ad esempio, la freccia etichettata con “principalInvestigator” che collega il concetto “EC-Project” con il concetto “Person”, rappresenta una proprietà oggetto che associa ad un progetto europeo la persona che è il principal investigator di quel progetto.

Ad ogni proprietà dato e ad ogni proprietà oggetto è associato un vincolo di cardinalità, specificato attraverso una coppia “min..max”, che stabilisce un limite al numero minimo e massimo di valori che la proprietà in questione può avere. Ad esempio, il vincolo “0..1” sulla proprietà “principalInvestigator” indica che un oggetto in EC-Project (ovvero, un progetto europeo) può avere o meno un principalInvestigator (vincolo minimo 0), e in ogni caso può averne al più uno (vincolo massimo 1). In modo analogo, il vincolo “[0..1]” sulla proprietà dato “startingYear” di “EC-Project”, indica che un progetto europeo può avere o meno un singolo anno di inizio. In generale, la cardinalità minima può essere 0 (ovvero nessun vincolo minimo), oppure un intero positivo; quella massima può essere un intero positivo, oppure “n” (ovvero nessun vincolo massimo). Se nel diagramma manca la specifica del vincolo di cardinalità, viene assunto “1..1”, ovvero la proprietà è sia obbligatoria (ha sempre un valore), sia funzionale (ne ha uno solo).

Un altro elemento importante delle ontologie è il meccanismo di generalizzazione, che permette di organizzare i concetti in una o più gerarchie. Una generalizzazione (detta anche “is-a”), è indicata nel diagramma con una freccia che termina con un triangolo chiuso, che va da un concetto più specifico ad uno più generale. Un is-a indica che ogni oggetto che appartiene al concetto più specifico appartiene anche a quello più generale. Ad esempio, la freccia is-a da “ERC-Project” a “EC-Project” indica che ogni progetto ERC è anche un progetto europeo. In virtù di questo, la generalizzazione comporta l’ereditarietà, ovvero il fatto che un concetto più specifico eredità tutte le proprietà di un concetto più generale. Ad esempio, ogni progetto ERC, essendo anche un progetto europeo, ha tutte le proprietà dei progetti europei, ad esempio un titolo (proprietà dato “title”). Ma un progetto ERC ha anche ulteriori proprietà che i progetti europei in generale non hanno, ad esempio il fatto di avere un “ercGrant”.

Dopo aver appreso le nozioni base sullo SPARQL Endpoint e sulla rappresentazione grafica dell’ontologia, è giunto il momento di interrogare in maniera autonoma il sistema e di sperimentare queries.

Una richiesta di informazioni ad un SPARQL endpoint tipicamente si compone dalle seguenti parole chiave:

• PREFIX: usato per specificare l’URL delle ontologie che si intende utilizzare nella query.
• SELECT: definisce i valori di output che saranno inclusi nella query. I suddetti valori devono essere presenti all’interno della clausola WHERE.
• WHERE: contiene le informazioni sotto forma di restrizione al fine di ottenere dei dati.

Di seguito un esempio di query che fornisce in output le università presenti nell’ontologia di UNICS.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#glt;
PREFIX unics: <http://unics.cloud/ontology#>
SELECT ?org
WHERE {
?org rdf:type unics:University .
}

L’istruzione PREFIX seguita da una parola (a scelta libera), introduce un abbreviazione per URL potenzialmente lunghi. Riportando l’esempio delle università, nell’ontologia di UNICS le università sono disponibili attraverso l’URL “http://unics.cloud/ontology/University”, usando l’istruzione PREFIX, è possibile riferirsi alle università usando “unics:University”, poiché l’URL di unics è stato salvato nella parola unics.

Si nota che la query è divisa in almeno due parti.
Nella prima parte, introdotta appunto da SELECT, si elencano le variabili che si vogliono avere come risultato, separandole con spazi.

La seconda parte, introdotta da WHERE e racchiusa da parentesi graffe, specifica le regole sotto forma di triple RDF. Una triple RDF è composta da:

• Soggetto: indica un risorsa disponibile nell’ontologia;
• Predicato: consente di creare una relazione tra soggetto e oggetto;
• Oggetto: può essere un risorsa identificabile tramite un univoco URI oppure un dato.

Nell’esempio sopra riportato troviamo:

• ?org: soggetto della query
• unics:University: oggetto della query
• Rdf:type: predicato che permette di salvare nella variabile ?org il contenuto dell'oggetto unics:University.

Analizzando il contenuto della query, si nota che si sta chiedendo le entità che sono di tipo unics:University. Il termine ?org è una variabile, in cui è salvato il contenuto . Essa può prendere un nome arbitrario, purché inizi con un punto di domanda. Essa permette di usare tutti i valori che assume nelle triple “valide” nella tabella dei risultati. All’interno di una variabile è possibile salvare qualsiasi tipo di contenuto, che sia un dato o un URI che sarà usato successivamente per creare query piú complesse.

In sostanza, WHERE seleziona dati da prendere in considerazione per costruire la tabella dei risultati.
È possibile inserire più di un triple pattern in una clausola WHERE:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX unics: <http://unics.cloud/ontology#>
SELECT *
WHERE {
?org rdf:type unics:University .
?org unics:extendedName "Università di Firenze" .
}

All’esempio precedente viene aggiunta la condizione che con lo stesso soggetto del primo pattern e associato alla variabile ?org porti anche il nome di "Università di Firenze".

Si può intuire come le query possono crescere man mano in termini di complessità. In combinazione con la caratteristica di SPARQL di poter interrogare i metadati (“che proprietà può avere un'università?”), questo lo rende un linguaggio molto adatto all’esplorazione progressiva del dati.
Vi sono poi vari modo più raffinati di selezionare ed elaborare dati, per i quali si rimanda alla letteratura più specifica e ai esempi contenuti sul portali TOR.

Una libreria di query predefinite, organizzate coerentemente con le sezioni principali dell’Osservatorio, è disponibile all’interno della sezione Accesso ai dati > SPARQL endpoint al seguente link: http://toscanaopenresearch.it/sparql-endpoint/it/.
Tramite questo SPARQL endpoint è inoltre possibile ottenere l’elaborazione visuale immediata dei dati ottenuti dall'esecuzione delle query, servendosi di strumenti quali “Pivot Table” e “Google Chart”.

Tuttavia, una volta presa confidenza con lo SPARQL endpoint e il diagramma dell’ontologia, seguendo le istruzioni sopra riportate, sarà possibile cambiare le query e adattarle in base alle esigenze, aggiungendo maggiori informazioni e/o cambiando il perimetro (sia temporale che geografico) di interesse.