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

[Piergiorgio Cipriano]

Davvero interessante.
Grazie

pg

______________________________
Piergiorgio Cipriano



Il giorno 22 febbraio 2013 11:12, <a.furieri a lqt.it> ha scritto:

> 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<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/<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.
>
> ______________________________**_________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/**mailman/listinfo/gfoss<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
>
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130222/6991b198/attachment.html>