Partial Credit bei abgeleiteten Variablen: leere Teilfelder von Omission unterscheiden

[jurei733]

Ausgangslage

Bei Partial-Credit-Aufgaben mit abgeleiteter Variable funktioniert die Auswertung aktuell nicht wie fachlich benötigt, wenn einzelne Basisvariablen leer bleiben dürfen.

Beispiel:

• Basisvariablen: 01a, 01b, 01c, 01d
• abgeleitete Variable: 01
• Ableitungsmethode: Bewertung summieren
• Fall: drei von vier Antworten korrekt, ein Feld leer

Aktuelles Ergebnis in diesem Fall:

• die leere Basisvariable bleibt DISPLAYED
• die abgeleitete Variable wird INVALID

Für Partial Credit wäre jedoch erwartbar, dass die abgeleitete Variable auswertbar bleibt, z. B. als teilweise richtig.

Problem mit aktuellem Workaround

Wenn bei den Basisvariablen in den Ableitungsparametern sowohl

• Angezeigt = Wert geändert
• Leerer Antwortwert ist gültig

aktiviert wird, funktioniert die Partial-Credit-Auswertung für teilweise bearbeitete Fälle zwar.

Dann wird aber auch der Fall, dass gar keine Antwort eingetragen wurde, als CODING_COMPLETE mit Code 0 / Bewertung 0 ausgewertet. Dadurch gehen Omission/Missing und echte falsche Antworten fachlich ineinander über.

Zu klärende Ziel-Logik

Es sollte fachlich und technisch geklärt werden, wie die Auswertung abgeleiteter Variablen bei Partial Credit mit leeren Quellwerten aussehen soll.

Vorgeschlagene Fallmatrix zur Abstimmung:

Fall	Erwartung
Alle Basisvariablen leer	weiterhin als Missing/Omission erkennbar, nicht automatisch falsch
Einzelne Basisvariablen bearbeitet, andere leer	Auswertung der abgeleiteten Variable soll möglich sein
Drei von vier Antworten richtig, eine leer	Partial Credit, nicht INVALID
Teilweise richtige und teilweise falsche Antworten	Bewertung gemäß Partial-Credit-Logik
Einzelne fachlich ungültige Eingabe	weiterhin als INVALID unterscheidbar
Alle Antworten korrekt	vollständig richtig

Akzeptanzkriterium

Die Logik muss weiterhin sauber unterscheiden können zwischen:

• vollständig unbearbeitet / Omission / Missing
• teilweise bearbeitet mit leeren Teilfeldern
• fachlich falsch
• ungültig / INVALID

Leere Teilfelder sollen innerhalb einer begonnenen Bearbeitung Partial Credit nicht verhindern. Vollständig unbearbeitete Aufgaben sollen aber nicht automatisch als CODING_COMPLETE mit Code/Bewertung 0 behandelt werden.

Vorschlag zum Vorgehen

1. Erwartete Status-/Code-/Bewertungsmatrix fachlich abstimmen.
2. Prüfen, ob die bestehende Parametrisierung dafür ausreicht.
3. Falls nicht, technische Erweiterung der Ableitungslogik bzw. Parametrisierung definieren.
4. Umsetzung mit Regressionstests für die abgestimmten Fälle absichern.

[schumaki]

Man könnte in den Basisvariablen (mit Angezeigt = Wert geändert und Leerer Antwortwert ist gültig) jeweils einen expliziten Code zum Abfangen von leeren Feldern anlegen:

Mit der Ableitungsmethode "Codes aneinanderhängen" könnte dann zwischen falschen, aber bearbeiteten Aufgaben und Omissions unterschieden werden.

Wenn allerdings aus einem anderen Grund "Bewertung summieren" o. ä. benötigt wird, funktioniert das nicht.

---

Im Zusammenhang mit #161 wäre zu überlegen, ob man generell ein anderes Handling von nicht bearbeiteten / leeren / syntaktisch falschen (z. B. Buchstaben in numerischen Eingaben) Basisvariablen braucht.

[jurei733]

