Sorgente

• Identificativo del campo chiave del database:
  1. Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz
• link per vedere tabella del db:
  1. http://192.168.0.21/phpMyEdit-5.7.1/Table16.php
• posizione e nome del file scaricato, URL:
  1. /home/ubuntu/Dati/Servizi/Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz/%DATA%/Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz.kmz

Prima Fase

• descrizione del processo di ingestion, prima fase
  • descrizione eventuali elaborazioni a mano e criticità:
    1. Non previste
  • posizione URL e nomi di file di elaborazione a mano o java, o perl o che altro:
    1. HBase: il software si trova in /home/ubuntu/programs/hbase-0.90.0
    2. h-rider: il software si trova in /home/ubuntu/Desktop/h-rider-1.0.3.0-hbase-0.90.4
  • fasi del processo: parti a mano, parti con altri tool----> ETL
    1. HBase: Viene usato una database HBase per la memorizzazione dei dati elaborati. Per accedervi da terminale andare su "home/ununtu/programs/hbase-0.90.0" e digitare "./bin/start-hbase". Altrimenti può essere utilizzato il tool grafico h-rider.
    2. h-rider: Per la visualizzazione dei database HBase viene utilizzato un software che permette di controllarne il contenuto in modo grafico, per semplificare le cose. Questo tool permette anche di effettuare le principali operazioni attuabili. Per avviare il programma on il terminal andare su /Desktop/h-rider-1.0.3.0-hbase-0.90.4 (digitando “cd Desktop/h-rider-1.0.3.0-hbase-0.90.4”). Da qui eseguire il comando java -jar h-rider-1.0.3.0.jar . Se esce una finestra che chiede il “ZooKeeper Quorum” digitare localhost .
  • dove sta l'ETL URL, come si chiama
    1. Directory+file: /home/ubuntu/SiiMobility/Trasformazioni/TrasformazioneServizi_KMZ/FaseA_Servizi_KMZ/Main.kjb
    2. Le trasformazioni chiamate dal job principale sono sulla stessa cartella.
  • descrizione sommaria dell'ETL

    1. JOB Main: setta la variabile col nome della dir di destinazione, chiama la TRASF Database (se ci sono degli errori, richiama la TRASF errorDatabase), chiama la TRASF GetLastDateFolder e crea una cartella col nome pari alla data attuale. Tramite chiamata HTTP scarica il file in oggetto (in caso di errori chiama la TRASF errorHTTP) e lo confronta con il vecchio: se sono uguali cancella la cartella creata in precedenza, altrimenti scompatta il file (in caso di errore chiama la TRASF unzipException) e chiama la TRASF filesModification (in caso di errore richiama anche la TRASF errorToHBase). Lo step filesModification chiama la trasformazione chiamata come il nome processo. In questo caso Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz.

    2. TRASF DataBase: recupera il nome del processo ed imposta la relativa variabile d'ambiente. Seleziona dal database tutte le righe che hanno stesso nome processo e crea una variabile in formato toISOString con la data attuale, gli leva la Z in fondo e salva il valore nella relativa variabile d'ambiente. Le righe risultanti dalla SELECT vengono copiate nei risultati.

    3. TRASF errorDataBase: si recupera il nome del processo, si definiscono delle costsanti e si va ad inserire nelle tabelle error e ProcessManager, rispettivamente la riga dell'errore ed il flag che avvisa dell'errore.

    4. TRASF LastDateFolder: seleziona la sottocartella con nome processName e poi identifica l'ultima cartella tra le presenti; filtra la riga che interessa e setta la relativa variabile d'ambiente.

    5. TRASF errorHTTP, TRASF errorFileModification: preleva il nome del processo ed il tipo di errore ed aggiorna la tabella processManager.

    6. TRASF FileModification (colonnine ricarica): si apre il file KML, si vanno ad eliminare i tag di apertura e chiusura per il CDATA, si prelevano i dati dal file, Tag, Span e Coordinate, si denormalizzano vari campi. Si controlla poi se nella tabella toponimo si trova l'indirizzo e si restituisce il codice toponimo; si aggiungono dei valori costanti, si crea l'organizationName e le eventuali Note e si eliminano i CR e LF da tutte le stringhe. Si crea la variabile dataInserimento in formato toISOString e si va a levargli la Z finale; si divide le coordinate in 2 valori, si recupera il processName, si seleziona i soli valori di interesse e si inseriscono in HBase nella tabella servizi.

  • descrizione e posizione dei file di output
    1. Tabella HBase - Servizi (al momento non sono presenti dati relativi a questa risorsa sulla tabella)
  • contributor name: Ortolani

