الگوهای RDF-star برای استحکام

مشخصات RDF-STAR به عنوان گزارش نهایی گروه جامعه در دسامبر سال 2021 منتشر شد. برای کمی بیشتر از یک سال ، برخی از شرکت کنندگان در گروه جامعه RDF-DEV به نیروهای پیوسته اند تا توضیحی تلفیقی از RDF-STAR و یک آزمایش مرتبط ارائه دهندمجموعههدف تقویت همگرایی پیاده سازی های موجود و ظهور موارد جدید قابل تعامل است.

توسعه RDF-STAR با شور و شوق و انتظارات زیادی احاطه شده است ، که هم نعمت و هم یک نفرین است. به نظر می رسد بسیاری از افراد با پیشینه و نیازهای مختلف انتظار دارند که RDF-Star یک راه حل کامل و سر راست برای مشکل خاص آنها باشد. برای فعال کردن موارد استفاده چندگانه ، این گروه تلاش کرده است RDF-STAR را به یک جعبه ابزار عمومی تبدیل کند ، که از این تعداد بیشتر موارد استفاده را می توان حل کرد-در حالی که گاهی اوقات کاربر را ملزم می کند تا مایل اضافی را طی کند.

در این پست ، ما برخی از درس های آموخته شده توسط گروه را از طریق بحث و تبادل ارائه می دهیم. این به معنای ارائه بینشی در مورد دلیل منطقی RDF-STAR است ، و برخی از دستورالعمل ها در مورد نحوه استفاده به بهترین وجه استفاده از آن برای مدل سازی داده های ارائه شده است.

فقط یک سه گانه نقل شده می تواند حمل کند

اولین نمونه از مشخصات RDF-STAR در زیر تکرار شده است:

PREFIX : :employee38 :familyName "Smith" .>: مطابق: کارمند 22. 

معنای مورد نظر این نمودار کوچک RDF-Star این است: "کارمند شماره 38 به نام اسمیت نامگذاری شده است ، و کارمند شماره 22 ادعا می کند که کارمند شماره 38 دستیار طراح است". این مثال ، به ویژه نشان می دهد که چگونه می توان از یک سه گانه نقل شده (بین براکت های زاویه دوتایی) استفاده کرد (در اینجا ، به عنوان موضوع سه گانه دیگر) بدون اینکه ادعا شود: ما (نویسندگان نمودار) ادعای مطرح شده توسط کارمند را تأیید نمی کنیمشماره 22. با نقل قول ، ما به سه گانه مراجعه می کنیم بدون اینکه خود سه گانه بخشی از نمودار باشد.

این مثال می تواند به شرح زیر گسترش یابد:

PREFIX :>: مطابق: کارمند 22 ،: کارمند 38 ؛: اعتماد به نفس 0. 8. 

در این مثال جدید ، هم کارمند شماره 22 و هم کارمند شماره 38 ادعای یکسان می کنند ، که هنوز مورد تأیید ما نیست. علاوه بر این ، ما نمره اعتماد به نفس را به این بیانیه اختصاص می دهیم که عنوان شغلی کارمند شماره 38 "دستیار طراح" است.

برای نشان دادن چگونگی مفید بودن این نوع مدل سازی ، یک فروشگاه RDF حاوی مجموعه ای از ادعاها را تصور کنید ، که در بالا با مدعیان و سطح اطمینان شرح داده شده است. از پرس و جو SPARQL-STAR زیر می توان برای بازیابی ، برای هر یک از مدعیان ، حداقل اعتماد به نفس ما در اظهارات آنها درباره خودشان استفاده کرد.

پیشوند: انتخاب کنید؟ مدعی (min (؟ conf) به عنوان؟ minConfidence)<> :accordingTo ?claimer; :confidence ?conf>گروه توسط؟ مدعی 

با این حال درک این نکته مهم است که این طرح اساسی محدودیت هایی دارد. یعنی ، هر جمله ای که درباره یک سه گانه خاص بیان شده است باید به طور مستقل از سایر اظهارات گفته شده در مورد آن سه گانه قابل تفسیر باشد.(این در واقع یک ویژگی کلی RDF است ، نه فقط RDF-STAR: دو جمله در مورد یک موضوع همیشه باید به طور مستقل از یکدیگر قابل تفسیر باشند. در وب باز ، اگر فرض کنیم سه گانه دیگری که هنوز کشف نکرده ایم می تواند تغییر کندمعنی سه گانه که ما می دانیم ، پس استدلال با آنچه می دانیم بسیار خطرناک تر خواهد شد.)

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

 # ⚠ YOU MUST NOT DO THIS PREFIX :> :accordingTo :employee22; :confidence 0.2 . # we don’t trust employee22 about someone else’s job title>: مطابق: کارمند 38 ؛: اعتماد به نفس 0. 8.# ما کاملاً به کارمند 38 در مورد عنوان شغل خودشان اعتماد داریم

