🥇เกิดอะไรขึ้นกับที่เก็บ RDF ในตอนนี้

Semantic Web และ Linked Data เป็นเหมือนพื้นที่รอบนอก: ไม่มีสิ่งมีชีวิตอยู่ที่นั่น เพื่อไปที่นั่นในระยะยาวไม่มากก็น้อย… ฉันไม่รู้ว่าพวกเขาบอกอะไรคุณตอนเด็กๆ เพื่อตอบว่า “ฉันอยากเป็นนักบินอวกาศ” แต่คุณสามารถดูสิ่งที่เกิดขึ้นบนโลกได้ การเป็นนักดาราศาสตร์สมัครเล่นหรือแม้แต่มืออาชีพนั้นง่ายกว่ามาก

บทความนี้จะมุ่งเน้นไปที่เทรนด์ล่าสุดจากโลกของการจัดเก็บ RDF ไม่เกินสองสามเดือน คำอุปมาในย่อหน้าแรกได้รับแรงบันดาลใจจากภาพโปรโมตที่ยิ่งใหญ่ภายใต้การตัด

ภาพมหากาพย์

I. GraphQL สำหรับการเข้าถึง RDF

พวกเขาพูดที่ GraphQL อ้างว่าเป็นภาษาเข้าถึงฐานข้อมูลสากล แล้วความสามารถในการเข้าถึงโดยใช้ GraphQL ถึง RDF ล่ะ?

โอกาสนี้จัดทำโดย:

สตาร์ด็อก(บล็อก, เอกสาร);
ผลิตภัณฑ์ TopQuadrant (การสัมมนาทางเว็บ, เอกสาร).

หากที่เก็บไม่ได้ให้โอกาสดังกล่าว จะดำเนินการโดยอิสระโดยการเขียน "ตัวแก้ไข" ที่เหมาะสม (ตัวแก้ไข) ตัวอย่างเช่นในโครงการฝรั่งเศส ดาต้าทัวริซึ่ม. หรือคุณไม่สามารถเขียนอะไรได้เลย แต่ใช้เวลา ไฮเปอร์กราฟคิวแอล.

จากมุมมองของผู้นับถือดั้งเดิมของ Semantic Web และข้อมูลที่เชื่อมโยง แน่นอนว่าทั้งหมดนี้เป็นเรื่องน่าเศร้า เนื่องจากดูเหมือนว่ามีไว้สำหรับการผสานรวมที่สร้างขึ้นรอบ ๆ ไซโลข้อมูลถัดไป และไม่ใช่แพลตฟอร์มที่เหมาะสม (แน่นอนว่าเป็นที่เก็บข้อมูล RDF) .

การแสดงผลจากการเปรียบเทียบ GraphQL กับ SPARQL เป็นสองเท่า

ในแง่หนึ่ง GraphQL ดูเหมือนญาติห่างๆ ของ SPARQL: มันแก้ปัญหาของการเลือกใหม่และการสืบค้นหลายรายการที่เป็นเรื่องปกติสำหรับ REST - หากไม่มีสิ่งนี้ คงเป็นไปไม่ได้ที่จะพิจารณา ภาษาแบบสอบถามอย่างน้อยก็สำหรับเว็บ
ในทางกลับกัน รูปแบบที่เข้มงวดของ GraphQL ทำให้เสีย ดังนั้น "ความครุ่นคิด" ของมันจึงดูเหมือนจะจำกัดมากเมื่อเทียบกับการสะท้อนกลับของ RDF ทั้งหมด และไม่มีอะนาล็อกของเส้นทางคุณสมบัติ ดังนั้นจึงไม่ชัดเจนด้วยซ้ำว่าทำไมมันถึงเป็น "กราฟ-"

ครั้งที่สอง อะแดปเตอร์สำหรับ MongoDB

เทรนด์เสริมจากเทรนด์ก่อนหน้า

ที่สตาร์ด็อกได้เลย บางที - โดยเฉพาะอย่างยิ่ง ทั้งหมดบน GraphQL เดียวกัน - กำหนดค่าการแสดงข้อมูล MongoDB เป็นกราฟ RDF เสมือน
Ontotext GraphDB เมื่อเร็ว ๆ นี้ ช่วยให้ แทรกลงในชิ้นส่วน SPARQL บน MongoDB Query

