مخطط المعرفة Knowledge Graph

هو من ينقل المشروع من شجرة أنساب إلى خريطة مجتمع.

Knowledge Graph بالذات قد تكون من أفضل الطرق لتحويل مشروعكم من “موسوعة أنساب” إلى بنية معرفية حيّة يمكن البحث فيها، وتحليلها، والتوسع بها لاحقًا.

المشكلة في الكتب النسبية أن النص يعطيك معلومات كثيرة، لكن على شكل جمل متفرقة.
أما الـ Knowledge Graph فهو يحول هذه الجمل إلى عُقَد وروابط.

بعبارة أبسط جدًا:

• الشخص = عقدة
• القبيلة / البطن = عقدة
• الزوجة = عقدة
• الأب / الأم / الابن / البنت = علاقات بين العقد
• الكتاب / المصدر / الرواية = عقدة أو مرجع مرتبط
• المكان / الفترة / الحدث = عقدة كذلك

فيصير عندك بدل النص:

زمعة بن الأسود، له عبد الله الأكبر، ويزيد من أم فلانة، وعبد الله الأصغر من أم ولد…

يصير عندك شيء من هذا النوع:

• زمعة بن الأسود — أب لـ — عبد الله الأكبر
• زمعة بن الأسود — أب لـ — يزيد
• يزيد — أمه — فلانة
• عبد الله الأصغر — أمه — أم ولد مجهولة
• زمعة بن الأسود — ينتمي إلى — بني أسد
• زمعة بن الأسود — مذكور في — نسب قريش

وهنا تبدأ المتعة الحقيقية. لأنك لم تعد تملك “معلومة مكتوبة” فقط، بل شبكة قابلة للاستعلام.

ما هو Knowledge Graph بدقة؟

هو تمثيل منظم للمعرفة على شكل:

كيانات + علاقات + صفات

يعني عندك:

1) الكيانات

مثل:

• شخص
• قبيلة
• بطن
• امرأة
• معركة
• مكان
• كتاب
• راوية
• زواج
• ولادة
• وفاة

2) العلاقات

مثل:

• ابن فلان
• بنت فلان
• أم فلان
• زوج فلانة
• من بني فلان
• شهد معركة كذا
• قُتل في كذا
• ورد في المصدر الفلاني
• له أخ لأم
• مولى لبني فلان

3) الصفات

مثل:

• الاسم
• الكنية
• اللقب
• الجنس
• حالة الشخص
• درجة الثقة
• زمن تقريبي
• ملاحظات
• موضع النص في المصدر

يعني هو ليس مجرد شجرة نسب.
الشجرة غالبًا تمشي من الأب إلى الابن فقط.
أما Knowledge Graph فيتجاوز هذا بكثير.

الشجرة تقول:

• هذا أب هذا، وهذا ابن هذا.

أما الـ Knowledge Graph فيقول أيضًا:

• هذه أمه
• وهذه زوجته
• وهذه أم أولاده
• وهذا أخوه من الأم
• وهذا مولى أسرته
• وهذا ورد في كتاب كذا
• وهذا مختلف فيه بين مصدرين
• وهذه العلاقة موثقة بدرجة ثقة متوسطة
• وهذا الشخص نفسه له اسم آخر وكنية أخرى

يعني الشجرة عظم، والـ Knowledge Graph عظم + لحم + أعصاب + جهاز دوران.
صار المخلوق يمشي، لا مجرد هيكل معلق.

لماذا هو مناسب جدًا لمشروعكم؟

لأن مشروعكم ليس مجرد “رسم أنساب قريش”.

أنتم تريدون غالبًا أشياء مثل:

• ربط الأشخاص بعضهم ببعض
• فهم الزواج والتحالفات
• تتبع الفروع
• جمع الروايات من مصادر متعددة
• توحيد الشخص الواحد رغم اختلاف الأسماء
• إظهار النساء والأمهات والسراري والموالي
• تحليل الشبكات الاجتماعية والسياسية

وهذه كلها أمور الشجرة العادية لا تكفي لها.

مثال

لو عندك شجرة بني أمية فقط، ستعرف تسلسل الآباء والأبناء.
لكن إذا سألت:

• من أكثر البطون زواجًا من بني هاشم؟
• من هن النساء اللواتي ربطْن بين بيتين كبيرين؟
• ما الأشخاص الذين يظهرون في أكثر من مصدر مع اختلاف في اسم الأم؟
• ما أبناء أم ولد داخل بطن معيّن؟
• ما البيوت التي كثرت فيها المصاهرات الداخلية؟
• ما الشخصيات المركزية في شبكة النسب والزواج؟

