Formato di testo semplice semplice, affidabile, aperto e interoperabile per l'archiviazione dei dati


17

In una domanda precedente ho chiesto informazioni sugli strumenti per la modifica dei file CSV .

Gavin si è collegato a un commento su R Help di Duncan Murdoch suggerendo che il formato di interscambio di dati è un modo più affidabile per archiviare i dati rispetto a CSV.

Per alcune applicazioni è necessario un sistema di gestione di database dedicato. Tuttavia, per i progetti di analisi dei dati su piccola scala sembra più adatto qualcosa di più leggero.

Considerare i seguenti criteri per la valutazione di un formato di file:

  • affidabile : i dati inseriti dovrebbero rimanere fedeli a quanto inserito; i dati dovrebbero essere aperti in modo coerente in diversi software;
  • semplice : sarebbe bello se il formato del file fosse di facile comprensione e idealmente leggibile con un semplice editor di testo; dovrebbe essere facile scrivere un semplice programma per leggere e scrivere il formato.
  • aperto : il formato dovrebbe essere aperto
  • interoperabile : il formato del file dovrebbe essere supportato da molti sistemi

Trovo che i formati di valori separati da tabulazione e virgola non riescano sul criterio di affidabilità. Anche se suppongo di poter incolpare i programmi di importazione ed esportazione piuttosto che il formato del file. Mi ritrovo spesso a dover apportare piccole modifiche alle opzioni read.tableper evitare che uno strano personaggio interrompa il caricamento del frame di dati.

Domande

  • Quale formato di file soddisfa meglio queste esigenze?
  • Il formato di interscambio di dati è un'alternativa migliore? o ha i suoi problemi?
  • C'è qualche altro formato preferibile?
  • Sto valutando ingiustamente TSV e CSV? Esiste un semplice insieme di suggerimenti per lavorare con tali file che rendono il formato del file più affidabile?

2
Dovrei aggiungere, R non ha un write.DIF()quindi è un po 'una strada a senso unico, temo.
Ripristina Monica - G. Simpson

1
Non capisco il problema del CSV e dell'affidabilità. Vuoi dire che CSV non è abbastanza severo? Rigido significa che se i regolamenti per CSV fossero abbastanza rigidi, ogni strumento che segue queste definizioni potrebbe caricare un file senza la necessità di parametri aggiuntivi.
Steffen,

@steffen Intendo cose come: il caricamento e il salvataggio di un file CSV in alcuni programmi modifica il file CSV; il caricamento di file CSV può comportare una conversione inappropriata a meno che tu non stia attento; I file CSV a volte si interrompono quando vengono aggiunte strane combinazioni di caratteri senza una corretta escape. Forse sto confondendo l'uso di CSV con il formato stesso, anche se ho sentito le persone commentare la mancanza di uno standard ufficiale. Certo, mi rendo conto che in molti casi funziona perfettamente.
Jeromy Anglim,

5
@steffen: CSV non memorizza alcuna informazione sul formato o sui tipi di dati dei dati memorizzati nel file. Puoi aprire un file CSV in due diverse app e far interpretare i dati nel file in due modi diversi.
Ripristina Monica - G. Simpson l'

1
@JeromyAnglim, penso che la modifica del file CSV dipenda dal tuo software, non dal formato CSV in sé.
Roman Luštrik,

Risposte:


9

Mi chiedo se ci sia una collisione tra i criteri in corso qui.

Una lamentela riguardo ai formati di file come Excel, SQL, ecc. È che devi definire in anticipo i tipi di dati per farlo funzionare bene, il che va contro il criterio "qualcosa di più leggero" (poiché capisco che la tua restrizione deve essere più tempo correlato rispetto a quello computazionale).

Al contrario, i criteri secondo cui i dati non devono essere confusi, o consentire che i dati vengano confusi, richiedono un controllo degli errori. A meno che non lasci che il sistema capisca automaticamente i tipi di dati (che è essenzialmente il punto in cui Excel ti sta fallendo), non c'è modo di avere la tua torta e mangiarla.

