Arsitektur Pertukaran Data Jurnal Digital
Ni Kadek Ayu Anggraeni (1104505050),Ni Putu Sri Merta Suryani (1104505060)
Jurusan Teknologi Informasi, Fakultas Teknik, Universitas Udayana Bukit Jimbaran
1. Pendahuluan
Perubahan persyaratan kelulusan untuk jenjang sarjana yang mewajibkan mahasiswa untuk menulis jurnal ilmiah mendapatkan respon yang kontradiktif. Sisi positif dari kewajiban tersebut adalah secara efektif dapat meningkatkan kondisi pendidikan di Perguruan Tinggi Indonesia. Harapannya adalah agar civitas-civitas perguruan tinggu tertantang untuk mempertajam pengetahuan dan pemahaman terhadap suatu permasalahan di masyarakat sehingga mampu memproduksi jurnal ilmiah yang berkualitas.
Sisi negatifnya adalah masih kurangnya dukungan sumber daya atau resource untuk merealisasikan kebijakan tersebut. Salah satu permasalahan yang ditemui adalah minimnya akses mahasiswa untuk mendapatkan jurnal yang berkualitas, oleh karena masih terdapat sentralisasi data atau akses yang masih dibatasi. Dengan limitasi akses tersebut, maka dikhawatirkan akan terjadi banyak penyimpangan dan menghasilkan jurnal yang tidak memenuhi standard oleh karena ketidaksiapan mahasiswa.
Untuk mengatasi hal tersebut, maka diperlukannya suatu kerjasama pertukaran data jurnal digital sehingga dapat meminimalkan usaha, waktu dan biaya untuk mendapatkan bahan pembuatan jurnal. Pada paper ini akan dibahas mengenai arsitektur pertukaran data jurnal digital dengan menggunakan protocol OAI-PMH atau Open Archive Initiative Protocol for Metadata Harvesting.
2. Landasan Teori 2.1 Protokol Metadata
Protokol metadata adalah rankaian set atau aturan yang diperlukan untuk melakukan pertukaran metadata antara satu sistem ke sistem yang lain. Protokol metadata akan memberikan teknik bagaimana cara untuk memindahkan data antara sistem.
Pada sistem-sistem yang berbeda, ada kemungkinan besar terdapat proses bisnis yang berbeda pula. Protol disini berperan untuk menyelaraskan proses bisnis tersebut sehingga dapat saling bekerjasama. Selain itu, protocol juga digunakan untuk memastikan bahwa kedua sistem ini memiliki pemahaman yang sama terhadap data yang ditukarkan.
a. Web Single Sign-On Metadata Exchange Protocol.
Web Single Sign-On Metadata Exchange Protocol adalah salah satu protokol pertukaran metadata yang sering digunakan. Pada protocol ini, provider dan client masing-masing memiliki beberapa protocol suite. Untuk membangun komunikasi antara provider dan client, protocol ini dapat melakukan penentuan pemakaian protocol suite yang support pada sisi provider dan support juga di sisi client.
b. OAI-PMH.
OAI-PMH merupakan protocol untuk metadata harvesting. Maksud dari metadata harvesting disini adalah suatu proses mengumpulkan deskripsi-deskripsi metadata dari record dokument yang tersimpan di berbagai repository sehingga service dapat dibangun menggunakan metadata dari berbagai tempat.
2.2 Protokol OAI-PMH
OAI-PMH merupakan protokol pertukaran data yang menggunakan metadata dalam format XML. Pertukaran ini terjadi antara server yang berperan sebagai service provider dengan server data provider. Service Provider bertugas untuk mengambil metadata dari data provider dan kemudian menempatkannya pada repositori lokal sedangkan data provider bertugas untuk mempublikasikan metadata koleksi. Mekanisme pertukaran data ini merupakan inti dari protokol OAI-PMH. Protokol ini cukup populer digunakan karena implementasinya yang relatif mudah. Beberapa search engine mengggunakan protokol ini seperti Citeseer dan Google. Citeseer menggunakan OAI-PMH dengan berperan sebagai service provider dan data provider. Google memanfaatkan protokol ini untuk mengambil metadata koleksi digital National Library of Australia.
Protokol OAI-PMH digunakan untuk melakukan pendistribusian metadata sehingga tersedia untuk service yang lain. Protokol ini berbasis pada standard HTTP dan XML, dimana request data dilakukan melalui HTTP dan metadata yang didapatkan adalah dalam format XML yang sesuai dengan standar Dublin Core.
Pada OAI-PMH terdapat dua istilah penting yaitu data provider (penyedia data) dan service provider (penyedia layanan). Data provider adalah pihak pemilik metadata yang ingin didistribusikan ke service yang lain. Kemudian di service provider akan dibangun value-added service atau layanan tambahan seperti interface pencarian. Layanan ini dibangun berdasarkan pada metadata yang dimiliki oleh data provider. Protokol OAI-PMH mampu menghubungkan kedua provider ini, sehingga metadata yang dimiliki tersebut tersedia untuk
di harvest. Harvest adalah proses pengumpulan metadata, dimana metadata yang berasal dari sejumlah respositori akan dikumpulkan dan dijadikan satu kesatuan data store.
Peran utama dari OAI-PMH adalah untuk memfasilitasi pencarian data dalam situasi dimana data tersebut tersimpan didalam respositori independen. Pencarian atau penemuan data dilakukan dengan cara mengeksport metadata dari masing-masing respositori tersebut. Untuk meningkatkan jangkauan interoperabilitasnya, OAI-PMH mewajibkan metadata yang dibangun harus berdasarkan pada Dublin Core.
Berikut adalah beberapa layanan atau service pada OAI-PMH untuk menfasilitasi penemuan metadata:
a. Cross-search user interface.
User dapat melakukan pencarian resource atau data dari pilihan respositori yang tersedia. Setiap respositori akan menediakan metadata resource-nya yang sudah di-harvest oleh service provider.
b. Cross-search application interface.
Service provider dapat memberikan akses ke metadata dimana pencarian dapat melalui protocol lain yang tidak ditawarkan oleh repository yang bersangkutan. Misalnya, pencarian metadata menggunakan protocol SRU/W dan A9, lalu repository akan menyediakan hasil dalam bentuk RSS atau ATOM Feed.
c. Service provider dapat melakukan pengindeksan full text untuk resource tersebut, apabila terdapat identifier resource yang sesuai.
Pada OAI-PMH terdapat beberapa verb atau request. Verb ini menunjukkan jenis operasi yang diminta oleh client ke pada server. Verb digunakan baik untuk mengetahui format metadata yang didukung oleh sebuah respositori digital, untuk mengambil satu koleksi dari server, atau mengetahui kategori-kategori yang disediakan oleh server respositori. Pada Tabel 1 terdapat daftar verb yang dikenali oleh OAI-PMH.
Tabel 1. Daftar Verb OAI-PMH
Verb Fungsi
GetRecord Mengambil satu record koleksi dari server
Identify Mendapatkan versi protokol OAI-PMH yang didukung oleh server, email administrator, sistem penghapusan record, dan tingkat detail dari tanggal.
ListIdentifiers Mendapatkan sekumpulan header koleksi. ListMetadataFormat
s
ListRecords Mendapatkan sekumpulan koleksi sesuai kriteria tanggal atau set tertentu.
ListSets Mendapatkan set (kategori) dari koleksi di server.
Arsitektur OAI-PMH adalah berdasarkan pada arsitektur client server. Untuk lebih jelasnya dapat dilihat pada Gambar 1.
Gambar 1.Data Provider dan Service Provider
Pada Gambar 1 terlihat bagaimana hubungan antara data provider dengan service provider. Jika dikaitkan dengan arsitektur client server, maka service provider disini bertindak sebagai client sedangkan data provider sebagai server.
Pada client atau service provider, terdapat aplikasi bernama harvester. Harvester adalah suatu aplikasi client yang berfungsi untuk melakukan request informasi tentang record-record yang tersimpan pada respositori di server. Harvester akan mengeluarkan request atau verb OAI-PMH, dan harvester ini digunakan untuk melakukan pengumpulan data dari berbagai respositori. Sedangkan respositori adalah server data yang dapat diakses oleh network dan dapat memproses requestOAI-PMH yang dikeluarkan oleh harvester tersebut.
Respositori terdapat disisi server atau data provider. Data provider disini berperan untuk mengeluarkan metadata dari masing-masing respositori ke service provider sehingga dapat di-harvest. Sedangkan untuk konfigurasi respository, OAI-PMH memiliki tiga entitas yakni resource, item dan record. Resource adalah dokumen atau file atau objek yang digambarkan oleh metadata. Item adalah konstituen dari repositori dari mana metadata tentang sumber daya dapat disebarluaskan, dan record adalah metadata dalam bentuk single format
Urutan proses OAI-PMH adalah sebagai berikut:
a. Harvester di sisi service provider akan meminta informasi ke respositori yang tersedia. Permintaan ini dilakukan dengan menggunakan keenam verb atau request OAI-PMH, dan dibawa melalui koneksi HTTP.
b. Data provider akan meneruskan request ke respositori yang bersangkutan. Kemudian data provider mem-publish atau mengirimankan feedback request yaitu berupa metadata dalam bentuk XML.
c. Service provider menerima metadata tersebut, yang kemudian akan di-harvest oleh aplikasi harvester.
d. Service provider mengeluarkan service atau layanan ke user berdasarkan pada hasil harvest.
Pada Gambar 1 tersebut, terlihat bahwa data provider memberikan respon balik dalam bentuk metadata. Akan tetapi, pada kenyataannya terdapat 5 tipe respon yang dikenali oleh OAI-PMH, antara lain:
a. General information.
b. Metadata formats (metadata dalam format XML). c. Set structure.
d. Record identifier. e. Metadata..
Berikut adalah gambar arsitektur OAI-PMH yang lengkap antara request dengan responnya.
Gambar 2. Arsitektur OAI-PMH
Pada Gambar 2, terlihat arsitektur OAI-PMH dengan request dan responnya. Pada service provider terdapat aplikasi harvester yang mengeluarkan request atau verb ke data provider. Masing-masing data provider menyimpan data atau file yang berbeda, berdasarkan pada bentuknya apakah berupa gambar, video atau teks.
Request atau verb dari harvester akan dibawa ke data provider masing-masing. Data provider kemudian memberikan respon balik berupa metadata dari respositori-nya. Selain
metadata tersebut, respon yang lain adalah general information, metadata format, set structure, dan record identifier.
General information adalah servis protocol OAI-PMH yang didukung oleh data provider. Metadata format adalah format metadata yang dimiliki oleh data provider. Sedangkan record identifier merupakan list identifier atau pengenal record yang berada pada data provider tersebut.
2.3 Metadata Dublin Core
Metadata Dublin Core merupakan metadata yang digunakan untuk menggambarkan sumber daya web seperti video, halaman web dan gambar serta juga digunakan dalam menggambarkan sumber daya fisik seperti buku maupun jurnal. Dublin Core juga dikenal dengan nama Dublin Core Metadata Element Set (DCMES) dimana didukung dengan tiga standar dokumen yaitu IETF RFC 5013, ISO Standard 15836-29 dan NISO Standard Z39.85. Metadata ini dapat digunakan juga untuk menggabungkan kosakata metadata dari berbagai standar metadata dan untuk menyediakan interoperabilitas dalam kosakata metadata dalam cloud link data dan implementasi web semantic.
Dublin mengacu pada Dublin, Ohio, USA dimana skema ini dibicarakan tahun 1995 ketika OCLC/NCSA Metadata Workshop yang diselenggarakan oleh Computer Center Online Library (OCLC). Core mengacu pada istilah metadata sebagai broad dan generic yang dapat digunakan untuk menggambarkan berbagai sumber daya. Semantic dari Dublin Core didirikan dan diselenggarakan oleh kelompok internasional dengan disiplin dan professional dari kepustakaan, ilmu komputer, encoding text, museum dan bidang terkait dengan beasiswa dan praktek.
Mulai tahun 2000, komunitas Dubin Core fokus pada “application profiles” dimana gagasan metadata dapat dengan menggunakan Dublin Core dan kosakata khusus lain dalam memenuhi persyaratan impelementasi tertentu. Dengan adanya hal tersebut World Wide Web Consortium memiliki pekerjaan pada model data generic untuk metadata, jatuh temponya Resource Description Framework (RDF). Sebagai bagian dari set DCMI Syarat Metadata, Dublin Core menjadi salah satu kosakata yang populer untuk digunakan dengan RDF dalam konteks movement Linked Data.
Dublin Core Metadata Initiative (DCMI) menyediakan sebuah forum terbuka untuk development standar metadata secara online untuk berbagai keperluan dan model bisnis. Kegiatan DCMI termasuk kelompok kerja consensus, konferensi global dan workshop, penghubung standard dan upaya pendidikan untuk mempromosikan penerimaan yang luas
dari standar metadata dan praktek. Tahun 2008, DCMI dipisahkan dari OCLC dan dimasukkan sebagai entitas mandiri (independen).
Sekarang ini, semua perubahan yang dibuat untuk standar Dublin Core ditinjau oleh DCMI Usage Board dengan konteks dari DCMI Namespace Policy (DCMI NAMESPACE). Kebijakan ini menjelaskan bagaimana istilah yang ada dan ditetapkan batasan pada jumlah perubahan editorial yang diizinkan untuk label, definisi dan komentar dalam penggunaan.
Standar Dublin Core memiliki 2 tingkatan yaitu sederhana dan berkualitas. Dublin Core sederhana terdiri dari 15 elemen sedangkan Dublin Core berkualitas memiliki 3 unsur tambahan yaitu audisence, provenance dan pemegang hak serta kelompok elemen perbaikan (kualifikasi) yang bisa memperbaiki semantic dari unsur-unsur dengan cara-cara yang berguna dalam penemuan sumber daya.
Adapun 15 element pada tingkat Dublin Core sederhana sebagai berikut : a. Judul b. Pencipta c. Subyek d. Deskripsi e. Penerbit f. Kontributor/Penyumbang g. Tanggal h. Jenis i. Format j. Identifier k. Sumber l. Bahasa m. Hubungan n. Liputan/Coverage o. Hak/Right
Setiap elemen Dublin Core merupakan opsional dan dapat diulang. DCMI telah membentuk cara standar untuk memperbaiki elemen dan mendorong penggunaan encoding dan skema kosakata. Tidak ada urutan yang ditentukan dalam Dublin Core untuk menyajikan atau menggunakan unsur-unsur. Dublin Core menjadi standar ISO 15836 tahun 2006 dan digunakan sebagai elemen tingkat basis data untuk deskripsi sumber belajar dalam ISO/IEC 19788-2 Metadata for Learning Resources (MLR)-Bagian 2 : Elemen Dublin Core disiapkan oleh ISO/IEC JTC1 SC36.
Contoh Kode Program:
<meta name="DC.Format" content="video/mpeg; 10 minutes"> <meta name="DC.Language" content="en" >
<meta name="DC.Publisher" content="publisher-name" >
Kode Program 1. Contoh Metadata Dublin Core
Tingkat Dublin Core berkualitas terdapat proses pengembangan Dublin Core menjadi Dublin Core Metadata Element Set (DCMES). Kelompok kerja Dublin Core Metadata Initiative dan DCMI Usage Board berada dalam kesesuaian dengan prinsip-prinsip praktek yang bain untuk kualifikasi elemen metadata Dublin Core.
Elemen perbaikan memberikan sebbuah makna dari unsure yang sempit maupun ke yang lebih spesifik. Unsur ini berbagi makna dari elemen tanpa pengecualian, tetapi dengan lingkup yang lebih terbatas. Prinsip untuk kualifikasi elemen Dublin Core, biasanya disebut dengan Dumb-Down Principle yang berarti bahwa aplikasi yang tidak mengerti mengenai elemen tentu harus dapat mengabaikan kualifikasi dan mengabaikan nilai metadata agar nampak kelihatan wajar tanpa ada pengecualian elemen.Meskipun hal ini dapat menyebabkan beberapa kehilangan spesifitas, nilai sisa elemen (tanpa kualifikasi) harus benar.
Selain perbaikan elemen, tingkat Dublin Core berkualitas mencakup seperangkat pengkodean yang sudah direkomendasikan, yang dirancang untuk membantu dalam interpretasi nilai elemen. Skema ini meliputi kosakata terkontrol dan notasi formal maupun aturan parsing. Sebuah nilai menyatakan menggunakan skema encoding sehingga mungkin dipilih dari kosakata terkontrol misalnya sebuah istilah dari sistem klasifikasi atau kumpulan judul subjek atau string yang diformat sesuai dengan notasi formal seperti 2000-12-31 sebagai ekspresi standar ISO. Apabila skema encoding tidak dipahami oleh aplikasi, nilai mungkin bisa ditentukan oleh pembaca.
Audience, Provenance dan pemegang hak merupakan sebuah elemen tetapi tidak termasuk dalam bagian dari 15 elemen Simple Dublin Core. Ketiga elemen ini digunakan pada tingkat Dublin Core berkualitas. DCMI juga melakukan perbaikan yang kecil dimana kosa kata umum direkomendasikan untuk digunakan dalam tipe elemen dengan kosakata 12 syarat.
Dubin Core Metadata Initiative (DCMI)Metadata Terms adalah himpunan syarat kosakata dari Dublin Core. Himpunan syarat ini termasuk 15 element Dublin Core Metadata Elemet Set serta istilah yang berkualitas. Setiap istilah memiliki url yang unik dan didefinisikan sebagai RDF property.
Tabel 2. RDF Property (1) abstract accessRights accrualMethod accrualPeriodicity accrualPolicy alternative audience available bibliographicCitation conformsTo contributor coverage created creator date dateAccepted dateCopyrighted dateSubmitted description educationLevel extent format Tabel 3. RDF Property (3) hasFormat hasPart hasVersion identifier instructionalMethod isFormatOf isPartOf isReferencedBy isReplacedBy isRequiredBy issued isVersionOf language license mediator medium modified provenance publisher references relation replaces requires rights rightsHolder source spatial subject tableOfContents temporal title type valid
Pilihan sintaks untuk metadata Dublin Core tergantung pada jumlah variable dan “satu ukuran cocok untuk semua” persepsi yang jarang berlaku. Ketika mempertimbangkan sehuah sintaks yang tepat, penting untuk dicatat bahwa konsep Dublin Core dan semantic dirancang untuk sintaks independen dan sama-sama berlaku dalam berbagai konteks, dimana selama metadata dalam bentuk yang sesuai untuk interpretasi baik oleh mesin dan dengan manusia.
Dublin Core Abstract Model menyediakan model referensi pedoman pengkodean Dublin Core tertentu dimana hal ini dapat dibandingkan, terlepas dari sintaks encoding tertentu. Model referensi tersebut memungkinkan pelaksana untuk mendapatkan pemahaman
yang lebih baik dari jenis deskripsi dimana mereka mencoba mengkodekan dan memfasilitasi pengembangan pemetaan yang lebih baik dan terjemahan antara sintaks yang berbeda.
3. Pembahasan 4. Kesimpulan