اول ، توجه داشته باشید که مثال فوق معنی: محمول اعتماد به نفس را تغییر می دهد. دیگر مورد استفاده قرار نمی گیرد تا اعتماد به نفس کلی ما در خود سه گانه را نشان دهد ، بلکه نشان دهنده اعتماد به نفس است که در یک شخص خاص داریم که ادعا می کند سه گانه است. اگر بخواهیم از یک هستی شناسی واقعی استفاده کنیم ، آن دو مفهوم مختلف "اعتماد به نفس" به دو عنبیه مجزا نیاز دارند.

اما مهمتر از همه ، مشکل مثال فوق این است که معنای مورد نظر را به طور دقیق ضبط نمی کند ، زیرا معادل:

PREFIX :>: مطابق: کارمند 22 ؛: مطابق: کارمند 38 ؛: اعتماد به نفس 0. 2 ؛: اعتماد به نفس 0. 8. 

The four triples asserted by this graph have the same subject (namely, the quoted triple>) ، و هیچ راهی برای دانستن اینکه کدام مدعی با کدام نمره اعتماد به نفس مرتبط است وجود ندارد.

این در تضاد RDF-STAR با (برخی از اجرای) نمودارهای خاصیت ، که به چندین لبه یکسان اجازه می دهد بین دو گره وجود داشته باشند و دارای خواص مختلف باشند. توجه داشته باشید که این "عدم تطابق امپدانس" از اوایل سال 2014 به رسمیت شناخته شده است ، اما برخی از راه حل ها قبلاً در آن زمان پیش بینی شده بودند.

مدل سازی پیچیده تر

The problem with the last example above is that we are not talking about the triple>(که منحصر به فرد توسط موضوع ، محمول و شیء آن مشخص می شود). ما می خواهیم در مورد دو ادعای مشابه اما متمایز صحبت کنیم ، هر یک با هویت خاص خود و خصوصیات خاص خود ادعا می کنیم. بگذارید یک ملک جدید را معرفی کنیم که یک سه گانه معین را به یک یا چند مورد از ادعاهای آن پیوند می دهد. یک نسخه صحیح از مثال قبلی اکنون خواهد بود:

PREFIX :>: HasClaim ،.: مدعی: کارمند 22 ؛: ContionConfidence 0. 2.: مدعی: کارمند 38 ؛: ContionConfidence 0. 8. 

به عنوان یک نهاد مستقل، هر ادعا می تواند دارای هر تعداد دارایی باشد که دیگر با ویژگی های سایر ادعاهای همان سه گانه اشتباه گرفته نمی شود. برای مثال، می توانیم این مثال را با افزودن تاریخ، یک سند منبع به هر ادعا، گسترش دهیم…

با چنین طراحی، پرس و جوی SPARQL-star فوق باید به روز شود و به این صورت می شود:

پیشوند: انتخاب کنید؟ مدعی (min (؟ conf) به عنوان؟ minConfidence)<> :hasClaim [ :claimer ?claimer; :claimConfidence ?conf ]>گروه توسط؟ مدعی 

پایان

توجه داشته باشید که می توان ادعا کرد که ما همیشه در مورد ادعاها صحبت کرده ایم، حتی در دو نمونه اول این پست، و به این ترتیب که این دو نمونه بد طراحی شده اند و باید از ویژگی :hasClaim نیز استفاده می کردند. ما استدلال می کنیم که طراحی دو مثال اول کافی است، زمانی که ویژگی های ثبت شده در مورد ادعاها به اندازه کافی ساده باشند. همیشه باید تعادلی بین، از یک سو، سادگی و قابلیت استفاده، و از سوی دیگر، خلوص و مقیاس پذیری یافت. به دنبال سخنان جورج باکس که «همه مدل ها اشتباه هستند، اما برخی مفید هستند»، در نظر می گیریم که طراحی دو نمونه اول در برخی شرایط به اندازه کافی مفید است.

تصدیق

با تشکر از اعضای گروه RDF-star برای بررسی و بازخوردشان در مورد این پست.