IMO, dei due, il secondo criterio è più importante. L'integrità dei dati, una volta violata, rende l'analisi difficile o impossibile. Osservazioni perse o valori non validi (se non controllati correttamente) possono rovinare tutto.

Per quanto riguarda il DIF, il testo non elaborato effettivo non è leggibile dall'uomo e sarebbe difficile (IMO) per gli umani inserire dati.

IMO, dovresti dare una scossa equa ai file delimitati. Come menzionato sopra nei commenti, la "manipolazione dei dati" è principalmente colpa di un sottoinsieme di strumenti che si sta utilizzando. I programmi ben educati non dovrebbero manipolare i file delimitati. La più grande fonte di demolizione è un delimitatore mal specificato. Ad esempio, se i tuoi dati potrebbero contenere virgole, un CSV è inappropriato. Se potrebbe avere le schede TSV non è appropriato. Per molti (ma non tutti) programmi è possibile specificare un delimitatore alternativo. Ad esempio, ho usato la tilde (~) in un paio di casi difficili.


Grazie. Sembra che l'uso di un formato di file delimitato con la dovuta cura possa essere l'opzione migliore.
Jeromy Anglim,

6

In tutta serietà, prenderei in considerazione i file RData creati da R stesso come si adatta

  • affidabile (controllo)
  • semplice (chiamalo un sorteggio - il formato è binario)
  • aperto (controlla: non si apre più del codice sorgente R)
  • interoperabile (controlla: funziona ovunque R funzioni)

Abbastanza vicino per me. Se per sistemi intendi applicazioni anziché sistema operativo, l'ultimo punto è un fallimento.

