ما يحدث مع مستودعات RDF الآن؟

تشبه شبكة الويب الدلالية والبيانات المرتبطة إلى الفضاء القريب: الحياة ليست هناك. للذهاب إلى هناك لفترة طويلة أو أقل ... حسنًا ، لا أعرف ما أخبروك به في مرحلة الطفولة ردًا على "أريد أن أصبح رائد فضاء". لكن يمكنك ملاحظة ما يحدث ووجودك على الأرض ؛ أصبح فلكي الهواة أو حتى المهنية أسهل بكثير.


سوف تركز المقالة على اتجاهات جديدة ، وليس أقدم من بضعة أشهر ، من عالم مستودعات RDF. استعارة في الفقرة الأولى مستوحاة من هذه الصورة الإعلانية الملحمية الحجم.


محتوى


I. GraphQL للوصول إلى RDF
II. محولات إلى MongoDB
III. OLTP مقابل OLAP
IV. RocksDB
دعم الغاز الطبيعي المسال
V.1. نماذج البيانات
V.1.1. الملكية المفردة
V.1.2. تم القيام به الصحيح
V.1.3. طرق أخرى
V.2. لغات الاستعلام
VI. تشديد التراخيص


I. GraphQL للوصول إلى RDF


يقولون أن GraphQL تدعي أنها لغة عالمية للوصول إلى قواعد البيانات. ماذا عن القدرة على استخدام GraphQL للوصول إلى RDF؟


خارج الصندوق ، يتم توفير هذه الفرصة عن طريق:



إذا لم يوفر المستودع هذه الفرصة ، فسيتم تنفيذه بشكل مستقل عن طريق كتابة محلل المطابق. تم ذلك ، على سبيل المثال ، في المشروع الفرنسي DataTourisme . أو يمكنك بالفعل كتابة أي شيء ، ولكن فقط تأخذ HyperGraphQL .


من وجهة نظر المتابعين الأرثوذكس للويب الدلالي والبيانات المرتبطة ، كل هذا ، بالطبع ، أمر محزن ، لأنه يبدو أنه يهدف إلى تكاملات مبنية على صوامع البيانات العادية ، وغير مناسبة لتلك المنصة (بالطبع ، تخزين RDF).


انطباعات مقارنة GraphQL مع SPARQL ذات شقين.


  • من ناحية ، يبدو أن GraphQL يشبه قريبًا من SPARQL: لقد حل المشكلات الخاصة بـ REST المتمثلة في إعادة جلب وتعدد الاستعلامات - وبدون ذلك ، سيكون من المستحيل اعتبار لغة استعلام ، حتى بالنسبة للويب ، ويكون لها "-QL" في الاسم ؛
  • من ناحية أخرى ، اضطراب الدوائر GraphQL قاسية. وفقًا لذلك ، يبدو "الاستبطان" الخاص بها محدودًا جدًا بالمقارنة مع الانعكاسية الكاملة لـ RDF. وليس هناك ما يماثل مسارات الملكية ، لذلك ليس من الواضح تمامًا سبب "الرسم البياني".

II. محولات إلى MongoDB


وهناك اتجاه مكمل للالسابق.


  • في Stardog أصبح من الممكن الآن - على وجه الخصوص ، كل شيء على نفس GraphQL - تكوين مناظرة بيانات MongoDB في رسوم بيانية RDF افتراضية ؛
  • يسمح لك Ontotext GraphDB مؤخراً بإدراج أجزاء في SPARQL في استعلام MongoDB.

عند التحدث على نطاق أوسع ، حول محولات مصادر JSON التي تتيح لـ "ذبابة" أكثر أو أقل تمثيل JSON كـ RDF ، يجدر التذكير بتوليد SPARQL Generale ، والذي يمكن ربطه ، على سبيل المثال ، بـ Apache Jena.


بتلخيص الاتجاهين الأولين ، يمكن القول أن مخازن RDF تظهر استعدادها التام للتكامل وتعمل في ظل ظروف "التخزين متعدد المتغيرات" (الثبات متعدد اللغات). ومع ذلك ، فمن المعروف أن هذا الأخير قد عفا عليه الزمن منذ فترة طويلة ، وأن النماذج المتعددة ستحل محلها. وماذا عن التشكيل المتعدد في عالم تخزين RDF؟


باختصار ، لا مفر. أود تخصيص مقالة منفصلة لموضوع نظام إدارة قواعد البيانات المتعدد الوسائط. في غضون ذلك ، يمكنك أن ترى أنه لا توجد نظم إدارة قواعد بيانات متعددة النماذج يكون فيها النموذج الرئيسي نموذجًا بيانيًا (يمكن اعتبار مجموعة متنوعة منها RDF). ستتم مناقشة بعض النماذج الصغيرة - دعم مستودع RDF لنموذج الرسم البياني LPG البديل - في القسم الخامس.


III. OLTP مقابل OLAP


