Web Semantik dan Data Tertaut mirip dengan ruang dekat: kehidupan tidak ada di sana. Untuk pergi ke sana untuk jangka waktu yang kurang lebih panjang ... yah, saya tidak tahu apa yang mereka katakan di masa kanak-kanak sebagai tanggapan atas "Saya ingin menjadi astronot." Tetapi Anda dapat mengamati apa yang terjadi dan berada di Bumi; Menjadi seorang astronom amatir atau bahkan seorang profesional jauh lebih mudah.
Artikel ini akan fokus pada tren segar, tidak lebih dari beberapa bulan, dari dunia repositori RDF. Metafora dalam paragraf pertama terinspirasi oleh gambar iklan berukuran epik ini .
Isi
I. GraphQL untuk mengakses RDF
II Adaptor untuk MongoDB
III. OLTP vs. OLAP
IV. RocksDB
V. Dukungan LPG
V.1. Model data
V.1.1. Properti Singleton
V.1.2. Reifikasi dilakukan dengan benar
V.1.3. Pendekatan lain
V.2. Bahasa Kueri
VI. Lisensi lebih ketat
I. GraphQL untuk mengakses RDF
Mereka mengatakan bahwa GraphQL mengklaim sebagai bahasa universal untuk mengakses basis data. Bagaimana dengan kemampuan menggunakan GraphQL untuk mengakses RDF?
Di luar kotak, peluang ini disediakan oleh:
Jika repositori tidak memberikan kesempatan seperti itu, itu diimplementasikan secara independen dengan menulis resolver yang sesuai. Ini dilakukan, misalnya, dalam proyek Perancis DataTourisme . Atau Anda sudah bisa menulis apa-apa, tetapi cukup ambil HyperGraphQL .
Dari sudut pandang pengikut ortodoks dari Semantic Web dan Linked Data, semua ini, tentu saja, menyedihkan, karena tampaknya dimaksudkan untuk integrasi yang dibangun di sekitar silo data biasa, dan tidak cocok untuk platform itu (tentu saja, penyimpanan RDF).
Kesan membandingkan GraphQL dengan SPARQL ada dua.
- Di satu sisi, GraphQL tampak seperti kerabat jauh dari SPARQL: ia memecahkan masalah khusus REST untuk mengambil ulang dan banyaknya kueri - tanpa yang, mungkin, tidak mungkin dianggap sebagai bahasa query, bahkan untuk web, dan memiliki "-QL" dalam namanya;
- Di sisi lain, sirkuit kaku GraphQL terganggu. Dengan demikian, "introspektif" -nya tampaknya sangat terbatas dibandingkan dengan refleksivitas penuh RDF. Dan tidak ada analog dengan jalur properti, jadi tidak terlalu jelas mengapa itu adalah "Grafik-".
II Adaptor untuk MongoDB
Tren yang komplementer dengan yang sebelumnya.
- Di Stardog sekarang mungkin - khususnya, semua yang ada di GraphQL yang sama - untuk mengkonfigurasi pemetaan data MongoDB ke dalam grafik RDF virtual;
- Ontotext GraphDB baru-baru ini memungkinkan Anda untuk memasukkan fragmen ke dalam SPARQL pada Permintaan MongoDB.
Berbicara lebih luas, tentang adaptor ke sumber JSON yang memungkinkan lebih atau kurang "on the fly" untuk mewakili JSON sebagai RDF, perlu diingat SPARQL Generate yang sudah lama ada, yang dapat dilampirkan, misalnya , ke Apache Jena.
Meringkas dua tren pertama, dapat dikatakan bahwa penyimpanan RDF menunjukkan kesiapan penuh untuk integrasi dan berfungsi dalam kondisi "penyimpanan multivarian" (persistensi poliglot). Namun, diketahui bahwa yang terakhir ini telah lama ketinggalan zaman, dan multimodel akan menggantikannya. Dan bagaimana dengan multimodeling di dunia penyimpanan RDF?
Singkatnya, tidak mungkin. Saya ingin mencurahkan artikel terpisah dengan topik multimodel DBMS. Sementara itu, Anda dapat melihat bahwa tidak ada DBMS multimodel di mana model utama akan menjadi grafik satu (berbagai dapat dianggap RDF). Beberapa multimodeling kecil - dukungan repositori RDF untuk model grafik LPG alternatif - akan dibahas dalam Bagian V.
III. OLTP vs. OLAP
Namun, Gartner yang sama menulis bahwa multimodeling adalah syarat utama terutama untuk DBMS operasional . Dapat dimengerti: dalam situasi "penyimpanan multivarian," masalah utama muncul dengan transaksionalitas.
Tapi di mana repositori RDF pada skala OLTP - OLAP? Saya akan menjawab seperti ini: baik di sana maupun di sini. Untuk menunjukkan apa yang dimaksudkan, beberapa singkatan ketiga diperlukan. Atau, saya sarankan OLIP - Online Intellectual Processing.
Namun, tetap saja:
- Mekanisme integrasi GraphDB diimplementasikan dengan MongoDB tidak sedikit dirancang untuk menghindari masalah kinerja penulisan;
- Stardog melangkah lebih jauh dan sepenuhnya menulis ulang mesin, sekali lagi dengan tujuan meningkatkan kinerja perekaman.
Sekarang izinkan saya memperkenalkan pemain baru ke pasar. Dari pencipta IBM Netezza dan Amazon Redshift - AnzoGraph . Gambar dari iklan produk berdasarkan itu ditempatkan di awal artikel. AnzoGraph memposisikan dirinya sebagai solusi GOLAP. Bagaimana Anda menyukai SPARQL dengan fungsi jendela? -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV. RocksDB
Di atas, sudah ada tautan ke pengumuman Stardog 7 Beta, yang mengatakan bahwa Stardog akan menggunakan RocksDB sebagai sistem penyimpanan yang mendasarinya - penyimpanan nilai kunci, garpu Facebook dari LevelDB Google. Mengapa layak berbicara tentang tren tertentu?
Pertama, dilihat dari artikel Wikipedia , tidak hanya repositori RDF yang ditransfer ke RocksDB. Ada proyek menggunakan RocksDB sebagai mesin penyimpanan di ArangoDB, MongoDB, MySQL dan MariaDB, Cassandra.
Kedua, proyek (yaitu, bukan produk) dari subjek yang sesuai sedang dibuat di RocksDB.
Misalnya, eBay menggunakan RocksDB di platform untuk "grafik pengetahuan" -nya. Ngomong-ngomong, itu menyenangkan untuk dibaca: bahasa query dimulai sebagai format yang dikembangkan, tetapi baru-baru ini telah ditransisikan menjadi lebih seperti SPARQL . Seperti dalam lelucon: tidak peduli berapa banyak grafik pengetahuan yang kita lakukan, kita masih mendapatkan RDF.
Contoh lain adalah Layanan Kueri Sejarah Wikidata , yang muncul beberapa bulan lalu. Sebelum kemunculannya, Wikidata harus mengakses API Mediawiki standar melalui MWAPI . Sekarang banyak kemungkinan pada SPARQL murni. "Di bawah tenda" ada juga RocksDB. Ngomong-ngomong, WDHQS melakukannya, tampaknya, orang yang mengimpor Freebase ke dalam Grafik Pengetahuan Google.
V. Dukungan LPG
Biarkan saya mengingatkan Anda tentang perbedaan utama antara grafik LPG dan grafik RDF .
Dalam LPG, properti skalar dapat digantung pada instance tepi, sedangkan dalam RDF mereka hanya dapat digantung pada "tipe" tepi (tetapi tidak hanya properti skalar, tetapi juga hubungan reguler). Keterbatasan RDF ini dibandingkan dengan LPG diatasi dengan berbagai teknik pemodelan. Keterbatasan LPG dibandingkan dengan RDF lebih sulit untuk diatasi, tetapi grafik LPG lebih besar daripada grafik RDF, mirip dengan gambar dari buku teks Harari, jadi orang menginginkannya.
Jelas, tugas mendukung LPG terbagi menjadi dua bagian:
- memperkenalkan perubahan pada model RDF yang memungkinkan untuk mensimulasikan konstruksi LPG di dalamnya;
- membuat perubahan pada bahasa kueri RDF yang memungkinkan untuk mengakses data dalam model yang dimodifikasi ini, atau penerapan kemampuan untuk membuat kueri ke model ini dalam bahasa kueri LPG populer.
V.1. Model data
Ada beberapa pendekatan yang mungkin.
V.1.1. Properti Singleton
Pendekatan paling harfiah untuk menyelaraskan RDF dan LPG mungkin adalah properti tunggal :
- Sebagai gantinya, misalnya
:isMarriedTo , predikat digunakan :isMarriedTo1 , dll. - Kemudian predikat ini menjadi subjek kembar tiga baru ::
:isMarriedTo1 :since "2013-09-13"^^xsd:date , etc. - Hubungan dari contoh-contoh predikat ini dengan predikat umum dibangun oleh kembar tiga dari formulir
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo . - Jelas,
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type , tetapi pikirkan mengapa Anda tidak menulis :isMarriedTo1 rdf:type :isMarriedTo .
Tugas mendukung LPG diselesaikan di sini di tingkat RDFS. Solusi semacam itu membutuhkan penyertaan dalam standar yang relevan. Beberapa perubahan mungkin diperlukan dari repositori RDF yang mendukung efek pemasangan, tetapi untuk saat ini, Properti Singleton dapat dianggap sebagai teknik pemodelan lainnya.
V.1.2. Reifikasi dilakukan dengan benar
Pendekatan yang kurang naif berasal dari kesadaran bahwa instance properti dipakai oleh kembar tiga. Memiliki kesempatan untuk mengatakan sesuatu tentang kembar tiga, kami mendapat kesempatan untuk berbicara tentang contoh properti.
Yang paling solid dari pendekatan ini adalah RDF * , alias RDR, lahir di perut Blazegraph. Sejak awal, AnzoGraph memilihnya untuk dirinya sendiri. Soliditas pendekatan ditentukan oleh fakta bahwa dalam kerangka kerjanya perubahan yang sesuai diusulkan dalam RDF Semantik . Intinya, bagaimanapun, sangat sederhana. Dalam serialisasi Turtle, RDF sekarang dapat ditulis seperti ini:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .
V.1.3. Pendekatan lain
Anda tidak dapat repot dengan semantik formal, tetapi cukup berasumsi bahwa kembar tiga memiliki pengidentifikasi tertentu, yang, tentu saja, URI, dan menyusun kembar tiga baru dengan URI ini. Yang tersisa adalah memberikan akses ke URI ini dalam SPARQL. Inilah yang dilakukan Stardog.
Allegrograph menempuh jalan tengah. Diketahui bahwa pengidentifikasi triplet ada di Allegrograph, tetapi ketika menerapkan tiga atribut, mereka tidak menonjol. Namun, semantik formal sangat jauh. Perlu dicatat bahwa atribut kembar tiga bukan URI, dan nilai-nilai atribut ini juga hanya bisa berupa literal. Penganut LPG mendapatkan apa yang mereka inginkan. Dalam format NQX yang diciptakan khusus, contoh yang mirip dengan di atas untuk RDF * terlihat seperti ini:
:bob :marriedTo :alice {"since" : "2013-09-13"}
V.2. Bahasa Kueri
Setelah mendukung LPG dengan satu atau lain cara di tingkat model, Anda perlu memberikan kesempatan untuk membuat permintaan data dalam model seperti itu.
- Blazegraph untuk permintaan RDF * mendukung SPARQL * dan GREMLIN . Kueri untuk SPARQL * terlihat seperti ini:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }
- Anzograph juga mendukung SPARQL * dan akan mendukung Cypher , bahasa query di Neo4j.
- Stardog mendukung ekstensi SPARQL sendiri dan sekali lagi GREMLIN. Anda bisa mendapatkan triplet dan "meta-informasi" di SPARQL URI menggunakan sesuatu seperti ini:
SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since }
- Allegrograph juga mendukung ekstensi SPARQL-nya sendiri:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
Omong-omong, GraphDB pada satu waktu mendukung Tinkerpop / GREMLIN, sementara tidak mendukung LPG, tetapi dalam versi 8.0 atau 8.1 ini berhenti.
VI. Lisensi lebih ketat
Tidak ada penambahan di persimpangan set "triplestore of choice" dan "open source triplestore" telah terjadi baru-baru ini. Repositori RDF open source baru jauh dari pilihan yang baik untuk penggunaan sehari-hari, dan kode sumber triplestor baru yang ingin kita gunakan (AnzoGraph yang sama) ditutup. Sebaliknya, kita dapat berbicara tentang penurunan ...
Tentu saja, kode sumber yang sebelumnya terbuka tidak ditutup, tetapi beberapa repositori open source secara bertahap tidak lagi dianggap layak untuk dipilih. Virtuoso, yang memiliki edisi open source, menurut saya, tenggelam dalam bug. Blazegraph dibeli oleh AWS dan membentuk dasar Amazon Neptunus; sekarang tidak jelas apakah akan ada setidaknya satu rilis lagi. Yang tersisa hanyalah Jena ...
Jika open source tidak terlalu penting, tetapi Anda hanya ingin mencoba, maka semuanya juga kurang semarak dari sebelumnya. Sebagai contoh:
- Stardog berhenti mendistribusikan versi gratis (namun, ia telah dua kali lipat periode percobaan dari versi reguler);
- di GraphDB Cloud , di mana sebelumnya Anda bisa memilih paket dasar gratis, pendaftaran pengguna baru ditangguhkan.
Secara umum, bagi kebanyakan orang awam TI, ruang menjadi semakin tidak dapat diakses, perkembangannya menjadi banyak korporasi.