Last but Not Least Part -> Kesimpulan!

Kita seringkali menyepelekan bagian ini (*setidaknya itu yang kami pikirkan selama beberapa momen ke belakang saat membuat sebuah laporan, sampai akhirnya kami menemukan sentilan dalam proses pengerjaan Tugas Akhir ini). Mengapa? Karena biasanya fokus lebih ditujukan pada bagaimana konten utama, misal Implementasi agar menarik pembaca untuk memberitahu tampilan aplikasi yang ada. Namun ini tidak 100% berlaku untuk para Penguji. Alasannya simpel, karena mereka bisa jadi lebih paham mengenai apa yang akan kita implementasi. Selain itu, karena hal yang mereka ingin eksplor adalah bagaimana akhir dari TA yang kita kerjakan, apa yang sudah berhasil terimplementasi, dan apakah kita sadar dengan kekurangan dalam aplikasi kita (karena jika kita sadar, permasalahannya bisa jadi bukan di pemahaman kita, tapi pada manajemen waktu kita selama proses pengerjaan).

Beberapa dari kita terbiasa menuliskan judul bagian ini dengan 'KESIMPULAN dan SARAN'. Hentikan itu! Meskipun memang di dalamnya terdapat dua komponen tersebut, tapi standar yang berlaku (setidaknya di JTK), tuliskan saja apa yang menjadi inti, 'KESIMPULAN', biarkan 'SARAN' menjadi bagian pelengkap dari simpulan yang ada.

1. KESIMPULAN
   Kami sudah beberapa kali melakukan perubahan konteks kalimat dalam bagian ini. Lebih banyak disebabkan oleh ketidak-yakinan dengan apa yang HARUSNYA dituliskan disini. Tapi setelah melewati beberapa kali konsultasi dengan pembimbing, beberapa hal yang kami yakini perlu menjadi bagian dari KESIMPULAN adalah:
• Ringkas konsep utama dari sistem/aplikasi kita ke dalam beberapa kalimat. Tapi jangan pernah memperlihatkan kebiasaan COPY-PASTE yakni dengan meng-copy bagian dari bab2 di atas dan mem-paste nya ke KESIMPULAN. Yakini pembaca bahwa kita paham inti dari konsep aplikasi kita, ringkas dengan bahasa ilmiah.
•  Sampaikan secara KUANTITATIF, pencapaian tugas akhir kita. Jangan mengira2 dengan menggunakan kata 'sangat', 'lebih baik', dan lain2 tanpa ada data kuantitatif menyertainya. Misal, "Nilai tertinggi yang dicapai hampir mendekati 1, yaitu 0,92 yang menunjukkan bahwa tingkat relevansi ayat dengan kata kunci sangat tinggi." Jangan biarkan para Penguji melihat kelemahan kita dalam berkata2, hahaha.
  JUGA INGAT, jangan menyertakan kalimat2 seperti "... yang telah kami capai...", atau yang menyertakan keterangan pelaku. Itu menunjukkan kalau kita sedang CURHAT. Sekali lagi sampaikan dengan menggunakan bahasa ilmiah alias secara OBJEKTIF.
2. SARAN
   Bagian ini sangat penting untuk memberi harapan pengembangan atau perbaikan sistem yang telah kita buat. Sasaran yang memungkinkan biasanya adalah untuk para generasi penerus (*adik kelas, dst...). Karena bisa jadi aplikasi yang kita buat memang sudah sempurna, namun karena dibangun di atas J2SE, seiring perkembangan zaman, platform yang pada zaman kita merupakan yang paling WAH bisa saja tergeser, bahkan menjadi punah di zaman adik2 kelas kita kelak. Itu mengapa, bagian SARAN ini penting untuk memberitahu adik2 kita mengenai possibilities pengembangan aplikasi ke teknologi yang lebih baik. Misal: dalam kasus Sistem Temu Balik yang identik dengan pencarian dan rekomendasi, kami memberi salah satu saran seperti "Pengguna dapat memberikan  feedback  (misal berupa rating/skala kepuasan) terhadap hasil rekomendasi agar sistem mampu memberikan rekomendasi tidak hanya berdasarkan input."

Begitu yang dapat kami sampaikan. Pasti banyak kekurangan. Jika ada pengalaman yang dapat dibagi, tulis saja komentar di bawah. Akan sangat menyenangkan bisa berbagi dengan adik2 kita agar tidak mengulangi kesalahan yang sama. ^^