ومع ذلك ، يكتب غارتنر نفسه أن التشكيل المتعدد شرط لا بد منه في المقام الأول لقواعد إدارة قواعد البيانات التشغيلية . من المفهوم: في حالة "التخزين متعدد المتغيرات" ، تنشأ المشاكل الرئيسية مع المعاملات.


ولكن أين توجد مستودعات RDF على مقياس OLTP - OLAP؟ أود الإجابة بهذه الطريقة: لا يوجد هنا ولا هنا. للإشارة إلى المقصود منها ، هناك حاجة إلى بعض الاختصار الثالث. بدلاً من ذلك ، أود أن أقترح OLIP - المعالجة الفكرية عبر الإنترنت.


ومع ذلك ، لا يزال:


  • آليات تكامل GraphDB المطبقة مع MongoDB ليست مصممة على الأقل للتحايل على مشاكل أداء الكتابة ؛
  • يمتد Stardog إلى أبعد من ذلك ويعيد كتابة المحرك بالكامل ، مرة أخرى بهدف تحسين أداء التسجيل.

الآن اسمحوا لي أن أعرض لاعب جديد في السوق. من المبدعين من IBM Netezza و Amazon Redshift - AnzoGraph . تم وضع الصورة من إعلان المنتج بناءً عليه في بداية المقالة. تضع AnzoGraph نفسها كحل GOLAP. كيف تحب SPARQL مع وظائف النافذة؟ -


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

IV. RocksDB


أعلاه ، كان هناك بالفعل رابط لإعلان Stardog 7 Beta ، الذي قال إن Stardog ستستخدم RocksDB كنظام تخزين أساسي - تخزين القيمة الرئيسية ، شوكة Facebook لـ LevelDB من Google. لماذا يستحق الحديث عن اتجاه معين؟


أولاً ، بناءً على مقالة ويكيبيديا ، لا يتم نقل مستودعات RDF فقط إلى RocksDB. هناك مشاريع حول استخدام RocksDB كمحرك تخزين في ArangoDB و MongoDB و MySQL و MariaDB و Cassandra.


ثانياً ، يتم تنفيذ مشاريع (أي ليست منتجات) للموضوع المقابل في RocksDB.


على سبيل المثال ، يستخدم eBay RocksDB في النظام الأساسي لـ "الرسم البياني للمعرفة". بالمناسبة ، من الممتع أن تقرأ: لغة الاستعلام بدأت كتنسيق محلي ، ولكن في الآونة الأخيرة ، كانت تنتقل لتصبح أكثر شبهاً بـ SPARQL . كما هو الحال في النكتة: بغض النظر عن مقدار الرسم البياني للمعرفة الذي نقوم به ، ما زلنا نحصل على RDF.


مثال آخر هو خدمة الاستعلام عن ويكيداتا ، والتي ظهرت قبل بضعة أشهر. قبل ظهوره ، كان على Wikidata الوصول إلى واجهة برمجة تطبيقات Mediawiki القياسية من خلال MWAPI . الآن الكثير ممكن على SPARQL النقي. "تحت غطاء محرك السيارة" هناك أيضا RocksDB. بالمناسبة ، قام WDHQS ، على ما يبدو ، بالشخص الذي قام باستيراد Freebase في Google Knowledge Graph.


دعم الغاز الطبيعي المسال


اسمحوا لي أن أذكرك بالفرق الرئيسي بين الرسوم البيانية للغاز الطبيعي المسال والرسومات RDF .


في LPG ، يمكن تعليق خصائص العدد على مثيلات الحافة ، بينما في RDF يمكن تعليقها فقط على "أنواع" الحواف (ولكن ليس فقط خصائص العددية ، ولكن أيضًا العلاقات العادية). يتم التغلب على هذا الحد من RDF مقارنة بغاز البترول المسال من خلال تقنيات النمذجة المختلفة. من الصعب التغلب على قيود LPG مقارنة بـ RDF ، ولكن الرسوم البيانية LPG أكبر من الرسوم البيانية RDF ، على غرار الصور من كتاب Harari ، لذلك يريدها الناس.


من الواضح أن مهمة دعم غاز البترول المسال تنقسم إلى قسمين:


  1. إدخال تغييرات على نموذج RDF التي تجعل من الممكن محاكاة إنشاءات غاز البترول المسال في ذلك ؛
  2. إجراء تغييرات على لغة استعلام RDF التي تجعل من الممكن الوصول إلى البيانات في هذا النموذج المعدل ، أو تنفيذ القدرة على إجراء استفسارات لهذا النموذج بلغات استعلام LPG الشائعة.

V.1. نماذج البيانات


هناك العديد من الأساليب الممكنة.


V.1.1. الملكية المفردة


الطريقة الأكثر حرفية لمواءمة RDF و LPG هي خاصية المفرد :


  • بدلاً من ذلك ، على سبيل المثال :isMarriedTo ، يتم استخدام :isMarriedTo1 ، :isMarriedTo1 ، إلخ.
  • ثم تصبح هذه المسندات مواضيع ثلاثية جديدة :: :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 ببساطة كطريقة أخرى للنمذجة.


