Presentation Paper: CrowdDB: Answering Queries with Crowdsourcing Authors: Michael Franklin, Donald Kossmann, Tim Kraska, Sukriti Ramesh, Reynold Xin Publication Date: June 2011 Conference: ACM SIGMOD Conference

1. CrowdDB: Answering Queries
with Crowdsourcing
Authors: Michael Franklin, Donald Kossmann, Tim Kraska, Sukriti
Ramesh, Reynold Xin
Publication Date: June 2011
Conference: ACM SIGMOD Conference
Viviana Murello
Scienze delle Reti
a.a. 2010/2011

2. Riassunto 1
 Alcune query non possono essere
soddisfatte dai database tradizionali
 l’elaborazione di tali query hanno
bisogno di input da parte delle
persone per
 Snellire l’elaborazione
 Per i confronti
 Per la classificazione
 O aggregazione dei risultati

3. Riassunto 2
 I CrowdDB usano l’input umano
fornito tramite crowsorcing per
rispondere alle query
 Descriviamo alcune caratteristiche
di un CrowdDB e alcuni esperimenti
fatti usando Amazon Mechanical
Turk

4. RDBMS
 Le assunzioni di base dei RDBMS
sono:
 Correttezza
 Completezza
 Non ambiguità
Dei dati.
Quando queste assunzioni mancano il
sistema fornisce risposte sbagliate
oppure non ne fornisce affatto.

5. Potere alle persone
 Il sistema fornisce risposte sbagliate
 Es. SELECT market_capitalization FROM
company WHERE name = "I.B.M.";
 I.B.M. non è stato inserito
 I.B.N.
 International Business Machine
 Altro esempio di queries che non trovano
risposte con gli attuali RDBMS:
 Es. stabilire quanto un’immagine è rilevante
per un certo argomento

6. Potere alle persone 2
 2 problemi
 Close World Assuption: le informazioni
che non sono inserite nel DB sono
considerate false o innesistenti
 RDBMS sono estremamente letterali: si
aspettano valori validi

7. CrowdDB
 Sfruttare Human Computation per
risolvere problemi
 AMT (Amazon’s Mechanical Turk)
 Trovare nuovi dati
 RDBMS: limitato dalla Closed World Assuption
 Persone: aiutate da strumenti sono brave nel
trovare nuove informazioni
 Confrontare dati
 RDBMS: algoritmi di confronto sono difficili o
impossibili
 Persone: sono qualificate a fare confronti

8. Crowdsourcing
 Amazon’s Mechanical Turk
 Assignment (compito)
 HIT
 HIT Group
 API di Mechanical Turk
 createHIT(title, description, question, keywords, reward,
duration,maxAssignments, lifetime)  HitID
 getAssignmentsForHIT(HitID)list(asnId, workerId ,
answer)
 approveAssignment(asnID) / rejectAssignment(asnID)
 forceExpireHIT(HitID)

9. Considerazione sulla progettazione del
CrowdDB
 La progettazione del CrowdDB è influenzata da:
 Prestazioni e variabilità: le persone e le macchine
differiscono in velocità e qualità.
 Attività di progettazione e ambiguità: le persone
richiedono UI per evitare che certe istruzioni
vengano interpretate in modo sbagliato.
 Affinità ed apprendimento: l’insieme dei lavoratori
sviluppa relazioni con i richiedenti e competenze per
certi HITs
 Quantità di lavoratori relativamente piccola:
 Mondo chiuso vs Mondo aperto: ogni operazione
potrebbe ritornare un numero illimitato di risposte
influenzando così l’ottimizzazione della query, i costi
di esecuzioni e la qualità della risposta.

10. Progettazione ed implementazione del
CrowdDB 1
 crowdDB usa i dati
memorizzati
quando possibile
altrimenti usa
interroga la folla
 Risultati ottenuti
vengono
memorizzati

11. Progettazione ed implementazione del
CrowdDB 2
 Sulla sx ci sono i
componenti
tradizionali
 Sulla dx i nuovi
componenti per
interagire con la folla
 Turker Relationship
Management
 User Interface
Management
 Hit manager:
controlla iterazioni
tra CrowdDB e
piattaforma di
crowdsourcing (AMT)