Oh, e RData è efficiente in quanto i file sono ora compressi per impostazione predefinita (che era un'opzione che era disattivata per impostazione predefinita).


2
RData funziona sicuramente bene con R. Potrebbe essere problematico per quanto riguarda il controllo della versione. Suppongo che la funzione R dput()fornisca un'alternativa di testo semplice che funzionerebbe con il controllo della versione. Tuttavia, uno degli appelli di csv / tsv è che quando condivido un repository con dati (diciamo per un articolo di giornale), le persone potrebbero prendere i dati e rianalizzarli facilmente usando qualsiasi software che preferiscono.
Jeromy Anglim

1
Sì, è una questione estremamente complicata. Penso che la gente ne abbia discusso sin dagli albori dell'informatica. Ho avuto altri due pensieri (e ho potuto espandere la mia risposta): ProtocolBuffer sono buoni per condividere in modo efficiente con Python, Java, C ++, ... e una miriade di altre lingue; Romain e io ci occupiamo di R. Il nuovo sito mldata.org lo copre per la ricerca in Machine Learning: hanno persino strumenti che rendono disponibili per la conversione. Potrebbe valere la pena dare un'occhiata.
Dirk Eddelbuettel,

1
In realtà, SVN accetta senza problemi BLOB binari come file PDF, ecc. Sospetto che lo faccia anche Git.
Dirk Eddelbuettel,

Buono a sapersi sui BLOB binari. Sarebbe comunque bello poter eseguire diff su file di testo e ottenere informazioni significative sulle modifiche. Grazie anche per il link a mldata.org. Sembra interessante.
Jeromy Anglim,

Piacere. Il sito della sorella mloss.org è semplicemente fantastico, se spero che ottengano trazione per mldata.org. È il momento giusto per quello.
Dirk Eddelbuettel,

4

In risposta alla risposta di Dirk Eddelbuettel, suggerisco di usare il formato di file HDF5 . È meno semplice del formato RData, o potresti dire "più ricco", ma sicuramente più interoperabile (può essere utilizzato in C, Java, Matlab, ecc.). Ho scoperto che l'I / O che coinvolge grandi file HDF5 è molto veloce.


(+1) Hai pensato alle sue prestazioni rispetto a NetCDF ?
chl

IIRC che è anche il formato interno scelto su mldata.org - con una suite di strumenti che si convertono. I convertitori potrebbero valere la pena dare un'occhiata. Ho sempre avuto la sensazione che il supporto R per HDF5 fosse meno perfetto.
Dirk Eddelbuettel,

@chl Avevo vagamente pensato che NetCDF usasse HDF5 internamente, ma questo non sembra del tutto accurato.
Shabbychef,

2

Non sono sicuro del perché il formato di testo fisso con i metadati appropriati non soddisfi i tuoi criteri. Non è semplice da leggere come un delimitatore, ma sono comunque necessari i metadati per utilizzare le informazioni. Il compito di scrivere la sintassi per leggere il programma dipende semplicemente da quanto è grande e complicata la struttura del set di dati. SPSS ed Excel hanno una GUI per aiutare con queste attività.

Ci sono solo due errori con i file CSV che ho riscontrato:

  1. Campi mancanti senza delimitatori (quindi ogni altro campo in quel record è fuori posto, ho avuto anche questo problema con tag mancanti in XML)
  2. Una virgola all'interno di una stringa di testo

(se hai riscontrato altri problemi, sentiti libero di fare esempi)

Due sono risolti con un delimitatore più irregolare come suggerito da drnexus (una pipe (|) è quella che ho incontrato prima, ma una tilde (~) funziona altrettanto bene in quanto non è probabile che sia inclusa nei campi stringa). Uno è un problema non facilmente risolvibile dal software in uso, ed entrambi sono problemi con il modo in cui le persone hanno scritto i file, non con il software utilizzato per leggere i file.

Vorrei anche dire che sono d'accordo con drnexus sia su questo thread che sulla sua risposta sull'altro thread recente sulla modifica di questi file. Sembra che ti stia lamentando del software che usi (in particolare Excel) e ti chieda di archiviare i dati in un formato conforme al tuo software mal comportato. Forse la domanda dovrebbe essere come ottenere Excel per interrompere la formattazione automatica dei file di testo normale. I tuoi criteri affidabili come mi sembrano sono un problema software con la lettura di file di testo semplice. Non uso R per la gestione dei dati, ma non ho avuto difficoltà a leggere i file delimitati in SPSS, come sembra suggerire.

Se i file originali non sono scritti correttamente, cosa ti aspetti che un software legga il file in modo affidabile? E un formato di file specifico non ti impedirà di scrivere in modo errato i dati in qualunque tipo di file tu scelga di iniziare.


(1) Vorrei poter aprire e chiudere il file di dati con la stessa facilità con cui posso aprire un file di dati Rdata, Excel o SPSS. Trascorrere del tempo camminando attraverso un mago funziona, ma non è proprio il flusso di lavoro semplice e affidabile che mi piacerebbe idealmente. (2) Sì, sono d'accordo sull'uso di un delimitatore irregolare. In generale Tab è sufficiente per me il più delle volte; (3) Non ho grossi problemi con CSV / TSV. Ho problemi occasionali che possono essere facilmente risolti. Tuttavia, mi piacerebbe non dover pensare ai problemi dei delimitatori e alla conversione dei formati.
Jeromy Anglim,

@Jeromy Anglim, per il punto n. 1, immagino che normalmente devi farlo solo una volta (a meno che non migri frequentemente tra due diversi ambienti che non possono leggere o produrre altri file). Per il punto 3, i file di testo corretti risolvono questo problema. Non ho mai incontrato una situazione in cui SPSS ha formattato un tipo di file diverso in modo errato. Se non è necessario divulgare i file, l'intera domanda è disattivata, se è possibile ottenere il salvataggio corretto dei file in qualsiasi ambiente in cui si lavora, non è più necessario eseguire la conversione / archiviazione.
Andy W,

1

Il problema comune con il formato di testo normale è che non è possibile memorizzare i metadati. Come si definiscono i dati mancanti? Come definisci 1 = in forte disaccordo, 2 = in disaccordo, ... tipi di cose in formato testo normale? Con il formato di testo normale, devi usare un altro documento per definire quei metadati. E non è facile da fare in XML.

A volte questo problema può essere molto inquietante.

La mia soluzione è utilizzare il formato dati SPSS, che è autonomo e facile da modificare in SPSS. So che questa non è una risposta giusta alla tua domanda, ma ho lottato sullo stesso problema per molto tempo e questa è la mia soluzione attuale.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.