<td>Variablenlabel (description in variables.csv, falls leer und description_de gefüllt, wird description_de verwendet mit führendem \[de\])</td>
<td>Variablenlabel (description in variables.csv, falls leer und description_de gefüllt, wird description_de verwendet mit führendem \\\[de\\\])</td>
</tr>
<tr>
<td>source.path</td>
...
...
@@ -183,11 +183,15 @@ Das Registrierungsergebnis, vermutlich eine JSON mit allen Variablen sollte sich
- Wenn die nächste Welle mit einer Kopie der v37-Metadaten beginnt (derzeit der Fall), müssen bei nächster Registrierung nur noch die neuen Variablen (also die ohne PID registriert werden)
# Weil paneldata.org versionsagnostisch ist
# Granularität der PID: Version, Edition, Dateiformat
- Die PID einer Variable in einem Datensatz ändert sich nicht über die Zeit, auch wenn der Inhalt sich ändert (Korrekturen, neue Fälle künftiger Wellen). Die Landing-Page repräsentiert immer die aktuellste Welle/Version.
- Wegfallende Variablen/Datensätze sollen eine Rumpf-Landingpage mit den Registrierungsinformationen erhalten.
- Aber durch die DOI wird ein Versionsbezug implizit hergestellt.
- paneldata.org ist versionsagnostisch
* Die PID einer Variable in einem Datensatz ändert sich nicht über die Zeit, auch wenn der Inhalt sich ändert (Korrekturen, neue Fälle künftiger Wellen). Die Landing-Page repräsentiert immer die aktuellste Welle/Version.
* Wegfallende Variablen/Datensätze sollen eine Rumpf-Landingpage mit den Registrierungsinformationen erhalten.
* Aber durch die DOI wird ein Versionsbezug implizit hergestellt.
- in jeder Version/Welle gibt es unterschiedliche Editionen
