Linked Open Data per i Servizi Pubblici

Transcript

1 Linked Open Data per i Servizi Pubblici Cristiano Longo Dipartimento di Matematica ed Informatica Università degli Studi di Catania mailto://longo@dmi.unict.it 30 Dicembre Introduzione L agenzia per l italia digitale (in breve AGID) 1 identifica le tecnologie del Web Semantico e dei Linked Open Data(vedi [1, 7, 2] per una introduzione) come strumenti ottimali per il rilascio e la diffusione dei dati aperti della pubblica amministrazione. A tal proposito, in [3] la stessa agenzia suggerisce un insieme di vocablari per modellare dati riguardanti svariati aspetti del patrimonio informativo pubblico, dalle informazioni sulla viabilità ai siti di interesse storico e culturale. Tali vocabolari sono stati sviluppati nel contesto dei Linked Open Data, spesso all interno di progetti internazionali. Molti di questi sono raccomandazioni presso il World Wide Web Consorium (in breve w3c), 2 o sono in fase di revisione per diventare tali. Questo documento intende essere una guida per la pubblicazione dei dati inerenti i servizi pubblici. In essa verranno brevemente descritti il vocabolario Core Public Service Vocabulary, sviluppato all interno del progetto Interoperability Solutions for European Public Administrations (in breve ISA), e alcuni vocabolari accessori necessari a descrivere elementi coinvolti nell espletamento del servizio quali ad esempio le stesse pubbliche amministrazioni, le modalità di accesso al servizio, etc. 2 Core Public Service Vocabulary Core Public Service Vocabulary (in breve CPSV ) 3 è un vocabolario per la rappresentazione di servizi pubblici. Tale vocabolario è realizzato e mantenuto da un Report realizzato nell ambito del progetto PON04a2 A PRISMA core-public-service-vocabulary 1

2 Vocabolario Namespace URI del Namespace Core Public Services cpsv Dublin Core dcterms Core Location locn Organization Ontology org Friend Of A Friend foaf WSG GEO wsg84 PROV-O prov Table 1: Elenco dei Vocabolari Citati gruppo di lavoro della commissione europea all interno del programma ISA e, al tempo in cui il presente documento viene scritto, è ancora in fase di revisione. Il namespace di questo vocabolario è abbreviato preferibilmente con cpsv: cpsv: In questo contesto, un pubblico servizio viene definito come la capacità di portare a termine una procedura (insieme di azioni), attuata da o per conto di una pubblica amministrazione, che porti beneficio ad un cittadino, un ente economico o ad un altro ente pubblico. I pubblici servizi vengono rappresentati nel vocabolario CPSV come istanze della classe PublicService e di norma sono dotati di un titolo, mediante la proprietà dcterms:title, e di una descrizione esplicativa, specificata usando dcterms:description. Le proprietà dcterms:title e dcterms:description sono mutuate dai vocabolari della iniziativa Dublin Core. 4 I servizi pubblici sono suddivisi in tipologie, che aiutano a identificare servizi simili offerti da amministrazioni differenti (magari in paesi diversi dell Unione, vedi anche la Sezione 3), sono accessibili attraverso alcuni canali (uffici, siti web,... ), possono richiedere degli input e di norma producono degli output. Nel loro funzionamento seguono regole e procedure definite in una norma o atto amministrativo specifico e sono sotto la responsabilità di un ente pubblico, che può erogarli direttamente o demandarne a terzi l esecuzione. È possibile indicare una relazione generica tra due servizi tramite la proprietà dcterms:relate. Inoltre, l erogazione di un servizio può essere condizionata da un altro servizio, è il caso ad esempio dei servizi che richiedono il rilascio di un certificato di residenza. Per modellare dipendenze di questo tipo è possibile utilizzare la proprietà dcterms:requires. Alcuni esempi di modellazione di pubblici servizi possono essere visionati nel Core Public Service Pilot. 5 Nel seguito analizzeremo in dettaglio vari aspetti della rappresentazione dei servizi pubblici, presentando anche degli esempi e analizzando vocabolari e dataset ausiliari che possono essere utili nella rappresentazione. 4 Il vocabolario dcterms è disponibile all indirizzo