Pengujian???

Hal pertama yang harus diperhatikan pada bagian ini adalah menentukan Metodologi (ciee, bahasanya...) Pengujian apa yang akan digunakan. Dua contoh yang kami ketahui adalah Black Box dan White Box Testing. Secara singkat, Black Box Testing adalah testing yang dilakukan tanpa mementingkan proses yang dijalankan, sementara White Box adalah sebaliknya (gimana tuh? ngerti lah ya...). Kami menggunakan Black Box Testing, karena pada bagian Pengujian kami hanya ingin memperlihatkan bagaimana kesesuian antara input dan outputnya.

Selain itu, beberapa bagian yang -mungkin- penting ada dalam Bab ini adalah:

Perencanaan Pengujian

Pada bagian ini dilakukan perincian mengenai :

1. Pelaku Pengujian
2. Skenario Pengujian
   Pada bagian ini dijelaskan lagi per-poin bagian pengujian. Misal, dalam aplikasi kami, dibuat pembagian sbb:

• Preprocessing, untuk memastikan kata kunci yang akan digunakan sesuai dengan matriks yang ada (Case Folding dan Tokenizing, Filtering, Stemming);
• SVD, untuk memastikan perhitungan matriks term dan document sesuai;
• TF-IDF, untuk melakukan perhitungan bobot antara dokumen dan term;
• Perhitungan Cosine Similarity antara Query dengan Dokumen, untuk memastikan hasil pencarian sesuai dengan query yang dimasukkan.

Terlepas dari format bab Pengujian yang standar, kami ingin menegaskan bahwa pengujian ini bertujuan agar Implementasi yang sudah dilakukan teruji kebenarannya, dengan kata lain, meyakinkan pembaca (atau dalam hal ini yang terpenting adalah para Penguji TA kita) bahwa tiap komponen/fungsi/method yang membentuk sistem sudah menghasilkan output yang sesuai (ketika memang SALAH, muncul sebagai sesuatu yang SALAH, begitu juga sebaliknya, bukan berdasarkan kira2).
Yah, sekian dari pengalaman kami menggeluti bab Pengujian ini.. Semoga bermanfaat... ^^

Come to The Implementation

Menuju sidang nih, kudu cepet2 implementasi aplikasi. Satu hal yang mau saya bagi di sini adalah,,, meskipun sesi analisis dan desain HARUSnya sudah berakhir, namun kenyataannya tidak bisa se-ideal itu. Karena, ketika seminar 3, kita menyadari banyak sekali hal yang masih kurang, bisa itu lewat teguran penguji, melihat referensi TA temen2 lainnya, maupun dari pencerahan yang tiba2 datang begitu saja. Tapi ga perlu khawatir, selama kita masih menyadarinya sekarang, ga ada yang terlambat, mumpung belum sidang kan...
Di Implementasi (khususnya untuk si laporan) kita akan banyak sekali merujuk ke Bab Analisis dan Perancangan karena apa yang akan kita implementasi adalah apa2 yang sudah kita analisis dan kita rancang. Itu adalah HARUS! Jangan ngalor ngidul, okeh. Karena kelompok kami banyak sekali mendapat teguran atas kelalaian kami yang tak memperhatikan dengan teliti kedua bab tersebut dan para dosen penguji akan sangat memperhatikan hal2 tersebut.Yuk kita tilik satu persatu komponen Implementasi (ini versi pemahaman kami loh...)

1. Batasan Implementasi
   Ini adalah bab yang menjelaskan sampai mana kita akan mengimplementasi sistem yang sudah kita analisis dan rancang. Karena pada kenyataannya rata2 kita tak bisa mengimplementasi 100% sesuai dengan harapan kita. Ya, itu boleh2 saja, asalkan jelas kita beritakan di laporan.
2. Deployment Diagram + Penjelasan
   Ini adalah diagram yang akan menjelaskan di atas apa kita membangun sistem kita, dan di atas apa sistem kita akan berjalan, secara hardware maupun software. Misal, OS nya apa, package library nya apa, toolsnya apa, dst.
3. Implementasi Modul
   Dalam Bab Perancangan sudah kita rancang kira2 modul apa saja yang kita butuhkan. Nah, di sini kita akan secara transparan memberi tahu modul apa saja yang ingin diimplementasi, requirement apa saja yang terpenuhi olehnya, dan status keberadaannya dalam sistem (ada/tidak terimplementasi).
