مقایسه مدل‌سازی داده در RDA و21 MARC: شکاف مفهومی و فنی

لیزنا؛ المیرا سفیان، دانشجوی دکتری مدیریت اطلاعات دانشگاه تبریز و کارشناس ترویج کتابخوانی ستاد مرکزی نهاد کتابخانه های عمومی کشور: سازماندهی دانش در کتابخانه‌ها همواره بازتابی از وضعیت فناوری اطلاعات در هر دوره بوده است. در دوره فهرست‌های برگه‌ای، هدف اصلی ثبت و بازیابی اطلاعات کتابشناختی در قالبی فشرده و انسانی‌خوان بود. با ورود سامانه‌های رایانه‌ای، همین منطق در قالب استانداردهایی چون MARC21 ادامه یافت؛ استانداردی که در اصل برای تبادل رکوردهای کتابشناختی طراحی شده بود، نه برای مدل‌سازی دانش در محیط‌های شبکه‌ای و معنایی.

با گسترش وب، داده‌های پیوندی، و نیاز به تعامل‌پذیری میان نظام‌های اطلاعاتی، ضعف‌های ساختار رکوردمحور21 MARC بیش از پیش آشکار شد. در پاسخ به این تحولات، RDA بر مبنای الگوهای مفهومی جدید، از جمله FRBR و سپس IFLA LRM، طراحی شد تا به‌جای تمرکز صرف بر رکورد، بر موجودیت‌ها، ویژگی‌ها و روابط میان آن‌ها تأکید کند. از این منظر، RDA نه صرفاً مجموعه‌ای از قواعد فهرست‌نویسی، بلکه بخشی از گذار به الگوی داده‌محور در سازماندهی دانش است.

مسئله اصلی: تفاوت استاندارد محتوایی و زیرساخت فنی

یکی از خطاهای رایج در پیاده‌سازی RDA آن است که تصور می‌شود با افزودن چند فیلد جدید به21 MARC یا تغییر برچسب‌های نمایشی در نرم‌افزار کتابخانه، می‌توان RDA را به طور کامل اجرا کرد. در حالی که RDA یک استاندارد محتوایی است، اما بهره‌گیری واقعی از ظرفیت‌های آن نیازمند زیرساخت فنی متناسب است. اگر زیرساخت فنی همچنان بر اساس رکوردهای خطی، فیلدهای از پیش تعریف‌شده و روابط ضمنی عمل کند، آنگاه داده‌های تولیدشده حتی اگر از نظر ظاهری مطابق RDA باشند، از نظر ساختاری همچنان اسیر منطق قدیم خواهند بود.

به بیان دیگر، مشکل اصلی در خود RDA نیست، بلکه در بستری است که قرار است RDA در آن اجرا شود. نرم‌افزارهای سنتی کتابخانه‌ای عمدتاً برای ذخیره، نمایش و بازیابی رکورد طراحی شده‌اند، نه برای مدیریت شبکه‌ای از موجودیت‌های مستقل و روابط صریح میان آن‌ها. بنابراین، RDA در این محیط‌ها دچار تقلیل می‌شود و فقط بخشی از ظاهر آن حفظ می‌گردد. 

فقدان شناسه‌های پایدار و مستقل

در منطق RDA و به‌ویژه در پیاده‌سازی‌های سازگار با RDF، هر موجودیت باید بتواند با یک شناسه پایدار و یکتا معرفی شود. اما در بسیاری از نرم‌افزارهای سنتی، اشخاص، نهادها، آثار و موضوعات غالباً در حد نقاط دسترسی متنی باقی می‌مانند. در نتیجه، «مولف» به عنوان یک موجودیت مستقل با قابلیت پیوند و استفاده مجدد ظاهر نمی‌شود، بلکه فقط به شکل یک رشته متنی در رکورد ثبت می‌گردد. این امر مانع از شکل‌گیری واقعی گراف داده می‌شود.

در بسیاری از نرم‌افزارهای کتابخانه‌ای قدیمی، اطلاعاتی مثل نام پدیدآورنده فقط به صورت رشته متنی در رکورد ذخیره می‌شود:

