trustgraph/docs/tech-specs/extraction-time-provenance.ar.md

---
layout: default
title: "أصل البيانات في وقت الاستخراج: الطبقة المصدر"
parent: "Arabic (Beta)"
---

# أصل البيانات في وقت الاستخراج: الطبقة المصدر

> **Beta Translation:** This document was translated via Machine Learning and as such may not be 100% accurate. All non-English languages are currently classified as Beta.

## نظرة عامة

يوثق هذا المستند ملاحظات حول أصل البيانات في وقت الاستخراج لأعمال المواصفات المستقبلية. يسجل أصل البيانات في وقت الاستخراج "الطبقة المصدر" - من أين أتت البيانات في الأصل، وكيف تم استخراجها وتحويلها.

هذا يختلف عن أصل البيانات في وقت الاستعلام (انظر `query-time-provenance.md`) الذي يسجل استنتاجات الوكيل.

## بيان المشكلة

### التنفيذ الحالي

يعمل أصل البيانات حاليًا على النحو التالي:
<<<<<<< HEAD
يتم تخزين بيانات وصف المستند كـ RDF triples في الرسم البياني المعرفي.
=======
يتم تخزين بيانات وصف المستند كـ "ثلاثيات" RDF في الرسم البياني للمعرفة.
>>>>>>> 82edf2d (New md files from RunPod)
يربط معرف المستند البيانات الوصفية بالمستند، بحيث يظهر المستند كعقدة في الرسم البياني.
عند استخراج الحواف (العلاقات/الحقائق) من المستندات، تربط علاقة `subjectOf` الحافة المستخرجة بالمستند المصدر.

### المشاكل في النهج الحالي

<<<<<<< HEAD
1. **تحميل البيانات الوصفية المتكرر:** يتم تجميع بيانات وصف المستند وتحميلها بشكل متكرر مع كل مجموعة من الـ triples المستخرجة من هذا المستند. هذا مضيعة ويزيد من التكرار - نفس البيانات الوصفية تنتقل كحمولة مع كل مخرج استخراج.
=======
1. **تحميل البيانات الوصفية المتكرر:** يتم تجميع بيانات وصف المستند وتحميلها بشكل متكرر مع كل مجموعة من "الثلاثيات" المستخرجة من هذا المستند. هذا مضيعة ويزيد من التكرار - حيث تنتقل نفس البيانات الوصفية كحمولة مع كل مخرج استخراج.
>>>>>>> 82edf2d (New md files from RunPod)

2. **أصل بيانات سطحي:** تربط العلاقة `subjectOf` الحالية الحقائق مباشرة بالمستند ذي المستوى الأعلى فقط. لا توجد رؤية لسلسلة التحويل - أي الصفحة التي جاءت منها الحقيقة، أو الجزء، أو طريقة الاستخراج المستخدمة.

### الحالة المرغوبة

<<<<<<< HEAD
1. **تحميل البيانات الوصفية مرة واحدة:** يجب تحميل بيانات وصف المستند مرة واحدة وإرفاقها بعقدة المستند ذات المستوى الأعلى، وليس تكرارها مع كل مجموعة من الـ triples.
=======
1. **تحميل البيانات الوصفية مرة واحدة:** يجب تحميل بيانات وصف المستند مرة واحدة وإرفاقها بعقدة المستند ذات المستوى الأعلى، وليس تكرارها مع كل مجموعة من "الثلاثيات".
>>>>>>> 82edf2d (New md files from RunPod)

2. **رسم بياني كامل لأصل البيانات:** التقاط سلسلة التحويل الكاملة من المستند المصدر عبر جميع القطع الأثرية الوسيطة وصولاً إلى الحقائق المستخرجة. على سبيل المثال، تحويل مستند PDF:

   ```
   PDF file (source document with metadata)
     → Page 1 (decoded text)
       → Chunk 1
         → Extracted edge/fact (via subjectOf)
         → Extracted edge/fact
       → Chunk 2
         → Extracted edge/fact
     → Page 2
       → Chunk 3
         → ...
   ```

<<<<<<< HEAD
3. **التخزين الموحد:** يتم تخزين الرسم البياني للأصل (provenance DAG) في نفس الرسم البياني للمعرفة كما يتم تخزين المعرفة المستخرجة. يتيح ذلك الاستعلام عن الأصل بنفس الطريقة التي يتم بها الاستعلام عن المعرفة - من خلال تتبع الحواف صعودًا في السلسلة من أي حقيقة إلى موقع مصدرها الدقيق.

4. **معرفات مستقرة:** لكل قطعة أثرية وسيطة (صفحة، جزء) معرف مستقر كعقدة في الرسم البياني.

5. **الربط بين الأب والطفل:** يتم ربط المستندات المشتقة بآبائها وصولاً إلى المستند المصدر الرئيسي باستخدام أنواع علاقات متسقة.

6. **تخصيص الحقائق بدقة:** تشير العلاقة `subjectOf` في الحواف المستخرجة إلى الأصل الفوري (الجزء)، وليس المستند الرئيسي. يتم استعادة الأصل الكامل من خلال التنقل عبر الرسم البياني للأصل.
=======
3. **التخزين الموحد:** يتم تخزين الرسم البياني للأصل (provenance DAG) في نفس الرسم البياني للمعرفة مثل المعرفة المستخرجة. يتيح ذلك الاستعلام عن الأصل بنفس الطريقة التي يتم بها الاستعلام عن المعرفة - من خلال تتبع الحواف صعودًا في السلسلة من أي حقيقة إلى موقع مصدرها الدقيق.

4. **معرفات مستقرة:** لكل قطعة أثرية وسيطة (صفحة، جزء) معرف مستقر كعقدة في الرسم البياني.

5. **الربط بين الأبناء والآباء:** يتم ربط المستندات المشتقة بآبائها وصولاً إلى المستند المصدر الرئيسي باستخدام أنواع علاقات متسقة.

6. **تخصيص الحقائق بدقة:** تشير العلاقة `subjectOf` في الحواف المستخرجة إلى الأصل الفوري (الجزء)، وليس المستند الرئيسي. يتم استعادة الأصل الكامل من خلال اجتياز الرسم البياني للأصل.
>>>>>>> 82edf2d (New md files from RunPod)

## حالات الاستخدام

### UC1: تحديد مصدر المعلومات في استجابات GraphRAG