V.1.2. تم القيام به الصحيح


النهج الأقل سذاجة تنبع من إدراك أن حالات الخصائص يتم إنشاء مثيل لها بواسطة ثلاثة توائم. بعد أن أتيحت لنا الفرصة لقول شيء عن ثلاثة توائم ، نحصل على فرصة للتحدث عن حالات الخصائص.


أكثر هذه الطرق صلابة هو RDF * ، المعروف أيضًا باسم RDR ، المولود في أحشاء Blazegraph. من البداية ، اختاره AnzoGraph لنفسه. يتم تحديد صلابة هذا النهج من خلال حقيقة أن التغييرات المقابلة في إطارها تقترح في الدلالات RDF . لكن النقطة بسيطة للغاية. في تسلسل السلاحف ، يمكن الآن كتابة RDF بشيء من هذا القبيل:


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

V.1.3. طرق أخرى


لا يمكنك أن تهتم بالدلالات الرسمية ، لكن ببساطة تفترض أن ثلاثة توائم لها معرفات معينة ، وهي بالطبع URIs ، وتؤلف ثلاثة توائم جديدة مع URIs هذه. كل ما تبقى هو منح حق الوصول إلى هذه URIs في SPARQL. هذا ما يفعله Stardog.


ذهب Allegrograph وسيلة وسيطة. من المعروف أن المعرفات الثلاثية موجودة في Allegrograph ، لكن عند تنفيذ السمات الثلاثية ، فإنها لا تلتزم بها. ومع ذلك ، فإن الدلالات الرسمية بعيدة جدًا. من الجدير بالذكر أن سمات الثلاثية ليست URIs ، وقيم هذه السمات يمكن أن تكون أيضًا حرفية. الحصول على أتباع غاز البترول المسال بالضبط ما يريدون. في تنسيق NQX الذي تم اختراعه بشكل خاص ، يبدو مثال مشابه للمثال أعلاه لـ RDF * كما يلي:


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

V.2. لغات الاستعلام


بعد دعم LPG بطريقة أو بأخرى على مستوى النموذج ، تحتاج إلى إعطاء الفرصة لتقديم طلبات البيانات في مثل هذا النموذج.


  • تدعم استعلامات Blazegraph for RDF * SPARQL * و Gremlin . يبدو الاستعلام عن SPARQL * كما يلي:

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

  • يدعم Anzograph أيضًا SPARQL * وسوف يدعم Cypher ، وهي لغة استعلام في Neo4j.
  • Stardog يدعم امتداد SPARQL الخاص به ومرة أخرى Gremlin. يمكنك الحصول على ثلاثة أضعاف و "معلومات التعريف" في SPARQL URI باستخدام شيء مثل هذا:

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

  • يدعم Allegrograph أيضًا امتداد SPARQL الخاص به:

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

بالمناسبة ، دعم GraphDB في وقت واحد Tinkerpop / Gremlin ، بينما لا يدعم LPG ، ولكن في الإصدار 8.0 أو 8.1 توقف هذا.


VI. تشديد التراخيص


لم تحدث إضافات عند تقاطع مجموعتي "triplestore of choice" و "open open triplestore" مؤخرًا. مستودعات RDF مفتوحة المصدر الجديدة بعيدة كل البعد عن أن تكون خيارًا جيدًا للاستخدام اليومي ، ويتم إغلاق الكود المصدري للثالثين الجدد الذين نود استخدامهم (نفس AnzoGraph). بدلا من ذلك ، يمكننا التحدث عن النقصان ...


بالطبع ، لا يتم إغلاق شفرة المصدر المفتوح سابقًا ، ولكن لم تعد مستودعات المصدر المفتوح تدريجيًا تستحق الاختيار. فيرتوسو ، الذي لديه إصدار مفتوح المصدر ، في رأيي ، يغرق في الأخطاء. تم شراء Blazegraph بواسطة AWS وشكلت أساس Amazon Amazon. الآن ليس من الواضح ما إذا كان سيكون هناك إصدار واحد آخر على الأقل. كل ما تبقى هو جينا ...


إذا لم يكن المصدر المفتوح مهمًا للغاية ، لكنك ترغب فقط في المحاولة ، فكل شيء أقل وردية من ذي قبل. على سبيل المثال:


  • توقف Stardog عن توزيع النسخة المجانية (ومع ذلك ، فقد ضاعفت فترة الإصدار العادي) ؛
  • في GraphDB Cloud ، حيث يمكنك في السابق اختيار خطة أساسية مجانية ، يتم تعليق تسجيل المستخدمين الجدد.

بشكل عام ، بالنسبة للشخص العادي لتكنولوجيا المعلومات ، أصبحت المساحة غير قابلة للوصول بشكل متزايد ؛ أصبح تطويرها هو الكثير من الشركات.

Source: https://habr.com/ru/post/ar451206/


All Articles