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

aperi2007 aperi2007 a gmail.com
Ven 15 Feb 2013 17:31:42 CET


Ciao Piergiorgio..
grazie per le indicazioni,

provo a spiegare meglio i miei dubbi.

A pagina 11 che citi te.
Ci sta' un trafiletto abbastanza esteso.

In cui il tratto saliente è abbastanza interessante.

 >Come indicato nella premessa, il Regolamento (CE) relativo ai metadati 
contempla, per quanto
 >riguarda i dati territoriali, solo i livelli di serie e dataset.
 >Dal Regolamento e dalle già citate Linee Guida Tecniche si evince che 
non esiste nessuna relazione
 >tra i due livelli tale da consentire di creare una gerarchizzazione 
dell’informazione contenuta nei
 >metadati, come previsto dal diagramma UML riportato nella figura 3 del 
paragrafo 6.2 dello
 >Standard ISO 19115 e come indicato, a livello informativo, negli 
allegati G e H del medesimo
 >Standard.

In soldoni ammetterebbe che nelle specifiche nazionali non è prevista 
alcuna relazione tra un dataset e la sua serie.
Al contrario di quanto previsto da ISO19115.

E fin qui ci siamo e tutto è chiaro.

Poi viene detto:

 >Per le trasmissioni, i metadati in questione sono “Identificatore del 
file” (fileIdentifier) e “Id file
 >precedente” (parentIdentifier); le istruzioni di compilazione di tali 
metadati sono riportate ai
 >successivi paragrafi 2.1.1.1 e 2.1.1.4.
 >In riferimento a ciò, nel caso di una prima trasmissione i due 
identificatori assumeranno lo stesso
 >valore; nel caso, invece, di un aggiornamento, l’identificatore “Id 
file precedente” del file XML
 >corrente dovrà assumere il valore dell’elemento “Identificatore del 
file” presente nel file XML della
 >trasmissione temporalmente precedente a cui è relazionato.

Il passaggio che a me crea dei dubbi amletici è quello dove si dice che
nel caso di una prima trasmissione i due identificatori

fileIdentifier e parentIdentifier devono assumere il medesimo valore.

Questa cosa mi pare che non sia in linea con le specifiche ISO19115.
O meglio, non mi sembra in linea con cio' che fa' GeoNetwork, che pero' 
nell'ultimissima versione che stanno rilasciando ora mi pare che abbiano 
supportato completamente iso19115/1939 e anche inspire.

Secondo ISO questi due campi non servirebbero per identificare la prima 
trasmissione da una successiva, ma bensi ' per legare la scheda figlia 
(dataset) con la scheda padre (serie). In particolare il secondo campo 
(parentIdentifier).

Su questa base io posso anche immaginare che vi si un legame di flusso , 
ovvero spedisco prima la serie (e quindi faccio la prima trasmissione), 
poi spedisco la figlia (e faccio quindi la seconda trasmissione) la 
figlia avra' il campo parentIdentifier valorizzato con il codice 
FileIdentifier del padre , e quindi tutto parrebbe funzionare.

Il problema è che la scheda serie che io mi genero da GeoNetwork non ha 
il campo parentIdentifier valorizzato con il suo medesimo codice di 
fileIdentifier, ma bensi' esso è assente.

Quindi il mio dubbio è sulla scheda serie.
Cioe' sula scheda che nella logica operativa di RNDT dovrebbe comporre 
la cosidetta "prima trasmissione".

Per avere una scheda che piaccia a RNDT io dovrei aprire la scheda serie 
che mi rilascia geoNetwork e aggiungervi un campo parentIdentifier con 
dentro il codice del fileIdentifier.

A margine di questo, poi ho altri dubbi in merito a come questi due 
campi sono valorizzati.

Infatti GeoNetwork quando mi genera una scheda mi valorizza il campo 
FileIdentifier con un valore UUID.

E anche questo è in linea con le specifiche ISO19115 e mi pare anche con 
Inspire.