Seconda Fase

• descrizione del processo di ingestion, seconda fase
  • descrizione eventuali elaborazioni a mano e criticità:
    1. Non previste
  • posizione URL e nomi di file di elaborazione a mano o java, o perl o che altro
    1. Karma data integration: Il software si trova in /home/ubuntu/programs/Web-Karma-master
    2. Modello R2RML: /home/ubuntu/Models/Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz.ttl
  • fasi del processo: parti a mano, parti con altri tool----> ETL
    1. Karma data integration: La seconda fase lancia il software Karma (comando batch) per la generazione delle triple. Karma utilizza un modello R2RML precedentemente creato a mano. Per avviare il tool grafico per la generazione dei modelli R2RML tramite terminal andare su programs/Web Karma master (digitando “cd programs/Web-Karma-master”). A questo punto lanciare il comando: “mvn jetty:run” . Il programma risulterà completamente avviato quando sul terminal comparirà la scritta [INFO] Started Jetty Server . A questo punto per poterlo utilizzare è sufficiente andare sul browser e digitare “http://localhost:8080/web-karma.html”. Per poter avviare Karma su una porta a piacere (diversa dalla 8080 che potrebbe essere dedicata ad altri processi) si può eseguire il comando “mvn -Djetty.port=9999 jetty:run” (ovviamente al posto di 9999 va specificata la porta desiderata).
    2. Nella seconda fase viene lanciato uno script che carica le triple generate sul repository RDF (sulla macchina windows - 192.168.0.205). Questo scripta carica tutto il contenuto di una cartella specificata e di tutte le sottocartelle. Questo script, fornito da Owlim, si chiama example.sh.
  • dove sta l'ETL URL, come si chiama
    1. Directory+file: /home/ubuntu/SiiMobility/Trasformazioni/TrasformazioneServizi_KMZ/FaseB_Servizi_KMZ/Main.kjb
    2. Le trasformazioni chiamate dal job principale sono sulla stessa cartella.
  • descrizione sommaria dell'ETL

    1. JOB Main: si imposta la directory di lavoro, si va ad effettuare un DROP ed una CREATE TABLE in SQL, si richiamano le TRASF getTime e HBaseToMySQL. Si controlla quante righe ha la tabella e si chiama le TRASF createR2RML, createActualDate, e si va a creare una cartella con nome uguale alla data attuale. Si va a richiamare uno script da shell che permette di creare le triple, si richiama la TRASF updateLastTriples e si esegue uno script da shell per caricare le triple tramite owlim e si esegue un DROP della tabella.

    2. TRASF errorDrop, TRASF errorSQl, TRASF errorGetTime, errorToMySQL, TRASF errorCreateR2RML, TRASF errorDrop2, TRASF errorLoadTriples, TRASF errorUpdateTime, TRASF errorKarma: si recupera il nome del processo, si definiscono delle costsanti e si va ad inserire nelle tabelle error e ProcessManager, rispettivamente la riga dell'errore ed il flag che avvisa dell'errore.

    3. TRASF getTime: si seleziona dalla tabella MySQL le ultime triple del processo considerato e si restituiscono come risultato. e prende le 10 cifre che rappresentano il giorno di oggi e ci imposta tale variabili d'ambiente.

    4. TRASF HBaseToMySQL: si fa una query su HBase e si prelevano le variabili timeB e processName, si definiscono 2 costanti e si filtrano le righe prelevate selezionando quelle in cui timeB e' minore di data_inserimento ed il process name corrisponde al selezionato e se ne seleziona i vari campi dalla tabella ProcessName. Nel caso in cui questo prelievo fallisca, si effettua il solito inserimento nelle tabelle errors e ProcessManager.

    5. TRASF createR2RML: carica il contenuto del file serviceX.ttl e fa un reply della stringa X con il processName e crea poi il file di output sempre in formato .ttl.

    6. TRASF createActualDate: preleva da sistema la data attuale e la converte in formato toISOString, elimina il carattere Z che il formato inserisce e setta la variabile d'ambiente relativa.

    7. TRASF updateLastTriples: prende il processName, crea la data d'inserimento in formato toISOString, elimina la Z del formato e va ad inserirla nelle tabella delle triple.

    8.  
  • descrizione e posizione dei file di output (triple)
    1. /home/ubuntu/Triple/Servizi/Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz/%DATA%/Colonnine_per_la_ricarica_dei_veicoli_elettrici_kmz.ttl
    2. Le triple sono presenti sulla macchina ma non sono state ancora caricate sul repository (perché sul repository era in atto un verifica delle riconciliazioni delle vie. Questo avrebbe compromesso tale verifica)
  • contributor name: Ortolani

