چکیده

:

GeoSPARQL یک استاندارد مهم برای جامعه داده‌های مرتبط با مکانی است، با توجه به اینکه واژگانی را برای نمایش داده‌های مکانی در RDF تعریف می‌کند، توسعه‌ای را برای SPARQL برای پردازش داده‌های مکانی تعریف می‌کند و برای استدلال فضایی کیفی و کمی پشتیبانی می‌کند. با این حال، چیزی که جامعه از دست می دهد، یک روش جامع و عینی برای اندازه گیری میزان پشتیبانی GeoSPARQL در سه فروشگاه های RDF مجهز به GeoSPARQL است. برای پر کردن این شکاف، ما معیار انطباق GeoSPARQL را توسعه دادیم. ما مجموعه‌ای از آزمایش‌ها را پیشنهاد می‌کنیم که انطباق فروشگاه‌های سه‌گانه RDF با استاندارد GeoSPARQL را بررسی می‌کنند تا آزمایش کنیم که یک سیستم آزمایش‌شده چه تعداد از الزامات ذکر شده در استاندارد را پشتیبانی می‌کند. این موضوع نگران‌کننده است زیرا پشتیبانی از GeoSPARQL بین پیاده‌سازی‌های مختلف سه‌گانه بسیار متفاوت است و میزان پشتیبانی برای کاربران مختلف از اهمیت بالایی برخوردار است. به منظور نشان دادن معیار و کاربرد آن، ما مقایسه‌ای از نتایج معیار چندین فروشگاه سه‌گانه را ارائه می‌کنیم، که بینشی از پشتیبانی فعلی GeoSPARQL و پشتیبانی کلی GeoSPARQL در حوزه داده‌های پیوندی جغرافیایی ارائه می‌دهد.
کلید واژه ها: 

GeoSPARQL ; داده های جغرافیایی ؛ معیار ; RDF _ SPARQL

 

1. مقدمه

