An architecture for scaling ontology networks

Constructing ontology networks typically occurs at design time at the hands of knowledge engineers who assemble their components statically. There are, however, use cases where ontology networks need to be assembled upon request and processed at runtime, without altering the stored ontologies and without tampering with one another. These are what we call "virtual [ontology] networks", and keeping track of how an ontology changes in each virtual network is called "multiplexing". Issues may arise from the connectivity of ontology networks. In many cases, simple flat import schemes will not work, because many ontology managers can cause property assertions to be erroneously interpreted as annotations and ignored by reasoners. Also, multiple virtual networks should optimize their cumulative memory footprint, and where they cannot, this should occur for very limited periods of time. We claim that these problems should be handled by the software that serves these ontology networks, rather than by ontology engineering methodologies. We propose a method that spreads multiple virtual networks across a 3-tier structure, and can reduce the amount of erroneously interpreted axioms, under certain raw statement distributions across the ontologies. We assumed OWL as the core language handled by semantic applications in the framework at hand, due to the greater availability of reasoners and rule engines. We also verified that, in common OWL ontology management software, OWL axiom interpretation occurs in the worst case scenario of pre-order visit. To measure the effectiveness and space-efficiency of our solution, a Java and RESTful implementation was produced within an Apache project. We verified that a 3-tier structure can accommodate reasonably complex ontology networks better, in terms of the expressivity OWL axiom interpretation, than flat-tree import schemes can. We measured both the memory overhead of the additional components we put on top of traditional ontology networks, and the framework's caching capabilities.

Recupero della funzione renale in pazienti con acute kidney injury (AKI) sottoposti a terapia sostitutiva renale

L’insufficienza renale acuta(AKI) grave che richiede terapia sostitutiva, è una complicanza frequente nelle unità di terapia intensiva(UTI) e rappresenta un fattore di rischio indipendente di mortalità. Scopo dello studio é stato valutare prospetticamente, in pazienti “critici” sottoposti a terapie sostitutive renali continue(CRRT) per IRA post cardiochirurgia, la prevalenza ed il significato prognostico del recupero della funzione renale(RFR). Pazienti e Metodi:Pazienti(pz) con AKI dopo intervento di cardiochirurgia elettivo o in emergenza con disfunzione di due o più organi trattati con CRRT. Risultati:Dal 1996 al 2011, 266 pz (M 195,F 71, età 65.5±11.3aa) sono stati trattati con CRRT. Tipo di intervento: CABG(27.6%), dissecazione aortica(33%), sostituzione valvolare(21.1%), CABG+sostituzione valvolare(12.6%), altro(5.7%). Parametri all’inizio del trattamento: BUN 86.1±39.4, creatininemia(Cr) 3.96±1.86mg/dL, PAM 72.4±13.6mmHg, APACHE II score 30.7±6.1, SOFAscore 13.7±3. RIFLE: Risk (11%), Injury (31.4%), Failure (57.6%). AKI oligurica (72.2%), ventilazione meccanica (93.2%), inotropi (84.5%). La sopravvivenza a 30 gg ed alla dimissione è stata del 54.2% e del 37.1%. La sopravvivenza per stratificazione APACHE II: <24=85.1 e 66%, 25-29=63.5 e 48.1%, 30-34=51.8 e 31.8%, >34=31.6 e 17.7%. RFR ha consentito l’interruzione della CRRT nel 87.8% (86/98) dei survivors (Cr 1.4±0.6mg/dL) e nel 14.5% (24/166) dei nonsurvivors (Cr 2.2±0.9mg/dL) con un recupero totale del 41.4%. RFR è stato osservato nel 59.5% (44/74) dei pz non oligurici e nel 34.4% dei pz oligurici (66/192). La distribuzione dei pz sulla base dei tempi di RFR è stata:<8=38.2%, 8-14=20.9%, 15-21=11.8%, 22-28=10.9%, >28=18.2%. All’analisi multivariata, l’oliguria, l’età e il CV-SOFA a 7gg dall’inizio della CRRT si sono dimostrati fattori prognostici sfavorevoli su RFR(>21gg). RFR si associa ad una sopravvivenza elevata(78.2%). Conclusioni:RFR significativamente piu frequente nei pz non oligurici si associa ad una sopravvivenza alla dimissione piu elevata. La distribuzione dei pz in rapporto ad APACHE II e SOFAscore dimostra che la sopravvivenza e RFR sono strettamente legati alla gravità della patologia.

