Aplikasi Pencarian Jadwal Dokter Dan Fasilitas Rumah Sakit e Doctor Schedule & Hospital Info Berbasis Web Semantik

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

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



DAFTAR ISI
KATA PENGANTAR 3
DAFTAR ISI 5
BAB I. PENDAHULUAN 7
BAB II. LANDASAN TEORI 11
2.1. WEB SEMANTIK 11
2.2. ONTOLOGI 13
2.3. RDF (RESOURCE DESCRIPTION FRAMEWORK) 14
2.4. OWL (ONTOLOGY WEB LANGUAGE) 14
2.5. PEMODELAN DATA SEMANTIK 15
2.6. INTEROPERABILITAS 16
2.7. PROTÉGÉ 17
2.8. SIMPLE HTML DOM PARSER 18
BAB III. METODE, ANALISIS DAN PERANCANGAN 21
3.1. METODE PENELITIAN 21
3.2. ANALISIS DAN PEMECAHAN MASALAH 22
3.2.1. ANALISIS KEBUTUHAN 22
3.2.2. ANALISIS MASALAH 22
3.2.3. PENDEFINISIAN MASALAH 22
3.2.4. PEMECAHAN MASALAH 23
3.3. PEMODELAN SISTEM 30
3.3.1. DIAGRAM USE CASE 30
3.3.2. DIAGRAM ACTIVITY 30
3.3.3. DIAGRAM SEQUENCE 31
3.4. PENGAMBILAN DATA LIVE 32
3.5. PEMBUATAN DATABASE UNTUK DATA LIVE 37
3.6. STRUKTUR RDF UNTUK DATA DUMMY 38
3.6.1. RDF GRAPH UNTUK JADWAL DOKTER 39
3.6.2. PROPERTY CLASS 39
3.6.3. MODEL DATA GRAPH 40
3.6.4. MODEL DATA RDF 42
3.6.5. REPRESENTASI PEMETAAN PADA RDF/OWL 42
3.6.6. REPRESENTASI QUERY 44

3.7. RANCANGAN TAMPILAN 48
3.7.1. RANCANGAN TAMPILAN HALAMAN USER 48
3.8. STRUKTUR NAVIGASI 50
BAB IV. PANDUAN APLIKASI HOSPITALINFO 51
4.1. HALAMAN HOME 51
4.2. HALAMAN KJS 53
4.3. HALAMAN ABOUT 54
4.4. HALAMAN SEARCH UNTUK DATA DUMMY 55
4.5. HALAMAN GRAPH 57
4.6. HALAMAN DATA GRID 57
4.7. HALAMAN KONTAK 58
DAFTAR PUSTAKA 59

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

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

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.



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

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].

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

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].

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.

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

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

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

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 . '<br>';

// Find all links
foreach($html‐>find('a') as $element)
echo $element‐>href . '<br>';
Berikut contoh untuk memodifikasi elemen HTML[17] :
// Create DOM from string
$html = str_get_html('<div id="hello">Hello</div><div id="world">World</div>');

$html‐>find('div', 1)‐>class = 'bar';

$html‐>find('div[id=hello]', 0)‐>innertext = 'foo';

echo $html; // Output: <div id="hello">foo</div><div id="world"
class="bar">World</div>


Berikut contoh untuk mengekstrak konten dari HTML[17] :
// Dump contents (without tags) from HTML
echo file_get_html('http://www.google.com/')‐>plaintext;


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)


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

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.

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

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.


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


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

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

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


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.

Gambar 3.9. Diagram Activity
Tabel 3.1. Spesifikasi Naratif Diagram Activity Input Data
Use Case Activity State
user memilih menu input data navigate to input data
sistem menampilkan form input sesuai
built input form
request
user input data baru sesuai form yang
enter and submit data
disediakan
sistem melakukan validasi data form validation
jika data tidak lengkap sistem
show info failed
menampilkan pesan gagal
jika lengkap sistem menampilkan pesan
show info success
berhasil
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

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

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 :

<?php
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.


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]);

$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", $urologisplit[0]);
$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];

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++)
{

$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
:
<?php
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%'");

}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 :


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 :
<rdf:RDF
xml:base="http://triyanaputri/ontologies/jadwal#"
xmlns:dt="http://foo.org#"
xmlns:Description="http://localhost/triyana/jadwal.owl#"
xmlns:ns2="http://triyanaputri.com/ontologies/jadwal.owl#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:v="http://sampleVocabulary.org/1.3/People#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
xmlns:rdf="http://www.w3.org/1999/02/22‐rdf‐syntax‐ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf‐schema#"
xmlns:ns1="http://www.w3.org/2001/vcard‐rdf/3.0#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:owl="http://www.w3.org/2002/07/owl#">
<rdf:Description
rdf:about="http://triyanaputri.com/ontologies/jadwal.owl#jadwal_dokter0">