Ich sehe den Vorschlag als guten Workaround für Fälle, in denen die Ableitung die Einzelcodes noch sichtbar macht, vor allem bei CONCAT_CODE.

Dort funktioniert die Idee: Wenn leere Basisfelder einen eigenen Code bekommen, kann die abgeleitete Variable später noch unterscheiden zwischen z. B. „leer“, „falsch“ und „richtig“.

Für SUM_SCORE reicht das aber nicht aus. Bei dieser Methode bleibt am Ende nur die Summe der Scores übrig. Wenn ein leeres Feld und eine falsche Antwort beide Score 0 haben, sehen diese Fälle nach der Summierung gleich aus. Dann kann man „gar nicht bearbeitet“ nicht mehr sauber von „bearbeitet, aber falsch“ unterscheiden.

Deshalb würde ich den Vorschlag eher als Workaround dokumentieren, aber nicht als allgemeine Lösung für #167 verstehen.

Die eigentliche Lösung müsste m. E. eine explizite Regel für leere Quellwerte definieren:

• vollständig leer: bleibt als Omission/Missing erkennbar
• teilweise bearbeitet mit leeren Teilfeldern: Partial Credit bleibt möglich
• syntaktisch ungültige Eingaben: bleiben von leeren Feldern unterscheidbar

Das passt auch zu #161: Wir brauchen wahrscheinlich nicht nur einen speziellen Leer-Code in den Basisvariablen, sondern eine allgemeinere und sichtbare Behandlung von leeren bzw. ungültigen Quellwerten in der Ableitungslogik.

[jurei733]

Ergänzend zu iqb-berlin/coding-box#190 sollte hier m. E. auch die Missing-Aggregation für abgeleitete Variablen explizit geklärt werden.

Für DERIVE_PENDING bzw. den 2. Autocoderlauf reicht es vermutlich nicht, nur einzelne leere Quellwerte zu behandeln. Fachlich offen ist auch, was passieren soll, wenn mehrere Quellvariablen unterschiedliche Missing- oder Invalid-Zustände haben.

Beispiele:

Quellvariablen	Erwartung für abgeleitete Variable
alle leer / nicht bearbeitet	Omission/Missing bleibt erkennbar
teilweise bearbeitet, teilweise leer	Partial Credit soll möglich bleiben
eine Quelle mir, andere korrekt	Aggregationsregel nötig
eine Quelle mci, andere mir	Priorität/Kombination nötig
syntaktisch ungültige Quelle plus leere Quelle	Unterscheidung INVALID vs. Missing nötig
alle Quellen fachlich falsch	nicht mit Omission vermischen

Für iqb-berlin/coding-box#190 ist das relevant, weil die spätere Itemmatrix/Score-Matrix nicht selbst entscheiden sollte, welche Missing-Codes aus abgeleiteten Variablen entstehen. Der Export sollte nur vorhandene oder vorher regelbasiert aufgelöste Codes/Scores abbilden.

Ich würde deshalb vorschlagen, hier eine explizite Aggregationsregel zu definieren, ähnlich der Idee von collapseMissings() aus eatPrep():

• Welche Missing-Codes haben Priorität?
• Wann bleibt eine abgeleitete Variable DERIVE_PENDING?
• Wann wird ein Missing-Code gesetzt?
• Wann ist der Fall fachlich INVALID?
• Wie werden unterschiedliche Missing-Codes aus mehreren Quellvariablen kombiniert?

Refs iqb-berlin/coding-box#190, iqb-berlin/coding-box#642.

[schumaki]

Bitte hier an der Referenzimplementierung in eatPrep::aggregateData() orientieren: https://github.com/sachseka/eatPrep/blob/master/R/aggregateData.R

@sachseka Kann die Logik aus den Papiertests hier 1:1 übernommen werden oder bräuchte es eine neue Matrix zur Missing-Aggregierung? Und soll das (z. B. im Missing-Profil des Arbeitsbereichs) in der Kodierbox editierbar sein?

[schumaki]

Bitte auch Zusammenhang mit #642 beachten.