3 3 Tipologie di Servizi Pubblici La tipologia di un servizio pubblico viene indicata attraverso la proprietà dcterms:type. Si consiglia, a fini di interoperabilità, di indicare una tipologia presente in uno degli elenchi ben noti. In particolare, per CPSV si fa espressa menzione del tesauro ESD Toolkit s Service List 6 utilizzato dai governi inglese e scozzese e dalle municipalità in Belgio, Olanda, Norvegia, Svezia e Germania. La URI corrispondente alla tipologia di un servizio si può ottenere dall elenco visualizzato quando si visita la services list dal browser dal numero tra parentesi indicato nella riga corrispondente come segue: ove < idservice > è l identificativo del servizio come riportato nella ESD Toolkit s Service List. Un esempio è la tipologia dei servizi concernenti il conferimento farmaci usati. Ad essa corrisponde la seguente riga nella lista Commercial clinical waste disposal (523) ed è identificata dalla URL 4 Regolamenti e Legislazione di Riferimento Un servizio opera seguendo un insieme di regole, linee guida o procedimenti che sono enunciati in uno specifico documento, di solito un atto normativo. Documenti di questo genere vengono rappresentati per mezzo della classe cpsv:rule e i servizi ad essi soggetti sono indicati utilizzando la proprietà cpsv:follows. L ente o il corpo politico responsabile del documento che regolamenta il servizio è collegato al documento stesso mediante la proprietà dcterms:creator. Inoltre, per ogni istanza della classe cpsv:rule può essere indicato il contesto legislativo (cpsv:formalframework) dal quale essa scaturisce usando la proprietà cpsv:implements. È il caso, ad esempio, di un documento di linee guida che siano realizzate a seguito di un decreto governativo. Per modellare leggi, norme, atti amministrativi e contesti normativi è stato creato, sotto invito del Consiglio d Europa (vedi [5]), il cosiddetto European Legislation Identifier, 7 in breve ELI, che permette di associare ad ogni provvedimento legislativo ed amministrativo una URI in maniera univoca. Per ricavare i riferimenti ELI dei provvedimenti europei è possibile consultare il portale EurLex. 8 Lo standard ELI è basato sul sistema delle URI Templates. 9 In particolare, in ELI viene definito il seguente template, in cui tutti i campi sono opzionali, tranne il prefisso eli cooperation_in_civil_matters/jl0068_en.htm

4 /eli/{jurisdiction}/{agent}/{sub-agent}/{year}/{month}/{day}/{type}/ {natural identifier}/{level 1...}/{point in time}/{version}/{language}. Riguardo alla legislazione europea, 10 lo URI scheme da utilizzare è il seguente of document}/{year of adoption}/{number of document}. Lo standard ELI definisce anche dei metodi per specificare informazioni aggiuntive su un provvedimento mediante il protocollo RDFa Canali di Erogazione del Servizio Un utente può entrare in contatto con un servizio attraverso svariati canali, per accedere al servizio o semplicemente ottenere informazioni su esso. Ad esempio un servizio può essere disponibile attraverso una pagina web (foaf:homepage) e/o dei locali appositi (cpsv:physicallylocatedat). Nel caso in cui venga usata la proprietà cpsv:physicallylocatedat, il luogo fisico nel quale è possibile accedere al servizio deve essere specificato come istanza della classe dcterms:location. A tal proposito, è possibile utilizzare il vocabolario LOCN per la rappresentazione di luoghi fisici. Questo vocabolario sarà brevemente richiamato nella Sezione 8. Si noti infine che cpsv:physicallylocatedat e foaf:homepage sono entrambe definite in CPSV come sotto-proprietà di cpsv:haschannel. 6 Input e Output di un Servizio Spesso un servizio richiede degli input per essere espletato. Ad esempio, per il rinnovo della patente di guida potrebbe essere richiesta la patente in scadenza, un documento di identità in corso di validità ed un certificato rilasciato da un medico autorizzato. Gli input eventualmente richiesti vengono indicati con la proprietà cpsv:hasinput e sono istanze della classe cpsv:input. Analogamente, un servizio può produrre degli output, ad esempio un passaporto o un certificato. Tali output vengono modellati come istanze della classe cpsv:output e sono collegati al servizio che li rilascia attraverso la proprietà cpsv:produces. Si noti che realtà le istanze della classe input, per come questa è definita e descritta nel vocabolario CPSV, non rappresentano i documenti stessi, quanto più una sorta di prototipi. 7 Responsabili del Servizio Il soggetto responsabile dell erogazione di un servizio, che può derogare l esecuzione dello stesso a terzi, viene indicato attraverso la proprietà cpsv:provides. Esso

