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

Piergiorgio Cipriano pg.cipriano a gmail.com
Gio 21 Feb 2013 19:42:50 CET


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
-------------- parte successiva --------------
Un allegato HTML ? stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20130221/991f3073/attachment-0001.html>


Maggiori informazioni sulla lista Gfoss