در اینجا "صمدبهرنگی" فقط یک متن است، نه یک موجودیت مستقل.

یعنی:

• شناسه یکتا ندارد
• نمی‌توان به آن مستقیماً ارجاع داد
• نمی‌توان ویژگی‌های دیگری برایش ثبت کرد
• استفاده مجدد از آن در رکوردهای دیگر ساخت‌یافته نیست
• پیوند به منابع بیرونی مثل VIAF، ISNI، Wikidata و غیره دشوار می‌شود

در نتیجه، «مولف» در این مدل بخشی از متن رکورد است، نه یک گره مستقل در گراف داده.

مدل صحیح در منطق RDA و RDF

در رویکرد RDA/RDF، «شخص» یک موجودیت مستقل است و باید با یک شناسه پایدار و یکتا معرفی شود. 

این قطعه Turtle دارد یک مدل «گرافی» می‌سازد که در آن اثر و پدیدآورنده (شخص) دو موجودیت جدا هستند و با یک رابطه به هم وصل می‌شوند؛ یعنی «مولف» دیگر یک رشته متن داخل رکورد نیست، یک گره قابل‌ارجاع است.

Prefixها (تعریف میان بر برای URIها)

@prefix dct:    <http://purl.org/dc/terms/> .

@prefix schema: <http://schema.org/> .

• dct: کوتاه‌شده‌ی واژگان Dublin Core Terms است (برای مفاهیمی مثل عنوان، پدیدآورنده، ناشر…).
• schema: کوتاه‌شده‌ی واژگان Schema.org است (برای کلاس‌هایی مثل Person و CreativeWork و ویژگی‌هایی مثل name).

بدون prefix مجبور بودیم هر بار URI کامل را بنویسیم.

تعریف یک «اثر» به عنوان یک منبع (resource) با URI مستقل

<http://example.org/work/1> a schema:CreativeWork ; dct:title "ماهی سیاه کوچلو" ; dct:creator <http://example.org/agent/5678> .

سوژه/گره

<http://example.org/work/1>

این یک شناسه یکتا (URI) برای «یک اثر مشخص» است. مهم‌ترین نکته اینجاست: اثر، یک گره مستقل در گراف است.

ب) نوع (rdf:type)

a schema:CreativeWork ;

کلمه a در Turtle همان rdf:type است. یعنی:

• این منبع از نوع اثر/کار خلاقانه (schema:CreativeWork) است.

ج) عنوان

dct:title "ماهی سیاه کوچلو" ;

یعنی:

• این اثر عنوانی دارد که مقدارش یک literal (رشته) است: " ماهی سیاه کوچلو ".

د) پدیدآورنده (creator) به صورت «لینک»، نه متن

dct:creator <http://example.org/agent/5678> .

این بخش کلیدی است:

• مقدار dct:creator یک رشته متنی نیست
• یک URI است که به یک موجودیت دیگر اشاره می‌کند:
• <http://example.org/agent/5678>

پس به جای این:

• creator = “صمدبهرنگی”

گفته‌ایم:

• creator = (یک شخص مشخص با URI مشخص)

3) تعریف «شخص» به عنوان موجودیت مستقل (Agent/Person)

<http://example.org/agent/7568>

    a schema:Person ;

    schema:name "صمدبهرنگی" .

این یعنی:

الف) گره شخص

<http://example.org/agent/5678>

یک URI یکتا برای «آن شخص» (پدیدآورنده) است. این همان چیزی است که در سیستم‌های سنتی معمولاً فقط به صورت متن ذخیره می‌شود.

ب) نوع

a schema:Person ;

یعنی این گره از نوع Person است.

ج) نام نمایشی

schema:name "صمدبهرنگی" .

نامی که برای نمایش/جستجو استفاده می‌شود.

4) حاصل کار: یک گراف با دو گره و یک یال

به زبان ساده این گراف ساخته شده:

• گره ۱: work/ (اثر)
• گره ۲: agent/5678 (شخص)
• یال/رابطه: dct:creator از اثر به شخص

پس اگر بعداً اثر دیگری هم همین مولف را داشته باشد، به جای تکرار متن، فقط به همان URI وصل می‌شود:

<http://example.org/work/2> dct:creator <http://example.org/agent/5678> .

این همان «قابلیت استفاده مجدد» و «هویت پایدار» است.

چون وقتی مولف یک URI دارد، می‌توانی:

• اطلاعات بیشتری به همان شخص اضافه کنی (تولد/وفات، شکل‌های دیگر نام، زبان، حرفه…)
• از همان شخص در هزار رکورد استفاده کنی بدون تکرار و ابهام
• به شناسه‌های بیرونی وصل کنی (VIAF/ISNI/Wikidata)
• واقعاً گراف بسازی (نه صرفاً متن درون رکورد)

استفاده مجدد از همان موجودیت

مزیت اصلی وقتی روشن می‌شود که همان مولف در چند اثر تکرار شود.

در سیستم سنتی، هر بار نام او به شکل متن تکرار می‌شود.

اما در RDF، همان یک شناسه دوباره استفاده می‌شود: 

ضمنی بودن روابط

در MARC21 رابطه‌ها عموماً ضمنی هستند. برای مثال، وجود نام شخص در فیلد 100 به این معنا تفسیر می‌شود که او پدیدآورنده اثر است، اما این رابطه به صورت یک پیوند صریح و قابل پیمایش در ساختار داده مدل نشده است. در مقابل، در مدل‌های مبتنی بر RDF رابطه‌ای مانند «این اثر دارای پدیدآورنده است» به شکل گزاره‌ای مستقل و قابل پردازش ثبت می‌شود. نرم‌افزارهای سنتی، چون چنین روابطی را ذاتاً مدیریت نمی‌کنند، نمی‌توانند منطق RDA را در سطح عمیق اجرا کنند. 

چرا می‌گویند ضمنی؟

چون رابطه:

• فقط از ساختار رکورد فهمیده می‌شود

یعنی نرم‌افزار باید بداند:

• 100 یعنی نام اصلی
• این نام معمولاً نقش پدیدآور دارد
• 245 عنوان است
• پس بین این دو یک رابطه وجود دارد

اینجا «مترجم» فقط یک متن است در انتهای یک فیلد.خود «مترجم» به عنوان یک موجودیت مستقل با شناسه یکتا (URI) که به اثر ترجمه شده «پیوند» خورده باشد، وجود ندارد، نرم‌افزار باید بفهمد که اگر در فیلد 700$e کلمه «مترجم» بود، پس این نام، نقش مترجم اثر را دارد، رابطه «ترجمه کردن» ضمنی است و به ساختار فیلدها وابسته است، در مجموع رابطه در خود داده نیست،در تفسیر ما از داده است. 

1. ex:hasTranslator agent:5678 .: این خط در تعریف data:samad_behrangi_translated_work (که همان اثر است) بیان می‌کند که رابطه “دارای مترجم” (ex:hasTranslator) بین این اثر و موجودیتی با URI agent:5678 وجود دارد.
2. agent:5678 rdf:type ex:Agent ; ex:name "صمد بهرنگی" .: این قسمت، موجودیت agent:5678 را تعریف می‌کند و مشخص می‌سازد که این موجودیت یک Agent (شخص) است و نامش “صمد بهرنگی” می‌باشد.

بنابراین، با ترکیب این دو بخش، به طور کاملاً روشن و با استفاده از URI، مشخص می‌شود که موجودیت agent:5678 که نامش “صمد بهرنگی” است، نقش مترجم را برای اثر data:samad_behrangi_translated_work ایفا کرده است. URI <http://example.org/agent/5678> به طور منحصر به فرد به شخص “صمد بهرنگی” اشاره دارد و نقش او در این زمینه خاص (مترجم) از طریق رابطه ex:hasTranslator مشخص شده است.

محدودیت در پیوند با داده‌های خارجی

یکی از قابلیت‌های مهم RDA در محیط جدید، آمادگی برای حضور در اکوسیستم Linked Data است. اما نرم‌افزارهای سنتی معمولاً برای ارتباط‌گیری پویا با واژگان کنترل‌شده، فایل‌های مستند خارجی، یا گراف‌های دانش طراحی نشده‌اند. بنابراین، حتی اگر داده‌ها مطابق RDA ورود شوند، ظرفیت اتصال آن‌ها به جهان وسیع‌تر داده‌های کتابخانه‌ای  فعال نمی‌شود. 

 خروجی 