Analisi e valutazione della piattaforma Spark

Negli ultimi anni i dati, la loro gestione e gli strumenti per la loro analisi hanno subito una trasformazione. Si è visto un notevole aumento dei dati raccolti dagli utenti, che si aggira tra il 40 e il 60 percento annuo, grazie ad applicazioni web, sensori, ecc.. Ciò ha fatto nascere il termine Big Data, con il quale ci si riferisce a dataset talmente grandi che non sono gestibili da sistemi tradizionali, come DBMS relazionali in esecuzione su una singola macchina. Infatti, quando la dimensione di un dataset supera pochi terabyte, si è obbligati ad utilizzare un sistema distribuito, in cui i dati sono partizionati su più macchine. Per gestire i Big Data sono state create tecnologie che riescono ad usare la potenza computazionale e la capacità di memorizzazione di un cluster, con un incremento prestazionale proporzionale al numero di macchine presenti sullo stesso. Il più utilizzato di questi sistemi è Hadoop, che offre un sistema per la memorizzazione e l’analisi distribuita dei dati. Grazie alla ridondanza dei dati ed a sofisticati algoritmi, Hadoop riesce a funzionare anche in caso di fallimento di uno o più macchine del cluster, in modo trasparente all’utente. Su Hadoop si possono eseguire diverse applicazioni, tra cui MapReduce, Hive e Apache Spark. É su quest’ultima applicazione, nata per il data processing, che è maggiormente incentrato il progetto di tesi. Un modulo di Spark, chiamato Spark SQL, verrà posto in confronto ad Hive nella velocità e nella flessibilità nell’eseguire interrogazioni su database memorizzati sul filesystem distribuito di Hadoop.

Implementazione di una infrastruttura basata su Kafka e Storm per il Mobile Cloud computing

Lo scopo dell'elaborato di tesi è l'analisi, progettazione e sviluppo di un prototipo di una infrastruttura cloud in grado di gestire un grande flusso di eventi generati da dispositivi mobili. Questi utilizzano informazioni come la posizione assunta e il valore dei sensori locali di cui possono essere equipaggiati al fine di realizzare il proprio funzionamento. Le informazioni così ottenute vengono trasmesse in modo da ottenere una rete di device in grado di acquisire autonomamente informazioni sull'ambiente ed auto-organizzarsi. La costruzione di tale struttura si colloca in un più ampio ambito di ricerca che punta a integrare metodi per la comunicazione ravvicinata con il cloud al fine di permettere la comunicazione tra dispositivi vicini in qualsiasi situazione che si potrebbe presentare in una situazione reale. A definire le specifiche della infrastruttura e quindi a impersonare il ruolo di committente è stato il relatore, Prof. Mirko Viroli, mentre lo sviluppo è stato portato avanti da me e dal correlatore, Ing. Pietro Brunetti. Visti gli studi precedenti riguardanti il cloud computing nell'area dei sistemi complessi distribuiti, Brunetti ha dato il maggiore contributo nella fase di analisi del problema e di progettazione mentre la parte riguardante la effettiva gestione degli eventi, le computazioni in cloud e lo storage dei dati è stata maggiormente affrontata da me. In particolare mi sono occupato dello studio e della implementazione del backend computazionale, basato sulla tecnologia Apache Storm, della componente di storage dei dati, basata su Neo4j, e della costruzione di un pannello di visualizzazione basato su AJAX e Linkurious. A questo va aggiunto lo studio su Apache Kafka, utilizzato come tecnologia per realizzare la comunicazione asincrona ad alte performance tra le componenti. Si è reso necessario costruire un simulatore al fine di condurre i test per verificare il funzionamento della infrastruttura prototipale e per saggiarne l'effettiva scalabilità, considerato il potenziale numero di dispositivi da sostenere che può andare dalle decine alle migliaia. La sfida più importante riguarda la gestione della vicinanza tra dispositivi e la possibilità di scalare la computazione su più macchine. Per questo motivo è stato necessario far uso di tecnologie per l'esecuzione delle operazioni di memorizzazione, calcolo e trasmissione dei dati in grado di essere eseguite su un cluster e garantire una accettabile fault-tolerancy. Da questo punto di vista i lavori che hanno portato alla costruzione della infrastruttura sono risultati essere un'ottima occasione per prendere familiarità con tecnologie prima sconosciute. Quasi tutte le tecnologie utilizzate fanno parte dell'ecosistema Apache e, come esposto all'interno della tesi, stanno ricevendo una grande attenzione da importanti realtà proprio in questo periodo, specialmente Apache Storm e Kafka. Il software prodotto per la costruzione della infrastruttura è completamente sviluppato in Java a cui si aggiunge la componente web di visualizzazione sviluppata in Javascript.