5 è in generale una pubblica amministrazione, che viene modellata come istanza della classe org:organizzation, definita nel vocabolario ORG che sarà brevemente richiamato nella Sezione 9. L utente di un pubblico servizio, sia esso un cittadino o una organizzazione, può essere indicato usando la proprietà cpsv:uses. Sia cpsv:provides che cpsv:uses sono sottoproprietà di cpsv:playsrole. Altre sottoproprietà di cpsv:playsrole possono essere definite per modellare l apporto di un agente allo svolgimento di un servizio, secondo i pattern definiti nel vocabolario ORG. 8 Loation, Siti e Indirizzi Nel documento di specifica del vocabolario CPSV viene indicato il vocabolario Core Location Vocabulary (LOCN), 12 sviluppato sempre nell ambito del progetto ISA, per rappresentare i luoghi fisici quali ad esempio le sedi e gli uffici del comune. In questa sezione descriveremo brevemente il vocabolario LOCN. Il namespace del vocabolario LOCN è il seguente: locn: Nel vocabolario LOCN, una location viene definita come an identifiable geographic place. Tale vocabolario definisce tre classi per rappresentare le location: locn:location, locn:address e locn:geometry. La classe locn:location può essere usata per modellare luoghi e località quali ad esempio città, stati, monumenti, palazzi, laghi e così via. Una istanza della classe locn:location è caratterizzata innanzitutto da un locn:geographicname, specificato come testo semplice. Per l identificazione del nome geografico si consiglia di seguire le linee guida INSPIRE Data Specification on Geographical Names. 13 In aggiunta, un geographicidentifier deve essere specificato usando il corrispondente individuo nel dataset geonames. 14 La classe locn:address modella invece gli indirizzi. Per ogni istanza di questa classe, ove applicabili, vanno specificate le seguenti proprietá: fulladdress una stringa con la rappresentazione completa e comprensibile agli umani dell indirizzo; pobox equivale alla eventuale casella postale; thoroughfare il nome della via (o del viadotto o del fiume); locatordesignator il numero civico; locatorname l eventuale nome dell edificio; 12 core-location-vocabulary DataSpecification_GN_v3.0.1.pdf

6 addressarea area che non rappresenta una entità amministrativa, ad esempio un quartiere o una contrada; postname la città; adminunitl2 l area amministrativa di secondo livello cui la location appartiene, per l Italia si può prendere in considerazione la regione o la provincia; adminunitl1 la più grande entità amministrativa cui la location appartiene (lo stato), espressa usando i codici ISO (IT per l Italia); postcode equivale al codice di avviamento postale; addressid una URL che rappresenti l indirizzo secondo qualche convenzione riconosciuta. Infine, al classe Geometry fornisce una collocazione spaziale della risorsa in questione tramite valori qantitativi, usualmente latitudine e longitudine. Non vengono definite nuove proprietà per questa classe, ma si suggerisce di usare classi di vocabolari specializzati, ad esempio, le classi del vocabolario WSG84 lat/lon (vedi [?]). 15 Il diagramma delle classi presente in [?] mostra come ad una Legal Entity possa essere associato un indirizzo ufficiale come istanza di locn:address, mediante la proprietà locn:hasregisteredaddress. 16 Inoltre, istanze di locn:address e locn:geometry possono essere associate, mediante le rispettive proprietà locn:address e locn:geometry, direttamente alla risorsa in questione, o possono essere associate ad una istanza di locn:location, a sua volta associata ad una risorsa con la proprietà locn:location. 9 Il Vocabolario Organization Ontology I servizi pubblici sono erogati, direttamente o indirettamente, da Pubbliche Amministrazioni. A tal proposito ricordiamo che il dataset del Sistema Pubblico di Connettività e Cooperazione 17 comprende la base di dati ufficiale per l identificazione univoca delle pubbliche amministrazioni italiane, alla quale è possibile e opportuno fare riferimento. In particolare, i comuni sono catalogati con URI della forma ove < codice catastale > è il codice catastale del comune. Ricordiamo che il soggetto responsabile del servizio è collegato al servizio stesso con la proprietà cpsv:provides. Per modellare le pubbliche amministrazioni è appropriato l utilizzo del vocabolario vocabolario Organization Ontology (in breve ORG). 18 Tale vocabolario fornisce gli strumenti per descrivere La classe Legal Entity viene definita nel Core Business Vocabulary, sviluppato sempre all interno dell iniziativa ISA