فهنا تدخل منطقة الـ Knowledge Graph بقوة.

كيف يبدو هذا عمليًا في مشروعكم؟

أقترح أن تفكروا فيه على أربع طبقات:

الطبقة الأولى: الأشخاص

كل شخص يصبح كيانًا مستقلًا.

مثال:

• Person: p_000123
• الاسم المعتمد: زمعة بن الأسود
• الجنس: ذكر
• الكنية: إن وجدت
• اللقب: إن وجد
• النسبة: القرشي الأسدي مثلًا
• ملاحظات: قتل يوم كذا، أو أدرك الإسلام، أو لا عقب له

هذه الطبقة مهمة جدًا لأن كل شيء سيدور حول “هوية الشخص”.

الطبقة الثانية: العلاقات

بدل أن تضع كل شيء كنص، تنشئ علاقات منفصلة.

مثلًا:

• p_000123 — father_of — p_000124
• p_000123 — spouse_of — p_000220
• p_000124 — mother_is — p_000220
• p_000123 — member_of — clan_045
• p_000123 — mentioned_in — source_nasab_quraysh

هذه العلاقات هي قلب المشروع.

الطبقة الثالثة: المصادر والشواهد

كل معلومة يجب ألا تعيش وحدها في الهواء.

يعني لا تقول فقط:

• فلان زوج فلانة

بل تقول:

• العلاقة موجودة في: نسب قريش، صفحة كذا، سطر كذا
• درجة الثقة: عالية
• هل توجد مصادر أخرى تؤيدها؟ نعم / لا
• هل هناك خلاف؟ نعم / لا

هذا مهم جدًا لأن مشروعكم ليس لعبة شجرة على الإنترنت، بل مشروع علمي.

الطبقة الرابعة: التطبيع والتحليل

هنا تبدأون في استخدام الشبكة لاستخراج نتائج:

• شبكة المصاهرات
• كثافة الروابط بين البطون
• الأشخاص الأكثر مركزية
• النساء الرابطات بين البيوت
• التوسع الزمني بين الأجيال
• المقارنة بين كتاب وآخر

وهنا يصبح المشروع “منتجًا بحثيًا” لا مجرد قاعدة بيانات.

الفرق بين قاعدة بيانات عادية وKnowledge Graph

قاعدة البيانات العادية غالبًا تكون جداول:

| id | name | father_id | mother_id |

وهذا جيد كبداية.

لكن مشكلته:

• صلب
• محدود
• صعب التوسع
• لا يتعامل بسهولة مع التعدد والالتباس
• يضطرّك إلى حشر العلاقات المعقدة في أعمدة مربكة

أما الـ Knowledge Graph فهو أكثر مرونة.

مثال: لو أردت تمثيل:

• شخص له اسم بديل
• أو أم مجهولة
• أو زوجة محتملة
• أو خلاف بين مصدرين
• أو علاقة “مولى”
• أو “أخ لأم”
• أو “منقرض إلا من البنات”

في الجداول التقليدية ستبدأ الأعمدة تتكاثر كالأرانب.
أما في الـ Graph فهذه كلها علاقات أو خصائص يمكن إضافتها بسهولة.

ما أنواع الكيانات الممكنة في مشروعكم؟

هذه نقطة مهمة جدًا.
في مشروعكم لا تحصروا أنفسكم في “أشخاص فقط”.

يمكن أن يكون عندكم:

أشخاص

• رجال
• نساء
• موالي
• أبناء أم ولد
• رواة

جماعات

• قريش
• البطون الكبرى
• الأفخاذ
• الأحلاف

مصادر

• نسب قريش
• جمهرة النسب
• الطبقات الكبرى
• البلاذري
• الزبيري
• روبنسون كدراسة تحليلية، لا كمصدر أصلي

أحداث

• زواج
• ولادة
• وفاة
• معركة
• هجرة
• خلافة
• نزاع أو تحالف

أماكن

• مكة
• المدينة
• الطائف
• الكوفة
• الشام

مفاهيم نسبية

• أم ولد
• لا عقب
• منقرض
• حليف
• مولى

وهنا يبدأ المشروع يأخذ شكل موسوعة حقيقية.

ما أهم العلاقات التي تحتاجونها؟

أرى أن تبدأوا بعلاقات قليلة لكن قوية، بدل خمسين علاقة من أول يوم.

ابدؤوا بهذه:

علاقات الهوية

• same_as
• has_name_variant
• has_kunya
• has_laqab

علاقات النسب