พูดให้กว้างขึ้นเกี่ยวกับอะแดปเตอร์ไปยังแหล่ง JSON ที่อนุญาตให้ "ทันที" มากขึ้นหรือน้อยลงเพื่อแสดง JSON ที่จัดเก็บไว้ในแหล่งข้อมูลเหล่านี้เป็น RDF จากนั้นเรายังสามารถเรียกคืนสิ่งที่มีอยู่ได้เป็นระยะเวลาหนึ่ง SPARQL สร้างซึ่งสามารถปรับ เช่นไปยัง Apache Jena

สรุปแนวโน้มสองข้อแรก เราสามารถพูดได้ว่าที่เก็บ RDF แสดงให้เห็นถึงความพร้อมอย่างเต็มที่สำหรับการผสานรวมและการทำงานในเงื่อนไขของ อย่างไรก็ตาม เป็นที่ทราบกันดีว่าหลังนี้ล้าสมัยไปนานแล้วและกำลังจะมาแทนที่ มา การสร้างแบบจำลองหลายแบบ แล้วการสร้างโมเดลหลายตัวในโลกของพื้นที่จัดเก็บ RDF ล่ะ?

ในระยะสั้นไม่มีทาง ฉันต้องการอุทิศบทความแยกต่างหากในหัวข้อของ DBMS หลายรุ่น แต่ตอนนี้คุณจะเห็นว่าไม่มี DBMS หลายรุ่น "ตาม" บนโมเดลกราฟ (RDF สามารถพิจารณาได้ว่าเป็นรูปแบบอื่น) เกี่ยวกับการสร้างโมเดลหลายโมเดลขนาดเล็ก - การสนับสนุนโดยที่เก็บ RDF ของโมเดลกราฟ LPG ทางเลือก - จะกล่าวถึงใน มาตรา V.

สาม. OLTP เทียบกับ สพป

อย่างไรก็ตาม Gartner เดียวกัน เขียนการสร้างแบบจำลองหลายตัวนั้นเป็นเงื่อนไขหลักสำหรับไซน์ควอไม่ใช่ ห้องผ่าตัด ดีบีเอ็มเอส. สิ่งนี้สามารถเข้าใจได้: ในสถานการณ์ของ "ที่เก็บข้อมูลหลายที่" ปัญหาหลักเกิดขึ้นกับการทำธุรกรรม

แต่ที่เก็บ RDF ในระดับ OLTP-OLAP อยู่ที่ไหน ฉันจะตอบแบบนี้: ไม่ว่าที่นั่นหรือที่นี่ เพื่อระบุว่ามีจุดประสงค์เพื่ออะไร จำเป็นต้องใช้ตัวย่อที่สาม เป็นตัวเลือกที่อยากจะแนะนำ โอลิป — การประมวลผลทางปัญญาออนไลน์

อย่างไรก็ตาม ยังคง:

กลไกการรวมที่ใช้ใน GraphDB กับ MongoDB นั้นไม่น้อยหน้ากัน ตั้งใจ เพื่อแก้ไขปัญหาประสิทธิภาพการเขียน
Stardog ก้าวไปอีกขั้นและสมบูรณ์ยิ่งขึ้น เขียนใหม่ เอ็นจิ้นอีกครั้งโดยมีเป้าหมายเพื่อปรับปรุงประสิทธิภาพการเขียน

และตอนนี้ให้ฉันแนะนำผู้เล่นใหม่ในตลาด จากผู้สร้าง IBM Netezza และ Amazon Redshift - แอนโซกราฟ™. รูปภาพจากโฆษณาสำหรับผลิตภัณฑ์ดังกล่าวถูกวางไว้ที่จุดเริ่มต้นของบทความ AnzoGraph วางตำแหน่งตัวเองเป็นโซลูชัน GOLAP คุณชอบ SPARQL กับฟังก์ชั่นหน้าต่างอย่างไร? —

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

IV. ร็อกส์ดีบี