4. Implementasi Requirement
   Nah loh, apa pula ini??? Awalnya kami juga bingung, karena dosen penguji mengharuskan kami membuat suatu tabel yang dapat menginformasikan keterkaitan tujuan, analisis, dan requirement yang ada. Namun terlepas dari apa judulnya begini kurang lebih yang kami buat.
   
5. Implementasi Data
   Kalo yang ini, kita perlu memberi informasi status apakah tabel2 yang sudah dirancang tersebut diimplementasi atau tidak.
6. Implementasi UI
   Untuk membuktikan bahwa kita sudah mengimplementasi suatu sistem aplikasi, tentu perlu ada bukti kan? Nah, di sini perlu kita tampilkan seperti apa tayangan sekilas mengenai aplikasi kita. Tak perlu semua kemungkinan, hanya beberapa yang sekiranya menjadi andalan dan perlu/penting untuk disampaikan. Karena demo aplikasi pun nanti akan dilakukan.

 Itu sekilas dari apa yang harus kita perhatikan dari segi LAPORAN. Namun dalam implementasi, tentunya yang paling penting untuk diperhatikan adalah HOW TO DO IT? Ya, ini tak mudah, karena kita bahkan harus mulai melakukannya saat masa analisis, karena kita perlu mempelajari terlebih dahulu sistem yang akan kita kembangkan. Hal terpenting yang kami rasakan adalah:

• Perlu kembali me-refresh/mengenal pengetahuan teknis dari (sintaks2, how to use, dll) dari tools yang akan kita gunakan.
• Perlu membuat kasus2 kecil, terkait dengan modul2 yang akan kita gunakan. Jangan langsung berpikir HOW TO FINISH OUR PROGRAM, tapi pikirkan HOW TO SOLVE OUR PROBLEM. Jadi kan kita bagi2 sistem kita ke dalam beberapa modul, nah kita test masing2 modul tersebut dengan percobaaan2 kecil.
• Pembagian tugas per anggota harus jelas. Minimal meskipun tugas perorangnya tidak spesifik, tapi harus jelas pertanggungjawaban masing2nya. Misal, yang bertanggungjawab terhadap integrasi laporan, integrasi code, database, dll.
• Ketika dirasa harapan pencapaian sistem tidak bisa 100%, rancang kembali strategi untuk 'menurunkan' idealisme namun poin tujuan di awal tetap dapat dicapai.

Intinya sih, semuanya harus terstruktur, bila perlu gunakan cara SVN, supaya jelas versioning nya. Jaga harmonisasi kelompok, jangan biarkan egoisme meruntuhkan keutuhan kelompok kita. Semangat implementasi !!! ^^

Terlalu lama ya...? Now, Let's Designing!

Maaf ya, sekian lama kami melaksanakan TA, belum melaporkan progress lagi, hehehe. Kami sudah sampai di tahap pra-Seminar 3. Di Seminar 3 ini, kami dituntut untuk menghasilkan dokumen sampai ke perancangan dan sudah bisa  men-demo-kan aplikasi yang akan dibuat, sehingga Dosen Penguji sudah bisa melihat kemungkinan realisasi aplikasi yang telah direncanakan.
Dalam dokumen Bab Perancangan, yang biasanya dibahas adalah :