• father_of
• mother_of
• child_of
• sibling_of
• maternal_sibling_of
• paternal_sibling_of

علاقات الزواج

• spouse_of
• had_child_with
• mother_of_child
• father_of_child

علاقات الانتماء

• member_of
• branch_of
• allied_with
• mawla_of

علاقات المصدر

• mentioned_in
• asserted_by
• disputed_by
• supported_by

علاقات الزمن والمكان

• lived_in
• died_in
• associated_with_period
• present_at_event

هذه تكفي لبداية قوية جدًا.

كيف يساعد ذلك في حل مشكلات روبنسون نفسها؟

هذا هو الجزء الجميل.

روبنسون واجه صعوبات مثل:

• الغموض في عدد السراري
• اختصار البنات
• تفاوت الأسماء
• غياب الزمن الدقيق
• اختلاف المصادر
• الحاجة إلى قرارات تحريرية

الـ Knowledge Graph لا يلغي هذه المشكلات، لكنه يجعل تمثيلها ممكنًا بدل كسرها بالقوة.

مثال 1: الأم مجهولة

بدل أن تترك الحقل فارغًا فقط، تستطيع أن تسجل:

• child_x — mother_status — umm_walad_unknown
• confidence: medium
• source: Nasab Quraysh

مثال 2: خلاف في النسب

• person_x — mother_is — person_a
• asserted_by: source_1
• confidence: medium

وفي نفس الوقت:

• person_x — mother_is — person_b
• asserted_by: source_2
• confidence: medium

يعني الشبكة تستوعب الخلاف، بدل أن تجبرك على اختيار واحد ومسح الآخر.

مثال 3: البنات مختزلات في “نسوة”

تستطيع تمثيل هذا كبيان ناقص:

• person_x — has_unidentified_daughters_count — unknown_plural
• source: Nasab Quraysh
• note: text says “نسوة”

ليست معلومة مثالية، لكنها أفضل من اختفائها تمامًا.

كيف تبنون هذا من الناحية العملية؟

أفضل مسار ليس أن تقفزوا مباشرة إلى نظام Graph معقد.
ابدؤوا على مراحل.

المرحلة 1: تصميم النموذج المعرفي

قبل أي برمجة، حددوا:

• ما هو الشخص؟
• ما هو الحدث؟
• ما هو المصدر؟
• ما أنواع العلاقات؟
• ما الذي يعد “معلومة”؟
• كيف نمثل الشك؟
• كيف نمثل المجهول؟
• كيف نمثل الاسم البديل؟
• كيف نمثل التقدير الزمني؟

هذا يسمى أحيانًا schema أو ontology بشكل مبسط.

المرحلة 2: بناء قاعدة بيانات وسيطة

في البداية يمكنكم استخدام جداول عادية:

• persons
• names
• relationships
• sources
• citations
• clans
• events

هذا أسهل في الإدخال والمراجعة.

ثم لاحقًا يمكن تحويلها إلى Graph database أو تصديرها كـ graph.

المرحلة 3: التطبيع

هذه أهم مرحلة وأتعبها:

• توحيد الأسماء
• فصل الأشخاص المتشابهين
• ربط الكنيات
• ربط الأمهات
• تصحيح التكرار
• تسجيل درجة الثقة

هنا يصنع الفرق بين مشروع قوي ومشروع جميل من بعيد فقط.

المرحلة 4: تمثيل الرسم البياني

بعد ذلك يمكن استخدام:

• Neo4j
• RDF/OWL إذا أردتم طابعًا دلاليًا أكثر
• أو حتى networkx وواجهات عرض خاصة

لكن لا تجعلوا الأداة هي البداية.
البداية هي النموذج العلمي.

مثال صغير جدًا من مشروعكم

لنأخذ حالة تخيلية مبسطة:

النص:
“زمعة بن الأسود، وولد عبد الله الأكبر فانقرض إلا من البنات، ويزيد أمه فلانة، وعبد الله الأصغر ولدته أم ولد.”

يمكن تمثيله هكذا:

كيانات

• زمعة بن الأسود
• عبد الله الأكبر
• يزيد
• عبد الله الأصغر
• فلانة
• أم ولد مجهولة
• بني أسد
• نسب قريش

علاقات

• زمعة — father_of — عبد الله الأكبر
• زمعة — father_of — يزيد
• زمعة — father_of — عبد الله الأصغر
• يزيد — mother_is — فلانة
• عبد الله الأصغر — mother_status — أم ولد مجهولة
• زمعة — member_of — بني أسد
• هذه العبارات — asserted_by — نسب قريش

خصائص

