Quando viene chiesto un campo della classificazione come ci si deve comportare? Un rilievo potrebbe avere 4 classificazioni diverse.
Spero abbiate pazienza con la spiegazione sotto.

Quale classificazione deve essere mostrata? Io sto prendendo la prima marcata "actual" che dovrebbe essere soltanto una, ma se dovesse succedere che il rilievo è 'lectotype' per un nome che ora è sinonimo e 'holotype' per un altro?

Altro esempio: prendiamo il nome "buono" e il typus "più importante".
Se cuccede che la classificazione attuale non è typus ma una vecchia si, si potrebbe rischiare di avere il nome attuale con il typus vecchio associati al rilievo.

Dunque la situazione teorica secondo me è questa. 
Si dovrebbe poter interrogare il campo classificazione cercando anche una qualsiasi parte di ciò che c'è scritto, indipendentemente se sia segnata la classificazione come [attuale] o no. Es. con una query "Lemnion minoris" dovrei poter trovare tutti i rilievi che contengono in classificazione "Lemnion minoris" come ad es.

"AS:Lemno-Spirodeletum polyrhizae Koch 1954 AL:Lemnion minoris Tüxen ex O. Bolòs et Masclans 1955 OR:Lemnetalia minoris Tüxen ex O. Bolòs et Masclans 1955 CL:Lemnetea Tüxen ex O. Bolòs et Masclans 1955"        

ma anche

"AS:Ricciocarpetum natantis (Segal 1963) Tüxen 1972 AL:Lemnion minoris de Bolòs et Masclans 1955 OR:Lemnetalia minoris de Bolòs et Masclans 1955 CL:Lemnetea de Bolòs et Masclans 1955"

Quando invece si esportano i rilievi secondo me si potrebbe avere una doppia necessità:

1) Esportare tutto ciò che è nel campo classificazione separato in due colonne distinte [classificazione attuale] e [sinonimo]

2) Avere tutti campi in colonne separate separate per AS: SA: AG: AL: SL: OR: SO: .... In questo caso io mi accontenterei di avere solo la classificazione attuale. Poi le altre informazioni sono comunque consultabili nel database.

Per quanto riguarda il caso che tu segnali non lo vedo così problematico, anche perché se si sta facendo uno studio su un certo gruppo si dovrebbe sempre verificare se tra i rilievi c'è un typus e non ci si potrebbe comunque fidare solo del database, l'informazione potrebbe non essere neanche archiviata... se è stata archiviata comunque non va persa è consultabile, semplicemente non trovo prioritario esportarla. 

Ti metto un paio di allegati di esempio...

Created attachment 28 [details]
Es. esportazione classificazione

Nel mio esempio ho accorpato tutte le due possibilità nella stessa tabella...
 Forse però non sarebbe un'idea malvagia se si potesse creare un'esportazione così almeno nessuna informazione andrebbe persa... ovviamente i campi separati sarebbero solo dell'attuale ma si potrebbe anche avere un'informazione sulla vecchia classificazione... 

E' possibile che io abbia idealizzato troppo la cosa e che non sia possibile materialmente fare quello che ti ho detto, questo devi dirmelo tu.

Per me l'ideale sarebbe avere i campi separati, però ripeto che se questo non è possibile almeno avere due caselle una per classificazione attuale e altre per le eventuali vecchie classificazioni...

concordo sull'opportunita' di poter esportare SIA "nome attuale" SIA "sinonimo"

finche' il campo "classificazione" non e' suddiviso in sottocampi forse e' sufficiente che il dato esportato contenga tutta la sequenza senza scorporarla, come propone flavia nel caso 1
inoltre non dimentichiamo che i sinonimi potrebbero essere piu' di uno, questo aumenterebbe in modo esponenziale le eventuali colonne se si decidesse di scorporare i diversi syntaxa!

nel peggiore dei casi, se scorporare in colonne distinte le sequenze sintassonomiche "attuale" e "sinonimo" fosse troppo complicato, andrebbe gia' bene esportare in blocco tutto il contenuto del campo "classificazione" (tanto ci sono i segnalini "AS:", "SA:" ecc.).

anche utile poter esportare l'attributo "typus" [questa informazione e' attualmente separata dal nome? senno', potrebbe essere utile inserirla sempre anche se non richiesta, come parte integrante del nome]
resta il fatto che le varie informazioni sulla tipizzazione non possono essere responsabilita' della banca dati, percio' ogni user dovra' fare le sue verifiche in letteratura.

NOTA IMPORTANTE: se possibile, le tre voci "holotipo", "lectotipo", "neotipo" dovrebbero essere modificate in "holotypus", "lectotypus" e "neotypus" - scusa ma prima nessuno aveva considerato che questa e' la dicitura corretta secondo il codice.
ciao

