في عام 2011، وجدت كلية تشارلستون (College of Charleston) نفسها عند مفترق طرق في إدارة الأصول الرقمية. فقد كانت مكتبة لوكانتري الرقمية (Lowcountry Digital Library: LCDL)، وهي تعاونية متعددة المؤسسات تأسست قبل ذلك بأقل من ثلاث سنوات، تقترب بسرعة من حد ترخيصها في (CONTENTdm) البالغ 50,000 مادة. وفي ظل نقص الموظفين وغياب مبرمج، قيّمت الكلية خياراتها، وشرعت في نهاية المطاف في بناء مستودع فيدورا كومنز (Fedora Commons) مع طبقة اكتشاف (discovery) من (Blacklight)، وتثبيت لبرنامج (OpenWMS) التابع لجامعة روتجرز (Rutgers) لإدخال المواد إلى فيدورا، وواجهة أمامية بنظام (Drupal)، بديلًا عن مكتبتها الرقمية القائمة. وقد اكتمل بناء النظام ورُحّلت إليه أكثر من 20,000 مادة. نجح المشروع، لكنه حمل دروسًا قاسية كثيرة.
مقدمة:
في عام 2009، أنشأت كلية تشارلستون، بدعم من مؤسسة غايلورد ودوروثي دونيلي (Gaylord and Dorothy Donnelley Foundation)، مكتبة لوكانتري الرقمية، وهي أول مكتبة رقمية في منطقة لوكانتري بولاية كارولاينا الجنوبية. وكان الهدف إنشاء مركز إقليمي للمسح الضوئي ومستودع رقمي يتشارك مع مؤسسات التراث الثقافي في المنطقة، ويغذي مكتبة كارولاينا الجنوبية الرقمية (South Carolina Digital Library: SCDL). وكانت المجموعات الرقمية لجامعة كارولاينا الجنوبية تستخدم (CONTENTdm)، كما كانت مكتبة كارولاينا الجنوبية الرقمية آنذاك تستخدم خادم (CONTENTdm) متعدد المواقع وسيلةً لتجميع المحتوى من أنحاء الولاية. ومن ثَمّ كان (CONTENTdm) خيارًا طبيعيًا لمكتبة لوكانتري. وعلى مدى العامين التاليين، تطورت المكتبة إلى نظام مرخّص تستضيفه الكلية بنفسها لـ(CONTENTdm)، مع نظام لإدارة المحتوى طُوّر محليًا وموقع متعدد الطبقات مبني بلغة (PHP) يتيح للعدد المتزايد من شركاء المشروع تطبيق بعض خصائص الهوية المؤسسية الخاصة بكل منهم على صفحات العرض.
وبحلول عام 2011، كان لدى المكتبة أكثر من 12 شريكًا في المشروع، ونحو 50,000 مادة مرقمنة. وكان ترخيص (CONTENTdm) الحالي للمكتبة محدودًا بـ50,000 مادة. ويعرّف (CONTENTdm) المادة بأنها صورة ممسوحة ضوئيًا واحدة، وتُحسب الكائنات المركبة (compound objects) بعدد صورها الممسوحة ضوئيًا مضافًا إليه واحد لتسجيلة الكائن المركب. وكانت الشريحة التالية والأخيرة المتاحة للمكتبة في الترخيص هي الترخيص غير المحدود، الذي يتيح للمؤسسة تحميل عدد غير محدود من المواد. وواجه موظفو المكتبة وإداريو المكتبات قرارًا مكلفًا: إما الالتزام بـ(CONTENTdm) وشراء الترخيص غير المحدود، بتكلفة لمرة واحدة تتجاوز 40,000 دولار ورسوم صيانة سنوية تتجاوز 9,000 دولار، وإما البحث عن حلول أخرى. وكان الحل السهل هو الاستثمار في الترخيص غير المحدود؛ غير أنه، حتى مع أقل من 50,000 مادة، كانت هناك بالفعل مشكلات واضحة في النظام القائم، منها مشكلات في البرمجيات من جهة الخادم ونتائج بحث غير دقيقة. وقررت الكلية أن ترقية (CONTENTdm) ليست مكلفة فحسب، بل لن تحل مشكلات النظام هذه أيضًا، فركزت على جدوى الخيارات مفتوحة المصدر المتاحة.
التقييم:
كُلّف مؤلفا هذا المقال، هيذر غيلبرت (Heather Gilbert) وتايلر موبلي (Tyler Mobley)، بتقييم النظام القائم وتقويم الحلول المحتملة. وغيلبرت، أمينة مكتبة البحث العلمي الرقمي (Digital Scholarship Librarian) في الكلية ومنسقة مشروع مكتبة لوكانتري الرقمية، مصممة رسوم ومطورة ويب متمرسة لها بعض الخلفية في تقييم البرمجيات. وكانت نقاط قوتها آنذاك في (HTML) و(PHP) و(CSS)، مع خبرة في البيانات الوصفية بمعياري دبلن كور (Dublin Core) و(VRA). وبحكم خبرتها السابقة في تطوير الويب ومنصبها الحالي منسقةً لمشروع المكتبة، كانت غيلبرت الخيار الطبيعي للتركيز على ترحيل البيانات الوصفية وتطوير الواجهة الأمامية. أما موبلي، أمين مكتبة الخدمات الرقمية، فقد ركز جهوده على تقييم الاكتشاف والمستودع وتنفيذهما. وكانت خبرته آنذاك تتركز في البحث في المصادر المفتوحة وتطوير الويب، مع نقاط قوة في (HTML) و(CSS) و(PHP) و(JavaScript). وفضلًا عن ذلك، فهو المتخصص في (XML/XSLT) في المكتبة بعد عمله على أدلة المجموعات الأرشيفية بمعيار (EAD) الخاصة بالمجموعات الخاصة وتحويلها للإتاحة على الإنترنت. وكان أيضًا أحد القلائل في المكتبة ممن يديرون خوادم لينكس، فكانت البرمجيات الجديدة وتثبيتها من اختصاصه.
وبعد تقييم دقيق للنظام القائم، خلصنا إلى أن استبداله يتطلب أربعة مكونات: وسيلة لإدخال البيانات من الملفات النصية، ومستودعًا للتخزين، وواجهة لاكتشاف المحتوى، وموقعًا يتيح إبراز هوية المؤسسات الشريكة.
وبعد تقييم نظامنا الحالي، قُيّمت أربعة خيارات بوصفها حلولًا بديلة محتملة: (Omeka)، و(DSpace)، والترخيص غير المحدود لـ(CONTENTdm)، ونموذج البناء الذاتي.
وفي وقت التقييم، كان الإصدار 1.2 من (Omeka) هو الإصدار الحالي، والإصدار 1.5 على وشك الصدور. وكان (Omeka) مألوفًا لنا بالفعل، إذ كنا نقيّمه لأغراض عديدة في المكتبة. غير أننا لم نعثر على أي تطبيقات فعلية له تضم مجموعات بحجم مجموعاتنا (50,000 مادة أو أكثر)، وكنا قلقين بشأن قابليته للتوسع. وكنا نعلم أيضًا أنه، مع تنوع أنواع ملفاتنا وعدد المؤسسات الشريكة، لن يكون (Omeka) خيارًا مثاليًا. وقررنا أنه، مع أن (Omeka) سيعمل جيدًا منصةً للمعارض، فإننا لا نزال بحاجة إلى نظام لإدارة الأصول الرقمية (digital asset management system: DAMS) لدعم المكتبة الرقمية. والواقع أننا نستخدم (Omeka) الآن منصةً للمعارض الرقمية، وقد نجحنا في ربطه بتثبيت فيدورا الجديد لمكتبة لوكانتري.
ونظرنا في (DSpace)، فوجدنا أنه يؤدي من الوظائف ما يكفي ليكون خيارًا ثانويًا إن أخفقت الحلول الأخرى. ولم نعثر على أمثلة لمكتبات رقمية أخرى قائمة على التراث الثقافي تستخدم (DSpace)، وأصبحنا قلقين من أنه قد لا يلبي احتياجاتنا تلبية كاملة. فأمثلة المكتبات الرقمية المبنية على (DSpace) التي وجدناها اعتمدت تصميمات أساسية لا تقدم خيارات بنيوية وخيارات عرض كافية لمحتوانا الأرشيفي المتنوع. وتحتاج مكتبة لوكانتري تحديدًا إلى عارض صور مرن ومتسق بصريًا يمكنه التعامل مع الكائنات المفردة والمركبة على حد سواء، فضلًا عن عرض النصوص المفرّغة ضمن الصفحة وتكبير الصور، ولم نعثر على أمثلة تمثيلية لذلك في (DSpace). ومع أننا فكرنا في تخصيص (DSpace) تخصيصًا كبيرًا، فإن العمل اللازم لذلك كان سيكون مرهقًا، ولا يستحق الجهد مقارنةً بالخيارين الواضحين الآخرين: إما ترقية تثبيت (CONTENTdm) القائم، وإما تقييم عناصر برمجية مفتوحة المصدر لبناء نظامنا الخاص لإدارة المحتوى.
وكما ذُكر سابقًا، كان الترخيص غير المحدود لـ(CONTENTdm) سيكون الحل الواضح لمشكلاتنا. غير أنه كانت هناك أسباب قوية عدة ضد ترقية (CONTENTdm). فقد كانت المكتبة تشغّل الإصدار 5.1 من (CONTENTdm)، وكان الموقع متعدد الطبقات المبني بـ(PHP) وجميع تخصيصاته معتمدًا على ذلك الإصدار. وكان هناك احتمال قوي جدًا أن يتعطل نظام إدارة المحتوى المطوَّر محليًا مع الترقية إلى (CONTENTdm 6).(x). وفضلًا عن ذلك، كان أمين مكتبة النظم الذي أنشأ ذلك النظام قد انتقل إلى منصب آخر ولم يكن متاحًا للاستشارة. وكنا قد واجهنا أيضًا قصورًا في الدعم الفني لـ(CONTENTdm) على مر السنين، ولا سيما طول فترات الانتظار في طلبات معالجة الأعطال، وعدم تقديم أي حل لمشكلاتنا التقنية في مرات عدة، ووجدنا كلًّا من واجهة البحث للمستخدم وطريقة عرض النتائج في (CONTENTdm) مخيّبة للآمال وغير متسقة. وتلقينا على مدى العام الماضي شكاوى متواصلة من المستخدمين بشأن واجهة البحث ونتائجه. فكثيرًا ما كانت الاستعلامات تسترجع لا نتائج، أو نتائج غير دقيقة، أو نتائج غير متسقة من استعلام إلى آخر، للمستخدمين الهواة والمتمرسين على حد سواء (ومنهم أعضاء فريق هذا المشروع). وكانت أوجه «تضييق البحث» (facets) المعروضة في صفحة النتائج إشكالية هي الأخرى؛ إذ لم تكن خيارات التضييق سوى الموضوع والمنشئ والتاريخ، ولم تكن جميع تلك النتائج تُعرض. وفي تجربتنا، قدّم (CONTENTdm) للمستخدم نتائج بحث غير دقيقة على نحو متقطع، وقدرة ضعيفة على تضييق تلك النتائج. وكنا نعتقد أن بإمكاننا تحقيق ما هو أفضل.
النظام المختار وأسباب اختياره:
في نهاية المطاف، توقفنا عن تقييم الأنظمة المتكاملة لإدارة الأصول الرقمية، واتجهنا إلى تجميع مكونات مفتوحة المصدر تعمل معًا لتلبية احتياجاتنا. وبنينا المكتبة الرقمية من أربعة مكونات تشكّل بديلًا كاملًا للنظام الأصلي: برنامج (OpenWMS) الذي طورته جامعة روتجرز لإدخال المواد إلى فيدورا، ومستودع فيدورا كومنز، وواجهة الاكتشاف (Blacklight)، ونظام (Drupal) لإدارة موقع المشروع وإبراز هوية المؤسسات الشريكة.
المستودع:
ثبّتنا مستودع فيدورا كومنز، الإصدار 3.4.2، لتخزين مواد مكتبة لوكانتري وحفظها. وبنية مستودع فيدورا كومنز قابلة للتوسع إلى ملايين المواد، وينبغي أن توفر للمنطقة متسعًا كافيًا للنمو في المستقبل المنظور. وقد قدّم نموذج الكائن الرقمي في فيدورا حزمة حسنة التنظيم للبيانات الوصفية والمحتوى الرقمي المصاحب لها في أثناء ترحيلنا من (CONTENTdm). ومع استمرار ترحيل موادنا إلى فيدورا، نكتسب المرونة لإعادة استخدامها في تطبيقات إضافية (مثل أداة (Exhibit Builder) في (Omeka)) بسحب الكائنات عبر واجهات برمجة التطبيقات (APIs) الشبكية لفيدورا. ولدينا أيضًا خطط مستقبلية لإضافة مزيد من الوثائق بصيغة (XML) في شكل أدلة مجموعات أرشيفية بمعيار (EAD). وفضلًا عن ذلك، وجدنا عند الترحيل أن فيدورا يخزن الكائنات بكفاءة أكبر من النظام السابق، مما ترك لنا مساحة تخزين على الخادم أكبر من المتوقع.
الإدخال:
تبيّن أن توفير وسيلة مناسبة لإدخال المواد هو أصعب المتطلبات. فالبرامج مفتوحة المصدر التي تتيح إدخال المواد دفعة واحدة من ملفات نصية مفصولة بعلامات الجدولة إلى مستودع رقمي قليلة على نحو لافت. ومع اتساع دائرة الشركاء وتفاوت مهاراتهم التقنية، وعدم توافر تمويل لتعيين أمين مكتبة متفرغ للبيانات الوصفية، كان علينا الحفاظ على سهولة استخدام جداول البيانات لإنشاء البيانات الوصفية ومراجعتها وتخزينها. وكان (OpenWMS) من جامعة روتجرز الخيار الوحيد الذي وجدناه يلبّي هذه الحاجة؛ فثبّتنا إصداره التجريبي، ولا نزال نستخدمه.
الموقع:
لما كانت مكتبة لوكانتري الرقمية تتألف من عدد متزايد من الشركاء من أنحاء المنطقة، فإن القدرة على تطبيق أنماط الهوية المؤسسية على أقسام مختلفة من موقع المكتبة ضرورة. واخترنا (Drupal) لأسباب عدة، ليس أقلها قدرته على تقديم سمات (themes) سهلة وقابلة للتغيير بناءً على مصطلحات التصنيف (taxonomy terms). كما أتاح لنا خيار إنشاء مدونات لكل مؤسسة من مؤسساتنا الشريكة يمكن أن تصب في مدونة جماعية واحدة للمكتبة. وفضلًا عن ذلك، يتمتع (Drupal) بسجل مثبت من الإصدارات المستقرة، ومجتمع هائل من المستخدمين، وقاعدة متنامية من الوحدات المساهَم بها التي تقدم مجموعة واسعة من الوظائف، مما يطمئننا إلى أن هذا النظام سيكون قادرًا على استيعاب نمو المكتبة مستقبلًا.
واجهة الاكتشاف:
كانت خصائص البحث والاكتشاف في (CONTENTdm) محدودة وغير فعالة في كثير من الأحيان. فقد كان من الصعب العثور على المواد المعروفة، وكان استرجاع نتائج البحث بطيئًا. والأهم من ذلك أننا كنا نفتقر إلى تحكم دقيق في حقول العرض وخيارات تضييق البحث التي تعرضها نتائج البحث. وبعد شيء من الاستكشاف، قررنا أن واجهة الاكتشاف (Blacklight) العاملة بمحرك (Solr)، مع إضافات من إطار (Hydra)، ستتيح لنا نوع البحث السريع والفعال الذي كنا نريده. ومشروع (Hydra) تعاون متعدد المؤسسات يقدم تطبيقًا مخصصًا لـ(Blacklight) متكاملًا مع فيدورا كومنز. ويوفر (Hydra) عمليات (CRUD) (الإنشاء والقراءة والتحديث والحذف) كاملة، ويمكن استخدامه حلًّا إداريًا كاملًا لمستودع فيدورا كومنز. غير أنه، لما كنا نستخدم بالفعل حلًّا آخر للإدارة، فإن تثبيتنا لـ(Blacklight) يستخدم أساسًا مكونات (Hydra) التي تتيح لنا فهرسة المحتوى من فيدورا كومنز في فهرس البحث (Solr). كما أتاح لنا التحكم الأكبر الذي منحتنا إياه هذه الأنظمة في نتائج البحث وخيارات العرض ضبطَ نتائج الاكتشاف إجمالًا ضبطًا دقيقًا. ونظرًا للطابع الإقليمي الخاص لأنواع المواد الموجودة حاليًا في مجموعات المكتبة، فإن القدرة على اختيار الأوجه تساعدنا على توجيه مستخدمينا بفاعلية أكبر إلى المحتوى الذي يحتاجون إليه.
التنفيذ: الواجهة الأمامية:
عرفنا (Drupal) لأول مرة خيارًا لموقع الواجهة الأمامية للمكتبات الرقمية (ولـ(CONTENTdm) تحديدًا) في عام 2011، حين قدّم مركز كارولاينا الشمالية للتراث الرقمي (North Carolina Digital Heritage Center) عرضًا في مؤتمر مستخدمي (CONTENTdm) في الجنوب الشرقي. وكان عرضهم مقنعًا بشأن مزايا (Drupal)، فحضرنا أول مخيم (DrupalCamp) لنا بعد بضعة أشهر. ورغم منحنى التعلم الكبير الذي ينطوي عليه إعداد (Drupal)، كان هذا النظام مرشحنا الأول والحقيقي الوحيد لاستبدال نظام إدارة المحتوى الداخلي للمكتبة. وقد نظرنا في أنظمة أخرى لإدارة المحتوى، منها (WordPress) و(Concrete5)، لكن مجتمع المستخدمين النشط، والمرونة الفائقة، وشبكة الدعم الإلكترونية الواسعة التي يقدمها (Drupal) جعلت القرار سهلًا. ومن المزايا الأخرى التي وجدناها في (Drupal) لهذا المشروع خيار شراء حزمة دعم ميسورة التكلفة إن احتجنا إليها، مما وفّر لنا خيارات لمعالجة الأعطال مستقبلًا إن تبيّن أن الدعم الذي يتطلبه (Drupal) يفوق طاقة موظفينا.
وما إن أعددنا الواجهة الخلفية لـ(Drupal) لأغراض المكتبة، حتى صار البناء بسيطًا إلى حد بعيد. فقد بنينا تصنيفات قائمة على أنواع الوسائط وأسماء المؤسسات. وطوّرنا أيضًا أنواع محتوى مخصصة للمجموعات والمؤسسات وخطط الدروس وشرائح الصور المميزة. وأتاح لنا استخدام وحدة (ThemeKey) في (Drupal) تطبيق سمات مخصصة بناءً على نوع التصنيف. فجميع مدخلات المدونة، والصفحات الرئيسية للمجموعات، والصفحات الرئيسية للمؤسسات، تحمل مصطلحات تصنيف، مما يجعل ربط السمات بمحتوى شركائنا أمرًا يسير التطبيق. وكان لا بد من تنسيق (Blacklight) ليندمج اندماجًا شبه سلس مع واجهة (Drupal) الأمامية. ومع أننا أردنا إبقاء تثبيتي الموقع والفهرس منفصلين، فإننا لم نرد أن يشعر المستخدمون بالضياع في أثناء تصفحهم وبحثهم. وتتضمن الصفحة الرئيسية في (Drupal) والصفحات الرئيسية للمؤسسات في أرجاء الموقع استعلامات بحث مخصصة ترتبط بنتائج البحث في فهرس (Blacklight).
وقد طرح تنفيذ (Blacklight) واجهةً للاكتشاف في النظام الجديد عددًا من التحديات الملازمة لمشروعات المصدر المفتوح. فمع أننا أردنا تحسين طريقة عرض المواد ونتائج البحث التي يقدمها (CONTENTdm)، لم يكن بوسع أي مشروع مفتوح المصدر أن يقدم بديلًا كاملًا جاهزًا للاستخدام لنظامنا الحالي من حيث مجمل الخصائص والوظائف. فإن أردنا عروضًا أفضل، كان علينا إنشاؤها وتخصيصها بأنفسنا. ويعني غياب بنية النظام المملوك هذا أنه لا يوجد تثبيتان لـ(Blacklight) متطابقان تمامًا، ولذا كثيرًا ما تكون الحلول خاصة بالمؤسسة. وكثيرًا ما يُساء فهم هذا الجانب من تطوير المصادر المفتوحة. فمشروعات المصدر المفتوح يمكن أن تمنحك نقطة انطلاق متينة والأدوات اللازمة لحل مشكلتك، لكن عليك أن تخصص المشروع ليلبي احتياجاتك. وقد تفاقمت صعوباتنا لأن خبرتنا كانت محدودة في التطوير بلغة (Ruby)، وهي اللغة المستخدمة في بناء (Blacklight). وهذا يعني أن عملية تطوير الاكتشاف كانت تتحول بانتظام إلى فرصة للتعلم في أثناء العمل.
ولما كان تثبيتنا لـ(Blacklight/Hydra) يتيح لنا فهرسة البيانات الوصفية من فيدورا في فهرس البحث (Solr)، فإن جزءًا كبيرًا من الوقت المستغرق في التنفيذ انصرف إلى مطابقة جميع التنويعات الممكنة للبيانات الوصفية للكائنات القادمة من فيدورا. وفضلًا عن ذلك، لا يوفر التصدير من (CONTENTdm) البيانات الوصفية البنيوية (structural metadata) اللازمة لترجمة المنطق المطلوب للكائنات المركبة كالكتب والكتيبات والبطاقات البريدية. فإصدارنا من (CONTENTdm)، وهو 5.1، كان يفتقر إلى واجهات برمجة التطبيقات المتاحة في الإصدارات الأحدث لتصدير بيانات أغنى. وتمثل هذه الكائنات جزءًا كبيرًا من مكتبة لوكانتري، واعتاد مستخدمونا أن يتمكنوا من تصفح هذه الكائنات في عارض واحد على الإنترنت. فكان علينا إعادة بناء وظيفة الكائن المركب هذه بأكبر قدر ممكن من السلاسة. وكان لا بد كذلك من إعادة بناء خصائص أخرى، كالنصوص المفرّغة للصفحات ضمن العرض وتكبير الصور. وقد دُمجت هذه الخصائص جميعها بنجاح في النظام الجديد دون الحاجة إلى (Adobe Flash)، الذي كان مشكلة في نظام (CONTENTdm) السابق بسبب تخصيصات (Zoomify) التي نُفّذت فيه من قبل. وكانت خصائص التكبير هذه تحظى بشعبية كبيرة لدى مستخدمينا، فأردنا الإبقاء عليها مع تحسين إتاحتها.
التنفيذ: الواجهة الخلفية:
كانت تعقيدات تنفيذ مستودع فيدورا كومنز للنسخة الجديدة من مكتبة لوكانتري عملية أكثر منها تقنية. فبالنسبة لتثبيت بحجم تثبيتنا، يُعدّ إعداد فيدورا وتثبيته أمرًا مباشرًا إلى حد بعيد. غير أنه، بالنظر إلى المستوى المحدود من الموارد الذي كان لدينا، تبيّن أن مسائل التخزين والوصول هي أبرز الصعوبات.
ويعمل نظام فيدورا كومنز لدينا حاليًا في حاوية (Apache Tomcat) تُوجَّه عبر (IIS 7) على خادم بنظام (Windows 2008). ويضم هذا الخادم أيضًا تثبيت (CONTENTdm) السابق. وحين حان وقت إيجاد بيئة تشغيل متاحة للجمهور لفيدورا (في أوائل عام 2012)، كانت المكتبة تملك عتادًا محدودًا من الخوادم ووحدات التخزين. وكان خادم ويندوز هذا أكبر ما لدينا (وأكثره توفرًا)، فقررنا إدخال فيدورا تدريجيًا مع إخراج (CONTENTdm) تدريجيًا على الخادم نفسه.
وفي ربيع عام 2012، حصلت المكتبة على عتاد جديد من الخوادم ووحدات التخزين، فنحن الآن في مراحل التخطيط لترحيل التثبيت الحالي لفيدورا إلى خادم لينكس في أقرب وقت ممكن. ومع أن فيدورا نفسه يعمل جيدًا في (Tomcat) على جهاز ويندوز، فقد واجهنا تعقيدات ناجمة عن تشغيل (Tomcat) عبر (IIS) وعن تواصله مع خوادم لينكس الأخرى.
وبعد أن حددنا بنية مستودعنا وبدأنا التنفيذ، شرعنا في البحث عن عملاء للإدخال. وبالنظر إلى الوراء، لم يكن هذا هو الترتيب المثالي الذي كان ينبغي أن تسير عليه العملية. فقد كانت لدينا احتياجات خاصة من عميل الإدخال، إذ كان عليه أن يحافظ على سهولة الاستخدام التي كان (CONTENTdm) يقدمها لشركاء مشروعنا في إدخال مواد أرشيفية متنوعة. وهذا يعني أن أحد متطلبات عميل الإدخال سيكون القدرة على الإدخال الدفعي من جدول بيانات (أي ملفات نصية مفصولة بعلامات الجدولة). وفي هذه المرحلة، كادت قلة خبرتنا في بناء أنظمة إدارة الأصول الرقمية أن تُحدث مشكلات خطيرة، ووجدنا مهمة تحديد عميل للإدخال أصعب مما توقعنا. فحين بحثنا عن طريقة للإدخال، وجدنا أن معظم عملاء الإدخال إما صُمموا للإصدار 2.(x) من فيدورا ((Elated) و(Fez))، وإما كانوا لا يزالون في مراحل التخطيط وسيصبحون في نهاية المطاف شيئًا لا صلة له باحتياجات مشروعنا (مثل (Ensemble)). وكان عميل الإدخال الوحيد الذي لبّى قدرًا كافيًا من احتياجاتنا هو (OpenWMS) من جامعة روتجرز. و(OpenWMS) عميل شبكي للبيانات الوصفية يتيح للمستخدم إدخال البيانات الوصفية والكائنات الرقمية إلى فيدورا وتصديرها منه. ويوفر واجهة شبكية مباشرة لإنشاء المجموعات والمجموعات الفرعية والمواد المفردة، فضلًا عن الاستيراد الدفعي ومطابقة البيانات الوصفية. ويتيح (OpenWMS) إدخال ملفات نصية للبيانات الوصفية مفصولة بعلامات الجدولة، ويحوّل تلك الملفات إلى تسجيلات مرمّزة بصيغة (Fedora Object XML) (FOXML). ثم ينشئ (OpenWMS) مجلدًا يحوي حزمة جاهزة للاستيراد إلى فيدورا.
والأهم بالنسبة لنا، وهو أحد أسباب استمرارنا في استخدامه عميلًا للإدخال حتى اليوم، أن (OpenWMS) يتيح للمستخدم استيراد البيانات الوصفية باستخدام مخطط داخلي. ففي وقت اعتماده، لم يكن (OpenWMS) يتيح للمستخدم المطابقة إلا من مخطط داخلي أو من (MARC) أو (MODS) (أما الإصدار المستقر فيتيح الآن مجموعة متنوعة من المخططات). وكان مخطط البيانات الوصفية لمكتبة لوكانتري في (CONTENTdm) قائمًا على دبلن كور. وعلى مر السنين، تضخم دبلن كور الخاص بالمكتبة إلى أكثر من ستين عنصرًا، وتبيّن عند المراجعة أن أكثر من ثلث هذه العناصر كانت مكررات صريحة أو تنويعات على حقول قائمة. وتطلّب استخدام نظام (OpenWMS) لإدخال موادنا إلى فيدورا أن تُجعل بيانات (CONTENTdm) الوصفية قابلة للمطابقة من دبلن كور إلى (MODS) (مخطط وصف عناصر البيانات الوصفية الذي يعتمد عليه (OpenWMS)). غير أننا رأينا في هذا المتطلب مسوّغًا وفرصة ممتازة في آن واحد لتصحيح البيانات الوصفية السابقة لمجموعاتنا الرقمية. وقد أسفر هذا التصحيح الذي يتطلب جهدًا بشريًا كبيرًا (الذي اكتمل نحو نصفه وقت كتابة هذه السطور، ولم يتبقَّ سوى 25,000 مادة) عن بيانات وصفية أدق بكثير. كما يجعل هذا التصحيح انضمامنا المرتقب إلى المكتبة العامة الرقمية الأمريكية (Digital Public Library of America: DPLA) أيسر، إذ إننا نصحح بالفعل معظم أوجه عدم الاتساق في البيانات الوصفية التي كشفت عنها عمليات تقييم الجودة وضبطها المبكرة في (DPLA).
غير أن تجاربنا مع (OpenWMS) لم تكن مثالية. فقد كان الإصدار التجريبي مليئًا بالأخطاء البرمجية (وهذا متوقع بطبيعة الحال)، وكان دليل الاستخدام لا يزال قيد الإعداد حين ثبّتناه. وفي البداية، كان إنشاء تسجيلات البيانات الوصفية وتحميلها قائمًا إلى حد بعيد على التجربة والخطأ، وكان توليد (FOXML) توليدًا صحيحًا من عمليات الاستيراد الدفعي صعبًا بعض الشيء في البداية. وتعلّمنا في النهاية كيف نملأ دفعيًا حقول (MODS) المترابطة، مثل <(note)> ونظيره <(note type)="(X)">، من جدول بيانات واحد. غير أننا لا نعتقد أن البرمجية المثبتة قد صُممت قط لتؤدي هذه الوظيفة. والواقع أنه حين أصدرت جامعة روتجرز إصدارًا مستقرًا من (OpenWMS) أصلح كثيرًا من الأخطاء التي واجهناها في الإصدار التجريبي، أغلق أيضًا، للأسف، معظم الثغرات التي يبدو أننا كنا نستغلها لاستيراد بياناتنا الوصفية استيرادًا صحيحًا. فاضطررنا فعلًا إلى العودة إلى الإصدار التجريبي الأقل استقرارًا.
تحسين الواجهة وتجربة الاستخدام:
أصبحت الصفحة الرئيسية الجديدة المبنية بنظام (Drupal) أبسط وأوضح، مع إبراز نموذج البحث في (Blacklight). وهي متجاوبة مع أحجام الشاشات المختلفة وتدعم اللمس، بينما كانت الصفحة القديمة تعتمد على (Flash) ولا تلائم الأجهزة المحمولة.
كان عرض المؤسسات المشاركة في النظام السابق يقتصر على قائمة تتضمن وصفًا موجزًا لكل مؤسسة وصورة مصغرة. أما النظام الجديد فيخصص لكل مؤسسة صفحة رئيسية تضم أداة بحث مرتبطة مباشرة بـ(Blacklight)، ويتيح تطبيق هويتها البصرية، بما في ذلك شعاراتها وتدرجات ألوان الخلفية.
وعملنا كذلك على تبسيط عارض الصور وطريقة عرض البيانات الوصفية، وإضافة وظيفة تكبير محسّنة تلائم الأجهزة اللوحية والمحمولة.
وفي المقارنة بين نتائج البحث في النظامين باستخدام كلمة «(Earthquake)» («زلزال»)، أعطى النظام الجديد نتائج أدق، مع أنه لم يكن يضم آنذاك سوى أقل من نصف محتوى النظام الأصلي بقليل. ونتوقع أن تتحسن هذه الدقة مع إضافة بقية المحتوى. كما يقدم النظام الجديد خيارات مفيدة لتضييق نتائج البحث، بخلاف الخيارات التي كان يعرضها النظام السابق.
الدروس المستفادة:
تحدث عمليات الترحيل من التقنيات المملوكة إلى تقنيات المصدر المفتوح في أنظمة المكتبات لأسباب عدة، ويمكن أن تكون مفيدة ومليئة بالتحديات في آن واحد. فأحيانًا لا تبدأ مشروعات الترحيل لأنها تحقق تحسينًا كبيرًا في الخدمات لموظفي المكتبة أو مستخدميها، بل لأن غياب رسوم الترخيص يبدو جذابًا. وبطبيعة الحال، فإن هذه المشروعات تتكبد ببساطة مجموعة مختلفة من التكاليف إذا أُخذ في الحسبان وقت الموظفين وعمليات التعلم والتكيف. وحين دخلت مكتبة لوكانتري عملية الترحيل هذه، كنا نعلم أن بديلًا مفتوح المصدر لمكتبتنا الرقمية سيمنحنا المرونة التي نحتاج إليها في نظام إدارة الأصول الرقمية، وكنا نعلم أنها لن تكون مهمة سهلة. فلم يكن لدينا في الأساس سوى شخصين للعمل على المشروع، وخبرة برمجية ضئيلة جدًا، ودعم مالي محدود. غير أن نطاق ما يمكن لمجموعة صغيرة إنجازه في مشروعات المكتبات مفتوحة المصدر قد اتسع اتساعًا هائلًا في السنوات الأخيرة. وبفضل عمل مجموعات التطوير في فيدورا و(OpenWMS) التابع لجامعة روتجرز و(Drupal) و(Blacklight) و(Hydra) وأمثالها، كنا نعلم أن الأدوات اللازمة لإنتاج المكتبة الرقمية التي نريدها موجودة.
ومع ذلك، بالغنا في تفاؤلنا بشأن توافر حلول جاهزة لبعض المسائل. فمع أن مطورين آخرين أنشؤوا عارضات متقدمة للكائنات المركبة في (Blacklight)، لم تكن أنظمتهم قابلة دائمًا للمقارنة بنظامنا، لاختلاف معايير البيانات الوصفية وإجراءات العمل بين المؤسسات. وفي هذه المشروعات مفتوحة المصدر، يصعب العثور على بيئتين متطابقتين يمكن تبادل حلول التطوير بينهما بسهولة، كما يحدث بين المؤسسات التي تستخدم الإعداد القياسي نفسه لـ(CONTENTdm). وقد تلقينا مساعدة كبيرة من مجموعتي مستخدمي (Hydra) و(Blacklight)؛ ولولا نصائحهما لما تجاوزنا كثيرًا من العقبات الأولى في فهم واجهة الاكتشاف وبنيتها. لكن الترحيل تطلّب في النهاية ابتكار حلول خاصة بظروفنا، وكان الوصول إليها صعبًا في كثير من الأحيان.
وكانت الحاجة لا إلى ترحيل بياناتنا الوصفية فحسب، بل إلى تصحيحها أيضًا، مليئة بالتحديات ومستهلكة للوقت، لكنها ستؤتي في النهاية نتائج إيجابية. فلم ندرك مدى عدم اتساق بياناتنا الوصفية الموروثة حتى بدأنا تقييم الأنظمة لهذا المشروع. وكان الكشف عن مكمن الضعف هذا في سير عملنا فائدة مهمة وغير متوقعة لهذا المشروع. وكان تصحيح البيانات الوصفية سيكون ضروريًا بصرف النظر عن النظام الذي اخترنا تنفيذه. ومع ذلك، ربما لم يكن صرف ساعات عمل الموظفين لتحويل دبلن كور إلى (MODS) أفضل فكرة في ذلك الوقت. فهذا التحويل الذي يتطلب جهدًا بشريًا كبيرًا إلى أقصى حد، وهو عملية لا يمكن أتمتتها بالكامل. فعلى سبيل المثال، في جدول بيانات وصفية، يجب أن يُفصل حقل (dc:subject) يدويًا إلى عمودي (MODS) <(subject)> <(topic)> و<(subject)> <(geographic)>. وبالنظر إلى الوراء، كان سيكون أكفأ أن نحافظ على دبلن كور الأصلي، وأن نصحح أوجه عدم الاتساق قبل التصدير باستخدام وظيفة البحث والاستبدال في (CONTENTdm). وسواء أكان ذلك للأفضل أم للأسوأ، اتخذنا القرار النهائي بالانتقال إلى (MODS) بناءً على حاجتنا إلى عميل للإدخال، ونحن الآن ملتزمون بذلك التحويل وبكل الوقت الذي يستلزمه. ربما سلكنا هذا الطريق الذي يتطلب جهدًا بشريًا كبيرًا عن سذاجة، لكنه أحدث تحولًا في تعاملنا مع البيانات الوصفية على مستوى المنطقة. فلدينا الآن فهم ممتاز لمخططات متعددة، ولمطابقتها وبنية شفرتها، وللمؤهِّلات (qualifications) والمفردات المضبوطة (controlled vocabularies) التي تتطلبها. وقد طلبت منا مكتبة كارولاينا الجنوبية الرقمية أن نوظف هذه المعرفة المكتسبة حديثًا في مساعدتها على وضع معايير أكثر صرامة للبيانات الوصفية على مستوى الولاية وإنفاذها.
وشكّل فقدان البيانات الوصفية البنيوية الناجم عن الخروج من بيئة (CONTENTdm) تحديًا إضافيًا. فقبل الخروج من (CONTENTdm)، لم نضطر قط إلى إيلاء البيانات الوصفية البنيوية اهتمامًا كبيرًا؛ إذ كان عميل المشروع في النظام يتيح لنا إنشاء الكائنات المركبة، ويتولى كل ما عدا ذلك خلف الكواليس. وحين صدّرنا البيانات الوصفية للكائنات المركبة، انتهى بنا الأمر إلى بيانات وصفية لمادة مفردة لكل صفحة، ولم يكن بوسع فيدورا و(Blacklight)، كما هو مفهوم، أن يعالجا ما إذا كانت لهذه الصفحات أي علاقات وظيفية. فكان لا بد من تعديل سير عمل الإدخال في (OpenWMS) تبعًا لذلك، وكُتبت طريقة مخصصة لـ(Blacklight) لمعاملة مواد معينة معاملة ملائمة. وفي نهاية المطاف، يستفيد نهجنا الجديد في تحميل الكائنات المركبة من فهرس (Solr) للبيانات الوصفية للكائنات. فكل كائن مركب هو كائن فيدورا من نوع النموذج ‘(Compound)’. ولما كنا نعامل كل كائن مركب كأنه مجموعة فرعية، فإن لكائن فيدورا هذا معرّفًا فريدًا للمجموعة في تدفق بيانات (MODS) (datastream) يُفهرس في (Solr). وحين يُستدعى كائن مركب في (Blacklight)، تستعلم طريقتنا (Solr) عن الكائنات المفهرسة من النموذج ‘(Page)’ التي تحمل معرّف المجموعة نفسه. ثم تُحلَّل نتيجة (Solr) إلى جدول تجزئة (hash) وتُسلَّم إلى عرض (Compound) لاستخدامها فهرسًا للصفحات. ولا تشبه هذه العملية إلا قليلًا الطريقة التي كان (CONTENTdm) يبني بها الكائنات المركبة، لكنها تلبي احتياجاتنا الحالية جيدًا، ولا سيما بالنظر إلى معرفتنا المحدودة بصيغ البيانات الوصفية البنيوية الأخرى مثل (RDF). وفي مشروعات الترحيل، ينبغي لمن يرغبون في اعتماد أنظمة مفتوحة المصدر أن يفهموا النظام الذي يغادرونه فهمهم للنظام الذي يبنونه. وفي حالتنا، لم نتعلم المزيد عن النظام الأصلي إلا حين حاولنا مغادرته.
الخاتمة:
رغم عدد من العثرات في عملية الترحيل والبناء، أصبحت لدينا الآن مكتبة رقمية عاملة يفوق أداؤها أداء نظامنا الأصلي بمراحل في خصائص العرض ودقة البحث وأزمنة التحميل. ونظامنا الجديد مستدام إلى حد كبير، وقابل للتوسع بما يكفي لاستيعاب نمونا بسهولة في المستقبل المنظور. ومع أن هذا المشروع كان يمكن أن يكون أقل صعوبة بكثير لو توفر مبرمج و/أو مجموعة أقوى من المهارات البرمجية لدى المؤلفَين كليهما، فإن تجربة التعلم وحدها كانت لا تقدر بثمن، ويمكننا القول بثقة إن رصيدنا من مهارات البرمجة قد تضاعف أضعافًا كثيرة. وبهذا النظام الجديد وهذه المهارات الجديدة، يمكننا ضمان النمو المستمر لرؤيتنا الخاصة لما يمكن أن تكونه مكتبة لوكانتري الرقمية، بدلًا من رؤية يفرضها نظام مملوك.