standard di documentazione cluster - SWOP

Transcript

UNIONE EUROPEA
FONDO EUROPEO DI SVILUPPO REGIONALE.
REGIONE PUGLIA
AREA POLITICHE PER LO SVILUPPO IL LAVORO E L’INNOVAZIONE
Modello M15 – SAL intermedio
POR PUGLIA 2007-2013 - Asse I Linea 1.1 – Azione 1.1.2
Bando “Aiuti agli Investimenti in Ricerca per le PMI”
BENEFICIARIO
Code Architects S.r.l.
TITOLO DEL PROGETTO
SWOP
Semantic Web-service Oriented Platform
CODICE DEL PROGETTO
B2SO201
RELAZIONE STATO AVANZAMENTO LAVORI
Periodo:
dal:
01/07/2009 al:
30/06/2010
Durata contrattuale:
dal:
01/07/2009
al:
31/12/2010
Durata prevista:
dal:
01/07/2009
al:
31/12/2010
SCHEDA A
IDENTIFICAZIONE DELLE ATTIVITA’ (OR) E SOTTOATTIVITA’ (TASKS)
PREVISTE NEL PERIODO DI RIFERIMENTO DEL PROGETTO SECONDO
LA SEGUENTE RIPARTIZIONE:
1) attività avviate nel periodo di riferimento e non concluse nello stesso:
CODICE
TITOLO
OR4
DISSEMINAZIONE DEI RISULTATI DI RICERCA
OR5
GESTIONE DEL PROGETTO
2) attività concluse (*) nel periodo di riferimento
CODICE
TITOLO
OR1
FUNZIONALITÀ PER LO SVILUPPO E L’ANNOTAZIONE SEMANTICA DEI
WEB SERVICE NELLA PIATTAFORMA
OR2
DESCRIZIONE SEMANTICA DEI WEB SERVICE
(*) Per ogni attività conclusa deve essere fornito il “RAPPORTO TECNICO
ATTIVITA’”
Beneficiario:Code Architects S.r.l. - Progetto:SWOP
Version:1
Data: 30/07/2010
Pag. 2 di 24
SCHEDA B/1
SCHEDA PER ATTIVITA’
ATTIVITA’:
OR1 – FUNZIONALITÀ PER LO SVILUPPO E L’ANNOTAZIONE SEMANTICA DEI WEB SERVICE
NELLA PIATTAFORMA
SOGGETTO ESECUTORE:
CODE ARCHITECTS S.R.L. (in qualità di soggetto beneficiario)
DIPARTIMENTO DI INFORMATICA - UNIVERSITÀ DEGLI STUDI DI BARI (in qualità
di fornitore di ricerca)
WEBIS S.R.L. (in qualità di fornitore di consulenza specialistica)
LUOGO DI SVOLGIMENTO:
CODE ARCHITECTS S.R.L.: via Iazzitiello n. 15/D – 70209 Santeramo in
Colle (BA)
DIPARTIMENTO DI INFORMATICA - UNIVERSITÀ DEGLI STUDI DI BARI: via
Orabona n. 4 – 70126 Bari
DESCRIZIONE DELLE ATTIVITA’ SVOLTE:
Nel periodo che va dal 01/11/2009 al 30/06/2010 sono state avviate e
concluse, nei modi e nei termini previsti dal Piano Dettagliato di Attuazione,
tutte le attività di cui si compone l’obiettivo realizzativo in esame.
A1.1
ANALIZZARE LE MODALITÀ PER L’ANNOTAZIONE SEMANTICA DEI WEB SERVICE
Per prima cosa è stata affrontata la descrizione dello stato dell'arte in materia
di strumenti a supporto dell'annotazione semantica senza considerare un
particolare linguaggio di rappresentazione, in modo da analizzare il problema
dell'annotazione in termini del tutto generali. In particolare, per annotazioni
semantiche si intendono le informazioni semantiche associate a risorse web.
Tali annotazioni si usano per:
-
arricchire il contenuto informativo dei documenti;
esprimere in maniera formale, il significato di porzioni di testo in un
documento, Web Service, strutture dati coinvolte in un processo di
collaborazione (interoperabilità tra applicazioni software) , ecc.
Esistono diverse modalità di annotazione, la maggior parte delle quali basate
sull'utilizzo di ontologie di dominio, che sono state ampiamente descritte nel
deliverable D1.1 e che prevedono una parziale o completa interazione con
l'utente finale.
Si è passati poi ad affrontare gli obiettivi, i requisiti e l'utilità dell'annotazione
semantica applicata ai Web Service.
Version:1
Data: 30/07/2010
Pag. 3 di 24
Negli ultimi anni i Web Service sono diventati il mezzo principale di
comunicazione su Internet per i servizi distribuiti. Grazie alla loro natura,
infatti, i Web Service favoriscono l'interoperabilità dei programmi, in quanto le
fondamenta dei Web Service sono protocolli standardizzati, come XML, SOAP,
WSDL, UDDI. La presenza di questo ambiente fertile, in cui la fornitura di un
servizio non e più legata alla compatibilità hardware e software, ha portato
allo sviluppo di numerose soluzioni per lo sviluppo, l'installazione e
l'invocazione dei Web Service.
Una importante caratteristica dei Web Service è la possibilità di descriverne le
caratteristiche in forme comprensibili da un calcolatore. Con questo
presupposto, non e più necessario specificare manualmente come funziona il
servizio, ma sarà il calcolatore stesso a generare il codice necessario per
interagire con un altro servizio, riducendo notevolmente la possibilità di errori.
Nonostante sia possibile ottenere questo risultato, tuttavia, è sempre l'essere
umano che deve specificare quale servizio specifico è utile invocare tra la
moltitudine di servizi disponibili.
L'innovazione proposta dal web semantico, in cui le risorse acquistano un
significato specifico per l'elaboratore, porta comunque una nuova alternativa:
è possibile far compiere al calcolatore ciò che l'essere umano esegue
normalmente, cioè capire quale sia il servizio più adatto ad uno scopo? Se per
“capire” intendiamo un processo di ragionamento basato sullo stato del
mondo, allora possiamo presupporre che risorse che hanno un significato
semantico e l'utilizzo di un ragionatore si possano avvicinare abbastanza
all'attività fatta dal programmatore. Ciò comporta la necessità di definire quali
caratteristiche sono funzionali al ragionamento cosicché si possano definire
operazioni automatiche quali ricerca, selezione e composizione di web service.
Scopo di questa attività è dunque anche quello di garantire che possano
essere annotate tutte le proprietà sia funzionali sia non funzionali di un
servizio in modo da poter supportare l'esecuzione automatica delle operazioni
su citate.
Si passa così dalla visione classica dei Web Service a quella dei Semantic Web
Service che si ottengono appunto mediante l’annotazione semantica
dell’interfaccia del servizio. La novità del nostro approccio all’annotazione
semantica consiste nell’utilizzare tecniche di elaborazione del linguaggio
naturale per confrontare la descrizione del servizio con il significato dei
concetti di una ontologia di dominio.
A1.2
ANALIZZARE
LE
MODALITÀ
DI
EVOLUZIONE
DELL'ARCHITETTURA
DELLA
PIATTAFORMA
Per portare a termine questa attività sono stati attraversati diversi iter
decisionali con l’obiettivo di individuare le scelte ottimali per la realizzazione
delle varie componenti che consentiranno l’evoluzione della piattaforma CA
Enterprise Solution Platform. Le decisioni prese sono state modificate in
seguito a diversi problemi di compatibilità tra le varie componenti o per la
Version:1
Data: 30/07/2010
Pag. 4 di 24
scelta di integrazione delle nuove componenti con quelle preesistenti nella
piattaforma o per l’utilizzo di software che non permetteva la completa
fruizione di tutti i servizi necessari.
A1.3
INDIVIDUARE, PROGETTARE E IMPLEMENTARE UN SET DI COMPONENTI DI SISTEMA
A partire dagli orientamenti definiti nella attività A1.2, in questa attività si è
proceduto alla descrizione dettagliata dell’architettura scorporandola in tutte
le sue parti e delineandone quindi specificatamente ogni singola componente.
In seguito è stata effettuata un’altra analisi per comprendere i requisiti
necessari alla realizzazione di ciascuna componente e alla collaborazione fra
queste.
Nell’ambito delle diverse componenti utilizzate nella realizzazione della
piattaforma per l’annotazione semantica dei Web Service, si è optato per la
realizzazione di un Web Service e delle sue funzionalità, che permettono la
cooperazione di varie architetture scritte e sviluppate in diversi contesti
applicativi.
All’interno del Web Service sono state utilizzate diverse componente esterne,
tutte scritte in linguaggio Java. Le componenti utilizzate dal servizio per il
suggerimento di concetti ontologici, e quindi l’annotazione semantica di
documenti WSDL, sono:
-
-
-
JENA: tool Open Source per la navigazione di ontologie;
SAWSDL4J: tool Open Source realizzato per l’annotazione semantica di
documenti WSDL (poi scartato in fase di deploying per alcuni bug presenti
all’interno di esso e quindi utilizzato solo per l’apertura del documento
stesso e la creazione del documento XML);
SAWA: tool sviluppato dal Dipartimento di Informatica dell’Università degli
Studi di Bari per il calcolo della similarità tra due stringhe in Natural
Language;
sqljdbc/sqljdbc4: librerie jar contenti le classi necessarie alla interazione di
applicativi Java con DBMS in SQLServer. Presenti dopo aver installato i
driver JDBC per Microsoft SQLServer.
Sono state sfruttate le caratteristiche della tecnologia dei Web Service che
consente la corretta cooperazione tra vari ambienti di programmazione e di
sviluppo per permettere alla parte scritta in .NET di poter interagire con tutte
queste componenti scritte in Java in maniera trasparente e sicura.
Una volta individuati i requisiti funzionali della piattaforma è stato descritto il
modo in cui ciascuna componente partecipa alla realizzazione di un singolo
caso d’uso. Inoltre è stato analizzato ogni singolo caso d’uso all’interno di ogni
possibile scenario che può presentarsi durante l’utilizzo della piattaforma da
parte dell’utente finale.
Version:1
Data: 30/07/2010
Pag. 5 di 24
A1.4
IMPLEMENTARE LE NUOVE FUNZIONALITÀ NELLA PIATTAFORMA
In questa attività è stato sviluppato un primo prototipo Java per l’annotazione
semantica di Web Service, consistente in un Web Service denominato
SWOPWSApplication.
Il lato JAVA del progetto SWOP consente di interagire con tutte le componenti
esterne dell’architettura scritte nel linguaggio della SUN e mette a
disposizione due servizi principali:
-
-
Recupera una serie di concetti ontologici che vengono suggeriti all’utente
in quanto risultano semanticamente simili alla descrizione da lui stesso
inserita. L’utente può compiere tale operazione per l’intero Web Service
che sta annotando, ma anche per ogni metodo da esso esposto e per tutti i
parametri di input e output di ogni singola operazione. L’utente poi potrà
decidere se associare all’elemento del WSDL uno o più concetti suggeriti
dal software oppure scartarli tutti e annotarlo scegliendo personalmente le
classi che secondo lui sono più simili.
Costruisce il documento SAWSDL aggiungendo i riferimenti alle classi
ontologiche precedentemente aggiunte ad ogni elemento del WSDL.
Gli elementi annotati dall’utente saranno salvati in un DBMS in SQLServer che
fungerà, quindi, da registry UDDI.
È possibile accedere al data base recuperando, in questo modo, tutte le
informazioni dell’elemento che l’utente vuole annotare; informazioni quali:
nome, tipo di elemento, elemento padre, WSDL a cui appartiene.
Successivamente, quando l’utente avrà bisogno di visualizzare il documento
SAWSDL, SWOPWSApplication accede al data base per recuperare gli URI che
l’utente ha associato ad ogni elemento del WSDL indicato, costruendo così, in
real-time, il documento SAWSDL che sarà poi visualizzato sul lato client.
Nella fase di discovery, le due macro sezioni .NET e Java coopereranno per
permettere all’utente di effettuare una ricerca tra i Web Service annotati
precedentemente. In particolare per quanto riguarda l’ambito .NET, l’utente
avrà a disposizione una sezione apposita relativa alla fase di discovery dei
servizi web in cui potrà, attraverso l’inserimento di una descrizione per ogni
operazione e/o elemento del servizio desiderato, effettuare una ricerca tra i
servizi web già annotati in modo tale da trovarne almeno uno che risponda
alle sue necessità. Qualora i risultati proposti non rispondessero agli scopi
dell’utente, quest’ultimo potrebbe tornare alla fase di annotazione ed
effettuare i passi precedentemente descritti.
A completamento dell’attività è stato effettuato un test funzionale del
dimostratore software realizzato. Si è scelto come dominio applicativo
Adventure Works. Su ciascun servizio disponibile è stata inserita la descrizione
delle operazioni e dei parametri di Adventure Works valutando i concetti che
vengono restituiti dal software di Natural Processing Language.
Version:1
Data: 30/07/2010
Pag. 6 di 24
INVESTIMENTI REALIZZATI:
(indicare le spese effettuate per l’attività, nel periodo di riferimento, nella
seguente tabella)
Voci di costo
1.
Personale
2.
Attrezzature
3.
Acquisizione di ricerca da Università e/o centri di ricerca
k€