Concordo con Daniela, ma ripeto che se si potesse avere anche un'esportazione dei singoli campi AS:, AL:, OR:, ecc... almeno della classificazione attuale sarebbe molto utile. Questa cosa mi è stata oggetto di discussione anche l'altro giorno, quando mi sono incontrata con gli altri. I quali hanno ribadito che in TURBOVEG questi campi sono separati e tutti loro hanno ammesso di beneficiare enormemente di questa separazione durante l'elaborazione dei dati, in quanto permette confronti diretti e immediati tra classificazione da letteratura e   riclassificazione dopo l'elaborazione, soprattutto per chi usa JUICE, il quale permette di ordinare i dati in base anche a classificazioni preesistenti, ma in caso di testi così lunghi (classificazione in un'unica casella) non è possibile un riordino automatico. Insomma i dati sono sicuramente meglio gestibili, soprattutto quando si lavora con molti dati.

Se questo non si può fare ora pazienza però sarà uno dei primi problemi che prima o poi riemergerà, in quanto mi pare di aver capito che non è solo mia, ma opinione comune, la necessità di avere campi separati, almeno di quanto sta in classificazione attuale. Poi le classificazioni storiche possono anche essere esportate in un unico campo e consultate in caso di necessità.

Concordo con holotypus, lectotypus, neotypus...

Mi permetto un paio di note di tipo pratico:
-se possibile cerchiamo di sistemare l'esportazione, la ricerca conviene trattarla a parte (gestibile diversamente).
-quello che fa Turboveg (che tralaltro avendo campi arbotrari potrebbe averli sia tutti insieme che separati) di deve condizionare un po senza distoglierci da valutare quel che facciamo.

Io ho l'esportazione per campi separati funzionante. Il problema è che l'esportaizone viene fatta in blocco.

Se c'è bisogno di tabelle in cui tutte le righe abbiano lo stesso numero di colonne ma un rilievo ha 4 sinoimi e uno soltanto due cosa si fa?

Mi pare di aver capito che serve questo via skype:

Nome attuale sia in unica colonna che esploso, sinonimi tutti insieme in una colonna.

Si io trovo questa soluzione un buon compromesso...

Il nome attuale viene esportato. Da testare

In caso non compaia in alto a destra l'icona per 'elenco dei rilievi bisogna dare "reload" alla pagina per forzare il browser a scaricare una libreria aggiornata.

Esporta anche i sinonimi, eventualmente (se più di uno) fusi in unico campo.

Da provare anche questo... e non sarà facile visto che nel DB non esiste un rilievo con due sinonimi ;-)

posso avere conferma che va tutto bene adesso? (o meno)

Ok al momento va tutto bene per me puoi chiudere il bug...

Scusa non avevo letto tutto il testo originale. Per quanto riguarda l'esportazione della classificazione tutto ok... invece mi sono ripromessa di controllare l'esportazione di tutti i campi con la spunta, tipo rilievo tipo, ecc... Credo infatti che questi campi non vengano esportati correttamente ma devo verificare... domani cerco di darti una risposta più precisa.

Ho rivisto tutti i commenti sopra.
I questo bug concentriamoci sull'esportazione.

da lunedì sarà possibile esportare:
- "la" classificazione (vedi sotto)
- "la" classificazione esplosa
- tutti i sinonimi in unica colonna
- tutti gli altri campi

In caso venga richiesta "la" classificazione viene utilizzata la prima marcata "actual" se non esiste si prende l'ultima dell'elenco.
In caso venga chiesto il typus viene ritornato quello relativo alla classificazione di cui sopra.

Ho rivisto anche il commento 8: questa resta una soluzoione di compromesso? in caso quale sarebbe quella ideale?

no so se sono off-topic
ho esportato una tabella, usando per la prima volta *Sample table (descriptions)* con la possibilita' di esportare molti campi, funziona ;-)
pero' l'esportazione della tabella di dati *Sample table*, indicando come opzione *The table INCLUDE headers*, produce una tabella in cui gli unici headers sono riportati nelle prime 3 righe e sono solo la data, ripetuta per 3 volte. e' normale?

ehm
vi chiedo cortesemente di ignorare il precedente messaggio :-S

ricevuto... credo che il problema sia quello del bug 255

la "quantità" di campi adesso va bene? ho appena aggiunto "id temporaneo" (mi rendo ben conto come nome fa abbastanza tristezza). ci sarebbero problemi se i campi fossero in ordine alfabetico?

Non so forse potrebbe anche essere meglio se i campi fossero in ordine alfabetico, anche se così seguono una logica che è quella di raccolta dati. Il problema secondo me comunque non si pone se sono raggruppati come ora, solo che i nomi dovrebbero essere il più possibile simili a quelli che sono negli importatori.

La logica attuale è... assenza di logica, nel senso che sono così come vengono.

Il fatto di avere gli stessi nomi ovunque è una cosa ben sensata. Non ovvia perché sul sito dovrebbero essere in inglese, nei clien sono in italiano.

Vediamo cosa si può fare.

