Ang Semantic Web at Linked Data ay parang outer space: walang buhay doon. Para makapunta doon nang mas marami o hindi gaanong mahabang panahon... Hindi ko alam kung ano ang sinabi nila sa iyo bilang isang tugon sa "Gusto kong maging isang astronaut." Ngunit maaari mong obserbahan kung ano ang nangyayari habang nasa Earth; Mas madaling maging isang amateur astronomer o kahit isang propesyonal.
Ang artikulo ay tumutuon sa kamakailang, hindi mas matanda sa ilang buwan, mga uso mula sa mundo ng imbakan ng RDF. Ang metapora sa unang talata ay inspirasyon ng epic-sized na imahe ng advertising sa ilalim ng hiwa.
Epic na larawan
I. GraphQL para sa RDF Access
na layunin ng GraphQL na maging isang unibersal na wika ng pag-access sa database. Paano naman ang kakayahang ma-access ang RDF gamit ang GraphQL?
Out of the box ang pagkakataong ito ay ibinigay ng:
- Stardog (, );
- Mga produktong TopQuadrant (, ).
Kung ang repositoryo ay hindi nagbibigay ng ganoong tampok, maaari itong ipatupad nang nakapag-iisa sa pamamagitan ng pagsulat ng naaangkop na "resolver". Ito ang ginawa nila, halimbawa, sa proyektong Pranses . O wala ka nang maisulat, kundi kumuha na lang .
Mula sa punto ng view ng isang orthodox adherent ng Semantic Web at Linked Data, ang lahat ng ito, siyempre, ay malungkot, dahil ito ay tila dinisenyo para sa mga integrasyon na binuo sa paligid ng susunod na data silo, at hindi angkop na mga platform (RDF store, siyempre) .
Ang mga impression mula sa paghahambing ng GraphQL sa SPARQL ay dalawang beses.
- Sa isang banda, ang GraphQL ay mukhang isang malayong kamag-anak ng SPARQL: nalulutas nito ang mga problema ng resampling at multiplicity ng mga query na tipikal para sa REST - kung wala ito, malamang, hindi posible na isaalang-alang wika ng tanong, hindi bababa sa para sa web;
- Sa kabilang banda, nakakadismaya ang mahigpit na schema ng GraphQL. Alinsunod dito, ang "introspectiveness" nito ay tila napakalimitado kumpara sa buong reflexivity ng RDF. At walang analogue ng mga landas ng ari-arian, kaya hindi masyadong malinaw kung bakit ito ay "Graph-".
II. Mga adaptor para sa MongoDB
Isang trend na pantulong sa nauna.
- Nasa Stardog ngayon - sa partikular, lahat sa parehong GraphQL - i-configure ang pagmamapa ng data ng MongoDB sa mga virtual na RDF graph;
- Ang Ontotext GraphDB ay kamakailan magpasok ng mga fragment sa SPARQL sa MongoDB Query.
Kung mas malawak ang pag-uusapan natin tungkol sa mga adapter sa mga source ng JSON, na nagbibigay-daan sa mas marami o mas kaunting "on the fly" na kumatawan sa JSON na nakaimbak sa mga source na ito bilang RDF, maaalala natin ang medyo matagal na. , na maaaring iakma, , kay Apache Jena.
Sa pagbubuod sa unang dalawang trend, masasabi nating ang mga imbakan ng RDF ay nagpapakita ng ganap na kahandaan para sa pagsasama at pagpapatakbo sa mga kondisyon ng "pagtitiyaga ng polyglot". Ito ay kilala, gayunpaman, na ang huli na ito ay matagal nang wala sa uso, at pinapalitan ng maraming modelo. Paano ang tungkol sa multi-modeling sa mundo ng imbakan ng RDF?
In short, no way. Nais kong mag-alay ng isang hiwalay na artikulo sa paksa ng mga multi-modelo na DBMS, ngunit sa ngayon ay mapapansin na sa kasalukuyan ay walang mga multi-modelo na DBMS na "batay" sa isang modelo ng graph (ang RDF ay maaaring ituring na isang uri nito) . Ang ilang maliit na multi-modeling - RDF storage support para sa alternatibong LPG graph model - ay tatalakayin sa .
III. OLTP vs. OLAP
Gayunpaman, ang parehong Gartner ang multimodel na iyon ay isang sine qua non kundisyon na pangunahing para sa operating room DBMS. Ito ay naiintindihan: sa isang sitwasyon ng "multivariate storage", ang mga pangunahing problema ay lumitaw sa transactionality.
Ngunit saan matatagpuan ang mga imbakan ng RDF sa sukat ng OLTP-OLAP? Sasagot ako sa ganitong paraan: wala doon o dito. Upang ipahiwatig kung para saan ang mga ito, kailangan ang ilang ikatlong pagdadaglat. Bilang isang pagpipilian, iminumungkahi ko OLIP β Online Intellectual Processing.
Gayunpaman, pa rin:
- ang mga mekanismo ng pagsasama sa MongoDB na ipinatupad sa GraphDB ay hindi bababa sa upang magtrabaho sa paligid magsulat ng mga isyu sa pagganap;
- Ang Stardog ay nagpapatuloy pa at ganap engine, muli na may layuning mapabuti ang pagganap ng pag-record.
Ngayon hayaan mo akong magpakilala ng bagong manlalaro sa merkado. Mula sa mga tagalikha ng IBM Netezza at Amazon Redshift - . Ang isang larawan mula sa isang patalastas para sa isang produkto batay dito ay nai-post sa simula ng artikulo. Pinoposisyon ng AnzoGraph ang sarili bilang isang solusyon sa GOLAP. Paano mo gusto ang SPARQL na may mga function ng window? β
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { β¦ }IV. RocksDB
Mas mataas na sa anunsyo ng Stardog 7 Beta, na nagsabing gagamitin ng Stardog ang RocksDB bilang isang pinagbabatayan na sistema ng imbakan - isang tindahan ng key-value, isang Facebook fork ng LevelDB ng Google. Bakit sulit na pag-usapan ang isang tiyak na kalakaran?
Una, paghusga sa pamamagitan ng , hindi lamang ang mga imbakan ng RDF ay "inilipat" sa RocksDB. May mga proyektong gagamitin ang RocksDB bilang storage engine sa ArangoDB, MongoDB, MySQL at MariaDB, Cassandra.
Pangalawa, ang mga proyekto (iyon ay, hindi mga produkto) sa mga nauugnay na paksa ay nilikha sa RocksDB.
Halimbawa, ang eBay ay gumagamit ng RocksDB sa para sa iyong "graph ng kaalaman". By the way, nakakatuwa basahin: ang wika ng query ay nagsimula bilang isang home grown na format, ngunit kamakailan lamang ay lumilipat ito upang maging mas katulad ng SPARQL. As in the joke: kahit gaano pa karami ang knowledge graph na ginawa natin, nauuwi pa rin tayo sa RDF.
Isa pang halimbawa - isa na lumitaw ilang buwan na ang nakakaraan . Bago ang pagpapakilala nito, ang makasaysayang impormasyon ng Wikidata ay kailangang ma-access sa pamamagitan ng sa karaniwang Mediawiki API. Ngayon marami ang posible sa purong SPARQL. "Sa ilalim ng hood" mayroon ding RocksDB. Siyanga pala, ang WDHQS ay ginawa, tila, ng taong nag-import ng Freebase sa Google Knowledge Graph.
V. Suporta sa LPG
Hayaan akong ipaalala sa iyo ang pangunahing pagkakaiba sa pagitan ng mga LPG graph at RDF graph.
Sa LPG, maaaring italaga ang mga katangian ng scalar sa mga edge na pagkakataon, habang sa RDF maaari lamang silang italaga sa mga "uri" ng gilid (ngunit hindi lamang mga katangian ng scalar, kundi pati na rin ang mga ordinaryong koneksyon). Ang limitasyong ito ng RDF kumpara sa LPG isa o ibang diskarte sa pagmomodelo. Ang mga limitasyon ng LPG kumpara sa RDF ay mas mahirap pagtagumpayan, ngunit ang mga LPG graph ay mas katulad ng mga larawan mula sa isang Harari textbook kaysa sa mga RDF graph, kaya naman gusto ito ng mga tao.
Malinaw, ang gawain ng "suporta sa LPG" ay nahahati sa dalawang bahagi:
- paggawa ng mga pagbabago sa modelo ng RDF na ginagawang posible na gayahin ang mga istruktura ng LPG dito;
- paggawa ng mga pagbabago sa RDF query language na ginagawang posible na ma-access ang data sa binagong modelong ito, o pagpapatupad ng kakayahang gumawa ng mga query sa modelong ito sa mga sikat na LPG query na wika.
V.1. Modelo ng data
Mayroong ilang mga posibleng diskarte dito.
V.1.1. Pag-aari ng Singleton
Ang pinaka-literal na diskarte sa pagsasama-sama ng RDF at LPG ay marahil :
- Sa halip na, halimbawa, ang panaguri
:isMarriedToginagamit ang mga panaguri:isMarriedTo1,:isMarriedTo2at t. d. - Ang mga panaguri na ito ay nagiging paksa ng mga bagong triplets:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateat iba pa - Ang koneksyon ng mga pagkakataong ito ng mga panaguri na may isang karaniwang panaguri ay itinatag ng mga triplet ng anyo
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Malinaw,
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ngunit isipin kung bakit hindi ka na lang magsulat:isMarriedTo1 rdf:type :isMarriedTo.
Ang problema ng "LPG support" ay nalutas dito sa antas ng RDFS. Ang ganitong desisyon ay nangangailangan ng pagsasama sa naaangkop . Maaaring kailanganin ang ilang mga pagbabago para sa mga tindahan ng RDF na sumusuporta sa pag-attach ng mga kahihinatnan, ngunit sa ngayon, ang Singleton Property ay maaaring ituring na isa pang diskarte sa pagmomodelo.
V.1.2. Tama ang Reification
Ang mga hindi gaanong walang muwang na diskarte ay nagmumula sa pagkaunawa na ang mga instance ng ari-arian ay ganap na nasasabihan ng triplets. Sa pamamagitan ng kakayahang magsabi ng isang bagay tungkol sa triplets, mapag-uusapan natin ang tungkol sa mga pangyayari sa ari-arian.
Ang pinaka-matatag sa mga pamamaraang ito ay , aka RDR, sa kaibuturan ng Blazegraph. Ito ay sa simula pa lamang para sa iyong sarili at sa AnzoGraph. Ang katatagan ng diskarte ay tinutukoy ng katotohanan na sa loob ng balangkas nito kaukulang pagbabago sa . Ang punto, gayunpaman, ay napakasimple. Sa Turtle serialization ng RDF maaari ka na ngayong magsulat ng ganito:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Iba pang mga diskarte
Hindi ka maaaring mag-abala sa mga pormal na semantika, ngunit ipagpalagay lamang na ang mga triplet ay may ilang mga identifier, na, siyempre, mga URI, at lumikha ng mga bagong triplet sa mga URI na ito. Ang natitira na lang ay magbigay ng access sa mga URI na ito sa SPARQL. Kaya Stardog.
Sa Allegrograph sa isang intermediate na paraan. Ito ay kilala na ang mga triplet identifier sa Allegrograph , ngunit kapag nagpapatupad ng triple attribute ay hindi sila nananatili. Gayunpaman, napakalayo pa rin nito sa pormal na semantika. Kapansin-pansin na ang mga triplet na katangian ay hindi mga URI, at ang mga halaga ng mga katangiang ito ay maaari ding mga literal lamang. Nakukuha ng mga tagasunod ng LPG ang gusto nila. Sa espesyal na naimbentong format ng NQX, ang isang halimbawang katulad ng nasa itaas para sa RDF* ay ganito ang hitsura:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Mga wika sa pagtatanong
Ang pagkakaroon ng suportado ng LPG sa isang paraan o iba pa sa antas ng modelo, kailangan mong gawing posible na gumawa ng mga query sa data sa naturang modelo.
- Blazegraph para sa RDF* na mga query ay sumusuporta ΠΈ . Ang isang query sa SPARQL* ay ganito ang hitsura:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Sinusuportahan din ng Anzograph at susuporta , isang wika ng query sa Neo4j.
- Sinusuportahan ng Stardog ang sarili nitong SPARQL at Gremlin. Makukuha mo ang triplet URI at "meta-information" sa SPARQL gamit ang isang bagay na tulad nito:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Sinusuportahan din ng Allegrograph ang sarili nito SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Oo nga pala, sinuportahan ng GraphDB ang Tinkerpop/Gremlin nang hindi sinusuportahan ang LPG, ngunit huminto ito sa bersyon 8.0 o 8.1.
VI. Paghihigpit ng mga lisensya
Walang kamakailang mga karagdagan sa intersection ng "triplestore of choice" at "open source triplestore" set. Ang mga bagong open source na tindahan ng RDF ay malayo na mula sa pagiging isang mahusay na pagpipilian para sa pang-araw-araw na paggamit, at ang mga bagong triple na tindahan na gusto kong gamitin (tulad ng AnzoGraph) ay closed source. Sa halip, maaari nating pag-usapan ang tungkol sa mga pagbaba...
Siyempre, ang open source ay hindi pa isinara sa nakaraan, ngunit ang ilang mga open source na repository ay dahan-dahang hindi na nakikita bilang sulit na pumili. Ang Virtuoso, na mayroong isang opensource na edisyon, ay, sa palagay ko, ay nalulunod sa mga bug. Ang Blazegraph ay binili ng AWS at naging batayan ng Amazon Neptune; ngayon ay hindi malinaw kung magkakaroon ng kahit isa pang release. Si Jena na lang ang natitira...
Kung ang open source ay hindi masyadong mahalaga, ngunit gusto mo lamang itong subukan, kung gayon ang lahat ay hindi gaanong kulay-rosas kaysa dati. Halimbawa:
- Stardog ipamahagi ang libreng bersyon (gayunpaman, ang panahon ng pagsubok ng regular na bersyon ay nadoble);
- Π² , kung saan maaari kang pumili dati ng isang libreng pangunahing plano, ang mga bagong pagpaparehistro ng user ay nasuspinde.
Sa pangkalahatan, para sa karaniwang taong IT, ang espasyo ay nagiging mas hindi naa-access; ang pag-unlad nito ay nagiging maraming mga korporasyon.
Pinagmulan: www.habr.com