Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

[Andrea Peri]

Ciao Alessandro, ti rispondo tra le righe.

>Giusto per aggiungere qualche ulteriore elemento di valutazione:
>OGC sta discutendo proprio in questi giorni il nuovo standard
>GeoPackage, che tra le altre cose si preoccupa anche di standardizzare
>come vanno registrati i Matadati ISO all'interno di un DBMS (SQLite)
>[1].
>Ancora di tratta solo di un "candidate standard" [1], ma e' sicuramente
>interessante prendere in considerazione l'implementazione proposta.
>
>[1] https://portal.opengeospatial.org/files/?artifact_id=51391
>

> ....

>venendo alla vexatissima queastio:
>
>"md_file_id"
>value for the metadata to which this metadata_reference applies
>
>"md_parent_id"
>value for the hierarchical parent metadata for the metadata to
>which this metadata_reference applies
>
>Every GeoPackage metadata_reference table that contains any rows
>shall contain at least one row record with an md_parent_id value
>of 0 that references the ‘undefined’ xml_metadata row record as
>defined by the SQL in table 51. Such record(s) establish the
>metadata reference to the “root” of a metadata hierarchy.

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.

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.

Oppure si è costretti a risolverla con una regola artificosa esterna al sistema.
Una cose del tipo:

"i valori di fileId e (di conseguenza) di parentId devono essere
solamente di tipo numerico-intero."

La cosa è ammissibile perche' ovviamente nel range delle stringhe ci
stanno anche i numeri come loro "subset", e quando iso dice che si
usano stirnghe di testo uno puo' anche ritenere di limitarsi alle
stringhe che rappresentino dei numeri.


Piu' interessante e sofisticato invece rispondere alla ultima parte
della tua conclusione, quella dove spieghi che per GeoPackage quando
siamo a livello di serie si mette "0".

La cosa è perfettamente lecita perche' attiene a un livello
implementativo di un sistema. :)
Infatti in un campo di un database (quale è il geopackage) o ci si
mette NULL o ci si mette EMPTY o ci si mette un valore.
La scelta di metterci zero è determinata dal garantire la massima
portabilita' su varie tipologie di database.

Non va dimenticato infatti che la specifica ISO19115 e la sua versione
implementativa ISO19139 si riferiscon a files xml come unico strumento
di contenimento ( ai soli fini di scambio o di trasporto) del
contenuto informativo di una scheda ISO19115.

Ovvero uno le schede le archivia dove gli pare, nel sistema software
che ritiene piu' pratico e piu' adeguato alle sue necessita', pero'
quando le deve spedire a qualcuno, le spedisce sottoforma di un file
XML realizzato con i contenuti informativi della specifica ISO19115 e
ulteriormente specificato dalla specifica ISO19139.

Quindi occorre capire come in un file XMLsi gestisce l'assenza di informazione.
Sottolineo in un DB l'assenza di informazione si gestisce valorizzando
il campo con un valore che rappresenta tale condizione . In certi DB
si mette il NULL, in altri si mette 0.
In GeoPackage scelgono di metterci zero.

Invece in un file XML per la specifica iso19115, quando un elemento
non ha valore , anziche' metterci un valore a cui convenzionalmente
gli si assegna il compito di rappresentare il nullo (0 nel caso del
campo del geopackage) si puo' piu' semplicemente e doverosamente
omettere il tag.

Per cui dovendo alla fine generare un XML che veicoli la scheda di
metainformazione:

Se un campo non viene valorizzato (come il campo parentIdentifier)
quando la scheda è di tipo serie o quando pur essendo di tipo
"dataset" non ha un padre,
nell'xml si omette il tag parentIdentifier. E' da questo aspetto
comportamentale dell' XML che a mio parere deriva l'opzionalit'a del
campo parentID.
Perche' se tale campo fosse stato obbligatorio, ISO19115 avrebbe
dovuto normare con che valore si indica che non vi è un padre.

Ovviamente , questa regola comportamentale di omettere il tag ha senso
nell' XML, non ha nessun senso invece quando si inserisce la scheda in
un DB.
Dove i campi sono fissati e prestabiliti.
In tal caso è gioco forza necessario metterci un valore.
Ma quello attiene a un livello di tipo implementativo e non ha e non
deve avere riflessi all'esterno del sistema.

Per cui nella specifica GPK adottano il valore 0, in altri sistema
(geonetwork) faranno in una altra maniera, nei sistemi di altri
produttori potranno essere usate soluzioni ancora differenti.

Ma resta sempre un discorso esterno al DB.
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.

Basta spedire il geopackage. :)

Creando ulteriore confusione.

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.

Andrea.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
630 iscritti al 1.12.2012

[a.furieri]

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.

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
630 iscritti al 1.12.2012

[Antonio Rotundo]

Molto interessante. Voglio approfondire anche in relazione al DB modellato per il RNDT.
Saluti,
Antonio