بحث اتحادي

التنفيذ

من جانب آخر، وهناك تطبيق آخر وهو Sesam الذي يعمل في كل من النرويج والسويد، وقد تم بناؤه فوق منصة مفتوحة المصدر متخصصة في حلول البحث الموحد. وتُعتبر منصة Sesat، وهي اختصار لـ (Sesam Search Application Toolkit)، منصة توفر الكثير من البنية التحتية والوظائف اللازمة للتعامل مع عمليات البحث المتوازية والمتسلسلة وعرضها بشكل أنيق في واجهة المستعمل، مما يتيح للمهندسين التركيز على ضبط إعدادات الفهرس وقاعدة البيانات.

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

علاوةً على ذلك، ثمة تحدٍّ آخر يواجه تنفيذ محركات البحث الموحد وهو القابلية للتوسع (Scalability)؛ إذ من الصعب الحفاظ على الأداء وسرعة الاستجابة لمحرك البحث الموحد كلما دمج المزيد والمزيد من مصادر المعلومات معاً. ومن التطبيقات التي بدأت في معالجة هذه المشكلة نظام WorldWideScience، الذي يستضيفه مكتب المعلومات العلمية والتقنية التابع لـ وزارة الطاقة الأمريكية. ويتكون موقع WorldWideScience من أكثر من 40 مصدر معلومات، والعديد منها عبارة عن بوابات بحث موحد في حد ذاتها. ومن الأمثلة على هذه البوابات موقع Science.gov الذي يدمج بدوره أكثر من 30 مصدر معلومات تمثل أغلب مخرجات البحث والتطوير للحكومة الفيدرالية الأمريكية. يعيد موقع Science.gov النتائج الأعلى تصنيفاً لديه إلى WorldWideScience، والذي يقوم فيما بعد بدمج هذه النتائج وتصنيفها مع نتائج البحث المسترجعة من مصادر المعلومات الأخرى التي يتكون منها. يتيح هذا الأسلوب القائم على "البحث الموحد المتتالي" إمكانية البحث في عدد كبير من مصادر المعلومات عبر استعلام واحد.

في هذا الإطار، ويعد SWIRL Search محرك بحث موحد مفتوح المصدر، تم إصداره بموجب رخصة Apache 2.0. ويتضمن موصلات مبنية مسبقاً لمحركات البحث مفتوحة المصدر الشهيرة، ويعيد تصنيف النتائج باستخدام تشابه جيب التمام الموجه (Cosine vector similarity).

من جهة ثانية، يعد ضمان توافق استعلام البحث مع محركات البحث المكونة التي يتم دمجها والجمع بينها أحد التحديات الرئيسية للبحث التجميعي. عندما تختلف مفردات البحث أو نموذج البيانات الخاص بنظام البحث عن نموذج البيانات الخاص بواحد أو أكثر من الأنظمة المستهدفة الخارجية، يجب ترجمة الاستعلام ليتوافق مع كل نظام من هذه الأنظمة. ويمكن القيام بذلك باستخدام ترجمة بسيطة لعناصر البيانات، أو قد يتطلب الأمر ترجمة دلالية. مثلًا، إذا كان أحد محركات البحث يسمح باقتباس نصوص دقيقة أو تركيبات لغوية متعددة الكلمات بينما لا يسمح محرك آخر بذلك، فيجب ترجمة الاستعلام ليكون متوافقاً مع كل محرك بحث. ولترجمة استعلام يحتوي على نص دقيق مقتبس، يمكن تفكيكه إلى مجموعة من تراكيب الـ N-gram المتداخلة التي يُحتمل أن تعطي نتائج البحث المطلوبة في كل محرك بحث.

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

التحديات

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

2. مطابقة موجهات قائمة النتائج في نموذج مشترك

ومن جهة أخرى، يفرض البحث الموحد عدداً من التحديات الكبيرة مقارنة بالبحث التقليدي أحادي المصدر:

1. تمرير بيانات الاعتماد (الصلاحيات)

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

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

5. الإتاحة و انتهاء المهلة

7. الإتاحة العالية والتعافي من الكوارث (HA/DR)

علاوةً على ذلك، لكي يكون النظام الموحد العام متاحاً بشكل دائم وقادراً على التعافي من الكوارث (HA/DR)، قد يلزم أن يكون كل نظام فرعي مجهزاً بالقدرات نفسها.

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

• انظر كذلك
• مجمع البحث
• Z39.50
• مراجع

من جهة ثانية، 6. التطوير والاختبار داخل المؤسسة (مقارنة بشبكة الإنترنت العامة)

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

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

كذلك، وبالمثل، فإن نمذجة الأداء وتخطيط السعة للنظام الموحد يتطلب نمذجة وتخطيطاً، وأحياناً توسيعاً لجميع المصادر المشاركة.

3. فرز النتائج وتقييمها

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

الغرض

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

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

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

قراءات إضافية

كذلك، Federated Search Primer. Lederman, S., AltSearchEngines, January 2009. أعيد نشر هذه المادة هنا ، على مدونة شركة تجارية لمحركات البحث.

كذلك، Federated Search 101. Linoski, Alexis, Walczyk, Tine, Library Journal, Summer 2008 Net Connect, Vol. 133. تم نقل هذا المحتوى هنا ، ولكن ستحتاج إلى حساب وصول عن بعد عبر مكتبتك المحلية للحصول على المقال كاملاً.

وعلى صعيد آخر، Cox, Christopher N. Federated Search: Solution or Setback for Online Library Services. Binghamton, NY: Haworth Information Press, 2007. Table of Contents

العملية

إضافةً إلى ذلك، تقديمها في تنسيق موجز وموحد مع تقليل التكرار إلى حده الأدنى.

بحسب ما وصفه بيتر جاكسو، يتكون البحث الموحد من:

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

دمج النتائج التي تم جمعها من قواعد البيانات.

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

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

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

4. مرونة الاستعلام

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