**السيناريو:** يقوم المستخدم بتشغيل استعلام GraphRAG ويتلقى استجابة من الوكيل.

**التدفق:**
1. يرسل المستخدم استعلامًا إلى وكيل GraphRAG.
2. يسترجع الوكيل الحقائق ذات الصلة من الرسم البياني للمعرفة لصياغة استجابة.
3. وفقًا لمواصفات الأصل في وقت الاستعلام، يقوم الوكيل بالإبلاغ عن الحقائق التي ساهمت في الاستجابة.
<<<<<<< HEAD
4. يربط كل حقيقة بمصدره (الجزء) عبر الرسم البياني للأصل.
5. ترتبط الأجزاء بالصفحات، وترتبط الصفحات بمستندات المصدر.

**النتيجة في تجربة المستخدم:** يعرض الواجهة استجابة نموذج اللغة الكبير (LLM) جنبًا إلى جنب مع تحديد مصدر المعلومات. يمكن للمستخدم:
رؤية الحقائق التي دعمت الاستجابة.
النزول من الحقائق إلى الأجزاء إلى الصفحات إلى المستندات.
مراجعة المستندات المصدر الأصلية للتحقق من صحة الادعاءات.
فهم بالضبط من أين في المستند (في أي صفحة، في أي قسم) نشأت الحقيقة.

**القيمة:** يمكن للمستخدمين التحقق من صحة الاستجابات التي تم إنشاؤها بواسطة الذكاء الاصطناعي مقابل المصادر الأولية، مما يعزز الثقة ويمكن المستخدمين من التحقق من الحقائق.
=======
4. ترتبط كل حقيقة بمصدرها من خلال الرسم البياني للأصل.
5. ترتبط الأجزاء بالصفحات، وترتبط الصفحات بمستندات المصدر.

**النتيجة في تجربة المستخدم:** يعرض الواجهة استجابة نموذج اللغة (LLM) جنبًا إلى جنب مع تحديد مصدر المعلومات. يمكن للمستخدم:
رؤية الحقائق التي دعمت الاستجابة.
الانتقال من الحقائق إلى الأجزاء إلى الصفحات إلى المستندات.
مراجعة المستندات المصدر الأصلية للتحقق من الادعاءات.
فهم بالضبط من أين في المستند (في أي صفحة، في أي قسم) نشأت الحقيقة.

**القيمة:** يمكن للمستخدمين التحقق من الاستجابات التي تم إنشاؤها بواسطة الذكاء الاصطناعي مقابل المصادر الأولية، مما يعزز الثقة ويمكن المستخدمين من التحقق من الحقائق.
>>>>>>> 82edf2d (New md files from RunPod)

### UC2: تصحيح جودة الاستخراج

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

### UC3: إعادة استخراج تدريجي

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

### UC4: حذف البيانات / الحق في النسيان

<<<<<<< HEAD
يجب إزالة مستند المصدر (بسبب اللائحة العامة لحماية البيانات، أو لأسباب قانونية، إلخ). تتبع الرسم البياني للأصل للعثور على جميع الحقائق المشتقة وإزالتها.

### UC5: حل النزاعات

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

### UC6: وزن سلطة المصدر

بعض المصادر أكثر موثوقية من غيرها. يمكن ترجيح الحقائق أو تصفيتها بناءً على سلطة/جودة مستندات الأصل.

### UC7: مقارنة مسار الاستخراج
=======
يجب إزالة مستند المصدر (بسبب GDPR، أو لأسباب قانونية، وما إلى ذلك). ابحث في الرسم البياني للأصل وأزل جميع الحقائق المشتقة.

### UC5: حل النزاعات

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

### UC6: وزن سلطة المصدر

بعض المصادر أكثر موثوقية من غيرها. يمكن وزن الحقائق أو تصفيتها بناءً على سلطة/جودة مستندات الأصل.

### UC7: مقارنة مسارات الاستخراج
>>>>>>> 82edf2d (New md files from RunPod)

قارن المخرجات من طرق/إصدارات استخراج مختلفة. أي أداة استخراج أنتجت حقائق أفضل من نفس المصدر؟

## نقاط التكامل

### أمين المكتبة

يوفر مكون أمين المكتبة بالفعل تخزين المستندات بمعرفات مستندات فريدة. يتكامل نظام التتبع مع هذه البنية التحتية الحالية.

#### القدرات الحالية (تم تنفيذها بالفعل)

<<<<<<< HEAD
**ربط المستندات من الأب إلى الابن:**
`parent_id` الحقل في `DocumentMetadata` - يربط المستند الابن بالمستند الأب
`document_type` الحقل - القيم: `"source"` (أصلي) أو `"extracted"` (مشتق)
واجهة برمجة تطبيقات `add-child-document` - لإنشاء مستند ابن بمعرف `document_type = "extracted"` تلقائيًا
واجهة برمجة تطبيقات `list-children` - لاسترداد جميع المستندات الابناء لمستند أب معين
الحذف المتتالي - يؤدي إزالة مستند الأب تلقائيًا إلى حذف جميع مستندات الأبناء

**تحديد المستند:**
معرفات المستندات محددة من قبل العميل (وليس تم إنشاؤها تلقائيًا)
المستندات مفهرسة باستخدام `(user, document_id)` المركب في Cassandra
يتم إنشاء معرفات الكائنات (UUIDs) داخليًا لتخزين الكائنات الثنائية

**دعم البيانات الوصفية:**
`metadata: list[Triple]` الحقل - ثلاثيات RDF للبيانات الوصفية المنظمة
`title`، `comments`، `tags` - بيانات وصفية أساسية للمستند
`time` - الطابع الزمني، `kind` - نوع MIME

**هيكل التخزين:**
يتم تخزين البيانات الوصفية في Cassandra (مساحة مفاتيح `librarian`، جدول `document`)
يتم تخزين المحتوى في تخزين الكائنات الثنائية MinIO/S3 (دلو `library`)
تسليم محتوى ذكي: يتم تضمين المستندات الأقل من 2 ميجابايت، ويتم بث المستندات الأكبر حجمًا

#### الملفات الرئيسية