1. Rancangan Database yang biasanya direpresentasikan oleh ER (Entity-Relationship) Diagram, CDM (Conceptual Data Model), lalu PDM (Physical Data Model). Adapun dari ERD, kita harus menjelaskan masing-masing tabel yang akan kita gunakan pada sistem aplikasi kita.
2. Model Perilaku Sistem yang direpresentasikan oleh use case diagram + skenario nya. Dan yang jangan dilupakan juga adalah penjelasan aktor yang tertera pada use case.
3. Masih berlanjut dari poin 2, lalu masuk ke Sequence Diagram yang akan lebih menjelaskan alur pekerjaan tiap use case yang ada. Tiap komponen Sequence Diagram akan mewakili kemungkinan class-class apa saja yang akan kita gunakan.
4. Seperti yang diungkapkan di atas, setelah tergambar dari sequence diagram, maka buat Package Diagram dan Class Diagram nya. Package Diagram merupakan penggambaran pengelompokan class agar lebih terstruktur, misal komponen class yang mengurusi database, kalkulasi, dll dipisah dalam package yang berbeda. Sedangkan class diagram sendiri adalah untuk menggambarkan class-class yang akan kita gunakan, juga keterkaitannya dengan class lain (tergambar juga dalam sequence diagram).
5. Dalam class, pasti berisi modul-modul yang menunjang fungsionalitas dari class tersebut, sehingga dibutuhkan Tabel Deskripsi Modul. Jika modul yang digunakan sangat banyak, misal dalam tiap class bisa mencapai 10 modul, maka pilih saja yang utama dan sekiranya penting untuk diketahui pembaca laporan, misal jika kita berdomainkan 'Sistem Temu Balik Informasi', maka sertakan modul yang utamanya, seperti misal searchByInput, cosineSimilarity, SVD, LSACalculation, dll.
6. Dalam modul juga, pasti kita akan bertemu dengan variabel-variabel atau record-record yang akan menjadi parameter dan diproses dalam modul yang kita buat, nah maka dari itu dibutuhkan Perancangan Struktur Data. Di sini akan dijelaskan mengenai nama variabel yang kita gunakan, deskripsinya dan bagaimana struktur datanya.
7. Bagian paling penting bagi pembaca adalah Rancangan User Interface, sehingga terlihat bagaimana hasil tampilan sistem aplikasi yang akan kita buat. Ini bisa dibuat dengan menggunakan salah satu tools mock-up (*my fav ^^) yaitu Balsamiq Mockups. Tapi, selain gambar UI nya, juga harus ada penjelasan mengenai masing-masing komponen yang ada di situ, misal jika ada tombol A, jelaskan apa guna tombol tersebut, bagaimana respon sistem setelah itu, juga modul-modul yang terkait.

Yah, sekian penjelasan yang akan kami lakukan pada sesi Perancangan ini, semoga membantu... ^^

Preprocessing

Preprocessing merupakan tahapan awal dalam mengolah data input sebelum memasuki proses tahapan utama dari metode Latent Semantic Analysis (LSA). Preprocessing text dilakukan untuk tujuan penyeragaman dan kemudahan pembacaan serta proses LSA selanjutnya (Aji P., Baizal SSi. and Firdaus S.T., 2011). Preprocessing terdiri dari beberapa tahapan. Adapun tahapan preprocessing berdasarkan (Triawati, 2009) , yaitu: case folding, tokenizing / parsing, filtering, stemming. Berikut penjelasan empat tahapan dalam proses preprocessing adalah sebagai berikut.

1.                       Case Folding

Case folding merupakan tahapan yang mengubah semua huruf dalam dokumen menjadi huruf kecil. Hanya huruf ‘a’ sampai dengan ‘z’ yang diterima. Karakter selain huruf dihilangkan dan dianggap delimiter (pembatas)(Triawati, 2009).Contoh penggunaan case folding adalah sebagai berikut.

                  data input                                                    hasil case folding

Penjelasan:

Input	Output
Kalimat/kata input dari pengguna	Kalimat/kata input menjadi huruf kecil serta tanpa karakter lain selain karakter huruf ‘a-z’

2.               Tokenizing

Tahap tokenizing / parsing adalah tahap pemotongan string input berdasarkan tiap kata yang menyusunnya(Triawati, 2009). Selain itu, spasi digunakan untuk memisahkan antar kata tersebut.

                           data input                                      hasil tokenizing / parsing

Penjelasan:

Input	Output
Kalimat/kata input hasil dari proses case folding	Kumpulan kata

3.            Filtering

Tahap filtering adalah tahap mengambil kata - kata penting dari hasil tokenizing. Proses filtering dapat menggunakan algoritma stoplist (membuang kata yang kurang penting) atau wordlist (menyimpan kata penting). Stoplist / stopword adalah kata-kata yang tidak deskriptif yang dapat dibuang dalam pendekatan bag-of-words. Contoh stopword adalah “yang”, “dan”, “di”, “dari” dan lain – lain.(Triawati, 2009).

        

 

              data input                                                       hasil filtering

Penjelasan:

Input	Output
Kumpulan kata hasil dari proses tokenizing/parsing	Kumpulan term yang siap untuk diolah dengan proses svd

 

4.               Stemming

