[Gfoss] Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

Andrea Peri aperi2007 a gmail.com
Gio 21 Feb 2013 20:36:16 CET


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
<pg.cipriano a gmail.com> 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 <aperi2007 a 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 a 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
>
>



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


Maggiori informazioni sulla lista Gfoss