Davvero interessante. Grazie pg
______________________________ Piergiorgio Cipriano Il giorno 22 febbraio 2013 11:12, <a.furi...@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@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 >
_______________________________________________ Gfoss@lists.gfoss.it 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
