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@gmail.com <mailto:aperi2007@gmail.com>> ha scritto:
Ciao Diego grazie del contributo.
Il 14 febbraio 2013 15:41, Diego Guidi <diegoguidi@gmail.com
<mailto:diegoguidi@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@lists.gfoss.it <mailto: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