7 le organizzazioni, pubbliche o private, in termini di struttura (unità, sottounità,... ), membri, ruoli ricoperti dai membri, strutture fisiche (di proprietà delle organizzazioni o dove queste svolgano le loro attività) ed eventuali mutamenti che ha subito l organizzazione nel corso degli anni (cambi di nome, unificazioni e divisioni). Il namespace di questo vocabolario è org: Le organizzazioni vengono modellate come istanze di org:organization. La sottoclasse org:formalorganization di org:organization viene utilizzata per modellare organizzazioni riconosciute nel mondo intero, ad esempio corporazioni, governi e chiese. Si noti che org:formalorganization è sottoclasse di gr:businessentity, ove gr è il namespace dell ontologia per il commercio elettronico GoodRelations 19 gr: La struttura gerarchica di una organizzazione che comprenda delle sotto-organizzazioni viene espressa tramite la proprietà org:suborganizationof e la sua inversa org:hassuborganization. Nel caso in cui la sotto-organizzazione abbia un senso solo nel contesto dell organizzazione principale, è indicato rappresentarla come istanza della classe org:organizationalunit, specializzazione a sua volta di org:organization. In questo caso, per descrivere la relazione tra questa e l organizzazione cui fa capo possono essere usate le proprietà org:unitof e org:hasunit, rispettivamente sotto-proprietà di org:suborganizationof e org:hassuborganization. L utilizzo della classe org:organizationalunit è appropriato, ad esempio, nel caso in cui la sotto-organizzazione non abbia di per se una identitá legalmente riconosciuta, ad esempio quando di parla di dipartimenti. Le tipologie per scopo (ONLUS, associazioni di promozione sociale,... ) possono essere concettualizzate e codificate in tesauri usando il vocabolario SKOS. Successivamente, ad ogni organizzazione può essere associata una categoria definita in un tale tesauro mediante la proprietà org:classification (vedi anche org:purpose). I membri dell organizzazione vengono indicati con la proprietà org:memberof, specificandoli come istanze di foaf:agent. Specificando delle sottoproprietà di org:memberof è possibile definire dei ruoli per i membri all organizzazione. In particolare, org:headof indica il vertice dell organizzazione. Viene indicato anche un meccanismo per la definizione di relazioni n-arie di appartenenza basato sulla reificazione, che non richiamiamo in questa sede. org:post viene utilizzata per indicare delle posizioni all interno di una organizzazione, siano esse attualmente piene o vacanti. Una posizione è collegata alla organizzazione mediante la proprietà org:postin, mentre una persona è messa in relazione con la (o le) posizione che attualmente ricopre tramite la proprietà org:holds. Ad ogni istanza di org:post può essere associata una istanza di org:role. org:reportsto è una relazione tra membri dell organizzazione o

