مورد ويب

📅 آخر تحديث: ٢٤ يوليو ٢٠٢٦
✍️ نُشر في: ٢٤ يوليو ٢٠٢٦
الموسوعة الحرة

مورد الويب هو أي مورد قابل للتحديد (رقمي، مادي، أو مجرد) موجود على شبكة الويب العالمية أو متصل بها . [ 1 ] [ 2 ] [ 3 ] تُحدد الموارد باستخدام مُعرّفات الموارد الموحدة (URIs). [ 1 ] [ 4 ] في الويب الدلالي ، تُوصف موارد الويب وخصائصها الدلالية باستخدام إطار وصف الموارد (RDF). [ 5 ]

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

من المستندات والملفات إلى موارد الويب

في المواصفات المبكرة للويب (1990-1994)، نادرًا ما استُخدم مصطلح " المورد" . صُمم الويب كشبكة من كائنات ثابتة قابلة للعنونة، وهي في الأساس ملفات ومستندات، مرتبطة باستخدام مُحددات مواقع الموارد الموحدة (URLs). يُعرَّف مورد الويب ضمنيًا بأنه شيء يمكن تحديده. يخدم التحديد غرضين متميزين: التسمية والعنونة؛ وتعتمد الأخيرة فقط على بروتوكول. من الجدير بالذكر أن RFC 1630 لم يُحاول تعريف مفهوم المورد على الإطلاق؛ بل إنه نادرًا ما يستخدم المصطلح باستثناء وروده في مُعرّف الموارد الموحد (URI) ومحدد موقع الموارد الموحد (URL) واسم الموارد الموحد (URN)، ولا يزال يتحدث عن "كائنات الشبكة".

يُحدد RFC 1738 (ديسمبر 1994) عناوين URL بشكلٍ أدق، حيث تم تغيير مصطلح "Universal" إلى "Uniform". ويُقدم هذا المستند استخدامًا أكثر منهجية لمصطلح " resource" للإشارة إلى الكائنات "المتاحة" أو "التي يُمكن تحديد موقعها والوصول إليها" عبر الإنترنت. ومع ذلك، لم يتم تعريف مصطلح "resource" نفسه تعريفًا صريحًا.

من موارد الويب إلى الموارد المجردة

أول تعريف صريح للمورد موجود في RFC 2396، في أغسطس 1998:

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

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

في يناير 2005، أوضح RFC 3986 هذا التوسع في التعريف بشكل صريح تمامًا: "...يمكن أن تكون المفاهيم المجردة موارد، مثل عوامل التشغيل والمعاملات في المعادلة الرياضية، أو أنواع العلاقات (مثل "الوالد" أو "الموظف")، أو القيم العددية (مثل الصفر والواحد واللانهاية)."

الموارد في RDF والويب الدلالي

صدرت RDF لأول مرة عام ١٩٩٩، وكان الهدف منها في البداية وصف الموارد، أي تعريف بياناتها الوصفية بطريقة موحدة. يتكون وصف RDF للمورد من مجموعة من الثلاثيات (الموضوع، والمسند، والمفعول به)، حيث يمثل الموضوع المورد المراد وصفه، والمسند نوعًا من الخصائص المتعلقة بهذا المورد، والمفعول به قد يكون بيانات أو موردًا آخر. يُعتبر المسند نفسه موردًا ويُعرَّف بواسطة معرّف موارد موحد (URI). بالتالي، تُمثَّل خصائص مثل "العنوان" و"المؤلف" في RDF كموارد، والتي يمكن استخدامها، بشكل متكرر، كموضوع لثلاثيات أخرى. وانطلاقًا من هذا المبدأ التكراري، ستُضيف مُفردات RDF، مثل RDF Schema (RDFS) و Web Ontology Language (OWL) و Simple Knowledge Organization System ، تعريفات للموارد المجردة مثل الفئات والخصائص والمفاهيم، وكلها مُعرَّفة بواسطة معرّفات موارد موحدة (URI).

يحدد RDF أيضًا تعريف الموارد المجهولة أو العقد الفارغة ، والتي لا يتم تحديدها بشكل مطلق بواسطة URIs.

استخدام معرّفات الموارد الموحدة (URIs) لبروتوكول HTTP لتحديد الموارد المجردة

تُستخدم عناوين URL ، وخاصةً عناوين URI الخاصة ببروتوكول HTTP ، بشكل متكرر لتحديد الموارد المجردة، مثل الفئات والخصائص والمفاهيم الأخرى. ويمكن إيجاد أمثلة على ذلك في أنطولوجيات RDFS أو OWL . ونظرًا لارتباط هذه العناوين ببروتوكول HTTP، فقد طُرح التساؤل حول نوع التمثيل الذي ينبغي الحصول عليه، إن وُجد، لهذه الموارد من خلال هذا البروتوكول، عادةً باستخدام متصفح الويب، وما إذا كان بناء جملة عنوان URI نفسه يُمكن أن يُساعد في التمييز بين الموارد "المجردة" والموارد "المعلوماتية". وقد تركت مواصفات عناوين URI، مثل RFC 3986، مهمة تحديد الإجراءات التي تُنفذ على الموارد لمواصفات البروتوكول، ولم تُقدم أي إجابة على هذا السؤال. لقد تم اقتراح أن يكون عنوان URI الخاص بـ HTTP الذي يحدد موردًا بالمعنى الأصلي، مثل ملف أو مستند أو أي نوع مما يسمى مورد المعلومات، هو عنوان URI "مائل" - بمعنى آخر، لا ينبغي أن يحتوي على معرف جزء ، في حين أن عنوان URI المستخدم لتحديد مفهوم أو مورد مجرد يجب أن يكون عنوان URI "مجزأ" باستخدام معرف جزء.

على سبيل المثال: http://www.example.org/catalogue/widgets.htmlسيحدد كلا النوعين صفحة ويب ويحدد موقعها (ربما من خلال تقديم وصف مفهوم للأدوات التي تبيعها شركة Silly Widgets, Inc.)، بينما http://www.example.org/ontology#Widgetسيحدد النوع الآخر المفهوم المجرد أو فئة "أداة" في أنطولوجيا هذه الشركة، ولن يسترجع بالضرورة أي مورد مادي عبر بروتوكول HTTP . ولكن قيل إن هذا التمييز مستحيل التطبيق عمليًا، وتقدم المصطلحات القياسية الشهيرة أمثلة مضادة شائعة الاستخدام. على سبيل المثال، تُعرَّف مفاهيم Dublin Core مثل "العنوان" و"الناشر" و"المنشئ" بواسطة معرّفات موارد موحدة (URIs) تبدأ بشرطة مائلة مثل http://purl.org/dc/elements/1.1/title.

كانت المسألة العامة المتعلقة بنوع الموارد التي ينبغي أو لا ينبغي أن يحددها معرّف الموارد الموحد (URI) لبروتوكول HTTP تُعرف سابقًا في اتحاد شبكة الويب العالمية (W3C) باسم مشكلة نطاق HTTP 14 ، وذلك نسبةً إلى اسمها في القائمة التي حددتها مجموعة العمل (TAG). وقدّمت مجموعة العمل (TAG) في عام 2005 إجابة نهائية لهذه المشكلة، حيث جعلت التمييز بين "مورد المعلومات" و"مورد غير المعلومات" يعتمد على نوع الاستجابة التي يقدمها الخادم لطلب "GET".

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

ملكية الموارد، والملكية الفكرية، والثقة

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

انظر أيضاً

مراجع

الاقتباسات

مصادر