`trustgraph-flow/trustgraph/librarian/librarian.py` - العمليات الأساسية لأمين المكتبة
`trustgraph-flow/trustgraph/librarian/service.py` - معالج الخدمة، تحميل المستند
`trustgraph-flow/trustgraph/tables/library.py` - تخزين جدول Cassandra
`trustgraph-base/trustgraph/schema/services/library.py` - تعريفات المخططات
=======
**ربط المستندات من النوع "الأب-الابن":**
الحقل `parent_id` في `DocumentMetadata` - يربط المستند الابن بالمستند الأب.
الحقل `document_type` - القيم: `"source"` (أصلي) أو `"extracted"` (مشتق).
واجهة برمجة تطبيقات `add-child-document` - لإنشاء مستند ابن مع `document_type = "extracted"` تلقائيًا.
واجهة برمجة تطبيقات `list-children` - لاسترداد جميع المستندات الابناء لمستند أب معين.
الحذف المتتالي - يؤدي إزالة مستند الأب تلقائيًا إلى حذف جميع مستندات الأبناء.

**تحديد المستند:**
معرفات المستندات محددة من قبل العميل (وليس تم إنشاؤها تلقائيًا).
المستندات مفهرسة بواسطة مفتاح مركب `(user, document_id)` في Cassandra.
يتم إنشاء معرفات الكائنات (UUIDs) داخليًا لتخزين الكائنات الثنائية.

**دعم البيانات الوصفية:**
الحقل `metadata: list[Triple]` - ثلاثيات RDF للبيانات الوصفية المنظمة.
`title`، `comments`، `tags` - بيانات وصفية أساسية للمستند.
`time` - الطابع الزمني، `kind` - نوع MIME.

**هيكل التخزين:**
يتم تخزين البيانات الوصفية في Cassandra (مساحة مفاتيح `librarian`، جدول `document`).
يتم تخزين المحتوى في تخزين الكائنات الثنائية MinIO/S3 (حاوية `library`).
تسليم محتوى ذكي: المستندات الأقل من 2 ميجابايت مضمنة، ويتم بث المستندات الأكبر حجمًا.

#### الملفات الرئيسية

`trustgraph-flow/trustgraph/librarian/librarian.py` - العمليات الأساسية لأمين المكتبة.
`trustgraph-flow/trustgraph/librarian/service.py` - معالج الخدمة، تحميل المستند.
`trustgraph-flow/trustgraph/tables/library.py` - متجر جدول Cassandra.
`trustgraph-base/trustgraph/schema/services/library.py` - تعريفات المخططات.
>>>>>>> 82edf2d (New md files from RunPod)

#### الثغرات التي يجب معالجتها

يحتوي أمين المكتبة على اللبنات الأساسية ولكن حاليًا:
<<<<<<< HEAD
1. الربط من الأب إلى الابن ذو مستوى واحد فقط - لا توجد أدوات مساعدة لتصفح الرسوم البيانية متعددة المستويات
2. لا يوجد مفردات قياسية لأنواع العلاقات (مثل `derivedFrom`، `extractedFrom`)
3. بيانات التتبع الوصفية (طريقة الاستخراج، والثقة، وموضع الجزء) غير موحدة
4. لا توجد واجهة برمجة تطبيقات للاستعلام للتنقل عبر سلسلة التتبع الكاملة من حقيقة إلى المصدر
=======
1. ربط الأب-الابن ذو مستوى واحد فقط - لا توجد أدوات مساعدة لتصفح الرسوم البيانية متعددة المستويات.
2. لا يوجد مفردات قياسية لأنواع العلاقات (مثل `derivedFrom`، `extractedFrom`).
3. بيانات التتبع الوصفية (طريقة الاستخراج، والثقة، وموضع الجزء) غير موحدة.
4. لا توجد واجهة برمجة تطبيقات للاستعلام للتنقل عبر سلسلة التتبع الكاملة من حقيقة إلى المصدر.
>>>>>>> 82edf2d (New md files from RunPod)

## تصميم التدفق الشامل

يتبع كل معالج في خط الأنابيب نمطًا متسقًا:
<<<<<<< HEAD
استقبال معرف المستند من البنية التحتية
جلب المحتوى من أمين المكتبة
إنتاج القطع الأثرية الفرعية
لكل قطعة أثرية فرعية: حفظ في أمين المكتبة، وإصدار حافة إلى الرسم البياني، وتمرير المعرف إلى البنية التحتية
=======
استقبال معرف المستند من المصدر العلوي.
جلب المحتوى من أمين المكتبة.
إنتاج القطع الأثرية الفرعية.
لكل قطعة أثرية فرعية: حفظ في أمين المكتبة، وإصدار حافة إلى الرسم البياني، وتمرير المعرف إلى المكون التالي.
>>>>>>> 82edf2d (New md files from RunPod)

### تدفقات المعالجة

هناك تدفقان اعتمادًا على نوع المستند:

#### تدفق مستند PDF

```
┌─────────────────────────────────────────────────────────────────────────┐
│ Librarian (initiate processing)                                         │
│   1. Emit root document metadata to knowledge graph (once)              │
│   2. Send root document ID to PDF extractor                             │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ PDF Extractor (per page)                                                │
│   1. Fetch PDF content from librarian using document ID                 │
│   2. Extract pages as text                                              │
│   3. For each page:                                                     │
│      a. Save page as child document in librarian (parent = root doc)   │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send page document ID to chunker                                │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Chunker (per chunk)                                                     │
│   1. Fetch page content from librarian using document ID                │
│   2. Split text into chunks                                             │
│   3. For each chunk:                                                    │
│      a. Save chunk as child document in librarian (parent = page)      │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send chunk document ID + chunk content to next processor        │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
          ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
          Post-chunker optimization: messages carry both
          chunk ID (for provenance) and content (to avoid
          librarian round-trip). Chunks are small (2-4KB).
          ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Knowledge Extractor (per chunk)                                         │
│   1. Receive chunk ID + content directly (no librarian fetch needed)   │
│   2. Extract facts/triples and embeddings from chunk content            │
│   3. For each triple:                                                   │
│      a. Emit triple to knowledge graph                                  │
│      b. Emit reified edge linking triple → chunk ID (edge pointing     │
│         to edge - first use of reification support)                     │
│   4. For each embedding:                                                │
│      a. Emit embedding with its entity ID                               │
│      b. Link entity ID → chunk ID in knowledge graph                   │
└─────────────────────────────────────────────────────────────────────────┘
```

#### تدفق مستندات النص

تتجاوز مستندات النص أداة استخراج ملفات PDF وتنتقل مباشرةً إلى وحدة التقسيم:

