Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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 àèìòù
-----------------
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

Piergiorgio Cipriano
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



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: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 <[hidden email]> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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


_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

a.furieri
On Thu, 21 Feb 2013 19:42:50 +0100, Piergiorgio Cipriano wrote:
> 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
>

confermo: ho appena verificato ...
il tuo sample passa la validazione di Schema XSD senza fare neppure la
piu' minuscola piegolina :-)

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

Andrea Peri
In reply to this post by Piergiorgio Cipriano
Ciao PG,
scusa ma con il tuo intervento in realta' mi convinci sempre di piu'
che è utile una discussione allargata
perche' come al soltio il tuo intervento entra sempre nel dettaglio
del metadato ed è percio' molto interessante.

Mi permetto percio' di rispondere alle tue osservazioni.

> 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).
>

Non mi pare di aver detto il contrario.
Sottoscrivo ogni singola stringa di cio' che è sopra scritto.

Porre vincoli di contenuto è perfettamente lecito.

Ma dire sul campo parentIdentifier ci si puo' scrivere il medesimo
valore che nella stessa scheda è trascritto nel campo parentIdentifier
è un po' di piu' che porre un vincolo di contenuto.
Quanto piuttosto porre una regola condizionale alla struttura.


> 2) gestione del "parentId" e GeoNetwork
> Dal punto di vista tecnico, mi sembra un problema superabile a livello XSLT
> ... o no?

Tutto è superabile nell'informatica.

Forse l'xslt da solo non basta e occorre anche una procedura
informatica a sostegno perche' una semplice procedura sequenziale sul
flusso xml della scheda di metadato puo' non bastare per riassegnare
tutti i giusti valori.
La scheda di metadato ha i tags ordinati sequenzialmente e potrebbe
darsi che un tag debba essere valirizzato prima che si conoscano i
valori necessari per determinare il valore da imporre al tag.

Feci qualche prova un paio di anni fa' su geonetwork, ma allora mi
concentrai essenzialmente sulla produzione di una scheda appiattita e
non considerai la problematica del parentIdentifier.
Se ci si limita al problema del parentIdentifier sicuramente con una
procedura xslt si puo' ovviare.
Infatti il campo parentIdentifier è successivo al campo fileIdentifier
e quindi quando si arriva nella procedura xslt a valorizzare tale
campo il valore da metterci è gia' stato recepito.

> 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)?

E qui siamo su un secondo ordine di problemi, ancora piu' complesso.
E quindi è il cuore del problema.

Infatti se un ente sceglie di adottare la descrizione ISO basata sulla
gerarchizzazione scheda-padre con schede-figlie ,
cosa perfettamente ammessa da GeoNetwork, ma anche prevista da
ISO19115, visto che viene da loro normata nelle specifiche iso19115, e
per le quali iso19115 pone nella sua specifica degli esempio molto
chiari in cui adotta il campo "parentIdentifier" per legare la scheda
filgia con la scheda padre.

Mi riesce difficile impiegare tale campo per gestire la
storicizzazione della scheda di tipo dataset stessa.
E quindi vado in errore per RNDT.

D'altronde l'idea di utilizzare tale campo per rappresentare una
storicizzazione della scheda medesima a me pare decisamente una
forzatura.

Riporto di seguito cio' che dice la specifica ISO19115 a pagina 38:

fileIdentifier:
unique identifier for this metadata file

parentIdentifier:
file identifier of the metadata to which this metadata is a subset (child)

Io non ci riesco a intravedere la possibile che in tale campo ci si
possa mettere un codice che rappresenta una precedente versione di
tale scheda.
La specifica parla chiaramente di "subset" cioe' definisce la scheda
figlia un subset di quella padre.
Non è assoggettabile quindi al tipo di relazione che intercorre tra
due versioni successive della medesima scheda. In tal caso non si puo'
sostenere che la successiva versione di una medesima scheda è un suo
"subset".

Saluti,