Stemming merupakan suatu proses yang terdapat dalam sistem IR yang mentransformasi kata-kata yang terdapat dalam suatu dokumen ke kata-kata akarnya (root word) dengan menggunakan aturan-aturan tertentu (Agusta, 2009). Stemming kebanyakan digunakan pada teks berbahasa inggris dikarenakan teks berbahasa inggris memiliki struktur imbuhan yang tetap dan mudah untuk diolah sementara stemming untuk proses bahasa Indonesia memiliki struktur imbuhan yang rumit / kompleks sehingga agak lebih susah untuk diolah.

Algoritma stemming untuk teks berbahasa Indonesia, diantaranya: Algortima Porter, Algoritma Nazief & Adriani. Berdasarkan hasil penelitian yang dilakukan(Agusta, 2009), kesimpulan dari perbandingan antara Algoritma Porter dengan Algoritma Nazief & Adriani, adalah:

1.              Proses stemming dokumen teks berbahasa Indonesia menggunakan Algoritma Porter membutuhkan waktu yang lebih singkat dibandingkan dengan stemming menggunakan Algoritma Nazief & Adriani.

2.              Proses stemming dokumen teks berbahasa Indonesia menggunakan Algoritma Porter memiliki prosentase keakuratan (presisi) lebih kecil dibandingkan dengan stemming menggunakan Algoritma Nazief & Adriani.

3.              Pada proses stemming menggunakan Algoritma Nazief & Adriani, kamus yang digunakan sangat mempengaruhi hasil stemming. Semakin lengkap kamus yang digunakan maka semakin akurat pula hasil stemming. Kamus yang digunakan mempengaruhi perhitungan presisi. Semakin lengkap kamus yang digunakan maka semakin akurat pula nilai presisinya. Contoh penggunaan stemming:

         

Goes to Seminar 2 - AnalysisDone-Oriented

Jangan pernah menyepelekan kata2 analisis. Ini yang sering menjadi batu sandungan ketika kita akan melanjutkan ke tahap berikutnya. Perancangan yang baik adalah yang sesuai dengan hasil analisis yang telah dilakukan, lantas bagaimana cara melakukan analisis yang baik dan benar?

Haha, gaya banget ya pernyataan di atas... :P
Berasa pakar gimana,,,gitu...
Engga ko, tenang aja, kami mau cari aman. Tiap kata di postingan ini hanya berdasarkan pengalaman saja alias ga ada referensi shahih. Tapi walau begitu, InsyaAllah akan bermanfaat ko terutama buat anak2 JTK POLBAN yang akan melaksanakan Tugas Akhir nya. Dont be too long! Check it out yo...

Setahu kami, komponen penting yang perlu ada dalam Bab Analisis adalah:

• Analisis terhadap sistem serupa / yang sudah pernah ada. Kalo udah pernah ada, kenapa perlu kita buat lagi? Buat apa dianalisis? Namanya juga manusia yang buat, semahir apapun, pasti ada aja kekurangannya, dan mungkin aja kita adalah salah satu yang tahu dan paham akan kekurangan tersebut dan mampu untuk memperbaikinya. Dan lagi, menurut salah satu pembimbing kami, Pak Jonner, "Ya, usahakan kalian tidak membuat aplikasi dari awal/yang sifatnya inovasi total." Tahu kenapa? Bukannya tidak boleh, ya, kalo waktunya memang memungkinkan, silakan saja. Karena menurut Dosen Senior kami, Pak Ridwan, "Ga usah bikin yang aneh2 lah. Saya yakin, kalian itu mampu, tapi waktunya kan cuma sebentar." Jadi inti yang saya tangkap adalah tak perlu 100% mengikuti idealisme dulu, perhatikan kemampuan dan waktu yang tersedia. Kalaupun kita mampu, perhatikan apakah teman2 kelompok kita juga mampu? *Ko jadi kesini ya? Tapi ketangkep kan ya, maksudnya gimana...
  
  Balik lagi deh, jadi yang disorot dari sistem yang sudah ada itu adalah bagaimana perilakunya (misal digambarkan dalam Use Case Diagram atau dideskripsikan via Use Case Skenario). Lalu buat evaluasinya, sehingga terlihat dimana peran sistem yang akan kita buat kelak.
  Jika terdapat aplikasi serupa lebih dari satu, lakukan perbandingan terhadap aplikasi2 tersebut. Tentukan parameter2 apa yang kira2 mampu menunjukkan perbedaan antara aplikasi2 tersebut. Misal parameter yang kami buat adalah sebagai berikut.