12. CrowdSQL
 CrowdSQL è un’estensione dell’SQL che
supporta il crowdsourcing nei casi d’uso
che coinvolgono dati mancanti e
comparazioni soggettive.
 Attributi specifici di una tupla, intere tuple
o intere tabelle possono essere
crowdsourced.
 Gestiamo i casi di dati mancanti con la
parola chiave CROWD.
 Per i confronti soggettivi e ordinamenti
usiamo rispettivamente le parole chiave
CROWDEQUAL e CROWDORDER

13. CrowdSQL – esempi
 Crowdsorced Colum
 CREATE TABLE Department ( university STRING, name
STRING, url CROWD STRING, phone STRING, PRIMARY KEY
(university,name) );
 Se un nuovo dipartimento viene creato automaticamente
spesso non viene inserita direttamete l’url, ma questa è
disponibile in altra forma (crowdsourced)
 Crowdsorced Table
 CREATE CROWD TABLE Professor (name STRING PRIMARY
KEY, email STRING UNIQUE, university STRING,
department STRING, FOREIGN KEY (university,
department) REF Department(university,name));
 CrowdDB si aspetta che ci possono essere altri professori per
il dipartimento che possono essere reperiti tramite
crowdsourcing.

14. CrowdSQL – esempi e considerazioni
 CROWDEQUAL
 Questa funzione prende 2 parametri in input
(lvalue,rvalue) e viene usata per decidere se 2 valori sono
uguali ~=. La seguente query richiede nomi diversi per
identificare “computer science” nel DB
 SELECT profile FROM department WHERE name ~=
"CS";
 CROWDORDER
 Questa funzione è usata per classificare o ordinare i
risultati.
 CREATE TABLE picture (p IMAGE, subject STRING);