ข้างบนแล้ว มีลิงค์ ในการประกาศของ Stardog 7 Beta ซึ่งกล่าวว่า Stardog กำลังจะใช้ RocksDB เป็นระบบจัดเก็บข้อมูลพื้นฐาน - ที่เก็บข้อมูลคีย์-ค่า ซึ่งเป็นทางแยกของ Facebook จาก LevelDB ของ Google เหตุใดจึงควรพูดถึงแนวโน้มบางอย่าง

อันดับแรกตัดสินโดย บทความวิกิพีเดียไม่เพียง แต่ที่เก็บ RDF เท่านั้นที่ "ถ่ายโอน" ไปยัง RocksDB มีโครงการที่จะใช้ RocksDB เป็นเครื่องมือจัดเก็บข้อมูลใน ArangoDB, MongoDB, MySQL และ MariaDB, Cassandra

ประการที่สอง โปรเจกต์ (ซึ่งไม่ใช่ผลิตภัณฑ์) ของหัวข้อที่เกี่ยวข้องนั้นถูกสร้างขึ้นบน RocksDB

ตัวอย่างเช่น eBay ใช้ RocksDB ใน เวที สำหรับ "กราฟความรู้" ของคุณ โดยวิธีการอ่านเป็นเรื่องตลก: ภาษาคิวรีเริ่มต้นเป็นรูปแบบที่พัฒนาขึ้นเอง แต่ไม่นานมานี้ได้มีการเปลี่ยนไปเป็นเหมือน SPARQL มากขึ้น. เป็นเรื่องตลก: ไม่ว่าเราจะสร้างกราฟความรู้มากแค่ไหน เราก็ยังได้รับ RDF

อีกตัวอย่างหนึ่ง - ปรากฏขึ้นเมื่อไม่กี่เดือนที่ผ่านมา บริการสอบถามประวัติ Wikidata. ก่อนที่จะมีการแนะนำ ข้อมูลทางประวัติศาสตร์ของวิกิสนเทศต้องสามารถเข้าถึงได้ผ่าน มว เป็น Mediawiki API มาตรฐาน ตอนนี้เป็นไปได้มากมายใน SPARQL บริสุทธิ์ "Under the hood" ยังมี RocksDB อย่างไรก็ตาม WDHQS เป็นคนทำ ดูเหมือนว่าบุคคลที่เกี่ยวข้องในการนำเข้า Freebase เข้าสู่กราฟความรู้ของ Google

V. การสนับสนุนก๊าซหุงต้ม

ฉันขอเตือนคุณถึงความแตกต่างที่สำคัญระหว่างกราฟ LPG และกราฟ RDF

ใน LPG คุณสมบัติสเกลาร์สามารถแนบกับอินสแตนซ์ของขอบได้ ในขณะที่ใน RDF สามารถแนบกับ "ประเภท" ของขอบได้เท่านั้น (แต่ไม่ใช่แค่คุณสมบัติสเกลาร์เท่านั้น แต่ยังรวมถึงลิงก์ธรรมดาด้วย) ข้อจำกัดนี้ของ RDF เมื่อเทียบกับก๊าซหุงต้ม เอาชนะ เทคนิคการสร้างแบบจำลองบางชนิด ข้อจำกัดของ LPG เมื่อเทียบกับ RDF นั้นยากที่จะเอาชนะ แต่กราฟของ LPG นั้นเหมือนรูปภาพจากหนังสือเรียนของ Harari มากกว่ากราฟ RDF ดังนั้นผู้คนจึงต้องการมัน

แน่นอนว่างาน "สนับสนุนก๊าซหุงต้ม" แบ่งออกเป็นสองส่วนคือ

การเปลี่ยนแปลงแบบจำลอง RDF ที่ทำให้สามารถจำลองโครงสร้างก๊าซหุงต้มได้
ทำการเปลี่ยนแปลงภาษาแบบสอบถาม RDF ที่ทำให้สามารถเข้าถึงข้อมูลในแบบจำลองที่แก้ไขนี้ หรือการนำความสามารถในการสืบค้นแบบจำลองนี้ในภาษาแบบสอบถาม LPG ที่เป็นที่นิยม

