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
