Salve,
grazie per l'intervento e le delucidazioni. Sono conscio che si puo' attivare un eventuale canale di colloquio punto a punto, ma poiche' ritengo che queste conoscenze siano di interesse generale. Credo che sia anche nel vostro interesse che la platea su come ci si interfaccia con RNDT sia abbastanza allargata da permettere a molti di imparare. Io per primo. Anche perche' da una parte ci sono discussioni in merito a Inspire e dal'altra su RNDT. In real'ta credo sia uitle a parecchi (parlo di chi produce dati e deve fornire schede di metadato) capire le problematiche che ci sono nel mondo dei metadati. Problematche non solo nei contenti (che gia' di per se bastano a riempire una vita) , ma anche nella strutturazione di campi e loro significati. Venendo ai punti della vostra risposta, Mi interessa in particolare esplorere meglio un dettaglio del discorso: Sono perfettamente conscio che ISO permette di evolvere lo schema. Questa cosa tra l'altro è stata molto ultilizzata da RNDT. Che infatti ha reso obbligatori molti elementi che su ISO erano facoltativi . Questo comportamento è perfettamente lecito e per giunta mi trova daccordo rendere obbligaotiro un campo nel momento in cui si ritiene che una determinata "informazione di contenuto" sia di importanza tale da dover essere sempre presente. Un piccolo dettaglio, ma marginale, riguarda il fatto che per ISO19115 una informazione facoltativa non è una informazione che non serve a niente, ma piuttosot una informazione che non sempre è disponibile. Mentre ,s empre per ISO una informazione obbligatoria è una informazione "sempre disponibile". Per cui quand si rende obbligaotoria una iformazione di contenuto occorre prima rispondersi alla domanda se tale informazione è sempre dispinibile. La risposta è affermativa se si parla di cmapi come il nominativo dell'ente da contattare, oppure dell'indirizzo di email di un detemrinato responsabile. Sono meno sicuro che sia affermativa quando leggo che tra gli obbligatori RNDT ha messo anche il campo "AbsoluteExternalPositionalAccuracy" come valore da esprimere in metri. Visto che l'espressione di tale valore comporta un rilievo in campo con strumenti dotati di una sufficiente precisione. Invece, mi trova un po' piu' perplesso quando tale possibilit'a viene applicata a campi che riguardano dei legami strutturali tra le schede. Ovvero non riguardano "informazioni di contenuto". Attenzione pero' che io non mi sto' riferendo ai contenuti del campo FileIdentifier. Come dicevo nel mio precedente intervento , poiche' ISO dichiarava tale campo di tipo testo uno puo' anche sceglierci di riportarci un identificartore che sia di una qualsivoglia natura. E quindi niente da eccepire sulla scelta fatta. Salvo un leggero retrogusto amaro basato sul fatto che adottare come prefisso un qualcosa che localizza chi spedisce il dato potrebbe alla lunga trarre in inganno, specie per le schede di metadato che non sono destinate a risiedere sempre e solo nel RNDT ma piuttosto a viaggiare assieme al dato stesso. Ma vorrei passare oltre anche questo aspetto e arrivare invece al punto saliente. Quindi, tornando alla punto centrale del discorso e in particolare all'aver reso sempre obbligatorio il campo "parentIdentifier". E' vero che ISO consente di rendere obbligatorio genericamente qualsiasi campo, ma occorre anche vedere se ha senso farlo e in tal caso occorre anche accollarsi l'onere di mantenere la definizione coerente. In questo caso con un parentIdentifier obbligatorio la coerenza a mio parere (ma saro' felice se mi spiegate che mi sbaglio) viene meno. Infatti se si dice che parentIdentifier contiene e il valore della scheda "parente" ovvvero di quella che nei sistemi a oggetti chiamano "antenato", esso è logicamente opzionale perche' una scheda puo' non avere un padre. L'averlo reso obbligatorio sempre fa si che esso deve cambiare significato a seconda della situazione al contorno della scheda. Ha un significato se la scheda è dota di un legame con un'altra scheda padre. Ed avrà di converso un altro significato se la scheda non ha un legame con una altra scheda (ovvero non ha una scheda padre) Quindi va a finire che tale campo contiene dei valori che possono seguire regole differenti a seconda dello stato in cui la scheda si trova. Se si considera che una scheda puo' nascere senza una scheda padre , perche' chi la compila sceglie di dettagliarla cosi', e poi successivamente essa potrebbe acquisire lo stato di scheda figlia nei confronti di una altra scheda (che sarebbe, di converso, padre) perche nel frattempo l'archivio si è evoluto in una determinata direzione. Si capisce che questo cambio di significato a seconda dello stato in cui si trova una scheda non è per niente facile da gestire. Per cui tornando a ISO. Verissimo che ISO permetteva di fare dei cambiamenti, anche rivolti a rendere obbligatori dei campi. Ma tale filosofia era primariamente rivolta a permettere di rendere obbligatori delle informazioni di contenuto. Ad esmepio a rendere obbligatorio ilnome del contatto , oppure a rendere obbligaotrio l'indirizzo di email e roba di questo genere. Altresi' ISO permetteva di aggiungere nuovi contenuti, ma anche qui la filosofia era di dare mergine per inserire delle informazioni di contenuto mancanti. Ad esempio , il passo di campionamento su un dato lidar oppure la paeltta dei colori su una immagine. E poi "last but not least". Che vantaggio porta questa scelta ? Mentre capisco che rendere obbligatoria una informazione di contenuto (la email del contatto ad esmepio) puo' servire. A che serve aver reso obbligatorio parentIdentifier ? Purtroppo io dal miopuntodi vista percepisco solo gli svantaggi. Ovvero il non poter usare un software gia esistente. ma anche il non potermi tenere aggiornato con tale software (geonetwork) via via che esso si evolve milgiorandosi e aggiungendo sempre nuove e piu' potenti features. >9)confermo che il CSI Piemonte sta lavorando ad un profilo RNDT per GN. La >soluzione prodotta, una volta validata dall'Agenzia, sarà resa disponibile >per il riuso; Non conosco i dettagli di questo lavoro. Ma visto che lo citate , forse potete rispondere a questa domanda: Si tratta di un fork di prodotto o di un plugin da poter applicare alla versione scaricabile dal sito di GN ? Se come immagino la risposta sia la prima. Come potrà essere gestito l'adeguamento di tale prodotto alle nuove versioni di GN ? Ad esempio: la versione 2.6 non è certificata per Inspire ed è molto lacunosa sui meccanismi di harvesting. tante' che ha dei bugs gia' riconosciuti che sono stati corretti nella successiva versione 2.8.0 La versione 2.8.0 uscira tra pochi giorni da oggi. Quando essa uscira la versione da voi crtificata probabilmente diverrà obsoleta ovvero non allineata all'ultima versione di GN. E questo succederà da ora in avanti finche' GN non adottasse al suo interno le varianti a ISO pensate da RNDT. Faccio questo raginonamento solo per esmeplificare una volta di piu' cosa comporta una eventale scelta di customizzare dei formati (iso in questo caso) con scelte che sebbene formalmente valide, finiscono per allontanare dai prodotti GFoss gia' esistenti e disponibili. Ad esempio: Infatti GN nella versione 2.6, oltre a dei "piccoli" bugs , ha anche un bug noto che (too files open bug) che la portava a schiantare quando è da troppo tempo attiva e funzionante. Questo piccolo bug è stato di recente risolto. Se una personalizzazione porta a un fork di prodotto, questo comporta che queste evoluzioni e correzioni, non sono facilmente accessibili a chi adotta la versione "forked". E di conseguenza deve cercare ( e probabilmente pagare) qualcuno che riporti tali evoluzioni dentro il proprio prodotto. Per questo è buona pratica non allontanarsi mai da uno standard, ma, muovendosi nei dettagi di uno standard, è importante anche compiere scelte che garantiscano una platea di prodotti allargata. Anche per evitare che poi parecchi enti si debbano dotare di versioni "forked" di altri prodotti, con tutto un onere di manutenzione non indifferente. Restando quindi su un piano strettamente tecnico, a vostro parere quale è la strada piu' efficiente: Sarebbe piu' efficiente ripensare il significato del campo "parentIdentifier" all'interno del sistema di RNDT oppure è piu' efficiente chiedere che tutti gli altri enti si dotino di softwares che seguano la logic del aprentIdentifier come la tratta ora RNDT ? Saluti, e grazie per il confronto tecnico estremamente utile e istruttivo per tutti. ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
Ciao Andrea,
concordo con te sulla utilita' della mailing list per condividere dubbi e possibili soluzioni di interesse generale.
Forse, pero', con un colpo di telefono ad Antonio (Rotundo) avresti risparmiato qualche riga di mail! Rispondo alla tua mail solo su due punti. 1) elementi ISO obbligatori
Sai meglio di me che gli elementi "obbligatori" previsti a livello di schemi 19139 (dataset o serie) sono solo:
- il ruolo del contatto responsabile per i metadati - la data (del metadato) - il titolo - la data (del dataset/serie) - l'abstract - la lingua Tutto il resto, per 19139, e' opzionale. Ogni profilo del 19115/19139 puo' lecitamente rendere obbligatori altri elementi, o anche porre vincoli a livello di contenuto (non verificabili quindi solo con una semplice validazione xsd ma con schematron o altri tipi di controlli).
2) gestione del "parentId" e GeoNetwork Dal punto di vista tecnico, mi sembra un problema superabile a livello XSLT ... o no? Il problema per me e' un altro, e non e' tecnologico ma concettuale e organizzativo: quando un metadato e' una nuova versione di uno precedente (quindi con fileIdentfier e parentId con valori diversi), e quando invece e' realmente un nuovo metadato (quindi con lo stesso valore)?
Su questo sarebbe utile un commento da parte di GeoSolutions o CSI, visto che ci stanno lavorando su per Regione Piemonte. O di qualcuno in Provincia di Trento (ha fatto / sta facendo una cosa analoga [1]) o di qualcuno in Provincia di Bolzano, visto che sono stati tra i primi a mettere in produzione GN [2] o di altri enti che stanno usando GN e magari hanno fatto qualche personalizzazione.
pg p.s. in riferimento al punto 1) questo sotto e' un xml valido dal punto di vista xsd 19139, ovviamente non per il profilo Inspire ne' per RNDT
<?xml version="1.0" encoding="UTF-8"?> <gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:geonet="http://www.fao.org/geonetwork" xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd">
<gmd:contact> <gmd:CI_ResponsibleParty> <gmd:role> <gmd:CI_RoleCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode" codeListValue="originator" />
</gmd:role> </gmd:CI_ResponsibleParty> </gmd:contact> <gmd:dateStamp> <gco:DateTime>2011-11-18T09:59:22</gco:DateTime>
</gmd:dateStamp> <gmd:identificationInfo> <gmd:MD_DataIdentification> <gmd:citation> <gmd:CI_Citation> <gmd:title>
<gco:CharacterString>bla bla bla</gco:CharacterString> </gmd:title> <gmd:date> <gmd:CI_Date> <gmd:date>
<gco:Date>2011-09-30</gco:Date> </gmd:date> <gmd:dateType> <gmd:CI_DateTypeCode codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode" codeListValue="revision" />
</gmd:dateType> </gmd:CI_Date> </gmd:date> </gmd:CI_Citation> </gmd:citation> <gmd:abstract>
<gco:CharacterString>bla bla bla</gco:CharacterString> </gmd:abstract> <gmd:language> <gco:CharacterString>ita</gco:CharacterString>
</gmd:language> </gmd:MD_DataIdentification> </gmd:identificationInfo> </gmd:MD_Metadata> ______________________________
Piergiorgio Cipriano Il giorno 21 febbraio 2013 10:20, Andrea Peri <[hidden email]> ha scritto: Salve, _______________________________________________ [hidden email] 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 |
On Thu, 21 Feb 2013 19:42:50 +0100, Piergiorgio Cipriano wrote:
> p.s. in riferimento al punto 1) > questo sotto e' un xml valido dal punto di vista xsd 19139, > ovviamente > non per il profilo Inspire ne' per RNDT > confermo: ho appena verificato ... il tuo sample passa la validazione di Schema XSD senza fare neppure la piu' minuscola piegolina :-) ciao Sandro -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. _______________________________________________ [hidden email] 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 |
In reply to this post by Piergiorgio Cipriano
Ciao PG,
scusa ma con il tuo intervento in realta' mi convinci sempre di piu' che è utile una discussione allargata perche' come al soltio il tuo intervento entra sempre nel dettaglio del metadato ed è percio' molto interessante. Mi permetto percio' di rispondere alle tue osservazioni. > Tutto il resto, per 19139, e' opzionale. > Ogni profilo del 19115/19139 puo' lecitamente rendere obbligatori altri > elementi, o anche porre vincoli a livello di contenuto (non verificabili > quindi solo con una semplice validazione xsd ma con schematron o altri tipi > di controlli). > Non mi pare di aver detto il contrario. Sottoscrivo ogni singola stringa di cio' che è sopra scritto. Porre vincoli di contenuto è perfettamente lecito. Ma dire sul campo parentIdentifier ci si puo' scrivere il medesimo valore che nella stessa scheda è trascritto nel campo parentIdentifier è un po' di piu' che porre un vincolo di contenuto. Quanto piuttosto porre una regola condizionale alla struttura. > 2) gestione del "parentId" e GeoNetwork > Dal punto di vista tecnico, mi sembra un problema superabile a livello XSLT > ... o no? Tutto è superabile nell'informatica. Forse l'xslt da solo non basta e occorre anche una procedura informatica a sostegno perche' una semplice procedura sequenziale sul flusso xml della scheda di metadato puo' non bastare per riassegnare tutti i giusti valori. La scheda di metadato ha i tags ordinati sequenzialmente e potrebbe darsi che un tag debba essere valirizzato prima che si conoscano i valori necessari per determinare il valore da imporre al tag. Feci qualche prova un paio di anni fa' su geonetwork, ma allora mi concentrai essenzialmente sulla produzione di una scheda appiattita e non considerai la problematica del parentIdentifier. Se ci si limita al problema del parentIdentifier sicuramente con una procedura xslt si puo' ovviare. Infatti il campo parentIdentifier è successivo al campo fileIdentifier e quindi quando si arriva nella procedura xslt a valorizzare tale campo il valore da metterci è gia' stato recepito. > Il problema per me e' un altro, e non e' tecnologico ma concettuale e > organizzativo: quando un metadato e' una nuova versione di uno precedente > (quindi con fileIdentfier e parentId con valori diversi), e quando invece e' > realmente un nuovo metadato (quindi con lo stesso valore)? E qui siamo su un secondo ordine di problemi, ancora piu' complesso. E quindi è il cuore del problema. Infatti se un ente sceglie di adottare la descrizione ISO basata sulla gerarchizzazione scheda-padre con schede-figlie , cosa perfettamente ammessa da GeoNetwork, ma anche prevista da ISO19115, visto che viene da loro normata nelle specifiche iso19115, e per le quali iso19115 pone nella sua specifica degli esempio molto chiari in cui adotta il campo "parentIdentifier" per legare la scheda filgia con la scheda padre. Mi riesce difficile impiegare tale campo per gestire la storicizzazione della scheda di tipo dataset stessa. E quindi vado in errore per RNDT. D'altronde l'idea di utilizzare tale campo per rappresentare una storicizzazione della scheda medesima a me pare decisamente una forzatura. Riporto di seguito cio' che dice la specifica ISO19115 a pagina 38: fileIdentifier: unique identifier for this metadata file parentIdentifier: file identifier of the metadata to which this metadata is a subset (child) Io non ci riesco a intravedere la possibile che in tale campo ci si possa mettere un codice che rappresenta una precedente versione di tale scheda. La specifica parla chiaramente di "subset" cioe' definisce la scheda figlia un subset di quella padre. Non è assoggettabile quindi al tipo di relazione che intercorre tra due versioni successive della medesima scheda. In tal caso non si puo' sostenere che la successiva versione di una medesima scheda è un suo "subset". Saluti, Andrea. Il 21 febbraio 2013 19:42, Piergiorgio Cipriano <[hidden email]> ha scritto: > Ciao Andrea, > concordo con te sulla utilita' della mailing list per condividere dubbi e > possibili soluzioni di interesse generale. > Forse, pero', con un colpo di telefono ad Antonio (Rotundo) avresti > risparmiato qualche riga di mail! > > Rispondo alla tua mail solo su due punti. > > 1) elementi ISO obbligatori > Sai meglio di me che gli elementi "obbligatori" previsti a livello di schemi > 19139 (dataset o serie) sono solo: > - il ruolo del contatto responsabile per i metadati > - la data (del metadato) > - il titolo > - la data (del dataset/serie) > - l'abstract > - la lingua > > Tutto il resto, per 19139, e' opzionale. > Ogni profilo del 19115/19139 puo' lecitamente rendere obbligatori altri > elementi, o anche porre vincoli a livello di contenuto (non verificabili > quindi solo con una semplice validazione xsd ma con schematron o altri tipi > di controlli). > > 2) gestione del "parentId" e GeoNetwork > Dal punto di vista tecnico, mi sembra un problema superabile a livello XSLT > ... o no? > Il problema per me e' un altro, e non e' tecnologico ma concettuale e > organizzativo: quando un metadato e' una nuova versione di uno precedente > (quindi con fileIdentfier e parentId con valori diversi), e quando invece e' > realmente un nuovo metadato (quindi con lo stesso valore)? > Su questo sarebbe utile un commento da parte di GeoSolutions o CSI, visto > che ci stanno lavorando su per Regione Piemonte. > O di qualcuno in Provincia di Trento (ha fatto / sta facendo una cosa > analoga [1]) o di qualcuno in Provincia di Bolzano, visto che sono stati tra > i primi a mettere in produzione GN [2] o di altri enti che stanno usando GN > e magari hanno fatto qualche personalizzazione. > > pg > > [1] > http://www.territorio.provincia.tn.it/portal/server.pt/community/sgc_-_geocatalogo/862/sgc_-_geocatalogo/32157 > [2] http://sdi.provincia.bz.it/geonetwork/srv/it/main.home > > > p.s. in riferimento al punto 1) > questo sotto e' un xml valido dal punto di vista xsd 19139, ovviamente non > per il profilo Inspire ne' per RNDT > > <?xml version="1.0" encoding="UTF-8"?> > <gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" > xmlns:gco="http://www.isotc211.org/2005/gco" > xmlns:gml="http://www.opengis.net/gml/3.2" > xmlns:xlink="http://www.w3.org/1999/xlink" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:geonet="http://www.fao.org/geonetwork" > xsi:schemaLocation="http://www.isotc211.org/2005/gmd > http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd"> > <gmd:contact> > <gmd:CI_ResponsibleParty> > <gmd:role> > <gmd:CI_RoleCode > codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode" > codeListValue="originator" /> > </gmd:role> > </gmd:CI_ResponsibleParty> > </gmd:contact> > <gmd:dateStamp> > <gco:DateTime>2011-11-18T09:59:22</gco:DateTime> > </gmd:dateStamp> > <gmd:identificationInfo> > <gmd:MD_DataIdentification> > <gmd:citation> > <gmd:CI_Citation> > <gmd:title> > <gco:CharacterString>bla bla bla</gco:CharacterString> > </gmd:title> > <gmd:date> > <gmd:CI_Date> > <gmd:date> > <gco:Date>2011-09-30</gco:Date> > </gmd:date> > <gmd:dateType> > <gmd:CI_DateTypeCode > codeList="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode" > codeListValue="revision" /> > </gmd:dateType> > </gmd:CI_Date> > </gmd:date> > </gmd:CI_Citation> > </gmd:citation> > <gmd:abstract> > <gco:CharacterString>bla bla bla</gco:CharacterString> > </gmd:abstract> > <gmd:language> > <gco:CharacterString>ita</gco:CharacterString> > </gmd:language> > </gmd:MD_DataIdentification> > </gmd:identificationInfo> > </gmd:MD_Metadata> > > > ______________________________ > Piergiorgio Cipriano > > > > Il giorno 21 febbraio 2013 10:20, Andrea Peri <[hidden email]> ha > scritto: >> >> Salve, >> >> grazie per l'intervento e le delucidazioni. >> >> Sono conscio che si puo' attivare un eventuale canale di colloquio >> punto a punto, >> ma poiche' ritengo che queste conoscenze siano di interesse generale. >> Credo che sia anche nel vostro interesse che la platea su come ci si >> interfaccia con RNDT sia abbastanza allargata da permettere a molti di >> imparare. >> Io per primo. >> >> Anche perche' da una parte ci sono discussioni in merito a Inspire e >> dal'altra su RNDT. In real'ta credo sia uitle a parecchi (parlo di chi >> produce dati e deve fornire schede di metadato) capire le >> problematiche che ci sono nel mondo dei metadati. Problematche non >> solo nei contenti (che gia' di per se bastano a riempire una vita) , >> ma anche nella strutturazione di campi e loro significati. >> >> Venendo ai punti della vostra risposta, >> Mi interessa in particolare esplorere meglio un dettaglio del discorso: >> >> Sono perfettamente conscio che ISO permette di evolvere lo schema. >> Questa cosa tra l'altro è stata molto ultilizzata da RNDT. >> Che infatti ha reso obbligatori molti elementi che su ISO erano >> facoltativi . >> Questo comportamento è perfettamente lecito e per giunta mi trova >> daccordo rendere obbligaotiro un campo nel momento in cui si ritiene >> che una determinata "informazione di contenuto" sia di importanza tale >> da dover essere sempre presente. >> >> Un piccolo dettaglio, ma marginale, riguarda il fatto che per >> ISO19115 una informazione facoltativa non è una informazione che non >> serve a niente, ma piuttosot una informazione che non sempre è >> disponibile. Mentre ,s empre per ISO una informazione obbligatoria è >> una informazione "sempre disponibile". >> Per cui quand si rende obbligaotoria una iformazione di contenuto >> occorre prima rispondersi alla domanda se tale informazione è sempre >> dispinibile. >> La risposta è affermativa se si parla di cmapi come il nominativo >> dell'ente da contattare, oppure dell'indirizzo di email di un >> detemrinato responsabile. >> Sono meno sicuro che sia affermativa quando leggo che tra gli >> obbligatori RNDT ha messo anche il campo >> "AbsoluteExternalPositionalAccuracy" come valore da esprimere in >> metri. >> Visto che l'espressione di tale valore comporta un rilievo in campo >> con strumenti dotati di una sufficiente precisione. >> >> Invece, mi trova un po' piu' perplesso quando tale possibilit'a viene >> applicata a campi che riguardano dei legami strutturali tra le schede. >> Ovvero non riguardano "informazioni di contenuto". >> Attenzione pero' che io non mi sto' riferendo ai contenuti del campo >> FileIdentifier. >> Come dicevo nel mio precedente intervento , poiche' ISO dichiarava >> tale campo di tipo testo uno puo' anche sceglierci di riportarci un >> identificartore che sia di una qualsivoglia natura. >> E quindi niente da eccepire sulla scelta fatta. Salvo un leggero >> retrogusto amaro basato sul fatto che adottare come prefisso un >> qualcosa che localizza chi spedisce il dato >> potrebbe alla lunga trarre in inganno, specie per le schede di >> metadato che non sono destinate a risiedere sempre e solo nel RNDT ma >> piuttosto a viaggiare assieme al dato stesso. >> >> Ma vorrei passare oltre anche questo aspetto e arrivare invece al >> punto saliente. >> >> Quindi, tornando alla punto centrale del discorso e in particolare >> all'aver reso sempre obbligatorio il campo "parentIdentifier". >> >> E' vero che ISO consente di rendere obbligatorio genericamente >> qualsiasi campo, ma occorre anche vedere se ha senso farlo e in tal >> caso occorre anche accollarsi l'onere di mantenere la definizione >> coerente. >> >> In questo caso con un parentIdentifier obbligatorio la coerenza a mio >> parere (ma saro' felice se mi spiegate che mi sbaglio) viene meno. >> >> Infatti se si dice che parentIdentifier contiene e il valore della >> scheda "parente" ovvvero di quella che nei sistemi a oggetti chiamano >> "antenato", >> esso è logicamente opzionale perche' una scheda puo' non avere un padre. >> >> L'averlo reso obbligatorio sempre fa si che esso deve cambiare >> significato a seconda della situazione al contorno della scheda. >> >> Ha un significato se la scheda è dota di un legame con un'altra scheda >> padre. Ed avrà di converso un altro significato se la scheda non ha un >> legame con una altra scheda (ovvero non ha una scheda padre) >> >> Quindi va a finire che tale campo contiene dei valori che possono >> seguire regole differenti a seconda dello stato in cui la scheda si >> trova. >> >> Se si considera che una scheda puo' nascere senza una scheda padre , >> perche' chi la compila sceglie di dettagliarla cosi', >> e poi successivamente essa potrebbe acquisire lo stato di scheda >> figlia nei confronti di una altra scheda (che sarebbe, di converso, >> padre) perche nel frattempo l'archivio si è evoluto in una determinata >> direzione. >> >> Si capisce che questo cambio di significato a seconda dello stato in >> cui si trova una scheda non è per niente facile da gestire. >> >> Per cui tornando a ISO. >> Verissimo che ISO permetteva di fare dei cambiamenti, anche rivolti a >> rendere obbligatori dei campi. >> Ma tale filosofia era primariamente rivolta a permettere di rendere >> obbligatori delle informazioni di contenuto. Ad esmepio a rendere >> obbligatorio ilnome del contatto , oppure a rendere obbligaotrio >> l'indirizzo di email e roba di questo genere. >> Altresi' ISO permetteva di aggiungere nuovi contenuti, ma anche qui la >> filosofia era di dare mergine per inserire delle informazioni di >> contenuto mancanti. >> Ad esempio , il passo di campionamento su un dato lidar oppure la >> paeltta dei colori su una immagine. >> >> E poi "last but not least". >> Che vantaggio porta questa scelta ? >> Mentre capisco che rendere obbligatoria una informazione di contenuto >> (la email del contatto ad esmepio) puo' servire. >> >> A che serve aver reso obbligatorio parentIdentifier ? >> >> Purtroppo io dal miopuntodi vista percepisco solo gli svantaggi. >> Ovvero il non poter usare un software gia esistente. >> >> ma anche il non potermi tenere aggiornato con tale software >> (geonetwork) via via che esso si evolve milgiorandosi e aggiungendo >> sempre nuove e piu' potenti features. >> >> >9)confermo che il CSI Piemonte sta lavorando ad un profilo RNDT per GN. >> > La >> >soluzione prodotta, una volta validata dall'Agenzia, sarà resa >> > disponibile >> >per il riuso; >> >> Non conosco i dettagli di questo lavoro. >> Ma visto che lo citate , forse potete rispondere a questa domanda: >> >> Si tratta di un fork di prodotto o di un plugin da poter applicare >> alla versione scaricabile dal sito di GN ? >> >> Se come immagino la risposta sia la prima. >> >> Come potrà essere gestito l'adeguamento di tale prodotto alle nuove >> versioni di GN ? >> >> Ad esempio: >> >> la versione 2.6 non è certificata per Inspire ed è molto lacunosa sui >> meccanismi di harvesting. >> tante' che ha dei bugs gia' riconosciuti che sono stati corretti nella >> successiva versione 2.8.0 >> La versione 2.8.0 uscira tra pochi giorni da oggi. Quando essa uscira >> la versione da voi crtificata probabilmente diverrà obsoleta ovvero >> non allineata all'ultima versione di GN. >> >> E questo succederà da ora in avanti finche' GN non adottasse al suo >> interno le varianti a ISO pensate da RNDT. >> >> Faccio questo raginonamento solo per esmeplificare una volta di piu' >> cosa comporta una eventale scelta di customizzare dei formati (iso in >> questo caso) con scelte che sebbene formalmente valide, finiscono per >> allontanare dai prodotti GFoss gia' esistenti e disponibili. >> >> Ad esempio: >> Infatti GN nella versione 2.6, oltre a dei "piccoli" bugs , ha anche >> un bug noto che (too files open bug) che la portava a schiantare >> quando è da troppo tempo attiva e funzionante. >> >> Questo piccolo bug è stato di recente risolto. >> Se una personalizzazione porta a un fork di prodotto, questo comporta >> che queste evoluzioni e correzioni, non sono facilmente accessibili a >> chi adotta la versione "forked". >> E di conseguenza deve cercare ( e probabilmente pagare) qualcuno che >> riporti tali evoluzioni dentro il proprio prodotto. >> >> Per questo è buona pratica non allontanarsi mai da uno standard, ma, >> muovendosi nei dettagi di uno standard, è importante anche compiere >> scelte che garantiscano una platea di prodotti allargata. >> >> Anche per evitare che poi parecchi enti si debbano dotare di versioni >> "forked" di altri prodotti, con tutto un onere di manutenzione non >> indifferente. >> >> Restando quindi su un piano strettamente tecnico, a vostro parere >> quale è la strada piu' efficiente: >> >> Sarebbe piu' efficiente ripensare il significato del campo >> "parentIdentifier" all'interno del sistema di RNDT >> oppure è piu' efficiente chiedere che tutti gli altri enti si dotino >> di softwares che seguano la logic del aprentIdentifier come la tratta >> ora RNDT ? >> >> >> Saluti, e grazie per il confronto tecnico estremamente utile e >> istruttivo per tutti. >> >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- >> _______________________________________________ >> [hidden email] >> 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 > > -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Il 21/02/2013 20:36, Andrea Peri ha scritto: > scusa ma con il tuo intervento in realta' mi convinci sempre di piu' > che è utile una discussione allargata > perche' come al soltio il tuo intervento entra sempre nel dettaglio > del metadato ed è percio' molto interessante. Concordo: la telefonata si sarebbe persa nei server di Telecom, questa interessante discussione rimarra' negli archivi della mailing list. Grazie mille. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEnFbsACgkQ/NedwLUzIr5WOQCePe8Q7Qo4haiR65AEjijkiOSg QRoAnioplQOThVBYh5LEXBnUBHN44FDL =T7gQ -----END PGP SIGNATURE----- _______________________________________________ [hidden email] 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 |
In reply to this post by Piergiorgio Cipriano
On Thu, Feb 21, 2013 at 07:42:50PM +0100, Piergiorgio Cipriano wrote:
> concordo con te sulla utilita' della mailing list per condividere dubbi e > possibili soluzioni di interesse generale. > Forse, pero', con un colpo di telefono ad Antonio (Rotundo) avresti > risparmiato qualche riga di mail! Ma avrebbe lasciato tutti noi altri all'oscuro ! Grazie Andrea per la mail dettagliata. --strk; _______________________________________________ [hidden email] 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 |
In reply to this post by Andrea Peri
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. _______________________________________________ [hidden email] 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 |
Davvero interessante.
Grazie
pg ______________________________ Piergiorgio Cipriano Il giorno 22 febbraio 2013 11:12, <[hidden email]> ha scritto: Giusto per aggiungere qualche ulteriore elemento di valutazione: _______________________________________________ [hidden email] 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 |
Free forum by Nabble | Edit this page |