[Gfoss] Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

[a.furieri a lqt.it]

On Fri, 22 Feb 2013 11:57:01 +0100, Andrea Peri wrote:
> Tutto giusto e mi torna perfettamente, in quanto attiene alle scelte
> fonanti e implementative che sono state prese nella specifica
> GeoPackage.
> Pensocpero' che convenga dettagliare meglio spiegando perche' si 
> parla
> di valore "0" . Cosa sia a me che a te perfettamente ovvia, ma che
> potrebbe sfuggire ad altri.
>

per pedante chiarezza :-)

la tavola "xml_medata" (quella dove vengono registrati i Metadati ISO)
deve necessariamente contenere sempre e comunque una riga di ID=0, con
md_scope=undefined e priva di payload XML significativo.

Convenzionalmente questa riga fittizia e' una sorta di "tappo", e serve
proprio per chiudere le catene gerarchiche: insomma, e' una 
dichiarazione
"vuota" da associare ai root-nodes, cioe' a quei nodi-capostipite che 
non
hanno padre.

Quindi riferire il metadato ID=0 e' semplicemente un modo convenzionale
chiaro ed assolutamente non ambiguo per dichiarare la chiusura della
catena nel pieno rispetto di tutti quanti i sacri vincoli relazionali
imposti dal DBMS.


> La scelta di usare un campo di tipo intero per memorizzare fileId e
> parentId (li abbrevio per comodita')
> è una scelta implementativa.
> Volendotrovare un punto debole di tale scelta, si puo' localizzare 
> nel
> fatto che costringe chi vuole impiegare dei valori testuali per i due
> campi fileId e parentId (visto che sono previsti tali da ISO) deve
> prevedere e attuare una loro transcodifica . Per cui la scelta valori
> interi anziche' valori testuali aumenta un po' la complessita'
> realizzativa.
>

attenzione: "fileIdentifier" e "fileParentIdentifier" sono attributi
XML, e quindi (opzionalmente) dichiarati all'interno del documento
XML che contiene i Metadati ISO.
viceversa "md_file_id" ed "md_parent_id" sono colonne DBMS, che 
addirittura
assurgono al ruolo strutturale di Primary/Foreign Keys.

ovviamente esiste una stretta corrispondenza, in entrambi i casi lo 
scopo
e' quello di dichiarare le catene gerarchiche child-parent; ma si 
tratta
comunque di oggetti diversi in contesti differenti.
incidentalmente: in un DBMS i vincoli Primary/Foreign Key basati su 
interi
sono decisamente piu' efficienti di quelli basati su stringhe 
(particolarmente
vero nel caso specifico di SQLite).

quindi il valore "integer lato DBMS" e quello "stringa lato XML" 
finiscono
semplicemente per diventare perfetti alias l'uno dell'altro, e sono 
sempre
in esatta corrispondenza univoca.

N.B.: e' comunque interessante notare che la specifica GeoPackage *non* 
si
basa direttamente sui valori dichiarati all'interno del documento XML
(proprio perche' sono elementi facoltativi, ed eventualmente potrebbero
anche essere del tutto assenti).
viceversa GeoPackage consente comunque di specificare tramite IDs 
numerici
le catene gerarchiche "funzionali" in qualsiasi scenario, anche quando 
i
documenti XML eventualmente non riportassero nessuna indicazione 
interna.


> All'esterno si veicola sempre e solo un XML scritto secondo le regole
> di ISO19115.
>
> In effetti su GeoPackage potrebbero nascere degli equivoci visto che
> rappresenta una specifico "mobile" e quindi potrebbe dalla finestra
> introdurre un meccanismo di spedifzione della metainformazione.
>

Andrea, concordo con te: GeoPackage si e' in qualche modo fermato a
meta' strada per quanto riguarda il supporto ai Metadati.
lo schema logico delle tavole DBMS e' assolutamente eccellente; ma il
fatto di lasciare il payload semplicemente definito come "un BLOB
che contiene un XML" (senza nessun trigger di validazione che entri
nel merito del contenuto) apre evidentemente la porta a millemila
fetenzie assortite :-P

immagino che visto tutto il fiorire di versioni e sottoversioni di
ISO 19115, INSPIRE etc etc OGC abbia preferito non entrare troppo
nei dettagli, fermandosi al livello piu' generico ed astratto 
possibile.

BTW visto che negli USA ancora sono largamente diffusi i metadati
FDGC, OGC in qualche modo ha voluto evidentemente avere un occhio
di riguardo per tutte le svariate Agenzie Federali che ancora si
trovano a sguazzare in un oceano di metadati FDGC legacy.


> Per questo non sarebbe affatto male se nella specifica GeoPackage
> fosse scritto (magari lo è, io non lo so') che la metainformazione si
> puo' recuperare solo tramite delle api che la estraggano e la
> traducano in un file XML secondo  la specifica ISO19115.
>

per tutti i motivi di cui sopra la specifica OGC preferisce
sorvolare elegantemente su tutti questi dettagli lasciando
una bella "zona grigia" aperta alle interpretazioni piu' varie ;-)

comunque sia: se c'e' un punto debole nell'architettura proposta
e' proprio esattamente questo.
l'implementazione supportata da SpatiaLite (ormai, di imminente
rilascio) sara' sicuramente molto piu' robusta e stringente ...
ed ovviamente, conterra' della API specifiche di supporto per gli
ISO Metadata.

ciao Sandro


-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.