V.1 โมเดลข้อมูล

มีหลายวิธีที่เป็นไปได้ที่นี่

V.1.1. คุณสมบัติซิงเกิลตัน

แนวทางที่ถูกต้องที่สุดในการทำให้ RDF และ LPG สอดคล้องกันน่าจะเป็น คุณสมบัติซิงเกิลตัน:

ตัวอย่างเช่น แทนที่จะเป็นภาคแสดง :isMarriedTo มีการใช้ภาคแสดง :isMarriedTo1, :isMarriedTo2 เป็นต้น
เพรดิเคตเหล่านี้จะกลายเป็นเรื่องของแฝดสามตัวใหม่: :isMarriedTo1 :since "2013-09-13"^^xsd:date เป็นต้น
การเชื่อมต่อของอินสแตนซ์ของเพรดิเคตเหล่านี้กับเพรดิเคตทั่วไปถูกสร้างขึ้นโดยสามเท่าของแบบฟอร์ม :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
เป็นที่ชัดเจนว่า rdf:singletonPropertyOf rdfs:subPropertyOf rdf:typeแต่พิจารณาว่าทำไมคุณไม่ควรเขียน :isMarriedTo1 rdf:type :isMarriedTo.

งานของ "การสนับสนุน LPG" ได้รับการแก้ไขที่นี่ที่ระดับ RDFS การตัดสินใจดังกล่าวจำเป็นต้องรวมอยู่ในสิ่งที่เกี่ยวข้อง มาตรฐาน. อาจจำเป็นต้องมีการเปลี่ยนแปลงบางอย่างจากที่เก็บ RDF ที่รองรับการแนบผลที่ตามมา แต่สำหรับตอนนี้ Singleton Property อาจถูกมองว่าเป็นเพียงเทคนิคการสร้างแบบจำลองอีกแบบหนึ่ง

V.1.2. การทำซ้ำทำถูกต้อง

วิธีการที่ไร้เดียงสาน้อยลงเกิดจากการตระหนักว่าอินสแตนซ์ของคุณสมบัติได้รับการสร้างอินสแตนซ์อย่างสมบูรณ์แบบโดยแฝดสาม เมื่อพูดถึงแฝดสาม เรายังสามารถพูดถึงตัวอย่างคุณสมบัติได้ด้วย

แนวทางที่มั่นคงที่สุดคือ มูลนิธิ กฟผ.*หรือที่เรียกว่า RDR เกิด ในลำไส้ของ Blazegraph มันมาจากจุดเริ่มต้น ได้รับการเลือกตั้ง สำหรับตัวฉันเองและ AnzoGraph ความแข็งแกร่งของวิธีการถูกกำหนดโดยความจริงที่ว่าภายในกรอบของมัน ที่นำเสนอ การเปลี่ยนแปลงที่สอดคล้องกันใน ความหมาย RDF. อย่างไรก็ตาม ประเด็นนั้นง่ายมาก ในการทำให้เป็นอันดับ RDF Turtle ตอนนี้คุณสามารถเขียนสิ่งนี้:

<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .

V.1.3 แนวทางอื่นๆ

คุณไม่สามารถกังวลกับความหมายที่เป็นทางการ แต่เพียงพิจารณาว่าแฝดสามมีตัวระบุบางอย่างซึ่งแน่นอนว่าเป็น URI และเขียนแฝดสามใหม่ด้วย URI เหล่านี้ สิ่งที่เหลืออยู่คือการให้สิทธิ์การเข้าถึง URI เหล่านี้ใน SPARQL ดังนั้น มาถึง สตาร์ด็อก

ใน Allegrograph ไปกันเถอะ ในทางสายกลาง เป็นที่ทราบกันดีว่าตัวระบุของแฝดสามใน Allegrograph เป็นแต่เมื่อใช้แอตทริบิวต์สามอย่าง จะไม่โดดเด่น อย่างไรก็ตาม แม้แต่ความหมายที่เป็นทางการก็ยังห่างไกลออกไปมาก โดยเฉพาะอย่างยิ่ง แอตทริบิวต์ triplet ไม่ใช่ URI และค่าของแอตทริบิวต์เหล่านี้สามารถเป็นตัวอักษรได้เท่านั้น สาวก LPG ได้รับสิ่งที่ต้องการอย่างแน่นอน ในรูปแบบ NQX ที่ประดิษฐ์ขึ้นเป็นพิเศษ ตัวอย่างที่คล้ายกับข้างต้นสำหรับ RDF* มีลักษณะดังนี้:

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2 สอบถามภาษา

