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 <aperi2...@gmail.com> 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 àèìòù > ----------------- > _______________________________________________ > 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
_______________________________________________ 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