<ns1:isA>Dokter</ns1:isA>
<ns1:hasNama> Dr. A. Asrorudin, SpU </ns1:hasNama>
<ns1:hasSpesialis> bedah umum </ns1:hasSpesialis>
<ns1:hasRumahsakit>fatmawati</ns1:hasRumahsakit>
<ns1:hasHari> Senin </ns1:hasHari>
<ns1:hasJam>08:00 ‐ 09:25</ns1:hasJam>
<ns1:hasAlamat>Jl. RS Fatmawati, Cilandak ‐ Jakarta Selatan</ns1:hasAlamat>
<ns1:hasTelp>021‐7501524</ns1:hasTelp>
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

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

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


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
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

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

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

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 <variable list> WHERE { graph pattern }

SPARQL meliputi sejumlah sintaksis shorcuts yang
menyederhanakan penulisan pola.
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 <http:www.daml.org/2003/01/periodictable/PeriodicTable.owl
WHERE
{

?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.


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
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


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.


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.

4.2. Halaman KJS

Halaman ini berisi informasi mengenai Kartu Jakarta Sehat (KJS).
4.3. Halaman About

Halaman ini berisi informasi tentang aplikasi dan administrator aplikasi.


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 :

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.

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


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.


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.

[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.


Aplikasi Pencarian Jadwal Dokter Dan Fasilitas Rumah Sakit e Doctor Schedule & Hospital Info Berbasis Web Semantik

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aplikasi Pencarian Jadwal Dokter Dan Fasilitas Rumah Sakit e Doctor Schedule & Hospital Info Berbasis Web Semantik

Diunggah oleh

Hak Cipta:

Format Tersedia

Aplikasi

Pencarian Jadwal Dokter dan

A. B. Mutiara, A. Muslim, T. Putri, T. Oswari, W. Silfianti

2 | Pengembangan e-DoctorSchedule & Hospital Info

3 | Pengembangan e-DoctorSchedule & Hospital Info

4 | Pengembangan e-DoctorSchedule & Hospital Info

5 | Pengembangan e-DoctorSchedule & Hospital Info

7 | Pengembangan e-DoctorSchedule & Hospital Info

8 | Pengembangan e-DoctorSchedule & Hospital Info

9 | Pengembangan e-DoctorSchedule & Hospital Info

10 | Pengembangan e-DoctorSchedule & Hospital Info

2.1. Web Semantik

11 | Pengembangan e-DoctorSchedule & Hospital Info

12 | Pengembangan e-DoctorSchedule & Hospital Info

13 | Pengembangan e-DoctorSchedule & Hospital Info

2.3. RDF (Resource Description Framework)

2.4. OWL (Ontology Web Language)

14 | Pengembangan e-DoctorSchedule & Hospital Info

2.5. Pemodelan Data Semantik

15 | Pengembangan e-DoctorSchedule & Hospital Info

16 | Pengembangan e-DoctorSchedule & Hospital Info

17 | Pengembangan e-DoctorSchedule & Hospital Info

2.8. Simple HTML DOM Parser

18 | Pengembangan e-DoctorSchedule & Hospital Info

19 | Pengembangan e-DoctorSchedule & Hospital Info

20 | Pengembangan e-DoctorSchedule & Hospital Info

3.1. Metode Penelitian

21 | Pengembangan e-DoctorSchedule & Hospital Info

3.2.1. Analisis Kebutuhan

3.2.2. Analisis Masalah

3.2.3. Pendefinisian Masalah

22 | Pengembangan e-DoctorSchedule & Hospital Info

3.2.4. Pemecahan Masalah

23 | Pengembangan e-DoctorSchedule & Hospital Info

25 | Pengembangan e-DoctorSchedule & Hospital Info

26 | Pengembangan e-DoctorSchedule & Hospital Info

27 | Pengembangan e-DoctorSchedule & Hospital Info

28 | Pengembangan e-DoctorSchedule & Hospital Info

29 | Pengembangan e-DoctorSchedule & Hospital Info

3.3.1. Diagram Use Case

3.3.2. Diagram Activity

30 | Pengembangan e-DoctorSchedule & Hospital Info

3.3.3. Diagram Sequence

31 | Pengembangan e-DoctorSchedule & Hospital Info

3.4. Pengambilan Data Live

32 | Pengembangan e-DoctorSchedule & Hospital Info

33 | Pengembangan e-DoctorSchedule & Hospital Info

34 | Pengembangan e-DoctorSchedule & Hospital Info

35 | Pengembangan e-DoctorSchedule & Hospital Info

36 | Pengembangan e-DoctorSchedule & Hospital Info

3.5. Pembuatan Database untuk Data Live

37 | Pengembangan e-DoctorSchedule & Hospital Info

3.6. Struktur RDF untuk Data Dummy

38 | Pengembangan e-DoctorSchedule & Hospital Info

3.6.1. RDF Graph untuk Jadwal Dokter

3.6.2. Property Class

39 | Pengembangan e-DoctorSchedule & Hospital Info

3.6.3. Model Data Graph

40 | Pengembangan e-DoctorSchedule & Hospital Info

41 | Pengembangan e-DoctorSchedule & Hospital Info

3.6.5. Representasi Pemetaan pada RDF/OWL

43 | Pengembangan e-DoctorSchedule & Hospital Info

3.6.6. Representasi Query