Semantic Model

• Descrizione del mapping delle triple rispetto al KB:
  1. A ciascun Service è associato il codice ATECO, cioè il codice ISTAT di classificazione delle attività economiche, il quale potrebbe essere utilizzato in futuro come filtro per definire la varie sottoclassi, al posto dell'attuale suddivisione in base alle categorie definite dalla Regione Toscana, in modo da rendere più precisa la ricerca dei vari tipi di servizi. L'attuale suddivisione dei servizi in sottoclassi si basa sul valore dell'objectProperty serviceCategory. I servizi KMZ si differiscono dai Servizi della regione per la presenza delle coordinate geografiche che li localizzano. Qui di seguito riportiamo la mappatura dei singoli tag XML sulla KB:
     1. longitude: e' mappato nella dataProperty geo:long di Service;
     2. latitude: e' mappato nella dataProperty geo:lat di Service;
     3. Nome/Denominazione: e' mappato nella dataProperty v:organization-name di Service aggiungendo eventualmente alcune parole prima che permettano di definire il tipo di servizio (ad es. per i consolati si aggiunge appunto la parola Consolato prima del nome "Croazia")
     4. Telefono: e' mappato nella dataProperty v:hasValue della classe SiiMobility:ServiceTelephone che e' connessa alla classe Service tramite la ObjectProperty v:hasTelephone.
     5. Indirizzo/Via+NCivico/Toponimo: e' mappato nella dataProperty v:street-address di Service;
     6. Quartiere, Tipo, Stato, Utenza, Gestore, Titolare, Specifica, : e' mappato nella dataProperty skos:note di Service;
     7. In base al nome file si va poi a determinare a quale serviceCategory appartiene il servizio;
         
• contributor name: Rauch

Open Problem

• problemi residui:
  • eventuali inconsistenze, elementi da riconciliare
    1. (Ortolani) La chiave che viene usata per l'inserimento sul database HBase viene creata a partire da informazioni relative allo specifico elemento. HBase non carica valori che hanno come chiave un valore già presente sul database. Per questo motivo può succedere che quando arriva una nuovo file, che ha qualche elemento che era presente anche nel precedente file (ma con qualche modifica), questo non viene salvato su HBase perchè ha la stessa chiave. Quindi si perdono informazioni relativa ad eventuali modifiche sugli elementi cambiati.
    2. (Ortolani) Se arriva un nuovo file che ha meno elementi del precedente, il che implica che magari qualche elemento non esiste più, non si ha modo di saperlo. In questo modo l'informazione relativa all'elemento eliminato continua a stare sia su HBase che sul repository RDF.
  • suggerimenti per non portarsi questi errori avanti nelle prossime ingestion:
    1. (Ortolani) Si deve prevedere un modo di salvare su HBase tutti i dati, ogni volta che vengono scaricati, magari prevedendo l'utilizzo di una chiave che cambia ogni volta (per esempio utilizzando la data)
    2. (Ortolani) Alternativamente al punto precedente si potrebbe prevedere un meccanismo che permetta di modificare su HBase i dati che sono cambiati. Per far questo sarebbe necessario scandire ogni volta le informazioni presenti sul database con quelle sul file.
    3. (Ortolani) Ogni modifica sui dati di HBase deve essere propagata sul repository RDF. Se un elemento viene eliminato si può trovare il modo di eliminarlo sul repositoru RDF oppure aggiungere un'informazione che indica il suo mancato futuro utilizzo.
    4. (Ortolani) C'è da tenere conto che se si decidesse di eliminare triple dal repository RDF allora andrebba fatta la stessa cosa anche sui file residenti sulla macchina. Altrimenti in un secondo momento, se si decidesse di ricaricare tuttle le triple su Owlim, queste sarebbero comprensive anche degli elementi deprecati.
    5. (Ortolani) Un'altra ipotesi è quelle di ricaricare l'intero repository RDF qualora ci fossero modifiche è cancellazioni consistenti sui dati di origine

Contributors

• name of contributors and date of the last change: Ortolani - 20/05/2014