Deployment automatico di applicazioni specificate in linguaggio ABS

Da quando è iniziata l'era del Cloud Computing molte cose sono cambiate, ora è possibile ottenere un server in tempo reale e usare strumenti automatizzati per installarvi applicazioni. In questa tesi verrà descritto lo strumento MODDE (Model-Driven Deployment Engine), usato per il deployment automatico, partendo dal linguaggio ABS. ABS è un linguaggio a oggetti che permette di descrivere le classi in una maniera astratta. Ogni componente dichiarato in questo linguaggio ha dei valori e delle dipendenze. Poi si procede alla descrizione del linguaggio di specifica DDLang, col quale vengono espressi tutti i vincoli e le configurazioni finali. In seguito viene spiegata l’architettura di MODDE. Esso usa degli script che integrano i tool Zephyrus e Metis e crea un main ABS dai tre file passati in input, che serve per effettuare l’allocazione delle macchine in un Cloud. Inoltre verranno introdotti i due sotto-strumenti usati da MODDE: Zephyrus e Metis. Il primo si occupa di scegliere quali servizi installare tenendo conto di tutte le loro dipendenze, cercando di ottimizzare il risultato. Il secondo gestisce l’ordine con cui installarli tenendo conto dei loro stati interni e delle dipendenze. Con la collaborazione di questi componenti si ottiene una installazione automatica piuttosto efficace. Infine dopo aver spiegato il funzionamento di MODDE viene spiegato come integrarlo in un servizio web per renderlo disponibile agli utenti. Esso viene installato su un server HTTP Apache all’interno di un container di Docker.

Una app ibrida per l'apprendimento incidentale delle lingue straniere.

La tesi è strutturata in tre macro capitoli: • e-learning: questo capitolo tratta i tre principi su cui è basato questo progetto quali e-learning, m-learning ed incidental learning descrivendo l’evoluzione di questi tre concetti e analizzando ognuno di essi nel dettaglio partendo dal principio, l’e-learning. Verranno poi presentati dei progetti inerenti a queste tipologie di apprendimento per fare in modo di dare un’idea più chiara di questi concetti. • Specifiche di progetto: in questo secondo capitolo vengono descritte, ad alto livello, le tecnologie utilizzate per lo sviluppo di questo progetto, descrivendo, per ognuna, le caratteristiche e le applicazioni che essa ha avuto all’interno del progetto. • Implementazione: nel terzo e ultimo capitolo verranno descritte, e motivate, le scelte implementative adottate per sviluppare l’applicazione iLocalApp e verranno mostrati scorci di codice per rendere più chiaro l’utilizzo delle varie API e tecnologie all’interno del progetto.

