[Gfoss] consigli su stoccaggio dati‏

[Andrea Peri]

>>* From: Andrea Peri <aperi2007 a gmail.com <http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss>>*>>* To: gfoss a lists.gfoss.it <http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss>*>* Subject: [Gfoss] consigli su stoccaggio dati‏*>* 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,
>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
>solamente un archivio? dati stoccati e non più utilizzati?
**>gli utenti utilizzerebbero i dati a cui hanno accesso sia in
scrittura che lettura?
**Usi il termine sbagliato.
Si tratterebbe di una area di dati realmente utilizzati.
Io parlo di una area read-only.
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.
Nessuno puo' ad esmepio modificare un vertice, cambiare un attrivuto o
cancellare qualcosa.

I dati nelle aree di lavoro scrivibili da tutti non sono realmente usabili.
E questo proprio per il fatto che sono scrivibili da chiunque.
Ad esempio:
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
per qualche altra ragione certamente valida (per lui).

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
la sua decodifica. Magari perche' cosi' l'etichetta nelle stampe e'
piu' facile da fare senza ingrullire troppo.

Insomma e' esperienza acquisita che con gli archivi di lavoro ci
lavora solo chi li produce.
Per renderliusabili agli altri utenti vanno "fissati", ovvero resi read-only .
Solo in questo modo diventano realmente usabili in un ambiente "corporate".

>il lavoro del responsabile dati che deve poi migrare i dati dalla zona open alla zona restricteddiventerebbe enorme,

Si' e' un lavoro impegnativo, ma non lo definirei enorme.
Dopo un po' di tempop ci prendi la mano e tutto diviene facile.
Ovviamente occorre coordinare il lavoro in partenza.
Ovviamente io parlo di una situazione in cui un archivio sviluppato e'
finalizzato a uno scopo istituzionale ,
e quindi dietro di esso vi e' una norma , un regolamento.
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.

Perche' e' ovvio che facendo cosi' poi e' difficile inserire tale
archivio in un costento insieme ad altri archivi mantenendolo
coerente.

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',
se si' tale parte viene scorporata dal lavoro da fare, perche' gia' esistente.
Poi concorda la struttura dell'archivio e in particolare i domini.
Concorda anche i nomi dei files e dei campi.
sempre perche' vi e' la necessita' di essere coerenti in un contesto allargato.

Mi spiego con un esmepio semplice:
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.
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
all'archivio esistente. Caso mai usa delle chiavi esterne (che puoi
inserire anche in uno shapefile) per legarsi all'archivio dei confini
comunali.

Poi, un altro esempio e' la codifica degli oggetti.
Infatti chi sviluppa un archivio tende a essere "tolomeico" ovvero
pensa che il suo archivio sara' al centro dell'universo.
Per cui non si preoccupa di mettere delle codifiche che reggano anche
all'uso in un contesto allargato.
Ad esmepio codifica con "1,2,3,4" oppure ci mette una codifica che
regge a livello di indagine.
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
all'uso su una scala piu' vasta

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
nel contesto del repository, permettera' di poter inserire l'archivio
fin da subito nel repository.

>se non viene stabilito un flusso di lavoro sul dato, un metodo di metadatazionea monte...o no?

La metadatazione, non aiuta nella progettazione, ma serve per il riuso
a posteriori.
E' piu' rivolta all'uso del dato da parte di un utente finale.
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.
Mentre invece e' contemplato la descrizione a posteriroi del processo
produttivo.
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
la sua indagine e come ha prodotto le geometrie, indicandone magari
tutti i risvolti importanti ai fini di determinarne la qualita'
intrinseca dle dato.
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
geografici che vengono prodotti dalle nostre parti. (Per completezza
devo anche dire che il RNDT privilegia invece il metodo del "report")

>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.

Certo il protocollo di lavoro e' essenziale, te lo ho descritto all'incirca.
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.
Con l'unico legame che sono tutte persone che parlano la stessa lingua
e studiano nella medesima università :)

Per quanto riguarda la strada del metadato come meccanismo di ricerca:

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.
Il meccanismo della ricerca sul metadato non esclude assolutamente che
gli archivi siano organizzati a cartelle gerarchiche.
Anzi usati insieme allargano la base di utenti soddisfatti.

La ricerca da metadato e' piu' rivolta a utenti occasionmali. Pero'
tale metodo di ricerca, per produrre dei risultati soddisfacenti,
richiede dei raffinamenti successivi.
Questo perche' l'utente occasionale non riuscira' mai ad "azzeccare"
le parole chiave impiegate.
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
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
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.
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.
Pensa ad esempio al processo produttivo del dato.
Sapere se il dato e' stato prodotto in un certo modo oppure in altro
modo potrebbe certamente aiutare a decidere in certi casi.

Tutto questo va a merito della metainformazione, ma richiede
certamente uno sforzo di lettura di svariate schede di mtd e non è uno
scherzo leggerle.

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
e poi magari andare sul metadato per capire tra quelli piu' "papabili"
quale sia quello piu' giusto.
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"
ecco che l'utente (parlo di utenti esperti) riesce in poco tempo a
localizzare la zona dove ci sono i dati di suo interesse.

Io credo che questo descriva meglio il contesto lavorativo in cui ci
si muove in un sistema "corporate".

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"
e finisce sempre a pagina 12 nelle ricerche effettuate. :)

>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.

L'organizzazione ad albero delle cartelle serve proprio a semplificare
e contestualizzare la lettura.
Esisten una vera e serie teria su come devono essere pesati questi
alberi per avere la migliore resa in termini di ricerca.
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.
Ovvero il nome del nodo, che richiama ilconstestod degli archivi
contenuti al suo interno aiuta a far capire all'utente se interessano
o meno.

*>Un'altro aspetto che valuterei è come stoccare i dati geografici, db
alla grass (divisi per location)

Io non li dividerei per location.

La location e' trasversale al contesto.

Finiresti per avere un sacco di archivi che coprono tutti il medesimo
territorio e quindi finiscono per ritrovarsi in tutte le medesime
"location".

>o dati ripetuti nelle varie dir progettuali come suggerivi? non si crea ridondanza e Tb buttati?

Perche' dati ripetuti ?
Io parlo di contesti mutuamente esclusivi.
Se un archivio e' di aree-protette non può essere di opianificazione o
di vincolo.

Forse non ho capito a cosa ti riferisci...

> 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.
Non ho ben chiaro quale sia il vantaggio nell'averli in un DB ai fini
della ricerca... :)
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,
il db comincia a scricchilare...Parli forse di un DB ad oggetti oppure NoSQL ?

In ogni caso credo che qui rientri prepotentemente il concetto di
metainformazione, ma credo anche che si finisce per confondere la sua
implementazione fisica
con il suo uso concettuale.

>Saluti
>Eugenio


you too.

Andrea.

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20120512/e4307cc6/attachment-0001.html>