```
┌─────────────────────────────────────────────────────────────────────────┐
│ Librarian (initiate processing)                                         │
│   1. Emit root document metadata to knowledge graph (once)              │
│   2. Send root document ID directly to chunker (skip PDF extractor)    │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Chunker (per chunk)                                                     │
│   1. Fetch text content from librarian using document ID                │
│   2. Split text into chunks                                             │
│   3. For each chunk:                                                    │
│      a. Save chunk as child document in librarian (parent = root doc) │
│      b. Emit parent-child edge to knowledge graph                       │
│      c. Send chunk document ID + chunk content to next processor        │
└─────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────────────┐
│ Knowledge Extractor                                                     │
│   (same as PDF flow)                                                    │
└─────────────────────────────────────────────────────────────────────────┘
```

الرسم البياني الموجه الناتج أقصر بمستوى واحد:

```
PDF:  Document → Pages → Chunks → Triples/Embeddings
Text: Document → Chunks → Triples/Embeddings
```

<<<<<<< HEAD
التصميم يتكيف مع كل من المصدر والصفحة لأن وحدة التقسيم تعالج مدخلاتها بشكل عام - فهي تستخدم أي معرف مستند تتلقاه كمعرف رئيسي، بغض النظر عما إذا كان ذلك مستند مصدر أم صفحة.

### مخطط البيانات الوصفية (PROV-O)

تستخدم البيانات الوصفية المتعلقة بالأصل علم الوجود W3C PROV-O. يوفر هذا مفردات قياسية ويمكن أن يمكّن التوقيع/المصادقة المستقبلية لنتائج الاستخراج.
=======
التصميم يتكيف مع كلتا الحالتين لأن وحدة التقسيم تعالج مدخلاتها بشكل عام - فهي تستخدم أي معرف مستند تتلقاه كمعرف رئيسي، بغض النظر عما إذا كان ذلك مستندًا أصليًا أم صفحة.

### مخطط البيانات الوصفية (PROV-O)

تستخدم البيانات الوصفية المتعلقة بالأصل علم الوجود W3C PROV-O. يوفر هذا مفردات قياسية ويمكن أن يتيح في المستقبل التوقيع والمصادقة على مخرجات الاستخراج.
>>>>>>> 82edf2d (New md files from RunPod)

#### المفاهيم الأساسية في PROV-O

| نوع PROV-O | استخدام TrustGraph |
|-------------|------------------|
| `prov:Entity` | مستند، صفحة، جزء، ثلاثي، تضمين |
| `prov:Activity` | حالات عمليات الاستخراج |
| `prov:Agent` | مكونات TG (مثل أداة استخراج PDF، ووحدة التقسيم، إلخ) مع الإصدارات |

#### علاقات PROV-O

| الرابط | المعنى | مثال |
|-----------|---------|---------|
| `prov:wasDerivedFrom` | كيان مشتق من كيان آخر | الصفحة مشتقة من المستند |
| `prov:wasGeneratedBy` | كيان تم إنشاؤه بواسطة نشاط | الصفحة تم إنشاؤها بواسطة نشاط استخراج PDF |
| `prov:used` | نشاط استخدم كيانًا كمدخل | نشاط استخراج PDF استخدم المستند |
| `prov:wasAssociatedWith` | نشاط تم تنفيذه بواسطة وكيل | نشاط استخراج PDF مرتبط بـ tg:PDFExtractor |

#### البيانات الوصفية في كل مستوى

<<<<<<< HEAD
**المستند المصدر (يتم إصداره بواسطة Librarian):**
=======
**المستند الأصلي (يتم إصداره بواسطة Librarian):**
>>>>>>> 82edf2d (New md files from RunPod)
```
doc:123 a prov:Entity .
doc:123 dc:title "Research Paper" .
doc:123 dc:source <https://example.com/paper.pdf> .
doc:123 dc:date "2024-01-15" .
doc:123 dc:creator "Author Name" .
doc:123 tg:pageCount 42 .
doc:123 tg:mimeType "application/pdf" .
```

**الصفحة (تم إنشاؤها بواسطة مُستخرج PDF):**
```
page:123-1 a prov:Entity .
page:123-1 prov:wasDerivedFrom doc:123 .
page:123-1 prov:wasGeneratedBy activity:pdf-extract-456 .
page:123-1 tg:pageNumber 1 .

activity:pdf-extract-456 a prov:Activity .
activity:pdf-extract-456 prov:used doc:123 .
activity:pdf-extract-456 prov:wasAssociatedWith tg:PDFExtractor .
activity:pdf-extract-456 tg:componentVersion "1.2.3" .
activity:pdf-extract-456 prov:startedAtTime "2024-01-15T10:30:00Z" .
```

<<<<<<< HEAD
**الجزء (يتم إصداره بواسطة وحدة التجميع):**
=======
**جزء (يتم إصداره بواسطة أداة التقسيم):**
>>>>>>> 82edf2d (New md files from RunPod)
```
chunk:123-1-1 a prov:Entity .
chunk:123-1-1 prov:wasDerivedFrom page:123-1 .
chunk:123-1-1 prov:wasGeneratedBy activity:chunk-789 .
chunk:123-1-1 tg:chunkIndex 1 .
chunk:123-1-1 tg:charOffset 0 .
chunk:123-1-1 tg:charLength 2048 .

activity:chunk-789 a prov:Activity .
activity:chunk-789 prov:used page:123-1 .
activity:chunk-789 prov:wasAssociatedWith tg:Chunker .
activity:chunk-789 tg:componentVersion "1.0.0" .
activity:chunk-789 tg:chunkSize 2048 .
activity:chunk-789 tg:chunkOverlap 200 .
```

**ثلاثي (تم إصداره بواسطة مُستخلص المعرفة):**
```
# The extracted triple (edge)
entity:JohnSmith rel:worksAt entity:AcmeCorp .

# Subgraph containing the extracted triples
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 prov:wasGeneratedBy activity:extract-999 .

activity:extract-999 a prov:Activity .
activity:extract-999 prov:used chunk:123-1-1 .
activity:extract-999 prov:wasAssociatedWith tg:KnowledgeExtractor .
activity:extract-999 tg:componentVersion "2.1.0" .
activity:extract-999 tg:llmModel "claude-3" .
activity:extract-999 tg:ontology <http://example.org/ontologies/business-v1> .
```

**التضمين (يتم تخزينه في مخزن المتجهات، وليس في مخزن الثلاثيات):**