Invece RNDT richiede che la scheda abbia su tale campo FileIdentifier un 
codice composito composto da un prefisso (che deriva dai codici spcoop) 
e una coppia di ennuple numeriche.
stile questo:

r_campan:000002:20090220:111239

Questo fa si' che un GeoNetwork come lo conosciamo noi, non genera un 
tale tipo di codice, perche' usa invece l' UUID.

La cosa non è cosi' peregrina come puo' sembrare all'inizio, perche' se 
io su geonetwork mi scrivo un scheda serie e poi 5 o 6 schede dataset 
figlie della serie, tutte queste sono tra loro legate da questi codici 
di tipo UUID inseriti nei due campi
FileIdentifier e parentIdentifier.

Se RNDT mi chiede di sostituire a questi codici una altra forma di 
codice seguendo la logica che mi chiede RNDT, io devo rimaneggiare tutte 
queste schede.
Senza contare che poi se un domani devo modificare qualcosa io mi 
devorigenerare le schede da geoNetwork e poi rimaneggiare nuovamente 
questi codici.

Le mie perplessit'a nascono proprio da queste questioni (ce ne sarebbe 
qualche altra, anche sulle definizioni dei sistemi di riferimento, ma 
questo sono quelle che mi preoccupano maggiormente).

Mi piacerebbe sapere se qualche altro soggetto è riuscito a far 
dialogare delle schede di metadato generate da geoNetwork con il RNDT o 
se si sono dovuti sempre ingegnare facendo modificare il codice di 
GeoNetwork facendosi dei forks del prodotto oppure se hanno fatto 
ricorso ad altri prodotti gia' impostati per capire il dialetto di RNDT.

Andrea.

