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

[Andrea Peri]

Ciao Piergiorgio.

Confesso che è veramente un piacere poter discutere con te di metadati.

Il punto su cui io esprimo il mio dispiacere riguarda i
fraintendimenti interpretativi che sembrano essere nati fin dagli
albori su determinati campi e che ora ci portiamo dietro come un
peccato originale anche per le generazioni a venire e a imperitura
memoria. :)

Ho appena scaricato la versione 1.2 del documento di inspire e il
trafiletto che ti riporto è estratto dall'esempio di pagina
67 del documento:

INSPIRE Metadata Implementing
Rules: Technical Guidelines based
on EN ISO 19115 and EN ISO 19119
del 16-Giugno-2010

Al paragrafo A.12.1.2 ISO/TS 19139 XML File:

Ecco il trafiletto che li' ci si trova:

xmlns:gml="http://www.opengis.net/gml">
<gmd:fileIdentifier>
<gco:CharacterString>029097fd-2ef2-487c-a5ca-6ec7a3dbac53</gco:CharacterString>
</gmd:fileIdentifier>
<gmd:language>
<gmd:LanguageCode codeList=" http://www.loc.gov/standards/iso639-2/"
codeListValue="eng">eng</gmd:LanguageCode>
</gmd:language>


Come puoi notare è stato inserito il FileIdentifier che come
giustamente te dici è opzionale,
ma nell'opzionalità a quanto pare Inspire sceglie di usarlo negli esempi.

Ma ancora piu' importante , Inspire non mette il parentIdentifier.
Noterai infatti che nell'esempio di Inpsire non è presente il
ParentIdentifier, ma questo è corretto perche' , dice il documento
Inspire, che si tratta di una scheda di livello Dataset senza padre e
per questo  non viene inserito e valorizzato il campo
parentIdentifier.

Cosa che invece la specifica di RNDT prescrive di mettere.

Il seguente frammento infatti è un trafiletto di un esempio estratto
da pagina 54 del documento 1.2 delle LineeGuida di RNDT.

<gmd:fileIdentifier>
<gco:CharacterString>r_molise:000002:20111219:172006</gco:CharacterString>
</gmd:fileIdentifier>
<gmd:language>
<gmd:LanguageCode codeList="http://www.loc.gov/standards/iso639-2"
codeListValue="ita">ita</gmd:LanguageCode>
</gmd:language>
<gmd:characterSet>
<gmd:MD_CharacterSetCode
codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/gmxCodelists.xml#MD_CharacterSetCod
e" codeListValue="utf8">utf8</gmd:MD_CharacterSetCode>
</gmd:characterSet>
<gmd:parentIdentifier>
<gco:CharacterString>r_molise:000002:20111219:172006</gco:CharacterString>
</gmd:parentIdentifier>

Noterai che anche qui è stato scelto di inserire FileIdentifier, ma a
differenza dell'esempio di Inspire, qui è stato inserito anche il
parentIdentifier ed è stato codificato con il medesimo valore del
FileIdentifier.

Uno potrebbe pensare che questo avviene perche' è una scheda di
livello dataset e quindi una figlia. Per cui è dotata di
parentIdentifer che punti alla sua scheda padre. Ma intanto si puo'
notare che FileIdentifier e parentIdentifier hanno identico valore e
poi al paragrafo successivo il documento di RNDT sgombra il campo da
ogni dubbio:

Riporto il trafiletto di cio' che dice:

>Fermo restando quanto indicato al § 1.4, le linee guida INSPIRE denotano che non ci sono
>differenze significative tra i metadati del dataset e i metadati della serie. Pertanto, per la serie si può
>fare riferimento all’esempio per il dataset riportato al paragrafo precedente.
>Nel caso della serie, non esistendo nessun livello gerarchico superiore, i due metadati
>“Identificatore” e “Id livello superiore” assumeranno sempre lo stesso valore.

Notare la sottigliezza dle discorso:
Anche inspire dice che tra l'esempio della seire edel dataset non ci
sono differenze.
Ma inpsire nell'esmepio del dataset non metteva il valore
ParentIdentifier, mentre RNDT SI !
Per cui quando RNDT dice che non ci sono differenze tra la scheda di
tipo serie e la scheda di tipo dataset implicitamente dice che
anche nella serie va messo il valore "parentIdentifer".