Created attachment 38 [details]
tabella contenete i nomi dei campi

Ho creato una infrastruttura per far si che i nomi siano consistenti e il più possibile indipendenti dal programma, ci è voluto un po ma ho preferito far per bene piuttosto che in fretta ;-)

in "tabella contenete i nomi dei campi"  ci sono le informazioni da integrare (nelle colonne nome italiano e nome inglese).

bisogna farci l'occhio qualche secondo, poi forse anche le altre colonne (in particolare la colonna proprietà) assumeranno un senso comprensibile!

dimenticavo: i nomi dei campi più sono corti e meglio è

al momento ho guardato molto rapidamente ma non è ce abbia capito molto... comunque appena posso mi ci concentro un'attimo... poi eventualmente ti chiedo.

Created attachment 39 [details]
aggiornamento campi rilievi edoardo 9 settembre

purtroppo ho dovuto caricare subito un aggiornamento all'elenco deicampi perché dovevo aggiornare il sistema e mi serviva che fiunzionasse, ovviamente ci saranno molti errori, la maggior parte dei campi più che nomi hanno dei poemi.

Questa roba impatta su tutte le zone del sistema da cui è possibile scegliere dall'elenco completo dei campi (attualmente la creazione delle tabelle e il download dei report)

Created attachment 40 [details]
campi modifiche

Nel file allegato ho aggiunto alcune modifiche che secondo me dovrebbero essere fatte ai nomi per essere più chiari. Forse sarebbe il caso di cambiare anche il nome in archiver, vegimport e tabimport, ma prima di tutto dovete vedere se secondo voi questi cambiamenti hanno un senso ... Ovviamente i nomi poi possono anche essere accorciati!

Non capisco l'utilità di avere i campi con null (a parte il primo, li ho evidenziati in verde), se ho capito bene questi sono campi non usati o cos'altro?... Se è così comunque dovrebbero avere un nome, così sembrano degli errori e non se ne capisce l'utilità.

Tra questi campi sono inclusi anche quelli addizionali, introtti da poco tipo il pH? Mi pare di no...

> Forse sarebbe il caso di
> cambiare anche il nome in archiver, vegimport e tabimport, 
il nome di cosa?

> ma prima di tutto
> dovete vedere se secondo voi questi cambiamenti hanno un senso ...
> Ovviamente i nomi poi possono anche essere accorciati!
comfermo la richiesta iniziale per nomi più corti possibile, più sono lunghi e più contribuiscono a creare interfacce confuse.
 
> Non capisco l'utilità di avere i campi con null (a parte il primo, li ho
> evidenziati in verde), se ho capito bene questi sono campi non usati o
> cos'altro?... 
come immaginerete sono nomi che non ho fatto in tempo a sistemare in fretta e se avete notato non sono quelli fondamentali (il not-for-search indica che non compaiono nelle ricerche).

> Se è così comunque dovrebbero avere un nome, così sembrano
> degli errori e non se ne capisce l'utilità.
non è che sembrano, è che -sono- degli errori

> Tra questi campi sono inclusi anche quelli addizionali, introtti da poco
> tipo il pH? Mi pare di no...
I cosiddetti "attributio estesi" non possono essere trattati da qui. In effetti andrebbero spostati tra gli estesi anche diversi di quelli che hanno null come descrizione.

Alla domanda il nome di cosa, intendevo il nome del campo... oltre che del campo in esportazione... I nomi si è detto che dovrebbero coincidere il più possibile.

Ok per nomi abbreviati, ma che si capisca cosa vogliono significare, se sono simili ai nomi negli importatori dovrebbe essere più facile abbreviarli.

Concordo che alcuni dei campi con null dovrebbero essere spostati tra gli attributi esterni e ok che non possono essere trattati qui, ma in qualche modo devono pur essere esportati, altrimenti che esistono a fare.

Posso fare un invito a procedere con calma?

I nomi dei campi in questione dovranno comparire ovunque allo stesso modo (come richiesto da Flavia, cosa ben ragionevole) quindi una volta deciso un campo dovrà avere lo stesso nome in archiver, tabimport, vegimport e sul sito web.

"I nomi più sono corti e meglio è" con questo non vogli invitare nessuno a chiamarli in modo incomprensibile. Lo scopo dei nomi è di comunicare un significato: quindi nomi in prima istanza comprensibili e poi corti per quanto possibile.

Credo sia meglio fare una cosa alla volta, intanto sto cercando di risolvere il problema "stesso campo con nomi diversi". Con questo non voglio escludere le altre 100 cose importanti da fare, semplicemente le trattiamo separatamente. In questa fase gli attributi estesi non sono presi in considerazione.

Questo bug è risolto, almeno per quanto riguarda i campi possibili in esportazione...

Per cosa non lo è?

Dopo più di 5 mesi senza ulteriori annotazioni considero risolta questa situazione.

Ok è risolto... ora possono essere esportati tutti i campi