Progettazione e sviluppo di un'applicazione mobile di supporto alle attivita sciistiche

Applicazione Multi-piattaforme allineata per spostamenti in montagna, che offre le funzionalità di tracciamento tra diversi utenti, raggiungimento fisico di bersagli con compimento di missioni premiati e un sistema d'emergenza.

Progettazione di Data Warehouse di dati genomici su piattaforma Hadoop

Negli ultimi anni la biologia ha fatto ricorso in misura sempre maggiore all’informatica per affrontare analisi complesse che prevedono l’utilizzo di grandi quantità di dati. Fra le scienze biologiche che prevedono l’elaborazione di una mole di dati notevole c’è la genomica, una branca della biologia molecolare che si occupa dello studio di struttura, contenuto, funzione ed evoluzione del genoma degli organismi viventi. I sistemi di data warehouse sono una tecnologia informatica che ben si adatta a supportare determinati tipi di analisi in ambito genomico perché consentono di effettuare analisi esplorative e dinamiche, analisi che si rivelano utili quando si vogliono ricavare informazioni di sintesi a partire da una grande quantità di dati e quando si vogliono esplorare prospettive e livelli di dettaglio diversi. Il lavoro di tesi si colloca all’interno di un progetto più ampio riguardante la progettazione di un data warehouse in ambito genomico. Le analisi effettuate hanno portato alla scoperta di dipendenze funzionali e di conseguenza alla definizione di una gerarchia nei dati. Attraverso l’inserimento di tale gerarchia in un modello multidimensionale relativo ai dati genomici sarà possibile ampliare il raggio delle analisi da poter eseguire sul data warehouse introducendo un contenuto informativo ulteriore riguardante le caratteristiche dei pazienti. I passi effettuati in questo lavoro di tesi sono stati prima di tutto il caricamento e filtraggio dei dati. Il fulcro del lavoro di tesi è stata l’implementazione di un algoritmo per la scoperta di dipendenze funzionali con lo scopo di ricavare dai dati una gerarchia. Nell’ultima fase del lavoro di tesi si è inserita la gerarchia ricavata all’interno di un modello multidimensionale preesistente. L’intero lavoro di tesi è stato svolto attraverso l’utilizzo di Apache Spark e Apache Hadoop.

Elaborazione di Big Data: un’applicazione dello Speed Layer di Lambda Architecture

I Big Data hanno forgiato nuove tecnologie che migliorano la qualità della vita utilizzando la combinazione di rappresentazioni eterogenee di dati in varie discipline. Occorre, quindi, un sistema realtime in grado di computare i dati in tempo reale. Tale sistema viene denominato speed layer, come si evince dal nome si è pensato a garantire che i nuovi dati siano restituiti dalle query funcions con la rapidità in cui essi arrivano. Il lavoro di tesi verte sulla realizzazione di un’architettura che si rifaccia allo Speed Layer della Lambda Architecture e che sia in grado di ricevere dati metereologici pubblicati su una coda MQTT, elaborarli in tempo reale e memorizzarli in un database per renderli disponibili ai Data Scientist. L’ambiente di programmazione utilizzato è JAVA, il progetto è stato installato sulla piattaforma Hortonworks che si basa sul framework Hadoop e sul sistema di computazione Storm, che permette di lavorare con flussi di dati illimitati, effettuando l’elaborazione in tempo reale. A differenza dei tradizionali approcci di stream-processing con reti di code e workers, Storm è fault-tolerance e scalabile. Gli sforzi dedicati al suo sviluppo da parte della Apache Software Foundation, il crescente utilizzo in ambito di produzione di importanti aziende, il supporto da parte delle compagnie di cloud hosting sono segnali che questa tecnologia prenderà sempre più piede come soluzione per la gestione di computazioni distribuite orientate agli eventi. Per poter memorizzare e analizzare queste moli di dati, che da sempre hanno costituito una problematica non superabile con i database tradizionali, è stato utilizzato un database non relazionale: HBase.

