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

[a.furieri a lqt.it]

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

tutto ruota attorno a due sole tavole DBMS:

CREATE TABLE xml_metadata (
  id INTEGER CONSTRAINT xm_pk PRIMARY KEY ASC
     ON CONFLICT ROLLBACK AUTOINCREMENT NOT NULL UNIQUE,
  md_scope TEXT NOT NULL DEFAULT 'dataset',
  metadata_standard_URI TEXT NOT NULL
    DEFAULT 'http://schemas.opengis.net/iso/19139/',
  metadata BLOB NOT NULL DEFAULT (zeroblob(4))
)

CREATE TABLE metadata_reference (
   reference_scope TEXT NOT NULL DEFAULT "table",
   table_name TEXT NOT NULL DEFAULT "undefined",
   column_name TEXT NOT NULL DEFAULT "undefined",
   row_id_value INTEGER NOT NULL DEFAULT 0,
   timestamp TEXT NOT NULL DEFAULT
     (strftime('%Y-%m-%dT%H:%M:%fZ',CURRENT_TIMESTAMP)),
   md_file_id INTEGER NOT NULL DEFAULT 0,
   md_parent_id INTEGER NOT NULL DEFAULT 0,
   CONSTRAINT crmr_mfi_fk FOREIGN KEY (md_file_id)
     REFERENCES xml_metadata(id),
   CONSTRAINT crmr_mpi_fk FOREIGN KEY (md_parent_id)
     REFERENCES xml_metadata(id)
)

e' interessante notare come sia "md_file_id" che "md_parent_id"
assurgono addirittura al rango di Foreign Key (quindi hanno un
ruolo strutturale decisamente forte).

"md_scope" puo' essere uno qualsiasi tra:
undefined,fieldSession,collectionSession,series,dataset,
featureType,feature,attributeType,attribute,tile,model,
catalogue,schema,taxonomy,software,service,collectionHardware,
nonGeographicDataset,dimensionGroup

"reference_scope" puo' essere uno qualsiasi tra:
table,column,row,row/col

"table_name", "column_name" e "row_id_value" consentono di
stabilire i riferimenti relazionali con gli oggetti contenuti
nel DBMS, che possono essere indifferentemente di tipo Vector
ma anche Raster (aka tiles).

la struttura relazione proposta e' estremamente flessibile,
e puo' coprire efficacemente tutti i possibile casi d'uso.

- piu' tavole possono fare riferimento ad un medesimo Metadato
- un Metadato puo' essere associato ad un'intera tavola; ma
   e' anche possibile definire un Metadato per una singola
   colonna/attributo
- una singola riga/entita' puo' avere associato un suo Metadato
   specifico (ovviamente, vale anche per gruppi di righe selezionate).
- infine, addirittura un singolo valore-attributo riga/colonna puo'
   avere un proprio specifico Metadato.

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

---------------------------------------------
chi fosse eventualmente intressato ad approfondire, nell'Annex C
della specifica GeoPackage e' presente una serie di esempi molto
chiari e decisamente illuminanti sui corretti criteri da adottare
per rappresentare la struttura gerarchica dei Metadati.

concludendo: almeno secondo l'interpretazione OGC-GeoPackage non
esiste alcun dubbio possibile.

A) i metadati formano una catena gerarchica parent-child; tutte
    le catene devono obbligatioramente iniziare con un elemento
    "root" che si riconosce perche' punta ad un parent con ID=0
B) assolutamente nulla lascia trapelare l'eventualita' che
    "parent" possa essere utilizzato per gestire il versioning;
    viceversa e' di cristallina chiarezza che deve servire
    esclusivamente per rappresentare le catene gerarchiche
    parent-child
C) secondo questa interpretazione, dichiare il medesimo valore
    per "md_file_id" e "md_parent_id" causa una sorta di loop
    infinito durante la fase di ricostruzione della catena :-D
    il valore convenzionale atteso per verificare di essere
    effettivamente giunti alla root (nodo iniziale) di una
    catena e' sempre e solo ZERO

ciao Sandro


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