يتم تخزين التضمينات في مخزن المتجهات مع البيانات الوصفية، وليس كـ RDF triples. يحتوي كل سجل تضمين على:

| الحقل | الوصف | مثال |
|-------|-------------|---------|
| vector | متجه التضمين | [0.123, -0.456, ...] |
| entity | عنوان URI للعقدة التي يمثلها التضمين | `entity:JohnSmith` |
| chunk_id | الجزء المصدر (الأصل) | `chunk:123-1-1` |
| model | نموذج التضمين المستخدم | `text-embedding-ada-002` |
| component_version | إصدار مُحسِّن التضمين (TG embedder) | `1.0.0` |

يربط الحقل `entity` التضمين بالرسم البياني المعرفي (عنوان URI للعقدة). يوفر الحقل `chunk_id` معلومات عن الأصل إلى الجزء المصدر، مما يتيح التنقل صعودًا في الرسم البياني الموجه (DAG) إلى المستند الأصلي.

#### امتدادات مساحة اسم TrustGraph

محددات مخصصة ضمن مساحة الاسم `tg:` لبيانات وصفية خاصة بالاستخراج:

| المحدد | النطاق | الوصف |
|-----------|--------|-------------|
| `tg:contains` | Subgraph | يشير إلى ثلاثية موجودة في هذا الرسوم البيانية الفرعية للاستخراج |
| `tg:pageCount` | Document | العدد الإجمالي لصفحات المستند المصدر |
| `tg:mimeType` | Document | نوع MIME للمستند المصدر |
| `tg:pageNumber` | Page | رقم الصفحة في المستند المصدر |
| `tg:chunkIndex` | Chunk | فهرس الجزء داخل الأصل |
| `tg:charOffset` | Chunk | الإزاحة الحرفية في النص الأصل |
| `tg:charLength` | Chunk | طول الجزء بالأحرف |
| `tg:chunkSize` | Activity | حجم الجزء المُكوَّن |
| `tg:chunkOverlap` | Activity | التداخل المُكوَّن بين الأجزاء |
| `tg:componentVersion` | Activity | إصدار مكون TG |
| `tg:llmModel` | Activity | نموذج LLM المستخدم للاستخراج |
<<<<<<< HEAD
| `tg:ontology` | Activity | عنوان URI للأنطولوجيا المستخدم لتوجيه الاستخراج |
=======
| `tg:ontology` | Activity | عنوان URI للدلالة المستخدم لتوجيه الاستخراج |
>>>>>>> 82edf2d (New md files from RunPod)
| `tg:embeddingModel` | Activity | النموذج المستخدم للتضمينات |
| `tg:sourceText` | Statement | النص الدقيق الذي تم استخراج ثلاثية منه |
| `tg:sourceCharOffset` | Statement | الإزاحة الحرفية داخل الجزء حيث يبدأ النص المصدر |
| `tg:sourceCharLength` | Statement | طول النص المصدر بالأحرف |

#### تهيئة المفردات (لكل مجموعة)

<<<<<<< HEAD
الرسم البياني المعرفي محايد للأنطولوجيا ويبدأ فارغًا. عند كتابة بيانات سلالة PROV-O إلى مجموعة لأول مرة، يجب تهيئة المفردات باستخدام تسميات RDF لجميع الفئات والمحددات. يضمن ذلك عرضًا قابلاً للقراءة بواسطة الإنسان في الاستعلامات وواجهة المستخدم.
=======
الرسم البياني المعرفي محايد بالنسبة للدلالات ويبدأ فارغًا. عند كتابة بيانات سلالة PROV-O إلى مجموعة لأول مرة، يجب تهيئة المفردات باستخدام تسميات RDF لجميع الفئات والمحددات. يضمن ذلك عرضًا قابلاً للقراءة بواسطة الإنسان في الاستعلامات وواجهة المستخدم.
>>>>>>> 82edf2d (New md files from RunPod)

**فئات PROV-O:**
```
prov:Entity rdfs:label "Entity" .
prov:Activity rdfs:label "Activity" .
prov:Agent rdfs:label "Agent" .
```

<<<<<<< HEAD
**المُتَعَدِّيات (Predicates) الخاصة بـ PROV-O:**
=======
**المفردات (Predicates) الخاصة بـ PROV-O:**
>>>>>>> 82edf2d (New md files from RunPod)
```
prov:wasDerivedFrom rdfs:label "was derived from" .
prov:wasGeneratedBy rdfs:label "was generated by" .
prov:used rdfs:label "used" .
prov:wasAssociatedWith rdfs:label "was associated with" .
prov:startedAtTime rdfs:label "started at" .
```

**عبارات TrustGraph:**
```
tg:contains rdfs:label "contains" .
tg:pageCount rdfs:label "page count" .
tg:mimeType rdfs:label "MIME type" .
tg:pageNumber rdfs:label "page number" .
tg:chunkIndex rdfs:label "chunk index" .
tg:charOffset rdfs:label "character offset" .
tg:charLength rdfs:label "character length" .
tg:chunkSize rdfs:label "chunk size" .
tg:chunkOverlap rdfs:label "chunk overlap" .
tg:componentVersion rdfs:label "component version" .
tg:llmModel rdfs:label "LLM model" .
tg:ontology rdfs:label "ontology" .
tg:embeddingModel rdfs:label "embedding model" .
tg:sourceText rdfs:label "source text" .
tg:sourceCharOffset rdfs:label "source character offset" .
tg:sourceCharLength rdfs:label "source character length" .
```

**ملاحظة حول التنفيذ:** يجب أن يكون هذا الإطار اللغوي ذاتي الإعادة - آمنًا للتشغيل عدة مرات دون إنشاء تكرارات. يمكن تشغيله في معالجة المستند الأول في المجموعة، أو كخطوة منفصلة لتهيئة المجموعة.

<<<<<<< HEAD
#### أصل الجزء الفرعي (طموح)

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

تسليط الضوء على النص المصدر الدقيق في واجهة المستخدم.
التحقق من دقة الاستخراج مقابل المصدر.
=======
#### مصدر المعلومات التفصيلية (طموح)

للحصول على معلومات تفصيلية حول المصدر، سيكون من المفيد تسجيل المكان الدقيق داخل جزء معين حيث تم استخراج الثلاثيات منه. هذا يسمح بـ:

تسليط الضوء على النص المصدر الدقيق في واجهة المستخدم.
التحقق من دقة الاستخراج مقارنة بالمصدر.
>>>>>>> 82edf2d (New md files from RunPod)
تصحيح جودة الاستخراج على مستوى الجملة.

**مثال مع تتبع الموضع:**
```
# The extracted triple
entity:JohnSmith rel:worksAt entity:AcmeCorp .

# Subgraph with sub-chunk provenance
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 tg:sourceText "John Smith has worked at Acme Corp since 2019" .
subgraph:001 tg:sourceCharOffset 1547 .
subgraph:001 tg:sourceCharLength 46 .
```

**مثال مع نطاق نص (بديل):**
```
subgraph:001 tg:contains <<entity:JohnSmith rel:worksAt entity:AcmeCorp>> .
subgraph:001 prov:wasDerivedFrom chunk:123-1-1 .
subgraph:001 tg:sourceRange "1547-1593" .
subgraph:001 tg:sourceText "John Smith has worked at Acme Corp since 2019" .
```

**اعتبارات التنفيذ:**

<<<<<<< HEAD
قد لا توفر استخراج البيانات باستخدام نماذج اللغة الكبيرة (LLM) بشكل طبيعي مواقع الأحرف.
يمكن توجيه نموذج اللغة الكبيرة لإرجاع الجملة/العبارة المصدرية بالإضافة إلى الثلاثيات المستخرجة.
بدلاً من ذلك، يمكن إجراء معالجة لاحقة لمطابقة الكيانات المستخرجة بشكل تقريبي مع النص المصدر.
يوجد مقايضة بين تعقيد الاستخراج ودقة تتبع المصدر.
قد يكون من الأسهل تحقيق ذلك باستخدام طرق الاستخراج المنظمة بدلاً من استخراج البيانات المجردة باستخدام نماذج اللغة الكبيرة.
=======
قد لا توفر عملية الاستخراج القائمة على نماذج اللغة الكبيرة (LLM) بشكل طبيعي مواقع الأحرف.
يمكن توجيه نموذج اللغة الكبيرة لإرجاع الجملة/العبارة المصدرية بالإضافة إلى الثلاثيات المستخرجة.
بدلاً من ذلك، يمكن إجراء معالجة لاحقة لمطابقة الكيانات المستخرجة بشكل تقريبي مع النص الأصلي.
يوجد مقايضة بين تعقيد الاستخراج ودقة تتبع المصدر.
قد يكون من الأسهل تحقيق ذلك باستخدام طرق الاستخراج المنظمة بدلاً من استخراج نماذج اللغة الكبيرة غير المنظمة.
>>>>>>> 82edf2d (New md files from RunPod)

هذا الأمر مصنف على أنه طموح - يجب تنفيذ تتبع المصدر على مستوى المقطع أولاً، مع تتبع المقطع الفرعي كتحسين مستقبلي إذا كان ذلك ممكنًا.

### نموذج التخزين المزدوج

<<<<<<< HEAD
يتم بناء رسم بياني لتتبع المصدر بشكل تدريجي أثناء تدفق المستندات عبر مسار العمل:
=======
يتم بناء رسم بياني (DAG) لتتبع المصدر تدريجيًا أثناء تدفق المستندات عبر مسار العمل:
>>>>>>> 82edf2d (New md files from RunPod)

| التخزين | ما يتم تخزينه | الغرض |
|-------|---------------|---------|
| أمين المكتبة | محتوى المستند + روابط الأبناء | استرجاع المحتوى، حذف متسلسل |
<<<<<<< HEAD
| الرسم البياني للمعرفة | حواف الأبناء، وبيانات وصفية | استعلامات تتبع المصدر، إسناد الحقائق |

تحتفظ كلا التخزينين بنفس هيكل الرسم البياني. يحتوي أمين المكتبة على المحتوى، بينما يحتوي الرسم البياني على العلاقات ويمكنه تمكين استعلامات التصفح.

### المبادئ الأساسية للتصميم

1. **معرف المستند كوحدة تدفق** - تمرر المعالجات المعرفات، وليس المحتوى. يتم استرداد المحتوى من أمين المكتبة عند الحاجة.

2. **الإرسال مرة واحدة من المصدر** - يتم كتابة البيانات الوصفية في الرسم البياني مرة واحدة عند بدء المعالجة، وليس بشكل متكرر في المراحل اللاحقة.

3. **نمط معالج متسق** - يتبع كل معالج نفس النمط: الاستقبال/الاسترداد/الإنتاج/الحفظ/الإرسال/التوجيه.

4. **بناء تدريجي للرسم البياني** - يضيف كل معالج مستواه إلى الرسم البياني. يتم بناء سلسلة تتبع المصدر الكاملة بشكل تدريجي.

5. **تحسين ما بعد التقطيع** - بعد التقطيع، تحمل الرسائل كلاً من المعرف والمحتوى. تكون القطع صغيرة (2-4 كيلوبايت)، لذلك يؤدي تضمين المحتوى إلى تجنب عمليات الذهاب والإياب غير الضرورية إلى أمين المكتبة مع الحفاظ على تتبع المصدر عبر المعرف.
=======
| الرسم البياني المعرفي | حواف الأبناء، بالإضافة إلى البيانات الوصفية | استعلامات تتبع المصدر، إسناد الحقائق |

تحتفظ كلتا الحالتين بنفس هيكل الرسم البياني. تحتفظ أمين المكتبة بالمحتوى، بينما يحتفظ الرسم البياني بالعلاقات ويمكنه تمكين استعلامات التصفح.

### المبادئ الأساسية للتصميم

1. **معرف المستند كوحدة تدفق** - تمرر المعالجات المعرفات، وليس المحتوى. يتم جلب المحتوى من أمين المكتبة عند الحاجة.

2. **الإرسال مرة واحدة من المصدر** - يتم كتابة البيانات الوصفية في الرسم البياني مرة واحدة عند بدء المعالجة، وليس بشكل متكرر في المراحل اللاحقة.

3. **نمط معالج متسق** - يتبع كل معالج نفس النمط: الاستقبال/الجلب/الإنتاج/الحفظ/الإرسال/التوجيه.

4. **بناء تدريجي للرسم البياني** - يضيف كل معالج مستواه إلى الرسم البياني. يتم بناء سلسلة تتبع المصدر الكاملة بشكل تدريجي.

