تقنية

رمز خدمة عامة: هل يحدد الطلب الفردي أم نوع المشكلة؟

رسم توضيحي: نوع خدمة مؤلف: ز 7؛ طلب فردي: ط 41؛ طلب فردي: ط 42؛ تعريف النوع يحدد السمات
مخطط من إعداد بحر العلوم. رمز النوع مشترك؛ هويتا الطلبين مختلفتان

رمز نوع الخدمة ومعرف الطلب الفردي يؤديان وظيفتين مختلفتين في GeoReport v2 من Open311. قد يقترح المساعد وضع رمز نوع المشكلة في خانة متابعة طلب معين. نقرأ تعريف الحقول، ثم نقارن بطاقتي طلب مؤلفتين من النوع نفسه دون التواصل مع جهة أو إنشاء بلاغ.

الخلاصة السريعة

اربط رمز النوع بتعريف الخدمة ومعرف الحالة بالطلب المحدد؛ تكرار النوع بين طلبين لا يدمجهما، ولا يكمل الرمز وحده الحقول المطلوبة.

  • تستخدم المواصفة service_code لنوع الخدمة، وservice_request_id للطلب الفردي المنشأ. [1] لا تحول رمز الفئة إلى رقم حالة، ولا تعمم رموز جهة على كل مدينة.
  • في مثالنا النوع ز 7 لتلف لوحة عامة، والطلبان ط 41 وط 42 له؛ تطابق ز 7 لا يجعل الطلبين واحدا أو يثبت أن لهما الموقع نفسه.
  • عندما تعلن الخدمة metadata=true تحتاج قراءة تعريفها؛ required=true يعني وجوب القيمة عند الإرسال، وقد تختلف السمات بالجهة. [1] لا يملأ المساعد حقلا مفقودا بتخمين.
  • احفظ الجهة والرمز وتعريفه ومعرف الطلب عند توفره؛ لا نخترع معرفا لطلب غير مرسل، ولا يثبت اكتمال المسودة قبولها أو تنفيذ إصلاح أو صحة جميع رموز مدينة.

ماذا يسمي كل معرف في المواصفة؟

تعرض GeoReport v2 رمز service_code لتحديد نوع الخدمة، ومعرف service_request_id للطلب الفردي المنشأ. [1]

الفرق عملي عند كتابة شاشة متابعة: اسم النوع يشرح موضوع الطلب، لكنه لا يختار تلقائيا الحالة التي يريد صاحبها متابعتها. نقترح أن يعرض المساعد دور كل قيمة بجانبها بدلا من تسمية كل الرموز «رقم الطلب».

كما نثبت الجهة التي جاءت منها القائمة. لم تقدم المواصفة رموزا عالمية لكل مشكلة في كل مدينة؛ فلا نختار رقما من مثالها ونقدمه بوصفه رمز جهة محلية لم نقرأ قائمة خدماتها.

هل نوع واحد يعني حالة واحدة؟

نخترع خدمة تعليمية رمزها ز 7 لتلف لوحة عامة. نعطي طلبين مفترضين معرفي ط 41 وط 42، ونعلن أن كليهما من ز 7. هذه رموز تدريب عربية وليست تنسيق استجابة حقيقية من خادم Open311.

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

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

أي تعريف تحتاجه قبل استكمال المسودة؟

تطلب المواصفة تعريف الخدمة إذا كان metadata=true؛ وتحدد required=true أن قيمة السمة لازمة للإرسال، وتذكر أن السمات قد تخص الجهة. [1]

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

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

كيف نفصل المسودة من سجل طلب منشأ؟

نقترح ورقة تربط الجهة ونسخة تعريف الخدمة ورمزها والإجابات المعروفة والأسئلة المفتوحة. يبقى معرف الحالة غير متاح ما دام لم يقدم سجل لطلب منشأ؛ لا يصنع المساعد ط 43 كي تبدو ورقة جديدة مكتملة.

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

المصادر ومتابعة القراءة

  1. Open311: GeoReport v2 (يفتح في نافذة جديدة)wiki.open311.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.