29,75





11,88





12,75

iscritti ad albo MUR
4.
Studi di fattibilità
5.
Brevettazione e diritti di proprietà intellettuale
6.
Acquisizione di Competenze tecniche e Consulenze
7.
Spese generali
8.
Altri costi del progetto (materiali,forniture etc..)
9.
Recuperi (da detrarre)
TOTALE
54,38
STATO DI AVANZAMENTO TEMPORALE DELLE ATTIVITA’:
1) Avviata il 01/11/2009
2) Conclusa il 30/06/2010
3) Secondo le previsioni [ X ]
4) In ritardo [
]
Il seguente diagramma illustra i tempi di svolgimento previsti allo stato
attuale per l’attività in esame confrontati con quelli riportati nel Piano
Dettagliato di Attuazione.
OR
Mesi
Mesi
1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OR1
A 1.1
5
5
A 1.2
3
3
A 1.3
3
3
A 1.4
3
3
Durata indicata nel Piano Dettagliato di Attuazione per l’attività
Durata prevista allo stato attuale
Version:1
Data: 30/07/2010
Pag. 7 di 24
18
MODALITA’ DI SVOLGIMENTO DELL’ATTIVITA’ RISPETTO A QUANTO
PREVISTO:
1) Rispondente
[X]
2) Parzialmente rispondente
[
]
3) Non rispondente
[
]
Version:1
Data: 30/07/2010
Pag. 8 di 24
SCHEDA B/2
ATTIVITA’:
OR2 – Descrizione semantica dei web service
SOGGETTO ESECUTORE:
CODE ARCHITECTS S.R.L. (in qualità di soggetto beneficiario)
DIPARTIMENTO DI INFORMATICA - UNIVERSITÀ DEGLI STUDI DI BARI (in qualità
di partner)
WEBIS S.R.L. (in qualità di fornitore di consulenza specialistica)
Colle (BA)
Nel periodo che va dal 01/07/2009 al 30/06/2010 sono state avviate e
concluse, nei modi e nei termini previsti dal Piano Dettagliato di Attuazione,
tutte le attività di cui si compone l’obiettivo realizzativo in esame.
A2.1
INDIVIDUARE I FORMALISMI PER LA RAPPRESENTAZIONE SEMANTICA DEI WEB
SERVICE
L’attività è consistita nelle seguenti azioni:
-
analisi dei linguaggi e degli strumenti per l’annotazione semantica dei web
service;
analisi dei linguaggi del Semantic Web e delle ontologie esistenti;
stato dell’arte delle tecniche di service selection, discovery, composition e
invocation.
Il prossimo passo nell'evoluzione dei Web Service consiste nell'aggiungere un
significato semantico agli stessi.
Consideriamo la descrizione WSDL di un qualunque servizio, per capire il
significato di ogni termine del messaggio un essere umano si affida a
deduzioni ottenute da termini autodescrittivi, e quando ciò non porta a
nessuno risultato ricorre alla documentazione. Per un calcolatore, invece, la
situazione è ovviamente diversa. Un calcolatore non può arrivare al significato
di un termine partendo dal suo nome, perché non ha a disposizione il contesto
in cui inserire tale significato (sempre supponendo che riesca a ricavare il
significato dal termine ed ad evitare ambiguità). Altrettanto vale per l'analisi
di documentazione esterna: dove reperirla? e come interpretarla?
Version:1
Data: 30/07/2010
Pag. 9 di 24
Da qui la necessita di stabilire un linguaggio per la descrizione semantica dei
Web Service, per permettere la manipolazione automatica tramite
elaboratore.
I linguaggi più utilizzati per definire semanticamente un Web Service sono
SAWSDL, WSMO, OWL-S e SAREST. Il primo è stato scelto come linguaggio di
riferimento per l'annotazione semantica dei Web Service della piattaforma
SWOP poiché è attualmente una W3C Recommendation.
Come caso d’uso per la piattaforma SWOP è stato selezionato un progetto di
esempio fornito da Microsoft©, chiamato Adventure Works, che rappresenta
una società fittizia che produce e vende biciclette. I servizi forniti alla società
sono quelli necessari ad interrogare una base dati relazionale contenente le
informazioni aziendali. È stata, inoltre, progettata un'architettura di massima
per la piattaforma SWOP ed il caso d’uso scelto (Business Enterprise).
A2.2
ANALISI DELLE TECNICHE PER L’UTILIZZO DELLE META-INFORMAZIONI E DELLE
ONTOLOGIE ESISTENTI NEL SEMANTIC WEB
Sulla base del caso d'uso individuato è stato definito lo stato dell'arte sulle
tecnologie alla base del progetto del Semantic Web: il livello sintattico, il
livello semantico ed il livello logico. È stato scelto OWL (Ontology Web
Language) come linguaggio ontologico per la definizione semantica della base
di conoscenza del progetto. Tale base di conoscenza è costituita dall'ontologia
SWOP che sarà utilizzata in fase di annotazione, per aggiungere semantica
alla descrizione dell'interfaccia di un Web Service, ed in fase di ricerca per
individuare i Web Service, tra quelli annotati disponibili nella piattaforma,
semanticamente "simili" alla descrizione cercata. Obiettivo di questa attività è
sviluppare un’ontologia che risponda alle esigenze di rappresentazione della
conoscenza della piattaforma SWOP. L'ontologia da sviluppare deve modellare
sia le caratteristiche funzionali sia le caratteristiche non funzionali di un web
service. Le azioni intraprese sono riepilogate ed illustrate di seguito:
-
-
-
definizione dei principali formalismi di rappresentazione della conoscenza,
le ontologie ed i vari linguaggi esistenti, con particolare riferimento ad
OWL;
analisi del ruolo delle ontologie nell’impresa e definizione di alcune linee
guida utili per lo sviluppo dell’ontologia SWOP;
analisi delle ontologie esistenti per il dominio enterprise, al fine di
individuare gli elementi necessari per progettare l’ontologia enterprise per
il caso d’uso di SWOP;
progettazione dell'ontologia SWOP: descrizione delle classi, attributi e
restrizioni, delle diverse ontologie definite (l’ontologia del dominio
enterprise per il caso d’uso del progetto, la tassonomia delle categorie,
l’ontologia funzionale, e l’ontologia dei servizi), descrizione del processo di
integrazione delle ontologie così definite e dei Web Service modellati per
testare il prototipo della piattaforma di annotazione e ricerca di servizi.
Version:1
Data: 30/07/2010
Pag. 10 di 24
L'ontologia sviluppata risulta funzionale a tutti i metodi e le tecniche di service
selection, discovery, composition e invocation indagati nella terza attività. Lo
sviluppo dell'ontologia SWOP si è reso necessario poiché, per poter classificare
correttamente i parametri dei servizi da utilizzare con il linguaggio di
annotazione scelto (SAWSDL), bisogna stabilire un'ontologia in cui siano
contemplati tutti i possibili tipi di input e di output del nostro dominio. Piccole
variazioni in questi tipi possono cambiare drasticamente il significato
ontologico assegnato loro da un servizio. Inoltre, le ontologie devono essere
abbastanza specifiche da poter gestire queste variazioni senza stravolgere
l'adeguatezza della classificazione ontologica dell'interfaccia del servizio.
Servizi con interfacce differenti ma stesso significato semantico devono
condividere un'ontologia comune, quindi, per esempio, un insieme di servizi di
localizzazione satellitare devono tutti condividere la stessa ontologia sulle
mappe. Solo condividendo un'ontologia comune, servizi con gli stessi input ed
output semantici possono essere scoperti con la medesima interrogazione,
anche se presentano interfacce diverse.
A2.3
INDIVIDUARE I METODI E LE TECNICHE PER DISCOVERY, SELECTION, COMPOSITION
E INVOCATION DI WEB SERVICE SU BASE SEMANTICA
Nonostante il presupposto di un'ontologia comune, chi desidera ricercare
dinamicamente servizi, non può utilizzare efficacemente SAWSDL, anche
avendo classificato per tipo i vari servizi. All'interno di una singola
classificazione di Web Service ci sono numerose combinazioni differenti di
input e di output da gestire. Per esempio, un'applicazione non può attendersi
di cercare semplicemente servizi di “previsione meteorologiche” e trovare
immediatamente il servizio adeguato alle sue necessità. Con che precisione, in
che data è richiesta la previsione? Che tipo di input fornire?
Per utilizzare SAWSDL come meccanismo di ricerca di servizi, è quindi
necessaria una classificazione almeno degli input e degli output. La
descrizione del servizio può essere usata come aiuto aggiuntivo per migliorare
la qualità dei risultati di una interrogazione, ma non può essere usata come
unico mezzo per la ricerca di servizi.
In questa attività si sono definiti da un punto di vista teorico le tecniche di
selection, discovery, composition e invocation di un servizio, mentre in
accordo agli obiettivi del progetto si è sviluppato un algoritmo di discovery dei
servizi utilizzando come parametri di ricerca: la classificazione e la descrizione
del servizio, la descrizione delle sue operazioni e i dati di input e di output per
ciascuna operazione.
Come estensione dell’attività A2.3 si è proceduto alla definizione di un
algoritmo di selection per la realizzazione di un matchmaking semantico che
restituisca una lista ordinata di servizi (dal più rilevante al meno rilevante
rispetto alla interrogazione dell'utente finale).
Version:1
Data: 30/07/2010
Pag. 11 di 24
A2.4
SVILUPPARE UN DIMOSTRATORE PER ALMENO UNA DELLE TECNICHE INDIVIDUATE
Riguardo la parte di annotazione semantica di un Web Service, il sistema
SWOP, e più precisamente il Web Service sviluppato in JAVA, si servirà di una
ontologia per recuperare i concetti che saranno poi suggeriti all’utente.
Come detto, è stato utilizzato il tool open source JENA. Esso permette di
importare l’intero file ontologico e navigare tra le classi, istanze, concetti e
proprietà in esso dichiarati gestendo la struttura dati direttamente da codice
sfruttando le librerie che il tool mette a disposizione.
Nel sistema SWOP JENA viene usato per poter navigare tra le classi definite in
esso, e recuperare così i concetti ontologici che verranno poi suggeriti
all’utente. A seconda del tipo di elemento del WSDL che si sta annotando si
navigherà in un diverso ramo dell’albero delle classi definite nell’ontologia
swop-integration (ad esempio, nel caso si sta annotando un metodo di un WS,
i concetti candidati a categorizzarlo saranno cercati tra le classi (e relative
sottoclassi) BusinessProcess e BusinessTask.
L’ontologia swop-integration è scritta in OWL-DL e risulta essere l’integrazione
di altre 4 ontologie:
-
BusinessObject: relativa alla modellazione dei dati di input/output dei
processi;
CommercialCategory: funge da tassonomia delle principali categorie
commerciali di prodotti e servizi;
BusinessProcess: ontologia del dominio funzionale nella quale ogni classe
rappresenta una funzionalità del dominio scelto;
Service: ontologia dei servizi che modelli i web service in funzione del loro
ritrovamento.
La funzionalità di discovery della piattaforma SWOP consente di ricercare Web
Service inserendo una query in linguaggio naturale che contenga le
informazioni riguardo le operazioni richieste dall’utente. Come nel caso di
annotazione, questa query viene elaborata da un algoritmo di NLP che
restituisce una serie di concetti correlati con quella descrizione. A questo
punto il sistema effettua una ricerca sul codice OWL dei concetti restituiti dal
software per trovare quei web service che sono correlati semanticamente con
la descrizione inserita dall’utente.
Per creare la descrizione OWL necessaria per invocare il metodo di discovery,
è necessario utilizzare JENA come tool di sviluppo. Si deve, infatti, costruire a
run-time il codice relativo ai concetti annotati dall’utente in fase di salvataggio
del Web Service. L’utente quindi annota il file WSDL creando il file SAWSDL,
con le informazioni contenute in esso crea una descrizione OWL ad hoc per il
Web Service, descrizione che sarà poi parsata ed elaborata dal modulo di
discovery.
Version:1
Data: 30/07/2010
Pag. 12 di 24
seguente tabella)
Voci di costo
1.
Personale
2.
Attrezzature
3.
Acquisizione di ricerca da Università e/o centri di
k€

55,87











ricerca iscritti ad albo MUR
4.
5.
6.
7.
Spese generali
8.
9.
TOTALE
55,87
1) Avviata il 01/07/2009
2) Conclusa il 30/06/2010
4) In ritardo [
]
OR
Mesi
Mesi
1
2
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OR2
A 2.1
3
3
A 2.2
3
3
A 2.3
3
3
A 2.4
3
3
Version:1
Data: 30/07/2010
Pag. 13 di 24
18
PREVISTO:
1) Rispondente
[X]
[
]
3) Non rispondente
[
]
Version:1
Data: 30/07/2010
Pag. 14 di 24
SCHEDA B/4
ATTIVITA’:
OR4 – DISSEMINAZIONE DEI RISULTATI DI RICERCA
SOGGETTO ESECUTORE:
CODE ARCHITECTS S.R.L.
DIPARTIMENTO DI INFORMATICA - UNIVERSITÀ DEGLI STUDI DI BARI
Colle (BA)
Nel periodo in esame è stata avviata, ma non conclusa, l’attività A4.1 PIANIFICARE LE ATTIVITÀ DI DISSEMINAZIONE E PREDISPORRE I MATERIALI.
In particolare, le azioni di promozione eseguite alla data del presente
documento sono:
-
-
-
creazione del sito web di progetto (http://codearchitects.swop.it/) e
relativo popolamento con le informazioni istituzionali del progetto SWOP;
predisposizione della sezione del progetto sui siti dei partner;
progettazione e organizzazione del workshop di disseminazione interna da
tenersi in data 27/07/2010 presso il Dipartimento di Informatica
dell’Università degli Studi di Bari;
progettazione e organizzazione del workshop pubblico da tenersi in data
14/09/2010 presso il Dipartimento di Informatica dell’Università degli
Studi di Bari;
individuazione e preparazione del paper da sottoporre al 6th Workshop on
Semantic Web Applications and Perspectives (SWAP 2010) che si terrà dal
21 al 22 settembre 2010 a Bressanone (TN) (http://www.swapconf.it/).
Version:1
Data: 30/07/2010
Pag. 15 di 24
seguente tabella)
Voci di costo
1.
Personale
2.
Attrezzature
3.
k€

8,39











4.
5.
6.
7.
Spese generali
8.
9.
TOTALE
8,39
1) Avviata il 01/04/2010
2) Conclusa il ___________
4) In ritardo [
]
OR
Mesi
Mesi
1
4
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OR4
A 4.1
7
7
A 4.2
6
6
Version:1
Data: 30/07/2010
Pag. 16 di 24
18
PREVISTO:
1) Rispondente
[X]
[
]
3) Non rispondente
[
]
Version:1
Data: 30/07/2010
Pag. 17 di 24
SCHEDA B/5
ATTIVITA’:
OR5 – GESTIONE DEL PROGETTO
SOGGETTO ESECUTORE:
Colle (BA)
Orabona N. 4 – 70126 Bari
Nella presente attività si è svolta una tipica funzione di coordinamento
progettuale indirizzata a favorire la cooperazione tra i partner di progetto e un
costante raccordo tra il team di progetto e le restanti attività aziendali.
Rientra in tale funzione anche il coordinamento con la Regione Puglia per
l’espletamento dei vari adempimenti relativi alla rendicontazione tecnicoscientifica.
Accanto all’esercizio di questa fondamentale funzione di coordinamento è
stato inoltre implementato un sistema di monitoraggio e valutazione
dell’attività progettuale finalizzato ad evitare pericolose ridondanze,
inefficienze o incoerenze nell’azione esplicata e ad assicurare lo sviluppo del
progetto in accordo con il piano esecutivo e gli obiettivi da conseguire.
Il continuo monitoraggio ha consentito di verificare puntualmente la coerenza
tra gli obiettivi di volta in volta conseguiti e gli obiettivi progettuali, fornendo
per tempo le indicazioni necessarie ad apportare le opportune correzioni
all’andamento del progetto.
Per le attività di monitoraggio e valutazione è stata adottata una metodologia
improntata ad una logica obiettivi/risultati supportata da una attenta gestione
del rischio progettuale.
Version:1
Data: 30/07/2010
Pag. 18 di 24
seguente tabella)
Voci di costo
1.
Personale
2.
Attrezzature
3.
k€