Andrea.


Il 21 febbraio 2013 19:42, Piergiorgio Cipriano
<[hidden email]> ha scritto:

> 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 <[hidden email]> 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 àèìòù
>> -----------------
>> _______________________________________________
>> [hidden email]
>> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

pcav
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 21/02/2013 20:36, Andrea Peri ha scritto:

> scusa ma con il tuo intervento in realta' mi convinci sempre di piu'
> che è utile una discussione allargata
> perche' come al soltio il tuo intervento entra sempre nel dettaglio
> del metadato ed è percio' molto interessante.

Concordo: la telefonata si sarebbe persa nei server di Telecom, questa interessante
discussione rimarra' negli archivi della mailing list.
Grazie mille.

- --
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEnFbsACgkQ/NedwLUzIr5WOQCePe8Q7Qo4haiR65AEjijkiOSg
QRoAnioplQOThVBYh5LEXBnUBHN44FDL
=T7gQ
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

Sandro Santilli
In reply to this post by Piergiorgio Cipriano
On Thu, Feb 21, 2013 at 07:42:50PM +0100, Piergiorgio Cipriano wrote:

> 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!

Ma avrebbe lasciato tutti noi altri all'oscuro !
Grazie Andrea per la mail dettagliata.

--strk;
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

a.furieri
In reply to this post by Andrea Peri
Giusto per aggiungere qualche ulteriore elemento di valutazione:
OGC sta discutendo proprio in questi giorni il nuovo standard
GeoPackage, che tra le altre cose si preoccupa anche di standardizzare
come vanno registrati i Matadati ISO all'interno di un DBMS (SQLite)
[1].
Ancora di tratta solo di un "candidate standard" [1], ma e' sicuramente
interessante prendere in considerazione l'implementazione proposta.

[1] https://portal.opengeospatial.org/files/?artifact_id=51391

tutto ruota attorno a due sole tavole DBMS:

CREATE TABLE xml_metadata (
  id INTEGER CONSTRAINT xm_pk PRIMARY KEY ASC
     ON CONFLICT ROLLBACK AUTOINCREMENT NOT NULL UNIQUE,
  md_scope TEXT NOT NULL DEFAULT 'dataset',
  metadata_standard_URI TEXT NOT NULL
    DEFAULT 'http://schemas.opengis.net/iso/19139/',
  metadata BLOB NOT NULL DEFAULT (zeroblob(4))
)

CREATE TABLE metadata_reference (
   reference_scope TEXT NOT NULL DEFAULT "table",
   table_name TEXT NOT NULL DEFAULT "undefined",
   column_name TEXT NOT NULL DEFAULT "undefined",
   row_id_value INTEGER NOT NULL DEFAULT 0,
   timestamp TEXT NOT NULL DEFAULT
     (strftime('%Y-%m-%dT%H:%M:%fZ',CURRENT_TIMESTAMP)),
   md_file_id INTEGER NOT NULL DEFAULT 0,
   md_parent_id INTEGER NOT NULL DEFAULT 0,
   CONSTRAINT crmr_mfi_fk FOREIGN KEY (md_file_id)
     REFERENCES xml_metadata(id),
   CONSTRAINT crmr_mpi_fk FOREIGN KEY (md_parent_id)
     REFERENCES xml_metadata(id)
)

e' interessante notare come sia "md_file_id" che "md_parent_id"
assurgono addirittura al rango di Foreign Key (quindi hanno un
ruolo strutturale decisamente forte).

"md_scope" puo' essere uno qualsiasi tra:
undefined,fieldSession,collectionSession,series,dataset,
featureType,feature,attributeType,attribute,tile,model,
catalogue,schema,taxonomy,software,service,collectionHardware,
nonGeographicDataset,dimensionGroup

"reference_scope" puo' essere uno qualsiasi tra:
table,column,row,row/col

