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

[Andrea Peri]

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 àèìòù
-----------------