۱٫ مقدمه
داده های مکانی به طور فزاینده ای در وب [ ۱ ] در قالب نمودارهای دانش در وب معنایی، اغلب با استفاده از اصول داده های پیوندی [ ۲ ] در دسترس هستند. برای دستیابی به این نمودارهای دانش، منابع (جغرافیایی) باید با استفاده از URI های HTTP شناسایی شوند، توسط موتورهای جستجو نمایه شوند، و به منابع دیگر متصل یا مرتبط شوند [ ۳ ]. بنابراین، این مستلزم اتخاذ بهترین شیوه ها برای انتشار، بازیابی و استفاده از داده ها در وب است [ ۲ ، ۳ ]. این بهترین شیوهها توسط تعداد فزایندهای از ارائهدهندگان داده پذیرفته میشوند، که منجر به ایجاد یک فضای داده جهانی حاوی میلیاردها ادعا – وب داده [ ۳ ] میشود.
تبدیل و انتشار دادههای مکانی بهعنوان نمودارهای دانش توسط طرحهایی مانند GeoNames ( http://www.geonames.org/ontology/documentation.html (دسترسی در ۲۳ نوامبر ۲۰۲۱))، OpenStreetMap [ ۴ ]، و Ordnance Survey پیشگام شد. [ ۵ ]. پس از این ابتکارات، بسیاری از مجموعه دادههای جغرافیایی در Web of Data ( http://lod-cloud.net / (در ۲۳ نوامبر ۲۰۲۱) منتشر شده است. این مستلزم آن است که دادههای مکانی نقش برجستهای در ابر وب دادهها ایفا میکنند، به عنوان پیوندهای مرکزی که رویدادها، افراد و اشیاء را به هم متصل میکنند [ ۶ ] و ارائه یک نمایش معنایی رو به رشد از ثروت اطلاعات مکانی [ ۷ ] است.].
علیرغم پیشرفتهای مرتبط با میزان دادههای موجود، نمودارهای دانش مکانی هنوز با محدودیتهای قابل توجهی در جامعه GIS مواجه هستند، زیرا استفاده، مصرف و بهرهبرداری از آنها در این جامعه واقعاً کمیاب است، بهویژه با توجه به تعداد کمی از آثار موجود که در آن این نمودارهای دانش بازیابی شدهاند. یکپارچه شده از درون سیستم های اطلاعات جغرافیایی (GIS).
برای غلبه بر این محدودیتها و پرداختن به برخی چالشهای حیاتی GIScience [ ۸ ]، استانداردها (به عنوان مثال، GeoSPARQL [ ۹ ]) و بهترین شیوههای وابستگی به دامنه برای انتشار، بازیابی و استفاده از دادههای مکانی در وب شروع به ارائه این دیدگاه جدید کردهاند. در جامعه GIScience علاوه بر این، برخی از ابزارهایی که بهترین شیوه های وب معنایی و وب GIS را ترکیب می کنند در [ ۱۰ ] جمع آوری شده اند.
نمودارهای دانش (جغرافیایی) توسط فروشگاه های سه گانه ذخیره و مدیریت می شوند که به عنوان فروشگاه های RDF یا پایگاه های دانش نیز شناخته می شوند. با توجه به [ ۱ ]، آنها قادر به پرداختن بهتر به انواع مختلفی از مسائلی هستند که پایگاه داده های رابطه ای در آنها با مشکل مواجه هستند یا قصد انجام آنها را ندارند: پرس و جوهایی با پیوندهای فراوان در موجودیت ها [ ۱۱ ]، پرس و جوهایی با ویژگی های متغیر [ ۱۱ ]، و استنتاج هستی شناختی در مورد مجموعه داده ها کنسرسیوم وب جهانی (W3C) مجموعه ای از فروشگاه های سه گانه موجود را جمع آوری کرده است ( https://www.w3.org/2001/sw/wiki/Category:Triple_Store(دسترسی در ۲۳ نوامبر ۲۰۲۱))، که در آن پیادهسازیهای مختلف مرتبط با حوزه جغرافیایی یافت میشود، و کارهای اخیر انطباق GeoSPARQL را در فروشگاههای سهگانه متنوع آزمایش کردهاند [ ۷ ]، به عنوان مثال، Apache Marmotta ( http://marmotta) را برجسته میکند. apache.org/ (دسترسی در ۲۳ نوامبر ۲۰۲۱))، پارلمان ( https://github.com/SemWebCentral/parliament (دسترسی در ۲۳ نوامبر ۲۰۲۱))، OpenLink Virtuoso ( https://virtuoso.openlinksw.com/ (دسترسی در ۲۳ نوامبر ۲۰۲۱))، یا GeoSPARQL Fuseki ( https://jena.apache.org/documentation/geosparql/geosparql-fuseki(دسترسی در ۲۳ نوامبر ۲۰۲۱)). با این وجود، پیشرفتهای کنونی از امکان بیان پرسشها در نمودارهای دانش متنوع پشتیبانی نمیکنند. از این نظر، منابع کافی وجود ندارد که از پیاده سازی ترکیبی GeoSPARQL و SPARQL 1.1 پشتیبانی کند تا امکان انجام پرس و جوهای مکانی فدرال در وب داده ها را فراهم کند.
با در نظر گرفتن این سناریو و نیاز شناخته شده برای پشتیبانی از پرس و جوهای فدرال با استفاده از GeoSPARQL [ ۱۲]، ما رویکردی را برای درخواست، بازیابی و مصرف نمودارهای دانش (جغرافیایی) ارائه می کنیم که به طور نمونه اولیه در Apache Marmotta پیاده سازی شده است. این رویکرد از ترکیب استانداردهای SPARQL 1.1 و GeoSPARQL پشتیبانی میکند و امکان انجام پرسوجوهای جغرافیایی فدرال را در وب دادهها فراهم میکند. علاوه بر این، رویکرد ما امکان مصرف نمودارهای دانش مکانی را برای نمایش عناصر جمعآوریشده در یک برنامه وب سبک یا اضافه کردن آنها از طریق یک GIS منبع باز به عنوان QGIS فراهم میکند. علاوه بر این، رویکرد ما از نمودارهای دانش غیر مکانی برای غنیسازی توصیف منابع مکانی جمعآوریشده از نمودارهای دانش استفاده میکند. پتانسیل رویکرد ما با دو مثال نشان داده شده است که نمودارهای دانش مبتنی بر GeoSPARQL را از Web of Data مدیریت می کند.
برخلاف کار قبلی، که از پارادایم داده های پیوندی از داخل یک GIS استفاده می کند [ ۶ ]، رویکرد ما بر روی یک چشم انداز فدرال تمرکز دارد، کاملاً مطابق با GeoSPARQL است و بر روی یک GIS منبع باز مانند QGIS پیاده سازی می شود. علاوه بر این، این کار به پر کردن شکاف کمک میکند و بهرهبرداری از منابع مبتنی بر GeoSPARQL را در یک محیط توزیعشده از طریق شیوههای فدرال (پرسوجو) ممکن میسازد، و به جامعه GIScience کمک میکند تا از غنای وب دادهها استفاده کند.
ساختار باقی مانده این مقاله به شرح زیر است. ما انگیزه کار خود را با یک سناریوی واقعی در جامعه GIScience در بخش ۲ ایجاد می کنیم. بخش ۳ برخی از مفاهیم مرتبط با پیشینه و برخی آثار مرتبط را ارائه می کند. شرح مفصلی از روش ها و اجرای نمونه اولیه رویکرد جستارهای GeoSPARQL فدرال ما در بخش ۴ توضیح داده شده است . بخش ۵ دو نمونه از کاربرد رویکرد ما را با استفاده از چندین نمودار دانش (جغرافیایی) نشان می دهد. در نهایت، بحث و نتیجه گیری در بخش ۶ ارائه شده است.
۲٫ مثال انگیزشی
انگیزه این کار سناریوی دنیای واقعی جامعه GIScience است که در آن کاربران مختلف با لایههای همپوشانی بهعنوان روش یکپارچهسازی دادههای مکانی سروکار دارند. در این سناریو، جامعه اغلب به دنبال منابع داده در مخازن مختلف، وبسایتها یا کاتالوگهای مرتبط با ابتکارات دادههای باز یا زیرساختهای داده مکانی (SDI) میگردد. با این حال، این حالت داده های جغرافیایی به عنوان سیلو باقی می ماند و دستیابی به یک چشم انداز کامل و یکپارچه از داده های موجود در وب را چالش برانگیز می کند.
تلاشهای متعددی با تبدیل دادههای مکانی سنتی به RDF [ ۱۳ ، ۱۴ ، ۱۵ ]، کشف پیوندها [ ۱۵ ، ۱۶ ، ۱۷ ، ۱۸ ]، بهرهبرداری از روابط توپولوژیکی [ ۲۰ ]، به تجزیه سیلوهای دادههای مکانی کمک کرده است . یا ترکیب وب معنایی با SDI [ ۲۱ , ۲۲ , ۲۳]. بنابراین، می توان از منابع داده های مکانی مناسب در وب داده ها استفاده و پرس و جو کرد. با این وجود، همانطور که اشاره کردیم، این رویکردها بر به دست آوردن دادههای مکانی از سیلوهای داده متمرکز بودند، در حالی که استفاده، مصرف و بهرهبرداری از نمودارهای دانش توسط جامعه GIScience کمیاب است.
به این معنا، ما میخواهیم جامعه ما نمودارهای دانش را برای استفاده و مصرف دادههای مکانی موجود بچرخاند. بنابراین، ما رویکردی را برای درخواست، بازیابی و مصرف نمودارهای دانش مکانی با استفاده از پرس و جوهای فدرال (SPARQL 1.1) و GeoSPARQL پیشنهاد می کنیم. علاوه بر این، رویکرد ما امکان مصرف نمودارهای دانش مکانی را در یک GIS فراهم میکند، زیرا پتانسیل فراتر از افزودن یک منبع داده دیگر را فراهم میکند [ ۶ ] و به غلبه بر مسائل معنایی قابلیت همکاری GIS [ ۲۴ ] کمک میکند.]. بنابراین، استفاده از جعبه ابزارهای عظیم تحلیل فضایی مدرن و همچنین استخراج و بهره برداری از دانش از منابع داده ناهمگن را ممکن می سازد. به این ترتیب، رویکرد ما به کاربران اجازه میدهد تا نمودارهای دانش مکانی را به دو روش دستکاری کنند: (۱) بهرهبرداری مستقیم از دادهها از طریق جستارهای فدرال GeoSPARQL و نمایش دادههای جمعآوریشده در یک وب اپلیکیشن، و (ب) مصرف نمودارهای دانش مکانی از طریق یک GIS برای بهرهبرداری از این. اطلاعات در یک محیط آشنا برای جامعه.
در نگاه اول، سناریوی ذکر شده در بالا چیزی بیش از یک کار مهندسی نرم افزار به نظر نمی رسد، یعنی یک عملکرد وارداتی بهبود یافته برای GIS که نمودارهای دانش مکانی را به مجموعه گسترده ای از فرمت های داده ای که می توان مصرف کرد اضافه کرد. با این حال، نمودارهای دانش یک قالب داده نیستند. همانطور که قبلا ذکر کردیم، این پارادایم مبتنی بر اصول داده های پیوندی با استراتژی های مورد نیاز برای مقیاس وب، زیرساخت داده های توزیع شده است و به خوبی با نحوه تبادل داده ها در GIS سازگار نیست [ ۶ ].]. بنابراین، مستلزم راههای جدیدی برای تفکر در مورد اینکه چگونه علم GIS و جامعه آن باید با نمودارهای دانش (جغرافیایی) در یک محیط توزیع شده و از طریق روشهای فدرال (پرس و جو) تعامل داشته باشند، به ما امکان میدهد از غنای یک فضای داده جهانی که حاوی میلیاردها (جغرافیایی) است بهره برداری کنیم. ) اظهارات – وب داده [ ۳ ].
۳٫ پیشینه و کارهای مرتبط
۳٫۱٫ نمودارهای دانش
مفهوم نمودار دانش ، که به عنوان شبکه های معنایی نیز شناخته می شود، در اوایل دهه ۱۹۷۰ برای نشان دادن دانش انسانی به شکل قابل خواندن توسط ماشین استفاده شد [ ۲۵ ، ۲۶ ]. بعداً، گوگل هنگامی که در سال ۲۰۱۲ ایده خود را در مورد استراتژی جستجوی وب جدید معرفی کرد ( https://googleblog.blogspot.com/2012/05/introducing-knowledge-graph-things-not ) مجدداً کشف کرد و دید جدیدی از این مفهوم را گسترش داد . html (دسترسی در ۲۳ نوامبر ۲۰۲۱)). این شامل تغییر از پردازش متن خالص به یک بازنمایی نمادین تر از دانش است که به روش زیر بیان می شود:
نمودار دانش به شما امکان میدهد چیزها، افراد یا مکانهایی را جستجو کنید که Google درباره مکانهای دیدنی، افراد مشهور، شهرها، تیمهای ورزشی، ساختمانها، ویژگیهای جغرافیایی، فیلمها، اجرام آسمانی، آثار هنری و موارد دیگر میشناسد و فوراً اطلاعات مرتبط با آنها را دریافت کنید. سوال شما این اولین قدم حیاتی برای ساختن نسل بعدی جستجو است که به هوش جمعی وب کمک میکند و دنیا را کمی بیشتر شبیه مردم میشناسد.»
زمینه وب معنایی همچنین یک نمایش مبتنی بر نمودار مرتبط با چارچوب شرح منابع ( https://www.w3.org/RDF/ (دسترسی در ۲۳ نوامبر ۲۰۲۱)) (RDF) را ترویج کرده است، که زبان استاندارد نمایش دانش است. برای این وب RDF یک زیرساخت قابل اعتماد برای انتشار، اشتراک گذاری و جستجوی داده های ساختار یافته در وب معنایی فراهم می کند [ ۲۷ ]. علاوه بر این، RDF چارچوبی را برای توصیف اطلاعات در وب ارائه می دهد، که نحو آن (یک مدل داده) دوگانه است: (۱) نمودارهای RDF مجموعه هایی از موضوع-مسئول- شی هستند.سه گانه که در آن مؤلفه ها ممکن است URI، حرف تایپ داده شده یا گره های خالی باشند. نمودارها شرح منابع را ارائه می دهند، به عنوان مثال: ابرداده در مورد شبکه های اجتماعی، مصنوعات دیجیتال، اطلاعات شخصی، و غیره، و همچنین مکانیزم یکپارچه سازی را بر روی منابع اطلاعاتی ناهمگن ارائه می دهند. (۲) مجموعه دادههای RDF برای ایجاد مجموعههای گراف RDF و تولید یک نمودار پیشفرض و صفر یا بیشتر گرافهای نامگذاری شده استفاده میشوند.
با توجه به [ ۲۸ ]، از یک پانورامای وسیع، هر نمایش مبتنی بر نمودار از برخی دانش را می توان یک نمودار دانش در نظر گرفت زیرا هیچ تعریف جهانی در مورد اینکه نمودار دانش چیست و چیست وجود ندارد [ ۲۹ ]. با این حال، ما حداقل مجموعه ای از اجزای نمودارهای دانش پیشنهاد شده توسط [ ۲۸ ] را انتخاب می کنیم:
-
عمدتاً موجودیت های دنیای واقعی و روابط متقابل آنها را که در یک نمودار جهت دار برچسب دار سازماندهی شده اند، توصیف می کند.
-
کلاس ها و روابط ممکن موجودیت ها را در یک طرحواره تعریف می کند.
-
امکان ارتباط بالقوه موجودیت های دلخواه با یکدیگر را فراهم می کند.
-
حوزه های مختلف موضوعی را پوشش می دهد.
-
به ما امکان می دهد داده ها را از طریق روابط بین گره ها استنباط کنیم.
نمونه های متعددی از نمودارهای دانش در وب معنایی اغلب با استفاده از اصول داده های پیوندی در دسترس هستند [ ۲ ]. این اصول با موارد زیر مشخص می شوند: (۱) استفاده از URI به عنوان نام چیزها. (۲) استفاده از URI های HTTP به طوری که مردم بتوانند آن نام ها را جستجو کنند. (۳) هنگامی که شخصی یک URI را جستجو می کند، اطلاعات ارزشمندی را از طریق چارچوب توصیفی منابع استاندارد (RDF) و پروتکل SPARQL و زبان پرس و جو RDF ( https://www.w3.org/TR/sparql11-query/ ) ارائه می دهد (در ۲۳ نوامبر قابل دسترسی است. ۲۰۲۱)) (SPARQL)؛ و (۴) افزودن پیوندها به سایر URIها به طوری که آنها بتوانند چیزهای بیشتری پیدا کنند. برخی از این نمودارهای دانش عبارتند از DBpedia ( https://dbpedia.org/ (دسترسی شده در ۲۳ نوامبر ۲۰۲۱))، OpenCyc ( https://github.com/asanchez75/opencyc(دسترسی در ۲۳ نوامبر ۲۰۲۱))، ویکی داده ( https://www.wikidata.org (دسترسی در ۲۳ نوامبر ۲۰۲۱))، Cyc ( https://www.cyc.com/ (دسترسی در ۲۳ نوامبر ۲۰۲۱))، و غیره شرح جامعی از این نمودارهای دانش و سایر نمودارها در [ ۲۸ ] شرح داده شده است.
۳٫۲٫ SPARQL و GeoSPARQL
SPARQL یک زبان پرس و جو معنایی است که قادر به بازیابی و دستکاری داده های ذخیره شده در RDF است. این زبان می تواند پرس و جوها را در منابع داده های مختلف بیان کند، چه داده ها به صورت بومی به عنوان RDF ذخیره شوند یا به عنوان RDF از طریق میان افزار مشاهده شوند. علاوه بر این، SPARQL دارای قابلیت هایی برای پرس و جو از الگوهای گراف مورد نیاز و اختیاری همراه با حروف ربط و تفکیک آنها است. SPARQL همچنین از تجمیع، پرس و جوهای فرعی، نفی، ایجاد مقادیر توسط عبارات، آزمایش ارزش توسعه پذیر و محدود کردن پرس و جوها توسط گراف RDF منبع پشتیبانی می کند. نتایج پرس و جوهای SPARQL می تواند مجموعه نتایج یا نمودارهای RDF باشد.
توسعه SPARQL 1.1 پرس و جوهای بیانی را در نمودارهای دانش متنوع امکان پذیر می کند، چه داده ها به صورت بومی به عنوان RDF ذخیره شوند یا به عنوان RDF از طریق میان افزار مشاهده شوند. مشخصات W3C نحو و معنای پسوند پرس و جو فدرال SPARQL 1.1 را برای اجرای پرس و جوهای توزیع شده در چندین نقطه پایانی SPARQL ایجاد می کند. جزئیات بیشتر در مورد این استاندارد را می توان در مشخصات W3C https://www.w3.org/TR/sparql11-federated-query/ (در ۲۳ نوامبر ۲۰۲۱) مشاهده کرد.
کنسرسیوم فضایی باز (OGC) رویکردی را برای توصیف و جستجوی دادههای مکانی در وب معنایی تعریف کرده است. این تلاش که GeoSPARQL [ ۹ ] نامیده میشود، واژگانی را برای نمایش دادههای مکانی در RDF و توسعهای به زبان پرس و جوی SPARQL برای پردازش این نوع دادهها تعریف میکند. علاوه بر این، GeoSPARQL برای تطبیق سیستمهای مبتنی بر استدلال فضایی کیفی و سیستمهای مبتنی بر محاسبات فضایی کمی طراحی شده است. این پیشنهاد امکان تعریف انواع متمایز هندسه (به عنوان مثال، چند ضلعی ها، خطوط، نقاط، چند نقطه، و غیره)، افزودن سیستم های مرجع مختصات متعدد، و آوردن فرصتی برای آشکارسازی روابط فضایی به مجموعه داده های جغرافیایی پرس و جو را به ابر وب داده می دهد (به عنوان مثال، لمس، تقاطع، همپوشانی، و غیره). کلاس هندسههندسه ها را نشان می دهد و مختصات را می توان در یک RDF از نوع متن شناخته شده (WKT)، که با [ ۳۰ ] مرتبط است، با استفاده از یک ویژگی RDF منفرد، یعنی asWKT، کدگذاری کرد.
GeoSPARQL همچنین امکان رمزگذاری هندسه ها را با استفاده از زبان نشانه گذاری جغرافیایی (GML) می دهد. بنابراین، نوع داده ( GMLLiteral )، ویژگی ( asGML ) و URL برای نوع هندسه باید مطابق با آن تنظیم شوند. مشخصات بیشتر در مورد GeoSPARQL در [ ۹ ] توضیح داده شده است.
۳٫۳٫ کار مرتبط
چندین کار، نمودارهای دانش را از دیدگاه وب معنایی به جامعه GIScience نزدیکتر کردهاند. در این زمینه، برخی از رویکردها بر فرآیند تبدیل از دادههای مکانی به RDF متمرکز شدند. Schade و Cox [ ۳۱ ] پیشنهادی برای تبدیل GML به RDF و گسترش انواع داده های داده شده توسط WFS به انواع دیگر، مانند GML، RDF و HTML ارائه کردند. استدلر و همکاران [ ۳۲ ] یک رویکرد ETL برای تبدیل داده های OpenStreetMap به داده های پیوندی ایجاد کرد و ابتکار LinkedGeoData را ایجاد کرد. Usery و Varanka [ ۱۳ ] تبدیلی از داده های برداری و شطرنجی به RDF تعریف کردند و همچنین داده های برداری را در قالب GML با استفاده از روابط توپولوژیکی پیش محاسباتی رمزگذاری کردند و آنها را به سه گانه RDF تبدیل کردند. ون دن برینک و همکاران [ ۱۴] یک تبدیل نیمه خودکار از مدل های اطلاعات جغرافیایی و داده های GML به داده های RDF را توصیف کرد. علاوه بر این، ابزارهای مختلفی برای انجام تبدیل دادههای مکانی سنتی (شکلفایلها یا پایگاههای دادههای مکانی) به RDF کمی سادهتر ظاهر شدهاند، مانند Geometry2RDF [ ۳۳ ]، Sparqlify، TripleGeo [ ۳۴ ]، SHP2GeoSPARQL، یا [ ۲ ]. [ ۳۵ ].
رویکردهای دیگر با هدف یکپارچگی عمیق تر از طریق فعال کردن پردازش پرس و جو فضایی در SPARQL [ ۱۰ , ۳۶ , ۳۷ ] با پیاده سازی چارچوب اتصال داده های پیوندی به عنوان مجموعه ای از جعبه ابزار برای ArcGIS Esri که امکان بازیابی، ادغام و تجزیه و تحلیل داده های پیوندی را فراهم می کند. در GIS [ ۶ ]، یا با توسعه استانداردها یا پسوندهای جدید برای استدلال مکانی و زمانی و پرس و جو بر روی داده های پیوندی [ ۳۸ ].
از سوی دیگر، کارهای متنوعی بر مدیریت دادههای مکانی با استفاده از GeoSPARQL متمرکز شدهاند. Battle و Kolas [ ۱ ] یکی از اولین پیاده سازی های GeoSPARQL را توسعه دادند که پرس و جوهای بافر را برای مکان های نزدیک مانند پارک ها فعال می کرد. برتا و همکاران [ ۳۹ ] Ontop-Spatial را تشریح کرد، یک گسترش جغرافیایی از سیستم OBDA Ontop، که از فناوریهای پایگاههای دادههای مکانی استفاده میکند و ترجمه GeoSPARQL به SQL را تسهیل میکند. نویسندگان، عملکردهای سیستم را در کشف مزارع کشاورزی که با مناطق حفاظت شده تلاقی می کنند و اطلاعات مربوط به سیل را یکپارچه می کنند، به تصویر می کشند. نایس و همکاران [ ۴۰] از GeoSPARQL و OWL-Time برای گسترش CIDOC CRM: CRMgeo استفاده کرد، که یک مدیریت تقریباً کامل داده برای استدلال پیچیده مکانی-زمانی و پرس و جو از طریق پرس و جوهای SPARQL ارائه می دهد. Vilches-Blázquez و Saavedra [ ۲۳ ] یک فرآیند کشف پیوند را بر اساس فرآیند تحلیل فضایی با استفاده از GeoSPARQL انجام دادند. این کار امکان تنظیم تطابق های فضایی بین منابع داده های مختلف جغرافیایی را فراهم می کند که روابط توپولوژیکی (مثلاً شامل، متقاطع، لمس و غیره) را بر اساس GeoSPARQL مشخص می کند.
با توجه به پرس و جوهای فدرال، برخی از آثار از پرس و جوهای فدرال بر روی نمودارهای دانش (جغرافیایی) استفاده کرده اند [ ۴۱ ، ۴۲ ، ۴۳ ، ۴۴ ، ۴۵ ، ۴۶ ]. با این حال، کاربرد پرس و جوها با توابع جغرافیایی محدود است و GeoSPARQL کاملاً مطابقت ندارد. علاوه بر این، با توجه به رویکردهای فزاینده مبتنی بر GeoSPARQL، برخی از کارها راه هایی برای اندازه گیری پشتیبانی در فروشگاه های سه گانه RDF با قابلیت GeoSPARQL ارائه کرده اند [ ۷ ، ۴۷ ، ۴۸ ، ۴۹ ]. حتی یک معیار با استفاده از ساختارهای GeoSPARQL تعریف شد که با تمام مراحل پردازش پرس و جو فدرال مواجه است [ ۵۰].
به طور خلاصه، چندین رویکرد عمدتاً بر افزودن مؤلفه جغرافیایی به وب داده ها، توسعه موارد استفاده و ابزارهای مربوطه برای تبدیل داده های مکانی «سنتی» در نمودارهای دانش (حتی بر اساس GeoSPARQL) و ارائه برخی قابلیت های فضایی متمرکز شده اند. علاوه بر این، آثار کمی به بازیابی و ادغام نمودارهای دانش از درون GIS پرداخته اند. با این حال، تا آنجا که ما میدانیم، هیچ نتیجه قبلی وجود ندارد که در آن نمودارهای دانش مکانی درخواست شده و از طریق یک روش فدرال ترکیبی از استانداردهای SPARQL 1.1 و GeoSPARQL بازیابی شوند. علاوه بر این، اگرچه یک کار مرتبط وجود دارد که در آن داده های پیوندی در ArcGIS بازیابی و ادغام می شوند [ ۶ ]]، رویکرد ما بر روی یک چشم انداز فدرال متمرکز است، کاملاً از سازگاری GeoSPARQL استفاده می کند و بر روی یک GIS منبع باز مانند QGIS پیاده سازی شده است.
۴٫ روش ها و اجرای نمونه اولیه
این بخش شرح مختصری از فروشگاه سهگانهای را ارائه میکند که ما پیادهسازی مرجع رویکرد جغرافیایی فدرال (Apache Marmotta) را بر روی آن توسعه دادهایم و ویژگیهای اصلی مربوط به معماری و طراحی رویکرد ما را شرح میدهد و هر یک از اجزای آن را توضیح میدهد.
۴٫۱٫ آپاچی مارموتا
Apache Marmotta یک فروشگاه سه گانه منبع باز است که در سال ۲۰۱۲ به انکوباتور بنیاد نرم افزار آپاچی پیوست. بنیاد نرم افزار آپاچی آن را اداره می کند و در نوامبر ۲۰۱۳، تحت مجوز نرم افزار آپاچی نسخه ۲٫۰ به عنوان یک پروژه سطح بالا فارغ التحصیل شد. Apache Marmotta به عنوان یک پروژه Linked Media Framework شروع به کار کرد که هدف اصلی آن این بود که یک برنامه سرور با تنظیم آسان باشد که به برخی فناوری ها مانند Apache Stanbol و Apache Solr ملحق شود. Apache Marmotta پلتفرمی را برای خواندن، نوشتن و به روز رسانی داده های RDF از طریق هستی شناسی ها، پایگاه های داده گراف و زبان SPARQL ارائه می دهد.
می توان آن را از طریق یک فایل jar در ویندوز مستقر کرد و به عنوان چنین فایلی اجرا کرد. نصب Apache Marmotta با استفاده از این روش استقرار آن را آسان تر می کند زیرا کاربران نیازی به پیکربندی هیچ تنظیماتی از جمله وب سرور آپاچی تامکت ندارند. راه دیگر برای نصب این فروشگاه سه گانه این است که کد منبع را با Maven کامپایل کنید و آن را اجرا کنید یا حتی آن را با یک تصویر عمومی Docker اجرا کنید.
در مورد ماندگاری داده ها، داده های RDF را می توان در سه پایگاه داده مختلف ذخیره کرد: H2 (به طور پیش فرض)، MySQL، که اتصال دهنده آن قابل توزیع نیست، و PostgreSQL مورد نیاز برای وظایف ژئوپردازش. با در نظر گرفتن دامنه این کار، PostgreSQL و پسوند جغرافیایی آن، PostGIS، در آپاچی مارموتا راه اندازی و استفاده شد.
با توجه به استانداردهای در نظر گرفته شده در این کار، Apache Marmotta از تعداد مناسبی از ویژگی های مربوط به SPARQL 1.1 پشتیبانی می کند و امکان پردازش هندسه ها (به عنوان مثال، نقاط، خطوط، چند ضلعی ها و چند ضلعی ها) را با ۳۵ تابع که GeoSPARQL را پشتیبانی می کند، ارائه می دهد. با این حال، هر دو استاندارد در Apache Marmotta ادغام نشدهاند و بهعنوان اجزای مجزا همزیستی دارند. بنابراین این فروشگاه سه گانه نمی تواند منابع جغرافیایی را به صورت فدرال پردازش کند.
۴٫۲٫ معماری و طراحی
این رویکرد بر چالش انجام پرس و جوهای فدرال با ترکیب SPARQL 1.1 و GeoSPARQL در زمینه نمودارهای دانش مکانی متمرکز است. با انجام این کار مراحل و پیاده سازی متفاوتی را برای فروشگاه سه گانه آپاچی مارموتا ارائه می دهیم. شکل ۱ گردش کار ما را برای انجام پرس و جوهای جغرافیایی فدرال در این اکوسیستم داده جدید برای جامعه GIS نشان می دهد. بنابراین، رویکرد ما شروع به جمعآوری ویژگیهای جغرافیایی از مختلف میکند ( ۱٫٫n) نقاط پایانی SPARQL، به عنوان مثال، همه ویژگی ها (از ۱ یا n نوع) را از یک مکان (ها) انتخاب شده پیدا کنید. این امکان جمعآوری ویژگیهای مکانی را از نمودارهای دانشی که GeoSPARQL را پشتیبانی میکنند، فراهم میکند. در مرحله بعد، با استفاده از ویژگی های مکانی جمع آوری شده به عنوان نقطه شروع، رویکرد ما از عملگرهای فضایی مرتبط با GeoSPARQL برای کشف ویژگی های جدید از انواع مختلف استفاده می کند ( ۱٫٫n) نمودارهای دانش از طریق نقاط پایانی SPARQL مربوط به آنها. مرحله زیر به فیلتر کردن ویژگیهای مکانی جمعآوریشده از نمودارهای دانش متمایز کمک میکند تا دادههای بهراحتی بهدستآمده را مطابق با ترجیحات کاربر مدیریت کند. مرحله چهارم امکان غنیسازی ویژگیهای مکانی را با اطلاعات اضافی از مخازن دیگر (مانند DBpedia یا Wikidata) فراهم میکند. در نهایت، رویکرد ما ما را قادر میسازد تا عناصر جمعآوریشده از نمودارهای دانش متنوع را از طریق یک وب برنامه کاربردی یا برنامه GIS مدیریت و بهرهبرداری کنیم و سناریوی جدیدی برای مقابله با اطلاعات مکانی فدرال در وب دادهها ارائه کنیم. برای دستیابی به این مراحل رویکرد ما، برخی از مسائل برطرف شد که در بخش های بعدی توضیح داده می شود.
نتایج بهدستآمده از طریق مراحل مختلف رویکرد GeoSPARQL فدرال ما را میتوان در استقرار محلی Apache Marmotta ذخیره کرد و امکان تحقق عناصر جمعآوریشده از نمودارهای دانش Web of Data را فراهم کرد. این ما را قادر می سازد تا از منابع فدرال (جغرافیایی) در یک محیط محلی پرس و جو و بهره برداری کنیم و عملیات سنتی برنامه های GIS را شبیه سازی کنیم. به همین ترتیب، رویکرد ما امکان بهره برداری مستقیم از منابع ذکر شده را با استفاده از جستارهای فدرال GeoSPARQL به نمودارهای دانش فراهم می کند.
۴٫۲٫۱٫ جمع آوری نمودارهای دانش مکانی
همانطور که قبلاً اشاره کردیم، آپاچی مارموتا نمی تواند منابع زمین فضایی فدرال را مدیریت کند. با در نظر گرفتن این محدودیت، رویکرد ما امکان جمعآوری نمودارهای دانش مکانی متنوع را از طریق اتصال فدرال به سرویسهای REST مرتبط با نقاط پایانی SPARQL وب دادهها فراهم میکند. به این ترتیب، سیستم توسعه نرم افزار Apache Marmotta را برای پشتیبانی از اتصال SPARQL 1.1 و GeoSPARQL انجام داد. این برنامه افزودنی استثناهای غیرمنتظره را در کلاسهای GeoSPARQL مدیریت میکند و دادههای موجود در Apache Marmotta را به منظور تجزیه دادهها به گویش PostgreSQL/PostGIS برای پردازش دادههای جمعآوریشده دستکاری میکند. بنابراین، یکی از اجزای اصلی این مرحله بر پیش پردازش داده های GeoSPARQL، ارسال پرس و جو مربوط به PostgreSQL و برگرداندن داده ها به Apache Marmotta بر اساس SPARQL 1.1 متمرکز است.
این مؤلفه رویکرد ما بر اساس فهرست ۱ است، که یک URL برای هر نقطه پایانی SPARQL وارد میکند و شامل یک جستجوی SPARQL برای جمعآوری ویژگیهای مکانی ( geoFeature ) از نمودارهای دانش متمایز از وب داده است. این مؤلفه ها امکان بازیابی اطلاعات مربوط به geoFeature ، به طور پیش فرض، URI، برچسب و هندسه را فراهم می کنند. مرحله بعدی این طرح پرس و جو، بازیابی عناصر هر نمودار دانش از هر نقطه پایانی SPARQL است.
فهرست ۱٫ طرح پرس و جو برای جمع آوری ویژگی های جغرافیایی از نمودارهای دانش.
نیاز: نشانیهای اینترنتی SPARQL Endpoint، geoFeature، نوع geoFeature و هندسه
اطمینان حاصل کنید: جمعآوری ویژگیهای جغرافیایی از نمودارهای دانش w (URI، برچسب، هندسه)
w ← {};
w .URI ← URI
{Extract geoFeature from specific Knowledge graphs (KGs)}
SPARQLEndpoint ← URI geoFeature ,
for all geoFeature ∈ SPARQLEndpoint do Set
geoFeature = query SPARQLEndpoint ۱ ( « UNPEQUENDY PARK )geoFeatureType ”)
UNION
query SPARQLEndpoint n (“ geoFeatureType ”)
geoFeatureList ← geoFeature (URI، برچسب، هندسه)
پایان برای |
۴٫۲٫۲٫ اعمال توابع GeoSPARQL و ویژگی های فیلتر در یک سناریوی فدرال
این جزء رویکرد ما به ویژه مرتبط است زیرا از پرس و جو و بهره برداری از نمودارهای دانش مکانی مبتنی بر GeoSPARQL پشتیبانی می کند. از آنجایی که توسعه ما از ۳۵ تابع GeoSPARQL پشتیبانی می کند، این امکان وجود دارد که از این نمودارهای دانش به روشی یکپارچه در سناریوی Web of Data بهره برداری کند. علاوه بر این، رویکرد ما میتواند عملگرها و فیلترهای مکانی را برای به دست آوردن منابع خاص از وب دادهها به روشی فدرال ترکیب کند. بنابراین، سیستم می تواند از نتایج پرس و جو قبلی برای انجام یک پرس و جو فضایی (بر اساس GeoSPARQL) با استفاده از مجموعه ای از ویژگی ها استفاده کند که به طور کیفی روابط فضایی تعریف شده در RCC-8 (حساب ارتباط منطقه) را نشان می دهد. این فرآیند می تواند منابع اصلی را با داده های اضافی جمع آوری شده از نقاط پایانی (Geo)SPARQL غنی کند.
این مؤلفه رویکرد ما بر اساس فهرست ۲ است، که اطلاعاتی را در مورد ویژگی(های) جغرافیایی جمع آوری شده از مرحله قبل می گیرد. با در نظر گرفتن این geoFeature ( ها )، رویکرد ما geoFeature(های) اضافی را از نمودارهای دانش یکسان یا اضافی بازیابی می کند. برای جمع آوری این/این ویژگی(های) جغرافیایی جدید ، رویکرد ما عملیات فضایی مبتنی بر RCC8 را اعمال می کند زیرا رویکرد ما کاملاً شکایت GeoSPARQL است. علاوه بر این، این مرحله امکان فیلتر کردن geoFeature(های) را با استفاده از یک یا چند نوع geoFeature(ها) می دهد.، افزایش پتانسیل پرس و جوی جغرافیایی. مرحله بعدی این طرح پرس و جو جمع آوری عناصر هر نمودار دانش از هر نقطه پایانی SPARQL است.
فهرست ۲٫ طرح پرس و جو برای اعمال GeoSPARQL و فیلترها بر اساس ویژگی ها.
مورد نیاز: URLهای SPARQL Endpoint، geoFeature، نوع geoFeature، هندسه و اپراتور(های) RCC8 .
اطمینان حاصل کنید: جمعآوری ویژگیهای جغرافیایی از نمودارهای دانش w (URI، برچسب، هندسه) پس از اعمال عملگر(های) فضایی
برای geoFeatureList
تنظیم geoFeature’ = پرس و جو SPARQLEndpoint ۱ (« geoFeatureType ۱ » )
UNION
query SPARLEQueFeatureFeatureFeature ( UNION query ۲۲ )» nd SPARQLEndpoint n (« geoFeatureType n »)
geoFeatureList’ ← geoFeature’ (URI، برچسب، هندسه)
geoFeatureListRCC8 ← RCC8_operator(geoFeatureList’)، هندسه،
نوع داده (بولی یا شناور).
پایان برای |
۴٫۲٫۳٫ غنی سازی با اطلاعات اضافی
هر منبع داده ای اغلب شامل ارجاعات خاصی به انواع دیگر داده ها است و منابع داده های جغرافیایی هیچ ناهنجاری ندارند. این مراجع اهمیت خود را زمانی که ما با منابع داده های حوزه تخصصی سروکار داریم گسترش می دهند. با این وجود، کاربران غیر متخصص اغلب دانستن و به کارگیری این داده های پنهان را چالش برانگیز می دانند [ ۵۱ ]. بنابراین، فرآیند غنی سازی فضایی بازیابی چنین اطلاعاتی و صریح ساختن آن را پیشنهاد می کند [ ۵۲ ].
رویکرد ما ما را قادر می سازد تا اطلاعات اضافی را از ویژگی های مکانی استخراج شده از ترکیب عملگرها و فیلترهای مکانی در مرحله قبل جمع آوری کنیم تا شرح منابع خاص را با اطلاعات تکمیلی از وب داده ها غنی سازیم. ما در نظر داریم که این مرحله گردش کار میتواند ویژگیها را افزایش دهد زیرا دادههای مکانی گاهی با ویژگیهای محدود متمرکز بر ویژگیهای هندسی منتشر میشوند. بنابراین، استفاده از وب داده ها برای غنی سازی منابع (جغرافیایی) با اطلاعات توصیفی بیشتر می تواند مفید باشد. با این وجود، یکی از جنبههای رویکرد ما این است که ما همیشه نمیتوانیم غنیسازی را با اطلاعات اضافی تضمین کنیم، زیرا در برخی موارد، پیشنهاد ما نمیتواند هیچ تطابقی بین منابع (جغرافیایی) و منابع وب دادهها ایجاد کند.
برای انجام این فرآیند غنیسازی، این رویکرد به نام منابع ( rdfs:label ) و انواع ( rdf:type ) برای جستجوی این منابع در وب دادهها، به طور مشخص، در DBpedia متکی است، اگرچه این رویکرد یک تنظیم انعطافپذیر برای هر نقطه پایانی SPARQL را که کاربران در نظر می گیرند تعریف کنید. DBpedia منبع حیاتی این فرآیند است زیرا به عنوان یک پایگاه دانش بین دامنه ای در نظر گرفته می شود و هسته ای از وب داده ها باقی می ماند [ ۵۳ ]]. هستی شناسی آن ۶۸۵ کلاس را جمع آوری می کند که یک سلسله مراتب فرعی را تشکیل می دهند و با ۲۷۹۵ ویژگی توصیف می شوند. علاوه بر این، این هستی شناسی تقریباً شامل ۴۲۳۳۰۰۰ نمونه است که ۷۳۵۰۰۰ نمونه با کلاس Place مرتبط هستند. به این ترتیب، این نمودار دانش ممکن است یک عنصر کلیدی برای غنی سازی هر منبع جغرافیایی باشد.
فهرست ۳٫ طرح پرس و جو برای جمع آوری اطلاعات اضافی.
مورد نیاز: آدرسهای اینترنتی DBpedia SPARQL Endpoint، geoFeature، نوع geoFeature، برچسب.
اطمینان حاصل کنید: جمع آوری اطلاعات اضافی درباره ویژگی(های) geoFeature از DBpedia z (URI، موضوع، چکیده، نوع و تصویر)
z ← {};
z .URI ← URI
{Extract more data related to geoFeature from DBpedia }
geoFeatureList’ ← Label geoFeature’ ,
for all geoFeature’ ∈ SPARQLEndpoint do Set
geoFeature ‘ = query DBpediaSPARQLE “ nd پرس و جو DBpediaSPARQLEنقطه ۱ (” چکیده “) پرس و جو
اختیاری
SPARQLEndpoint n (” موضوع “) پرس و جو
اختیاری
SPARQLEndpoint n (” نوع “) پرس و جو
اختیاری
SPARQLEndpoint n (” تصویر “)
geoFeatureList” ← ‘ (جغرافیا، نوع، نوع، موضوع، شکل جغرافیایی، موضوع تصویر)
پایان برای |
فهرست ۳ یک طرح پرس و جوی SPARQL را برای جمع آوری اطلاعات اضافی از ویژگی های مکانی ارائه می دهد. اگرچه فکر میکنیم این مرحله میتواند برای جمعآوری اطلاعات مربوط به ویژگیهای فیلتر شده به صورت مکانی و بر اساس نوع (ها) (از مرحله قبل) مفید باشد، این طرح پرس و جو را میتوان در مورد هر ویژگی جمعآوریشده در مراحل متمایز رویکرد ما انجام داد. بنابراین، طرح پرس و جو از عناصر نوع و برچسب geoFeature(های) جمع آوری شده قبلی برای جستجوی این ویژگی ها در DBpedia استفاده می کند. هنگامی که یک تطابق انجام می شود، رویکرد ما اطلاعات اضافی مرتبط با چکیده، موضوع، برچسب (به زبان های مختلف، زمانی که در دسترس باشد) و تصاویر بازیابی می کند. با توجه به اینکه این عناصر می توانند در برخی موارد حذف شوند ( geoFeature ) ، آنها اختیاری در نظر گرفته می شوندعناصر در طرح پرس و جو مرحله بعدی این طرح پرس و جو جمع آوری عناصر از DBpedia و ارائه آنها به کاربر با غنی سازی داده های اصلی است.
۴٫۲٫۴٫ بهره برداری از نتایج
برای بررسی نتایج بهدستآمده از مراحل قبلی، دو گزینه برای برخورد با نتایج بهدستآمده از جستارهای GeoSPARQL فدرال ایجاد کردیم. از یک طرف، یک برنامه وب که به عنوان یک کلاینت SPARQL کار می کند و داده های مکانی را روی نقشه نشان می دهد. این برنامه تحت وب با Node.js و Leaflet توسعه یافته است و یک نقطه پایانی SPARQL متصل به Apache Marmotta برای نوشتن پرس و جوهای GeoSPARQL فدرال را در اختیار کاربران نهایی قرار می دهد. هنگامی که یک پرس و جو اجرا می شود (فرض می کنیم که به درستی شکل گرفته است)، برنامه اجازه می دهد تا نتایج پرس و جو را به صورت JSON یا جدول ارائه دهد. علاوه بر این، زمانی که نتایج حاوی اطلاعات مکانی باشد، گزینه سومی ارائه می شود که امکان نمایش اطلاعات بر اساس GeoSPARQL بر روی نقشه را فراهم می کند.
از سوی دیگر، ما رویکرد خود را به ابزار QGIS متصل کردیم زیرا سعی کردیم نمودارهای دانش (جغرافیایی) را به جامعه GIScience ببندیم. بنابراین، ما از SPARQLing Unicorn QGIS Plugin ( https://plugins.qgis.org/plugins/sparqlunicorn/ (در ۲۳ نوامبر ۲۰۲۱ در دسترس قرار گرفت)) برای اتصال به رویکرد خود و QGIS دوباره استفاده کردیم. این امکان افزودن لایههای GeoJSON به QGIS را با دادههای جمعآوریشده از جستارهای فدرال GeoSPARQL در وب دادهها فراهم میکند. در اینجا، افزونه به پارامترهای اتصال به نقطه پایانی SPARQL نمودارهای دانش انتخاب شده برای جمع آوری ویژگی ها و هندسه های موجود نیاز دارد ( شکل ۲ را ببینید ). توضیح مفصلی در مورد اتصال رویکرد ما و QGIS در https://github.com/Osw1997/Guide-connection-for-Apache-marmotta-and-QGIS موجود است.(دسترسی در ۲۳ نوامبر ۲۰۲۱).
۵٫ مثال ها
در این بخش، ما دو نمونه از استفاده از رویکرد جستارهای GeoSPARQL فدرال خود را با استفاده از منابع متنوع وب داده ارائه می کنیم. در مرحله بعد، ما جزئیات مربوط به هر یک از آنها را ارائه می دهیم.
۵٫۱٫ پارکینگ دوچرخه و مکان های تاریخی
در این مثال در حال اجرا، ما با چهار نمودار دانش متمایز مانند datos.zaragoza.es (گراف دانش با داده های باز از شهر ساراگوزا )، LinkedGeoData (تلاشی که از اطلاعات جمع آوری شده توسط پروژه OpenStreetMap استفاده می کند و آن را به عنوان در دسترس قرار می دهد، سروکار داریم. یک پایگاه دانش RDF بر اساس اصول داده های پیوندی – http://linkedgeodata.org/ (دسترسی در ۲۳ نوامبر ۲۰۲۱))، datos.ign.es (در ۲۳ نوامبر ۲۰۲۱ قابل دسترسی است) (گراف دانشی که اطلاعات مربوط به پایگاه داده ملی توپوگرافی ( Base Topográfica Nacional ۱:۱۰۰٫۰۰۰—BTN100) ( https://datos.ign.es/btn100.html (دسترسی شده در ۲۳ نوامبر ۲۰۲۱)) از آژانس ملی نقشه برداری اسپانیا (Instituto Geográfico Nacional de España (IGN-E)— http://www.ign.es/ (دسترسی در ۲۳ نوامبر ۲۰۲۱))، و یک مخزن محلی با منابع مستقر شده از LinkedGeoData.
این مثال تمام اطلاعات مربوط به پارکینگ دوچرخه را از یک مکان خاص، به طور خاص در ساراگوزا (اسپانیا) جستجو می کند. برای آن، ما یک پرسش SPARQL ایجاد کردیم تا پارکینگ دوچرخه این شهر را در چندین نمودار دانش با استفاده از مؤلفه فدرال سیستم خود جمع آوری کنیم. فهرست ۴ یک درخواست SPARQL را نشان میدهد که به دو مخزن مختلف ارسال شده است، به طور مشخص به https://www.zaragoza.es/sede/portal/datos-abiertos/servicio/sparql (در ۲۳ نوامبر ۲۰۲۱ در دسترس قرار گرفته است) و LinkedGeoData، برای دریافت پارکینگ دوچرخه مورد مطالعه ما
فهرست ۴٫ یک جستجوی SPARQL به datos.zaragoza.es و LinkedGeoData.
PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns# >
PREFIX geof: < http://www.opengis.net/def/function/geosparql/ >
واحدهای PREFIX : < http://www.opengis.net/def/uom/OGC/1.0/ >
PREFIX xsd: < http://www.w3.org/2001/XMLSchema# >
PREFIX vocab: < http://vocab. linkeddata.es/datosabiertos/def/urbanismo-infraestructuras/ > را انتخاب کنید * جایی که {
# هندسه های مرتبط با پارکینگ دوچرخه در اسپانیا (نقطه پایانی SPARQL ساراگوسا) را دریافت کنید.
سرویس < http://datos.zaragoza.es/sparql > {
انتخاب کنید ?sb ?park where {
?sb ?ob vocab:equipamiento#AparcamientoBicicleta.
?sb ?p ?o ;
< http://www.w3.org/2003/01/geo/wgs84_pos#geometry > ?o .
?o < http://www.opengis.net/ont/geosparql#asWKT > ?og .
# فیلتر داده هایی که دارای فیلتر سیستم ژئودزی WGS84
(regex(?o, “WGS84”))
bind(str(?og) به عنوان ?park)
} محدودیت ۵۰
}
} |
مرحله زیر از رویکرد ما امکان استفاده از پردازش جغرافیایی با استفاده از عملگرهای فضایی GeoSPARQL در مورد دادههای مکانی که قبلاً جمعآوری شده است را میدهد. بنابراین، ما از پارکینگ دوچرخه ساراگوزا که از https://www.zaragoza.es/sede/portal/datos-abiertos/servicio/sparql (دسترسی در ۲۳ نوامبر ۲۰۲۱) و LinkedGeoData گردآوری شده بود، استفاده کردیم و یک بافر در اطراف هر پارکینگ دوچرخه ایجاد کردیم تا بازیابی شود. نزدیک به نقاط مورد علاقه (POI) از نمودارهای دانش مختلف وب داده ها. علاوه بر این، اگر ما به POI های خاصی علاقه مند هستیم، رویکرد ما امکان ترکیب عملگرها و فیلترهای مکانی را برای به دست آوردن POI های خاص می دهد. فهرست ۵ یک جستار فدرال GeoSPARQL را برای به دست آوردن POI های تاریخی در نزدیکی پارکینگ دوچرخه ارائه می دهد که توسط جستجوی فهرست ۴ جمع آوری شده است.. در این مورد، ( فهرست ۵ )، درخواست فدرال GeoSPARQL به چهار نقطه پایانی SPARQL مجزا در نظر گرفته میشود، مانند https://www.zaragoza.es/sede/portal/datos-abiertos/servicio/sparql (در ۲۳ نوامبر قابل دسترسی است. ۲۰۲۱)، LinkedGeoData، datos.ign.es (در ۲۳ نوامبر ۲۰۲۱ قابل دسترسی است)، و یک مخزن محلی LinkedGeoData. علاوه بر این، با توجه به ترکیب عملگرهای مکانی و فیلترها بر اساس نوع POI اعمال شده در فهرست ۵ ، برخی از نتایج نشان داده شده در جدول ۱ را به دست آوردیم ، که در آن پارکینگ دوچرخه های متنوع در نزدیکی POI های تاریخی و فاصله بین آنها بر حسب متر (۱۰۰۰ متر) مرتبط است. .
فهرست ۵٫ یک جستار فدرال GeoSPARQL برای به دست آوردن POI های تاریخی در نزدیکی پارکینگ دوچرخه.
PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns# >
PREFIX geof: < http://www.opengis.net/def/function/geosparql/ >
واحدهای PREFIX : < http://www.opengis.net/def/uom/OGC/1.0/ >
PREFIX xsd: < http://www.w3.org/2001/XMLSchema# >
PREFIX vocab: < http://vocab. linkeddata.es/datosabiertos/def/urbanismo-infraestructuras/ > را انتخاب کنید * جایی که {
# هندسه های مرتبط با پارکینگ دوچرخه در اسپانیا (نقطه پایانی SPARQL ساراگوسا) را دریافت کنید.
سرویس < http://datos.zaragoza.es/sparql > {
انتخاب کنید ?sb ?park where {
?sb ?ob vocab:equipamiento#AparcamientoBicicleta .
?sb ?p ?o ;
< http://www.w3.org/2003/01/geo/wgs84_pos#geometry > ?o .
?o < http://www.opengis.net/ont/geosparql#asWKT > ?og .
# فیلتر داده هایی که دارای فیلتر سیستم ژئودزی WGS84
(regex(?o, “WGS84”))
bind(str(?og) به عنوان ?park)
} محدودیت ۵۰
}
# Recover Points Of Interest (POI) از سرویس IGN.es
< https://datos.ign.es/sparql/ > {
?titlePOI ?geometriaPOI را در آنجا انتخاب کنید {
?sa < https://datos.ign.es/def/btn100#LugarDeInteres > .
?s < http://purl.org/dc/terms/title > ?titlePOI .
?s <http://www.opengis.net/ont/geosparql#hasGeometry > ?geoIns.
?geoIns < http://www.opengis.net/ont/geosparql#asWKT > ?geom .
bind(str(?geom) as ?geometriaPOI)
bind(“POI” as ?tipo)
} limit 25 offset 100
}
# مکان های تاریخی را از سرور محلی ما بازیابی کنید که شامل مجموعه داده ای از LinkedGeoData است.
service < http://192.168.100.10:7200/repositories/IDRep > {
?titleHistoric ?geometriaHistoric where {
graph < http://www.linkedGeodata.org/historic > {
?nodes < http://www.w3. org/2000/01/rdf-schema_label > ?labelEsp_.
?گره ها <http://geovocab.org/geometry_geometry > ?geoIns.
?geoIns < http://www.opengis.net/ont/geosparql_asWKT > ?geoEsp_ .
bind(str(?geoEsp_) به عنوان ?geometriaHistoric) .
bind(str(?labelEsp_) به عنوان ?titleHistoric) .
bind(“TurismoEspania” به عنوان ?tipo)
}
}
}
# سپس برای هر ترکیبی از نقاط
# از ۳ نمودار قبلی (Bycicles، POI و مکان های تاریخی) فاصله بگیرید.
bind(geof:distance(?park, ?geometriaPOI, units:meter) as ?D_m_POI)
bind(geof:distance(?park, ?geometriaHistoric, units:meter) as ?D_m_Historic)
# در نهایت نقاطی را که فاصله آنها بیشتر از یک کیلومتر بین نقاط
filter((?D_m_POI < 1000) || (?D_m_Historic < 1000))
} |
در ادامه روند کاری رویکردمان، اطلاعات بیشتری در مورد POIهای تاریخی (که در آخرین مرحله به دست آمد) در نزدیکی پارکینگ دوچرخه جمع آوری کردیم. بنابراین، برای مثال، دادههای اصلی کاخ فوئنکلارا ( https://es.dbpedia.org/page/Palacio_de_Fuenclara (دسترسی در ۲۳ نوامبر ۲۰۲۱)) را با توضیحات (dbo:abstract)، تصویر ( prop-) غنیسازی کردیم. es:imagen) و موضوعات مرتبط (dct:subject) ارائه شده توسط esDBpedia ( جدول ۲ را ببینید ). برای این مورد، ما از نسخه اسپانیایی DBpedia ( https://es.dbpedia.org/ استفاده کردیم(دسترسی در ۲۳ نوامبر ۲۰۲۱)) زیرا ما با اطلاعات مربوط به اسپانیا سروکار داشتیم، و از این رو، این نسخه خاص DBpedia دارای منابع دقیق تری است که ممکن است به غنی سازی منابع جغرافیایی جمع آوری شده از مراحل قبلی رویکرد ما کمک کند.
همانطور که در بالا ذکر شد، رویکرد ما از روش های مختلفی برای نمایش نتایج جمع آوری شده پشتیبانی می کند. در این مورد، ما عناصر جمعآوریشده را از نمودارهای مختلف دانش مکانی در برنامه وب توسعهیافته تجسم کردیم ( شکل ۳ را ببینید ).
۵٫۲٫ باغ وحش ها و موزه ها
این مثال سه نمودار دانش مختلف را در نظر میگیرد: LinkedGeoData، datos.ign.es (در ۲۳ نوامبر ۲۰۲۱ قابل دسترسی است)، و FOODIE (سکوی ابری برای جمعآوری، ذخیرهسازی، اشتراکگذاری و تجزیه و تحلیل دادههای ارجاعشده مکانی و غیرمکانی مرتبط با کشاورزی، جنگلداری). ، و محیط زیست— https://www.foodie-cloud.org/ (در ۲۳ نوامبر ۲۰۲۱ قابل دسترسی است)).
در این مثال، ما به دنبال باغوحشها و موزههایی میگردیم که در یک مرز اداری خاص در اسپانیا، به طور خاص، استانها قرار دارند. برای جمعآوری این منابع از وب دادهها، یک جستار GeoSPARQL ساختیم تا تمام هندسههای استانهای مختلف را به دست آوریم و پرس و جوی ذکر شده را برای بازیابی همه باغوحشهای موجود در اسپانیا (از Foodie’s SPARQL Endpoint) و موزهها (از Endpoint SPARQL LinkedGeoData) تکمیل کنیم. پس از به دست آوردن هندسه ها، عملیات GeoSPARQL “contains” را وارد کردیم که پارامترهای ورودی آن متغیرهای مرتبط با هندسه های جمع آوری شده هستند. فهرست ۶ پرس و جو اجرا شده در Apache Marmotta را نشان می دهد تا منابع این مورد مطالعه را از Web of Data جمع آوری کند.
در این مورد، ما نتایج را در جدول ارائه نمی دهیم زیرا هندسه های هر استان لفظ هایی را با مجموعه ای دقیق از مختصات ارائه می دهند. به هر حال، این مناطق از انواع هندسه پیچیده تشکیل شده اند. با توجه به تجسم نتایج، ما پرس و جو قبلی را در QGIS با استفاده از افزونه SPARQLing Unicorn QGIS تنظیم کردیم تا از رویکرد توسعه یافته خود در Apache Marmotta پشتیبانی کند. شکل ۴ نتایج جمع آوری شده را نشان می دهد، که در آن استان ها به صورت چند ضلعی (اشکال آبی)، باغ وحش ها به صورت نقاط قرمز و موزه ها به صورت نقاط سبز نشان داده شده اند.
فهرست ۶٫ یک جستار فدرال GeoSPARQL برای به دست آوردن باغ وحش ها و موزه های موجود در استان های اسپانیا.
PREFIX geof: < http://www.opengis.net/def/function/geosparql/ >
واحدهای PREFIX: < http://www.opengis.net/def/uom/OGC/1.0/ >
PREFIX xsd: < http: //www.w3.org/2001/XMLSchema# >
PREFIX vocab2: << http://vocab.linkeddata.es/datosabiertos/def/sector-publico/ > ?titleProv ?titlePlace ?placeFrom ?geoProv ?geoPlace Where {
#
سرویس استانها را انتخاب کنید < https://datos.ign.es/sparql > {
select ?s ?titleProv ?geoProv where {
?s ?p vocab2:territorio#Provincia .
?s < http://www.opengis.net/ont/geosparql#hasGeometry > ?o ;
# نام استان
<http://purl.org/dc/terms/title > ?titleProv.
?o < http://www.opengis.net/ont/geosparql#asWKT > ?geo_ .
bind(str(?geo_) as ?geoProv)
}
}
# یک اتحاد بین باغ وحش ها و موزه ها ایجاد کنید تا نمودار بزرگتری ایجاد کنید.
{
#
سرویس باغ وحش < https://www.foodie-cloud.org/sparql > {
انتخاب کنید ?titlePlace ?geoPlace ?placeFrom where {
?sF a < http://gis.zcu.cz/SPOI/Ontology#zoo > . ?sF < http://purl.org/dc/elements/1.1/title > ?titlePlace .
?sF < http://www.opengis.net/ont/geosparql#asWKT > ?geo_ .
?sF <http://www.opengis.net/ont/geosparql#sfWithin > ?w .
bind(str(?geo_) as ?geoPlace)
bind(“Foodie” as ?placeFrom)
filter(regex(?w، “Spain”)) . }
limit 25
} UNION { # Museums service < http://linkedgeodata.org/sparql > { select distinct ?titlePlace ?geoPlace ?placeFrom where { ?sb ?p < http://linkedgeodata.org/ontology/Museum > . ?s < http://www.w3.org/2000/01/rdf-schema#label > ?titlePlace . ?s < http://geovocab.org/geometry#geometry > ?o . ?o < http://www.opengis.
> ?o2 .
bind(str(?o2) به عنوان ?geoPlace)
bind(“LinkedGeoData” به عنوان ?placeFrom)
bind(xsd:float(strbefore(strafter(str(?geoPlace)، “”)، “)”)) به عنوان ?c2)
bind (xsd:float(strbefore(strafter(str(?geoPlace)، “(“)، “”)) به عنوان ?c1)
فیلتر(?c1 > -1 && ?c1 < 0 && ?c2 > 40 && ?c2 < 42 )
} limit 25
}
}
# هندسههایی را فیلتر کنید که استانها حداقل یک باغوحش/موزه دارند.
bind(geof:sfContains(?geoProv, ?geoPlace) as ?contains)
filter(str(?contains) = ‘t’)
} |
۶٫ بحث و نتیجه گیری
همانطور که در این کار اشاره کردیم، چندین رویکرد بر افزودن مولفه مکانی به وب داده ها، توسعه موارد استفاده و ابزارهای مرتبط برای افزودن داده های مکانی “سنتی” این جدید متمرکز شده است.سناریویی برای جامعه GIScience. این شواهدی را ارائه میکند که نمودارهای دانش مکانی در حال افزایش هستند و از این رو، مستلزم روشهای جدیدی برای تفکر در مورد نحوه تعامل علم GIS و جامعه آن با نمودارهای دانش (جغرافیایی) است. از این نظر، رویکرد ما به ما اجازه داده است که نمودارهای دانش (جغرافیایی) را بر اساس GeoSPARQL درخواست بازیابی و مصرف کنیم. به این ترتیب، این کار به پر کردن شکاف کمک میکند و بهرهبرداری از منابع مبتنی بر GeoSPARQL را در یک محیط توزیعشده و از طریق شیوههای فدرال (پرسشها) ممکن میسازد، و به جامعه GIScience اجازه میدهد تا از غنای وب دادهها بهرهبرداری کند.
با توجه به منابع جغرافیایی موجود در Web of Data، اگرچه تعداد فزاینده ای از رویکردها GeoSPARQL را اتخاذ می کنند، ما آگاه هستیم که اکثر نمودارهای دانش اصلی موجود در وب داده (به عنوان مثال، Wikidata یا DBpedia) داده های مکانی را با استفاده از واژگان پایه جغرافیایی نشان می دهند. ( https://www.w3.org/2003/01/geo/(دسترسی در ۲۳ نوامبر ۲۰۲۱)) (WGS84 lat/long). این واژگان WGS84 یکی از واژگان برتر در زمینه Web of Data در میان واژگان موجود برای توصیف نمودارهای دانش مکانی است. این واژگان پایه فضای نامی را برای نمایش lat (itude)، long (itude) و سایر اطلاعات در مورد چیزهایی که در فضایی قرار دارند، با استفاده از WGS84 به عنوان منبع مرجع فراهم می کند. با در نظر گرفتن این سناریو، اکثر منابع ویژگی ها را به عنوان نقاط نمایش می دهند و GeoSPARQL را پشتیبانی نمی کنند. با این حال، تعداد فزاینده ای از ابتکارات در حال اجرای استاندارد OGC ذکر شده هستند. علیرغم محدودیت رویکرد ما برای مقابله با اکثر نمودارهای دانش مکانی اصلی، ما می توانیم از انواع هندسه پیچیده تر و مجموعه ای جامع از عملگرهای مکانی برای استفاده از پتانسیل این اطلاعات مکانی موجود در وب داده استفاده کنیم.
صرف نظر از تعهد مشترک به نمودارهای دانش و اینکه چگونه، در این خط، کار ما رویکردی را برای درخواست، بازیابی و مصرف نمودارهای دانش مکانی به صورت فدرال ارائه میکند، دانش عمیق در مورد این منابع وب دادهها مورد نیاز است. ، زیرا استفاده از هر یک از این منابع به دلیل تنوع هستی شناسی ها، ساختارهای هستی شناسی و رابط های دسترسی می تواند چالش برانگیز باشد.
رویکرد ما یک پیاده سازی اولیه است که برای نشان دادن پتانسیل جامعه GIScience برای درخواست، بازیابی و مصرف نمودارهای دانش توسعه یافته است. از این نظر، اگرچه کار ما به ما اجازه می دهد تا با انواع هندسه پیچیده بر اساس GeoSPARQL سروکار داشته باشیم، محدودیت هایی برای مدیریت حجم زیادی از ویژگی های جغرافیایی با هندسه پیچیده وجود دارد، زیرا این ویژگی ها با داده های مفصل (هندسی) نشان داده می شوند.
همانطور که قبلاً ذکر کردیم، ما رویکرد خود را بر روی Apache Marmotta توسعه دادیم و از طریق دو مثال با استفاده از چندین نمودار دانش (جغرافیایی) مستقر در موتورهای فروشگاه های سه گانه مختلف مانند Virtuoso و Apache Marmotta آزمایش شد. با این حال، ما رویکرد خود را با موتورهای دیگر، مانند Apache Jena، GraphDB، یا پارلمان، به دلیل عدم وجود نمودارهای دانش مکانی مستقر در موتورهای فروشگاه سه گانه مورد آزمایش قرار ندادیم. با این وجود، ما برای استقرار چندین منبع جغرافیایی در مورد برخی از این موتورها و انجام آزمایشات مختلف با استفاده از برخی از معیارهای اخیر GeoSPARQL [ ۷ ، ۴۷ ، ۴۸ ، ۴۹ ] کار خواهیم کرد.
با توجه به توسعه برنامه های کاربردی وب، نسخه فعلی به ما اجازه می دهد تا منابع جمع آوری شده از پرس و جوهای جغرافیایی فدرال را به عنوان جایگزینی سبک برای اتصال QGIS به وب داده ها نمایش دهیم. با این حال، محدودیت هایی در رابطه با عناصر تجسمی و تعامل با منابع جغرافیایی وجود دارد. این به دلیل توسعه مداوم نسخه فعلی است، و بنابراین، ما نسخه های مختلف این برنامه وب را توسعه خواهیم داد.
این مقاله رویکردی را برای درخواست و بازیابی نمودارهای دانش مکانی از طریق یک روش فدرال با ترکیب استانداردهای SPARQL 1.1 و GeoSPARQL ارائه کرده است. علاوه بر این، رویکرد ما به ما این امکان را میدهد که نمودارهای دانش مکانی را مصرف کنیم و از دادهها مستقیماً از طریق جستارهای GeoSPARQL فدرال، نمایش دادههای جمعآوریشده در یک وب برنامه و از طریق QGIS بهرهبرداری کنیم. علاوه بر این، مشارکت ما از نمودارهای دانش مکانی و غیر مکانی استفاده کرد و پتانسیل رویکرد ما را از طریق دو مثال نشان داد که نمودارهای دانش مختلف (جغرافیایی) را از وب داده داده ها مدیریت می کند.