الخلاصة

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

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

في 30 نوفمبر 1993، أعلن Martijn Koster عن ALIWEB بوصفها تجربة لفهرسة الويب «الموزعة». يعلن كل خادم عن محتواه في ملف محلي، ويسترجع موقع واحد هذه الملفات ويعالجها، ثم يمكن البحث في قاعدة البيانات الموحّدة عبر الويب. ووفق ورقة المؤتمر التي نشرها Koster لاحقاً، كانت الخدمة التجريبية تعمل على خادم NEXOR منذ أكتوبر. وفي إعلانه في 30 نوفمبر، وصفها Koster بأنها خطوة أولى لا حلاً نهائياً، وأضاف وعداً لافتاً: ينبغي أن يسهل استخدام البيانات أو تحويلها حين تظهر آليات أفضل.

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

كان الإدخال ملفاً نصياً معداً مسبقاً، كثيراً ما سمي /site.idx، ويستخدم قوالب Internet Anonymous FTP Archives (IAFA). تسجل هذه القوالب السمات والقيم، ويمكن لملف واحد أن يصف عدة موارد؛ مثل نوع القالب والعنوان وURI والوصف والكلمات المفتاحية. لم تحاول ALIWEB استنتاج معنى كل صفحة من وسومها. بدلاً من ذلك، أتاحت لمن يعرف بنية الموقع اختيار نقاط الدخول المهمة مع الإبقاء على تنظيمه الداخلي. ويصف المثال الذي أورده Koster مواد Perl في NEXOR ودليلها، لا كل ملف على الخادم.

ومع ذلك، تطلبت المشاركة اتفاقاً تشغيلياً صغيراً. يسجل المدير اسم الخادم والمنفذ ومسار ملف الفهرس عبر نموذج على الويب، ويقدم جهة اتصال مسؤولة، ويمكنه تحديد الحد الأدنى للفترة بين عمليتي استرجاع. تتحقق ALIWEB من وجود الملف وصحة صيغته قبل قبول التسجيل. ثم تتولى عملية Perl مستقلة فحص الفهارس المسجلة واسترجاع النسخ التي تغيرت وإعادة بناء قاعدة البيانات باستخدام cron في UNIX. وكان ممكناً البحث في القاعدة عبر نموذج ALIWEB أو من خلال دليل آخر، ومنها CUI W3 Catalog.

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

تعرض الأرقام التي نشرها Koster الاستخدام والحدود معاً. عند إعداد الورقة، كان هناك 54 مضيفاً مسجلاً و310 سجلات في قاعدة البيانات. استقبل نموذج البحث البسيط في ALIWEB نحو 80 استعلاماً يومياً في المتوسط، بينما استخدم CUI W3 Catalog القاعدة لأكثر من 8,000 استعلام أسبوعياً. تثبت هذه الأرقام وجود خدمة عاملة وتكامل واحد مفيد. لكنها لا تقيس نسبة الويب المفهرسة، ولا جودة النتائج، ولا عدد الخوادم التي استطاعت أو رغبت في صيانة ملف صالح.

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

ولم تكن كلمة «يدوي» تعني بالضرورة أن يكتب شخص كل سطر إلى الأبد. رأى Koster أن البرنامج يستطيع إنشاء الملف، بشرط الاحتفاظ ببيانات وصفية كافية للبحث والاختيار. وفي 1995، وثق مشروع أرشيف آخر استخدام قوالب IAFA التي تتحدث مع تغيرات نظام الملفات وتنتج فهارس نصية وGopher وHTML. توضح ورقة مؤتمر WWW التابعة لـW3C أن الفكرة أمكن استخدامها لإنتاج واجهات مختلفة؛ لكنها لا تثبت أن مجموعة ALIWEB انتقلت إلى نظام آخر أو أن الخدمة انتشرت على نطاق واسع.

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

وصفت مراجعة عام 1994 لاسترجاع المعلومات عبر الشبكات هذا المجال بأنه لا يزال ناشئاً، وأن التحكم في التصنيف وميزات أخرى لم تكن واسعة الانتشار. تعايشت ALIWEB مع القوائم اليدوية وCUI W3 Catalog وأساليب الروبوتات، مثل JumpStation وقاعدة عناوين RBSE؛ لذلك لم تكن أول أداة بحث على الويب. وكانت مساهمتها الأضيق هي إظهار إمكان جمع أوصاف يختارها مزودو الموارد تلقائياً وإعادة استخدامها في أنظمة أخرى.

توفر ملاحظة Heng Lu رقم 65 عن أولوية الشيفرة العاملة زاوية تحليلية لاحقة، لا دليلاً على أفكار Koster: يمكن للصيغة أن تعد بقابلية النقل، لكن الأنظمة التي تعتمدها وتشغلها هي التي تجعل ذلك واقعاً. توثق الورقة تشغيل ALIWEB واستخدام W3 Catalog لقاعدتها، لكنها لا توثق اعتماداً عاماً ولا سلطة ملزمة على ناشري الويب ولا انتقالاً مكتملاً للبيانات. والتمييز التاريخي المفيد يتكون من ثلاثة أجزاء: يقرر المزود ما يقوله موقعه؛ وتقرر ALIWEB ما يدخل الفهرس المشترك؛ وتستطيع الأنظمة اللاحقة إعادة استخدام الملف من دون أن ترث الخدمة المركزية للتجربة.