[rojak-api] Query untuk scoring sentiment

[bobbypriam]

Berdasarkan skema data yang sudah ada, kita harus melakukan query untuk mendapatkan skor sentimen yang dibutuhkan.

Skor yang kita butuhkan:

• Given seorang kandidat, kita mau dapet overall sentimentnya
• Given seorang kandidat, kita mau dapet list media dan sentiment dari tiap media terhadap kandidat tersebut
• Given sebuah pasangan kandidat, kita mau dapet overall sentimentnya
• Given sebuah pasangan kandidat, kita mau dapet list media dan sentiment dari tiap media terhadap kandidat tersebut
• Given sebuah berita, kita mau dapet kandidat yang disebut dan sentimentnya
• Given sebuah media, kita mau dapet list pasangan dan sentiment dari media terhadap tiap pasangan
• Given sebuah media, kita mau dapet list kandidat dan sentiment dari media terhadap tiap kandidat

Untuk bagaimana bentuk hasil yang diharapkan, bisa dilihat pada spesifikasi Rojak API.

Issue ini untuk menampung saran dan review dari query-query yang akan digunakan, dengan harapan skor yang keluar nantinya sesuai dengan data. Kalau ada yang punya ide bagaimana bentuk querynya untuk poin-poin di atas, silakan ungkapkan di sini.

[pyk]

Untuk masalah sentimen dan skornya ini mungkin perlu sedikit klarifikasi sih:

Rojak menyimpan data ini:

1. Sentiment ke suatu kandidat (sentiment positif dan negatif)
2. Confident score dari rojak tentang sentiment itu (keyakinan rojak kalau berita itu bersentimen positif ke A misalnya)

catatannya: skor disini bukan menggambarkan seberapa negatif atau seberapa positif.

Terus untuk:

Given seorang kandidat, kita mau dapet overall sentimentnya

Given sebuah pasangan kandidat, kita mau dapet overall sentimentnya

Maksutnya overall sentiment yang gimana ya? apa list of overall sentiment dari media?

[pyk]

Untuk fokus ke skor sentimen, dibahas di #138

[bobbypriam]

Ah, I see, berarti saya agak salah nangkep maksud dari score itu apa. Saya selama ini asumsi (should have known better, sorry) score sentiment dari suatu berita melambangkan berita itu "n% condong ke kandidat A". Kalau dengan reply @pyk tadi, berarti score itu adalah "seberapa besar keyakinan rojak-analyzer bahwa berita tersebut condong ke kandidat A" ya?

I have a feeling kalo beberapa endpoint terkait sentiment jadi ga relevan.

Kalau emang begitu, apakah tetep make sense kalo kita nge-query agregasinya? Gimana kita bisa menjawab pertanyaan "media mana saja yang condong ke kandidat A?" atau "gimana stance media-media terhadap kandidat B?"? Apakah berarti cukup dengan counting? Misalnya:

case sentiment(news, candidate_a) of
  positive -> 1
  neutral -> 0
  negative -> -1
end

tanpa memperhitungkan confidence score?

[pyk]

@bobbypriambodo yup bener, cukup dengan counting. Bisa juga percentage, misal
overall sentiment positif kandidat A di media X:

jumlah berita bersentiment positif kandidat A di media X
--------------------------------------------------------
        total berita di media X yg rojak pantau

[bobbypriam]

@pyk 👍 Oke, kayaknya dari endpoint sendiri ga perlu ada yang berubah sih kalau gitu. Saya ikutin thread #138 dulu aja deh.

[bobbypriam]

Saya sedang mengimplementasi embedding sentiment di mentions pada news. Sudah bekerja, tapi querynya agak lama ya (~200ms). Berikut hasil tesnya:

# List with mentions /news?embed[]=mentions
[debug] QUERY OK source="news" db=207.1ms decode=0.4ms
SELECT n0.`id`, n0.`title`, n0.`url`, n0.`author_name`, n0.`media_id`, n0.`inserted_at`, n0.`updated_at`, n1.`id`, n1.`score`, n1.`news_id`, n1.`sentiment_id`, n1.`inserted_at`, n1.`updated_at`, s2.`id`, s2.`name`, s2.`candidate_id`, s2.`inserted_at`, s2.`updated_at`, c3.`id`, c3.`full_name`, c3.`alias_name`, c3.`place_of_birth`, c3.`date_of_birth`, c3.`religion`, c3.`website_url`, c3.`photo_url`, c3.`fbpage_username`, c3.`instagram_username`, c3.`twitter_username`, c3.`inserted_at`, c3.`updated_at`
FROM `news` AS n0
INNER JOIN `news_sentiment` AS n1 ON n1.`news_id` = n0.`id`
INNER JOIN `sentiment` AS s2 ON s2.`id` = n1.`sentiment_id`
INNER JOIN `candidate` AS c3 ON c3.`id` = s2.`candidate_id`
ORDER BY n0.`id` DESC LIMIT ? OFFSET ? [10, 0]
[info] Sent 200 in 209ms

# List without mentions /news
[debug] QUERY OK source="news" db=1.1ms decode=0.2ms queue=0.1ms
SELECT n0.`id`, n0.`title`, n0.`url`, n0.`author_name`, n0.`media_id`, n0.`inserted_at`, n0.`updated_at`
FROM `news` AS n0
ORDER BY n0.`id` DESC LIMIT ? OFFSET ? [10, 0]
[info] Sent 200 in 2ms

# ID with mentions /news/1?embed[]=mentions
[debug] QUERY OK source="news" db=1.7ms decode=0.2ms queue=0.1ms
SELECT n0.`id`, n0.`title`, n0.`url`, n0.`author_name`, n0.`media_id`, n0.`inserted_at`, n0.`updated_at`, n1.`id`, n1.`score`, n1.`news_id`, n1.`sentiment_id`, n1.`inserted_at`, n1.`updated_at`, s2.`id`, s2.`name`, s2.`candidate_id`, s2.`inserted_at`, s2.`updated_at`, c3.`id`, c3.`full_name`, c3.`alias_name`, c3.`place_of_birth`, c3.`date_of_birth`, c3.`religion`, c3.`website_url`, c3.`photo_url`, c3.`fbpage_username`, c3.`instagram_username`, c3.`twitter_username`, c3.`inserted_at`, c3.`updated_at`
FROM `news` AS n0
INNER JOIN `news_sentiment` AS n1 ON n1.`news_id` = n0.`id`
INNER JOIN `sentiment` AS s2 ON s2.`id` = n1.`sentiment_id`
INNER JOIN `candidate` AS c3 ON c3.`id` = s2.`candidate_id`
WHERE (n0.`id` = ?) [1]
[info] Sent 200 in 2ms

# ID without mentions /news/1
[debug] QUERY OK source="news" db=1.9ms queue=0.1ms
SELECT n0.`id`, n0.`title`, n0.`url`, n0.`author_name`, n0.`media_id`, n0.`inserted_at`, n0.`updated_at`
FROM `news` AS n0
WHERE (n0.`id` = ?) [1]
[info] Sent 200 in 2ms

Summary:

1. Query list of news dengan mention memakan waktu 209ms dengan 207.1ms dihabiskan di query, dibandingkan dengan list tanpa mention memakan waktu hanya 2ms dengan waktu query 1.1ms
2. Query untuk sebuah news berdasarkan ID tidak berbeda signifikan dengan mengembed mentions atau tidak.
3. Lucunya, waktu respon list of news dengan mention relatif konstan terhadap berapa banyak data yang diambil (default 10, saya sudah mencoba dengan limit=1 dan limit=1000, waktu querynya sama, hanya berbeda pada waktu decode array yang besar; total response time dengan 1000 entry adalah 425ms). (Thought: kayaknya limit harus dikasih max ya biar ga exhausting resource)

Query yang tertera di atas digenerate oleh Ecto. Kira-kira querynya bisa lebih dioptimalkan lagi ga ya?