نتیجه‌گیری :

ناتوانی اثبات‌شده نرم‌افزارهای سنتی در پیاده‌سازی RDA

حقیقت محض و غیرقابل انکار این است: RDA یک استاندارد نوین با منطقی بنیادین متفاوت است و نرم‌افزارهای کتابخانه‌ای سنتی، با معماری رکورد-محور و منطق ضمنی خود، به طور ذاتی فاقد توانایی لازم برای پیاده‌سازی کامل آن هستند. هرگونه تلاشی برای “جا دادن” RDA در این چارچوب‌های قدیمی، نه یک راه‌حل، بلکه صرفاً اتلاف منابع و زمان است؛ تلاشی محکوم به شکست که تنها ظاهرسازی می‌کند و با نمونه‌کدهای نمایشی، عدم امکان آن اثبات شده است.

شکاف مفهومی و فنی: موجودیت‌گرایی RDA در برابر رکوردگرایی MARC.

RDA بر پایه مدل‌های مفهومی مدرنی بنا شده که موجودیت‌ها، روابط صریح و شناسه‌های جهانی (URI) را محور اصلی قرار می‌دهند و داده‌ها را به یک گراف دانش پویا تبدیل می‌کنند. در مقابل، MARC21 یک فرمت تبادل رکورد است که روابط را به صورت ضمنی تعریف می‌کند. این تفاوت، یک شکاف مفهومی و فنی بنیادی است.

ناتوانی پردازش داده‌ها با کد: نمایان شدن محدودیت‌ها.

همانطور که با نمونه کدها نشان داده شد، نحوه نمایش و پردازش داده‌ها در دو مدل کاملاً متفاوت است. در مدل MARC، اطلاعات به صورت رشته‌های متنی ساده در رکوردها ذخیره می‌شوند، بدون آنکه هویت مستقل یا قابلیت پیوند جهانی داشته باشند. این در حالی است که RDA هر موجودیت را با یک شناسه منحصربه‌فرد (URI) تعریف کرده و روابط را به صورت صریح بیان می‌کند، که اساس یک ساختار گراف‌محور است. نرم‌افزارهای سنتی که بر پایه منطق MARC و پایگاه‌های داده رابطه‌ای طراحی شده‌اند، قادر به درک، پردازش، و بهره‌برداری از این ساختار گراف‌محور نیستند. آن‌ها فاقد موتورهای پردازشی برای مدیریت URIها به عنوان موجودیت‌های مستقل و پیمایش روابط صریح هستند.

هزینه  و پیچیدگی “پیاده‌سازی جزئی”.

پذیرش کامل RDA مستلزم سرمایه‌گذاری کلان در زیرساخت‌های نوین (مانند پایگاه‌های داده گراف) است. تلاش برای “شبیه‌سازی” RDA در سیستم‌های موجود، تنها به تغییرات سطحی و ناکارآمد منجر می‌شود که مزایای واقعی RDA را ارائه نمی‌دهد و منابع را هدر می‌دهد.

با توجه به تفاوت‌های بنیادین مدل‌های داده‌ای و ناتوانی اثبات‌شده نرم‌افزارهای سنتی در پردازش مدل RDA، همانطور که با نمونه کدها نشان دادیم، هرگونه تلاش برای انطباق RDA با این چارچوب‌ها، قطعاً محکوم به شکست و صرفاً نوعی ظاهرسازی است. واقعیت فنی این است که RDA نیازمند یک زیرساخت کاملاً متفاوت است و اصرار بر استفاده از ابزارهای قدیمی برای استانداردهای نوین، راه به جایی نخواهد برد. این یک پایان قطعی برای بحث بر سر امکان‌پذیری فنی است.

https://github.com/RDFLib/rdflib

https://github.com/tu-graz-library/invenio-records-marc21

https://github.com/ImMattDavison/LinkData

https://www.loc.gov/marc/bibliographic/

https://www.loc.gov/aba/rda/