การสนับสนุน LPG ไม่ทางใดก็ทางหนึ่งในระดับโมเดล คุณต้องทำให้สามารถสืบค้นข้อมูลในโมเดลดังกล่าวได้

รองรับข้อความค้นหา Blazegraph สำหรับ RDF* สปาร์คิวแอล* и ปู่โสม. ข้อความค้นหา SPARQL* มีลักษณะดังนี้:

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

Anzograph ยังรองรับ สปาร์คิวแอล* และจะไปอุดหนุน อักษรไขว้, ภาษาคิวรีใน Neo4j
Stardog รักษาตัวเอง ส่วนขยาย SPARQL และ อีกครั้ง เกรมลิน. คุณสามารถรับ URI ของ triplet และ "ข้อมูลเมตา" ใน SPARQL โดยใช้สิ่งนี้:

SELECT * {
    BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
    ?id :since ?since
}

Allegrograph ยังสนับสนุนของตัวเอง ส่วนขยาย สปาร์คเคิล:

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

บังเอิญ GraphDB รองรับ Tinkerpop/Gremlin ในคราวเดียวโดยไม่รองรับ LPG แต่หยุดในเวอร์ชัน 8.0 หรือ 8.1

วี.ไอ. ใบอนุญาตที่รัดกุม

ยังไม่มีการเพิ่มชุด "triplestore of choice" และ "open source triplestore" เข้าด้วยกันเมื่อเร็วๆ นี้ ร้านค้า RDF โอเพ่นซอร์สใหม่ยังห่างไกลจากตัวเลือกที่ดีสำหรับการใช้งานทุกวัน และซอร์สโค้ดสำหรับร้านค้าสามแห่งใหม่ที่ฉันต้องการใช้ (เช่น AnzoGraph) ถูกปิด แต่เราสามารถพูดคุยเกี่ยวกับการลด ...

แน่นอนว่าโอเพ่นซอร์สก่อนหน้านี้ไม่ได้ถูกปิด แต่ที่เก็บโอเพ่นซอร์สบางแห่งก็ค่อยๆ ไม่ถือว่าคู่ควรอีกต่อไป Virtuoso ซึ่งมีรุ่นโอเพ่นซอร์สในความคิดของฉันกำลังจมอยู่ในข้อบกพร่อง Blazegraph ซื้อโดย AWS และเป็นพื้นฐานของ Amazon Neptune; ตอนนี้ยังไม่ชัดเจนว่าจะมีการเปิดตัวอีกอย่างน้อยหนึ่งรายการหรือไม่ เหลือแต่เจนน่า...

หากโอเพ่นซอร์สไม่สำคัญมาก แต่คุณแค่อยากลอง ทุกอย่างก็จะดูมีสีสันน้อยลงกว่าเดิมด้วย ตัวอย่างเช่น:

สตาร์ด็อก สิ้นสุด แจกจ่ายเวอร์ชันฟรี (อย่างไรก็ตาม ระยะเวลาทดลองใช้ของเวอร์ชันปกติจะเพิ่มเป็นสองเท่า);
в GraphDB คลาวด์ซึ่งก่อนหน้านี้คุณสามารถเลือกแผนพื้นฐานฟรีได้ การลงทะเบียนผู้ใช้ใหม่จะถูกระงับ

โดยทั่วไปแล้วพื้นที่จะไม่สามารถเข้าถึงได้มากขึ้นเรื่อย ๆ สำหรับคนธรรมดาด้านไอที การพัฒนาของมันกำลังกลายเป็นที่หลาย ๆ องค์กร

ที่มา: will.com

เกิดอะไรขึ้นกับที่เก็บ RDF ในตอนนี้