Tecniche Cloud Avanzate per Adaptive Hadoop Load Balancing tramite Sahara

Ogni giorno vengono generati grandi moli di dati attraverso sorgenti diverse. Questi dati, chiamati Big Data, sono attualmente oggetto di forte interesse nel settore IT (Information Technology). I processi digitalizzati, le interazioni sui social media, i sensori ed i sistemi mobili, che utilizziamo quotidianamente, sono solo un piccolo sottoinsieme di tutte le fonti che contribuiscono alla produzione di questi dati. Per poter analizzare ed estrarre informazioni da questi grandi volumi di dati, tante sono le tecnologie che sono state sviluppate. Molte di queste sfruttano approcci distribuiti e paralleli. Una delle tecnologie che ha avuto maggior successo nel processamento dei Big Data, e Apache Hadoop. Il Cloud Computing, in particolare le soluzioni che seguono il modello IaaS (Infrastructure as a Service), forniscono un valido strumento all'approvvigionamento di risorse in maniera semplice e veloce. Per questo motivo, in questa proposta, viene utilizzato OpenStack come piattaforma IaaS. Grazie all'integrazione delle tecnologie OpenStack e Hadoop, attraverso Sahara, si riesce a sfruttare le potenzialita offerte da un ambiente cloud per migliorare le prestazioni dell'elaborazione distribuita e parallela. Lo scopo di questo lavoro e ottenere una miglior distribuzione delle risorse utilizzate nel sistema cloud con obiettivi di load balancing. Per raggiungere questi obiettivi, si sono rese necessarie modifiche sia al framework Hadoop che al progetto Sahara.

Temporal changes of coronary artery plaque located behind the struts of the everolimus eluting bioresorbable vascular scaffold

Implantation of a coronary stent results in a mechanical enlargement of the coronary lumen with stretching of the surrounding atherosclerotic plaque. Using intravascular ultrasound virtual-histology (IVUS-VH) we examined the temporal changes in composition of the plaque behind the struts (PBS) following the implantation of the everolimus eluting bioresorbable vascular scaffold (BVS). Using IVUS-VH and dedicated software, the composition of plaque was analyzed in all patients from the ABSORB B trial who were imaged with a commercially available IVUS-VH console (s5i system, Volcano Corporation, Rancho Cordova, CA, USA) post-treatment and at 6-month follow-up. This dedicated software enabled analysis of the PBS after subtraction of the VH signal generated by the struts. The presence of necrotic core (NC) in contact with the lumen was also evaluated at baseline and follow-up. IVUS-VH data, recorded with s5i system, were available at baseline and 6-month follow-up in 15 patients and demonstrated an increase in both the area of PBS (2.45 ± 1.93 mm(2) vs. 3.19 ± 2.48 mm(2), P = 0.005) and the external elastic membrane area (13.76 ± 4.07 mm(2) vs. 14.76 ± 4.56 mm(2), P = 0.006). Compared to baseline there was a significant progression in the NC (0.85 ± 0.70 mm(2) vs. 1.21 ± 0.92 mm(2), P = 0.010) and fibrous tissue area (0.88 ± 0.79 mm(2) vs. 1.15 ± 1.05 mm(2), P = 0.027) of the PBS. The NC in contact with the lumen in the treated segment did not increase with follow-up (7.33 vs. 6.36%, P = 0.2). Serial IVUS-VH analysis of BVS-treated lesions at 6-month demonstrated a progression in the NC and fibrous tissue content of PBS.

The effect of polymerization procedure on Vickers hardness of dual-curing resin cements

To investigate the surface hardness (Vickers hardness, HVN) of one light-curing flowable resin composite and five dual-curing resin cements after different polymerization procedures.

Influence of curing rate on softening in ethanol, degree of conversion, and wear of resin composite

