TL,DR; Hasil dapat dilihat di sini.
Saya sering menyunting di Wikipedia. Di sana, saya bercita-cita bisa memiliki daftar artikel yang mendesak untuk dikerjakan (dibuat atau dikembangkan). Alasannya cukup sederhana, penyunting bisa melihat daftar ini dan mengetahui artikel apa saja yang berkekurangan, dan itu membantu memutuskan cara paling efisien memperbaikinya. Sebagai contoh, nantinya dari daftar ini kita bisa melihat, cakupan artikel bertopik statistika masih sangat minim sampai sekarang (November 2024).
Beberapa penyunting mungkin sedikit jengkel membaca paragraf di atas, karena saya tidak menyampaikan alasan semua kekurangan itu terjadi. Untuk artikel bertopik matematika, ini bisa disebabkan karena minimnya penyunting yang bisa mengelola, tidak ada patokan kepenulisan teks matematika bahasa Indonesia, termasuk di dalamnya penggunaan istilah (ada yang pakai istilah Inggris, merumuskan sendiri padanan Indonesianya, mengikuti istilah di lingkungan kampus masing-masing, atau berpatok pada Glosarium Pusat Bahasa), isi konten yang "tidak tertolong" (karena vandalisme besar-besaran, terjemahan mesin dari versi Inggris) dan menciutkan nyali penyunting baru, penyunting yang pergi karena burn-out, dan semua kegilaan yang terjadi di antaranya. Itu cerita yang berat dan butuh tempatnya tersendiri.
Baik, kembali ke masalah membuat daftar. Sekitar dua tahun yang lalu, saya mencoba melakukannya dengan membuat Google Sheet. Namun eksekusi ide itu terlalu rumit… terutama karena saya tidak tahu apa yang saya lakukan. Nah, karena saya punya waktu senggang, dan karena ada teman yang sedang bergulat memroses data Wikipedia, saya melihat sekarang adalah waktu untuk tuntas mengerjakannya, sekali dan untuk selama-lamanya. Namun karena saya masih merevisi tulisan ini lima bulan bahkan setelah diterbitkan, masalah ini ternyata lebih sulit dari dugaan saya.
Konten tulisan ini saya bagi menjadi beberapa bagian: dimulai dari menyusun daftar artikel, lalu mendapatkan aspek-aspek yang menentukan "mendesaknya" artikel, kemudian cara mengurutkannya, dan hasil yang didapatkan. Saya mengakhiri dengan memberi saran bagi mereka yang ingin mengembangkan proses yang saya kerjakan, dan info-info yang saya dapatkan selagi mengerjakannya.
Menyusun daftar artikel
Sebelum mengurutkan artikel berdasarkan tingkat mendesaknya, kita terlebih dahulu harus punya daftar semua (judul artikel) konsep matematika yang ada di Wikipedia. Untungnya di versi Wikipedia tertua dan terbesar, Wikipedia bahasa Inggris, ada komunitas WikiProject Mathematics (WP:MATH) yang sejak tahun 2002-an mengelola apapun terkait artikel matematika di Wikipedia Bahasa Inggris. Mereka telah membuat daftar -- yang totalnya saat saya menulis ini -- lebih dari 28,000 artikel bertopik matematika. Daftar ini bisa didapatkan dengan menggunakan kueri SQL, yang dibahas pada bagian selanjutnya.
Suatu artikel dapat memiliki beberapa topik sekaligus. Di daftar yang WP:MATH buat, ada artikel tokoh-tokoh matematikawan; contohnya Euler dan Dantzig. Karena saya tidak menganggap artikel seperti itu sebagai "konsep matematika", karena artikel tokoh juga merupakan fokus dari WikiProject Biography (ProyekWiki Biografi di versi komunitas Wikipedia Indonesia), saya tidak menyertakannya di daftar saya, agar menghasilkan "daftar artikel matematika" yang lebih sesuai dengan ekspektasi (saya).
Menentukan aspek
Baik, saat ini kita telah mendapatkan daftar artikel bertopik matematika; ya… secara teknis kita baru mengetahui daftar itu ada, kita belum mendapatkannya, tapi tetap, sshhh. Selanjutnya kita butuh beberapa aspek dari setiap artikel untuk menentukan prioritasnya; hal-hal seperti ukuran bita artikel. Untungnya, Wikipedia menyimpan data dalam bentuk pangkalan data (database) SQL publik, lengkap dengan dokumentasi susunan tabel-tabelnya. Untuk menjalankan kueri-kueri SQL di (replika) pangkalan data tersebut, Wikimedia (induk dari Wikipedia) menyediakan situs Quarry yang bisa dipakai.
Ada banyak kolom yang tersebar di banyak tabel, kita bisa membuat aspek seperti "banyaknya penyunting setiap artikel", "banyaknya artikel penting yang mengarah ke artikel ini", dan "waktu terakhir artikel disunting". Satu-satunya batasan adalah kreativitas… dan kemampuan SQL juga daya pemrosesan server Quarry, malangnya. Khususnya karena dua batasan terakhir tadi, saya memutuskan menggunakan beberapa aspek berikut:
Padanan judul artikel versi Inggris dan Indonesia; karena ada banyak artikel yang belum ada versi Indonesianya.
Ukuran bita artikel versi Inggris dan Indonesia. Ini nanti digunakan untuk mendapatkan selisih dan rasio selisih ukuran keduanya. Tentunya kita mau berfokus pada artikel dengan selisih yang besar (contoh, selisih 80 kilobita), dan pada artikel dengan rasio selisih yang besar (contoh, versi Indonesianya 90% lebih kecil daripada versi Inggris).
Penilaian kategori dan prioritas artikel versi Inggris. Dalam rangka mengelola artikel, WP:MATH akan menambahkan suatu templat penilaian ke setiap halaman diskusi setiap artikel. Templat ini kemudian menyertakan artikel ke dalam dua kelompok kategori, berdasarkan prioritas dan kualitas. Contoh kategori itu adalah
Top-prioritydanFA-Class(featured article), mengartikan artikel yang bersangkutan merupakan artikel sangat penting dan punya kualitas konten terbaik sampai bisa tampil (featured) ke halaman beranda Wikipedia. Perbaikan artikelTop-priorityseharusnya lebih diutamakan ketimbangLow-priority, kecuali, tentunya, kalau konten di versi Indonesia lebih lengkap (dilihat dari ukuran halamannya).Banyaknya artikel lain yang merujuk ke (inlinks), dan yang dirujuk oleh (outlinks), masing-masing artikel di versi Inggris. Sebagai ilustrasi, kalau ada banyak artikel yang menyebut konsep X ketimbang yang menyebut konsep Y, artikel tentang X seharusnya lebih penting ketimbang Y. Begitu pula sebaliknya, kalau artikel X lebih banyak menyebut konsep-konsep lain ketimbang artikel Y, artikel tentang X seharusnya lebih penting ketimbang Y. Anggaplah ini versi buruk dari algoritma PageRank (versi baiknya tidak bisa dibuat tanpa membuat server Quarry down).
Implementasi
Nah, setelah beberapa hari belajar, berpikir, men-debug, akhirnya saya menulis kueri yang Anda dapat baca di Quarry#84057 dan Quarry#84037. Saya menulis dua kueri terpisah, karena Wikipedia tidak lagi dapat menjalankan kueri yang menggunakan dua basis data berbeda. Malangnya, ini menghasilkan masalah baru: artikel matematika di versi Indonesia yang tidak diberi templat penilaian, tidak akan memiliki data ukuran halaman. Ini menjadi akhir dari perjalanan SQL, dan kita terpaksa turun tangan mengerjakan secara manual.
Wikipedia juga menerbitkan dumps/snapshots data Wikipedia. Kekurangannya, ini hanya diperbarui sekali (atau dua kali) setiap bulannya, tapi lebih baik daripada tidak ada sama sekali. Untuk kasus ini, kita perlu mengunduh dumps idwiki-<DATE>-page.sql.gz. Menggunakan mwsql, saya mengubah berkas SQL menjadi CSV yang hanya berisi kolom page_title dan page_len; itupun yang berfokus ke artikel non-pengalihan di ruang nama Utama.
Aspek total kunjungan
Halo dari kekavigi di masa depan. Ada satu aspek yang menurut saya juga penting: banyaknya total kunjungan ke artikel tersebut di versi Inggris. Pertimbangannya, artikel yang banyak dibaca tentunya penting untuk ditingkatkan/dijaga kualitasnya. Saya tidak memakai total kunjungan di versi Indonesia karena: untuk tujuan saya kurang lengkap, dapat ditaksir oleh versi bahasa Inggris, dan menghemat proses pengerjaan. Untungnya lagi, Wikimedia juga telah menerbitkan data kunjungan yang sesuai dengan kebutuhan kita ini.
Wikimedia menyediakan dua jenis data kunjungan: harian dan bulanan. Untuk menghemat tenaga dan waktu, saya menggunakan data bulanan selama satu tahun kebelakang. Walau terlihat kecil (sekian gigabita saja), ukuran decompress dari setiap data bulanan bisa mencapai lebih dari 20GB. Karena bentuk data, daya proses CPU, dan pikiran yang suntuk, saya menggunakan bash:
# download data kunjungan 12 bulan kebelakang
aria2c -x 16 -s 16 -c -i list-to-downloads.txt \
--auto-file-renaming=false \
--retry-wait=600
# Lalu decompress semuanya, ini bisa dilakukan
# karena saya punya banyak memori SSD yang kosong :)
ls *.bz2 | parallel "pbzip2 -d"
for file in pageviews*; do
# Ekstrak hanya versi "id.wikipedia" dan "en.wikipedia" saja
for wiki in 'id' 'en'; do
echo "processing $wiki-$file";
# untuk menyingkat waktu, paralelkan proses ekstraksi
# kita hanya butuh kolom ke-2 (title) dan ke-5 (count)
# trim digunakan untuk menggabungkan count suatu title
parallel -a $file --block 64M --keep-order --pipe-part \
"grep ^$wiki\\.wikipedia | awk '{print \$2,\$5}' | python trim.py" > "tmp";
# pastikan tidak ada data yang tidak ter-trim akibat parallel
python trim.py < "tmp" > "trimmed-$wiki-$file";
# hilangkan ini jika ingin menyimpan data mentah
rm $file
done;
done;
dengan isi kode Python (TODO: sebenarnya bisa lebih cepat ~60% kalau diubah ke Rust):
from sys import stdin
title, count = None, None
for row in stdin:
t, c= row[:-1].split(' ')
c = int(c)
if t!=title:
if title:
print(f'{title} {count}')
title, count = t, c
else:
count += c
Hasil sementara
Setelah semua kode-kode diatas dijalankan, kita dapat memroses dan menggabungkannya menjadi satu tabel. Kolom-kolom di tabel ini adalah:
title_en, judul artikel dalam bahasa Inggris,title_id, judul artikel dalam bahasa Indonesia (kalau ada),priority(), penilaian prioritas di enwiki,quality(), hasil penilaian kualitas,size_en(), ukuran artikel,size_diff(), selisih ukuran halaman dengan versi idwiki (size_en - size_id),size_ratio(), rasio selisih ukuran halaman dengan versi idwiki (1 - size_id/size_en),talk_length(), ukuran halaman pembicaraannya,total_lang(), banyak padanan di Wikipedia bahasa lainnya,total_inlink(), banyak halaman yang merujuk ke artikel,total_outlink(), banyak halaman yang dirujuk artikel,pageview_en(), banyak total kunjungan halaman di versi enwiki, danpageview_id(), banyak total kunjungan halaman di versi idwiki.
Mengurutkan artikel
Di tahap ini, kita perlu berpikir bagaimana mengurutkan artikel berdasarkan nilai aspek-aspek yang sudah didapatkan. Kita ingin mencari pengurutan artikel yang mempertimbangkan banyak aspek: apakah seharusnya kita lebih berfokus pada artikel yang sering dirujuk, atau artikel yang kontennya banyak, atau artikel yang punya padanan di banyak bahasa, atau yang kualitasnya bagus, atau apa? Bagaimana kalau kualitasnya kurang tapi lagi trending dibaca? Aroma multiobjektif dari masalah mengingatkan pada skripsi saya tentang penerapan pemrograman tujuan (goal programming, GP). GP adalah salah satu metode dalam optimisasi multiobjektif, yang bertujuan untuk mencari solusi ~~optimal~~ memuaskan dari masalah yang perlu mempertimbangkan banyak objektif/aspek.
Hal yang menyenangkan dari GP adalah kita hanya perlu merancang suatu "fungsi objektif" yang membuat pengambil keputusan (dalam kasus ini saya) puas, ketimbang mencari fungsi yang optimal tapi kemungkinan besar sulit untuk dimaknai (kenapa rumusnya begitu? entahlah). Karena saya yang mengambil keputusan, daftar yang dihasilkan mungkin tidak memuaskan beberapa orang. Tapi bagi orang lain yang punya cara pemrioritasan yang sama dengan saya, harapannya daftar akan sesuai ekspektasi mereka.
Sekarang, tentang fungsi skor (fungsi objektif) yang ingin saya buat:
- Saya tidak terlalu peduli perbedaan antara artikel yang posisi peringkatnya bersebelahan (misal peringkat 1 dan 2). Namun saya berharap, sebagai contoh ilustrasi, semua artikel di peringkat 50 teratas, pantas dianggap lebih penting, ketimbang artikel di peringkat 500-600, dan pantas dianggap jauh lebih penting, daripada artikel peringkat 5000-6000.
- Secara umum, saya punya preferensi aspek berikut dalam mengurutkan artikel:
size_ratio>size_diff>priority>quality>total_lang>pageview_en>total_inlink>talk_length>total_outlink - Preferensi ini tidak tegas, walau
size_diff>quality, ada kalanya artikel kualitas tinggi lebih mendesak untuk dikembangkan ketimbang yang selisihnya lebih banyak. Walauquality>pageview_en, ada kalanya artikel trending lebih mendesak ketimbang yang kualitasnya bagus.
Dari syarat-syarat tersebut dan menggunakan konsep GP, saya memilih fungsi skor berikut:
Fungsi itu tidak dibuat dengan rigor karena saya hanya melakukan ini untuk menghabiskan waktu senggang. Berikut beberapa penjelasan tambahan. Setiap variabel di rumus tersebut dinormalisasi agar berada di rentang nilai . Untuk mengubah kolom priority menjadi bernilai angka, kita tetapkan nilai Top-priority sebagai , lalu menurun secara berurut, sampai ke NA-priority dan Unknown-priority yang keduanya diberi nilai . Hal yang serupa dilakukan untuk kolom quality, dengan nilai FA-Class dan FL-Class diganti menjadi (karena keduanya sama-sama Featured), lalu menurun berurut, sampai ke Stub yang kita beri nilai . Ini menyisakan artikel dengan kualitas List, Disambig, Redirect, dan Unassessed, yang saya beri skor , , , dan ; karena menurut saya pribadi sebenarnya tidak penting in the grand scheme of things.
Untuk variabel dan , saya menggunakan normalisasi berikut:
Sedangkan untuk variabel lainnya, saya memilih menggunakan nilai karena rentang nilainya yang cukup besar. Fungsi normalisasi di atas selanjutnya diterapkan ke variabel-variabel ini.
Hasil
Anda dapat melihat daftar "artikel paling mendesak" dalam bentuk halaman HTML di sini (ukuran sekitar tujuh megabita uncompressed) Melihat sekilas isi tabel tersebut, saya menemukan banyak sekali konsep penting, terutama terkait statistika, yang belum dibuat di WBI. Whoa. Kita benar-benar dapat melihat realita yang terjadi, mungkin sambil terkejut/terheran "Oh artikel itu belum ada di WBI?".
Oiya, ada baiknya saya juga menyampaikan kekurangan dari daftar ini. Jika ada artikel (baik versi enwiki atau idwiki) yang dialihkan ke judul baru, total pageview selama satu tahun hampir pasti berkurang drastis, menyebabkan peringkat artikel ikut turun dengan tajam. Selain itu, karena kita tidak melakukan analisis kebahasaan ke setiap konten artikel di idwiki, daftar ini tidak dapat memprioritaskan perbaikan artikel idwiki yang seluruhnya hasil terjemahan buruk mesin.
Saran dan info
- Proses yang saya lakukan ini dapat mudah ditingkatkan (entah dengan mengubah aspek maupun fungsi skor). Ini bisa berguna untuk proyek-proyek Wiki lainnya; paling mudah kalau padanan komunitas versi Inggrisnya menggunakan WikiProject banner untuk mencatat artikel-artikel.
- Fasilitas PAWS dapat mempermudah seluruh proses membuat daftar ini, karena semua kode dijalankan di server Wikimedia, bukan perangkat pribadi Anda.
- Jika merasa mumpuni bahasa SQL, Anda membuat kueri yang "memecah"
total_inlink, agar bisa mendapatkan banyaknya inlink yang datang dari artikel dengan prioritas/kualitas tertentu. Jika ini bisa dilakukan, Anda dapat membuat hampiran algoritma PageRank yang pernah dipakai Google dalam mengurutkan hasil pencarian. - Wikimedia juga sedang melakukan riset penelitian terkait pemrioritasan artikel dengan fokus pada sistem rekomendasi. Walaupun berbeda haluan, ada banyak irisan submasalah yang juga dijumpai, seperti cara mengukur tingkat kepentingan suatu artikel.
Akhir kata semoga apa yang saya kerjakan ini, dapat digunakan untuk mempermudah mengembangkan artikel bertopik matematika di Wikipedia Bahasa Indonesia. :)
Tambahan: artikel ini saya sertakan di kolom diskusi Warung Kopi Wikipedia ini#Artikel_matematika_apa_yang_mendesak_perlu_ada%3F). Jika ingin berdiskusi, ada baiknya ditulis disana agar para penyunting lain juga dapat melihat pendapat / membantu mengembangkan ide Anda.