• عبد الله الأكبر: lineage_status = extinct_except_daughters

هنا صار بإمكانك لاحقًا أن تسأل:

• كم عدد أبناء أم الولد في هذا البطن؟
• كم الأشخاص الذين انقرض نسلهم الذكوري؟
• من الأمهات اللواتي يرد ذكرهن بالاسم؟
• ما المواضع التي تأتي فيها الأم مجهولة؟

هذا بالضبط هو الانتقال من نص إلى معرفة قابلة للحساب.

لماذا هذا يرفع قيمة المشروع جدًا؟

لأن المشروع حينها لن يكون:
“لدينا أنساب قريش.”

بل سيكون:
“لدينا Knowledge Graph للقرابة والزواج والانتماء والمصادر في قريش المبكرة.”

وهذا يفتح أبوابًا كثيرة:

بحثيًا

• تحليل الزواج
• تحليل التحالفات
• دراسة النخب
• الشبكات بين البطون
• الأمومة والشرعية
• كثافة الروابط

تقنيًا

• بحث ذكي
• واجهة استعلام
• اقتراح علاقات محتملة
• عرض بصري
• تصدير بيانات للباحثين

تمويليًا

هذا الوصف أقوى بكثير عند الجامعات والمراكز والممولين، لأنكم لا تقدمون مجرد “جمع معلومات”، بل:

• بنية تحتية معرفية
• corpus structured
• graph-ready data
• foundation for digital humanities

ما الذي يجب الحذر منه؟

الـ Knowledge Graph ليس عصًا سحرية.
هناك أخطاء شائعة لو وقعتم فيها صار المشروع أنيقًا ومربكًا في الوقت نفسه.

الخطأ الأول

تحويل كل شيء إلى رسم شبكي جميل قبل ضبط الهوية والمصدر.

النتيجة: شبكة مذهلة بصريًا… لكنها مليئة بأخطاء نسبية كارثية.

الخطأ الثاني

الإفراط في عدد أنواع العلاقات من البداية.

ابدؤوا بعشرة أو خمسة عشر نوعًا أساسيًا، ثم توسعوا.

الخطأ الثالث

عدم التمييز بين:

• المعلومة المؤكدة
• المعلومة المحتملة
• المعلومة المختلف فيها
• المعلومة الناقصة

هذا قاتل علميًا.

الخطأ الرابع

الخلط بين الشخص وبين “ذكر الشخص في مصدر”.

أحيانًا الأفضل أن تميزوا بين:

• الشخص التاريخي
• والادعاء النصي عن هذا الشخص

لأن المصدر قد يذكر شيئًا يختلف مع مصدر آخر.

الشكل المثالي لمشروعكم

أراه على هذا النحو:

المستوى الأول

قاعدة بيانات موثقة بدقة

المستوى الثاني

Knowledge Graph للعلاقات

المستوى الثالث

واجهة بحث:

• ابحث عن شخص
• اعرض شجرته
• اعرض زوجاته وأمهات أولاده
• اعرض صلاته ببطون أخرى
• اعرض مصادر كل معلومة

المستوى الرابع

أدوات تحليل:

• شبكة المصاهرات
• كثافة الارتباط بين البطون
• الشخصيات المركزية
• خرائط زمنية
• إحصاء النساء المذكورات وغير المذكورات
• إحصاء أبناء الإماء وأبناء الحرائر

المستوى الخامس

ربط مصادر متعددة

• نسب قريش
• الطبقات
• البلاذري
• غيرها

وهنا يتحول المشروع من قاعدة نسب إلى منصة بحثية فعلًا.

هل هو ممكن لكم؟

نعم، بل أراه ممكنًا جدًا إذا بدأتم بشكل منضبط.
وليس مطلوبًا من أول يوم أن تبنوا Graph عالميًا معقدًا.

المطلوب:

• نموذج واضح
• مجموعة كيانات مضبوطة
• علاقات قليلة قوية
• مصدر موثق
• مراجعة صارمة
• ثم التوسع

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

الخلاصة

Knowledge Graph في مشروعكم يعني تحويل كتب الأنساب من نصوص سردية إلى شبكة معرفية قابلة للبحث والتحليل والتمدد.
وهو مناسب جدًا لكم لأن مشروعكم لا يدور حول “من ابن من” فقط، بل حول:

• القرابة
• الزواج
• البطون
• النساء
• الأمومة
• التحالف
• المصدر
• الشك والاختلاف
• التحليل الشبكي

بكلمة واحدة:
هو ينقل المشروع من شجرة أنساب إلى خريطة مجتمع.