Ganzo eh ? :)

RNDT usa tutti i costrutti di Inpsire e di ISO (e quindi è conforme si
dice) pero' li usa in maniera difforme per cui non è compatibile a
livello di relazione tra le schede.

Mettiamo da parte la scelta di usare nel fileIdentifier un codice non UUID.
Questa scelta ci puo' anche stare visto che ISO stessa non dice che
cosa usare, ma dice slo che deve essere univoco.
L'univocita' si ottiene in tanti modi , anche nel modo prescritto da
RNDT (sigh).

Ma il problema strutturalmente rilevante è la scelta di aver messo il
parentIdentifier nelle schede di livello serie codificandolo con il
medesimo valore del proprio fileIdentifier.

E' questo fatto che non trova riscontro negli esempi di Inspire e
nemmeno nelle specifiche di Inspire ne' tanto meno in quelli di
ISO19115.

Te giustamente dici che tali due valori sono facoltativi.
Ma il fatto che siano facoltativi non implica che si puo' scegliere di
usarli in maniera differente da come le specifiche dicono che
dovrebbero essere usati.

Quindi per rispondere alle tue asserzioni:

> 2) Inspire non prevede nè fileIdentifier nè parentId, e non prevede
> relazioni tra metadati di serie e metadati di dataset

Come detto sopra Inspire li usa e liusa anche RNDT ma i due sistemi
assegnano a questi campi signigificati leggermente differenti, tanto
da rendere le due schede non del tutto compatibili a livello di legame
strutturale tra le varie schede.

Questa tua asserzione, probabilmente è frutto di un malinteso sui significati.
Infatti Inspire parla di contenuti dell'informazione geografica non si
preoccupa della struttura che demanda a ISO. Per cui parla dei campi
che dettagliano i contenuti precisandoli e espandendoli nei
significati, ma non vuol dire che i campi di cui non parla non vanno
usati, anzi.
E questi due (fileIdentifier e parentIdentifier li usa eccome)

Infatti nel documento delle specifiche di Inspire, a pagina 50 dice:

>This template only shows the
>properties in the scope of the INSPIRE metadata elements, which encompass the mandatory
>properties of ISO 19115 and ISO 19119. The other optional properties of ISO 19115 are not
>described, but can be present in a real instance.

Quindi chiarisce che ci possono essere proprieta' del documento
ISO19115 che non sono citate nel documento, ma che possono (se
servono) essere presenti in una reale e completa scheda di metadati.

E infatti se si guarda gli esempi che lo stesso documento Inspire
riporta (vedi il trafiletto che ho riportato in precedenza) si vede
che FileIdentifer è in effetti impiegato.

Negli esempi che Inspire mette nei suoi documenti ci si trova
FileIdentifier, quindi pare ovvio che prevede di farne uso.

Si puo' anche spiegare facilmente perche' ISO abbiammesso tali due
campi facoltativi anziche' obbligatori.
Infatti è ragionevole ritenere che la facoltatività derivi dalla ovvia
considerazione che il campo FileIdentifier serve in effetti solamente
per identificare una singola scheda in un gruppo di schede in
relazione padre-figlio tra di loro.

