0 votes
in SoSci Survey (dt.) by s000913 (125 points)

Bei der Auswertung einer Erhebung in R ist mir beim Prüfen der vorhandenen Werte einer Texteingabe (Definierte Zeichen: "keine Einschränkung") aufgefallen, dass bei einer Frage nach der Dauer in Stunden unerwartet viele Teilnehmer geantwortet haben sollen, dass sie beispielsweise '0.5 Stunden mit etwas verbracht hätten (man beachte das einfache Kodierungszeichen/Gänsefüßchen). Auf der Suche nach der korrekten Interpretation - könnte ja theoretisch auch für als Abkürzung für Minuten stehen - habe ich selbst alle möglichen Varianten getestet und bin hier auf eine unkonsistente Verarbeitung gestoßen.

Alle Varianten mit Komma als Dezimaltrennzeichen (mit/ohne führendem Kodierungszeichen; mit/ohne 0 als letzte Stelle) haben in allen Darstellungen in meinem Fall (Browser in Deutschland mit deutschen Zeicheneinstellungen im System) keine Probleme bereitet und die Eingegebenen Werte stimmen mit allen Ausgaben überein. Das Gleiche gilt (wie erwartet), wenn im Fragebogen einer Zahl mit Punkt als Dezimaltrennzeichen ein führendes einfaches Kodierungszeichen vorangestellt wird.

Probleme bereiteten allerdings die Eingaben einer Zahl mit Punkt als Dezimaltrennzeichen (ohne führendes einfaches Kodierungszeichen). Dabei kam es zu den folgenden nicht konsistenten (und verwirrenden) Ausgaben:

  • Eingabe von 0.5 ==> CSV: '0.5 || Daten ansehen*: 0.5 || Darstellung Fragebogen**: 0,5
  • Eingabe von 0.30 ==> CSV: '0.30 || Daten ansehen*: 0.30 || Darstellung Fragebogen**: 0.30
  • = Erhobene Daten > Daten ansehen (Tabellenansicht)
    ** = HTML-Ansicht des Fragebogens nach Klick auf die CASE-Nummer des Falls

Bei der Darstellung unter ** wird hier also eine Zahl mit Punkt als Dezimaltrennzeichen ohne 0 als letzte Ziffer sogar mit Komma als Dezimaltrennzeichen dargestellt.

Nun ist die Frage, die sich mir stellt: Was hat der Teilnehmer denn ursprünglich eingegeben, wenn in der CSV-Datei '0.5 oder '0.30 als Antwort vermerkt ist? '0.5 oder 0.5 bzw '0.30 oder 0.30?

Herzlichen Dank für die Rückmeldung.

by s000913 (125 points)
Das gleiche Problem tritt übrigens auch auf, wenn Zahlen mit führender Null eingegeben werden. Diese werden in der CSV-Datei für R ebenfalls mit einem führenden Kodierungszeichen versehen.
by SoSci Survey (305k points)
Was haben Sie denn als Format für das Eingabefeld eingestellt? Haben Sie für die Angabe "0.5" und "0.30" dasselbe Eingabefeld verwendet oder unterschiedliche?
by s000913 (125 points)
Unterschiedliche Felder einer Frage, die aber alle das gleiche Format haben. Dabei habe ich für jede Eingabe ein Feld verwendet. Falls Sie mit "Format" das Feld "Definierte Zeichen" meinen, dann ist bei allen diesen offenen Texeingaben "keine Einschränkung" ausgewählt.
by SoSci Survey (305k points)
Bei dem (nicht-)Format "keine Einschränkung" sollte die Eingabe unverändert in den Datensatz übernommen werden. Allerdings ergänzt SoSci Survey beim Download der Daten per CSV das Anführungszeichen, damit Excel die Werte nicht als Zahl um-interpretiert, was z.B: dazu führt dass führende Nullen abgeschnitten werden.