8 tra posizioni, ed indica un rapporto di subordinazione. Ad ogni ruolo infine può essere associata una remunerazione (org:remuneration), specificata come istanza della classe gr:pricespecification. La proprietà org:hasite serve a specificare le sedi di una organizzazione. Con org:hasregisteredsite si indicano le sedi legali, mentre org:hasprimarysite si indicano le locazioni presso le quali è possibile accedere all organizzazione. Ogni sede deve essere dichiarata come una istanza di org:site, e l indirizzo della sede va specificato con org:siteaddress utilizzando altri vocabolari. È possibile indicare un sito nel quale un membro di una associazione opera con org:basedat. Nulla vieta di specificare molteplici siti per un singolo individuo. Inoltre, anche se non è detto esplicitamente, nel caso in cui un sito abbia svariati ingressi riteniamo sia lecito associare diversi indirizzi al sito stesso, uno per ogni ingresso. Le modifiche sostanziali all organizzazione vengono descritte come org:changeevent, ed utilizzando gli strumenti espressivi forniti dal vocabolario PROV-O. 20 La classe org:organizationalcollaboration viene indicata per rappresentare aggregazioni temporanee o permanenti che coinvolgano diverse associazioni, ad esempio consorzi o gruppi di lavoro collegati ad un progetto. La claase org:organizationalcollaboration è definita come sottoclasse di org:organization, ossia una siffatta aggregazione viene trattata come una organizzazione. Per i contatti telefonici, le caselle mail e le pagine web associate alle organizzazioni e alle unità operative si sceglie in questa sede di adottare le proprietà definite nel vocabolario FOAF foaf:phone, foaf:mbox e foaf:homepage, esendo la classe org:organizarion definita come specializzazione della classe foaf:agent. Si noti che nel caso in cui la mail, il telefono o la pagina web siano riferite ad una posizione all interno dell organizzazione o dell unità (ad esempio mailto://direttore@comune.it), esse vanno collegate all istanza di Post che rappresenta la posizione. I numeri di telefono vanno rappresentati come individui seguendo l URI Scheme specificato nello RFC2806. Di seguito riportiamo due esempi di URL per numeri di telefono e fax, rispettivamente: tel: fax: Un Ontologia per i Servizi Pubblici nel Comune di Catania In questa sezione presentiamo a titolo di esempio una ontologia che contiene le informazioni relative ad alcuni servizi offerti dal comune di catania. Come namespace viene scelta una URL con dominio quello del sito del comune di catania, abbreviato col prefisso cct: c c t : http : / /www. comune. c a t a n i a. i t / s e r v i c e s o n t. owl#

9 È opportuno ma non obbligatorio che il file contenente l ontologia venga reso disponibile allo stesso indirizzo indicato come namespace Struttura del comune La struttura organizzativa del comune è disponibile sul sito stesso del comune alla pagina Gli indirizzi e i recapiti telefonici sono invece forniti nella sezione dedicata alle relazioni col pubblico: Descriviamo questa struttura organizzativa utilizzando l ontologia ORG, richiamata alla Sezione 9. Innanzitutto definiamo un individuo che rappresenti il comune di Catania. Tale individuo avrà la stessa URI di quello corrispondente al comune di Catania nel dataset del sistema pubblico di connettività e cooperazione citato nella Sezione 9: Riportiamo qui a titolo informativo alcuni dati riguardanti il comune di catania come entità geopolitica, e non inteso come pubblica amministrazione. L individuo corrispondente nell ontologia geonames 21 è org/ /, mentre nel dataset dell ISTAT 22 l area del comune di Catania è identificata dall individuo con uri 1.2/CL_REFAREA/ La struttura amministrativa del comune è suddivisa in diverse direzioni (Direzione Lavori Pubblici e Protezione Civile, Direzione Manutenzioni -SS.TT. Servizi Cimiteriali - Demolizioni Opere Abusive,... ), raggruppate in due macroaree. Non ci è stato possibile rintracciare questa struttura nel sistema di pubblica connettività, per cui verranno inseriti degli individui con URI create adhoc a rappresentare i vari uffici qualora ve ne fosse bisogno. Tali URI sono nel namespace dell ontologia ad indicare che non si tratta di identificativi ufficiali. Secondo quanto indicato nella Sezione 9, specifichiamo un sito per ogni direzione. Tale sito è contemporaneamente una locn:location (vedi Sezione 8), per la quale sono disponibili l indirizzo(locn:address) e le coordinate (locn:geometry), ed una istanza di org:site. A tal proposito, nella nostra ontologia definiamo un collegamento tra i vocabolari LOCN e ORG specificando che la proprietà org:hassite è una sotto-proprietà di locn:location. Utilizzeremo la seguente convenzione: se cct:direzione x è l individuo che rappresenta la direzione che stiamo andando a modellare, cct:direzione x site, cct:direzione x address, cct:direzione x geometry saranno rispettivamene

10 gli individui per la location, l indirizzo e il punto delle coordinate di quella direzione. Nel presente lavoro si indicherà un unica sede per ogni direzione. Nel caso in cui due direzioni abbiano sede nello stesso edificio, chiaramente si riporterà un unico individuo di classe org:site, utilizzando la nomenclatura precedente per una sola delle direzioni coinvolte (non viene specificato alcun criterio di scelta). Un caso particolare è la direzione urbanistica. Essa ha una sua segreteria, ed offre svariati servizi, tra cui quello di front-office. 23 Ad ognuno di questi sono assegnati diversi numeri di telefono. Inoltre, il front-office è disponibile ad un altro indirizzo rispetto alla direzione (stesso edificio, altro ingresso) Conferimento Farmaci Scaduti Prendiamo adesso in considerazione il servizio per il conferimento di farmaci scaduti. Come visto in precedenza, il sevizio va modellato come istanza della classe cpsv:publicservice. Per il servizio in questione scegliamo una uri interna al namespace dell ontologia dei servizi del comune: cct:farmaciscaduti. Si noti che non è obbligatorio che le uri con le quali indichiamo gli elementi nella nostra ontologia ricadano all interno del namespace dell ontologia stessa. Il comune offre sul suo sito informazioni sul servizio e su come accedervi attraverso una apposita pagina web. 24 Tale pagina viene modellata come istanza di foaf:document e collegata al servizio tramite la proprietà foaf:homepage. Nella stessa pagina vengono forniti: una descrizione del servizio, la normativa comunitaria di riferimento che ha dato luogo all implementazione del servizio (direttiva del Parlamento europeo 2004/27/CE) e un elenco delle farmacie nelle quali è possibile conferire i farmaci scaduti. Forniamo quindi un titolo Smaltimento farmaci scaduti per il servizio che andiamo a descrivere con la proprietà dcterms:title e riportiamo pedissequamente la descrizione contenuta nel sito attraverso la proprietà dcterms:description. Si noti che questi metadati non assumono particolare rilevanza semantica, ma sono utili solo a livello di presentazione del servizio in una pagina web o in un applicativo. In particolare, il titolo indica la tipologia del servizio, che verrà tuttavia ulteriormente specificata facendo riferimento alla ESD Toolkit s Service List sopracitata. A tal proposito, nella lista dei servizi della ESD Toolkit è presente la tipologia Commercial clinical waste disposal: Collection and safe disposal of clinical waste. This includes items such as surgical waste, used syringes, drugs and pharmaceuticals. caratterizzata dalla URI Ricordiamo che ad ogni servizio viene associata la tipologia attraverso la proprietà dcterms:type. All autore di questo documento non sono noti gli atti legislativi che hanno dato luogo alla creazione di questo servizio, ne quelli che lo regolamentano direzioni/urbanistica/orario-di-ricevimento/ 24 direzioni/ambiente/farmaci-scaduti/ 10

11 È nota invece la direttiva dell unione europea per conformarsi alla quale il servizio è stato creato. Per cui viene creato una istanza non meglio specificata di cpsv:rule ad indicare il regolamento, che si intende specificare meglio in un secondo momento, collegata però con la direttiva del Parlamento europeo 2004/27/CE mediante la proprietà cpsv:implements. La URI di tale direttiva, secondo il protocollo sopracitato ELI, è la seguente: Il servizio di smaltimento di farmaci scaduti viene erogato dalla Direzione Ecologia, Ambiente e Nettezza Urbana, 25 che a sua volta si trova all interno della prima area di coordinamento del comune. Introduciamo quindi due individui atti a rappresentare la prima area di coordinamento (cct:area1) e la direzione ecologia e ambiente (cct:direzione ecologia ambiente nu). Il primo di questi viene specificato come unità del comune tramite la proprietá org:hasunit. Analogamente, l individuo che rappresenta la direzione in questione viene specificato come unità operativa dell area uno di coordinamento. Infine, la direzione viene collegata al servizio tramite la proprietà cpsv:provides. Nel sito del comune vengono forniti l indirizzo della direzione, i contatti telefonici ed un indirizzo mail del direttore. Come indicato nella Sezione 8, definiamo quindi un individuo per la locazione della direzione ambiente, cct:direzione ecologia ambiente nu s che sarà collegato alla Direzione Ambiente tramite la proprietà org:hasite. Al sito colleghiamo l indirizzo (cct:direzione ecologia ambiente nu address) e le coordinate cct:direzione ecologia ambiente nu point. I contatti telefonici sono relativi alla direzione stessa. Vengono quindi collegati all individuo associato alla direzione tramite le proprietà foaf:phone come indicato nella Sezione 9. Per quanto riguarda la casella , viene fornita la mail del direttore. Inizialmente si era pensato di creare una posizione corrispondente al direttore e di associarvi una mail. Tuttavia, la proprietà foaf:mbox si applica solo agli agenti, e una posizione non può essere considerata tale. Per cui, la casella mail indicata viene assegnata direttamente alla direzione. Il servizio di conferimento di siringhe usate e farmaci scaduti viene effettuato presso alcune farmacie nelle quali sono presenti degli appositi raccoglitori. Sul sito della direzione ecologia è presente l elenco e l indirizzo di tali farmacie. Come indicato alla Sezione 5, tali location vanno collegate la servizio tramite la proprietà cpsv:physicallylocatedat. Nel nostro caso, le farmacie vengono indicate come istanze di locn:location, tralasciando quindi che si tratti nello specifico di farmacie e la ragione sociale delle stesse. Inoltre, per alcune farmacie gli indirizzi presenti sul sito risultano incompleti, per cui una geolocalizzazione risulta impossibile. Un caso particolare di Location non trattata fino ad ora è rappresentato dalla farmacia al seguente indirizzo: Villaggio Sant Agata Zona A 26. In questo caso non abbiamo il nome di una strada, quindi la proprietà locn:thoroughfare non può essere utilizzata. Abbiamo invece il quartiere (Vil direzioni/ambiente/ 11

12 laggio Sant Agata), una zona all interno del quartiere (Zona A), derivante da una suddivisione specifica del quartiere in questione, ed il numero civico (26). In questo caso si decide di accorpare il quartiere e la zona, specificandoli come locn:addressarea. Riportiamo quindi in Figura 1 un esempio di modellazione del servizio di conferimento farmaci scaduti in RDF/XML. Si noti che in questo esempio non vengono riportati gli individui relativi alle location nelle quali il servizio è accessibile, ma solo i collegamenti tra il servizio e questi luoghi (cpsv:physicallylocatedat). 11 Collegamento con il Sistema informativo Territoriale Attualmente una versione Linked Open Data di un dump di parte dei dati del Sistema Informativo Territoriale (in breve SIT ) viene fornita dal CNR allo endpoint SPARQL disponbile all indirizzo Il processo di conversione dei dati del SIT in Linked Open Data viene descritto in [4]. Nel dataset accessibile tramite l endpoint sopraindicato è stato definito un grafo prisma. Nel seguito indicheremo con MoC (acronimo per Municipality of Catania) il dataset fornito dal CNR generato a partire dai dati del Sistema Informativo Territoriale di Catania. Nel seguito useremo nelle abbreviazioni delle uri il seguente prefisso: prisma : < Per garantire l interoperabilità tra l ontologia di esempio realizzata in questa sede e quella realizzata dal CNR, si è deciso di creare dei collegamenti, mediante la proprietà ccn:hasmoc definita per questo scopo, tra le istanze di locn:location nella nostra ontologia e i corrispondenti individui nell ontologia del SIT. Gli elementi descritti nell endpoint del CNR appartengono alle segueni categorie: Archi Stradali, Contorno Densità, Pubblica Sicurezza, Sedi Servizi Sociali, Aree di Emergenza, Farmacie, Rete Fibra Ottica, Sezioni Censimento 1991, Sezioni Censimento 2001, Carceri, Isolati, Rete Gas, Case Riposo, Municipalità, Aree, Uffici Comunali, Centraline Smog, Numeri Civici, Scuole, Università, Chiese, Ospedali, Semafori, Circoscrizioni, Poste, Serbatoi Idrici, Aree Verde, Confini Comunali, Piano Regolatore Generale, Aree Servizi Sociali, Vigili del Fuoco. Per ognuna di queste categorie è definita una classe corrispondente. Ad esempio, per le farmacie è definita la classe prisma:farmacia. Con la query in Figura 2 è possibile ricavare l elenco di tutte le farmacie presenti nel dataset MoC. Ad ogni entità georeferenziata, come ad esempio una farmacia, è associato un numero civico, istanza della classe prisma:numerocivico, attraverso la proprietà prisma:indirizzo. Un esempio di numero civico è il seguente: 12

13 <cpsv:publicservice rdf:about="&cct;farmaci_scaduti"> <rdfs:label>conferimento farmaci scaduti</rdfs:label> <dcterms:title>conferimento farmaci scaduti</dcterms:title> <dcterms:description>le sostanze tossiche contenute nei farmaci scaduti possono inquinare il suolo e l acqua. I farmaci scaduti, raccolti separatamente e conferiti negli appositi cont prossimità di farmacie, possono essere trattati da ditte specializzate in modo tale che essi non possano nuocere alla nostra salute. E quindi necessario smaltirli separatamente, second procedure previste dalla legge. Tra le normative di riferimento, c è anche la direttiva del Parlamento europeo (la 2004/27/CE), che disciplina l uso dei "medicinali per uso umano" e stabilisce che "gli Stati membri introducono, per i medicinali inutilizzati o scaduti, idon sistemi di raccolta". La raccolta capillare in alcune delle farmacie della nostra città consentirà il recupero ed il successivo corretto smaltimento dei farmaci, delle siringhe e degli aghi usati. Il contenitore sarà alloggiato all interno o in prossimità della farmacia, in posizione visibile e facilmente raggiungibile dai cittadini. Il cittadino, seguendo le ist dovrà inserirvi unicamente il farmaco, l ago o la siringa, trattenendo quindi l involucro in carta o cartoncino che dovrà essere smaltito nella raccolta differenziata della carta. </dcterms:description> <foaf:homepage rdf:resource=" <dcterms:type rdf:resource=" /> <cpsv:follows> <cpsv:rule rdf:about="&cct;farmaci_scaduti_rule"> <cpsv:implements rdf:resource=" /> </cpsv:rule> </cpsv:follows> <cpsv:physicallylocatedat rdf:resource="via_garibaldicatania24it" /> <cpsv:physicallylocatedat rdf:resource="via_plebiscitocatania534it" /> <cpsv:physicallylocatedat rdf:resource="via_etneacatania79it" /> <cpsv:physicallylocatedat rdf:resource="piazza_carlo_albertocatania18it" /> <cpsv:physicallylocatedat rdf:resource="via_francesco_crispicatania195it" /> <cpsv:physicallylocatedat rdf:resource="viale_mario_rapisardicatania320it" /> <cpsv:physicallylocatedat rdf:resource="viale_librinocatania15it" /> <cpsv:physicallylocatedat rdf:resource="piazza_stesicorocatania36it" /> <cpsv:physicallylocatedat rdf:resource="via_garibaldicatania376it" /> <cpsv:physicallylocatedat rdf:resource="via_etneacatania238it" />... </cpsv:publicservice> Figure 1: Frammento RDF/XML per la rappresentazione del servizio di conferimento farmaci scaduti 13

14 PREFIX prisma: < SELECT?x FROM <prisma> WHERE{?x a prisma:farmacia. } Figure 2: Query per ottenere le farmacie nel dataset MoC In genere, la URI dell indirizzo corrispondente alla via o piazza v e numero civico n nel dataset MoC può essere ottenuta come segue con civicnump refix uguale a φ(v, n) := civicnumprefixv n. e v ottenuto da v 1. convertendo tutta la stringa in minuscono, 2. sostituendo gli spazi con il carattere -, 3. sostituendo eventuali vocali accentate con le corrispondenti non accentate e, infine, 4. eliminando eventuali apostrofi. Dato quindi un indirizzo nel comune di Catania corrispondente alla via o piazza v e numero civico n, e posto addressurl := φ(v, n), è possibile verificare che esso sia presente nel dataset MoC accertandosi che la seguente query restituisca almeno un insieme non vuoto di risultati: PREFIX prisma: < SELECT?x FROM <prisma> WHERE{?x prisma:indirizzo addressurl. } È importante notare che i nomi delle vie e piazze che si riferiscono ad un personaggio pubblico vengno spesso riporati nel dataset MoC nell ordine Cognome- Nome. Ad esempio, l indirizzo Viale Mario Rapisardi è identificato da un individuo con la seguente URI: 14

15 References [1] Tim Berners-Lee, James Hendler, and Ora Lassila. The Semantic Web. Scientific American Magazine, May [2] Christian Bizer, Tom Heath, and Tim Berners-Lee. Linked Data - The Story So Far. Int. J. Semantic Web Inf. Syst., 5(3):1 22, [3] G. Ciasullo, Giorgia Lodi, A. Maccioni, A. Rotundo, and F. Tortorelli. Linee guida nazionali per la valorizzazione del patrimonio informativo pubblico (anno 2014). Technical report, Agenzia per l Italia Digitale (AgID), Presidenza del Consiglio dei Ministri Italiano. [4] Sergio Consoli, Aldo Gangemi, Andrea Giovanni Nuzzolese, Silvio Peroni, Valentina Presutti, Diego Reforgiato Recupero, and Daria Spampinato. Geolinked open data for the municipality of catania. In Rajendra Akerkar, Nick Bassiliades, John Davies, and Vadim Ermolayev, editors, 4th International Conference on Web Intelligence, Mining and Semantics (WIMS 14), WIMS 14, Thessaloniki, Greece, June 2-4, 2014, page 58, [5] European Council. Council conclusions inviting the introduction of the European Legislation Identifier (ELI). Official Journal of the European Union. uri=oj:c:2012:325:0003:0011:en:pdf. [6] Dave Reynolds. The organization ontology. Technical report, W3C, [7] Nigel Shadbolt, Tim Berners-Lee, and Wendy Hall. The Semantic Web Revisited. IEEE Intelligent Systems, 21(3):96 101, May