Aplikasi Pencarian Jadwal Dokter dan Fasilitas Rumah Sakit e‐Doctor Schedule & Hospital Info Berbasis Web Semantik
A. B. Mutiara, A. Muslim, T. Putri, T. Oswari, W. Silfianti
Aplikasi Pencarian Jadwal Dokter dan Fasilitas Rumah Sakit e‐Doctor Schedule & Hospital Info Berbasis Web Semantik A. B. Mutiara, A. Muslim, T. Putri, T. Oswari, W. Silfianti
Aplikasi Pencarian Jadwal Dokter dan Fasilitas Rumah Sakit e‐Doctor Schedule & Hospital Info Berbasis Web Semantik Penyusun : A. B. Mutiara, A. Muslim, T. Putri, T. Oswari, W. Silfianti Desain : T. Putri Desain dan Layout : A. Muslim Diterbitkan pertama kali oleh Universitas Gunadarma Hak Cipta dilindungi Undang‐Undang Depok, Oktober 2013 ISBN 978‐602‐9438‐30‐7
2 | Pengembangan e-DoctorSchedule & Hospital Info
KATA PENGANTAR
Puji syukur kepada Allah SWT yang telah memberikan rahmat,
hidayah, pencerahan, dan kekuatan sehingga Buku Pengembangan berikut Petunjuk Penggunaan Situs HospitalInfo Gunadarma ini dapat diselesaikan dengan lancar. Buku petunjuk penggunaan ini merupakan bagian dari pembangunan Situs Pencarian Jadwal Dokter dan Rumah Sakit “HospitalInfo” yang Berbasis Web Semantik.
Buku Pengembangan dan Petunjuk Penggunaan situs HospitalInfo
ini berisikan i) landasan teori, metode, analisa dan perancangan situs HospitalInfo dan ii) semua panduan untuk menggunakan fasilitas‐fasilitas yang tersedia dalam situs. Situs ini menyediakan fasilitas‐fasilitas yang dapat digunakan dalam pencarian jadwal dokter dan fasilitas yang ada di beberapa rumah sakit.
Akhirnya, kami menyadari bahwa Buku Petunjuk Penggunaan Situs
HospitalInfo ini masih kurang sempurna dalam mengakomodir semua yang dapat dilakukan oleh situs itu sendiri dan keinginan pengguna. Oleh karenanya segala kritik yang membangun dan saran untuk perbaikan dan kebaikan sangat kami harapkan. Semoga buku pengembangan dan panduan ini dapat membantu pengguna dalam i) memahami prinsip web semantik dan ii) mengoperasikan situs HospitalInfo ini. Depok, Oktober 2013 A. B. Mutiara, A. Muslim, T. Putri, T. Oswari, W. Silfianti
3 | Pengembangan e-DoctorSchedule & Hospital Info
4 | Pengembangan e-DoctorSchedule & Hospital Info
DAFTAR ISI KATA PENGANTAR
3
DAFTAR ISI
5
BAB I. PENDAHULUAN
7
BAB II. LANDASAN TEORI
11
2.1. WEB SEMANTIK 2.2. ONTOLOGI 2.3. RDF (RESOURCE DESCRIPTION FRAMEWORK) 2.4. OWL (ONTOLOGY WEB LANGUAGE) 2.5. PEMODELAN DATA SEMANTIK 2.6. INTEROPERABILITAS 2.7. PROTÉGÉ 2.8. SIMPLE HTML DOM PARSER
11 13 14 14 15 16 17 18
BAB III. METODE, ANALISIS DAN PERANCANGAN
21
3.1. METODE PENELITIAN 3.2. ANALISIS DAN PEMECAHAN MASALAH 3.2.1. ANALISIS KEBUTUHAN 3.2.2. ANALISIS MASALAH 3.2.3. PENDEFINISIAN MASALAH 3.2.4. PEMECAHAN MASALAH 3.3. PEMODELAN SISTEM 3.3.1. DIAGRAM USE CASE 3.3.2. DIAGRAM ACTIVITY 3.3.3. DIAGRAM SEQUENCE 3.4. PENGAMBILAN DATA LIVE 3.5. PEMBUATAN DATABASE UNTUK DATA LIVE 3.6. STRUKTUR RDF UNTUK DATA DUMMY 3.6.1. RDF GRAPH UNTUK JADWAL DOKTER 3.6.2. PROPERTY CLASS 3.6.3. MODEL DATA GRAPH 3.6.4. MODEL DATA RDF 3.6.5. REPRESENTASI PEMETAAN PADA RDF/OWL 3.6.6. REPRESENTASI QUERY
21 22 22 22 22 23 30 30 30 31 32 37 38 39 39 40 42 42 44
5 | Pengembangan e-DoctorSchedule & Hospital Info
3.7. RANCANGAN TAMPILAN 3.7.1. RANCANGAN TAMPILAN HALAMAN USER 3.8. STRUKTUR NAVIGASI
48 48 50
BAB IV. PANDUAN APLIKASI HOSPITALINFO
51
4.1. HALAMAN HOME 4.2. HALAMAN KJS 4.3. HALAMAN ABOUT 4.4. HALAMAN SEARCH UNTUK DATA DUMMY 4.5. HALAMAN GRAPH 4.6. HALAMAN DATA GRID 4.7. HALAMAN KONTAK DAFTAR PUSTAKA
51 53 54 55 57 57 58 59
6 | Pengembangan e-DoctorSchedule & Hospital Info
BAB I. PENDAHULUAN
Saat ini kesehatan merupakan kebutuhan primer bagi masyarakat,
salah satu penunjang kesehatan adalah rumah sakit. Sebagai, media penunjang kesehatan, hal yang paling diutamakan oleh rumah sakit adalah menyediakan pelayanan kesehatan bagi masyarakat. Rumah sakit yang baik dapat dilihat dari segi pelayanan yang disajikan untuk pasiennya. Jadi, bila ingin meningkatkan kinerja rumah sakit salah satu caranya dengan meningkatkan pelayanan yang ada pada rumah sakit tersebut.
Salah satu cara untuk meningkatkan pelayanan kesehatan terutama
untuk warga kurang mampu yaitu dengan dikeluarkannya Kartu Jakarta Sehat (KJS). KJS merupakan salah satu program unggulan Provinsi DKI Jakarta Tahun 2013 dibawah kepemimpinan Gubernur dan Wakil Gubernur, Joko Widodo dan Basuki Tjahaja Purnama. Tujuan dari Program KJS ini adalah memberikan jaminan pemeliharaan kesehatan bagi penduduk Provinsi DKI Jakarta, terutama bagi keluarga miskin dan kurang mampu dengan sistem rujukan berjenjang. Ada sekitar 77 rumah sakit yang terdaftar dalam program ini.
Dalam beberapa kasus, terkadang kebutuhan seorang pasien tidak
mungkin dapat terpenuhi dari satu rumah sakit saja. Adakalanya, dokter yang dibutuhkan saat itu sedang tidak bertugas atau fasilitas rumah sakit yang disediakan kurang memadai untuk pasien dengan kondisi tertentu. Selain itu, tidak semua rumah sakit terdaftar dalam program KJS.
Karena itu, dibutuhkan suatu sistem informasi yang dapat
menyediakan informasi penting seperti ketersediaan dokter berdasarkan jadwal prakteknya dan fasilitas yang ada pada seluruh rumah sakit rujukan
7 | Pengembangan e-DoctorSchedule & Hospital Info
KJS yang mudah, update, valid, dan bisa saling berkomunikasi dengan sistem informasi lainnya.
Permasalahannya,
masing‐masing
rumah
sakit
biasanya
membangun sistem informasi sesuai dengan kebutuhannya. Akibatnya, menciptakan banyak standar data, informasi, maupun skema. Untuk mengatasi hal itu maka dibuat sebuah situs aplikasi yang menjadi interface untuk beberapa sistem rumah sakit yang berbeda. Sekaligus dapat meningkatkan efisiensi layanan data dari berbagai rumah sakit sehingga dapat memberikan kemudahan pada pasien untuk mendapatkan informasi dari beragam rumah sakit yang ada hanya pada satu sistem informasi sehingga pertolongan pada pasien dapat segera dilaksanakan.
Salah satu teknik untuk mengatasi perbedaan data informasi dan
skema dari sistem rumah sakit yang berbeda‐beda yaitu dengan penggunaan Semantic Web dan Ontology dengan metode Ontology Web Language (OWL) dan Resource Description Framework (RDF), sehingga perbedaan tersebut tidak dirasakan oleh end user atau pengguna akhir dalam mencari informasi seperti jadwal dokter dan failitas pelayanan dari beberapa sistem informasi yang berbeda dengan cukup dilakukan pada satu situs interface tersebut.
Adapun metode yang dilakukan pada pengembangan aplikasi ini
yaitu dengan : 1. Studi literature Mencari, mempelajari dan merangkum berbagai macam pustaka yang berkaitan dengan rumusan masalah, teori‐teori yang berkaitan dengan Web Semantik, XML, OWL/RDF, PHP, MySQL, SPARQL dan Simple HTML DOM Parser. 2. Penentuan class 8 | Pengembangan e-DoctorSchedule & Hospital Info
Menentukan class‐class yang akan digunakan dalam Struktur web semantik ini. 3. Perancangan bentuk‐bentuk query Membuat rancangan bentuk‐bentuk query dan hasil luarannya. 4. Pengambilan konten tabel dengan Simple HTML DOM Parser Mengambil konten tabel dari sampel web rumah sakit dan memasukkannya ke dalam database. 5. Pengujian pencarian jadwal dokter dan fasilitas pelayanan rumah sakit pada web services berbasis web semantik rumah sakit Menguji form pencarian baik pencarian dengan data live (hasil pengambilan konten) maupun data yang diinput secara manual (dengan RDF) dapat berjalan dengan baik atau tidak. Untuk selengkapnya tahapan‐tahapan di atas akan dijelaskan pada Bab III Metode, Analisis dan Perancangan.
9 | Pengembangan e-DoctorSchedule & Hospital Info
10 | Pengembangan e-DoctorSchedule & Hospital Info
BAB II. LANDASAN TEORI
2.1. Web Semantik
Secara garis besar semantic web adalah informasi dalam jumlah
sangat besar di World Wide Web yang terhubung secara global dengan suatu cara tertentu dan dimengerti/dipahami oleh mesin, sehingga dapat diproses secara langsung oleh mesin menjadi knowledge untuk ditampilkan kepada user. Semantic web juga dapat dikatakan sebagai sebuah cara yang efisien untuk merepresentasikan data di World Wide Web sebagai sebuah database yang terhubung secara global[5].
Semantic web dicetuskan pertama kali oleh Tim Berners‐Lee,
penemu WWW, URIs, HTTP dan HTML. Ada sebuah tim yang berdedikasi pada konsorsium World Wide Web (W3C) telah bekerja untuk meningkatkan, memperluas dan membuat sistem standard, banyak bahasa, publikasi, perlengkapan dan lain‐lain[5].
Rasionalisasi untuk semantic web adalah bahwa data yang
umumnya tersembunyi di dalam file HTML terkadang berguna dalam beberapa konteks, tapi tidak dalam konteks yang lain. Masalah umum pada data yang berada di web adalah, dalam bentuknya yang sekarang sulit untuk digunakan dalam skala besar, karena tidak terdapat sistem global untuk menyebarluaskan data dalam sebuah cara yang mudah untuk diproses oleh semua orang. Sebagai contoh, sebuah event olahraga, informasi cuaca, jadwal pesawat, acara televisi dan lain‐lain, semua informasi ini di hadirkan oleh banyak web site, namun semua dalam format HTML. Masalahnya adalah, dalam beberapa konteks, sulit untuk menggunakan data yang ada tersebut sebagaimana yang dinginkan orang lain[5]. Oleh karena itu, semantic web dipandang sebagai sebuah solusi 11 | Pengembangan e-DoctorSchedule & Hospital Info
teknis, namun lebih dari itu. Dengan semantic web, akan menjadi lebih mudah untuk mempublikasikan data dalam bentuk yang repurposeable, sehingga akan ada banyak orang ingin mempublikasikan datanya, dan kemudian akan terjadi knock‐on atau efek domino[5].
Metode semantic web telah membantu terjadinya revolusi dalam hal
penyampaian dan pemanfaatan informasi pada World Wide Web. Sebagai contoh, jika seseorang ingin menyusun informasi dari beberapa situs web sekaligus, maka dengan teknologi web yang sekarang ada, dia harus mengunjungi situs‐situs tersebut satu – persatu dan kemudian melakukan cut and paste pada content dari masing‐masing situs untuk menciptakan suatu informasi yang menyeluruh. Hal ini sangatlah membuang waktu dan tenaga, karena dilakukan secara manual oleh manusia, dan dengan berbasis teknologi yang sudah ada tidak akan mungkin dibuat otomatisasinya, mengingat halaman web berbasis HTML hanyalah dirancang untuk dipahami oleh manusia bukan mesin[1].
Dengan metode semantic web, data berbasis HTML dapat dirubah
menjadi format yang dapat dipahami oleh mesin, sehingga mesin dapat melakukan proses pengumpulan informasi dan memahami hubungan antara informasi. Semantic Web mampu melakukan perubahan ini dengan bantuan XML (Extensible Markup Language) dan data – language standards seperti RDF (Resource Description Framework) dan OWL (Ontology Web Language), dua standarisasi dari W3C (World Wide Web Consortium). Dengan berbagai standar tersebut, memungkinkan pengembang web (Web Developer) untuk menambahkan satu layer “arti” pada dokumen web‐nya. Sebagai framework untuk mendefinisikan bagaimana beberapa data terhubung dan bagaimana relasi yang menyertai data‐data tersebut seharusnya ditampilkan[1]. 12 | Pengembangan e-DoctorSchedule & Hospital Info
Semantic web bukanlah Artifitial Intelegent (kecerdasan buatan),
karena mesin tidak dengan sendirinya memahami bahasa manusia secara menyeluruh. Konsep ini hanya menandakan kemampuan mesin untuk memecahkan well‐defined problems (permasalahan yang telah ditentukan) dengan cara melakukan well‐defined operations (operasi untuk memecahkan masalah yang juga telah ditentukan) pada well‐defined data (data yang juga telah ditentukan) yang tersedia. Jadi, untuk bahasa manusia yang berada di luar well‐defined data, mesin sudah tidak mampu lagi untuk memahami bahasa tersebut[1].
2.2. Ontologi
Istilah ontologi sebenarnya berasal dari istilah filosofi “ontology”
yang artinya sesuatu yang sesungguhnya ada dan bagaimana menggambarkannya. Dalam dunia komputer ontologi digunakan untuk menspesifikasikan suatu konseptualisasi. Dalam istilah lain ontologi dijelaskan sebagai suatu representasi dari domain pengetahuan tertentu yang berisi istilah‐istilah dalam domain tersebut beserta hubungan antara istilah‐istilah yang ada[7].
Ontologi saat ini banyak digunakan terutama untuk mendukung
web semantik, yaitu teknologi web yang diarahkan dapat memahami makna suatu kata atau kalimat yang diberikan oleh pengguna. Membuat komputer mengerti seperti manusia adalah suatu hal yang sepertinya mustahil, namun visi ini terus diupayakan dengan menyediakan seperangkat alat sehingga membuat mesin atau komputer dengan mudah dapat memproses informasi dan mengerti informasi yang diinginkan oleh pengguna[7].
Tidak ada standar khusus untuk membangun suatu ontologi dan
tidak ada justifikasi bahwa ontologi yang dikembangkan oleh seseorang 13 | Pengembangan e-DoctorSchedule & Hospital Info
adalah salah atau benar. Kualitas ontologi dapat dilihat dari aplikasi yang dibangun berdasarkan ontologi ini. Ketika aplikasi yang dibangun dapat memenuhi kebutuhan pengguna dan menjawab permasalahan yang ada maka ontologi yang digunakan termasuk ontologi yang berkualitas[7].
2.3. RDF (Resource Description Framework)
RDF merupakan suatu metadata yang digunakan untuk
mendeskripsikan alamat sumber daya pada web[11]. Metadata ini dapat berupa judul, pengarang, hak cipta, dan lisensi dalam dokumen web. Elemen pernyataan dalam RDF terdiri dari subyek, predikat, dan obyek. Subyek adalah sesuatu yang dideskripsikan dan biasanya berupa alamat URI. Dalam hal ini alamat URI merepresentasikan sumber daya. Predikat merupakan properti dari sumber daya yang menjelaskan hubungan antara subyek dengan obyek. Selain itu obyek merupakan nilai dari sebuah predikat. Obyek mempunyai dua tipe data yaitu obyek yang mempunyai tipe URI misalnya http://airplane.com/id/102 dan obyek yang bertipe literal misalnya “adam air”. Subyek dan predikat berisikan data yang berisikan sumber daya sedangkan obyek dapat bertipe sumber daya maupun literal[11].
2.4. OWL (Ontology Web Language)
Web Ontology Language (OWL) adalah suatu bahasa yang dapat
digunakan oleh aplikasi – aplikasi yang bukan sekedar menampilkan informasi tersebut pada manusia, melainkan juga yang perlu memproses isi informasi isi. Ontology sendiri dapat didefinisikan sebagai suatu cara untuk mendeskripsikan arti dan relasi dari istilah‐istilah. Deskripsi tersebut berisi classes, properties, dan instances. Deskripsi ini dapat membantu sistem komputer dalam menggunakan istilah‐istilah tersebut dengan cara yang lebih mudah[10]. 14 | Pengembangan e-DoctorSchedule & Hospital Info
Dengan menggunakan OWL, kita dapat menambah vocabulary
tambahan di samping semantik formal yang telah dibuat sebelumnya menggunakan XML, RDF, dan RDF Schema. Hal ini sangat membantu penginterpretasian mesin yang lebih baik terhadap isi Web. Untuk mendeskripsikan property dan class, OWL menambahkan vocabulary seperti [10]: 1. “among others”. 2. Relasi antar classes (misalnya: “disjointness”). 3. Kardinalitas (misalnya: “exactly one”). 4. Kesamaan (equality). 5. Karakteristik property (misalnya: “symmetry”). 6. Enumerated classes.
2.5. Pemodelan Data Semantik
Konsep semantik adalah bagian utama dalam Semantic Data
Modeling (SDM). SDM menggambarkan keterhubungan antara definisi formal dan hubungannya dengan dunia nyata yang di modelkan. Tetapi di dalam SDM, hanya hubungan antara definisi formal (data) yang membentuk informasi yang diformalisasikan dalam model konseptual. Berikut ini adalah konsep dasar dibalik SDM[12] : 1. Model konseptual hanya mengandung pernyataan positif (assertions). Artinya, pernyataan harus benar sebagaimana kenyataannya. Oleh karena itu, semisal, data seseorang yang tidak bekerja untuk sebuah perusaahaan tidak akan ditempatkan dalam tabel karyawan. 2. Setiap definisi bersifat unik, artinya, tidak ada perbedaan definisi type dengan nama yang sama atas koleksi atribut yang sama pula. 3. Sebuah atribut direlasikan dengan sebuah type, dan sebuah type direlasikan dengan sedikitnya sebuah atribut. 15 | Pengembangan e-DoctorSchedule & Hospital Info
4. Sebuah object dapat berupa type atau instantiasi dari object, tergantung sudut pandangnya. 5. Sebuah type adalah sekumpulan object yang memiliki properties. 6. Attribute sebuah type adalah properties yang meng‐agregasi type tersebut. 7. Sebuah instance dari type, adalah object yang memiliki properties type‐ nya.
Contoh implementasi SDM terdapat pada perancangan aplikasi dan
dijelaskan lebih detail pada Bab III.
2.6. Interoperabilitas
Istilah "interoperabilitas" digunakan berbeda antar komunitas yang
berbeda. Istilah ini digunakan untuk menguraikan kemampuan pertukaran informasi antar sistem yang dikembangkan secara terpisah, di mana sistem yang terpisah mampu memahami bentuk, maksud/arti, dan juga mutu informasi yang sedang dipertukarkan[15].
Interoperabilitas, seperti yang digambarkan oleh Institute of
Electrical and Electronics Engineers (IEEE) (Institute of Electrical and Electronics Engineers, 1990), adalah “kemampuan dari dua atau lebih sistem atau komponen untuk pertukaran informasi dan menggunakan informasi yang telah dipertukarkan”. Suatu sistem (atau komponen) dapat interoperate dengan sistem yang lain ( atau komponen) sepanjang mereka dapat memahami informasi yang telah dipertukarkan antar satu sama lain.
Brodie (Brodie, 1992) memberi suatu definisi fungsional tentang
Interoperabilias di dalam sistim informasi sebagai berikut: “Interoperabilitas: Dua komponen (atau object) X dan Y dapat interoperate (adalah interoperable) jika X dapat mengirimkan permintaan layanan (atau pesan) R ke Y berdasarkan pada suatu saling pengertian dari R dengan X dan 16 | Pengembangan e-DoctorSchedule & Hospital Info
Y, dan Y dapat mengembalikan response/tanggapan S ke X berdasarkan pada suatu saling pengertian dari S sebagai (berturut‐turut) tanggapan R oleh X dan Y.” Singkatnya, sistem X dapat interoperate dengan sistem Y jika permintaan X dapat dijawab/direspon secara tepat oleh Y[15].
Berikut ini definisi dari Brodie dan IEEE, interoperabilitas antar
sistem informasi tidaklah ditentukan oleh penempatan fisik. Sehingga, interoperabilitas antar dua sistem informasi (atau komponen) dapat terjadi di dalam mesin yang sama atau antara dua mesin yang berbeda. Ia juga tidak ditentukan oleh tujuan interoperation. Ia hanya ditentukan oleh kesuksesan dari pertukaran informasi antara dua sistem informasi[15].
2.7. Protégé
Protégé adalah perangkat lunak bantu yang digunakan utnuk
pengembangan sistem berikut Knowledge Base System. Aplikasi yang dikembangkan oleh Protégé digunakan dalam pemecahan masalah dan pembuatan keputusan dalam sebuah domain. Protégé dikembangkan oleh sebuah organisasi yang bernaung di bawah Stanford University, yang mengambil spesialisasi di bidang ontology[12].
Protégé merupakan sebuah alat yang digunakan untuk membuat
sebuah domain ontology, menyesuaikan form untuk entry data dan memasukkan data. Berbagai format penyimpanannya seperti OWL, RDF, XML dan HTML. Protégé menyediakan kemudahan plug and play yang membuatnya fleksibel untuk pengembangan prototype. Protégé dibuat dengan menggunakan bahasa pemrograman Java. Semua alat‐alat dalam Protégé dapat digunakan melalui Graphical User Interface (GUI) dengan menyediakan Tab untuk masing‐masing bagian dan fungsi standar. Class Tab dalam editor ontology berfungsi untuk mendefinisikan class dan 17 | Pengembangan e-DoctorSchedule & Hospital Info
hirarki class, property dan nilai property tersebut relasi antara class dan property dari relasi tersebut[18].
Perangkat lunak Protégé menyediakan konsepsi dasar pengetahuan
yang terintegrasi, serta mengubah tampilan visual lingkungan dengan memperluas arsitektur sistem untuk membuat pemodelan dasar pengetahuan secara lebih sederhana dan mudah. Protégé dapat juga digunakan dengan tujuan berikut membangun ontology,. memodelkan tampilan pengetahuan akuisisi dan memasukkan domain pengetahuan. Protégé memvisualisasikan hubungan subclass dalam tree, mendukung berbagai penurunan (multiple inheritance) dan root pada hirarki class yang terbentuk adalah class "THING"[12].
Untuk mendapatkan Protégé dapat dilakukan dengan cara
mengunduh dari web penyedia tool, alamat web tersebut adalah http://Protégé.stanford.edu/. Ukuran file instalasi untuk Protégé tergantuk pada versi yang diinginkan dan juga tergantung termasuk atau tidaknya SDK Java. Protégé membutuhkan SDK Java terdapat dua pilihan yaitu apakan SDK Java termasuk ke dalam file instalasi atau tidak. Protégé dapat berjalan di berbagai platform operating system, antara lain Windows, Mac OS, Solaris, Linux, HP‐UX, Unix, dan AIX. Protégé dapat membuka berbagai macam format file, ada tiga format file umum yang dapat dibuka dengan Protégé, yaitu XML, RDF dan OWL. Untuk dapat membuka format file tersebut hal yang perlu dilakukan adalah dengan membuat sebuah project baru pada Protégé, Protégé tersebut akan memiliki format file .pprj[12].
2.8. Simple HTML DOM Parser
Simple HTML DOM Parser adalah class PHP 5+ yang membantu
memanipulasi elemen HTML. Tidak hanya terbatas pada class HTML yang valid, tetapi juga dapat bekerja dengan kode HTML yang tidak termasuk 18 | Pengembangan e-DoctorSchedule & Hospital Info
validasi W3C. Obyek dokumen dapat ditemukan menggunakan selector, mirip dengan yang ada pada jQuery. Pada HTML DOM dapat ditemukan unsur menurut id, kelas, tag, dan banyak lagi. Elemen DOM juga dapat ditambahkan, dihapus atau diubah[13].
Elemen HTML DOM ditemukan dengan menggunakan find function.
Fungsi ini mengembalikan objek atau array dari beberapa objek. Objek ini serupa dengan objek pertama, sehingga semua class function yang ada dapat digunakan[13]. Output yang dihasilkan berupa string. Berikut contoh untuk pengambilan elemen[17] : // Create DOM from URL or file $html = file_get_html('http://www.google.com/'); // Find all images foreach($html‐>find('img') as $element) echo $element‐>src . '
'; // Find all links foreach($html‐>find('a') as $element) echo $element‐>href . '
';
Berikut contoh untuk memodifikasi elemen HTML[17] : // Create DOM from string $html = str_get_html('
Hello
World
'); $html‐>find('div', 1)‐>class = 'bar'; $html‐>find('div[id=hello]', 0)‐>innertext = 'foo'; echo $html; // Output:
foo
World
19 | Pengembangan e-DoctorSchedule & Hospital Info
Berikut contoh untuk mengekstrak konten dari HTML[17] : // Dump contents (without tags) from HTML echo file_get_html('http://www.google.com/')‐>plaintext;
20 | Pengembangan e-DoctorSchedule & Hospital Info
BAB III. METODE, ANALISIS DAN PERANCANGAN
3.1. Metode Penelitian
Dalam pembuatan web semantik jadwal praktek dokter ini
dibutuhkan suatu metode penelitian yang merupakan prosedur pengumpulan data yang digunakan untuk memecahkan masalah yang dihadapi. Adapun metode ilmiah yang dilakukan pada penelitian ini yaitu dengan menggunakan metode pengembangan rekayasa perangkat lunak Waterfall. Metode ini merupakan metode yang sering digunakan oleh penganalisa sistem pada umumnya. Inti dari metode Waterfall adalah pengerjaan dari suatu sistem dilakukan secara berurutan atau secara linear. Jadi jika langkah satu belum dikerjakan maka tidak akan bisa melakukan pengerjaan langkah 2, 3 dan seterusnya. Secara otomatis tahapan ke‐3 akan bisa dilakukan jika tahap ke‐1 dan ke‐2 sudah dilakukan.
Gambar 3.1. Metode Waterfall (Pressman & Somerfille, 2010) 21 | Pengembangan e-DoctorSchedule & Hospital Info
3.2. Analisis dan Pemecahan Masalah
Terdapat beberapa analisa yang dilakukan dalam penelitian ini.
3.2.1. Analisis Kebutuhan Terdapat beberapa data yang dibutuhkan dalam penelitian ini untuk dijadikan bahan penyelesaian sebuah masalah. Pada penelitian web semantik ini, dibutuhkan beberapa sumber data berupa jadwal praktek berikut fasilitas masing‐masing rumah sakit yang termasuk dalam rujukan KJS. Data tersebut diperoleh dari situs resmi masing‐masing rumah sakit tersebut. 3.2.2. Analisis Masalah Masalah yang akan dianalisa membutuhkan pendefinisian terlebih dahulu untuk memberikan sebuah gambaran tepat guna mendapatkan sebuah solusi dari masalah dalam sebuah penelitian. 3.2.3. Pendefinisian Masalah Dalam penelitian ini terdapat sebuah kasus yaitu jika pengguna ingin mencari jadwal dokter atau fasilitas dari satu atau lebih rumah sakit tanpa membuka seluruh halaman situs rumah sakit yang ada. Karena itu, dibutuhkan mesin pencarian dimana dengan memasukkan beberapa kata kunci, maka mesin akan melakukan kemudian menampilkan jadwal dokter jadwal dokter sesuai dengan kata kunci yang sudah dimasukkan.
Data yang ditampilkan disesuaikan dengan standarisasi yang sudah
ada pada penelitian sebelumnya karena penelitian ini merupakan pengembangan dari penelitian tersebut. Penelitian ini dibagi menjadi dua bagian, yaitu pencarian data dimana datanya diambil secara langsung dari masing‐masing situs rumah sakit, dengan kata lain data bersifat live, dan pencarian data dimana datanya dimasukkan secara manual dengan
22 | Pengembangan e-DoctorSchedule & Hospital Info
menggunakan file RDF (data dummy). Hal ini dilakukan sebagai perbandingan antara data live dan data dummy.
Namun, terdapat beberapa permasalahan terutama pada data yang
bersifat live, antara lain : 1. Pertama, situs yang dapat diambil datanya secara live haruslah situs dengan jadwal praktek berupa tabel dengan properties yang sesuai dengan standarisasi yang sudah ditentukan pada penelitian sebelumnya. Sedangkan, dari 77 rumah sakit rujukan Kartu Jakarta Sehat (KJS) hanya terdapat 43 rumah sakit yang memiliki situs sendiri, namun hanya ada 4 situs yang sesuai dengan standarisasi yang sudah ada dan yang bisa diambil datanya hanya ada 2 situs. Untuk 2 situs lainnya, akan digunakan sebagai bahan untuk pencarian dengan RDF. 2. Kedua, terdapat perbedaan properties pada tabel pada situs untuk data live dan data dummy. 3. Ketiga, data hasil dari pengambilan secara live tidak dapat langsung ditampilkan begitu saja, terdapat beberapa pengaturan agar data dapat ditampilkan sesuai dengan standarisasi yang ada. 3.2.4. Pemecahan Masalah Dalam permasalahan perbedaan properties pada data live, pendekatan yang memungkinkan untuk dijadikan solusi adalah dengan Web Semantik yang memanfaatkan konsep pemetaan ontology utnuk mencapai interoperabilitas berdasarkan keanekaragaman data. Fokus utamanya adalah pada pemetaan ontology beberapa sumber data yang memiliki terminologi yang heterogen ditingkat semantik dengan domai yang digunakan yaitu jadwal praktek dokter.
23 | Pengembangan e-DoctorSchedule & Hospital Info
Rancangan dalam pemetaan ontologi dideskripsikan yaitu berupa
pemetaan yang dilakukan antara dua ontology yaitu antara ontology User View dengan ontology dari sumber data yang digunakan dengan pemetaan terminologi yang bersumber dari kedua ontology tersebut yang dihubungkan oleh sebuah ontology yang disebut dengan Common Ontology. User View adalah ontology yang digunakan sebagai terminologi acuan yang sering digunakan oleh user dalam sebuah pencarian dan pemilihannya mewakili terminologi lainnya, sedangkan sumber data adalah situs web yang menjadi sumber dari terminologi yang dijadikan bahan pemetaan.
Implementasi dari rancangan dalam pemetaan ontology ini
dilakukan dengan beberapa tahapan yaitu dimulai dengan pembentukan ontology sumber data, Common Ontology, dan ontology User View. Selanjutnya dilakukan pemetaan antara User View dengan Common Ontology, dan pemetaan antara Common Ontology dengan Local Schema sumber data. 1. Local Schema Sumber Data Tahap ini adalah menentukan gambaran local schema dari sumber data jadwal praktek dokter rumah sakit. Rumah sakit yang dijadikan objek penelitian ini adalah sebagai berikut. a) RS Kartika Pulomas gambar local schema
Gambar 3.2. Bentuk Schema dari Ontology Sumber Data RS Kartika 24 | Pengembangan e-DoctorSchedule & Hospital Info
b) RS Marinir Cilandak gambar local schema
Gambar 3.3. Bentuk Schema dari Ontology Sumber Data RS Marinir Terminologi yang terdapat pada setiap sumber data akan dijadikan property dari semua ontology yang akan dibuat yaitu pada local schema, common ontology, dan user view. Local schema terdiri dari nama rumah sakit, nama class yang akan digunakan untuk pemetaan ontology, dan terminologi tiap rumah sakit yang akan digunakan sebagai data property pada tool Protégé.
Pertama‐tama, pada Protégé akan dibuat local schema untuk
kartika dimana kartika adalah class.
25 | Pengembangan e-DoctorSchedule & Hospital Info
Gambar 3.4. Pembuatan Class untuk Local Schema RS Kartika
Setelah pembuatan class, dilanjutkan dengan pembuatan
properties yang dilakukan pada halaman object properties pada Protégé.
Gambar 3.5. Pembuatan Properties untuk Local Schema RS Kartika 26 | Pengembangan e-DoctorSchedule & Hospital Info
2. Common Ontology Common Ontology adalah sebuah ontology yang memiliki property yang terbentuk dari gabungan semua property yang terdapat pada schema sumber data. Common ontology ini menjadi sebuah ontology yang memuat keanekaragaman terminologi dari sumber data yang diambil yang memiliki maksud atau arti yang sama serta sebagai ontology yang dijadikan mediasi atau penghubung pemetaan dua ontology lain yaitu ontology schema sumber data dan user view. Bentuk struktur common ontology yang mengandung sebuah class yaitu common ontology dan property dari class kartika yang merupakan terminologi keseluruhan dari sumber data yang diambil. Setelah diketahui class dan property yang akan dibuat ontology maka dapat dibuat common ontology pada tool Protégé dengan tahapan pembuatan ontology sama dengan tahapan pembuatan ontology pada sumber data yang telah dijelaskan sebelumnya. Namun, khusus common ontology ini perlu dilakukan pemetaan tersendiri untuk terminologi yang memiliki arti atau makna yang sama. 3. User View User view merupakan bentuk terminologi dari sumber data yang hampir selalu ada pada tiap sumber data karena merupakan data yang utama terdapat pada sebuah objek dalam hal ini yaitu jadwal praktek rs kartika dan merupakan data yang sering dicari oleh user atau pengguna internet. Berdasarkan sumber data yang telah digunakan oleh penulis maka ditentukan nama rumah sakit, nama dokter, hari praktek dan jam praktek. Setelah diketahui class dan property yang akan dibuat ontology maka dapat dibuat user view 27 | Pengembangan e-DoctorSchedule & Hospital Info
pada tool Protégé dengan tahapan pembuatan ontology sama dengan tahapan pembuatan ontology pada sumber data yang telah dijelaskan sebelumnya Tahapan selanjutnya dalam penelitian ini adalah pembentukan pemetaan yang pertama yaitu pemetaan antara User View dengan Common Ontology. 4. Pemetaan antara User View dengan Common Ontology Pemetaan ini adalah pemetaan antara terminologi yang terdapat pada user view dengan terminologi yang terdapat pada common ontology. Pemetaan yang dilakukan ini adalah pemetaan pada tingkat property yang jika terdapat dua atau lebih konsep dimana konsep‐ konsep tersebut memiliki arti yang sama maka dengan menggunakan tool Protégé ini, konsep‐konsep tersebut akan disamakan atau dibuat equivalent property. Equivalent property adalah suatu keterhubungan antar property yang menyatakan makna sepadan/similiar. Komposisi pemetaan digunakan untuk menciptakan arah hubungan semantik antara User View dan berbagai sumber data.
Gambar 3.6. Contoh Hasil Pemetaan Ontology 5. Pemetaan antara Common Ontology dengan Local Schema Sumber Data 28 | Pengembangan e-DoctorSchedule & Hospital Info
Sama seperti pemetaan sebelumnya, pemetaan ini merupakan pemetaan antara terminologi yang terdapat pada common ontology dengan terminologi yang terdapat pada sumber data. Pemetaan yang dilakukan ini adalah pemetaan property yang jika terdapat dua atau lebih konsep pada common ontology dimana konsep‐konsep tersebut memiliki arti yang sama dengan konsep yang terdapat pada sumber data maka dengan menggunakan tool Protégé ini, konsepkonsep tersebut akan disamakan atau dibuat
equivalent dengan
menggunakan salah satu menu dalam RDF/OWL yaitu owl :equivalentProperty. Setelah semua pemetaan selesai dilakukan, maka terbentuk sebuah alur proses pemetaan seperti terlihat pada Gambar 3.7 berikut.
Gambar 3.7. Contoh Alur Proses Pemetaan 29 | Pengembangan e-DoctorSchedule & Hospital Info
3.3. Pemodelan Sistem
Dalam merancang sistem ini, alat bantu pemodelan yang digunakan
adalah UML(Unified Modelling Language). Sistem ini hanya akan digambarkan dalam 3 macam UML yaitu use case diagram, activity diagram dan sequence diagram. 3.3.1. Diagram Use Case Diagram ini menunjukkan hubungan antara sistem dengan pengguna di luar sistem yaitu user dan admin. Deskripsi use case dari sistem ini dapat dilihat pada Lampiran yang disertakan dalam penulisan ini.
Gambar 3.8. Diagram Use Case 3.3.2. Diagram Activity Activity diagram merupakan diagram yang menggambarkan alur kerja sistem. Diagram ini menunjukkan aktivitas yang menyebabkan suatu objek berada dalam state tertentu. Simbol lingkaran berwarna hitam menandakan awal state sedangkan simbol lingkaran yang dilingkari oleh lingkaran bergaris menandakan akhir state. Diagram activity yang dibuat dalam penelitian ini meliputi use case input data, use case browse, dan use case check data. 30 | Pengembangan e-DoctorSchedule & Hospital Info
Gambar 3.9. Diagram Activity Tabel 3.1. Spesifikasi Naratif Diagram Activity Input Data Use Case user memilih menu input data sistem menampilkan form input sesuai request user input data baru sesuai form yang disediakan sistem melakukan validasi data jika data tidak lengkap sistem menampilkan pesan gagal jika lengkap sistem menampilkan pesan berhasil
Activity State navigate to input data built input form enter and submit data form validation show info failed show info success
3.3.3. Diagram Sequence Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek‐objek yang terkait). Sequence diagram biasa digunakan 31 | Pengembangan e-DoctorSchedule & Hospital Info
untuk menggambarkan skenario atau rangkaian langkah‐langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu.
Gambar 3.10. Diagram Sequence
3.4. Pengambilan Data Live
Pada penelitian ini, pengambilan data untuk pencarian jadwal
rumah sakit secara langsung (live) menggunakan PHP Simple HTML DOM Parser. Sampel data diambil dari 2 rumah sakit berikut : 1. RS Kartika Pulomas (http://rskartikapulomas.com/?Jadwal_Praktik). 2. RS Marinir Cilandak (http://www.rsmarinir.com/jadwal.praktek. php).
Data diambil dari situs masing‐masing rumah sakit. Data yang
diambil (get content) berupa tabel yang berisi jadwal praktek. Cara pengambilan data sebagai berikut dengan membuka halaman situs jadwal praktek, misal jadwal praktek rumah sakit RS Karika Pulomas. Pengambilan konten tabel didasarkan pada class dari tabel tersebut yang 32 | Pengembangan e-DoctorSchedule & Hospital Info
diperoleh dengan melihat sumber halaman jadwal praktek yang sudah dibuka. Berikut adalah contoh script pengambilan konten tabel dengan PHP Simple HTML DOM Parser berdasarkan class tabel :
include('simplehtmldom/simple_html_dom.php');
include('common.php');
$link = dbConnect();
$html = file_get_html('http://rskartikapulomas.com/?Jadwal_ Praktik');
foreach($html‐>find('p.MsoNormal, p.MsoNoSpacing') as $e)
{
$data[] = $e‐>plaintext."|";
unset($data[138]);unset($data[139]);unset($data[140]);
}
Hasil dari data yang diambil akan berupa data String, sehingga tidak
bisa ditampilkan sesuai dengan standarisasi tampilan yang ada, yaitu berupa tabel. Karena itu, data tersebut harus diubah menjadi array yang bisa dilihat pada perintah berikut : $data[] = $e‐>plaintext."|";
Array yang telah terbentuk displit untuk merapikan tata letaknya.
Hal itu dikarenakan pada situs RS Kartika pulomas, spesialisasi memiliki konten yaitu nama masing‐masing dokter yang ada, hari serta jam jadwal praktek dokter tersebut, seperti yang ditunjukkan pada Gambar 3.8.
33 | Pengembangan e-DoctorSchedule & Hospital Info
Gambar 3.11. Tampilan Jadwal Praktek RS Kartika Pulomas Berikut adalah script split jadwal berdasarkan spesialis : $rumahsakit = "RS Kartika Pulomas"; $datastring = ""; for($i = 0; $i < sizeof($data); $i++) {
$datastring = $datastring.$data[$i];
} echo $datastring; //Split jadwal diurut dari spesialisasi terakhir di tabel jadwal praktek rs kartika pulomas
$gigisplit = explode("GIGI & MULUT", $datastring);
$gigi = $gigisplit[1];
$matasplit = explode("MATA", $gigisplit[0]);
$mata = $matasplit[1];
$thtsplit = explode("THT", $matasplit[0]);
$tht = $thtsplit[1]."THT".$thtsplit[2];
$umumsplit = explode("UMUM/IGD", $thtsplit[0]);
34 | Pengembangan e-DoctorSchedule & Hospital Info
$umum = $umumsplit[1];
$anaksplit = explode("ANAK", $umumsplit[0]);
$anak = $anaksplit[1];
$sarafsplit = explode("SARAF", $anaksplit[0]);
$saraf = $sarafsplit[1];
$parusplit = explode("PARU", $sarafsplit[0]);
$paru = $parusplit[1];
$dalamsplit = explode("PENY.DALAM", $parusplit[0]);
$dalam = $dalamsplit[1];
$urologisplit = explode("BEDAH UROLOGI", $dalamsplit[0]);
$urologi = $urologisplit[1];
$orthopaedisplit = explode("BEDAH ORTHOPAEDI",
$orthopaedi = $orthopaedisplit[1];
$kardiosplit = explode("BEDAH KARDIO VASKULER", $orthopaedisplit[0]);
$kardio = $kardiosplit[1];
$bedahsplit = explode("BEDAH UMUM", $kardiosplit[0]);
$bedah = $bedahsplit[1];
$digestivesplit = explode("BEDAH DIGESTIVE", $bedahsplit[0]);
$digestive = $digestivesplit[1];
$anestesisplit = explode("ANESTESI", $digestivesplit[0]);
$anestesi = $anestesisplit[1];
$obstetrisplit = explode("OBSTETRI DAN GYNEKOLOGI", $anestesisplit[0]);
$obstetri = $obstetrisplit[1];
$urologisplit[0]);
Data yang sudah displit kemudian dimasukkan ke dalam database.
berikut contoh script insert ke database : /*/Untuk OBSTETRI DAN GYNEKOLOGI**/ $jObstetri = explode("|", $obstetrisplit[1]); //insert jadwal obstetri $spesialisobstetri = "Obstetri Dan Gynekologi"; for($i = 0; $i < sizeof($jObstetri); $i++) {
35 | Pengembangan e-DoctorSchedule & Hospital Info
$indeks_dokter = $i + 1;
$indeks_hari = $i + 2;
$indeks_jam = $i + 3;
if(isset($jObstetri[$indeks_dokter]) && isset($jObstetri[$indeks_hari]) &&
isset($jObstetri[$indeks_jam]))
{
$dokter = str_replace("|", "", $jObstetri[$indeks_dokter]);
$hari = str_replace("|", "", $jObstetri[$indeks_hari]);
$jam = str_replace("|", "", $jObstetri[$indeks_jam]);
$insert = mysql_query("INSERT INTO jadwalpraktek(rumah_sakit, dokter,
spesialis, hari, jam) VALUES('$rumahsakit','$dokter','$spesialisobstetri','$hari','$jam')");
}
$i = $i + 2;
}
/*//end insert obstetri*/
Data yang sudah dimasukkan kedalam database akan ditampilkan
berupa tabel dengan pencarian sesuai dengan kata kunci yang dimasukkan dalam mesin pencariannya. Berikut adalah script pencarian pada database :
include("common.php");
$link = dbConnect();
$search=$_POST["isearch"];
$indeks=$_POST["pilih"];
if ($search != "") {
if ($indeks == "Rumah Sakit"){
$result = mysql_query("SELECT * FROM jadwalpraktek WHERE rumah_sakit LIKE
'%$search%'") or die ('Unable to run query:'.mysql_error());
}elseif ($indeks == "Spesialis"){
$result = mysql_query("SELECT * FROM jadwalpraktek WHERE spesialis LIKE
'%$search%'");
36 | Pengembangan e-DoctorSchedule & Hospital Info
}elseif ($indeks == "Nama Dokter"){
$result = mysql_query("SELECT * FROM jadwalpraktek WHERE dokter LIKE
'%$search%'");}
3.5. Pembuatan Database untuk Data Live
Pada penulisan ini, database hanya digunakan untuk data yang
diperoleh secara langsung. Sedangkan untuk data dummy diinput secara manual pada file RDF sehingga tidak memerlukan database. Untuk membuat database, terlebih dahulu perlu dijalankan beberapa aplikasi pendukung yaitu server, web browser dan phpmyadmin. 1. Menjalankan Server XAMPP Server XAMPP yang sebelumnya telah diinstall dijalankan melalui XAMPP Control Panel sehingga tampil jendela XAMPP Control Panel. 2. Menjalankan Apache dan MySQL Klik tombol start yang berada di sebelah kanan Apache dan MySql untuk memulai sehingga muncul keterangan “Running”. 3. Menjalankan phpMyAdmin pada Web Browser Jalankan web browser kemudian pada kotak address ketik http://localhost/phpmyadmin
untuk
membuka
halaman
phpmyadmin. Pada bagian Create new database masukkan nama database yang ingin dibuat. Dalam hal ini penulis membuat database dengan nama “jadwalpraktek”. Klik tombol Create untuk membuat database.
4. Membuat tabel Setelah membuat database, maka langkah selanjutnya adalah membuat tabel untuk menampung data yang sudah diambil, terdapat 1 buah tabel dengan struktur seperti berikut : 37 | Pengembangan e-DoctorSchedule & Hospital Info
Tabel 3.2. Struktur Data Tabel Jadwal Praktek Nama Field
Tipe
Ukuran
Keterangan
id
bigint
20
Id jadwal perdokter
rumah_sakit
text
‐
Nama rumah sakit
dokter
text
‐
Nama dokter
spesialis
text
‐
Spesialisasi dokter
hari
text
‐
Hari praktek
jam
text
‐
Jam praktek
3.6. Struktur RDF untuk Data Dummy
Format representasi data untuk web semantik adalah RDF (Resource
DescriptionFramework). RDF merupakan sebuah model standar untuk pertukaran data pada web. Berikut ini adalah struktur dari RDF Bird yang akan ditampilkan pada web entry data telah dibuat :
38 | Pengembangan e-DoctorSchedule & Hospital Info
<ns1:isA>Dokter <ns1:hasNama> Dr. A. Asrorudin, SpU <ns1:hasSpesialis> bedah umum <ns1:hasRumahsakit>fatmawati <ns1:hasHari> Senin <ns1:hasJam>08:00 ‐ 09:25 <ns1:hasAlamat>Jl. RS Fatmawati, Cilandak ‐ Jakarta Selatan <ns1:hasTelp>021‐7501524
3.6.1. RDF Graph untuk Jadwal Dokter Pada Struktur RDF untuk semantik Jadwal Dokter berikut ini, terdapat 6 komponen class utama yaitu Nama Dokter, Rumah Sakit, Spesialis, Hari, Waktu, dan Website. Masing‐masing class memiliki object properties sebagai berikut : hasNama, hasRumahsakit, hasSpesialis, hasHari, hasJam, dan hasWebsite. Domain dari tiap properties adalah class Jadwal Dokter, sedangkan class lainnya berfungsi sebagai range.
Gambar 3.12. Struktur RDF Graph Jadwal Dokter 3.6.2. Property Class Sebuah class jika berdiri sendiri tidak akan memberikan informasi yang cukup dari apa yang kita inginkan dari RDF ini. Sekali kita mendefinisikan sebuah atau beberapa kelas, maka kita harus 39 | Pengembangan e-DoctorSchedule & Hospital Info
mendefinisikan atau menjelaskan struktur dari internal dari konsep yang akan kita bangun dari class‐class tersebut.
Kita telah menentukan class‐class yang kita akan gunakan. Setiap
class mempunyai sebuah objek property, yaitu antara lain class nama dokter mempunyai objek propety yaitu has nama, class hari mempunyai object property yaitu has hari, class rumah sakit mempunyai objek property yaitu has rumahsakit, class spesialis mempunyai objek property yaitu has spesialis, class waktu mempunyai objek property has jam, class website mempunyai objek property has website.
Setiap class‐class mempunyai beberapa member list, member list
ialah sebuah data dari suatu class. Dalam pembuatan struktur semantik jadwal dokter ini, data cobtoh diperoleh dari beberapa website rumah sakit, di sini ada 10 rumah sakit yang dijadikan sebuah contoh. Setiap rumah sakit diambil dua jadwal dokter yang memenuhi kriteria terdapat nama dokter, nama rumah sakit, spesialis, hari, jam. 3.6.3. Model Data Graph Pada pengembangan aplikasi ini dimulai dengan membuat rancangan model data RDF yang diberi nama Jadwal Dokter. Model data tersebut nantinya akan dijadikan acuan dalam mengimplementasikan metadata Jadwal Dokter. Berdasarkan model data tersebut juga akan ditentukan bagaimana aplikasi melakukan proses pencarian jadwal dokter berdasakan konteksnya.
Model data RDF Graph adalah simbolik dari desain struktur
semantik yang akan dibuat. Model graph ini akan dapat diaplikasikan secara langsung dalam aplikasi yang dibuat yang dibuat, model ini lebih menekankan pada desain data yang akan menggambarkan relasi antara
40 | Pengembangan e-DoctorSchedule & Hospital Info
property dari RDF. Dengan melihat graph ini akan mempermudah melihat desain data secara menyeluruh.
Gambar 3.13. Model OntoGraf Semantik Jadwal Dokter Gambar 3.13 di atas adalah model data untuk struktur semantik Jadwal Dokter yang menggambarkan hubungan antara property dengan domain, property dengan range, dan suatu kelas dengan kelas yang lain. Gambar 3.3 di atas di deskripsikan pada Tabel 3.3 di bawah ini. Tabel 3.3. Deskripsi property Jadwal Dokter Nama Property
Domain
Range
Tipe Property
Has_hari
Jadwal Dokter
Hari
Class
Has_jam
Jadwal Dokter
Waktu
Class
Has_nama
Jadwal Dokter
Nama Dokter
Class
Has_rumah sakit
Jadwal Dokter
Rumahsakit
Class
Has_spesialis
Jadwal Dokter
Spesialis
Class
Has_website
Jadwal Dokter
Website
Class
41 | Pengembangan e-DoctorSchedule & Hospital Info
3.6.4. Model Data RDF Dari desain data model data OWL Graph, selanjutnya akan diterjemahkan ke dalam bentuk OWL XML. OWL XML maksudnya adalah model data dalam bentuk OWL yang ditempelkan ke dalam defile XML yang mengikuti aturan tata tulis XML. Penggunaan XML OWL di sini bertujuan agar aplikasi dapat membaca dan melakukan query pada model data tersebut. OWL XML juga merupakan bentuk standart yang direkomendasikan oleh W3C , karena dalam bentuk XML sintak, model dapat ditempatkan di internet dan dibaca oleh aplikasi web lainnya. Sedangkan model data RDF dibuat untuk mendeskripsikan antara sumber‐ sumber daya yang merupakan properties dan values. 3.6.5. Representasi Pemetaan pada RDF/OWL Resource Description Framework (selanjutnya disebut RDF) adalah satu bahasa berbasis XML‐based untuk menciptakan metada tentang sumber daya informasi di Web. Model metadata didasarkan pada suatu sumber daya yang dapat berupa potongan informasi dengan suatu nama yang unik yang disebut Uniform Resource Identifier (URI). URI dapat menjadi tidak hanya sebagai Unique Resource Locators (URILs) yang dikenal dari halaman web konvensional tetapi juga tagged informasi yang dimasukkan di suatu halaman atau pada definisi‐definisi RDF yang lain. Struktur dari RDF adalah sangat sederhana: satu kumpulan statemen‐ statemen berbentuk suatu graf berarah yang berlabel di mana sumber daya diwakili oleh simpul‐simpul, dan hubungan‐hubungan antara sumber daya oleh panah berarah (arcs). Ini diberi label dengan nama dari hubungan.
Secara lebih umum, RDF juga digunakan untuk merepresentasikan
informasi lainnya yang dapat diidentifikasi di web. Di antara karakteristik utama dari RDF, fitur yang paling penting bagi pendekatan yang 42 | Pengembangan e-DoctorSchedule & Hospital Info
dikembangkan dalam adalah bahwa RDF menyediakan satu kerangka kerja untuk mengekspresikan metadata sumberdaya dan informasi semantik yang terkait untuk mengijinkan pertukaran data diantara aplikasi. RDF menggunakan identifier web yang unik (URI) untuk mengidentifikasi sumber daya yang terkandung dalam domain yang ada.
Sintaks dasar terdiri dari satu elemen rdf:Description, yang berisi
satu himpunan elemen property. Rdf:attribute mengidentikasi sumberdaya yang digambarkan. Sementara property rdf:type digunakan untuk mengekspresikan bahwa sebuah sumberdaya adalah anggota dari class yang diberikan atau seperti property tipe instant dari link yang digunakan oleh jaringan semantik dan system frame. Terdapat banyak variasi dari singkatan dalam sintaks RDF, untuk menghindari konflik penamaan diantara kosakata yang berbeda, RDF menggunakan satu XML namespaces pada tiap kosakata.
Perangkat lunak dapat menyediakan dukungan daur hidup yang
lengkap dari model RDF. Para Editor dan konvertor tersedia untuk pembuatan penyajian‐penyajian RDF schema sejak awal mula atau dokumen desain perangkat lunak. Perangkat bantu anotasi mendukung pengguna untuk pengikatan uraian RDF ke halaman web dan sumber daya informasi yang lain baik secara manual atau semi otomatis dengan menggunakan teknik natural language processing.
Sebagai suatu tanggapan untuk kebutuhan penggambaran model
yang digunakan bersama dari isi web, bahasa ontology Web (OWL) sudah dikembangkan. OWL, sebagai rekomendasi W3C, adalah satu bahasa yang didasarkan pada RDF. Data RDF dapat terhubung dengan model OWL melalui penggunaan class dan hubungannya di dalam uraian metadata. Definisi tambahan yang sesuai didalam model OWL menetapkan batasan 43 | Pengembangan e-DoctorSchedule & Hospital Info
kebenaran dan penafsiran metadata. Sejumlah reasoning tools telah dikembangkan untuk mengecek batasan ini serta mengambil kesimpulan pengetahuan yang baru (yaitu, keanggotaan class dan hubungan‐hubungan subclass).
Ontology Web Language (OWL) dirancang untuk digunakan aplikasi
yang membutuhkan pemrosessan konten informasiyang tidak hanya disajikan untuk pengguna. OWL memfasilitasi kemampuan interpretasi mesin yang lebih besar tentang konten web dan OWL didukung oleh XML,RDF dan RDF schema (RDF‐S) dengan menyediakan kosakata tambahan dengan semantik formal. OWL menggunakan baik URI untuk penamaan dan kerangka kerja deskripsi bagi web yang disediakan oleh RDF untuk menambah kemampuan bagi ontology, seperti openness, extensibility, scalability dan terdistribusi pada banyak system. OWL dibangun pada RDF dan skema RDF dan menambah lebih banyak kosakata untuk menggambarkan property dan class, relasi diantara class (missal, disjointness), kardinalitas (missal, exactly one), equality, properti tipe yang lebih kaya, karakteristik dari property (missal, simetri), dan daftar spesifikasi class. OWL mempunyai tiga sub bahasa yang ekspresif: OWL Lite, OWL DL, dan OWL full. 3.6.6. Representasi Query Sebagian besar dari data yang ada di dunia ditemukan di dalam basis data, terutama basis data relational. Bahkan sejumlah data yang lebih besar berada dalam file biasa, email archives, dan semacamnya. Integrasi dari semua data. RDF adalah satu bahasa untuk Web yang dapat merepresentasikan, data seragam dari sumber berbeda. SPARQL, satu bahasa query untuk RDF, dapat menggabungkan data dari basis data berbeda, demikian pada 44 | Pengembangan e-DoctorSchedule & Hospital Info
dokumen, atau lain‐lain yang mungkin menyatakan pengetahuannya sebagai sebuah grafik berarah yang berlabel. SPARQL adalah satu bahasa yang baik untuk menyatukan data dalam basis data relational dengan basis data lain, demikian pula sumber data lain.
Kemunculan web semantik telah mengilhami beberapa pintu
gerbang antara RDF dan penyimpanan relational konvensional. Sistem seperti Virtuoso, D2RQ dan SquirrelRdf menulis kembali query SPARQL ke SQL. Oracle release 10.2 dan MySQL SPASQL modul menyusun query SPARQL secara langsung ke dalam satu struktur evaluasi yang akan dieksekusi oleh mesin relational. Penambahan native SPARQL yang mendukung ke basis data memungkinkan kinerja yang sama seperti SQL Query.
Basis data Relational yang konvensional adalah yang paling umum
diakses melalui SQL. Hubungan antara data di dalam basis data yang berbeda dikelola oleh tool data warehouse khusus yang mempunyai pengetahuan spesifik tentang satu kumpulan basis data dan adanya view dari data yang disatukan. Ketika jumlah data berkembang, interaksi akan berkembang secara eksponensial, teknik data warehouse yang konvensional tidak praktis untuk sejumlah besar sumber data.
Satu tantangan dalam mengintegrasikan sumber data relational
yang berbeda di dalam satu query tunggal adalah kebutuhan akan identifier yang umum untuk tuples dan atribut.
RDF secara esensial menyediakan universal grounding ini, dengan
cara menamai semua entitas dan atribut dengan URIs yang merupakan satu bentuk umum dari URLs. Pada RDF, setiap tuple dinyatakan bukan sebagai satu proposisi n‐ary dengan slot bernama, tetapi sebagai kumpulan proposisi biner dengan hubungan nama dari slot‐slot. Salah satu dari 45 | Pengembangan e-DoctorSchedule & Hospital Info
permasalahan paling besar dalam mengintegrasikan data dari sumber yang berlainan, sekallipun mereka semua basis data SQL yang dikelola oleh DBMS dari pelaksana yang sama, adalah penemuan cara‐cara untuk mencocokan data dalam satu database ke data yang mempunyai semantik yang sama dalam basis data lain.
SPARQL sebenarnya terdiri dari tiga spesifikasi yang terpisah, yakni
Spesifikasi bahasa query, hasil dalam bentuk XML dan protocol akses data yang menggunakan WSDL 2.0. Spesifikasi bahasa query (query language) yang merupakan inti. Tetapi di samping itu query menghasilkan bentuk XML, menguraikan satu bentuk XML untuk menjadikan hasil‐hasil yang serial dari suatu query SPARQL SELECT. Bentuk sederhana ini dengan mudah bias diproses dengan tool XML yang umum seperti XSLT.
Spesifikasi yang ketiga adalah protocol akses data yang
menggunakan WSDL 2.0 untuk menggambarkan protocol‐protokol HTTP dan SOAP sederhana untuk secara remote melakukan query RDF database. (Atau, untuk melakukan query ke setiap tempat penyimpanan data yang dapat dipetakan dalam model RDF). Hasil dalam format XML digunakan untuk
menghasilkan
tanggapan‐tanggapan
dari
layanan
yang
menggunakan protocol ini.
Secara keseluruhan, SPARQL terdiri dari satu bahasa query, yang
menyampaikan suatu query ke suatu layanan prosesor query, dan format XML yang merupakan format hasil query yang dihasilkan.
SPARQL adalah satu bahasa query untuk RDF. Subset SPARQL
digunakan dalam penulisan ini dapat digambarkan sebagai : [prefix declarations] SELECT WHERE { graph pattern }
SPARQL
meliputi
sejumlah
sintaksis
shorcuts
yang
menyederhanakan penulisan pola. 46 | Pengembangan e-DoctorSchedule & Hospital Info
PREFIX table : http://www.daml.org/2003/01/periosictable/periodicTable.owl SELECT * FROM http://www.daml.0rg/2003.01/periodictable/periodictable.owl WHERE { ?element table:name ?name;
Table:symbol ?symbol;
table :atomicnumber ? number; }
Contoh di atas menggunakan dua shortcut. Pertama sudah familiar
bagi para pemakai SQL yakni *. Shortcut ini berarti “menghasilkan semua variable menjadi terdaftar dalam pola graf”. Ini menyederhanakan sintaksis dibandingkan harus memperinci setiap variable yang akan digunakan. Shortcut kedua secara formal, penggunaan satu daftar predikat‐ objek. Shortcut ini memungkinkan seorang pembuat query untuk membuat daftar subjek dari satu rangkaian pola triple hanya sekali. Ketika menggunakan bentuk ini, masing‐masing pola triple diakhiri dengan satu titik koma bukan titik. Shortcut ini mungkin digunakan ketika beberapa pola melakukan pamakaian subjek yang sama.
Graf RDF seringkali berbentuk semi‐structured; beberapa data
mungkin saja tidak tersedia atau tidak dikenal. SPARQL berikut membahas satu contoh untuk menggambarkan masalah ini. PREFIX table: http://www.daml.org/2003/01/periodictable/PeriodicTable#> SELECT ?name ?symbol ?number ?color FROM
47 | Pengembangan e-DoctorSchedule & Hospital Info
?element table:name ?name ?element table:symbol ?symbol ?element table:atomic number?number ?element table:color ?color }
Pada contoh pola di atas telah memperluas pernyataan SELECT
untuk menyertakan variable baru, yakni color, dan juga telah menambahkan satu pencocokan untuk properti (table:color) ke pola graf.
3.7. Rancangan Tampilan
Rancangan tampilan merupakan perkiraan dari tampilan yang
diinginkan dan disertai dengan penjelasan dari tiap bagian. Pada sistem berbasis web ini, terdapat satu tampilan, yaitu tampilan halaman user biasa. Halaman user dapat digunakan oleh siapa saja. Pada tampilan halaman user terdapat beberapa menu halaman yaitu halaman Home, KJS, About, Semantic, dan Contact.. 3.7.1. Rancangan Tampilan Halaman User Pada bagian ini penulis akan menampilkan rancangan halaman dari sisi user berikut dengan penjelasannya.
48 | Pengembangan e-DoctorSchedule & Hospital Info
Gambar 3.14. Rancangan Halaman User
Halaman ini terdiri dari judul web, daftar menu, teks yang
menjelaskan sedikit fungsi aplikasi, kolom search, slide gambar, informasi singkat mengenai website dan footer.
Menu pertama adalah menu Home yang akan menampilkan
halaman home. Pada halaman ini, terdapat dua form pencarian untuk mencari jadwal dokter dan untuk mencari fasilitas yang ada di rumah sakit tertentu.
Menu kedua adalah menu KJS yang akan menampilkan informasi
lengkap seputar KJS.
Menu ketiga adalah menu About yang akan menampilkan
penjelasan singkat tentang aplikasi dan profile pembuatnya.
Menu keempat adalah menu Semantic yang berupa menu dropdown
yang terdiri dari tiga menu yaitu menu Search, Graph dan Datagrid. Menu Search akan menampilkan pencarian dimana data diinput manual dengan 49 | Pengembangan e-DoctorSchedule & Hospital Info
file RDF. Menu Graph akan menampilkan data dari setiap jadwal dokter rumah sakit yang telah dimasukkan berupa tampilan graph. Menu Datagrid akan menampilkan data dari setiap jadwal dokter rumah sakit yang telah dimasukkan berupa tampilan tripel RDF yang terdiri atas subjek, predikat dan objek.
Menu kelima adalah menu Contact. Pada bagian ini, ditampilkan
nama dan alamat email dari penulis. Hal ini dilakukan untuk mengantisipasi pertanyaan‐pertanyaan yang berkenaan dengan web ini.
3.8. Struktur Navigasi
Struktur navigasi digunakan untuk menggambarkan fungsi‐fungsi
yang ada pada seluruh halaman sistem yang dibuat. Struktur navigasi dari sistem yang akan dibuat terdiri dari struktur navigasi untuk pengguna yang berlevel user biasa. Berikut adalah penggambarannya:
Gambar 3.15. Struktur Navigasi Campuran
50 | Pengembangan e-DoctorSchedule & Hospital Info
BAB IV. PANDUAN APLIKASI HOSPITALINFO Berikut ini adalah panduan penggunaan untuk aplikasi HospitalInfo yang berbasis web semantik.
4.1. Halaman Home
Halaman Home merupakan halaman awal yang akan muncul ketika pengguna pertama kali mengakses situs dan berisi sedikit penjelasan mengenai situs HospitalInfo. Selain itu, terdapat search jadwal praktek dokter berdasarkan data live (data yang diambil secara langsung dari situs resmi masing‐masing rumah sakit) dan search fasilitas rumah sakit. 51 | Pengembangan e-DoctorSchedule & Hospital Info
Search Jadwal Dokter Terdapat 3 kategori pencarian : 1. Pencarian berdasarkan nama Rumah Sakit 2. Pencarian berdasarkan Spesialisasi 3. Pencarian berdasarkan Nama Dokter Untuk melakukan pencarian, pilih terlebih dahulu kategori yang diinginkan. Kemudian masukkan kata kunci pencarian, lalu pilih cari. Maka akan muncul hasil sebagai berikut :
Search Fasilitas Rumah Sakit Untuk pencarian fasilitas, cukup memilih nama rumah sakit yang diinginkan dan pilih cari untuk menampilkan hasilnya.
52 | Pengembangan e-DoctorSchedule & Hospital Info
4.2. Halaman KJS
Halaman ini berisi informasi mengenai Kartu Jakarta Sehat (KJS). 53 | Pengembangan e-DoctorSchedule & Hospital Info
4.3. Halaman About
Halaman ini berisi informasi tentang aplikasi dan administrator aplikasi.
54 | Pengembangan e-DoctorSchedule & Hospital Info
4.4. Halaman Search untuk Data Dummy
Halaman ini merupakan pencarian untuk data dummy atau data yang diinput secara manual dengan script RDF. Search Jadwal Dokter Terdapat 3 kategori pencarian : 1. Pencarian berdasarkan nama Rumah Sakit 2. Pencarian berdasarkan Spesialisasi 3. Pencarian berdasarkan Nama Dokter Untuk melakukan pencarian, pilih terlebih dahulu kategori yang diinginkan. Kemudian masukkan kata kunci pencarian, lalu pilih cari. Maka akan muncul hasil sebagai berikut :
55 | Pengembangan e-DoctorSchedule & Hospital Info
Search Fasilitas Rumah Sakit Untuk pencarian fasilitas sama dengan pencarian fasilitas sebelumnya, cukup memilih nama rumah sakit yang diinginkan dan pilih cari untuk menampilkan hasilnya.
56 | Pengembangan e-DoctorSchedule & Hospital Info
4.5. Halaman Graph
Halaman ini untuk menampilkan ontology graph dari script RDF yang telah dibuat untuk data dummy, user dapat merubah bentuk, ukuran dan label dari graph tersebut berdasarkan pilihan yang disediakan di atas graph.
4.6. Halaman Data Grid
57 | Pengembangan e-DoctorSchedule & Hospital Info
Halaman ini untuk menampilkan data grid dari script RDF yang telah dibuat untuk data dummy.
4.7. Halaman Kontak
Halaman ini digunakan apabila user ingin mengirim pertanyaan atau saran pada administrator. Cukup dengan menuliskan nama, e‐mail dan pesan yang diinginkan kemudian pilih submit untuk mengirim dan reset untuk memperbaiki isi form atau membatalkan pengiriman.
58 | Pengembangan e-DoctorSchedule & Hospital Info
DAFTAR PUSTAKA
[1] Amiril Muslimin.; Waskitho Wibisono dan Daniel O. Siahaan. 2006. Image
Search Engine Using Semantic Web. Informatics Department Digital Library. Surabaya : ITS. [2] Bornier, E and Lee Provoost. 2006. “Service‐Oriented Architecture and the Semantic Web: A killer combination?”. Published Thesis. Utrecht : University of Utrech. [3] Champin, P. A. 2001. RDF Tutorial, http://classweb.gmu.edu/kersch/ infs770/OntologyLecture/rdf‐tutorial.pdf, diakses tanggal : 17 April 2013. [4] Daniel O. Siahaan. 2004. “Transformation from Semantic Data Model to RDF”. JUTI Jurnal Ilmiah Teknologi Informasi FTIF ITS. Edisi: 3. Vol: 2. ISSN:1412‐6389. [5] ___________. 2006, Graphical Notations For Semantic Web Language. Informatics Department. Faculty of Information Technology. Surabaya : Sepuluh Nopember Institute of Technology. [6] Dermawan. 2010. “Pemetaan Ontology pada Sumber Data Heterogen di Tingkat Semantik dengan Domain Rumah”. Skripsi. Fakultas Teknologi Industri, Jakarta : Universitas Gunadarma. [7] Dumbill, E. 2000. The Semantic Web : A Primer, http://www.xml.com/pub /a/2000/11/01/semanticweb/index.html. diakses tanggal : 17 April 2013. [8] Futty Pratiwi. 2010. “Sistem Informasi Keanekaragaman Hayati Unggas di Indonesia Berbasis Web Semantik”. Skripsi. Fakultas Ilmu Komputer dan Teknologi Informasi. Jakarta : Universitas Gunadarma. [9] H. Bayuputera. 2006. Studi Kasus : Implementasi Ontology. http://www. docstoc.com/docs/22431401/Studi‐Kasus‐Implementasi‐Ontology. diakses tanggal : 18 April 2013. [10] I Wayan Simri Wicaksana. 2004. Survei dan Evaluasi Metode Pengembangan Ontologi (Survey and Evaluation of Methodology of Ontology Development). Jakarta : Universitas Gunadarma. [11] ________________. 2006. Ontology: Bahasa dan Tools Protégé. Jakarta : Universitas Gunadarma. [12] Imam Mulya. 2010. “Aplikasi Pencarian Informasi untuk Jadwal Dokter Berbasis RDF”. Skripsi. Fakultas Ilmu Komputer dan Teknologi Informasi. Jakarta : Universitas Gunadarma. [13] Janjic, V. 2011. PHP Simple HTML DOM Parser: Editing HTML Elements in PHP, http://www.phpbuilder.com/columns/PHPHTMLDOM parser/ PHPHTMLDOMParser.cc_09‐07‐2011.php3, diakses tanggal : 13 Mei 2013.
59 | Pengembangan e-DoctorSchedule & Hospital Info
[14] Kris Triyantio. 2006. Perbandingan Tool Untuk Membangun Ontology
Berbasis RDF/OWL Dan Ilustrasi Implementasinya. Jakarta : Universitas Gunadarma. [15] Lily Wulandari. 2009. “Query Rewriting berbasis Ontology dan Mapping untuk Mencapai Interoperabilitas pada Sumber Data Heterogen di Tingkat Semantik”. Disertasi. Jakarta : Universitas Gunadarma. [16] Niko Ibrahim. 2007. Pengembangan Aplikasi Semantic Web Untuk Membangun Web yang lebih Cerdas. Bandung : Universitas Kristen Maranatha. [17] PHP Simple HTML DOM Parser. 2013. http://simplehtmldom.source forge.net/. diakses tanggal : 31 Mei 2013. [18] Protégé. 2013. http://protege.stanford.edu/. diakses tanggal : 8 Mei 2013. [19] RDF API. 2013. http://www.seasr.org/wp‐content/plugins/meandre/ rdfapi‐php/doc/index.html. diakses tanggal : 7 Mei 2013. [20] RDF Primer. 2013. http://www.w3.org/TR/rdf‐primer/. diakses tanggal : 30 April 2013. [21] Stojanovic, L; Steffen Staab and Rudi Studer. e‐Learning based on the Semantic Web. Karlsruhe : University of Karlsruhe.
60 | Pengembangan e-DoctorSchedule & Hospital Info