Ciao Andrea,<div>concordo con te sulla utilita' della mailing list <span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">per condividere dubbi e possibili soluzioni di interesse generale.</span> </div>
<div>Forse, pero', con un colpo di telefono ad Antonio (Rotundo) avresti risparmiato qualche riga di mail!</div><div><br></div><div><div>Rispondo alla tua mail solo su due punti.</div><div><br></div><div><b>1) elementi ISO obbligatori</b></div>
<div>Sai meglio di me che gli elementi "obbligatori" previsti a livello di schemi 19139 (dataset o serie) sono solo:</div>
<div>- il ruolo del contatto responsabile per i metadati</div><div>- la data (del metadato)</div><div>- il titolo</div><div>- la data (del dataset/serie)</div><div>- l'abstract</div><div>- la lingua</div><div><br></div>
<div>Tutto il resto, per 19139, e' opzionale.</div><div>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).</div>
<div><br></div><div><b>
2) gestione del "parentId" e GeoNetwork</b></div><div>Dal punto di vista tecnico, mi sembra un problema superabile a livello XSLT ... o no?</div><div>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)?</div>
<div>Su questo sarebbe utile un commento da parte di GeoSolutions o CSI, visto che ci stanno lavorando su per Regione Piemonte. </div><div>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.</div>
<div><br></div><div>pg</div><div><br></div><div>[1] <a href="http://www.territorio.provincia.tn.it/portal/server.pt/community/sgc_-_geocatalogo/862/sgc_-_geocatalogo/32157">http://www.territorio.provincia.tn.it/portal/server.pt/community/sgc_-_geocatalogo/862/sgc_-_geocatalogo/32157</a></div>
<div>[2] <a href="http://sdi.provincia.bz.it/geonetwork/srv/it/main.home">http://sdi.provincia.bz.it/geonetwork/srv/it/main.home</a></div><div><br></div><div><br></div><div>p.s. in riferimento al punto 1)</div><div>questo sotto e' un xml valido dal punto di vista xsd 19139, ovviamente non per il profilo Inspire ne' per RNDT</div>
<div><br></div><div><div><?xml version="1.0" encoding="UTF-8"?></div><div><gmd:MD_Metadata xmlns:gmd="<a href="http://www.isotc211.org/2005/gmd">http://www.isotc211.org/2005/gmd</a>" xmlns:gco="<a href="http://www.isotc211.org/2005/gco">http://www.isotc211.org/2005/gco</a>" xmlns:gml="<a href="http://www.opengis.net/gml/3.2">http://www.opengis.net/gml/3.2</a>" xmlns:xlink="<a href="http://www.w3.org/1999/xlink">http://www.w3.org/1999/xlink</a>" xmlns:xsi="<a href="http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001/XMLSchema-instance</a>" xmlns:geonet="<a href="http://www.fao.org/geonetwork">http://www.fao.org/geonetwork</a>" xsi:schemaLocation="<a href="http://www.isotc211.org/2005/gmd">http://www.isotc211.org/2005/gmd</a> <a href="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd">http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/gmd/gmd.xsd</a>"></div>
<div> <gmd:contact></div><div> <gmd:CI_ResponsibleParty></div><div> <gmd:role></div><div> <gmd:CI_RoleCode codeList="<a href="http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode">http://www.isotc211.org/2005/resources/codeList.xml#CI_RoleCode</a>" codeListValue="originator" /></div>
<div> </gmd:role></div><div> </gmd:CI_ResponsibleParty></div><div> </gmd:contact></div><div> <gmd:dateStamp></div><div> <gco:DateTime>2011-11-18T09:59:22</gco:DateTime></div>
<div> </gmd:dateStamp></div><div> <gmd:identificationInfo></div><div> <gmd:MD_DataIdentification></div><div> <gmd:citation></div><div> <gmd:CI_Citation></div><div> <gmd:title></div>
<div> <gco:CharacterString>bla bla bla</gco:CharacterString></div><div> </gmd:title></div><div> <gmd:date></div><div> <gmd:CI_Date></div><div> <gmd:date></div>
<div> <gco:Date>2011-09-30</gco:Date></div><div> </gmd:date></div><div> <gmd:dateType></div><div> <gmd:CI_DateTypeCode codeList="<a href="http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode">http://www.isotc211.org/2005/resources/codeList.xml#CI_DateTypeCode</a>" codeListValue="revision" /></div>
<div> </gmd:dateType></div><div> </gmd:CI_Date></div><div> </gmd:date></div><div> </gmd:CI_Citation></div><div> </gmd:citation></div><div> <gmd:abstract></div>
<div> <gco:CharacterString>bla bla bla</gco:CharacterString></div><div> </gmd:abstract></div><div> <gmd:language></div><div> <gco:CharacterString>ita</gco:CharacterString></div>
<div> </gmd:language></div><div> </gmd:MD_DataIdentification></div><div> </gmd:identificationInfo></div><div></gmd:MD_Metadata></div></div><div><br clear="all"><div><div> </div><div>______________________________</div>
<div>Piergiorgio Cipriano</div><div> </div></div>
<br><br><div class="gmail_quote">Il giorno 21 febbraio 2013 10:20, Andrea Peri <span dir="ltr"><<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Salve,<br>
<br>
grazie per l'intervento e le delucidazioni.<br>
<br>
Sono conscio che si puo' attivare un eventuale canale di colloquio<br>
punto a punto,<br>
ma poiche' ritengo che queste conoscenze siano di interesse generale.<br>
Credo che sia anche nel vostro interesse che la platea su come ci si<br>
interfaccia con RNDT sia abbastanza allargata da permettere a molti di<br>
imparare.<br>
Io per primo.<br>
<br>
Anche perche' da una parte ci sono discussioni in merito a Inspire e<br>
dal'altra su RNDT. In real'ta credo sia uitle a parecchi (parlo di chi<br>
produce dati e deve fornire schede di metadato) capire le<br>
problematiche che ci sono nel mondo dei metadati. Problematche non<br>
solo nei contenti (che gia' di per se bastano a riempire una vita) ,<br>
ma anche nella strutturazione di campi e loro significati.<br>
<br>
Venendo ai punti della vostra risposta,<br>
Mi interessa in particolare esplorere meglio un dettaglio del discorso:<br>
<br>
Sono perfettamente conscio che ISO permette di evolvere lo schema.<br>
Questa cosa tra l'altro è stata molto ultilizzata da RNDT.<br>
Che infatti ha reso obbligatori molti elementi che su ISO erano facoltativi .<br>
Questo comportamento è perfettamente lecito e per giunta mi trova<br>
daccordo rendere obbligaotiro un campo nel momento in cui si ritiene<br>
che una determinata "informazione di contenuto" sia di importanza tale<br>
da dover essere sempre presente.<br>
<br>
Un piccolo dettaglio, ma marginale, riguarda il fatto che per<br>
ISO19115 una informazione facoltativa non è una informazione che non<br>
serve a niente, ma piuttosot una informazione che non sempre è<br>
disponibile. Mentre ,s empre per ISO una informazione obbligatoria è<br>
una informazione "sempre disponibile".<br>
Per cui quand si rende obbligaotoria una iformazione di contenuto<br>
occorre prima rispondersi alla domanda se tale informazione è sempre<br>
dispinibile.<br>
La risposta è affermativa se si parla di cmapi come il nominativo<br>
dell'ente da contattare, oppure dell'indirizzo di email di un<br>
detemrinato responsabile.<br>
Sono meno sicuro che sia affermativa quando leggo che tra gli<br>
obbligatori RNDT ha messo anche il campo<br>
"AbsoluteExternalPositionalAccuracy" come valore da esprimere in<br>
metri.<br>
Visto che l'espressione di tale valore comporta un rilievo in campo<br>
con strumenti dotati di una sufficiente precisione.<br>
<br>
Invece, mi trova un po' piu' perplesso quando tale possibilit'a viene<br>
applicata a campi che riguardano dei legami strutturali tra le schede.<br>
Ovvero non riguardano "informazioni di contenuto".<br>
Attenzione pero' che io non mi sto' riferendo ai contenuti del campo<br>
FileIdentifier.<br>
Come dicevo nel mio precedente intervento , poiche' ISO dichiarava<br>
tale campo di tipo testo uno puo' anche sceglierci di riportarci un<br>
identificartore che sia di una qualsivoglia natura.<br>
E quindi niente da eccepire sulla scelta fatta. Salvo un leggero<br>
retrogusto amaro basato sul fatto che adottare come prefisso un<br>
qualcosa che localizza chi spedisce il dato<br>
potrebbe alla lunga trarre in inganno, specie per le schede di<br>
metadato che non sono destinate a risiedere sempre e solo nel RNDT ma<br>
piuttosto a viaggiare assieme al dato stesso.<br>
<br>
Ma vorrei passare oltre anche questo aspetto e arrivare invece al<br>
punto saliente.<br>
<br>
Quindi, tornando alla punto centrale del discorso e in particolare<br>
all'aver reso sempre obbligatorio il campo "parentIdentifier".<br>
<br>
E' vero che ISO consente di rendere obbligatorio genericamente<br>
qualsiasi campo, ma occorre anche vedere se ha senso farlo e in tal<br>
caso occorre anche accollarsi l'onere di mantenere la definizione<br>
coerente.<br>
<br>
In questo caso con un parentIdentifier obbligatorio la coerenza a mio<br>
parere (ma saro' felice se mi spiegate che mi sbaglio) viene meno.<br>
<br>
Infatti se si dice che parentIdentifier contiene e il valore della<br>
scheda "parente" ovvvero di quella che nei sistemi a oggetti chiamano<br>
"antenato",<br>
esso è logicamente opzionale perche' una scheda puo' non avere un padre.<br>
<br>
L'averlo reso obbligatorio sempre fa si che esso deve cambiare<br>
significato a seconda della situazione al contorno della scheda.<br>
<br>
Ha un significato se la scheda è dota di un legame con un'altra scheda<br>
padre. Ed avrà di converso un altro significato se la scheda non ha un<br>
legame con una altra scheda (ovvero non ha una scheda padre)<br>
<br>
Quindi va a finire che tale campo contiene dei valori che possono<br>
seguire regole differenti a seconda dello stato in cui la scheda si<br>
trova.<br>
<br>
Se si considera che una scheda puo' nascere senza una scheda padre ,<br>
perche' chi la compila sceglie di dettagliarla cosi',<br>
e poi successivamente essa potrebbe acquisire lo stato di scheda<br>
figlia nei confronti di una altra scheda (che sarebbe, di converso,<br>
padre) perche nel frattempo l'archivio si è evoluto in una determinata<br>
direzione.<br>
<br>
Si capisce che questo cambio di significato a seconda dello stato in<br>
cui si trova una scheda non è per niente facile da gestire.<br>
<br>
Per cui tornando a ISO.<br>
Verissimo che ISO permetteva di fare dei cambiamenti, anche rivolti a<br>
rendere obbligatori dei campi.<br>
Ma tale filosofia era primariamente rivolta a permettere di rendere<br>
obbligatori delle informazioni di contenuto. Ad esmepio a rendere<br>
obbligatorio ilnome del contatto , oppure a rendere obbligaotrio<br>
l'indirizzo di email e roba di questo genere.<br>
Altresi' ISO permetteva di aggiungere nuovi contenuti, ma anche qui la<br>
filosofia era di dare mergine per inserire delle informazioni di<br>
contenuto mancanti.<br>
Ad esempio , il passo di campionamento su un dato lidar oppure la<br>
paeltta dei colori su una immagine.<br>
<br>
E poi "last but not least".<br>
Che vantaggio porta questa scelta ?<br>
Mentre capisco che rendere obbligatoria una informazione di contenuto<br>
(la email del contatto ad esmepio) puo' servire.<br>
<br>
A che serve aver reso obbligatorio parentIdentifier ?<br>
<br>
Purtroppo io dal miopuntodi vista percepisco solo gli svantaggi.<br>
Ovvero il non poter usare un software gia esistente.<br>
<br>
ma anche il non potermi tenere aggiornato con tale software<br>
(geonetwork) via via che esso si evolve milgiorandosi e aggiungendo<br>
sempre nuove e piu' potenti features.<br>
<br>
>9)confermo che il CSI Piemonte sta lavorando ad un profilo RNDT per GN. La<br>
>soluzione prodotta, una volta validata dall'Agenzia, sarà resa disponibile<br>
>per il riuso;<br>
<br>
Non conosco i dettagli di questo lavoro.<br>
Ma visto che lo citate , forse potete rispondere a questa domanda:<br>
<br>
Si tratta di un fork di prodotto o di un plugin da poter applicare<br>
alla versione scaricabile dal sito di GN ?<br>
<br>
Se come immagino la risposta sia la prima.<br>
<br>
Come potrà essere gestito l'adeguamento di tale prodotto alle nuove<br>
versioni di GN ?<br>
<br>
Ad esempio:<br>
<br>
la versione 2.6 non è certificata per Inspire ed è molto lacunosa sui<br>
meccanismi di harvesting.<br>
tante' che ha dei bugs gia' riconosciuti che sono stati corretti nella<br>
successiva versione 2.8.0<br>
La versione 2.8.0 uscira tra pochi giorni da oggi. Quando essa uscira<br>
la versione da voi crtificata probabilmente diverrà obsoleta ovvero<br>
non allineata all'ultima versione di GN.<br>
<br>
E questo succederà da ora in avanti finche' GN non adottasse al suo<br>
interno le varianti a ISO pensate da RNDT.<br>
<br>
Faccio questo raginonamento solo per esmeplificare una volta di piu'<br>
cosa comporta una eventale scelta di customizzare dei formati (iso in<br>
questo caso) con scelte che sebbene formalmente valide, finiscono per<br>
allontanare dai prodotti GFoss gia' esistenti e disponibili.<br>
<br>
Ad esempio:<br>
Infatti GN nella versione 2.6, oltre a dei "piccoli" bugs , ha anche<br>
un bug noto che (too files open bug) che la portava a schiantare<br>
quando è da troppo tempo attiva e funzionante.<br>
<br>
Questo piccolo bug è stato di recente risolto.<br>
Se una personalizzazione porta a un fork di prodotto, questo comporta<br>
che queste evoluzioni e correzioni, non sono facilmente accessibili a<br>
chi adotta la versione "forked".<br>
E di conseguenza deve cercare ( e probabilmente pagare) qualcuno che<br>
riporti tali evoluzioni dentro il proprio prodotto.<br>
<br>
Per questo è buona pratica non allontanarsi mai da uno standard, ma,<br>
muovendosi nei dettagi di uno standard, è importante anche compiere<br>
scelte che garantiscano una platea di prodotti allargata.<br>
<br>
Anche per evitare che poi parecchi enti si debbano dotare di versioni<br>
"forked" di altri prodotti, con tutto un onere di manutenzione non<br>
indifferente.<br>
<br>
Restando quindi su un piano strettamente tecnico, a vostro parere<br>
quale è la strada piu' efficiente:<br>
<br>
Sarebbe piu' efficiente ripensare il significato del campo<br>
"parentIdentifier" all'interno del sistema di RNDT<br>
oppure è piu' efficiente chiedere che tutti gli altri enti si dotino<br>
di softwares che seguano la logic del aprentIdentifier come la tratta<br>
ora RNDT ?<br>
<br>
<br>
Saluti, e grazie per il confronto tecnico estremamente utile e<br>
istruttivo per tutti.<br>
<br>
-----------------<br>
Andrea Peri<br>
. . . . . . . . .<br>
qwerty àèìòù<br>
-----------------<br>
_______________________________________________<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/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</blockquote></div><br></div>
</div>