On 15/02/2013 12:29, Piergiorgio Cipriano wrote:
> Ciao Andrea,
> credo stiate facendo confusione tra id del "metadato" e id della 
> "risorsa" descritta.
> Chiedo ad Antonio (Rotundo) di confermare o correggere.
>
> A pag. 11 del documento RNDT c'è scritto:
> /Per le trasmissioni, i metadati in questione sono “Identificatore del 
> file” (fileIdentifier) e “Id file precedente” (parentIdentifier); le 
> istruzioni di compilazione di tali metadati sono riportate ai 
> successivi paragrafi 2.1.1.1 e 2.1.1.4./
>
> Il "parentId" corrisponde all'identificativo del file XML precedente, 
> cioè la versione "storica" del metadato in oggetto. In pratica:
>
> <gmd:fileIdentifier>
>  <gco:CharacterString>r_campan:000002:20090220:111239</gco:CharacterString>
> </gmd:fileIdentifier>
> [...]
> <gmd:parentIdentifier>
>    <gco:CharacterString>r_campan:000001:20090124:093213 
> <tel:093213></gco:CharacterString>
> </gmd:parentIdentifier>
>
> In questo caso, la versione attuale del metadato è quella che termina 
> con *:111239*, mentre la versione precedente del metadato è quella che 
> termina con *:093213 <tel:093213>*.
>
> Diverso il concetto di identificatore di "dataset" e "serie"; a pag. 
> 12 c'è scritto:
> /Per la gestione delle relazioni tra livelli gerarchici, sono previsti 
> i metadati “Identificatore” //(identifier) e “Id livello superiore” 
> (series); le relative istruzioni di compilazione sono riportate ai 
> //successivi paragrafi 2.1.2.5 e 2.1.2.6. /
>
> Il primo corrisponde allo "Unique resource identifier" (previsto da 
> INSPIRE).
>
> In pratica, con gli esempi riportati nel documento RNDT:
>     <gmd:identifier>
> <gmd: RS_Identifier>
>            <gmd:code>
> <gco:CharacterString>r_piemon:00000001</gco:CharacterString>
>            </gmd:code>
>    </gmd:RS_Identifier>
>     </gmd:identifier>
>
> [...]
>      <gmd:series>
> <gmd:CI_Series>
>          <gmd:issueIdentification>
>     <gco:CharacterString> r_piemon:00000001</gco:CharacterString>
>          </gmd:issueIdentification>
>    </gmd:CI_Series>
>      </gmd:series>
> In questo esempio non c'è gerarchia visto che il valore 
> dell'identificativo è lo stesso, quindi il metadato potrebbe una 
> risorsa di livello "dataset" non collegata ad alcuna serie, oppure di 
> una di livello "serie".
>
> NOTA1: INSPIRE non richiede il fileIdentifier come obbligatorio (vedi 
> Implementing Rules [1], e Tech.Guidance [2]) ma viene comunque 
> valorizzato con l'editor web [3] del geoportale.
>
> NOTA2: nel 19115 (e 19139) il tag fileIdentifier è opzionale, idem il 
> parentId
>
> [1] 
> http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:EN:PDF 
> - pag. 18
> [2] 
> http://inspire.jrc.ec.europa.eu/documents/Metadata/INSPIRE_MD_IR_and_ISO_v1_2_20100616.pdf 
> - pag. 47
> [3] http://inspire-geoportal.ec.europa.eu/editor/
>
>
> pg
>
> ______________________________
> Piergiorgio Cipriano
>
>
> Il giorno 14 febbraio 2013 16:09, Andrea Peri <aperi2007 a gmail.com 
> <mailto:aperi2007 a gmail.com>> ha scritto:
>
>     Ciao Diego grazie del contributo.
>
>
>     Il 14 febbraio 2013 15:41, Diego Guidi <diegoguidi a gmail.com
>     <mailto:diegoguidi a gmail.com>> ha scritto:
>     >> Le ultime due righe in particolare sembrano indicare che i due
>     campi
>     >> parentIdentifier e FileIdentifier quando la scheda non ha un padre
>     >> (ad esempio una scheda di livello serie non ha padre) devono
>     assumere
>     >> il medesimo valore.
>     > A naso sembra una pazzia bella e buona.
>
>     mi annoto la tua opinione . :)
>
>     >
>     >> A questo riguardo facendo delle prove con GeoNetwork
>     >> ho notato invece che lui, quando una scheda non ha padre lascia
>     il campo
>     >> "parentIdenfier" non valorizzato (ovvero non ce lo mette proprio)
>     >> nell'XML di output.
>     > Non avento padre, la logica questo impone, e mi sembra di ricordare
>     > pure ISO dica questo.
>     >
>
>     anche a me parrebbe logico cosi'.
>
>     >> a meno di non fare un fork di GeoNetwork e rimaneggiarlo
>     pesantemente
>     >> (ammesso che si voglia e debba fare)
>     > https://github.com/geosolutions-it/geonetwork
>     > dovrebbe essere il progetto nato dalla collaborazione tra CSI
>     Piemonte
>     > e Geosolutions.
>     > Per ora c'è poco più di un paio di template RNDT e modifiche al
>     layout.
>     > Mi sembra di capire che l'obiettivo sia quello di arrivare alla
>     > validazione RNDT.
>
>     Il problema è come ci si arriva.
>
>     Modificando pesantemente il codice di GN in maniera che ragioni come
>     il profilo RNDT.
>     Oppure svilupando dei moduli che si possono aggiungere a GN (il 2.8.0
>     esce oggi stesso San Valentino)
>     in maniera da poterli applicare anche alle successive
>     patch-version di GN.
>
>     In ogni caso il mio problema sul momento è capire se l'interpretazione
>     di RNDT è iso compliant oppure no.
>
>     Mi pare di capire che te concordi con la mia interpretazione che
>     quando una scheda non ha padrea non si deve mettere "parentIdentifier
>     = fileidentifier" ma bensi si deve omettere del tutto.
>
>     Grazie,
>
>     --
>     -----------------
>     Andrea Peri
>     . . . . . . . . .
>     qwerty àèìòù
>     -----------------
>     _______________________________________________
>     Gfoss a lists.gfoss.it <mailto: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
>
>

-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130215/97ed4dab/attachment.html>


Maggiori informazioni sulla lista Gfoss