• Analisis hal-hal yang berkaitan dengan aplikasi. Misal, karena tugas akhir kami berhubungan dengan sistem temu balik informasi (*pencarian) ayat Alquran, maka kami perlu menganalisis bagaimana input yang sesuai, bagaimana proses preprocessing dan stemming dilakukan, dan lain2.
• Analisis requirement. Ini adalah bagian krusial dalam analisis karena akan menjembatani kita ke proses perancangan. Maksud analisis requirement adalah berdasarkan analisis yang telah kita lakukan di atas (terutama dari hasil analisis sistem yang telah ada/telah berjalan), bagaimana requirement 'ideal' yang perlu kita perhatikan dalam perancangan sistem kita kelak. Perlu diperhatikan, bahwa karena 'ideal' itulah, kemungkinan pada akhirnya kita tidak mengimplementasi seluruhnya adalah mungkin saja. Namun ke-ideal-an tersebut harus tetap dituliskan dalam rangka memberitahu pembaca bahwa kita memahami domain yang sedang kita garap.
  Pada bagian ini, kita akan bergelut dengan komponen SRS yaitu Use Case diagram juga skenario (ayo, perhatikan jelas2 saat dosen APPL sedang mengajar), juga tidak lupa menyertakan DEFINISI AKTOR sistem yang akan kita buat. Misal dalam sistem kami, Pengguna -> Aktor yang menggunakan aplikasi untuk mencari terjemahan ayat Alquran berdasarkan kata kunci yang di-inputkan, menelusuri ayat-ayat Alquran, memilih ayat sebagai ayat favorit.
  Selain itu juga perlu dibuat Requirement Fungsional dan Non-Fungsional, yang singkatnya, Fungsional itu berhubungan dengan analisis yang sudah kita buat dan metoda yang akan kita gunakan, sedangkan Non-Fungsional merupakan kebutuhan pendukung untuk melengkapi fungsi yang ada pada sistem.
• Bussiness Rules. Apaan tuh??? Maksudnya adalah aturan2 yang harus dipenuhi untuk dapat menjalankan proses yang berkaitan dengan sistem kita. Misal, "Sistem harus memberikan rekomendasi ayat berdasarkan 5 rating tertinggi" dan harus disertakan itu berkaitan dengan requirement yang mana.

Cukup sekian ya, sedikit arahan dalam membuat Bab Analisis. Ingat, konten bab ini akan sangat menentukan apakah kita memahami domain TA kita atau tidak. Maka persiapkan otak untuk menggali lebih dalam sebenarnya bagaimana sistem yang akan kita buat? Selamat menganalisis...

Pembagian Tugas Hari Ini

Pembagian Tugas Hari ini untuk kajian pustaka:
Target:  progress besok.

1. Ajeng: AlQuran Digital
2. Putri: Zekr
3. Teguh: Quran Terjemah

Selain itu, besok (Rabu. 21.3.2012) jam 16.00, bimbingan dengan Pa Jonner!!
Lalu, besok (Rabu. 21.3.2012)  mengirimkan SRS ke Bu Ida!!

Laporan Progress

Hanya sekedar mengingatkan.. 

Setiap hari senin, JANGAN LUPA mengirimkan progress hasil eksplorasi ke Pa Jonner, dengan di kirim via email ke jonnerh@yahoo.com, jn@jtk.polban.ac.id. Cuma aq ga tau ni,, hasil eksplorasi nya ada format apa ngga? nanti di konfirmasiin lagi ke Pa Jonner y!!

Selain itu, setiap hari senin, JANGAN LUPA JUGA mengirimkan progress laporan kelompok, di kirim via email ke id@jtk.polban.ac.id, idasuhartini@gmail.com!!

Ayo,, SEMANGAT TEMAN2!!!

Latent Semantic Analysis - Singular Value Decomposition

Mau sharing mengenai pemahaman LSA - SVD yang udah nempel di kepala, walau belum 100% paham pengimplementasiannya ke dalam coding... hehe, cekidot...

