<pre>>><i> From: Andrea Peri <<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss">aperi2007 a gmail.com</a>>
</i>>><i> To: <a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss">gfoss a lists.gfoss.it</a>
</i>><i> Subject: [Gfoss] consigli su stoccaggio dati‏
</i>><i> Ciao Andrea, grazie per i consigli, avrei però ancora dei dubbi e punti da chiarire:concordo sul fatto che samba garantisca una buona familiarità di utilizzo per i vari utenti,le cartelline, <br>>i drag end drop, ctrl-c ctrl-v sono attività che ormai tutti sono capaci di svolgereconcorderei anche sulla possibilità di creare 2 aree, ma l'area in sola lettura diventerebbe <br>
>solamente un archivio? dati stoccati e non più utilizzati?<br></i><i>>gli utenti utilizzerebbero i dati a cui hanno accesso sia in scrittura che lettura? <br></i>
<i>Usi il termine sbagliato.<br>Si tratterebbe di una area di dati realmente utilizzati.<br>Io parlo di una area read-only.<br>Ovvero una area dove gli utenti possono leggere i dati e quindi usarli con qualciasi ambiente GIS desktop, ma non riescono a scriverli, ma solamente a leggerli.<br>
Nessuno puo' ad esmepio modificare un vertice, cambiare un attrivuto o cancellare qualcosa.<br><br>I dati nelle aree di lavoro scrivibili da tutti non sono realmente usabili.<br>E questo proprio per il fatto che sono scrivibili da chiunque.<br>
Ad esempio:<br>Te punti un archivio oggi e domani non lo trovi piu', perche' qualcuno lo ha rinominato, perche' riteneva che avesse piu' senso chiamarlo in altro modo, oppure lo ha spostato in altra cartella <br>
per qualche altra ragione certamente valida (per lui).<br><br>Oppure categorizzavi su un campo che aveva un dominio e quando vai a riaprire il progetto dopo un mese, non ti compare piu'nulla e spendi qualche ora per capire che altri hanno sostituito al codice numerico<br>
la sua decodifica. Magari perche' cosi' l'etichetta nelle stampe e' piu' facile da fare senza ingrullire troppo.<br><br>Insomma e' esperienza acquisita che con gli archivi di lavoro ci lavora solo chi li produce.<br>
Per renderliusabili agli altri utenti vanno "fissati", ovvero resi read-only .<br>Solo in questo modo diventano realmente usabili in un ambiente "corporate".<br><br>>il lavoro del responsabile dati che deve poi migrare i dati dalla zona open alla zona restricteddiventerebbe enorme, <br>
<br>Si' e' un lavoro impegnativo, ma non lo definirei enorme.<br>Dopo un po' di tempop ci prendi la mano e tutto diviene facile.<br>Ovviamente occorre coordinare il lavoro in partenza.<br>Ovviamente io parlo di una situazione in cui un archivio sviluppato e' finalizzato a uno scopo istituzionale ,<br>
e quindi dietro di esso vi e' una norma , un regolamento.<br>Non parlo di una situazione in cui uno si sveglia la mattina e decide di inventarsi l'archivio dei "pollai" facendo un po' come gli pare.<br>
<br>Perche' e' ovvio che facendo cosi' poi e' difficile inserire tale archivio in un costento insieme ad altri archivi mantenendolo coerente.<br><br>Piuttosto, chi deve sviluppare l'archivio si rivolge a chi gestisce il repository e si informa se gia' esiste qualcosa che supporti parte delle sue nocessita',<br>
se si' tale parte viene scorporata dal lavoro da fare, perche' gia' esistente.<br>Poi concorda la struttura dell'archivio e in particolare i domini. Concorda anche i nomi dei files e dei campi.<br>sempre perche' vi e' la necessita' di essere coerenti in un contesto allargato.<br>
<br>Mi spiego con un esmepio semplice:<br>Chi sviluppa l'archivio dei pollai potrebbe pensare di metterci dentro anche i confini comunali perche' magari ogni comune ha una normativa differente, con le loro geometrie.<br>
MA se te hai gia' un archivio dei confini comunali, e' concettualmente sbagliato inserirne una copia dentro l'archivio dei pollai, proprio perche' in realta' deve fare riferimento <br>all'archivio esistente. Caso mai usa delle chiavi esterne (che puoi inserire anche in uno shapefile) per legarsi all'archivio dei confini comunali.<br>
<br>Poi, un altro esempio e' la codifica degli oggetti.<br>Infatti chi sviluppa un archivio tende a essere "tolomeico" ovvero pensa che il suo archivio sara' al centro dell'universo.<br>Per cui non si preoccupa di mettere delle codifiche che reggano anche all'uso in un contesto allargato.<br>
Ad esmepio codifica con "1,2,3,4" oppure ci mette una codifica che regge a livello di indagine.<br>Anche questo e' un punto importante, e spetta a chi coordina il repository indicare il giusto tipo di codifica che supporti le esigenze dell'archivio "dei pollai" e che regga anche <br>
all'uso su una scala piu' vasta<br><br>Questo lavoro di analisi preliminare, che non stravoklge assolutamente il lavoro di chi dovra' produrre l'archivio, ma piuttosto che lo indirizza fin da subito a produrre un archivio che sara' coerente<br>
nel contesto del repository, permettera' di poter inserire l'archivio fin da subito nel repository.<br><br>>se non viene stabilito un flusso di lavoro sul dato, un metodo di metadatazionea monte...o no? <br><br>
La metadatazione, non aiuta nella progettazione, ma serve per il riuso a posteriori.<br>E' piu' rivolta all'uso del dato da parte di un utente finale.<br>Se fai caso nelle specifiche ISO19115 non e' contemplato assolutamente la descrizizone dell'archivio dal punto di vista della struttura dei campi e dei loro domini.<br>
Mentre invece e' contemplato la descrizione a posteriroi del processo produttivo.<br>Ove pero' il processo produttivo non riguarda le cose che ti ho indicato sopra, ma piuttosto (e non e' poco) le indicazioni di come l'utente che ha prodotto l'archivio dei "pollai" ha svolto <br>
la sua indagine e come ha prodotto le geometrie, indicandone magari tutti i risvolti importanti ai fini di determinarne la qualita' intrinseca dle dato.<br>Naturalmente io parlo della scleta del metodo "lineage" piuttosto che il metodo "report". Anche perche' mi convience maggiormente e lo ritengo molto piu' adeguato a descrivere la qualità degli archivi <br>
geografici che vengono prodotti dalle nostre parti. (Per completezza devo anche dire che il RNDT privilegia invece il metodo del "report")<br><br>>a questo aggiungerei grossi problemi di ricerca!!credo sia necessario una sorta di protocollo e flusso di lavoro sui dati che non prescinde da una metadatazione.<br>
<br>Certo il protocollo di lavoro e' essenziale, te lo ho descritto all'incirca.<br>Ma del resto non e' pensabile che se si vuole tenere un archivio organizzato si possa mettere a disposizione uno spazio ove chiunque fa' un po' come gli pare.<br>
Con l'unico legame che sono tutte persone che parlano la stessa lingua e studiano nella medesima università :)<br><br>Per quanto riguarda la strada del metadato come meccanismo di ricerca:<br><br>La ricerca su metadato e' basata sul concetto della lista flat su cui poi te esegui una ricerca con determinate chiave , per isolare l'archivio o gli archivi di interesse.<br>
Il meccanismo della ricerca sul metadato non esclude assolutamente che gli archivi siano organizzati a cartelle gerarchiche.<br>Anzi usati insieme allargano la base di utenti soddisfatti.<br><br>La ricerca da metadato e' piu' rivolta a utenti occasionmali. Pero' tale metodo di ricerca, per produrre dei risultati soddisfacenti, richiede dei raffinamenti successivi.<br>
Questo perche' l'utente occasionale non riuscira' mai ad "azzeccare" le parole chiave impiegate. <br>Infatti, quello che succede di solito è che te cerchi un archivio, il sistema di metadati te ne propone qualche decina, a questo punto ti devi leggere una decina di abstract da cui desumere quale sia quello <br>
utile ai tuoi scopi. Ammesso che l'abstract contenge le informazioni utili per questa decisione. Non sempre le contiene. Ed è logico perche' il processo di scelta è un processo decisionale che deve <br>tenere conto delle esigenze che ha chi sta cercando l'archivio. A volte chi cerca l'archivio non ha neanche dei requisiti iniziali, ma guarda solo a quello che e' disponibile.<br>
Per questo l'abstract non basta, proprio perche' per sua natura è lacunoso su certi aspetti che se saputi potrebbero far pendere la scelta su un archivio o su un altro.<br>Pensa ad esempio al processo produttivo del dato.<br>
Sapere se il dato e' stato prodotto in un certo modo oppure in altro modo potrebbe certamente aiutare a decidere in certi casi.<br><br>Tutto questo va a merito della metainformazione, ma richiede certamente uno sforzo di lettura di svariate schede di mtd e non è uno scherzo leggerle.<br>
<br>Poi, ci sono gli utenti piu' esperti che prima ancora di fare una ricerca sul sistema dimetadati vogliono prima farsi una "giratina" (browsing) sugli archivi disponibili per vedere cosa vi e' su piazza<br>
e poi magari andare sul metadato per capire tra quelli piu' "papabili" quale sia quello piu' giusto.<br>Nella fase di browsing se gli archivi sono organizzati in maniera gerarchica, con una chiave di lettura che contestualizza l'archivio al suo impiego o meglio alla sua "ragione di essere"<br>
ecco che l'utente (parlo di utenti esperti) riesce in poco tempo a localizzare la zona dove ci sono i dati di suo interesse.<br><br>Io credo che questo descriva meglio il contesto lavorativo in cui ci si muove in un sistema "corporate".<br>
<br>Affidarsi completamente a un sistyema di ricerca su metadati rischia di tenere nascosti archivi interessantissimi, solo perche' hanno delle keyword troppo criptiche, oppure perche' il suo nome comincia con la "Z"<br>
e finisce sempre a pagina 12 nelle ricerche effettuate. :)<br><br>>A questo aggiungerei che le operazioni di ricerca diventerebbero difficoltose, anche all'interno delle dir create e gestite dagli utenti, specie quando si creano molte dir annidate e i dati sono molti Gb.<br>
<br>L'organizzazione ad albero delle cartelle serve proprio a semplificare e contestualizzare la lettura.<br>Esisten una vera e serie teria su come devono essere pesati questi alberi per avere la migliore resa in termini di ricerca.<br>
Ma in questo caso cio' che conta è la "semantica" del nodo dell'albero. Proproio perche' si rivolge a una perosna e non a un sistema automatico.<br>Ovvero il nome del nodo, che richiama ilconstestod degli archivi contenuti al suo interno aiuta a far capire all'utente se interessano o meno.<br>
<br></i>>Un'altro aspetto che valuterei è come stoccare i dati geografici, db alla grass (divisi per location)<br><br>Io non li dividerei per location.<br><br>La location e' trasversale al contesto.<br><br>Finiresti per avere un sacco di archivi che coprono tutti il medesimo territorio e quindi finiscono per ritrovarsi in tutte le medesime "location".<br>
<br>>o dati ripetuti nelle varie dir progettuali come suggerivi? non si crea ridondanza e Tb buttati?<br><br>Perche' dati ripetuti ?<br>Io parlo di contesti mutuamente esclusivi.<br>Se un archivio e' di aree-protette non può essere di opianificazione o di vincolo.<br>
<br>Forse non ho capito a cosa ti riferisci...<br><br>> In sostanza direi che concettualmente preferirei organizzare tutto x mezzo di un catalogo dati stoccati in un dbms, per questionilegate a maggiore potenza di ricerca e 'credo' ad un maggior controllo sui dati usati e prodotti dagli utenti,ma riconosco che l'approccio samba/file system è di gran lunga il più 'digerito' tra gli utenti, sebbene però molti dubbi  ancora mi rimangono.
<br>Non ho ben chiaro quale sia il vantaggio nell'averli in un DB ai fini della ricerca... :)<br>Il DB e' fortissimo quando si ricerca dei dati all'interno di una tabella, o di un gruppo prestabilito di tabelle, ma quando si ricerca la tabella che contiene certi dati senza sapere come tale tabella si chiami,<br>
il db comincia a scricchilare...Parli forse di un DB ad oggetti oppure NoSQL ?<br><br>In ogni caso credo che qui rientri prepotentemente il concetto di metainformazione, ma credo anche che si finisce per confondere la sua implementazione fisica <br>
con il suo uso concettuale.<br><br>>Saluti
>Eugenio</pre><br>you too.<br><br clear="all">Andrea.<br><br>-- <br>-----------------<br>Andrea Peri<br>. . . . . . . . . <br>qwerty àèìòù<br>-----------------<br><br>