SELECT p FROM picture WHERE subject = "Golden
Gate Bridge“ ORDER BY CROWDORDER(p,"Which picture
visualizes better %subject");

15. CrowdSQL
 CNULL è equivalente al NULL del SQL
standard ma indica che il valore può
essere crowdsourced quando viene usato
per la prima volta.
 CNULL è generato automaticamente per
le istruzioni di INSERT (è il valore di
default per le colonne crowd)
 Se un attributo viene inizializzato a NULL
il crowdsourcing non avrà effetto.

16. CrowdSQL
 SELECT * FROM Professor WHERE email LIKE
“%berkeley%” AND dept = “Math”;
 La query richiede email e il dipartimento (se
hanno valore CNULL) di tutti i professori
individuati dalla condizione where
 Le specifiche del CrowdSQL prevedono che le
tabelle siano aggiornate quando vengono
interrogate le persone.
 Gli aggiornamenti e gli inserimenti fanno parte
della stessa transazione e vengono eseguiti prima
dell’interrogazione.

17. CrowdDB – in pratica
 Dato che si passa all’assunzione di mondo aperto
il costo per ogni query potrebbe essere illimitato
 Non è chiaro il numero di tuple che possono essere
coinvolte per eseguire completamente la query
 Clausola LIMIT per limitare il numero di tuple che
possono essere ritornate dalle interrogazioni
 Una futura estensione del CrowdDB potrebbe
includere
 il controllo della derivazione dei dati (ad esempio
per escludere i dati forniti da un utente che si sa
essere uno spammer, o per sapere la data di
inserimento per sapere quando un dato non è più
valido)
 controllo sulla pulizia dei dati in quanto in una
tabella di tipo crowd può succedere che la chiave
primaria si un dato crowdsourced.

18. Generazione delle interfaccia utente
 La chiave del successo per il
crowdsourcing è avere delle
interfacce utenti efficaci.
 Alla compilazione il crowdDB crea i
template per richiedere alle persone
i dati mancanti per le tabelle crowd
e gli attributi crowd.
 I template possono comunque
essere estesi dai programmatori .

19. Interfacce di base
 In generale UI sono
generate copiando i dati
conosciuti mentre tutti i
dati che hanno valore
CNULL diventano campi di
input del form
 Se il CrowdDB prevede il
vincolo CHECK questo
limita il dominio del valore
richiesto.
 Un’ottimizzazione è quella Altra ottimizzazione è
di raggruppare (batch) le prefetching
tuple. (richiedere prima) gli
 Assunzione: conviene
attributi di una stessa
inserire 2 parti di tupla. Ad esempio se
informazione dello stesso manca sia la email
tipo in un unico form che 2 che il dipartimento
parti in form separati chiedo entrambi. La
versione attuale non
implementa questa
possibilità

20. Interfacce di base
 Queste sono le
interfacce per il
confronto e
l’ordinamento
 Entrambi possono
essere raggruppate
 Nell’attuale
implementazione sono
supportati solo i
confronti binari.

21. Interfacce di base – relazioni con chiavi
esterne
 Nel caso più semplice la chiave esterna punta a
una tabella non crowd, viene quindi visualizzato
un menù a tendina con i valori possibili
 Nel caso in cui la chiave esterna punti a una
tabella crowd i possibili valori non si conoscono a
priori e quindi possono essere richieste tuple in
più rispetto a quella richiesta

22. Elaborazione della query
 Il parse del crowdDB è stato esteso per
analizzare CrowdSQL
 L’ottimizzatore del crowdDB è stato
implementato in modo da tenere conto
dei nuovi operatori.

23. I nuovi operatori
 CrowdProbe: usato per inserire nuovi informazioni
o creare nuovo tuple. L’operatore forza il controllo
di qualità selezionando la risposta che è stata
data più volte. Nel caso di nuove tuple i valori
inseriti possono differire nella chiave primaria in
questo caso il task viene riproposto lasciano vuoti
tutti i dati non confermati a parte la chiave
primaria.
 CrowdJoin: per ogni tupla della relazione più
esterna, l’operatore crea uno o più HITs al fine di
crowdsourcing nuove tuple dalla relazione interna
che corrispondano alla relazione più esterna. Il
controllo di qualità è quello usato nel CrowdProbe.
 CrowdCompare: questo operatore implementa
CROWDEQUAL e CROWDORDER. Il controllo di
qualità viene fatto a maggioranza.

24. Esperimenti
 AMT (ottobre 2010)
 25000 HITs
 Vari parametri come prezzo, jobs per HIT
e ora.
 Sono stati misurati tempo di risposta e
qualità delle risposte fornite dalle persone
 Obiettivo dell’esperimento: esaminare il
comportamento delle persone per i vari
tipi di compiti richiesti dal CrowdDB non
che di ottenere intuizioni per ottimizzare i
costi di esecuzione delle queries.

25. Base dell’esperimento
 Tabella: CREATE TABLE businesses ( name VARCHAR
PRIMARY KEY, phone_number CROWD VARCHAR(32),
address CROWD VARCHAR(256));
 Richiesta: SELECT phone_number, address FROM
businesses;
 Dato che le competenze e le persone non sono
equamente distribuite nei vari fusi orari, l’ora può
incidere sui tempi di risposta e la qualità
 In questo articolo riportiamo solo i risultati ottenuti tra
le 0600 e 1500 PST per ridurre la variabilità
 Gli esperimenti sono stati ripetuti 4 volte e fatto la
media dei valori ottenuti.
 Ricompensa di default: 1 centesimo/HIT e ogni HIT
richiedeva numero di telefono e indirizzo .

26. Esperimento 1 – Tempo di risposta al
variare # HIT/gruppo
 Esaminiamo il tempo di risposta dei compiti in funzione del numero di
HITs in un HIT Group.
 Il # di HITs per HIT Group varia da 10 a 400, # di incarichi per HIT =
1
 (4) mostra tempi di risposta, (5) # di HITs completati in 30 min.
 Risultato: le prestazioni per compiti semplici possono variare
notevolmente anche quando a variare è un unico parametro.

27. Esperimento 2 – Reattività /
ricompensa
 Analizziamo quanto il tempo di
risposta varia in funzione della
ricompensa
 (6) mostra che la % di HITs
completata è in funzione del
tempo. Ovviamente più si
aspetta e più compiti vengono
completati.
 (7) mostra la frazione di HITs che
ricevono almeno una risposta in
funzione del tempo.
 Confronto:
 In 60 minuti la maggioranza di
HITs riceve almeno una risposta
se il pagamento è 2/3/4 cent.Se
anche una sola risposta è
accettabile non c’è nessun
incentivo a pagare più di 2cent.

28. Esperimento 3 – affidabilità e qualità
 Focus sulla distribuzione del
lavoro tra le persone e la
qualità.
 (8)mostra # di HITs fatti da
ogni persona e il # di errori
commessi. La distribuzione
è asimmetrica e conferma
gli studi che dicono che il
richiedente acquisisce una
comunity di lavoratori che
si specializzano nei compiti
proposti. Possibilità di
creare delle communità
 La percentuale di errori non
migliora con l’aumentare
dei HIT eseguiti.

29. Queries complesse
 3 esperimenti con interrogazioni che
non possono essere fatte a DB
tradizionali

30. 1)
 Tabella con 2 attributi