5. **تحسين ما بعد التقسيم إلى أجزاء** - بعد التقسيم إلى أجزاء، تحمل الرسائل كلاً من المعرف والمحتوى. الأجزاء صغيرة (2-4 كيلوبايت)، لذا فإن تضمين المحتوى يتجنب عمليات الذهاب والإياب غير الضرورية إلى أمين المكتبة مع الحفاظ على تتبع المصدر عبر المعرف.
>>>>>>> 82edf2d (New md files from RunPod)

## مهام التنفيذ

### تغييرات أمين المكتبة

#### الحالة الحالية

يبدأ معالجة المستند عن طريق إرسال معرف المستند إلى المعالج الأول.
لا يوجد اتصال بمخزن الثلاثيات - يتم تجميع البيانات الوصفية مع مخرجات الاستخراج.
`add-child-document` ينشئ روابط الأبناء من مستوى واحد.
`list-children` يُرجع فقط الأبناء المباشرين.

#### التغييرات المطلوبة

**1. واجهة جديدة: اتصال بمخزن الثلاثيات**

<<<<<<< HEAD
يحتاج أمين المكتبة إلى إرسال حواف بيانات وصفية للمستند مباشرة إلى الرسم البياني للمعرفة عند بدء المعالجة.
=======
تحتاج أمين المكتبة إلى إرسال حواف بيانات وصفية لمستندات الأبناء مباشرة إلى الرسم البياني المعرفي عند بدء المعالجة.
>>>>>>> 82edf2d (New md files from RunPod)
إضافة عميل/ناشر مخزن الثلاثيات إلى خدمة أمين المكتبة.
عند بدء المعالجة: إرسال بيانات وصفية للمستند الجذر كحواف في الرسم البياني (مرة واحدة).

**2. مفردات أنواع المستندات**

<<<<<<< HEAD
توحيد قيم `document_type` لأبناء المستند:
=======
توحيد قيم `document_type` لمستندات الأبناء:
>>>>>>> 82edf2d (New md files from RunPod)
`source` - المستند الذي تم تحميله أصلاً.
`page` - صفحة مستخرجة من المصدر (PDF، إلخ).
`chunk` - جزء نصي مشتق من الصفحة أو المصدر.

#### ملخص تغييرات الواجهة

| الواجهة | التغيير |
|-----------|--------|
<<<<<<< HEAD
| مخزن الثلاثيات | اتصال صادر جديد - إرسال حواف بيانات وصفية للمستند |
=======
| مخزن الثلاثيات | اتصال صادر جديد - إرسال حواف بيانات وصفية لمستندات الأبناء |
>>>>>>> 82edf2d (New md files from RunPod)
| بدء المعالجة | إرسال البيانات الوصفية إلى الرسم البياني قبل توجيه معرف المستند |

### تغييرات مستخرج PDF

#### الحالة الحالية

<<<<<<< HEAD
يتلقى محتوى المستند (أو يتدفق المستندات الكبيرة).
يستخرج النص من صفحات PDF.
يوجه محتوى الصفحة إلى وحدة التقطيع.
=======
يتلقى محتوى المستند (أو يقوم بتدفق المستندات الكبيرة).
يستخرج النص من صفحات PDF.
يوجه محتوى الصفحة إلى وحدة تقسيم إلى أجزاء.
>>>>>>> 82edf2d (New md files from RunPod)
لا يوجد تفاعل مع أمين المكتبة أو مخزن الثلاثيات.

#### التغييرات المطلوبة

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

يحتاج مستخرج PDF إلى حفظ كل صفحة كمستند تابع في أمين المكتبة.
إضافة عميل أمين المكتبة إلى خدمة مستخرج PDF.
لكل صفحة: استدعاء `add-child-document` مع parent = معرف المستند الجذر.

**2. واجهة جديدة: اتصال بمخزن الثلاثيات**

<<<<<<< HEAD
يحتاج مستخرج PDF إلى إرسال حواف الأبناء إلى الرسم البياني للمعرفة.
=======
يحتاج مستخرج PDF إلى إرسال حواف الأبناء إلى الرسم البياني المعرفي.
>>>>>>> 82edf2d (New md files from RunPod)
إضافة عميل/ناشر مخزن الثلاثيات.
لكل صفحة: إرسال حافة تربط مستند الصفحة بالمستند الأصل.

**3. تغيير تنسيق الإخراج**

بدلًا من إرسال محتوى الصفحة مباشرةً، أرسل مُعرّف مستند الصفحة.
<<<<<<< HEAD
سيقوم المقطع (Chunker) بجلب المحتوى من أمين المكتبة (librarian) باستخدام المعرّف.
=======
سيقوم المقطع (Chunker) بجلب المحتوى من المكتبة (librarian) باستخدام المعرّف.
>>>>>>> 82edf2d (New md files from RunPod)

#### ملخص التغييرات في الواجهة

| الواجهة | التغيير |
|-----------|--------|
<<<<<<< HEAD
| أمين المكتبة (Librarian) | واجهة تصدير جديدة - حفظ المستندات الفرعية |
| قاعدة البيانات الثلاثية (Triple store) | واجهة تصدير جديدة - إرسال علاقات الأبناء والبنات |
=======
| المكتبة (librarian) | إخراج جديد - حفظ المستندات الفرعية |
| المستودع الثلاثي (Triple store) | إخراج جديد - إرسال علاقات الأبناء |
>>>>>>> 82edf2d (New md files from RunPod)
| رسالة الإخراج | تغيير من المحتوى إلى مُعرّف المستند |

### تغييرات المقطع (Chunker)

#### الحالة الحالية

<<<<<<< HEAD
يستقبل محتوى الصفحة/النص
يقسم إلى أجزاء (chunks)
يرسل محتوى الجزء إلى المعالجات اللاحقة
لا يوجد تفاعل مع أمين المكتبة أو قاعدة البيانات الثلاثية
=======
يتلقى محتوى الصفحة/النص
يقسم إلى أجزاء
يرسل محتوى الجزء إلى المعالجات اللاحقة
لا يوجد تفاعل مع المكتبة أو المستودع الثلاثي
>>>>>>> 82edf2d (New md files from RunPod)

#### التغييرات المطلوبة

**1. تغيير طريقة معالجة الإدخال**

<<<<<<< HEAD
استقبل مُعرّف المستند بدلًا من المحتوى، وجلبه من أمين المكتبة.
أضف عميل أمين المكتبة إلى خدمة المقطع.
جلب محتوى الصفحة باستخدام مُعرّف المستند.