Latent Semantic Analysis (LSA) merupakan teknik matematika/statistika untuk mengekstraksi dan menyimpulkan hubungan kontekstual arti kata yang diaplikasikan pada bagian teks yang dibutuhkan (Landauer, Foltz and Laham, 1998). Pada LSA, dilakukan preprocessing yang salah satunya berfungsi sebagai penentu kumpulan term untuk direpresentasikan dalam sebuah matriks semantik dan kemudian diolah secara matematis menggunakan teknik aljabar linier Singular Value Decomposition (SVD), sehingga dalam hal ini, query dapat dibandingkan dengan hasil SVD untuk menghitung similaritas antara query-document (Baker, 2005). Selain itu, juga dilakukan representasi ke dalam bentuk matriks, sehingga dari hasil dekomposisi SVD, terdapat tiga jenis operasi perbandingan yang dapat dilakukan yaitu:

1. Membandingkan dua kata (terms)
2. Membandingkan dua dokumen (documents)
3. Membandingkan kata (terms) dengan dokumen (documents)

Berbeda dari dua operasi sebelumnya yang memerlukan penghitungan  cosine similarity, untuk membandingkan kata i dengan dokumen j dapat diketahui dari nilai cell(i,  j) dari matriks aproksimasi kata-dokumen yang didapat dari perhitungan SVD.

(Deerwester et al., 1990)

Gambar 1 - Representasi geometri 2 dimensi dari term dan dokumen pada analisis SVD

Pada gambar di atas, kumpulan term yang ada dipetakan keberadaannya ke tiap dokumen, sehingga didapatkan nilai keberadaan tiap term pada dokumen-dokumen yang ada, sehingga isu yang muncul adalah “seberapa dekat hubungan antara term i dengan dokumen j?”. Melalui standar informasi pendekatan sistem temu balik, untuk membandingkan dua baris, kolom, atau menguji cell digunakan matriks X, yang terdiri dari term pada dokumen (Deerwester et al., 1990). Namun kita menggunakan X^ yang merepresentasikan pola dari X dan nilainya mendekati X yang sebenarnya. Karena X^ = TSD’ (Deerwester et al., 1990), maka dapat digambarkan sebagai berikut.

T : mendeskripsikan baris asli sebagai vektor turunan nilai faktor ortogonal
S : adalah matriks diagonal yang memuat nilai skala jika ketiga komponen matriks dikalikan
D : mendeskripsikan kolom seperti matriks T
t : adalah jumlah baris pada X
d : adalah jumlah kolom pada X
m : adalah rank pada X (≤min(t,d))

Berikut merupakan contoh pengimplementasian rumus di atas.

                                    

                                         Misal, X =

 

Dengan,
T (9 dimensi vektor singular kiri untuk 12 term)
S (matriks diagonal dari 9 nilai singular)
D (9 dimensi vektor singular kanan untuk 9 dokumen)

Maka untuk mencari X^ (agar mengetahui keterhubungan antara term dan dokumen lebih detil), maka perlu untuk mencari matriks T, S, dan D^T untuk kemudian dihitung ke dalam rumus yang telah disebutkan di atas.

Untuk mencari T, dilakukan:

1. Mencari hasil dari XX^T
2. Mencari eigenvalue dan eigenvector dari XX^T. Eigenvector adalah vektor tak nol yang memenuhi persamaan. Dimana A adalah matriks segiempat, λ bernilai skalar, dan v adalah eigenvector / vektor karakteristik. λ adalah eigenvalue / akar karakteristik nya.
3. Konversi matriks vektor ke matriks ortogonal menggunakan proses Gram-Schmidt orthonormalization

Gambar 2 - Hasil matriks T

Untuk mencari D, dilakukan:

1. Mencari hasil dari X^TX
2. Mencari eigenvalue dan eigenvector dari X^TX
3. Konversi matriks vektor ke matriks ortogonal menggunakan proses Gram-Schmidt orthonormalization
4. Didapatkan D, namun yang dibutuhkan adalah D^T, maka dilakukan transpose terhadap D

Gambar 3 - Hasil matriks D transpose

Untuk mendapatkan S, hanya perlu mengakarkan nilai eigenvalue yang sudah didapatkan dan merangkaikan dalam matriks secara diagonal.

Gambar 4 - Hasil matriks S

Lalu dimasukkan ke dalam rumus perkalian matriks berikut,

Sehingga didapatkan hasil berikut,

Dari hasil tersebut, ditemukan dokumen yang paling mewakili makna dari kumpulan term yang ada. Sehingga dapat diberikan rekomendasi dokumen sesuai dengan nilai yang dihasilkan.