السلام عليكم ورحمة الله وبركاته.
في النقاش ده https://community.itqan.dev/d/399 كان اتكلم بشمهندس @هادي الأحمد عن موضوع توحيد الـ Quran APIs والـ schemas المختلفة، وبعدها بشمهندس @abdullah mohammed كان يبحث فى موضوع توحيد البينات كاملًا وكان اتكلم عن QUSX فى النقاش الأخير له ده https://community.itqan.dev/d/632
وده نقاش وافى وكافى عشان تعرف الموضوع وصل إلى أين حاليا.
طبعا أنا أول ما دخلت ما فهمتش أي حاجة تقريبا 😅 والموضوع كان معقد زيادة عن اللزوم بالنسبة لي، لكن بدأت أقرأ وأبحث واحدة واحدة، والدنيا بدأت تبان شوية معايا.
واكتشفت إن الموضوع أعمق بكتير من مجرد توحيد أسماء fields أو schemas بتاعة APIs.
إحنا هنا بنتكلم عن الأصل نفسه:
إزاي نمثل البيانات القرآنية بطريقة موحدة، بحيث إن الـ APIs والمكتبات والتطبيقات المختلفة تقدر كلها تبني فوق نفس الـ standard.
وعندي هنا كام نقطة حابب أناقشهم معاكم، وممكن أكون صح وممكن أكون فاهم حاجة غلط، فخبرات الناس اللي أقدم مني في الموضوع أكيد هتفيد جدا، وجزاهم الله خيرا.
أولا: QUSX بيحل المشكلة إزاي حاليا؟
QUSX بالفعل بينزل لمستوى الـ word، وكل كلمة بيكون ليها ID، وبعد كده حاجات زي الآيات والصفحات والسطور بتتعامل كـ milestones فوق تسلسل الكلمات.
وده في رأيي تصميم جميل جدا.
وهو مبنى على USX (Unified Scripture XML)
يعني بدل ما الصفحة أو السطر أو الآية يكونوا هم الـ container الأساسي للنص، عندك text stream، وبعدها كل layer تقول:
أنا أبدأ من هنا.
وأنتهي هنا.
فالصفحة ممكن تبدأ عند كلمة معينة وتنتهي عند كلمة معينة.
والسطر نفس الكلام.
والآية نفس الكلام.
وده يسمح إنك تغير الـ layout أو طبعة المصحف بدون ما تكرر النص نفسه.
لكن وأنا بقرأ في موضوع الروايات، حسيت إن عندنا مشكلتين مختلفتين لازم نفصل بينهم.
المشكلة الأولى: اختلاف عد الآيات وحدودها
ممكن نفس الموضع في النص يكون نهاية آية في رواية أو عد معين، ومش نهاية آية في عد أو رواية أخرى.
وفي أنظمة USX موجود مفهوم اسمه Versification Mapping، والهدف منه إنه يعمل mapping بين أنظمة مختلفة في ترقيم وتقسيم الـ verses.
يعني لو عندك verse في نظام معين، تقدر تعرف هو يقابل إيه في نظام آخر.
لكن بما إن QUSX عنده أصلا word IDs وميلستونز، فإحنا ممكن نهندل الموضوع بشكل مباشر جدا.
الآية نفسها يكون عندها metadata تقول:
في حفص، الآية دي تبدأ عند word/slot كذا وتنتهي عند كذا.
وفي ورش مثلا تبدأ عند كذا وتنتهي عند كذا.
فلو الآية تبدأ من الموضع 120 وتنتهي عند 125، أنا مش محتاج أخزن جوه كل كلمة:
دي أول كلمة في الآية.
دي الكلمة التانية.
دي آخر كلمة.
أنا أقدر أستنتج ده من الـ start والـ end نفسهم.
يعني الـ ayah layer كل مسؤوليتها تكون:
الآية رقم كام؟
تابعة لأنهي رواية/عد؟
تبدأ فين؟
وتنتهي فين؟
وبكده فصلنا عد الآيات وحدودها عن الكلمات نفسها.
المشكلة التانية: اختلاف الكلمات نفسها بين الروايات
وهنا الموضوع بقى أصعب شوية.
لأن الاختلاف مش دائما مجرد حركة أو شكل مختلف لنفس الكلمة.
ممكن كلمة تكون موجودة في رواية ومش موجودة في رواية أخرى.
والمثال اللي اتذكر في النقاش السابق من سورة الحديد:
في حفص عن عاصم:
«فَإِنَّ اللَّهَ هُوَ الْغَنِيُّ الْحَمِيدُ»
وفي ورش:
«فَإِنَّ اللَّهَ الْغَنِيُّ الْحَمِيدُ»
يعني كلمة «هو» موجودة في حفص، وغير موجودة في ورش.
وده بيخلينا نسأل:
إحنا نعمل alignment للكلمات دي إزاي؟
لو كل اللي عندي canonical word IDs مبنية على حفص، يبقى الموضوع في الحالة دي سهل نسبيا.
عندي مثلا:
110 → فإن
111 → الله
112 → هو
113 → الغني
114 → الحميد
وفي ورش أقول إن الكلمة 112 غير موجودة، وبالتالي لما أرجع النص أعمل لها skip.
تمام.
لكن المشكلة تظهر في الاتجاه التاني.
لو عندي رواية فيها كلمة إضافية في موضع ما، ومفيش لها canonical word ID أصلا في الـ base sequence، هحطها فين؟
هل أقول مثلا:
122
122A
123 ؟
ممكن.
لكن هنا الـ ID نفسه بدأ يحمل معنى الترتيب.
ولو بعد كده احتجنا كلمة تانية بين 122 و122A؟
هل هنعمل:
122A1؟
ولا 122B؟
والمشكله الأكبر لو المرجع مفهوش الكلمه والروايه هلى الى موجود فيها الكلمه.
الموضوع ممكن يبدأ يتعقد.
ومن هنا جت فكرة الـ slot.
إيه هي فكرة الـ slot؟
الفكرة ببساطة إن بدل ما الـ canonical sequence نفسها تكون عبارة عن words فقط، يبقى عندي layer فوق الكلمات اسمها مؤقتا:
slot
أو أي اسم أدق يتم الاتفاق عليه بعد كده.
إحنا نبدأ من حفص عن عاصم باعتباره الـ base/reference اللي بنبني عليه، ونمشي على تسلسل الكلمات كله.
كل كلمة طبعا يفضل ليها canonical word ID الخاص بها.
لكن فوق الكلمات نعمل sequence من الـ slots.
فالـ slot مش هي الكلمة نفسها.
الـ slot هي موضع alignment.
مثلا في المثال السابق:
حفص:
فإن الله هو الغني الحميد
ورش:
فإن الله الغني الحميد
ممكن يكون عندي:
Slot 110 → فإن
Slot 111 → الله
Slot 112 →
حفص: هو
ورش: لا شيء
Slot 113 → الغني
Slot 114 → الحميد
بالتالي لما أطلب حفص:
110 → فإن
111 → الله
112 → هو
113 → الغني
114 → الحميد
ولما أطلب ورش:
110 → فإن
111 → الله
112 → skip
113 → الغني
114 → الحميد
والـ ayah نفسها مالهاش أي علاقة بالتفصيلة دي.
هي كل اللي تعرفه مثلا:
start_slot = 110
end_slot = 114
وبعدها الـ slots نفسها هي اللي تحدد إيه الكلمات اللي ترجع بناء على الرواية المطلوبة.
طيب لو عندنا كلمة زيادة؟
نفس الفكرة.
بدل ما أضطر أغير canonical IDs للكلمات كلها اللي بعدها أو أخترع ID غريب في النص، أقدر أخلي alignment layer نفسها تستوعب الاختلاف.
والـ slot ممكن بالنسبة لرواية معينة يرجع:
ولا كلمة.
أو كلمة واحدة.
ولو احتجنا في بعض الحالات:
أكثر من كلمة.
يعني إحنا هنا فصلنا 3 حاجات عن بعض:
الآية:
تقول أنا أبدأ فين وأنتهي فين.
الـ slot:
يقول في الموضع ده الرواية المطلوبة فيها إيه.
الـ word:
تفضل هي الوحدة النصية نفسها، وليها الـ canonical ID والـ metadata والمورفولوجي وغيرهم.
وده في رأيي بيمنع إننا نحط مسؤوليات كتير جدا على الـ word ID نفسها.
ليه أنا شايف الـ slot ممكن يكون مفيد؟
لأن لو اعتمدنا فقط على canonical word IDs، فإحنا غالبا هنحتاج نتعامل مع حالات:
word موجودة.
word غير موجودة.
word إضافية بين اتنين IDs موجودين.
وممكن بعد كده alignment أكثر تعقيدا.
لكن لو عندي slot sequence مستقلة، أنا بقى عندي coordinate system ثابت.
والكلمة نفسها مجرد reading أو content مرتبط بالموضع ده حسب الرواية.
يعني بدل ما السؤال يكون:
"الكلمة رقم كام؟"
السؤال الأساسي يبقى:
"إيه الموجود في الموضع ده في الرواية دي؟"
وده في رأيي أقرب للمشكلة اللي إحنا بنحاول نحلها.
طبعا أنا مش بقول إن ده implementation نهائي ولا حتى بقول إن الـ slot نفسها هي الحل الصح.
ده اقتراح محتاج يتراجع على كل edge cases الموجودة فعلا في الروايات.
خصوصا إن المجال نفسه كبير جدا، وممكن يكون فيه حالات أنا مش واخد بالي منها تماما تخلي الـ model ده محتاج تعديل أو حتى تخلي فيه حل أبسط منه.
وده السؤال الأساسي اللي حابب أناقشه:
هل إضافة alignment layer زي الـ slot فوق الـ canonical word IDs هتسهل فعلا دعم اختلاف الروايات داخل QUSX؟
ولا الـ word IDs الحالية مع tradition والـ milestones بالفعل كافية للتعامل مع الزيادة والنقصان، وإضافة slot جديدة هتبقى abstraction زيادة من غير احتياج؟
أنا بصراحة أميل للـ slot حاليا، خصوصا في مشكلة الكلمة الزائدة، لكن مش عندي العلم الكافي إني أقول إن ده هو الحل النهائي.
وفي الآخر أنا Front-end Developer أصلا 😅، فمش هعمل نفسي فجأة متخصص databases وdata structures وtextual standards.
لكن الموضوع شدني، وقلت بدل ما أفضل أفكر فيه لوحدي أشاركه، يمكن حد عنده خبرة أكبر يصحح الفكرة أو يطورها أو يقول لنا إن في حل أبسط موجود أصلا.
والله المستعان.
جزء منفصل شوية: Quran API Unified
وده جزء مختلف عن اقتراح QUSX نفسه، لكن مرتبط بنفس الاتجاه.
أنا كنت اتكلمت قبل كده عن package اسمها:
Quran API Unified
والفكرة بتاعتها كانت ببساطة إن عندنا APIs كثيرة جدا للقرآن، وكل API منهم بترجع schema مختلفة.
واحدة تسمي الحقل:
verse
واحدة:
ayah
واحدة ترجع الكلمات جوه object معين.
واحدة ترجعها في structure مختلفة تماما.
فالفكرة إن بدل ما كل مبرمج يضطر يكتب integration مختلف لكل API، الـ package تعمل adapters للـ APIs المختلفة وتطلع في الآخر schema واحدة موحدة.
وكان في الأول هدفي بس إني أوحد شكل الـ data والمصطلحات.
وبالنسبة للمصطلحات نفسها، كنت بفكر إننا نستخدم أسماء إنجليزية واضحة وثابتة بدل transliteration في أسماء الـ fields.
لأن حتى لو المصطلح العربي نفسه ثابت، الـ transliteration مش بالضرورة تكون ثابتة.
مثلا:
Ayah
Aya
Aayah
وهكذا.
وده في codebase أو specification ممكن يعمل اختلافات مالهاش لازمة.
فالأفضل في الـ programmatic keys إننا نختار terminology إنجليزية ثابتة ومتفق عليها، حتى لو الـ UI أو الـ documentation نفسها تستخدم المصطلحات العربية الأصلية.
لكن بعد ما بدأت أقرأ في QUSX جت لي فكرة تانية.
هل Quran API Unified ممكن تكون transition layer؟
دلوقتي عندنا الوضع الحالي:
APIs كثيرة.
schemas كثيرة.
مفيش standard واحد أغلب الـ applications ماشية عليه.
وفي الناحية التانية ممكن يبقى عندنا مستقبلا standard زي QUSX يتم تطويره واعتماده بشكل أوسع.
فإيه اللي يمنع إن Quran API Unified تكون مرحلة انتقالية بين الاتنين؟
يعني بدل ما المبرمج اللي عايز يستخدم standard موحد يضطر يحمل dataset أو SQLite أو يتعامل مع XML مباشرة أو يبني backend مخصوص:
هو يستخدم APIs الموجودة حاليا عادي.
والـ package هي اللي تاخد الـ responses المختلفة وتعمل لها normalization إلى schema واحدة قريبة أو متوافقة قدر الإمكان مع الـ QUSX model.
يعني مثلا هو يطلب:
Surah
Ayah
Words
Edition
Riwayah
Layout
أو أي fields يتم الاتفاق عليها في الـ schema.
وكل API provider يكون ليه adapter خاص به يحول الـ response بتاعه لنفس الشكل النهائي.
طبعا هنا إحنا مقيدين بالداتا اللي الـ API نفسها بتوفرها.
يعني لو API معينة ما بتدعمش ورش مثلا، إحنا مش هنخلق داتا ورش من العدم.
لكن على الأقل الـ interface نفسه يفضل ثابت.
والفكرة اللي شدتني هنا إن لو المبرمجين بدأوا يستخدموا نفس الـ schema من دلوقتي، وبعد كده APIs نفسها بدأت تتبنى QUSX أو standard موحد، فالـ migration بالنسبة للتطبيقات ممكن يبقى بسيط جدا.
يعني بدل:
Current APIs
↓
كل application عنده integration خاص
تبقى:
Current APIs
↓
Quran API Unified adapters
↓
Unified schema
↓
Applications
وبعدين في المستقبل:
QUSX-compatible API
↓
نفس الـ schema أو schema قريبة جدا
↓
Applications
فالمبرمج مش محتاج يغير كل الـ data layer بتاعته.
ممكن بس يغير الـ provider أو الـ adapter.
وبالتالي نوفر مرحلة انتقالية للمبرمجين وللمشاريع بدل ما يحصل breaking change كامل لو الـ ecosystem انتقل بعد كده لـ standard مختلف.
وده طبعا لو ربنا قدر والـ package نفسها اتبنت وانتشرت واتقبلت، يعني إحنا بنتكلم في احتمالات 😅
لكن حبيت أطرح الفكرة من بدري بدل ما أروح أبني package كاملة وبعدين أكتشف إن الـ direction نفسه كان محتاج يتغير.
فالسؤال هنا برضه:
هل Quran API Unified ممكن فعلا تكون compatibility/transition layer بين الـ Quran APIs الحالية وبين standard مستقبلي زي QUSX؟
ولا الأفضل إن المشروع يفضل بسيط جدا في scope بتاعه:
API normalization فقط،
ونفصل موضوع الـ standard عنه تماما؟
أنا مش عارف بصراحة هل أنا كده بجمع حاجات فعلا مرتبطة ببعض، ولا بدأت أسرح بالفكرة زيادة عن اللزوم 😅
لكن المرة اللي فاتت كنت ناوي أشتغل الأول وبعد كده أنشر.
وبعدين لما شاركت النقاش قبل التنفيذ لقيت إن الناس أضافت حاجات وغيرت طريقة تفكيري تماما.
فقلت المرة دي أعمل العكس:
أشارك الفكرة بدري.
ونشوف الناس اللي عندها خبرة أكبر شايفة إيه.
فالأسئلة اللي حابب أخد رأيكم فيها في الآخر:
هل الـ slot/alignment layer لها معنى فعلا لدعم اختلاف الروايات، خصوصا الزيادة والنقصان؟
ولا الـ QUSX model الحالي يقدر يهندل الحالات دي بالفعل بدون layer إضافية؟
وهل Quran API Unified ممكن تكون transition layer للـ standard، ولا الأفضل فصل المشروعين تماما؟
وجزاكم الله خيرا جميعا.
وشكر خاص للأستاذ عبد الله، والأستاذ هادي أحمد، ولكل شخص شارك في النقاشات السابقة وأضاف معلومة أو صحح فكرة.
وده رابط المشروع/النقاش اللي بنيت عليه الكلام ده:
https://community.itqan.dev/d/632/13
والله المستعان.