Ich habe gerade eine Test-Frage angelegt mit drei Eingabefeldern, eingetragen "0.5", "0.30" und "0.01" und ich bekomme sowohl unter "Erhobene Daten" wie auch wenn ich dort auf die Druckansicht klicke, exakt diese Angaben wieder angezeigt. Heißt, ich kann Ihre Beobachtung im Moment nicht replizieren. Würden Sie die beiden Werte nochmal testen und diesmal das jeweils andere Feld verwenden?

Haben Sie die CSV-Datei über den Karteireiter "CSV" abgerufen oder haben Sie den R-Import (Karteireiter "GNU R") verwendet?

Und generell: Wenn Sie Dezimalzahlen erwarten, empfehle ich, das als Vorgabe für das Eingabeformat festzulegen. Das hat den Vorteil, dass SoSci Survey Kommata und Punkte schon bei der Eingabe vereinheitlicht.
by s000913 (125 points)
Das Voranstellen eines Anführungszeichen macht beim Import in Tabellenkalkulationsprogrammen sicher Sinn, um die von Ihnen beschriebenen Fehler zu vermeiden. Allerdings wird beim CSV-Import in R ja der Wert als Zeichenkette eingelesen und diese Fehler entstehen somit nicht. Wird aber das Zeichen automatisch vorangestellt, so kann ich nie wissen, ob das Anführungszeichen vom User kommt oder nicht. Daher sollte aus meiner Sicht beim CSV-Export für R kein Anführungszeichen hinzugefügt werden, denn das verfälscht die Daten nur.

Was den zweiten Absatz angeht, kann ich die Situation ebenfalls nicht replizieren. Aber ich denke, die Erklärung hier darin liegen, dass der Fragebogen, in welchem ich getestet hatte, auf Niederländisch war, und Niederländische Seiten bei mir aktuell automatisch übersetzt werden. Insofern mea culpa, das war dann wohl nicht gut genug geprüft.

Die Datei habe ich über den Reiter R-Import abgerufen.

Was die Dezimalzahlen angeht rufen wir diese bewusst als offenen Text ab, denn so kann ich noch den ein oder anderen Panel-Teilnehmer minderer Qualität rausfiltern, denn wenn man gezwungen wird, dann schreibt man halt eine Zahl rein, aber so haben wir auch TN dabei, die einfach Textfragmente eingetragen hatten.

Danke für die ausführliche Antwort =)
by SoSci Survey (305k points)
> Daher sollte aus meiner Sicht beim CSV-Export für R kein Anführungszeichen hinzugefügt werden, denn das verfälscht die Daten nur.

Da stimme ich Ihnen zu. Das kontrolliere und ändere ich zeitnah.
by s000913 (125 points)
Perfekt! Danke für Ihr Engagement.

1 Answer

0 votes
by SoSci Survey (305k points)
selected by s000913
 
Best answer

Daher sollte aus meiner Sicht beim CSV-Export für R kein Anführungszeichen hinzugefügt werden, denn das verfälscht die Daten nur.

Danke für den Hinweis. Wir haben den CSV-Export für R nun so angepasst, dass dort Zahlen mit einer führenden Null (z.B. auch Telefonnummern, dort gibt es in Excel die meisten Probleme) nicht mehr durch ein Anführungszeichen (') maskiert werden.

Weiterhin durch ein vorangestelltes Leerzeichen maskiert werden aber Antworten, die mit einem Gleichheitszeichen beginnen (=2+2), da über Excel-Formeln Schadcode auf Computer installiert werden kann. Und wer weiß, wenn eine CSV-Datei unversichtlich per Doppelklick geöffnet wird...

by s000913 (125 points)
Klar, Sicherheit geht natürlich vor!

Danke für's schnelle Anpassen =)

Willkommen im Online-Support von SoSci Survey.

Hier bekommen Sie schnelle und fundierte Antworten von anderen Projektleitern und direkt von SoSci Survey.

→ Eine Frage stellen


Welcome to the SoSci Survey online support.

Simply ask a question to quickly get answers from other professionals, and directly from SoSci Survey.

→ Ask a Question

...