وب معنایی مکانی [ 1 ] به عنوان بخشی از وب معنایی [ 2 ] نشان دهنده انبوهی از اطلاعات مکانی است که به لحاظ معنایی تفسیر شده است. تحقیقات اولیه [ 3 ] و معرفی بعدی استاندارد OGC GeoSPARQL [ 4 ] نمایش داده های برداری مکانی (WKT [ 5 ] و GML [ 6 ]) را در هستی شناسی ها رسمی کرد و زبان پرس و جو SPARQL [ 7 ] را با پشتیبانی از فضایی گسترش داد. عملگرهای رابطه
چندین راه‌حل ذخیره‌سازی RDF از آن زمان تاکنون GeoSPARQL را به‌عنوان ویژگی‌های پیاده‌سازی فروشگاه سه‌گانه خود به کار گرفته‌اند [ 8 ، 9 ]. این سطوح مختلف پیاده سازی ممکن است منجر به برخی فرضیات نادرست کاربران در هنگام انتخاب پیاده سازی سه گانه مناسب برای پروژه خود شود. به عنوان مثال، برخی از پیاده‌سازی‌ها اجازه تعریف یک سیستم مرجع مختصات (CRS) [ 10 ] را در هندسه WKT داده‌ای را می‌دهند که در استاندارد GeoSPARQL (مثلا GraphDB) بیان شده است. سایر پیاده سازی ها اجازه تعریف CRS را نمی دهند و در عوض فقط از سیستم ژئودتیک جهانی WGS84 (به عنوان مثال RDF4J) پشتیبانی می کنند [ 11 ]]. چنین پیاده‌سازی‌هایی، حتی اگر طبق استاندارد GeoSPARQL ناقص باشند، هنوز بسیاری از موارد کاربری جغرافیایی را پوشش می‌دهند و می‌توانند در بسیاری از سناریوها مفید باشند. با این حال، به عنوان مثال، برای یک مرجع جغرافیایی که نیاز به کار با تعاریف مختلف سیستم مختصات دارد، مفید نیستند.
الزامات سه گانه های سازگار GeoSPARQL به وضوح در استاندارد GeoSPARQL [ 4 ] بیان شده است. با این حال، وب معنایی و جامعه GIS فاقد مجموعه آزمایشی انطباق برای GeoSPARQL است که ما در این نشریه مشارکت می‌کنیم. امیدواریم مشارکت ما به لیست تست‌های انطباق OGC اضافه شود (مجموعه‌های تست OGC: https://cite.opengeospatial.org/teamengine/ (در 22 مه 2021 قابل دسترسی است))، زیرا فاقد مجموعه آزمایشی مناسب برای GeoSPARQL هستند. .
مقاله ما به شکل زیر سازماندهی شده است. در بخش 2 ، ما رویکردهای موجود را که برای ارزیابی سه‌گانه‌های جغرافیایی کار می‌کردند، مورد بحث قرار می‌دهیم، و بخش 3 چارچوب آزمایشی معیار را معرفی می‌کند و چگونگی اجرای آزمایش‌های انطباق را توضیح می‌دهد. بخش 4 کاربرد چارچوب تست تعریف شده را در برابر پیاده سازی های مختلف triplestore توضیح می دهد و ما نتایج را در بخش 5 مورد بحث قرار می دهیم . در بخش 6 ، قبل از پایان کار در بخش 7 ، محدودیت های رویکرد خود را بیان می کنیم .

2. کارهای مرتبط

اکثر استانداردها الزاماتی را تعریف می کنند که برای برآورده کردن تعریف استاندارد باید برآورده شوند. با این حال، همه استانداردها توضیحات صریح در مورد نحوه آزمایش انطباق با الزامات آنها یا مجموعه آزمایشی که انطباق کلی با استاندارد را آزمایش می کند، ارائه نمی دهند.
GeoSPARQL [ 4 ]، به عنوان پسوند زبان پرس و جو SPARQL [ 7 ]، یک مدل هستی شناسی را برای نمایش هندسه های برداری، روابط و سریال سازی آن ها در WKT و GML، مجموعه ای از توابع فیلتر هندسه، یک پسوند دلالت RDFS، یک بازنویسی پرس و جو تعریف می کند. گسترش برای ساده سازی پرس و جوهای مکانی و توابع بیشتر دستکاری هندسه.
اول، مهم است که بین معیارهای عملکرد و معیارهای انطباق تمایز قائل شویم. معیارهای عملکرد سعی می کنند عملکرد سیستم را ارزیابی کنند، معمولاً با استفاده از مجموعه ای از پرس و جوها. معیارهای عملکرد ممکن است پیاده سازی های معادل معنایی را نیز در نظر بگیرند که از نحو مشخص شده توسط یک استاندارد معین پیروی نمی کنند. از سوی دیگر، معیارهای انطباق به کارایی یا عملکرد کلی یک سیستم مربوط نمی شود، بلکه به توانایی آن در برآوردن الزامات خاص مربوط می شود.
چندین پیاده‌سازی معیار که فروشگاه‌های سه‌گانه جغرافیایی را هدف قرار می‌دهند، مانند سری Geographica [ 12 ، 13 ] یا [ 9 ]، سعی می‌کنند عملکرد پیاده‌سازی عملکرد جغرافیایی را ارزیابی کنند. هر دو رویکرد از جامعه داده های پیوندی سرچشمه می گیرند. علاوه بر این، Ref. [ 14 ] نشان می‌دهد که جامعه جغرافیایی علاقه‌مند است تا فروشگاه‌های سه‌گانه زمین‌فضایی را نیز محک بزند. معیار آنها شامل یک مجموعه داده جدید ایجاد شده است و عملکردهای فیلتر GeoSPARQL را آزمایش می کند. در حالی که معیارهای ذکر شده ممکن است نشان دهند که آیا توابع پیاده‌سازی می‌شوند، لزوماً اجرای نادرست یک تابع مشخص را نشان نمی‌دهند.
معیار Tests for Triplestores (TFT) [ 15 ] شامل یک آزمون فرعی GeoSPARQL است. با این حال، آزمون فرعی که در اینجا مورد استفاده قرار می‌گیرد، بر اساس شش نمونه پرس‌و‌جوی SPARQL و مجموعه داده‌های نمونه تعریف‌شده در ضمیمه B استاندارد GeoSPARQL [ 4 ] است. اگرچه این مثال‌ها نقطه شروع خوبی هستند، اما ماهیت آموزنده دارند و به عنوان راهنما در نظر گرفته شده‌اند. بنابراین، هر معیاری که صرفاً بر اساس آنها باشد، حتی شروع به پوشش همه الزامات ممکن یا راه های متعددی که در آنها باید آزمایش شوند، نمی شود تا سیستمی مطابق با استاندارد تلقی شود.
اخیراً، گروه EuroSDR از پیاده‌سازی معیار [ 14 ] برای اجرای یک معیار انطباق با GeoSPARQL کوچک استفاده کرد (تست EuroSDR GeoSPARQL: https://data.pldn.nl/eurosdr/geosparql-test (در 22 مه 2021 در دسترس قرار گرفت). این معیار انطباق شامل 27 پرس و جو است که مجموعه‌ای از توابع GeoSPARQL را روی یک مجموعه داده آزمایشی آزمایش می‌کنند. برخلاف معیار ما، این پیاده سازی به صراحت تمام الزامات تعریف شده در استاندارد GeoSPARQL را آزمایش نمی کند. به طور خاص، پشتیبانی GML، پشتیبانی مستلزم RDFS و پسوند بازنویسی پرس و جو، در میان سایر موارد، در این معیار آزمایش نشده اند.

3. معیار انطباق GeoSPARQL

معیار انطباق GeoSPARQL بر اساس الزامات تعریف شده در استاندارد GeoSPARQL [ 4 ] است. 30 الزامات تعریف شده در استاندارد در شش دسته گروه بندی می شوند و به مدل هستی شناسی GeoSPARQL و مجموعه ای از برنامه های افزودنی که سیستم ها نیاز به پیاده سازی دارند و باید در معیار ما آزمایش شوند اشاره دارد:
  • مؤلفه اصلی (CORE): مؤلفه‌های واژگان فضایی سطح بالا را تعریف می‌کند (الزامات 1-3).
  • گسترش واژگان توپولوژی (TOP): واژگان رابطه توپولوژیکی را تعریف می کند (الزامات 4-6).
  • پسوند هندسی (GEOEXT): واژگان هندسه و توابع پرس و جو غیر توپولوژیکی را تعریف می کند (الزامات 7-20).
  • پسوند توپولوژی هندسه (GTOP): توابع پرس و جوی توپولوژیکی را برای اشیاء هندسی تعریف می کند (نیازمندی های 21-24).
  • پسوند مستلزم RDFS (RDFSE): مکانیزمی را برای تطبیق سه گانه RDF ضمنی (استنتاج شده) که بر اساس معنایی RDF و RDFS مشتق شده اند، به عنوان مثال، از استدلال RDFS مشتق شده اند (الزامات 25-27) تعریف می کند.
  • پسوند بازنویسی پرس و جو (QRW): قوانین تبدیل پرس و جو را برای محاسبه روابط فضایی بین اشیاء فضایی بر اساس هندسه مرتبط آنها تعریف می کند (الزامات 28-30).
هر یک از الزامات مشخص شده ممکن است با استفاده از مجموعه‌ای از دستورالعمل‌ها آزمایش شوند که در مجموعه آزمایشی انتزاعی در ضمیمه A استاندارد GeoSPARQL [ 4 ] به طور آزاد تعریف شده‌اند. در حالی که مجموعه آزمایشی انتزاعی هدف، روش و نوع آزمون را برای تأیید اینکه آیا یک نیاز خاص برآورده شده است، تعریف می‌کند، مجموعه مشخصی از پرس‌و‌جوهای SPARQL و مجموعه داده‌های آزمایشی را که ممکن است برای مرجع استفاده شود، تعریف نمی‌کند. ما مجموعه داده‌های آزمایشی و مجموعه‌ای از جستارهای SPARQL را برای تأیید هر الزام در این انتشارات مشارکت می‌دهیم.
در معیار انطباق GeoSPARQL، هر نیاز توسط یک یا چند پرسش SPARQL، که در آن یک پاسخ مورد انتظار یا مجموعه‌ای از پاسخ‌های مورد انتظار وجود دارد، آزمایش می‌شود. تعداد پرس و جوهایی که برای آزمایش یک نیاز استفاده می شود، و همچنین تعداد پاسخ های مورد انتظار در هر پرس و جو، به ماهیت نیاز بستگی دارد. برای برخی از آنها، داشتن یک پرس و جو و یک پاسخ مورد انتظار برای آزمایش اینکه آیا سیستم تحت آزمایش با آن مطابقت دارد کافی است. در مقابل، سایر الزامات دارای الزامات فرعی هستند – برای مثال، الزامات مربوط به چندین ویژگی یا توابع، الزامات مربوط به توابعی که می توانند با هندسه هایی با سریال های مختلف استفاده شوند، یا الزاماتی که نیاز به پوشش گسترده تری از موارد دارند تا اطمینان حاصل شود که آنها به طور کامل برآورده می شوند. در این موارد از چندین پرس و جو استفاده می شود.
این رویکرد استفاده از پرسش‌ها و پاسخ‌های مورد انتظار به‌عنوان آزمایش به ما اجازه می‌دهد تا انطباق هر سیستم ذخیره‌سازی RDF را با استفاده از پلتفرم معیار HOBBIT اندازه‌گیری کنیم [ 16 ، 17 ].
خروجی معیار درصدی است که انطباق کلی سیستم آزمایش شده را با استاندارد GeoSPARQL اندازه گیری می کند. تعداد نیازهای پشتیبانی شده سیستم را از 30 مورد نیاز مشخص شده به صورت درصد اندازه گیری می کند.

3.1. مجموعه داده محک

استاندارد GeoSPARQL یک مجموعه داده نمونه را برای آزمایش در ضمیمه B [ 4 ] خود تعریف می کند، که می تواند با مجموعه ای از شش نمونه پرس و جوی آزمایشی تعریف شده در همان بخش استفاده شود. این مجموعه داده نمونه شامل شش هندسه است. ما می‌خواستیم از این مجموعه داده استفاده کنیم، اما با توجه به اینکه هدف ما آزمایش تمام الزامات استاندارد بود، باید مجموعه داده‌ها را هم با هندسه‌های جدید و هم با ویژگی‌های اضافی هندسه‌های موجود به طور قابل‌توجهی گسترش دهیم. شکل 1 هندسه های موجود در مجموعه داده توسعه یافته ما را نشان می دهد، در حالی که فهرست 1 حاوی گزیده ای RDF از مجموعه داده است، در نحو لاک پشت که هندسه A (نقطه) را نشان می دهد.
مجموعه داده معیار توسعه یافته شامل 13 هندسه از انواع Polygon ، Point و LineString است که همگی به صورت WKT و GML بیان می شوند. اندازه کل مجموعه داده RDF بیش از 300 سه برابر است. مجموعه داده به عنوان بخشی از کد معیار [ 18 ، 19 ]، در نمایش‌های RDF/XML، GeoJSON [ 20 ] و GML موجود است.

3.2. پرس و جوهای محک

ما در اینجا یک نمای کلی از رویکردی که در نوشتن پرسش‌های مورد استفاده توسط معیار برای آزمایش الزامات استاندارد GeoSPARQL داشتیم، ارائه می‌کنیم. الزامات به ترتیب تعاریف توسعه GeoSPARQL ارائه شده در بخش 3 ارائه شده است. پرسش‌های معیار به‌عنوان بخشی از کد محک [ 18 ]، همراه با یک جدول خلاصه که الزامات را به مجموعه‌های مربوطه پرس‌و‌جوها، یعنی آزمون‌ها و آزمون‌های فرعی ترسیم می‌کند، در دسترس هستند. جزئیات در مورد نحوه نمره گذاری هر آزمون و آزمون فرعی در بخش 3.3 ارائه شده است.
درخواست  1
پیاده سازی ها باید از زبان پرس و جوی SPARQL برای RDF [ 7 ]، پروتکل SPARQL برای RDF [ 21 ] و قالب XML نتایج جستجوی SPARQL [ 22 ] پشتیبانی کنند.
ما شرط 1 را با یک پرس و جوی SPARQL اصلی آزمایش می کنیم که اولین سه گانه را که هندسه A موضوع است انتخاب می کند. برای به دست آوردن نتایج ثابت در سیستم های مختلف، باید از یک موضوع خاص استفاده کنیم و نتایج را مرتب کنیم.
درخواست  2
پیاده سازی ها باید به کلاس RDFS [ 23 ] geo:SpatialObject در الگوهای گراف SPARQL استفاده شود.
درخواست  3
پیاده سازی ها باید به کلاس RDFS اجازه دهند که در الگوهای نمودار SPARQL استفاده شود.
الزامات 2 و 3 با پرس و جوهای SPARQL منفرد آزمایش می شوند که به ترتیب اولین موجودیت از نوع geo:SpatialObject و geo:Feature را انتخاب می کنند. برای به دست آوردن نتایج ثابت برای هر دو پرس و جو در سیستم های مختلف، نتایج را سفارش می دهیم.
جدول
فهرست 1: گزیده ای RDF از مجموعه داده های معیار، در نحو لاک پشت، که هندسه نقطه ای دوبعدی را نشان می دهد.
درخواست  4
پیاده سازی ها باید ویژگی های geo:sfEquals ، geo:sfDisjoint ، geo:sfIntersects ، geo:sfTouches ، geo:sfCrosses ، geo:sfWithin ،
geo:sfContains ، geo:sfOverlaps برای استفاده در الگوهای نمودار SPARQL.
درخواست  5
پیاده سازی ها باید ویژگی های geo:ehEquals ، geo:ehDisjoint ،
geo:ehMeet , geo:ehOverlap , geo:ehCovers , geo:ehCoveredBy , geo:ehInside ,
geo:eh حاوی برای استفاده در الگوهای نمودار SPARQL.
درخواست  6
پیاده‌سازی‌ها باید ویژگی‌های geo:rcc8eq ، geo:rcc8dc ، geo:rcc8ec ، geo:rcc8po ، geo: rcc8tppi ، geo:rcc8tpp ، geo:rcc8ntpp ، geo:rcc8ntppi ، الگوی SPARQL استفاده شود.
ما هر یک از الزامات 4، 5 و 6 را با هشت پرس و جو مختلف (یک مورد در هر ویژگی) آزمایش می کنیم تا شرایط فرعی را برای هر ویژگی مشخص شده آزمایش کنیم. از آنجایی که جستارهای مربوط به الزامات 28، 29 و 30 به استفاده از این ویژگی ها برای آزمایش انطباق سیستم با قوانین GeoSPARQL RIF [ 24 ] نیاز دارند، ما از رویکردی استفاده می کنیم که در آن RDF صریح مورد نیاز برای آزمایش الزامات 4، 5 و 6 سه برابر می شود. هندسه هایی که هنگام استفاده از ترتیب نتایج پرس و جو، بهترین نتیجه هستند. برای این منظور، پرس‌و‌جوهای نیازمندی‌های 4، 5 و 6 نتایج را مرتب می‌کنند و تنها نتیجه برتر را انتخاب می‌کنند تا اطمینان حاصل شود که وجود RDF سه‌گانه صریح و واقعی در مجموعه داده را آزمایش می‌کنند.
درخواست  7
پیاده سازی ها باید به کلاس RDFS امکان استفاده از geo:Geometry در الگوهای گراف SPARQL را بدهند.
درخواست  8
پیاده سازی ها باید به ویژگی های geo:hasGeometry و geo:hasDefaultGeometry اجازه دهند تا در الگوهای نمودار SPARQL استفاده شوند.
درخواست  9
پیاده‌سازی‌ها باید به ویژگی‌های geo:dimension اجازه دهند ،
geo:coordinateDimension ، geo:spatialDimension ، geo:isEmpty ، geo:isSimple ،
geo:hasSerialization برای استفاده در الگوهای نمودار SPARQL.
آزمایش‌های الزامات 7، 8 و 9 با انتخاب همه موجودیت‌های نوع geo:Geometry (مورد 7)، یا با انتخاب شی/مقدار هندسه A که با خاصیت مورد نظر مشخص می‌شود انجام می‌شود (شرایط 8 و 9). از آنجایی که الزام 8 دو ویژگی متمایز را مشخص می کند، و الزام 9 شش ویژگی از این قبیل را مشخص می کند، آزمایش های این نیازمندی ها به ترتیب شامل دو و شش پرس و جو هستند.
درخواست  10
تمام RDFS Literal از نوع geo:wktLiteral باید از یک URI اختیاری تشکیل شده باشد که سیستم مرجع مختصات را شناسایی می‌کند و به دنبال آن متن با ویژگی‌های ساده (WKT) یک مقدار هندسی را توصیف می‌کند. نمونه های معتبر جغرافیایی:wktLiteral با الحاق یک URI معتبر و مطلق همانطور که در [ 25 ] تعریف شده است، یک یا چند فاصله (نویسه Unicode U+0020) به عنوان جداکننده و یک رشته WKT همانطور که در Simple Features [ 5 ] تعریف شده است، تشکیل می شوند.
ما شرط 10 را با انتخاب و بررسی نوع داده یک WKT literal به درستی تعریف شده از مجموعه داده آزمایش می کنیم تا مطمئن شویم سیستم تحت آزمایش از فرمت مشخص شده WKT literal و نوع داده آنها پشتیبانی می کند.
درخواست  11
URI <https://www.opengis.net/def/crs/OGC/1.3/CRS84> باید به عنوان سیستم مرجع فضایی برای geo:wktLiterals در نظر گرفته شود که یک URI سیستم مرجع فضایی صریح را مشخص نمی کند.
ما الزام 11 را با تعریف دو هندسه در مجموعه داده آزمایش می کنیم: J و K، که نشان دهنده یک چند ضلعی هستند، اما هندسه K دارای یک WKT WKT با یک سیستم مرجع مشخص شده است، در حالی که هندسه J شامل URI نیست و فقط شامل چند ضلعی است. امتیاز در ارزش تحت اللفظی:
ج:
Polygon((-77.089005 38.913574,-77.029953 38.913574,
-77.029953 38.886321,-77.089005 38.886321,-77.089005 38.913574))
ک:
< https://www.opengis.net/def/crs/OGC/1.3/CRS84 >
Polygon((-77.089005 38.913574,-77.029953 38.913574,
-77.029953 38.886321,-77.089005 38.886321,-77.089005 38.913574))
سپس، آزمایش می کنیم که آیا این دو هندسه، یعنی حروف WKT متناظر آنها، از نظر هندسی برابر هستند یا خیر. این تضمین می کند که پاسخ صحیح به این تست به این معنی است که سیستم زیربنایی CRS84 را به عنوان سیستم مرجع فضایی پیش فرض برای WKT literals که به صراحت یکی را مشخص نمی کند، فرض می کند.
درخواست  12
تاپل های مختصات در geo:wktLiterals باید با استفاده از ترتیب محوری تعریف شده در سیستم مرجع فضایی مورد استفاده تفسیر شوند.
به منظور آزمایش شرط 12، دو هندسه جدید در مجموعه داده تعریف می کنیم: L و M که یک نقطه را نشان می دهند. هندسه L دارای لفظ WKT است که نقطه را با استفاده از سیستم مختصات CRS84 مشخص می کند، در حالی که هندسه M از سیستم مختصات EPSG:4326 استفاده می کند [ 26 ]. در مقایسه با یکدیگر، این سیستم های مختصات از ترتیب محور معکوس استفاده می کنند:
L:
< https://www.opengis.net/def/crs/OGC/1.3/CRS84 > Point(-88.38 31.95)
م:
< https://www.opengis.net/def/crs/EPSG/0/4326 > Point(31.95 -88.38)
برای اینکه آزمایش کنیم که آیا سیستم ترتیب محور را به درستی تفسیر می کند، یعنی با توجه به سیستم مرجع فضایی، آزمایش می کنیم که آیا دو هندسه بر اساس سیستم مورد آزمایش برابر هستند یا خیر.
درخواست  13
یک RDFS Literal خالی از نوع geo:wktLiteral باید به عنوان یک هندسه خالی تفسیر شود.
ما دو هندسه جدید، H و I را برای آزمایش شرط 13 تعریف می کنیم. هندسه H یک هندسه LineString را نشان می دهد که دارای یک حرف WKT است که یک رشته خالی است. هندسه I یک هندسه LineString خالی تعریف شده را نشان می دهد :
H:
من:
LineString EMPTY
علاوه بر این، مانند بسیاری از هندسه های دیگر، این دو هندسه نیز نمایش نقطه ای دارند. در مورد هندسه H، دوباره با یک مقدار خالی از WKT نشان داده می شود، در حالی که هندسه I یک هندسه نقطه خالی به صراحت در لفظ WKT خود دارد:
H:
من:
نقطه خالی
سپس آزمون از دو بخش تشکیل شده است، که در آن هر دو بررسی می کنند که آیا حرف WKT از H و I برابر است یا خیر. این دو بخش به آزمایش جداگانه تساوی هندسه های LineString و هندسه نقطه اشاره دارد. هر دو بخش باید درست باشند تا شرط 13 برآورده شود و بنابراین به طور کامل توسط معیار امتیازدهی شود.
درخواست  14
پیاده سازی ها باید به ویژگی RDF geo:asWKT اجازه دهند که در الگوهای گراف SPARQL استفاده شود.
ما شرط 14 را به سادگی با انتخاب مقدار geo:asWKT هندسه A و بررسی آن در برابر مقدار تحت اللفظی مورد انتظار آزمایش می کنیم.
درخواست  15
همه geo:gmlLiterals باید از یک عنصر معتبر از طرح GML تشکیل شده باشند که یک زیرنوع از GM_Object را همانطور که در [ 27 ] تعریف شده است، پیاده سازی می کند.
برای آزمایش شرط 15، همه مقادیر ویژگی geo:asGML را بدون توجه به موضوع RDF انتخاب می کنیم و بررسی می کنیم که آیا همه آنها دارای یک زیرنوع معتبر GM_Object در مقدار هستند و آیا نوع داده آن geo:gmlLiteral است یا خیر . سپس فهرست مرتب شده نتایج با پاسخ‌های مورد انتظار، که شامل تمام واژه‌های معتبر GML از مجموعه داده است، بررسی می‌شود.
درخواست  16
یک geo:gmlLiteral خالی باید به عنوان یک هندسه خالی تفسیر شود.
مشابه با الزام 13، ما انطباق با الزام 16 را با ارائه یک رشته خالی به عنوان مقدار تحت اللفظی GML در یک هندسه – هندسه H، و یک LineString خالی تعریف شده در یک GML Literal – هندسه I آزمایش می کنیم:
H:
من:
<LineString><posList></posList></LineString>
درست مانند شرط 13، در اینجا نیز از یک نمایش نقطه استفاده می کنیم . در مورد هندسه H، دوباره با یک مقدار خالی از حرف GML نشان داده می شود، در حالی که هندسه I یک هندسه نقطه خالی به صراحت در لفظ GML خود دارد:
H:
من:
<Point><pos></pos></Point>
آزمون مورد نیاز 16 نیز شامل دو بخش است که هر دو بررسی می کنند که آیا حروف GML H و I برابر هستند یا خیر. این دو بخش به آزمایش جداگانه تساوی هندسه های LineString و هندسه نقطه اشاره دارد. هر دو قسمت باید صحیح باشند تا شرط 16 برآورده شود.
درخواست  17
پیاده سازی ها باید نمایه های GML پشتیبانی شده را مستند کنند.
الزام 17 تنها الزام غیر فنی استاندارد GeoSPARQL است و بنابراین نمی توان آن را به طور خودکار بررسی و آزمایش کرد. این تنها شرطی است که توسط تست های معیار حذف شده است. برای ساده نگه داشتن آن، فرض می‌کنیم که همه پیاده‌سازی‌های GeoSPARQL این نیاز را برآورده می‌کنند و مستندات مناسبی را برای پروفایل‌های GML پشتیبانی‌شده ارائه می‌کنند، که به نظر ما یک فرض معقول است.
درخواست  18
پیاده سازی ها باید به ویژگی RDF geo:asGML اجازه دهند که در الگوهای گراف SPARQL استفاده شود.
مشابه شرط 14، شرط 18 را به سادگی با انتخاب مقدار geo:asGML هندسه A و بررسی آن در برابر مقدار تحت اللفظی مورد انتظار آزمایش می کنیم.
درخواست  19
پیاده سازی ها باید geof:distance ، geof:buffer ، geof:convexHull ،  geof:intersection ،  geof:union ،  geof:difference ، geof:symDifference ،
geof:envelope و geof:boundary به عنوان توابع گسترش SPARQL، مطابق با تعاریف توابع مربوطه (فاصله، بافر، محدبHull، تقاطع، تفاوت، symDifference، پاکت و مرز به ترتیب) در Simple Features [ 5 ].
برای تست شرط 19، از تست های جداگانه برای 9 تابع مورد نظر استفاده می کنیم، یعنی هر تابع را جداگانه بررسی می کنیم. برای آزمایش انطباق کامل هر تابع، ما سه آزمون فرعی را برای آنها اجرا می کنیم: (الف) ما تابع را با پارامترهای هندسی که به صورت حرف WKT بیان می شوند، آزمایش می کنیم، (ب) آن را با پارامترهای هندسه که به صورت حرف GML بیان می شوند، آزمایش می کنیم، و (ج) ما آن را با ترکیبی از WKT و GML آزمایش می کنیم. اگر تابع از یک پارامتر استفاده می کند، ما فقط از آزمون های فرعی (a) و (b) استفاده می کنیم. اگر از دو پارامتر استفاده می کند، از آزمون های فرعی (a)، (b) و (c) استفاده می کنیم، که در آن (c) شامل دو پرس و جو است که در آن WKT اولین و GML پارامتر دوم تابع است. WKT-GML)، و بالعکس (به عنوان GML-WKT مشخص می شود). با این کار، آزمون هر تابع از دو آزمون فرعی (WKT و GML) تشکیل شده است. یا از چهار آزمون فرعی (WKT-WKT، GML-GML، WKT-GML و GML-WKT). این تضمین می کند که امتیاز انطباق برای هر عملکرد به طور کامل بررسی می شود. جزئیات امتیازدهی برای این آزمون ها در ارائه شده استبخش 3.3 .
با این کار، کل آزمون مورد نیاز 19 شامل تست هایی برای 9 تابع است که هر کدام دارای دو یا چهار آزمون فرعی است که در مجموع 28 پرس و جو SPARQL را شامل می شود.
درخواست  20
پیاده سازی ها باید geof:getSRID را به عنوان یک تابع توسعه SPARQL پشتیبانی کنند.
ما نیاز 20 را با استفاده از تابع geof:getSRID در دو پرس‌وجو آزمایش می‌کنیم: یکی با WKT تحت اللفظی هندسه A، و دیگری با واژه GML هندسه A. در هر دو مورد، بررسی می‌کنیم که آیا سیستم به درستی https:// را برمی‌گرداند یا خیر. www.opengis.net/def/crs/OGC/1.3/CRS84 به عنوان پاسخ.
درخواست  21
پیاده‌سازی‌ها باید geof:relate را به‌عنوان یک تابع گسترش SPARQL، مطابق با عملگر مرتبط تعریف‌شده در Simple Features [ 5 ] پشتیبانی کنند.
برای آزمایش شرط 21، از یک عملگر مرتبط استفاده می کنیم که رابطه حاوی را نشان می دهد (به صورت T*****FF* در DE-9IM [ 28 ] بیان می شود)، و آن را روی هندسه های A و B آزمایش می کنیم، جایی که A حاوی B در مجموعه داده با توجه به اینکه تابع geof:relate از دو پارامتر استفاده می کند، چهار پرس و جو برای این تست وجود دارد: WKT-WKT، GML-GML، WKT-GML و GML-WKT.
درخواست  22
پیاده سازی ها باید geof:sfEquals ، geof:sfDisjoint ،
geof:sfمتقاطع ، geof:sfTouches ، geof:sfCrosses ، geof:sfWithin ،
geof:sfContains ، geof:sfOverlaps به عنوان توابع گسترش SPARQL، مطابق با الگوهای تقاطع DE-9IM مربوطه آنها [ 28 ]، همانطور که توسط Simple Features [ 5 ] تعریف شده است.
درخواست  23
پیاده سازی ها باید geof:ehEquals ، geof:ehDisjoint ، geof:ehMeet ،  geof:ehOverlap ،  geof:ehCovers ،  geof:ehCoveredBy ، geof:ehInside ،
geof:eh شامل توابع گسترش SPARQL، مطابق با الگوهای تقاطع DE-9IM متناظر آنها، همانطور که توسط Simple Features [ 5 ] تعریف شده است.
درخواست  24
پیاده سازی ها باید geof:rcc8eq ، geof:rcc8dc ، geof:rcc8ec ،
geof:rcc8tppi ، geof:rcc8tppi ، geof:rcc8tpp ، geof:rcc8ntpp ، geof:rcc8ntppi به عنوان توابع گسترش SPARQL، مطابق با الگوهای تقاطع DE-9IM متناظر آنها [ 28 ]، همانطور که توسط [ 5 ] تعریف شده است.
ما الزامات 22، 23 و 24 را با اعمال مجموعه ای جداگانه از آزمون ها برای هر یک از بیست و چهار عملکرد مشخص شده آزمایش می کنیم. هر تابع با استفاده از چهار پرس و جو آزمایش می شود: یکی با دو حرف WKT (WKT-WKT)، یکی با دو حرف GML (GML-GML)، و دو با ترکیبی از WKT و GML literal (WKT-GML و GML-WKT) . هر یک از پرس و جوها آزمایش می کند که آیا رابطه پیاده سازی شده توسط تابع آزمایش شده برای هندسه های استفاده شده از مجموعه داده صحیح است یا خیر، و هر یک از آنها یک پاسخ xsd:boolean برمی گرداند . هندسه های مورد استفاده برای تست های هر تابع به دقت انتخاب می شوند تا ارزیابی روشنی از پشتیبانی و اجرای صحیح تابع در سیستم تحت آزمایش ارائه شود.
درخواست  25
تطبیق الگوی نمودار پایه باید از معنایی استفاده کند که توسط رژیم مستلزم RDFS [ 29 ] تعریف شده است.
برای آزمایش الزامات 25، 26 و 27، ما از پرس و جوهایی استفاده می کنیم که سیستم را ملزم می کند هر دو سه گانه RDF تحقق یافته و همچنین سه گانه RDF استنباط شده را بر اساس ویژگی های هر نیاز انتخاب کند.
بنابراین، ما نیاز 25 را با استفاده از سه پرس‌وجو جداگانه آزمایش می‌کنیم: اولی همه نمونه‌های کلاس geo:Feature را انتخاب می‌کند ، جایی که انتظار داریم سیستم نمونه‌هایی از کلاس‌های فرعی کلاس را نیز انتخاب کند، به عنوان مثال،  my:PlaceOfInterest ; مورد دوم و سوم همه نمونه‌ها را با ویژگی‌های geo:hasGeometry و geo:hasDefaultGeometry انتخاب می‌کنند، اما انتظار می‌رود نتایج شامل موجودیت‌هایی باشد که از ویژگی‌های فرعی این ویژگی‌ها نیز استفاده می‌کنند، به عنوان مثال  my:hasExactGeometry .
درخواست  26
پیاده‌سازی‌ها باید از الگوهای نموداری شامل عباراتی از سلسله‌مراتب کلاس RDFS/OWL [ 30 ] از انواع هندسه مطابق با نمونه موجود در نسخه مشخص شده Simple Features [ 5 ] پشتیبانی کنند.
برای شرط 26، ما از دو پرس‌وجو جداگانه استفاده می‌کنیم: آنها به ترتیب همه نمونه‌های sf:Surface و sf:Curve را انتخاب می‌کنند، اما انتظار داریم که نتایج شامل همه نمونه‌های زیر کلاس‌های آنها نیز باشد، مانند sf:LineString و sf:Polygon .
درخواست  27
پیاده‌سازی‌ها باید از الگوهای گراف شامل عباراتی از سلسله‌مراتب کلاس RDFS/OWL از انواع هندسه سازگار با طرح GML پشتیبانی کنند که GM_Object را با استفاده از نسخه مشخص شده GML [ 27 ] پیاده‌سازی می‌کند.
برای آزمایش شرط 27، از یک پرس و جو استفاده می کنیم که همه نمونه های gml:Surface را انتخاب می کند ، اما نتایج مورد انتظار شامل تمام نمونه های زیر کلاس آن، gml:LineString می شود.
درخواست  28
تطبیق الگوی نمودار اصلی باید از معنایی تعریف شده توسط RIF Core Entailment Regime [W3C SPARQL Entailment] برای قوانین RIF [ 31 ] geor:sfEquals ، geor:sfDisjoint ، geor:sfIntersects ، geor:sfTouches :rossf ، استفاده کند .
geor:sfWithin ، geor:sfContains ، geor:sfOverlaps .
درخواست  29
تطبیق الگوی نمودار اصلی باید از معنایی تعریف شده توسط RIF Core Entailment Regime [W3C SPARQL Entailment] برای قوانین RIF [ 31 ] geor:ehEquals ، geor:ehDisjoint ، geor:ehMeet ، geor:ehOverlap ، استفاده کند.
geor:ehCovers , geor:ehCoveredBy , geor:ehInside , geor:ehContains .
درخواست  30
تطبیق الگوی نمودار اصلی باید از معنایی تعریف شده توسط RIF Core Entailment Regime [W3C SPARQL Entailment] برای قوانین RIF [ 31 ] geor:rcc8eq ، geor:rcc8dc ، geor:rcc8ec ، geor:rcc8po، geor:rcc8po ، geor: pppir استفاده کند .
geor:rcc8tpp ، geor:rcc8ntpp ، geor:rcc8ntppi .
ما الزامات 28، 29 و 30 را با هشت پرس‌و‌جوی مختلف آزمایش می‌کنیم تا زیر نیازمندی‌های هر قانون مشخص شده را آزمایش کنیم. پرس و جوهایی که در اینجا استفاده می شوند مشابه پرس و جوهای الزامات 4، 5 و 6 هستند، با این تفاوت که آزمون های نیازمندی های 28، 29 و 30 نیازمند انتخاب سه گانه RDF تحقق یافته و سه گانه RDF استنتاج شده برای پاسخ پرس و جو هستند. برای اطمینان از اینکه سیستم همه چنین موجوداتی را انتخاب می‌کند و بنابراین از معنایی تعریف شده در رژیم مستلزم هسته RIF برای قوانین RIF پشتیبانی می‌کند، آزمایش‌ها نیاز به لیست مرتبی از موجودیت‌هایی دارند که درخواست پرس و جو را انجام می‌دهند.

3.3. نتایج محک

معیار می تواند آزمایش کند که آیا سیستم محک شده پاسخ صحیح یا نادرستی را برای هر یک از پرس و جوهای 206 معیار ارائه می دهد. به منظور تبدیل این نتایج به یک نتیجه کلی، دو نتیجه معیار را از یک آزمایش مشخص محاسبه می‌کنیم:
  • پاسخ‌های صحیح : تعداد پاسخ‌های صحیح از تمام جستارهای GeoSPARQL، یعنی تست‌ها.
  • درصد انطباق GeoSPARQL : درصد انطباق با الزامات استاندارد GeoSPARQL.
اولی ساده است—تعداد پاسخ های صحیحی است که سیستم ارائه کرده است، از بین 206 پرسش آزمایشی. مورد دوم از منظر 30 الزامات محاسبه شده و انطباق کلی سیستم محک شده با استاندارد GeoSPARQL را اندازه گیری می کند. این مقدار نیازهای پشتیبانی شده سیستم را از 30 مورد نیاز مشخص شده اندازه گیری می کند، که در آن وزن هر نیاز به طور یکنواخت توزیع شده است، یعنی هر نیاز 3.33٪ به نتیجه کل کمک می کند.
اگر یک نیاز شامل چندین پرسش زیر آزمون باشد، 3.33٪ آن به طور یکنواخت بین آنها توزیع می شود. بنابراین، برای مثال، هر یک از هشت شرط فرعی شرط 4 با 12.5 درصد به نمره آزمون والد کمک می کند، یعنی با 0.4167 درصد (3.33 درصد × 12.5 درصد) به کل امتیاز درصد انطباق معیار. این بدان معنی است که یک نیاز واحد از استاندارد GeoSPARQL می تواند به طور کامل پشتیبانی شود، تا حدی پشتیبانی شود یا اصلاً پشتیبانی نشود.
تنها استثناهای این قاعده توزیع یکنواخت وزن‌ها بین آزمون‌ها در یک سطح، عبارت‌های آزمایش فرعی هستند که توابع GeoSPARQL را با سریال‌سازی‌های مختلف لفظ به عنوان پارامتر، یعنی الزامات 19-24 آزمایش می‌کنند. وقتی تابعی را برای انطباق با استاندارد آزمایش می کنیم در حالی که از (الف) حرف فقط WKT، (ب) حرف فقط GML و (ج) ترکیبی از حرف WKT و GML استفاده می کنیم، امتیاز به طور یکنواخت بین این سه گروه منطقی توزیع می شود. هر کدام با 33.33 درصد در نمره آزمون والد مشارکت دارند. با این حال، (c) عملاً با استفاده از دو پرس‌وجو آزمایش می‌شود: یکی که در آن WKT اولین پارامتر است و GML دومین پارامتر تابع (که با WKT-GML مشخص می‌شود) و بالعکس (با GML-WKT مشخص می‌شود). این دو پرس و جو از نظر فنی هر کدام با 16.67٪ به نمره آزمون والد کمک می کنند. به طوری که سهم کل از گروه منطقی (ج) 33.33 درصد باقی می ماند. با این، وزن فنی خود پرس و جوها 33.33 درصد برای پرس و جو فقط WKT، 33.33 درصد برای پرس و جو فقط GML، 16.67 درصد برای پرس و جو WKT-GML و 16.67 درصد برای پرس و جو GML-WKT است. از نظر فنی، در سطح پرس و جو، این یک استثنا از قاعده توزیع یکنواختی است که ما تمرین می کنیم، اما، به طور منطقی، در سطح گروهی، همچنان پابرجاست.
با توجه به اینکه شرط 17 غیرفنی است، و بنابراین به عنوان بخشی از معیار آزمایش نشده است، هر سیستم 3.33 درصد امتیاز خود را به طور خودکار دریافت می کند، زمانی که حداقل یک پاسخ صحیح به تست های معیار ارائه دهد.

3.4. ملاحظات معیار

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

3.4.1. اصطلاحات هندسه

بسیاری از نتایج توابع پرس و جو تعریف شده در استاندارد GeoSPARQL یک ogc:geomLiteral را به دنبال تعریف استاندارد GeoSPARQL برمی‌گردانند. این بدان معناست که طبق استاندارد، تابعی مانند:
  •       geof:boundary(ogc:geomLiteral):ogc:geomLiteral
ممکن است WKT، GML 2.0 یا GML 3.2 را به عنوان آرگومان در نظر بگیرد، و ممکن است WKT، GML 2.0 یا GML 3.2 را به عنوان یک آرگومان برگرداند. مجموعه داده‌ای که ما برای معیار خود استفاده می‌کنیم شامل حروف فرمت‌شده WKT و GML 3.2 است. با این حال، ما پاسخ‌های پرس و جو را در WKT، GML 2.0 و GML 3.2 ارائه می‌کنیم تا از تمام نتایج ممکن از یک سیستم آزمایش شده توسط معیار پشتیبانی کند.
تصمیم به گنجاندن تنها GML 3.2 و نه GML 2.0 در مجموعه داده ما اتخاذ شد زیرا GML 2.0 عملاً توسط GML 3.2 جایگزین شده است. GML 2.0 حتی به عنوان یک گزینه صادراتی در نرم افزار GIS فعلی مانند QGIS پشتیبانی نمی شود. علاوه بر این، در همه سیستم‌ها، ما محک زدیم که تنها نوع GML که پشتیبانی می‌شود GML 3.2 است.

3.4.2. تغییرات بین سریال سازی های تحت اللفظی

در یک نوع تحت اللفظی، نمایش‌های معادل معنایی متفاوتی از هندسه ممکن است. سریال‌سازی‌های WKT ممکن است شامل یک CRS URI باشد، اما ممکن است آن را نیز حذف کنند (اگر وجود نداشته باشد، WGS84 CRS فرض می‌شود)، و ممکن است در مقدار و موقعیت فضاهای خالی متفاوت باشند. کلمات GML ممکن است در ترتیب صفات و تعریف فضاهای نام متفاوت باشند. برای انعطاف پذیری در مورد این تغییرات، قبل از مقایسه نتایج سیستم آزمایش شده با پاسخ مورد انتظار، یک فرآیند عادی سازی را اعمال می کنیم. حروف WKT کوتاه می شوند و فضاهای سفید آنها حذف می شوند و حروف GML با تعاریف فضای نام نرمال شده به XML متعارف تبدیل می شوند.

3.4.3. پاسخ های جایگزین

استاندارد GeoSPARQL نتایج توابع GeoSPARQL را به صورت تعریف می کند
ogc:geomLiteral مقادیری را دارد اما مشخص نمی کند که کدام نوع هندسه باید این حرف ها را سریال کنند. بنابراین، توابع ممکن است نه تنها نتایج را در انواع مختلف تحت اللفظی، بلکه در نمایش هندسه های مختلف حتی در یک سریال سازی تحت اللفظی یکسان برگردانند. یک مثال تابع geof:boundary است که می تواند یک sf:LinearRing یا یک هندسه sf:Polygon را در نتیجه برگرداند. حتی مقادیر بازگشتی فرضی ساده ای مانند xsd:boolean ممکن است به صورت حرف xsd:boolean با مقدار true و false یا 1 و 0 نمایش داده شوند.
به منظور مقابله با این سناریوها، ما پاسخ های پرس و جوی جایگزین را برای هر یک از احتمالات فوق تعریف می کنیم. این بدان معناست که هر آزمون شامل یک پرسش واحد است که برای سیستم تحت آزمایش صادر می‌شود، و مجموعه‌ای از چندین پاسخ صحیح جایگزین، که از نظر منطقی معادل هستند، اما ممکن است از نظر فنی در سریال‌های مختلف نمایش داده شوند.

3.5. پیاده سازی

ما این معیار را به عنوان معیاری برای پلتفرم HOBBIT (نمونه عمومی پلتفرم HOBBIT: https://master.project-hobbit.eu (دسترسی در 22 مه 2021) پیاده‌سازی کرده‌ایم)، که برای محک زدن کل‌نگر داده‌های پیوندی بزرگ در نظر گرفته شده است [ 17 ]]. پلتفرم HOBBIT به کاربران این امکان را می دهد که از یک طرف معیارها را تعریف و اجرا کنند و از طرف دیگر سیستم های سه گانه را ارائه و اضافه کنند. یک کاربر می‌تواند با انتخاب معیار مورد نظر و سیستم سه‌گانه مورد نظر برای آزمایش، آزمایشی را روی پلتفرم اجرا کند. سپس پلتفرم معیار را به عنوان مجموعه‌ای از کانتینرهای Docker بارگیری می‌کند (کنترل‌کننده معیار، تولیدکننده داده، تولیدکننده وظیفه و ماژول ارزیابی)، سیستم را به‌عنوان یک ظرف Docker بارگیری می‌کند (سیستم محک‌گذاری‌شده)، و سپس معیار را بر اساس منطق آن اجرا می‌کند، برنامه‌ریزی شده در کنترل کننده ( شکل 2 ). نتایج هر آزمایش در پلتفرم ذخیره می شود و به صورت عمومی در وب در دسترس قرار می گیرد.
در مورد ما، معیار انطباق GeoSPARQL ابتدا مجموعه داده را در سیستم محک بارگذاری می کند، سپس تمام پرس و جوهای آزمایشی را می خواند و آنها را برای اجرا به سیستم محک می فرستد. ماژول ارزیابی تک پاسخ مورد انتظار یا مجموعه ای از پاسخ های جایگزین مورد انتظار را برای هر پرس و جو می خواند، و مقایسه می کند که آیا سیستم محک، پاسخ صحیح یا نادرست را برمی گرداند و نتیجه را در فروشگاه ارزیابی ذخیره می کند. پس از انجام تمام تست‌ها، ماژول ارزیابی دو نتیجه خلاصه را محاسبه می‌کند: (1) تعداد پاسخ‌های صحیح، از بین تمام تست‌های ممکن، و (2) درصد انطباق با الزامات استاندارد GeoSPARQL، همانطور که در بخش 3.3 توضیح داده شد. .
ما تصمیم گرفتیم از پلتفرم HOBBIT برای معیار خود به دلیل ماهیت پلاگین آن استفاده کنیم، که در آن سیستم های اضافی می توانند توسط کاربران علاقه مند اضافه شوند، که سپس می توانند آزمایشی را با معیار روی سیستم خود اجرا کنند. کاربر همچنین می‌تواند معیار انطباق GeoSPARQL ما را بر روی هر سیستم سه‌گانه‌ای که از قبل در پلتفرم موجود است اجرا کند. علاوه بر این، ماهیت عمومی پلتفرم به شفافیت و تکرارپذیری بیشتر نتایج هر معیار، از جمله معیار انطباق GeoSPARQL ما اجازه می دهد.

4. راه اندازی آزمایشی

به منظور نشان دادن قابلیت استفاده و سودمندی معیار انطباق GeoSPARQL، ما تصمیم گرفتیم تعدادی آزمایش را روی برخی از متداول ترین فروشگاه های سه گانه اجرا کنیم. مجموعه سه گانه انتخاب شده در جدول 1 نشان داده شده است .
برای هر آزمایش، یک آداپتور سیستم در یک نمونه پلت فرم عمومی HOBBIT، و همچنین در مخزن HOBBIT GitLab (HOBBIT Platform Triplestores: https://git.project-hobbit.eu/triplestores (در 22 مه (در تاریخ 22 مه قابل دسترسی است) ایجاد و منتشر شده است. 2021)). این امکان بازتولید آزمایش ها و نتایج را فراهم می کند. هر نسخه triplestore از جدول 1جدیدترین نسخه پایدار موجود از پیاده سازی در زمان آزمایش بود. اگر یک فروشگاه تریپل به یک فایل مجوز نیاز دارد (به عنوان مثال، Stardog، TriplyDB)، آزمایشات آن تنها تا زمانی که مجوز تعبیه شده سیستم یکپارچه معتبر باشد، روی پلتفرم HOBBIT قابل تکرار هستند. هنگامی که مجوز منقضی می شود، هر شخص علاقه مند باید نمونه خود را از سیستم به پلتفرم ارسال کند تا آن را آزمایش کند. برای هر یک از فروشگاه‌های سه‌گانه‌ای که آزمایش شده‌اند، یک پیاده‌سازی آداپتور سیستم ایجاد شده است که پیکربندی اولیه فروشگاه سه‌گانه را مدیریت می‌کند، به‌عنوان مثال، راه‌اندازی یک مخزن که حاوی داده‌هایی است که باید آزمایش شوند، پشتیبانی از پرس و جوی مکانی را فعال می‌کند، و غیره. در صورت امکان، این پیاده‌سازی آداپتور در یک تصویر مشترک Docker به پیاده‌سازی triplestore اضافه شد یا دو تصویر Docker – پیاده‌سازی آداپتور و پیاده‌سازی triplestore – برای آزمایش ایجاد شدند. لازم به ذکر است که همه تریپل استورهای فوق الذکر ادعای پشتیبانی از GeoSPARQL را ندارند. در واقع Blazegraph و Jena Fuseki از GeoSPARQL پشتیبانی نمی کنند. ما آنها را در آزمایش‌های خود گنجانده‌ایم تا نشان دهیم کدام الزامات GeoSPARQL قبلاً توسط یک پیاده‌سازی غیر GeoSPARQL از یک فروشگاه سه‌گانه RDF پشتیبانی می‌شود که حداقل از زبان جستجوی SPARQL پشتیبانی می‌کند.

5. نتایج و بحث

5.1. نتایج کلی

نتایج آزمایش‌ها با معیار ما و سیستم‌های فهرست‌شده در جدول 1 در جدول 2 و شکل 3 نشان داده شده است و به‌صورت آنلاین در پلتفرم HOBBIT در دسترس است (نتایج در پلت فرم HOBBIT: https://master.project-hobbit. EU/آزمایشات/1612476122572،16124777003063،1612476116049،1625421291667،161247750016416416444451051105121212121212121212121212121212121212121212121212121212121212121212121212121212121212128(دسترسی در 8 ژوئیه 2021)). آنها نشان می دهند که هیچ یک از این راه حل های پرکاربرد ذخیره سازی RDF به طور کامل با استاندارد GeoSPARQL مطابقت ندارند. جدای از آن، می‌توان به این اشاره کرد که یکی از آنها با امتیاز انطباق GeoSPARQL به طور قابل توجهی بهتر از سایرین متمایز است و به طور کلی، چهار مورد برتر از بقیه متمایز هستند. سه طبقه در موقعیت های 5-8 نتیجه تقریباً یکسانی دارند.
برای اینکه دلایل این تغییرات را دقیق تر ببینیم، نتایج انطباق را به شش برنامه افزودنی تعریف شده در استاندارد GeoSPARQL تقسیم بندی کردیم. این نتایج در جدول 3 نشان داده شده است. همانطور که از این جدول می بینیم، فروشگاه های سه گانه در موقعیت های 5-8 به دلیل نشان دادن انطباق کامل با پسوندهای CORE، TOP و RDFSE معیار GeoSPARQL، نتیجه یکسانی دارند، اما نه با سایر برنامه های افزودنی. دلیل اینکه تقریباً همه فروشگاه‌های سه‌گانه محک‌شده با CORE، TOP و RDFSE مطابقت دارند، ساده است: این الزامات به گونه‌ای طراحی شده‌اند که توسط اکثر راه‌حل‌های ذخیره‌سازی سازگار با RDF و SPARQL «خارج از جعبه» برآورده می‌شوند. آنها به استفاده از کلاس های خاص (CORE) و ویژگی ها (TOP) در الگوهای پرس و جو SPARQL، و همچنین استدلال RDFS (RDFSE) اشاره می کنند، که ویژگی هایی هستند که امروزه در اکثر فروشگاه های سه گانه پشتیبانی می شوند. از آنجایی که استدلال RDFS در نسخه Marmotta که ما بنچمارک کردیم فعال نشده است، هیچ انطباق با RDFSE ندارد، بنابراین امتیاز آن فقط از انطباق آن با CORE و TOP بدست می آید.
سه سیستم پایینی صراحتاً با GeoSPARQL سازگار نیستند، اما ما آنها را در آزمایش‌های خود به عنوان آزمایش‌های پایه گنجانده‌ایم. همانطور که می بینیم، همه آنها سازگاری با دو یا سه پسوند استاندارد GeoSPARQL را نشان دادند ( جدول 3 )، و امتیاز 56.67% یا 46.67% از امتیاز انطباق GeoSPARQL را کسب کردند ( جدول 2 ). با این حال، این بدان معنا نیست که امتیاز معیار باید از 56.67٪ یا 46.67٪ شروع شود، زیرا یک سیستم ذخیره سازی RDF معیار ممکن است در این آزمایش ها نیز شکست بخورد.

5.2. بحث در مورد نتایج هر Triplestore

ابتدا، ما فروشگاه‌های سه‌گانه RDF را که ادعا می‌کنند از GeoSPARQL پشتیبانی می‌کنند، آزمایش کردیم. ما می‌خواستیم بررسی کنیم که مطابقت آنها با استاندارد GeoSPARQL چقدر است، و این لیست شامل: GeoSPARQL Fuseki، GraphDB، Virtuoso، TriplyDB، RDF4J و Stardog است.
GeoSPARQL Fuseki سه‌گانه‌ای است که بالاترین امتیاز انطباق GeoSPARQL را در آزمایش‌های ما دارد. این تنها سیستمی است که از GML و WKT کامل پشتیبانی می کند و تنها سیستمی است که تمام پسوندهای GeoSPARQL را به طور کامل پیاده سازی می کند ( جدول 3 ). با این حال، GeoSPARQL Fuseki در بسیاری از توابع تحت پوشش پسوند بازنویسی پرس و جو و در چند توابع تحت پوشش پسوند هندسه نتایج نادرستی ایجاد کرد. علاوه بر این، درست مانند سایر فروشگاه‌های سه‌گانه‌ای که آزمایش کردیم، GeoSPARQL Fuseki در مدیریت WKT خالی و GML خالی نیست.
GraphDB یک پیاده سازی کامل از همه به جز پسوند بازنویسی پرس و جو را فراهم می کند. با این حال، GraphDB فقط می تواند WKT literals را مدیریت کند اما GML literals را نمی تواند انجام دهد. این منجر به نمره قابل ملاحظه‌ای پایین‌تر در معیار ما می‌شود، زیرا بسیاری از پرس‌و‌جوها برای اجرا به یک GML تحت اللفظی به عنوان ورودی یا ترکیبی از یک GML و یک WKT برای اجرا نیاز دارند. اکثر توابع با حروف فقط WKT در تست های الحاقی GEOEXT و GTOP نتایج صحیحی را تولید کردند.
Virtuoso از WKT literals پشتیبانی می کند، اما از GML literals پشتیبانی نمی کند. مشابه GraphDB، اجرای کامل را برای تمام پسوندهای GeoSPARQL، به جز پسوند بازنویسی پرس و جو، فراهم می کند. با این حال، یک مشکل اضافی دارد: حتی اگر نتایج منطقی درستی را برای آزمایش‌های توابع در نیاز 19 (بخشی از پسوند GEOEXT) برمی‌گرداند، لفظ‌ها از WKT به یک نوع تحت اللفظی داخلی که مختص Virtuoso است تبدیل می‌شوند. این باعث عدم تطابق بین پاسخ ارائه شده و مورد انتظار می شود و امتیاز معیار Virtuoso را کاهش می دهد.
TriplyDB یک راه حل داده پیوندی است که از Virtuoso Open-Source و Jena Fuseki برای ذخیره داده های RDF در back-end استفاده می کند. ما در آزمایشات خود از نسخه مبتنی بر Virtuoso استفاده کردیم. با توجه به اینکه TriplyDB داده‌ها را در حین ورود پیش پردازش می‌کند، درخواست‌های SPARQL را قبل از اجرا پردازش می‌کند، و نتایج SPARQL را پس از اجرا پس پردازش می‌کند، ممکن است نتایج متفاوتی ارائه دهد و رفتار متفاوتی را در مقایسه با استفاده از Virtuoso و Fuseki به تنهایی نشان دهد. با این حال، در مورد بنچمارک ما، TriplyDB 3.5 دقیقاً امتیازی مشابه Virtuoso Open-Source 7.2 کسب کرد، به این معنی که پشتیبانی جغرافیایی TriplyDB با Virtuoso یکسان است.
RDF4J triplestore تمام توابع GeoSPARQL پسوند GEOEXT و پسوند GTOP را برای WKT literals پیاده سازی می کند. با این حال، RDF4J تقریباً در تمام آزمایش‌های GeoSPARQL از این برنامه‌های افزودنی شکست خورده است، زیرا از URI‌های CRS در حروف WKT پشتیبانی نمی‌کند. در حالی که استاندارد GeoSPARQL تصدیق می کند که ادغام URI های CRS در WKT Literals اختیاری است، آنها در موارد مختلف استفاده می شوند، به ویژه در مقامات جغرافیایی، و ما انتظار داریم که در هر سه فروشگاهی که ادعا می کند از GeoSPARQL پشتیبانی می کند، پشتیبانی شوند. بنابراین، کلمات WKT با URI های CRS صریح در اکثر تست های معیار گنجانده شده اند. علاوه بر این، RDF4J فاقد پشتیبانی از GML literals و پسوند بازنویسی query است.
Stardog triplestore یک پیاده‌سازی را ارائه می‌کند که WKT را تحت پوشش قرار می‌دهد و پنج عملکرد جغرافیایی را پیاده‌سازی می‌کند که مشابه توابع GeoSPARQL هستند، اما کاملاً سازگار نیستند. به طور دقیق تر، از بین پنج عملکرد جغرافیایی آنها ( geof:within ، geof:area ، geof:nearby ، geof:distance و geof:relate )، فقط geof:distanceتابع از امضای تابع GeoSPARQL با همان URI پیروی می کند. با این حال، آزمایش‌های ما برای این تابع شامل حروف WKT با URI‌های واضح CRS است که Stardog از آن‌ها پشتیبانی نمی‌کند، بنابراین تست این تابع با شکست مواجه می‌شود. تست‌های سایر توابع یا به این دلیل که توابع با آن URIها در استاندارد GeoSPARQL وجود ندارند یا به دلیل عدم تطابق امضای تابع ناموفق هستند. بنابراین، Stardog فقط در آزمون هایی که پسوندهای CORE، TOP و RDFSE را پوشش می دهد، امتیاز می گیرد.
در مرحله بعد، ما تریپل استورهایی را آزمایش کردیم که ادعای پشتیبانی از GeoSPARQL را ندارند، اما ادعای پشتیبانی از سایر برنامه‌های افزودنی جغرافیایی را دارند. ما انتظار داشتیم که آنها پشتیبانی کاملی از برنامه های افزودنی GeoSPARQL CORE، TOP و RDFSE ارائه دهند که به اجرای اپراتورهای مکانی اضافی متکی نیستند. بنابراین آنها به عنوان آزمون های پایه برای رویکرد ما هستند و این لیست شامل: Blazegraph، Jena Fuseki، Apache Marmotta و پارلمان است.
Blazegraph برخی از توابع فضایی غیر GeoSPARQL را در پسوند جستجوی GeoSpatial خود پشتیبانی می کند ( https://github.com/blazegraph/database/wiki/GeoSpatial (در 22 مه 2021 قابل دسترسی است). این برنامه افزودنی امکان تعریف نقاط را از طریق WKT literals فراهم می کند، اما در غیر این صورت با GeoSPARQL سازگار نیست. بنابراین Blazegraph همانطور که انتظار می رفت در تست های GEOEXT، GTOP و QRW شکست خورد.
Jena Fuseki شامل یک پسوند فضایی سفارشی شده Jena Spatial ( https://jena.apache.org/documentation/query/spatial-query.html (دسترسی در 22 مه 2021)) است که قرار است با پیاده سازی GeoSPARQL Fuseki که آزمایش کردیم جایگزین شود. . Jena Fuseki می تواند با WKT literals کنار بیاید و مجموعه ای سفارشی از توابع را تعریف کند که هیچ کدام با امضاهای تابع تعریف شده در استاندارد GeoSPARQL مطابقت ندارد. از این رو، Jena Fuseki فقط در پسوندهای CORE، GTOP و RDFSE امتیاز کامل دریافت می کند.
Apache Marmotta یک پیاده‌سازی GeoSPARQL دارد که در پروژه تابستانی کد Google ایجاد شده است ( https://marmotta.apache.org/kiwi/geosparql.html (در 22 مه 2021 قابل دسترسی است). در زمان آزمایش، افزونه در آخرین نسخه پایدار این فروشگاه سه‌گانه گنجانده نشده بود. بنابراین، نسخه ای که ما آزمایش کردیم با GeoSPARQL سازگار نبود. حتی با وجود اینکه Marmotta از استدلال RDFS پشتیبانی می‌کند، ما در تلاش‌هایمان برای فعال کردن آن برای نمونه‌ای که با آن کار می‌کردیم ناموفق بودیم، بنابراین حتی اگر انتظار داشتیم که آن را به همان امتیازی که فروشگاه‌های سه‌گانه دیگر که GeoSPARQL را پشتیبانی نمی‌کنند، به دست آورد، اما فقط به عنوان منطبق با CORE و TOP.
در نهایت، ما می خواهیم اذعان کنیم که ما تریپل استور 2.7.10 را نیز آزمایش کردیم. پارلمان حروف WKT و GML را قبل از اضافه شدن به نمودار اعتبار سنجی می کند و در صورت بروز خطای اعتبارسنجی، مجموعه داده را بارگیری نمی کند. در آزمایش ما، پارلمان نتوانست حرف های GML 3.2 و حروف خالی WKT را تجزیه کند. در نتیجه، مجموعه داده معیار بارگیری نشد، و ما نمی‌توانیم آزمایش را با triplestore پارلمان انجام دهیم.

6. محدودیت های معیار

معیار انطباق GeoSPARQL هر تابع GeoSPARQL را با هر نوع هندسه موجود و ترکیبات آنها آزمایش نمی کند. ما این کار را با سریال‌سازی‌های WKT و GML انجام می‌دهیم، اما نه انواع هندسه متفاوت. دلیل این امر این است که تعداد ترکیب‌های ممکن هندسه به طرز غیرقابل تصوری بسیار زیاد و مزیت آزمایش آنها بسیار کم است. WKT 27 نوع هندسه را تعریف می کند، GML حداقل به همان تعداد که باید هم در GML 2.0 و هم در انواع GML 3.2 آنها در نظر گرفته شود تا کامل شود، تعریف می کند. در عوض، مجموعه داده ما از Points ، LineStrings و Polygons تشکیل شده استکه پرکاربردترین انواع هندسه هستند. با این، ما معتقدیم که تعادل خوبی بین معیار بسیار گسترده و دقیق بودن کافی در اندازه‌گیری انطباق سیستم با استاندارد GeoSPARQL ایجاد می‌کنیم.
با توجه به امتیاز درصد انطباق GeoSPARQL: همانطور که قبلاً بیان کردیم، این امتیاز تعداد نیازهای پشتیبانی شده سیستم را از 30 مورد نیاز مشخص شده اندازه گیری می کند، که در آن وزن هر نیاز به طور یکنواخت توزیع شده است، یعنی هر نیاز 3.33٪ به نتیجه کل دلیل اینکه ما تصمیم گرفتیم از توزیع یکنواخت به جای اختصاص وزن های خاص نیاز استفاده کنیم این است که اضافه کردن وزن به نیازمندی های مختلف تا حدودی خودسرانه خواهد بود. با توجه به اینکه نویسندگان استاندارد GeoSPARQL هیچ گونه اهمیت متغیری را بین الزامات مختلف مورد بحث قرار نداده‌اند، به ما سیگنالی می‌دهد که حداقل در حال حاضر، باید آنها را به یک اندازه مهم در نظر بگیریم. در حالی که عملا اینطور نیست،

7. نتیجه گیری

این مقاله یک معیار انطباق GeoSPARQL را معرفی می‌کند که هدف آن اندازه‌گیری میزان مطابقت یک فروشگاه سه‌گانه RDF با الزامات مشخص‌شده در استاندارد GeoSPARQL است. با انجام یک سری آزمایش برای هر نیاز، معیار می تواند ارزیابی کند که آیا سیستم محک شده به طور کامل یا جزئی از یک نیاز معین پشتیبانی می کند یا نه. نتایج حاصل از 206 آزمایش فردی به یک درصد انطباق GeoSPARQL تبدیل می‌شوند که هدف آن ارائه معیاری از میزان الزامات تحت پوشش سیستم محک است.
به منظور نشان دادن سودمندی و قابلیت استفاده از معیار، به عنوان بخشی از پلتفرم HOBBIT، ما یک سری آزمایش را با هشت مورد از متداول‌ترین فروشگاه‌های سه‌گانه RDF انجام دادیم. نتایج کلی نشان می دهد که پشتیبانی GeoSPARQL بین سه فروشگاه های آزمایش شده بسیار متفاوت است. در حالی که برنامه‌های افزودنی CORE، TOP و RDFSE تقریباً در هر تریپل استور پشتیبانی می‌شوند – زیرا آنها فقط به عملکردهای SPARQL و RDFS وابسته هستند و مختص GeoSPARQL نیستند – افزونه‌های GEOEXT و GTOP سطوح مختلف پیاده‌سازی را نشان می‌دهند. برخی از فروشگاه‌های سه‌گانه، مانند GraphDB یا Virtuoso، فقط از WKT literals پشتیبانی می‌کنند، RDF4J فقط از WKT بدون URI‌های CRS پشتیبانی می‌کند و تنها GeoSPARQL-Jena پیاده‌سازی کامل با GeoSPARQL از همه توابع با سازگاری GML و WKT را ارائه می‌دهد.
در نتیجه، می‌توانیم ببینیم که استاندارد GeoSPARQL، تقریباً نه سال پس از انتشار اولیه‌اش، اغلب تنها تا حدی توسط فروشندگان اصلی فروشگاه‌های سه‌گانه پشتیبانی می‌شود. ما امیدواریم که سهم معیار GeoSPARQL ما بتواند به ایجاد انگیزه در اجراکنندگان برای بهبود راه‌حل‌های ذخیره‌سازی RDF کمک کند، به مشتریان راهنمایی بدهد که کدام پیاده‌سازی برای موارد مورد نظرشان مناسب‌تر است، و نقطه شروعی برای سازگاری بیشتر با استانداردها باشد. گسترش وب معنایی جغرافیایی

کار آینده

اخیراً، گروه کاری OGC GeoSPARQL دوباره فعال شده است [ 42 ، 43 ] تا GeoSPARQL 2.0، جانشین استاندارد GeoSPARQL را تعریف کند. این یک روش خوب است که استانداردهای OGC در حال ظهور ابتدا تعریف شوند، سپس بررسی شوند، و در عین حال به عنوان اثبات مفهوم نیز اجرا شوند. در طول این پیاده سازی، آزمایش انطباق به طور فزاینده ای رایج می شود همانطور که می توان با ایجاد موتور تیم OGC مشاهده کرد ( https://cite.opengeospatial.org/teamengine/(دسترسی در 22 مه 2021))، یک مجموعه تست انطباق که شرکت‌ها ممکن است از آن برای دریافت گواهینامه‌های رسمی انطباق OGC برای پیاده‌سازی نرم‌افزار خود استفاده کنند. با توجه به اینکه در حال حاضر هیچ تست انطباق OGC GeoSPARQL تایید شده با OGC وجود ندارد، ما از همکاری با OGC استقبال می کنیم و می خواهیم مجموعه آزمایشی خود را برای پوشش تغییراتی که در GeoSPARQL 2.0 تعریف می شود گسترش دهیم.
با توجه به اینکه معیار ما یک معیار انطباق است، ما قصد داریم یک معیار عملکرد مکمل ایجاد کنیم که عملکرد سه‌گانه RDF تست شده را برای هر یک از توابع GeoSPARQL که پشتیبانی می‌کند، آزمایش کند. این یک رویکرد جامع تر در ارزیابی راه حل های ذخیره سازی RDF جغرافیایی را ممکن می کند. علیرغم ظهور بسیاری از معیارهای عملکرد برای سه‌گانه‌های RDF زمین‌فضایی (که در بخش 2 ذکر شده استهیچ یک از معیارهای موجود برای هر تابعی که در GeoSPARQL در مجموعه داده آزمایشی مشخص شده است، تست نمی‌کند. معیار عملکرد ما می تواند از نتایج معیار انطباق استفاده کند و توابع GeoSPARQL پشتیبانی شده را هدف قرار دهد. پلت فرم معیار HOBBIT یک محیط عالی برای معیارهای عملکرد فراهم می کند، با توجه به اینکه همه آنها زیرساخت یکسانی برای آزمایش ها دارند و همه نتایج قابل تکرار هستند.

مشارکت های نویسنده

مفهوم سازی، میلوش جووانویک؛ روش شناسی، میلوش جووانوویک، تیمو هومبورگ و میرکو اسپاسیچ. نرم افزار، Milos Jovanovik، Timo Homburg و Mirko Spasić. اعتبارسنجی، میلوش جووانوویک، تیمو هومبورگ و میرکو اسپاسیچ. تحلیل رسمی، میلوش یووانوویک، تیمو هومبورگ و میرکو اسپاسیچ. تحقیق، میلوش یووانوویک، تیمو هومبورگ و میرکو اسپاسیچ. منابع، میلوش جووانوویک، تیمو هومبورگ و میرکو اسپاسیچ. گزینش داده ها، میلوش جووانوویک، تیمو هومبورگ و میرکو اسپاسیچ. نوشتن – آماده سازی پیش نویس اصلی، میلوش جووانوویک و تیمو هامبورگ. نوشتن-بررسی و ویرایش، میلوش جووانوویک، تیمو هامبورگ و میرکو اسپاسیچ. تجسم، میلوش جووانویک و تیمو هامبورگ. نظارت، میلوش جووانوویک؛ مدیریت پروژه، میلوش جووانوویک. همه نویسندگان نسخه منتشر شده نسخه خطی را خوانده و با آن موافقت کرده اند.

منابع مالی

این کار تا حدی توسط Eurostars Project SAGE (GA no. E!10882) پشتیبانی شده است.

بیانیه در دسترس بودن داده ها

کد معیار به صورت عمومی در GitHub در https://github.com/OpenLinkSoftware/GeoSPARQLBenchmark در دسترس است (در 8 ژوئیه 2021 قابل دسترسی است). نتایج آزمایش‌های اجرا شده در نمونه عمومی پلتفرم HOBBIT، در https://master.project-hobbit.eu (در 8 ژوئیه 2021 قابل دسترسی است). More specifically, the results from Figure 3 are available at https://master.project-hobbit.eu/experiments/1612476122572,1612477003063,1612476116049,1625421291667,1612477500164,1612661614510,1612637531673,1612828110551,1612477849872(در 8 ژوئیه 2021 قابل دسترسی است)، که در آن هر آزمایش پیوند داده شده است و می توان آن را جداگانه مشاهده کرد. گزارش‌های دقیق هر آزمایش نیز برای بارگیری از همان مکان وب در دسترس عموم است. پلتفرم HOBBIT تکرارپذیری نتایج ما را فراهم می‌کند و به کاربران اجازه می‌دهد آزمایش‌های خود را با معیار انطباق GeoSPARQL و هر سیستم(هایی) که علاقه‌مند به محک زدن هستند، اجرا کنند.

تضاد علاقه

میلوس جووانوویک و میرکو اسپاسیچ برای OpenLink Software کار می کنند که فروشنده Virtuoso، یکی از فروشگاه های سه گانه محک است. تامین کنندگان مالی هیچ نقشی در طراحی مطالعه نداشتند. در جمع آوری، تجزیه و تحلیل یا تفسیر داده ها؛ در نوشتن دست‌نوشته یا تصمیم به انتشار نتایج.

اختصارات

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

هسته جزء اصلی
CRS سیستم مرجع مختصات
GEOEXT پسوند هندسه
GML زبان نشانه گذاری جغرافیا
GTOP پسوند توپولوژی هندسه
OGC کنسرسیوم فضایی باز
QRW درخواست بازنویسی پسوند
RDF چارچوب شرح منابع
RDFS طرحواره RDF
RDFSE پسوند RDFS Entailment
SPARQL پروتکل SPARQL و زبان پرس و جو RDF
بالا پسوند واژگان توپولوژی
WKT متن معروف

منابع

  1. Fonseca، F. وب معنایی جغرافیایی. در کتاب راهنمای علم اطلاعات جغرافیایی ; Blackwell Publishing: Malden, MA, USA, 2008; صص 367-376. [ Google Scholar ]
  2. برنرز لی، تی. هندلر، جی. Lassila، O. وب معنایی. علمی صبح. 2001 ، 284 ، 34-43. [ Google Scholar ] [ CrossRef ]
  3. نبرد، آر. Kolas، D. GeoSPARQL: فعال کردن یک وب معنایی جغرافیایی. سمنت. Web J. 2011 , 3 , 355-370. [ Google Scholar ] [ CrossRef ]
  4. پری، م. هرینگ، J. OGC GeoSPARQL – زبان جستجوی جغرافیایی برای داده‌های RDF. استاندارد OGC، کنسرسیوم فضایی باز، Wayland، MA، ایالات متحده آمریکا. 2012. در دسترس آنلاین: https://www.ogc.org/standards/geosparql (در 22 مه 2021 قابل دسترسی است).
  5. هرینگ، J. OpenGIS® پیاده‌سازی استاندارد برای اطلاعات جغرافیایی – دسترسی به ویژگی‌های ساده – بخش 1: معماری مشترک. استاندارد پیاده سازی OpenGIS، کنسرسیوم فضایی باز، Wayland، MA، ایالات متحده آمریکا. 2011. در دسترس آنلاین: https://www.ogc.org/standards/sfa (در 22 مه 2021 قابل دسترسی است).
  6. Portele, C. OGC Geography Markup Language (GML) – طرحواره های توسعه یافته و قوانین رمزگذاری. استاندارد پیاده سازی OpenGIS، کنسرسیوم فضایی باز، Wayland، MA، ایالات متحده آمریکا. 2012. در دسترس آنلاین: https://www.ogc.org/standards/gml (در 22 مه 2021 قابل دسترسی است).
  7. Prud’hommeaux, E.; Seaborne، A. SPARQL Query Language for RDF. توصیه W3C، W3C. 2008. در دسترس آنلاین: https://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ (در 22 مه 2021 قابل دسترسی است).
  8. نبرد، آر. کولاس، دی. فعال کردن وب معنایی مکانی با پارلمان و GeoSPARQL. سمنت. وب 2012 ، 3 ، 355-370. [ Google Scholar ] [ CrossRef ]
  9. آلبیستون، جی ال. عثمان، تی. Chen, H. GeoSPARQL-Jena: پیاده سازی و محک گذاری یک فروشگاه گرافیک GeoSPARQL. سمنت. Web J. 2019 . تحت بررسی [ Google Scholar ]
  10. Janssen, V. درک سیستم های مرجع مختصات، داده ها و تبدیل ها. بین المللی J. Geoinformatics 2009 ، 5 ، 41-53. [ Google Scholar ]
  11. Decker, BL World Geodetic System 1984 ; گزارش فنی؛ مرکز هوافضای آژانس نقشه برداری دفاعی: سنت لوئیس، MO، ایالات متحده آمریکا، 1986. [ Google Scholar ]
  12. گاربیس، جی. کیزیراکوس، ک. Koubarakis, M. Geographica: A Benchmark for GeoSpatial RDF Stores (نسخه طولانی). در مجموعه مقالات کنفرانس بین المللی وب معنایی، سیدنی، NSW، استرالیا، 21 تا 25 اکتبر 2013. Springer: برلین/هایدلبرگ، آلمان، 2013; صص 343-359. [ Google Scholar ]
  13. Ioannidis، T. گاربیس، جی. کیزیراکوس، ک. برتا، ک. Koubarakis, M. Evaluating Geospatial RDF stores Using the Benchmark Geographica 2. arXiv 2019 , arXiv:1906.01933. [ Google Scholar ]
  14. هوانگ، دبلیو. رضا، س. میرزوف، او. Harrie, L. ارزیابی و محک گذاری فروشگاه های RDF فعال فضایی برای نسل بعدی زیرساخت داده های مکانی. ISPRS Int. J. Geo-Inf. 2019 ، 8 ، 310. [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
  15. رافس، ک. ناروی، جی. Germain, C. TFT, Tests For Triplestores. در مجموعه مقالات چالش وب معنایی، بخشی از کنفرانس بین المللی وب معنایی، ریوا دل گاردا، ایتالیا، 19 تا 23 اکتبر 2014. [ Google Scholar ]
  16. Ngomo، ACN; گارسیا روخاس، آ. Fundulaki، I. HOBBIT: محک زدن کل نگر برای داده های پیوندی بزرگ. ERCIM News 2016 . [ Google Scholar ]
  17. رودر، ام. کوچلف، دی. Ngonga Ngomo، AC HOBBIT: بستری برای محک زدن داده‌های پیوندی بزرگ. اطلاعات علمی 2020 ، 3 ، 15-35. [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
  18. جووانوویک، م. هامبورگ، تی. Spasić، M. GeoSPARQL Compliance Benchmark. در دسترس آنلاین: https://github.com/OpenLinkSoftware/GeoSPARQLBenchmark (در 8 ژوئیه 2021 قابل دسترسی است).
  19. جووانوویک، م. هامبورگ، تی. Spasić، M. نرم افزار برای معیار انطباق GeoSPARQL. نرم افزار Impacts 2021 , 8 , 100071. [ Google Scholar ] [ CrossRef ]
  20. باتلر، اچ. دالی، م. دویل، ا. گیلیز، اس. هاگن، اس. Schaub, T. فرمت GeoJSON ; گزارش فنی 7946; IETF: Fremont، CA، USA، 2016. [ Google Scholar ]
  21. کلارک، ک. فایگنباوم، ال. تورس، پروتکل E. SPARQL برای RDF. توصیه W3C، W3C. 2008. در دسترس آنلاین: https://www.w3.org/TR/2008/REC-rdf-sparql-protocol-20080115/ (دسترسی در 22 مه 2021).
  22. بکت، دی. Broekstra, J. SPARQL Query Results Format XML. توصیه W3C، W3C. 2008. در دسترس آنلاین: https://www.w3.org/TR/2008/REC-rdf-sparql-XMLres-20080115/ (در 22 مه 2021 قابل دسترسی است).
  23. بریکلی، دی. Guha, R. RDF Schema 1.1. توصیه W3C، W3C. 2014. در دسترس آنلاین: https://www.w3.org/TR/2014/REC-rdf-schema-20140225/ (دسترسی در 22 مه 2021).
  24. کیفر، م. Boley, H. RIF بررسی اجمالی (نسخه دوم). W3C Note، W3C. 2013. در دسترس آنلاین: https://www.w3.org/TR/2013/NOTE-rif-overview-20130205/ (در 22 مه 2021 قابل دسترسی است).
  25. برنرز لی، تی. Masinter، LM; فیلدینگ، شناسه های منبع یکسان RT (URI): Generic Syntax ; گزارش فنی 2396; IETF: Fremont، CA، USA، 1998. [ Google Scholar ]
  26. نیکولای، آر. Simensen, G. The New EPSG Geodetic Parameter Registry. در مجموعه مقالات هفتادمین کنفرانس و نمایشگاه EAGE که شامل SPE EUROPEC 2008، رم، ایتالیا، 9 تا 12 ژانویه 2008 است. انجمن اروپایی دانشمندان و مهندسین زمین: هوتن، هلند، 2008. [ Google Scholar ] [ CrossRef ]
  27. Portele, C. OpenGIS® Geography Markup Language (GML) استاندارد رمزگذاری. استاندارد OpenGIS، کنسرسیوم فضایی باز، Wayland، MA، ایالات متحده آمریکا. 2007. در دسترس آنلاین: https://www.ogc.org/standards/gml (در 22 مه 2021 قابل دسترسی است).
  28. Strobl، C. مدل تقاطع نه‌گانه توسعه‌یافته (DE-9IM). در دایره المعارف GIS ; Shekhar, S., Xiong, H., Zhou, X., Eds. Springer: Cham, Switzerland, 2017; صص 470-476. [ Google Scholar ] [ CrossRef ]
  29. گلیم، بی. Ogbuji, C. SPARQL 1.1 Entailment Regimes. توصیه W3C 2013. در دسترس آنلاین: https://www.w3.org/TR/2013/REC-sparql11-entailment-20130321/ (دسترسی در 22 مه 2021).
  30. مک گینس، دی. ون هارملن، F. OWL مروری بر زبان هستی شناسی وب. توصیه W3C، W3C. 2004. در دسترس آنلاین: https://www.w3.org/TR/2004/REC-owl-features-20040210/ (در 22 مه 2021 قابل دسترسی است).
  31. بولی، اچ. هالمارک، جی. کیفر، م. پاشکه، ا. پولرس، ا. Reynolds، D. RIF Core Dialect. توصیه W3C، W3C. 2010. در دسترس آنلاین: https://www.w3.org/TR/2010/REC-rif-core-20100622/ (در 22 مه 2021 قابل دسترسی است).
  32. آپاچی مارموتا. در دسترس آنلاین: https://marmotta.apache.org (در 22 مه 2021 قابل دسترسی است).
  33. بلیزگراف در دسترس آنلاین: https://blazegraph.com (در 22 مه 2021 قابل دسترسی است).
  34. Eclipse RDF4J. در دسترس آنلاین: https://rdf4j.org (در 22 مه 2021 قابل دسترسی است).
  35. GeoSPARQL Fuseki. در دسترس آنلاین: https://jena.apache.org/documentation/geosparql/geosparql-fuseki (در 22 مه 2021 قابل دسترسی است).
  36. ینا فوسکی. در دسترس آنلاین: https://jena.apache.org/documentation/fuseki2/ (دسترسی در 22 مه 2021).
  37. GraphDB. در دسترس آنلاین: https://graphdb.ontotext.com (در 22 مه 2021 قابل دسترسی است).
  38. Erling، O. Virtuoso، فروشگاه ترکیبی RDBMS/Graph Column. IEEE Data Eng. گاو نر 2012 ، 35 ، 3-8. [ Google Scholar ]
  39. دارای ذوق هنری. در دسترس آنلاین: https://virtuoso.openlinksw.com (در 22 مه 2021 قابل دسترسی است).
  40. سگ ستاره ای. در دسترس آنلاین: https://www.stardog.com (در 22 مه 2021 قابل دسترسی است).
  41. TriplyDB. در دسترس آنلاین: https://triplydb.com (در 8 ژوئیه 2021 قابل دسترسی است).
  42. ابهایاراتنا، ج. ون دن برینک، ال. ماشین، ن. اتکینسون، آر. هامبورگ، تی. Knibbe، F. مک گلین، ک. واگنر، آ. بوندوئل، ام. هولتن راسموسن، ام. و همکاران مزایای OGC از نمایش داده های مکانی با استفاده از فن آوری های معنایی و نموداری. OGC White Paper، کنسرسیوم فضایی باز، Wayland، MA، ایالات متحده آمریکا. 2020. در دسترس آنلاین: https://docs.ogc.org/wp/19-078r1/19-078r1.html (در 22 مه 2021 قابل دسترسی است).
  43. ابهایاراتنا، ج. ون دن برینک، ال. ماشین، ن. هامبورگ، تی. منشور Knibbe، F. OGC GeoSPARQL 2.0 SWG. در دسترس آنلاین: https://github.com/opengeospatial/geosemantics-dwg/tree/master/geosparql_2.0_swg_charter (در 22 مه 2021 قابل دسترسی است).
Ijgi 10 00487 g001 550
شکل 1. نمای انتزاعی از هندسه هایی که بخشی از مجموعه داده معیار هستند. هندسه های A، B، C، D، G، J و K نشان دهنده هندسه های چند ضلعی هستند و (به غیر از J و K) همگی هندسه نقطه مرکزی دارند. هندسه E نشان دهنده هندسه LineString است، در حالی که هندسه های F، L و M نشان دهنده هندسه نقطه ای هستند. هندسه های H و I هندسه های خالی هستند و در این شکل قابل مشاهده نیستند. همه هندسه ها در سیستم ژئودزی CRS84 نشان داده شده اند، به جز هندسه M که در EPSG:4326 نشان داده شده است. هر هندسه با استفاده از WKT و GML نشان داده می شود.
Ijgi 10 00487 g002 550
شکل 2. پلتفرم محک زدن HOBBIT.
Ijgi 10 00487 g003 550
شکل 3. نتایج از معیار انطباق GeoSPARQL، از نمونه عمومی پلت فرم HOBBIT.

دسته‌بندی نشده

مطالب مرتبط ...

بدون دیدگاه

دیدگاهتان را بنویسید