**2. واجهة جديدة: عميل أمين المكتبة (للكتابة)**

احفظ كل جزء كمستند فرعي في أمين المكتبة.
لكل جزء: استدعِ `add-child-document` مع `parent = page document ID`

**3. واجهة جديدة: اتصال بقاعدة البيانات الثلاثية**

أرسل علاقات الأبناء والبنات إلى الرسم البياني المعرفي.
أضف عميل/ناشر قاعدة البيانات الثلاثية.
=======
استقبل مُعرّف المستند بدلاً من المحتوى، وجلبه من المكتبة.
أضف عميل المكتبة إلى خدمة المقطع.
جلب محتوى الصفحة باستخدام مُعرّف المستند.

**2. واجهة جديدة: عميل المكتبة (للكتابة)**

احفظ كل جزء كمستند فرعي في المكتبة.
لكل جزء: اتصل بـ `add-child-document` مع `parent = مُعرّف مستند الصفحة`

**3. واجهة جديدة: اتصال بالمستودع الثلاثي**

أرسل علاقات الأبناء إلى الرسم البياني المعرفي.
أضف عميل/ناشر المستودع الثلاثي.
>>>>>>> 82edf2d (New md files from RunPod)
لكل جزء: أرسل علاقة تربط مستند الجزء بمستند الصفحة.

**4. تغيير تنسيق الإخراج**

<<<<<<< HEAD
أرسل كلاً من مُعرّف مستند الجزء ومحتوى الجزء (تحسين لاحق للمقطع).
تستقبل المعالجات اللاحقة المعرّف لأغراض التتبع + المحتوى للعمل به.
=======
أرسل كلاً من مُعرّف مستند الجزء ومحتوى الجزء (تحسين بعد تقسيم الجزء).
تتلقى المعالجات اللاحقة المعرّف لتتبع المصدر + المحتوى للعمل به.
>>>>>>> 82edf2d (New md files from RunPod)

#### ملخص التغييرات في الواجهة

| الواجهة | التغيير |
|-----------|--------|
| رسالة الإدخال | تغيير من المحتوى إلى مُعرّف المستند |
<<<<<<< HEAD
| أمين المكتبة (Librarian) | واجهة تصدير جديدة (قراءة وكتابة) - جلب المحتوى، حفظ المستندات الفرعية |
| قاعدة البيانات الثلاثية (Triple store) | واجهة تصدير جديدة - إرسال علاقات الأبناء والبنات |
=======
| المكتبة (librarian) | إخراج جديد (قراءة وكتابة) - جلب المحتوى، حفظ المستندات الفرعية |
| المستودع الثلاثي (Triple store) | إخراج جديد - إرسال علاقات الأبناء |
>>>>>>> 82edf2d (New md files from RunPod)
| رسالة الإخراج | تغيير من المحتوى فقط إلى المعرّف + المحتوى |

### تغييرات مُستخرج المعرفة (Knowledge Extractor)

#### الحالة الحالية

<<<<<<< HEAD
يستقبل محتوى الجزء
يستخرج الثلاثيات والتضمينات
يرسل إلى قاعدة البيانات الثلاثية ومخزن التضمينات
`subjectOf` تشير العلاقة إلى المستند ذي المستوى الأعلى (وليس الجزء)
=======
يتلقى محتوى الجزء
يستخرج الثلاثيات والتضمينات
يرسل إلى المستودع الثلاثي ومستودع التضمينات
تشير علاقة `subjectOf` إلى المستند ذي المستوى الأعلى (وليس الجزء).
>>>>>>> 82edf2d (New md files from RunPod)

#### التغييرات المطلوبة

**1. تغيير طريقة معالجة الإدخال**

استقبل مُعرّف مستند الجزء بالإضافة إلى المحتوى.
<<<<<<< HEAD
استخدم مُعرّف الجزء لأغراض الربط (المحتوى مدرج بالفعل كتحسين).

**2. تحديث أثر الثلاثيات**

اربط الثلاثيات المستخرجة بالجزء (وليس المستند ذي المستوى الأعلى).
استخدم التجريد لإنشاء حافة تشير إلى الحافة
`subjectOf` العلاقة: ثلاثية → مُعرّف مستند الجزء
الاستخدام الأول للدعم الحالي للتجريد

**3. تحديث أثر التضمينات**

اربط معرفات كيانات التضمين بالجزء.
أرسل حافة: معرف كيان التضمين → مُعرّف مستند الجزء
=======
استخدم مُعرّف الجزء لتتبع المصدر (تم تضمين المحتوى بالفعل كجزء من التحسين).

**2. تحديث تتبع المصدر**

اربط الثلاثيات المستخرجة بالجزء (وليس المستند ذي المستوى الأعلى).
استخدم التجريد لإنشاء حافة تشير إلى الحافة.
علاقة `subjectOf`: الثلاثية → مُعرّف مستند الجزء
الاستخدام الأول للدعم الحالي للتجريد.

**3. تحديث تتبع التضمينات**

اربط معرفات كيانات التضمين بالجزء.
أرسل حافة: معرف كيان التضمين → مُعرّف مستند الجزء.
>>>>>>> 82edf2d (New md files from RunPod)

#### ملخص التغييرات في الواجهة

| الواجهة | التغيير |
|-----------|--------|
| رسالة الإدخال | توقع مُعرّف الجزء + المحتوى (وليس المحتوى فقط) |
<<<<<<< HEAD
| قاعدة البيانات الثلاثية | استخدم التجريد لأثر الثلاثية → الجزء |
| أثر التضمين | اربط معرف الكيان → معرف الجزء |

## المراجع

أثر وقت الاستعلام: `docs/tech-specs/query-time-provenance.md`
معيار PROV-O لنمذجة الأثر
البيانات الوصفية المصدر الحالية في الرسم البياني المعرفي (تحتاج إلى تدقيق)
=======
| المستودع الثلاثي (Triple store) | استخدم التجريد لتتبع الثلاثية → الجزء |
| تتبع التضمينات | اربط معرف الكيان → معرف الجزء |

## المراجع

تتبع وقت الاستعلام: `docs/tech-specs/query-time-provenance.md`
معيار PROV-O لنمذجة التتبع.
البيانات الوصفية المصدر الحالية في الرسم البياني المعرفي (تحتاج إلى تدقيق).
>>>>>>> 82edf2d (New md files from RunPod)