[Openmark-developers] Docs

[Lucio B. <ben...@de...>]

Mattia Dongili wrote:

>[cut]
>0. Quanto dei due docs vogliamo mantenere?  
>
Io credo che la maggior parte dei requirements vada bene, ci sono alcune 
cose che mi piacerebbe aggiungere...ma ne parlero' prossimamanete, dato 
che ci sto ancora pensando.

>1. XML
>Io per la verita' non mi ero figurato un uso cosi' ampio di XML. Soprattutto per quanto riguarda la persistenza dei dati pensavo al solito buon DB relazionale ed un buono strato di rappresentazione delle gerarchie di Assessment/Block/Branch/Question con classi java. Magari senza tipizzare eccessivamente queste gerarchie ma parlando solo di Nodi e Foglie (il che mi potrebbe riportare ad XML).
>
Secondo me l'uso di XML e' essenziale, soprattutto per semplificare la 
comunicazione e agevolare l'indipendenza fra le varie parti 
dell'applicazione. Il fatto di utilizzarlo anche per la persistenza mi 
 lascia invece dubbioso: non credo molto alla effettiva utilita' ed 
efficacia dei database XML. Si potrebbe invece utilizzare un piu' 
tradizionale RDBMS e memorizzare i documenti (o frammenti) XML in BLOB 
(se poi il DBMS ha delle funzionalita' aggiuntive per trattare XML, 
tanto meglio, ma solo XML non credo che sia utile). In ogni caso, devo 
ancora dare un'occhiata ai riferimenti che ci ha dato Ugo, quindi potrei 
cambiare idea.

>
>2. GUI v/s HTML
>Chiaramente l'accoppiata Javasrcipt+HTML e' meno flessibile e sicura (questo nell'ottica di domande/questionari temporizzati) di una GUI swing. 
>Ma su questo credo dobbiate esprimervi voi in primo luogo in quanto primi utilizzatori del progetto :) Per quello che mi rigua il concetto erarda sono un po' meno ferrato su swing rispetto ad HTML+Js ma questo conta gran poco.
>Sarebbe carina una soluzione multipla (sia l'una che l'altra) e questo ci riporterebbe ad XML come mezzo di comunicazione tra applicativo e UI, ma potrebbero entrare in gioco anche i webservices (sto usando Axis da qualche giorno e devo dire che e' veramente soddisfacente, se necessario posso argomentare ulteriormente)
>
Si', un'interfaccia Web e' sicuramente piu' complicata da gestire, 
soprattutto per quanro riguarda la sicurezza ed il controllo su cio' che 
l'utente puo' fare. Ad ogni modo (almeno per me) e' un requisito essenziale.
L'unica cosa che potrebbe non essere un'interfaccia Web sono i tool di 
amministrazione e il tool di authoring, ma a me piacerebbe che lo 
fossero, sia per omogeneita', sia per praticita' di utilizzo anche da 
remoto e non necessariamente avendo a disposizione il proprio computer.
So che Ugo ha delle riserve sulla fattibilita' di quest'ultimo punto: 
potresti spiegarcene i motivi? Dopotutto ormai ci sono tantissimi 
software che possono essere amministrati con un interfaccia web (CUPS, 
SAMBA, solo per citarne alcuni), perche' non anche OpenMark? Sono 
d'accordo sulla difficolta' dello sviluppo (e potrebbe essere un buon 
motivo per non dargli una precedenza altissima: l'importante e' che si 
possano sostenere i test, meno importante che li si possa 
amministrare/costruire in maniera semplice), ma non credo che sia un 
problema di fattibilita'.

>
>Mi sfugge piuttosto come sia una domanda drag&drop e come gestire la correzione di una domanda a testo libero, ma per questo c'e' tempo.
>
Sulla domanda drag&drop non ti so dire, immagino si riferisca a domande 
in cui si deve operare col mouse (ad esempio, vengono mostrate una serie 
di icone che rappresentano periferiche e si chiede di distinguere fra le 
periferiche di input e di output spostando le relative icone in una 
scatola piuttosto che in un altra).
Per quanto riguarda la correzione di domande a testo libero, qualche 
idea ce l'ho gia', anche se non molto definita:

* Correzione manuale: l'esaminatore deve scorrersi tutte le risposte, 
leggerle e poi scrivere il voto o segnare la risposta come corretta (il 
tutto attraverso un'interfaccia Web).

* Automatica: utilizzando tecniche di Information Retrieval. Ad esempio, 
e' possibile confrontare la risposta del candidato con una risposta 
corretta, e avere un'indice di similarita' fra le due: piu' la risposta 
del candidato e' simile a quella corretta, piu' alta e' la 
verosimiglianza che la risposta del candidato sia corretta.

* Semi-automatica: viene fatta una prima correzione automatica, che deve 
essere poi revisionata dall'esaminatore (eventualmente solo per le 
risposte al di sotto di una certa soglia di verosimiglianza). 
L'esaminatore deve semplicemente dire se la correzione automatica ha 
valutato correttamente la risposta, ed eventualmente correggere la 
valutazione. Questo e' un processo molto piu' semplice e rapido per 
l'esaminatore, di quello in cui deve correggere da zero la risposta. 
Inoltre grazie a questo meccanismo si possono implementare delle 
tecniche di relevance-feedback che, mano a mano che l'esaminatore 
esprime il suo giudizio, migliorano l'efficacia della correzione 
automatica e riducono il numero degli interventi necessari.

>3. Questionari Template
>era una funzionalita' che avevamo implementato nell'applicazione di cui vi ho raccontato: in realta' il concetto era quello della duplicazione in toto del questionario, su cui poi l'esaminatore/amministratore apportava le modifiche necessarie alla personalizzazione di questo. Si potrebbe espandere un po' il concetto pensando a _strutture_ di Assessment/Block/Branch con n componenti tipizzate (sia per argomento che per difficolta'):
>  - selezionate random dal sistema (mi pare di aver letto qualcosa a riguardo nei docs)
>  - personalizzate dall'esaminatore tramite dei wizard che permettono la selezione delle componenti secondo i tipi richiesti dal template
>  
>
...non credo di aver capito molto bene...ci devo pensare meglio. 
Comunque...potresti esplicitare meglio la cosa?

A presto
  Lucio