Nel momento in cui si prevede di creare delle schede di tipo "dataset"
(cioe' schede che descrivono un dataset) senza che ci debba essere
alcuna relazione gerarchica di tipo padre-figli tra varie schede , non
serve usarlo.
Se pero' ci sono relazioni di questo tipo, servono entrambi eccome.

E attenzione anche al dettaglio che
Inspire non dice che non si debbono creare schede in relazione
padre-figlio, prova ne è che cita l'esistenza di tali relazioni
gerarchiche in un suo paragrafo.

Concordo con te in pieno quando dici:

>Possiamo discutere quanto vogliamo sul corretto significato dei 4 elementi
> definiti da RNDT, ma non andremmo da alcuna parte.
>

Infatti so benissimo che ormai i giochi sono fatti e si deve convivere
con le scelte che in un momento del passato sono state fatte.

Quello che pero' mi rende abbastanza amaro tutta questa storia è  la
consapevolezza
che mentre il resto del mondo potrà usufruire di un GeoNetwork che
permette di scrivere schede di metadato intelleggibili tra i due
emisferi.
In Italia ci dovremo attrezzare con delle specifiche nostre versioni
di softwares per scriverci schede che capiamo solo noi.

Immagino che RNDT avra' i suoi meccanismi per trasformare le schede
dalsuo formato RNDT al formato Inspire/ISO.
In fondo gli basterà rimuovere il campo parentIdentifier sulle schede
di tipo serie e cambiare qualche codifica qua' e la'.

Piu' problematico per chi deve conferire le schede a RNDT perche'
dovraì procurarsi uno specifico software oppure svilupparsi un proprio
trasduttore da ISO19115/19139 verso RNDT.

Termino con una simpatica digressione sulla tua asserzione seguente:

> 6) due elementi per gestire il versionamento del metadato (Nota: non esiste
> in 19115 un "versionId" o similare) e ...
>
> 7) due elementi per gestire la gerarchia serie-dataset
>

In ISO19115 non trovi un versionID perche' non ha senso nella logica
del metadato ISO19115.

ISO prevede di poter descrivere l'evoluzione di un dataset attraverso
l'inserimento di una nuova scheda di metadato che assumerebbe il ruolo
di scheda di tipo feature-istance o attribute-istance permettendo di
legarla a quella di partenza (o storica come diresti te) tramite il
parentID.

Per questo non ha il concetto di scheda vecchia superata dalla scheda
nuova e legata con un versionID.

La struttura che prevede ISO è  molto sofisticata che per giunta
GeoNetwork nella versione 2.8.0 (che doveva uscire ieri ed è stata
rimandata di qualche giorno per correggere un baco critico) gestisce e
pure bene.