2,38











4.
5.
6.
7.
Spese generali
8.
9.
TOTALE
2,38
1) Avviata il 01/07/2009
2) Conclusa il ___________
4) In ritardo [
]
OR
Mesi
Mesi
1
5
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
OR5
A 5.1
18
18
A 5.2
3
3
Version:1
Data: 30/07/2010
Pag. 19 di 24
18
PREVISTO:
1) Rispondente
[X]
[
]
3) Non rispondente
[
]
Version:1
Data: 30/07/2010
Pag. 20 di 24
SCHEDA C/1
SCHEDA PER SOGGETTI ESECUTORI
IDENTIFICAZIONE SOGGETTO:
POSIZIONE CONTRATTUALE:
1)
2)
[X]
[ ]
Beneficiario
Partner
INDIRIZZO: via Iazzitiello n. 15/D – 70029 Santeramo in Colle (BA)
RAPPRESENTANTE LEGALE: Giuseppe Dimauro
RESPONSABILE TECNICO: Giuseppe Dimauro
IDENTIFICAZIONE DELLE AZIONI PARZIALMENTE O TOTALMENTE
SVOLTE NELL’AMBITO DELLE ATTIVITA’ DELLA LINEA/FASE:
ATTIVITA’:
OR1
FUNZIONALITÀ PER LO SVILUPPO E L’ANNOTAZIONE SEMANTICA DEI WEB
SERVICE NELLA PIATTAFORMA
AZIONI:
A 1.1
ANALIZZARE LE MODALITÀ PER L’ANNOTAZIONE SEMANTICA DEI WEB SERVICE
A 1.2
ANALIZZARE
LE
MODALITÀ
DI
EVOLUZIONE
DELL'ARCHITETTURA
DELLA
PIATTAFORMA
A 1.3
INDIVIDUARE, PROGETTARE E IMPLEMENTARE UN SET DI COMPONENTI DI
SISTEMA
A 1.4
IMPLEMENTARE LE NUOVE FUNZIONALITÀ NELLA PIATTAFORMA
ATTIVITA’:
OR2
AZIONI:
A 2.1
SERVICE
A 2.2
Version:1
Data: 30/07/2010
Pag. 21 di 24
ONTOLOGIE ESISTENTI NEL
A 2.3
SEMANTIC WEB
INDIVIDUARE I METODI E LE TECNICHE PER DISCOVERY, SELECTION,
COMPOSITION E INVOCATION DI WEB SERVICE SU BASE SEMANTICA
A 2.4
SVILUPPARE
UN
DIMOSTRATORE
PER
ALMENO
UNA
DELLE
TECNICHE
INDIVIDUATE
ATTIVITA’:
OR4
AZIONI:
A 4.1
PIANIFICARE LE ATTIVITÀ DI DISSEMINAZIONE E PREDISPORRE I MATERIALI
ATTIVITA’:
OR5
GESTIONE DEL PROGETTO
AZIONI:
A 5.1
COORDINAMENTO
A 5.2
MONITORAGGIO
Version:1
Data: 30/07/2010
Pag. 22 di 24
SCHEDA C/2
SCHEDA PER SOGGETTI ESECUTORI
IDENTIFICAZIONE SOGGETTO:
POSIZIONE CONTRATTUALE:
1)
2)
[ ]
[X]
Beneficiario
Partner
INDIRIZZO: via Orabona n. 4 – 70126 Bari
RAPPRESENTANTE LEGALE: prof.ssa Anna Maria Fanelli
RESPONSABILE TECNICO: prof. Giovanni Semeraro
IDENTIFICAZIONE DELLE AZIONI PARZIALMENTE O TOTALMENTE
SVOLTE NELL’AMBITO DELLE ATTIVITA’ DELLA LINEA/FASE:
ATTIVITA’:
OR2
AZIONI:
A 2.1
SERVICE
A 2.2
ONTOLOGIE ESISTENTI NEL SEMANTIC WEB
A 2.3
INDIVIDUARE I METODI E LE TECNICHE PER DISCOVERY, SELECTION,
COMPOSITION E INVOCATION DI WEB SERVICE SU BASE SEMANTICA
ATTIVITA’:
OR4
AZIONI:
A 4.1
PIANIFICARE LE ATTIVITÀ DI DISSEMINAZIONE E PREDISPORRE I MATERIALI
Version:1
Data: 30/07/2010
Pag. 23 di 24
FIRMA DIGITALE CERTIFICATA
Apporre la Firma digitale certificata del Legale rappresentante del soggetto
Beneficiario.
Version:1
Data: 30/07/2010
Pag. 24 di 24

standard di documentazione cluster - SWOP

Transcript

Documenti analoghi

Brad Pitt presenta case ecologiche per New Orleans

Contents

Untitled - Stoppani10

curcuma alismatifolia

SeaClub insotel Cala Mandia 55 BaLeari

No all`uniforme scolastica Vincerà “Cars” o “Gang

edificio per uffici 30 jellicoe / 30 jellicoe office block johannesburg

UserID e password sono quelle che ti sono state communicate dal

COMPITI PER LE VACANZE ESTIVE

Illegittimo impedimento

Tecniche di gestione delle meta-informazioni nel Semantic

F. Mambrini, L`Ancient Greek Dependency Treebank. Un nuovo

Dialoghi Annotati per Interfacce vocali avanzate – Specifiche Tecniche