[Gfoss] 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 àèìòù
-----------------