> Un suggerimento: perché non organizzare un bel webinar tecnico, con DigitPA
> (o come si chiama ora ... Agenzia per l'Italia Digitale) e discuterne in
> modo costruttivo a voce?

Sarebbe interesante, ma non penso che servirebbe un gran che'

In effetti ritornando all'origine della mia domanda, a me interessava
sapere se qualcuno aveva gia' provato a usare un GeoNetwork per
generare una scheda compatibile con RNDT anche perche' mi interessvaa
sapere e capire come avevano superato i problemi che io ho riportato e
che non sono gli unici.

Per il resto concordo con te.

Ormai la specifica RNDT è una norma e bisogna attenersi ad essa.
Per cui discutere di come si doveva interpretare un campo ISO è ormai inutile.

L'unica cosa che mi rode un po' è che nella norma che istituiva RNDT
non ci stava scritto che parentIdentifier era da usarsi come in
effetti RNDT lo ha poi usato.
Questa cosa è stata inserita in primis nel codice delle versioni
prototipali e poi successivamente normata nelle specifiche delle linee
guida uscite qualche anno dopo.

Per cui in realt'a la commissione che lavoro' sul nucleo base non
disse niente diquesto genere , forse è stata una errata
interpretazione data dalla ditta che ha sviluppato il sistema RNDT per
conto del Cnipa ?

Chissa', fatto sta che dopo qualche anno nelle linee guida RNDT ha
inserito un paragrafo esplicito in cui dettalgi abenissimo questo
aspetto e rende esplicita quindi una interpretazizone che fino a quel
momento era nota solo a chi provava il software.


Per cui direi che è perfettamente inutile parlarne.
Evidentemente quando vi era ancora il mdo di risolvere perche' la
norma non chiariva in effetti come andava usato il campo
parentiIdentifier,
anziche' correggere si è preferito fissare la situazione attuale una
volta per tutte. Chiarendo che cosi' è, cosi' resta e si deve
accettare come tale.

Non resta che prendere atto di questa intenzione.

E quindi per chi deve accollarsi l'onere di gestire questa storia non
resta che rimboccarsi le mani e destinare una rilevante parte del
proprio tempo di lavoro ( e risorse) per cercare di risolvere dei
problemi che con un attimo di accortezza in piu' in sede di stesura
delle specifiche (anni fa) ci si sarebbe potuto risparmiare oggi.

Saluti,

Andrea.

Il 16 febbraio 2013 19:13, Piergiorgio Cipriano
<pg.cipriano a gmail.com> ha scritto:
> Ciao Andrea, di seguito le mie considerazioni:
>
>>Come indicato nella premessa, il Regolamento (CE) relativo ai metadati
>> contempla,
>> per quanto riguarda i dati territoriali, solo i livelli di serie e
>> dataset.
> [...]
>> 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.
>
> Non è così:
>
> 1) il Regolamento (CE) che citi nella tua ultima mail è quello Inspire,
>
> 2) Inspire non prevede nè fileIdentifier nè parentId, e non prevede
> relazioni tra metadati di serie e metadati di dataset
>
> 3) nel 19115 quei due elementi sono opzionali e servono a identificare il
> metadato (non la risorsa descritta)
>
> 4) il 19115 oltre a essere uno standard "astratto" lascia ampio margine a
> interpretazioni su molti elementi (pensa alla codelist dei "ruoli")
>
> 5) ciò detto, l'interpretazione data in Italia (dal gruppo di lavoro del
> defunto "Comitato Regole Tecniche ...") ha portato a quel che abbiamo ora, e
> cioè ...
>
> 6) due elementi per gestire il versionamento del metadato (Nota: non esiste
> in 19115 un "versionId" o similare) e ...
>
> 7) due elementi per gestire la gerarchia serie-dataset
>
>
> Possiamo discutere quanto vogliamo sul corretto significato dei 4 elementi
> definiti da RNDT, ma non andremmo da alcuna parte.
>
> I quattro elementi, come scrivi tu, devono contenere un prefisso (es.
> r_campan) corrispondente al codice IPA, seguito non per forza da ennuple
> numeriche: Regione Lombardia, per esempio, utilizza dopo il codice IPA un
> UUID; Regione Sardegna, Regione Emilia-Romagna e Provincia di Trento,
> invece, un codice alfanumerico in alcuni casi "parlante".
>
> Per quanto so io, GeoNetwork viene usato in Provincia di Bolzano, Provincia
> di Trento, Provincia di Avellino, e da qualche tempo Regione Piemonte.
> Sarebbe opportuno verificare come hanno risolto in quei casi la gestione dei
> 4 elementi.
> Idem per l'accuratezza posizionale.
>
> Una precisazione finale:
> a) un metadato RNDT con encoding 19139 è valido sia per RNDT che per Inspire
>
> b) RNDT con encoding 19139, infatti, è un'estensione di quanto previsto da
> Inspire, che a sua volta è un'estensione del core 19115
>
>
> Un suggerimento: perché non organizzare un bel webinar tecnico, con DigitPA
> (o come si chiama ora ... Agenzia per l'Italia Digitale) e discuterne in
> modo costruttivo a voce?
>
> pg
>
>
> p.s. ... ma che fine ha fatto Metabeta?  :)
>
>
> ______________________________
> Piergiorgio Cipriano
>
>
>
> Il giorno 15 febbraio 2013 20:14, Andrea Peri <aperi2007 a gmail.com> ha
> scritto:
>>
>> >Non so cosa intendesse chi ha scritto lo il 19115 quasi 15 anni fa (visto
>> >che iniziarono a fine '98).
>> >Sta di fatto che per l'Italia si applicano le specifiche RNDT.
>> >Che sono conformi a quanto chiesto in INSPIRE.
>> >
>> >pg
>>
>> Ciao PG,
>>
>> su questo punto non ci piove assolutamente.
>> Che in Italia si debba applicare le specifiche RNDT per conferire i dati a
>> RNDT.
>>
>> Sottolineo per conferire i dati a RNDT.
>>
>> NOn avevo notato pero' questo particolare che te sembri sottolineare,
>> che la normativa vigente dice che è fatto obbligo in italia di
>> riferirsi assolutamente alle specifiche RNDT quando si copila una
>> scheda di metainformazione.
>> Io pensavo che fosse richiesto che il conferimento a RNDT fosseo
>> conforme a RNDT.
>> Se ad esempio un ente espone su internet il proprio catalogo, non
>> penserei che esso debba essere necessariamente coforme a RNDT.
>> Basta che quando egli conferisce le schede a RNDT le confeisca con il
>> formato richiesto
>>
>> Sbaglio ?
>>
>> Se questa è la situazione, il discorso diventa come di genera questa
>> scheda conforme a RNDT.
>>
>> Anche io avevo sempre letto da qualche parte (non ricordo dove) che
>> RNDT era conforme a Inspire e quindi quando ho visto che Geonetwork
>> era anche lui conforme a Insspire, salti di gioia.
>> http://trac.osgeo.org/geonetwork/wiki/InspireReadyGeoNetwork
>>
>> Poi pero' la sorpresa.
>>
>> Infatti io, come penso altri, contavo su GN per gestire i metadati da
>> poter conferire a RNDT.
>>
>> Pero' le prime prove hanno fatto emergere alcuni problemi, ovvero
>> quelli che ho gia' elencato.
>> Come ad esempio il fatto che GN non valorizza il parentID sulla serie
>> ne' tanto meno lo valorizza con il medesimo valore del FileIdentifier
>> della medesima scheda (se stessa).
>>
>> Dalla lettura delle specifiche come dicevo io riterrei sia piu' logica
>> l'interpretazione che ne da' GN.
>> Anche perche' in ultima analisi cio' che comanda è la specifica ISO19115.
>>
>> Ma detto questo , mi piaceva avere ritorni di altri che si erano
>> confrontati con questa problematica,
>> anche perche' ritengo che la scheda di metadata non sia solo un
>> documento formale e burocratico, ma bensi' una parte integrale e
>> importante di un archivio geografico.
>>
>> Ovviamente la situazione perfetta sarebbe se qualcuno che ha gia'
>> avuto modo di provare possa testimoniare che una scheda di GeoNetwork
>> , (preso come tale senza alcuna modifca al suo cidce sorgente tanto
>> per intendersi) , intendo una scheda complessa, dotata di una parte
>> "serie" e svariate parti "figlie" di tipo dataset.
>> Entra senza alcun problema su RNDT.
>>
>> Al che mi posso tranquillizzare e pensare a cio' che realmente conta,
>> ovvero ai contenuti della scheda di metainformazione.
>>
>> Colgo l'occasione di questo contatto .
>> Per avere uno spunto anche su un punto che riguarda l'informazione da
>> inserire nelle schede di RNDT.
>>
>> In RNDT è stato reso obbligaroio un campo che in ISO19115 ( e in
>> Inspire) era facoltativo.
>> Si tratta della qualità dell'archivio espressa in metri e denominata
>> "absolute-external-position-accuracy".
>>
>> In determinati tipologie di archivi non è dato sapere questo valore.
>> Tante' che ISO19115, molto saggiamente , aveva previsto in alternativa
>> (sottolineo alternativa) a tale tipo di indicazione di qualita',
>> un altro tipo di indicazione di precisione che viene chiamata
>> "Lineage" o "Genealogia".
>> In cui si esprime la qualit'a dell'archivio descrivendono il processo
>> produttivo o di acquisizione.
>>
>> In determinate tipologie di archivi, come ad esempio la geologia o gli
>> archivi di pianificazione, non è per niente facile e scontato che si
>> possa conoscere la qualita' dell'archivio espressa da un numero in
>> metri. Mentre invece è sempre possibile esprimerne il processo
>> produttivo.
>>
>> Per cui mentre una scheda di metadato ISO19115 e Inpire compliant è
>> compilabile.
>> Una scheda RNDT compliant proprio per la difficolta' di sapere e
>> GARANTIRE tale valore non è facilmente compilabile.
>> Almeno su determiate tipologie di archivi.
>>
>> Per la tua esperienza, è sempre possibile (piu' o meno difficilmente)
>> esprimere tale valore ?
>> Oppure ci si rifa' a valori standard o a stime di massima o che altro ?
>>
>> Mi rendo conto che sono domande affatto banali specie queste sui
>> contenuti della scheda.
>>
>> Anche per questo mi piacerebbe diradarmi i dubbi almeno sulla parte
>> infrastrutturale visto che gia' riempe abbastanza la giornata i
>> problemi sui contenuti della scheda.
>>
>> Grazie,
>>
>>
>> >
>> --
>> -----------------
>> 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 àèìòù
-----------------