PURPOSE: To investigate the effect of curing rate on softening in ethanol, degree of conversion, and wear of resin composites. METHOD: With a given energy density and for each of two different light-curing units (QTH or LED), the curing rate was reduced by modulating the curing mode. Thus, the irradiation of resin composite specimens (Filtek Z250, Tetric Ceram, Esthet-X) was performed in a continuous curing mode and in a pulse-delay curing mode. Wallace hardness was used to determine the softening of resin composite after storage in ethanol. Degree of conversion was determined by infrared spectroscopy (FTIR). Wear was assessed by a three-body test. Data were submitted to Levene's test, one and three-way ANOVA, and Tukey HSD test (alpha = 0.05). Results: Immersion in ethanol, curing mode, and material all had significant effects on Wallace hardness. After ethanol storage, resin composites exposed to the pulse-delay curing mode were softer than resin composites exposed to continuous cure (P< 0.0001). Tetric Ceram was the softest material followed by Esthet-X and Filtek Z250 (P< 0.001). Only the restorative material had a significant effect on degree of conversion (P< 0.001): Esthet-X had the lowest degree of conversion followed by Filtek Z250 and Tetric Ceram. Curing mode (P= 0.007) and material (P< 0.001) had significant effect on wear. Higher wear resulted from the pulse-delay curing mode when compared to continuous curing, and Filtek Z250 showed the lowest wear followed by Esthet-X and Tetric Ceram.

Analysis of 1 year virtual histology changes in coronary plaque located behind the struts of the everolimus eluting bioresorbable vascular scaffold

Serial intravascular ultrasound virtual histology (IVUS-VH) after implantation of metallic stents has been unable to show any changes in the composition of the scaffolded plaque overtime. The everolimus-eluting ABSORB scaffold potentially allows for the formation of new fibrotic tissue on the scaffolded coronary plaque during bioresorption. We examined the 12 month IVUS-VH changes in composition of the plaque behind the struts (PBS) following the implantation of the ABSORB scaffold. Using IVUS-VH and dedicated software, the composition of the PBS was analyzed in all patients from the ABSORB Cohort B2 trial, who were imaged with a commercially available IVUS-VH console (s5i system, Volcano Corporation, Rancho Cordova, CA, USA), immediately post-ABSORB implantation and at 12 month follow-up. Paired IVUS-VH data, recorded with s5i system, were available in 17 patients (18 lesions). The analysis demonstrated an increase in mean PBS area (2.39 ± 1.85 mm(2) vs. 2.76 ± 1.79 mm(2), P = 0.078) and a reduction in the mean lumen area (6.37 ± 0.90 mm(2) vs. 5.98 ± 0.97 mm(2), P = 0.006). Conversely, a significant decrease of 16 and 30% in necrotic core (NC) and dense calcium (DC) content, respectively, were evident (median % NC from 43.24 to 36.06%, P = 0.016; median % DC from 20.28 to 11.36%, P = 0.002). Serial IVUS-VH analyses of plaque located behind the ABSORB struts at 12-month demonstrated an increase in plaque area with a decrease in its NC and DC content. Larger studies are required to investigate the clinical impact of these findings.

Interleukin-6, -7, -8 and -10 predict outcome in acute myocardial infarction complicated by cardiogenic shock

The IABP-SHOCK-trial was a morbidity-based randomized controlled trial in patients with infarction-related cardiogenic shock (CS), which used the change of the quantified degree of multiorgan failure as determined by APACHE II score over a 4-day period as primary outcome measure. The prospective hypothesis was that adding IABP therapy to "standard care" would improve CS-triggered multi organ dysfunction syndrome (MODS). The primary endpoint showed no difference between conventionally managed cardiogenic shock patients and those with IABP support. In an inflammatory marker substudy, we analysed the prognostic value of interleukin (IL)-1β, -6, -7, -8, and -10 in patients with acute myocardial infarction complicated by cardiogenic shock.