"table_name", "column_name" e "row_id_value" consentono di
stabilire i riferimenti relazionali con gli oggetti contenuti
nel DBMS, che possono essere indifferentemente di tipo Vector
ma anche Raster (aka tiles).

la struttura relazione proposta e' estremamente flessibile,
e puo' coprire efficacemente tutti i possibile casi d'uso.

- piu' tavole possono fare riferimento ad un medesimo Metadato
- un Metadato puo' essere associato ad un'intera tavola; ma
   e' anche possibile definire un Metadato per una singola
   colonna/attributo
- una singola riga/entita' puo' avere associato un suo Metadato
   specifico (ovviamente, vale anche per gruppi di righe selezionate).
- infine, addirittura un singolo valore-attributo riga/colonna puo'
   avere un proprio specifico Metadato.

---------------------------------------------
venendo alla vexatissima queastio:

"md_file_id"
value for the metadata to which this metadata_reference applies

"md_parent_id"
value for the hierarchical parent metadata for the metadata to
which this metadata_reference applies

Every GeoPackage metadata_reference table that contains any rows
shall contain at least one row record with an md_parent_id value
of 0 that references the ‘undefined’ xml_metadata row record as
defined by the SQL in table 51. Such record(s) establish the
metadata reference to the “root” of a metadata hierarchy.

---------------------------------------------
chi fosse eventualmente intressato ad approfondire, nell'Annex C
della specifica GeoPackage e' presente una serie di esempi molto
chiari e decisamente illuminanti sui corretti criteri da adottare
per rappresentare la struttura gerarchica dei Metadati.

concludendo: almeno secondo l'interpretazione OGC-GeoPackage non
esiste alcun dubbio possibile.

A) i metadati formano una catena gerarchica parent-child; tutte
    le catene devono obbligatioramente iniziare con un elemento
    "root" che si riconosce perche' punta ad un parent con ID=0
B) assolutamente nulla lascia trapelare l'eventualita' che
    "parent" possa essere utilizzato per gestire il versioning;
    viceversa e' di cristallina chiarezza che deve servire
    esclusivamente per rappresentare le catene gerarchiche
    parent-child
C) secondo questa interpretazione, dichiare il medesimo valore
    per "md_file_id" e "md_parent_id" causa una sorta di loop
    infinito durante la fase di ricostruzione della catena :-D
    il valore convenzionale atteso per verificare di essere
    effettivamente giunti alla root (nodo iniziale) di una
    catena e' sempre e solo ZERO

ciao Sandro


--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: Corretta Interpretazione di un paio di campi della scheda metadati ISO19115

Piergiorgio Cipriano
Davvero interessante.
Grazie

pg
 
______________________________
Piergiorgio Cipriano
 


Il giorno 22 febbraio 2013 11:12, <[hidden email]> ha scritto:
Giusto per aggiungere qualche ulteriore elemento di valutazione:
OGC sta discutendo proprio in questi giorni il nuovo standard
GeoPackage, che tra le altre cose si preoccupa anche di standardizzare
come vanno registrati i Matadati ISO all'interno di un DBMS (SQLite) [1].
Ancora di tratta solo di un "candidate standard" [1], ma e' sicuramente
interessante prendere in considerazione l'implementazione proposta.

[1] https://portal.opengeospatial.org/files/?artifact_id=51391

tutto ruota attorno a due sole tavole DBMS:

CREATE TABLE xml_metadata (
 id INTEGER CONSTRAINT xm_pk PRIMARY KEY ASC
    ON CONFLICT ROLLBACK AUTOINCREMENT NOT NULL UNIQUE,
 md_scope TEXT NOT NULL DEFAULT 'dataset',
 metadata_standard_URI TEXT NOT NULL
   DEFAULT 'http://schemas.opengis.net/iso/19139/',
 metadata BLOB NOT NULL DEFAULT (zeroblob(4))
)

