Davvero interessante.<div>Grazie<br><div><br></div><div>pg<br clear="all"><div><div> </div><div>______________________________</div><div>Piergiorgio Cipriano</div><div> </div></div>
<br><br><div class="gmail_quote">Il giorno 22 febbraio 2013 11:12,  <span dir="ltr"><<a href="mailto:a.furieri@lqt.it" target="_blank">a.furieri@lqt.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Giusto per aggiungere qualche ulteriore elemento di valutazione:<br>
OGC sta discutendo proprio in questi giorni il nuovo standard<br>
GeoPackage, che tra le altre cose si preoccupa anche di standardizzare<br>
come vanno registrati i Matadati ISO all'interno di un DBMS (SQLite) [1].<br>
Ancora di tratta solo di un "candidate standard" [1], ma e' sicuramente<br>
interessante prendere in considerazione l'implementazione proposta.<br>
<br>
[1] <a href="https://portal.opengeospatial.org/files/?artifact_id=51391" target="_blank">https://portal.opengeospatial.<u></u>org/files/?artifact_id=51391</a><br>
<br>
tutto ruota attorno a due sole tavole DBMS:<br>
<br>
CREATE TABLE xml_metadata (<br>
 id INTEGER CONSTRAINT xm_pk PRIMARY KEY ASC<br>
    ON CONFLICT ROLLBACK AUTOINCREMENT NOT NULL UNIQUE,<br>
 md_scope TEXT NOT NULL DEFAULT 'dataset',<br>
 metadata_standard_URI TEXT NOT NULL<br>
   DEFAULT '<a href="http://schemas.opengis.net/iso/19139/" target="_blank">http://schemas.opengis.net/<u></u>iso/19139/</a>',<br>
 metadata BLOB NOT NULL DEFAULT (zeroblob(4))<br>
)<br>
<br>
CREATE TABLE metadata_reference (<br>
  reference_scope TEXT NOT NULL DEFAULT "table",<br>
  table_name TEXT NOT NULL DEFAULT "undefined",<br>
  column_name TEXT NOT NULL DEFAULT "undefined",<br>
  row_id_value INTEGER NOT NULL DEFAULT 0,<br>
  timestamp TEXT NOT NULL DEFAULT<br>
    (strftime('%Y-%m-%dT%H:%M:%fZ'<u></u>,CURRENT_TIMESTAMP)),<br>
  md_file_id INTEGER NOT NULL DEFAULT 0,<br>
  md_parent_id INTEGER NOT NULL DEFAULT 0,<br>
  CONSTRAINT crmr_mfi_fk FOREIGN KEY (md_file_id)<br>
    REFERENCES xml_metadata(id),<br>
  CONSTRAINT crmr_mpi_fk FOREIGN KEY (md_parent_id)<br>
    REFERENCES xml_metadata(id)<br>
)<br>
<br>
e' interessante notare come sia "md_file_id" che "md_parent_id"<br>
assurgono addirittura al rango di Foreign Key (quindi hanno un<br>
ruolo strutturale decisamente forte).<br>
<br>
"md_scope" puo' essere uno qualsiasi tra:<br>
undefined,fieldSession,<u></u>collectionSession,series,<u></u>dataset,<br>
featureType,feature,<u></u>attributeType,attribute,tile,<u></u>model,<br>
catalogue,schema,taxonomy,<u></u>software,service,<u></u>collectionHardware,<br>
nonGeographicDataset,<u></u>dimensionGroup<br>
<br>
"reference_scope" puo' essere uno qualsiasi tra:<br>
table,column,row,row/col<br>
<br>
"table_name", "column_name" e "row_id_value" consentono di<br>
stabilire i riferimenti relazionali con gli oggetti contenuti<br>
nel DBMS, che possono essere indifferentemente di tipo Vector<br>
ma anche Raster (aka tiles).<br>
<br>
la struttura relazione proposta e' estremamente flessibile,<br>
e puo' coprire efficacemente tutti i possibile casi d'uso.<br>
<br>
- piu' tavole possono fare riferimento ad un medesimo Metadato<br>
- un Metadato puo' essere associato ad un'intera tavola; ma<br>
  e' anche possibile definire un Metadato per una singola<br>
  colonna/attributo<br>
- una singola riga/entita' puo' avere associato un suo Metadato<br>
  specifico (ovviamente, vale anche per gruppi di righe selezionate).<br>
- infine, addirittura un singolo valore-attributo riga/colonna puo'<br>
  avere un proprio specifico Metadato.<br>
<br>
------------------------------<u></u>---------------<br>
venendo alla vexatissima queastio:<br>
<br>
"md_file_id"<br>
value for the metadata to which this metadata_reference applies<br>
<br>
"md_parent_id"<br>
value for the hierarchical parent metadata for the metadata to<br>
which this metadata_reference applies<br>
<br>
Every GeoPackage metadata_reference table that contains any rows<br>
shall contain at least one row record with an md_parent_id value<br>
of 0 that references the ‘undefined’ xml_metadata row record as<br>
defined by the SQL in table 51. Such record(s) establish the<br>
metadata reference to the “root” of a metadata hierarchy.<br>
<br>
------------------------------<u></u>---------------<br>
chi fosse eventualmente intressato ad approfondire, nell'Annex C<br>
della specifica GeoPackage e' presente una serie di esempi molto<br>
chiari e decisamente illuminanti sui corretti criteri da adottare<br>
per rappresentare la struttura gerarchica dei Metadati.<br>
<br>
concludendo: almeno secondo l'interpretazione OGC-GeoPackage non<br>
esiste alcun dubbio possibile.<br>
<br>
A) i metadati formano una catena gerarchica parent-child; tutte<br>
   le catene devono obbligatioramente iniziare con un elemento<br>
   "root" che si riconosce perche' punta ad un parent con ID=0<br>
B) assolutamente nulla lascia trapelare l'eventualita' che<br>
   "parent" possa essere utilizzato per gestire il versioning;<br>
   viceversa e' di cristallina chiarezza che deve servire<br>
   esclusivamente per rappresentare le catene gerarchiche<br>
   parent-child<br>
C) secondo questa interpretazione, dichiare il medesimo valore<br>
   per "md_file_id" e "md_parent_id" causa una sorta di loop<br>
   infinito durante la fase di ricostruzione della catena :-D<br>
   il valore convenzionale atteso per verificare di essere<br>
   effettivamente giunti alla root (nodo iniziale) di una<br>
   catena e' sempre e solo ZERO<div class="im HOEnZb"><br>
<br>
ciao Sandro<br>
<br>
<br>
-- <br>
Il messaggio e' stato analizzato alla ricerca di virus o<br>
contenuti pericolosi da MailScanner, ed e'<br>
risultato non infetto.<br>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
<a href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/<u></u>mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.<br>
630 iscritti al 1.12.2012</div></div></blockquote></div><br></div></div>