(company name, headquarter
address) popolata con 100
aziende.
 SELECT name FROM company
WHERE name ~=“[a non-
unifrom name of the
company]”
 (9) 4 diverse istanze. Ogni
HIT mette a confronto 10
nomi di società con uno dei 4
nomi completi. Ogni HIT
aveva 3 compiti e la
ricompensa era di 1
cent./HIT. In tutti e 4 i casi la
maggioranza ha prodotto la
risposta corretta, ma solo in
un caso c’è stata l’unanimità.
Il tempo totale per
completare i 40 HITs (120
compiti) è stato di 39 minuiti.

31. 2) Ordinamento di immagini
 CREATE TABLE picture (p IMAGE, subject STRING); SELECT p FROM
picture WHERE subject = "Golden Gate Bridge“ ORDER BY
CROWDORDER(p,"Which picture visualizes better %subject");
 Abbiamo testato 30 soggetti e 8 foto per ogni soggetto. Ogni HIT prevedeva il
confronto di 4 coppie di foto. Questa classificazione è stata fatta con 210 HITs
ognuno con 3 compiti. 68 minuti per completare l’esperimento.
 (10) mostra il numero di persone che hanno votato, il ranking della foto in base
al voto di maggioranza e il ranking in base al voto di 6 esperti.

32. 3) Join tra Professor e Departments
 In questo esperimento vengono confrontati 2 modalità di
esecuzione per un’operazione di join.
 SELECT p.name, p.email, d.name,d.phone FROM
Professor p, Department d WHERE p.department =
d.name AND p.university = d.university AND p.name =
“[name of a professor]”;
 1) prima vengono richieste le informazioni per il professore e
poi per il dipartimento a cui è associato facendo così il
join(3d) – 206 minuti, $ 0.99
 2) chiedere per il professore e il dipartimento nello stesso
momento usando l’interfaccia (2e) – 173 minuti $ 0.75
 Le 2 diverse procedure sono state simili nei tempi di
esecuzione e nei costi ma significativamente diversi nella
qualità, con il secondo sono stati forniti risultati sbagliati per
tutti i numeri di dipartimento i soggetti infatti ha fornito il #
di tel. del professore invece che quello del dipartimento.

33. Osservazioni
 Gli esperimenti: 25817 compiti eseguiti da 718
diversi lavoratori.
1. La risorsa “folla” implica memoria a lungo
termine che può influenzare le performace. Le
persone e i richiedenti possono tenere traccia
dei rispettivi comportamenti e questo influenza
le relazioni future.
2. La progettazione delle interfacce e la precisione
delle istruzioni sono importanti
3. I risultati sperimentali mostrano la complessità e
le nuove sfide che si presentano per
l’elaborazione delle query tramite
crowdsourcing.

34. Conclusioni
 Gli esperimenti effettuati con CrowdDB e AMT
dimostrano che gli input delle persone possono essere
sfruttati per estendere notevolmente le funzionalità del
SQL
 La qualità è fortemente influenzata dalle motivazioni e
capacità delle persone.
 Ci sono dei parametri chiavi per la progettazione:
 Ricompensa
 # di compiti per HIT
 È importante creare una comunity di lavoratori e dare
loro ricompensa adeguata o un feedback adeguato.
 Lavoro futuro:
 Migliorare il controllo sulla qualità delle risposte
 Tecniche di ottimizzazione adattiva

35. Fine
La combinazione di input umano con
database ad alte prestazioni non solo
estende la gamma dei database systems,
ma che permette nuove applicazioni