CREATE TABLE metadata_reference (
  reference_scope TEXT NOT NULL DEFAULT "table",
  table_name TEXT NOT NULL DEFAULT "undefined",
  column_name TEXT NOT NULL DEFAULT "undefined",
  row_id_value INTEGER NOT NULL DEFAULT 0,
  timestamp TEXT NOT NULL DEFAULT
    (strftime('%Y-%m-%dT%H:%M:%fZ',CURRENT_TIMESTAMP)),
  md_file_id INTEGER NOT NULL DEFAULT 0,
  md_parent_id INTEGER NOT NULL DEFAULT 0,
  CONSTRAINT crmr_mfi_fk FOREIGN KEY (md_file_id)
    REFERENCES xml_metadata(id),
  CONSTRAINT crmr_mpi_fk FOREIGN KEY (md_parent_id)
    REFERENCES xml_metadata(id)
)

e' interessante notare come sia "md_file_id" che "md_parent_id"
assurgono addirittura al rango di Foreign Key (quindi hanno un
ruolo strutturale decisamente forte).

"md_scope" puo' essere uno qualsiasi tra:
undefined,fieldSession,collectionSession,series,dataset,
featureType,feature,attributeType,attribute,tile,model,
catalogue,schema,taxonomy,software,service,collectionHardware,
nonGeographicDataset,dimensionGroup

"reference_scope" puo' essere uno qualsiasi tra:
table,column,row,row/col

"table_name", "column_name" e "row_id_value" consentono di
stabilire i riferimenti relazionali con gli oggetti contenuti
nel DBMS, che possono essere indifferentemente di tipo Vector
ma anche Raster (aka tiles).

la struttura relazione proposta e' estremamente flessibile,
e puo' coprire efficacemente tutti i possibile casi d'uso.

- piu' tavole possono fare riferimento ad un medesimo Metadato
- un Metadato puo' essere associato ad un'intera tavola; ma
  e' anche possibile definire un Metadato per una singola
  colonna/attributo
- una singola riga/entita' puo' avere associato un suo Metadato
  specifico (ovviamente, vale anche per gruppi di righe selezionate).
- infine, addirittura un singolo valore-attributo riga/colonna puo'
  avere un proprio specifico Metadato.

---------------------------------------------
venendo alla vexatissima queastio:

"md_file_id"
value for the metadata to which this metadata_reference applies

"md_parent_id"
value for the hierarchical parent metadata for the metadata to
which this metadata_reference applies

Every GeoPackage metadata_reference table that contains any rows
shall contain at least one row record with an md_parent_id value
of 0 that references the ‘undefined’ xml_metadata row record as
defined by the SQL in table 51. Such record(s) establish the
metadata reference to the “root” of a metadata hierarchy.

---------------------------------------------
chi fosse eventualmente intressato ad approfondire, nell'Annex C
della specifica GeoPackage e' presente una serie di esempi molto
chiari e decisamente illuminanti sui corretti criteri da adottare
per rappresentare la struttura gerarchica dei Metadati.

concludendo: almeno secondo l'interpretazione OGC-GeoPackage non
esiste alcun dubbio possibile.

A) i metadati formano una catena gerarchica parent-child; tutte
   le catene devono obbligatioramente iniziare con un elemento
   "root" che si riconosce perche' punta ad un parent con ID=0
B) assolutamente nulla lascia trapelare l'eventualita' che
   "parent" possa essere utilizzato per gestire il versioning;
   viceversa e' di cristallina chiarezza che deve servire
   esclusivamente per rappresentare le catene gerarchiche
   parent-child
C) secondo questa interpretazione, dichiare il medesimo valore
   per "md_file_id" e "md_parent_id" causa una sorta di loop
   infinito durante la fase di ricostruzione della catena :-D
   il valore convenzionale atteso per verificare di essere
   effettivamente giunti alla root (nodo iniziale) di una
   catena e' sempre e solo ZERO


ciao Sandro


--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

_______________________________________________
[hidden email]
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


_______________________________________________
[hidden email]
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