GeoSPARQL 1.1: انگیزه ها، جزئیات و کاربردهای به روز رسانی ده ساله به مهم ترین استاندارد LOD جغرافیایی †

در سال ۲۰۱۲، کنسرسیوم فضایی باز GeoSPARQL را منتشر کرد که «هستی شناسی RDF/OWL برای اطلاعات [مکانی]»، «توابع گسترش SPARQL» برای انجام عملیات فضایی بر روی داده های RDF و «قوانین RIF» تعریف مستلزماتی را که باید از تطبیق الگوی نمودار ترسیم شوند، تعریف کرد. در بیش از ۸ سال پس از انتشار، GeoSPARQL به مهمترین استاندارد فضایی وب معنایی تبدیل شده است، همانطور که با ارجاع به آن در سایر استانداردهای وب معنایی و استفاده گسترده آن برای داده های وب معنایی قضاوت می شود. به روز رسانی GeoSPARQL در سال ۲۰۱۹ پیشنهاد شد تا نسخه ۱٫۱ را با منشور ارائه کند: رسیدگی به درخواست های تغییر برجسته و منبع جدید از جامعه کاربر و “ارائه بهتر” استاندارد، یعنی پیوند بهتر همه قطعات استاندارد و بهتر عناصر را مستند و مثال بزنید. به روز رسانی های مورد انتظار شامل نمایش های هندسی جدید، هم ترازی با دیگر هستی شناسی ها، مدیریت سیستم های ارجاع فضایی جدید، و ارائه مصنوعات جدید. این مقاله درخواست‌های تغییر انگیزشی و به‌روزرسانی‌های حاصل واقعی را در نسخه کاندید ۱٫۱ استاندارد در کنار پیاده‌سازی مرجع و مثال‌های استفاده توصیف می‌کند. ما همچنین تئوری پشت به‌روزرسانی‌های خاص، پیاده‌سازی اولیه بسیاری از بخش‌های استاندارد و انتظاراتمان برای استفاده GeoSPARQL 1.1 را شرح می‌دهیم.

کلید واژه ها:

GeoSPARQL ; GeoSPARQL 1.1 ; فضایی ؛ جغرافیایی ; وب معنایی ؛ RDF _ جغد ; OGC ; کنسرسیوم فضایی باز استاندارد ؛ هستی شناسی

۱٫ مقدمه و انگیزه

استاندارد GeoSPARQL که در سال ۲۰۱۲ توسط کنسرسیوم فضایی باز (OGC) ( https://www.ogc.org ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) صادر شد، یکی از محبوب ترین استانداردهای وب معنایی برای داده های مکانی است. ارجاعات به GeoSPARQL در استانداردهای معروف دیگر، مانند DCAT2 [ ۱ ] و CIDOC-CRM [ ۲ ، ۳ ] نشان می دهد که این GeoSPARQL محبوب است، همانطور که پیوندهای ورودی در واژگان باز پیوند داده شده ( https://lov.linkeddata.es/ ) محبوب هستند. مجموعه داده/lov/vocabs/gsp ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) و فهرست پیاده‌کننده‌هایی که شامل اکثر فروشندگان محبوب سه‌گانه است، فهرستی از آنها در اینجا گردآوری شده است: https://github.com/opengeospatial/ogc-geosparql /issues/59، در ۳۰ اکتبر ۲۰۲۱ مشاهده شد. نسخه اصلی – GeoSPARQL 1.0 [ ۴ ] – شامل:

یک مشخصات : سند:

–

سند اصلی GeoSPARQL که اکثر عناصر استاندارد از جمله عناصر هستی شناسی، توابع جغرافیایی را که ممکن است بر روی داده های فرمت توصیف منابع (RDF) [ ۵ ] از طریق پرس و جوهای SPARQL [ ۶ ، ۷ ] انجام شود، در قالب های قابل خواندن توسط انسان و با تکه های کد تعریف می کند. ، قوانین مستلزم در قالب تبادل قوانین (RIF) [ ۸ ] برای استدلال و الزامات RDF و تست های انتزاعی برای آزمایش داده های هستی شناسی و اجرای تابع.
یک طرح RDF/OWL [ ۹ ] :

–

هستی شناسی GeoSPARQL – مدل داده وب معنایی – در یک فایل RDF.
یک واژگان RDF :

–

واژگان ویژگی های ساده برای «تعریف انواع هندسه SimpleFeature» برگرفته از [ ۱۰ ] در اصطلاحات RDF/OWL، همچنین در یک فایل RDF.

در این شکل، GeoSPARQL 1.0 به طور گسترده مورد استفاده قرار گرفته است. با این حال، درخواست هایی برای به روز رسانی آن توسط OGC دریافت شده است. در این نشریه، توسعه مقاله کارگاه [ ۱۱ ]، در ادامه این بخش، در مورد انگیزه های به روز رسانی GeoSPARQL 1.0 بحث می کنیم، محتوای نسخه برنامه ریزی شده GeoSPARQL 1.1 (برای آخرین فرم انتشار نامزد GeoSAPRQL به مخزن کاری GeoSPARQL مراجعه کنید. ۱٫۱: https://github.com/opengeospatial/ogc-geosparql ، دسترسی به ۳۰ اکتبر ۲۰۲۱) در بخش ۲ و پیاده سازی مرجع و موارد استفاده در بخش ۳ و بخش ۴ . در نهایت، در بخش ۵، ما یک چشم انداز برای درخواست های ویژگی های بیشتر ارائه می دهیم که احتمالاً در نسخه های آینده یا جایگزین های GeoSPARQL برطرف می شوند.

همانطور که استاندارد GeoSPARQL 1.1، در زمان انتشار [ ۱۱ ] هنوز در حال توسعه بود، ما به تغییراتی اشاره می کنیم که از آن زمان رخ داده است. این تغییرات شامل حذف کلاس geo:SpatialMeasure و گنجاندن چندین ماده تکمیلی (ترازبندی، شکل‌های SHACL و زمینه‌های JSON-LD) است که در این نشریه به طور گسترده درباره آنها توضیح می‌دهیم.

داده های فضایی OGC و کنسرسیوم وب جهانی (W3C) در گروه کاری وب (SDWWG) فهرستی از بهترین نکات را منتشر کرد (به https://w3c.github.io/sdw/bp/ مراجعه کنید ، در ۳۰ اکتبر ۲۰۲۱ برای یک نسخه قابل دسترس از نقاط آنلاین و [ ۱۲ ] برای انتشارات دانشگاهی مربوطه) برای رتبه بندی داده های مکانی مبتنی بر وب. SDWWG از طریق استفاده از آن سیستم رتبه‌بندی و کارهای دیگر خاطرنشان کرد: «بهترین روش برای بازگرداندن هندسه‌ها در یک CRS درخواستی خاص هنوز پدیدار نشده است». با توجه به گستره GeoSPARQL 1.0، این بیانیه نشان می دهد که GeoSPARQL 1.0 در آن زمان انتشار داده های مکانی مبتنی بر وب را حل نکرده است. این گروه همچنین به‌روزرسانی‌های پیشنهادی خاصی را برای GeoSPARQL به‌طور غیررسمی دریافت کرد (https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL ، در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است)، اما پس از آن هیچ به‌روزرسانی برای خود GeoSPARQL انجام نشد.

نویسندگان خاطرنشان می‌کنند که در بیش از ۳ سال پس از انتشار آن بیانیه، GeoSPARQL 1.0 به طور گسترده‌تری توسط پایگاه‌های اطلاعاتی وب معنایی (به اصطلاح «triplestores») و سایر برنامه‌های کاربردی وب معنایی پشتیبانی شده است، همانطور که با تلاش‌های مکرر برای محک زدن اطلاعات مکانی مکانی نشان داده می‌شود. سه فروشگاه برای انطباق و عملکرد GeoSPARQL [ ۱۳ ، ۱۴ ، ۱۵ ، ۱۶ ]. برخی نکات بیشتر در مورد پشتیبانی GeoSPARQL در بخش ۵٫۱ ارائه شده است .

در سال ۲۰۱۹، OGC کارگروه استانداردهای GeoSPARQL (SWG) را برای به روز رسانی GeoSPARQL تشکیل داد. انگیزه کار در حوزه GeoSPARQL، داده‌های وب معنایی فضایی به طور کلی، و برخی رفع خطاهای خاص و الحاقات پیشنهادی برای GeoSPARQL 1.0 در یک کاغذ سفید OGC [ ۱۷ ] ثبت شده است. برخی، اما نه همه، مسائل مطرح شده SDWWG توسط SDW مورد توجه قرار گرفت، برای مثال، بهترین شیوه [ ۱۲ ] آرزو داشت که «یک راه ممکن رو به جلو، به روز رسانی برای هستی شناسی فضایی GeoSPARQL است. این یک هستی شناسی فضایی توافق شده را فراهم می کند، به عنوان مثال، یک پل یا زمینه مشترک بین داده های مکانی جغرافیایی و غیرجغرافیایی …“. این موضوع به طور خاص در برنامه های افزودنی GeoSPARQL 1.1 برای داده های مکانی اسکالر مورد توجه قرار گرفته است.

سایر موضوعات مطرح شده درباره بهترین روش‌ها مانند «انتشار نمایش‌های هندسی مختلف از یک شی فضایی که می‌تواند برای مقاصد مختلف استفاده شود منطقی است» تا حدی به آن پرداخته شده است. GeoSPARQL 1.1 در واقع نشان می دهد که چگونه می توان از چندین نمایش هندسی هندسه در رابطه با یک ویژگی واحد استفاده کرد، اما مفاهیمی مانند تعریف نقش برای هندسه ها، با توجه به ویژگی ها، اجرا نشده است.

منشور SWG – دامنه نهایی کار آنها – نیز توسط OGC [ ۱۸ ] منتشر شده است و این امر فعالیت های SWG را هدایت می کند. اقدامات خاص SWG و مرحله‌بندی آن‌ها از طریق استفاده از یک سیستم ردیابی وظیفه آنلاین و در دسترس عموم در مخزن کد آنلاین فعال SWG توضیح داده می‌شود ( https://github.com/opengeospatial/ogc-geosparql/projects/1 ، مشاهده شده در ۳۰ اکتبر ۲۰۲۱).

در سطح بالا، به روز رسانی های پیشنهادی GeoSPARQL توسط SDWWG و SWG ممکن است به عنوان یکی از موارد زیر طبقه بندی شود:

سریال های هندسی جدید:

–

GeoJSON، KML و سایر فرمت‌های رایج که اکنون در GeoSPARQL 1.0 وجود ندارند.

–

امکان تبدیل بین قالب های تحت اللفظی در پرس و جو.
کلاس ها و ویژگی های هستی شناسی جدید و تخصصی:

–

نمایش داده های فضایی ظریف تر و همسویی با سیستم های دیگر.
توابع فضایی بیشتر:

–

اجرای توابع شناخته شده در سیستم های فضایی وب غیر معنایی.
ویژگی های فضایی اسکالر:

–

مساحت، حجم و غیره در کنار هندسه ها.
مدیریت بهتر سیستم های مرجع فضایی (مختصات) (SRS)

–

امکان تبدیل سریال سازی مختصات خودکار.
انتخاب هندسه های مختلف بر اساس پروتکل اینترنت برای ویژگی ها.

برخی از این به‌روزرسانی‌های پیشنهادی در GeoSPARQL 1.0 پیش‌بینی شده‌اند، در بخش Future Work چندین نکته در بالا ذکر شده است. منشور SWG ، با پیش‌بینی اینکه مطمئناً به‌روزرسانی‌های واضح‌تر مانند سریال‌سازی‌های هندسی جدید اجرا می‌شوند، حوزه‌های تحقیقاتی اضافی زیر را که از بحث‌های طرفدار SWG پدید آمده است، فهرست کرده است:

بازنگری در ساختار GeoSPARQL “هستی شناسی فوقانی” – چگونه کلاس های آن با مفاهیم اساسی در هستی شناسی ارتباط دارند.
ترازهایی با دیگر هستی شناسی ها، شاید W3C Time Ontology در OWL [ ۱۹ ];
پذیرایی برای SRSهای بسیار متفاوت، مانند سیستم‌های شبکه جهانی گسسته.

به طور خاص در منشور ، هرگونه تحقیق در مورد نمودارهای دارایی منتفی است. بحث‌های اخیر (چند سال گذشته) در OGC و جاهای دیگر در مورد نمودارهای دارایی انگیزه توجه آنها را فراهم کرد. با این حال، طرفداران SWG احساس کردند که اگرچه نمودارهای ویژگی ممکن است برای سیستم‌های داده‌های مکانی وب معنایی آینده مهم باشند ، برای کارهای اولیه SWG (چندین تجدیدنظر استاندارد) بیش از اندازه کافی برای حذف این حوزه از بررسی وجود دارد.

پس از جلسات اولیه، SWG تصمیم گرفت نسخه‌های چندگانه به‌روزرسانی‌های GeoSPARQL را با اهداف مختلف ارائه کند:

۱٫۱: برنامه های افزودنی که به طور کامل با GeoSPARQL 1.0 سازگار هستند.
۱٫۲: الحاقات کاملاً یا عمدتاً سازگار اما افزوده‌های بزرگ‌تری به پوشش مفهومی استاندارد هستند.
۲٫۰: GeoSPARQL آینده احتمالاً با GeoSPARQL 1.0 ناسازگار است.

دلیل انتظار یک GeoSPARQL 2.0 ناسازگار در آینده این است که شرکت کنندگان اولیه SWG فکر می کردند که روابط مکانی-زمانی و عناصر هستی شناسی اساسی در GeoSPARQL می توانند یا باید بازسازی شوند، که ممکن است روابط کلاس ویژگی/هندسه فعلی، آشنا را از بین ببرد. جزئیات این تغییرات بالقوه در زمان این مقاله به طور کامل توضیح داده نشده است، با این حال شهود اولیه شرکت کنندگان SWG این است که GeoSPARQL 2.0 آینده، یا شاید جایگزینی GeoSPARQL که تغییر نام داده است، ممکن است مفاهیم فضایی را تعمیم دهد و از تنها، یا در درجه اول دور شود. ژئو فضایی، یا شاید تمرکز نه تنها بر روی روابط ویژگی/هندسه، بلکه به مکانیسم های تعمیم یافته برای توصیف ابعاد ویژگی هایی که هندسه تنها یکی از بسیاری از آنهاست، و موقتی بودن نگاه کنید.ممکن است دیگری باشد برای جزئیات بیشتر به بخش ۵ مراجعه کنید.

در ابتدا غیرمنتظره، منطقه ای از به روز رسانی های ارائه استاندارد توسط SWG در نظر گرفته شد. انگیزه کار مفهومی در W3C و OGC برای ارائه استانداردهای چند قسمتی و تمایل “مرجع نامگذاری” OGC. (مرجع نامگذاری ( https://www.ogc.org/projects/groups/ogcnasc ، دسترسی به ۳۰ اکتبر ۲۰۲۱) این اختیار را دارد که «…اطمینان از یک فرآیند منظم برای تخصیص URI برای منابع OGC، مانند اسناد OGC، استانداردها ، فضاهای نام XML، هستی شناسی ها” و همچنین به عنوان مبشر فرآیند عمل می کند، و همانطور که می بیند، عملکرد انتشار استانداردهای بهتر را ترویج می کند) تا استانداردها را به صورت سیستماتیک تر و به اشکال قابل خواندن ماشینی تر، و همچنین برنامه های کاری مانند “تست” OGC منتشر کند. Bed 17: Model Driven-Standards» (بسته کاری TestBed 17 «Model Driven Standards» (https://portal.ogc.org/files/?artifact_id=95726#ModelDrivenStandards ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) بر تولید اسناد از مدل‌ها تمرکز داشت، اما همچنین تا حدی اجرای آزمایشی استانداردهای چند بخشی را که به طور رسمی تعریف شده بودند، توسعه داد، مانند GeoSPARQL 1.1)، این منجر به اعلان نمایه توضیح داده شده در بخش بعدی شده است.

۲٫ به روز رسانی در GeoSPARQL 1.1

در سال ۲۰۲۱، GeoSPARQL SWG به بسیاری از درخواست‌های تغییر GeoSPARQL در نسخه ۱٫۱ پرداخت. همه تغییرات گزارش شده در اینجا اکنون در پیش نویس فعلی استاندارد GeoSPARQL 1.1، سند مشخصات و سایر بخش های استاندارد قابل مشاهده است [ ۲۰ ]. انتظار می‌رود که استاندارد کاندید اساساً تا انتشار نهایی بدون تغییر باقی بماند و به‌دلیل بازخورد اجرای گسترده‌تر، به‌روزرسانی‌های جزئی ممنوع شود. این بخش فقط کارهای تکمیل شده را فهرست می کند ( برای یادداشت های بیشتر در مورد کار نهایی GeoSPARQL 1.1 به بخش ۵٫۱ مراجعه کنید ) و به ویژگی ها، امکانات و کاربردهای جدید عناصر موجود در به روز رسانی GeoSPARQL 1.1 اشاره می کند. در ابتدا، ساختار جدید مشخصات استاندارد را مورد بحث قرار می دهیم ( بخش ۲٫۱، پسوندهای مربوط به مدل هستی شناسی و زبان پرس و جو را در بخش ۲٫۴ و بخش ۲٫۹ شرح دهید .

۲٫۱٫ اعلامیه مشخصات

یکی از اولین اقدامات SWG، پیوند دادن عناصر GeoSPARQL 1.0 از طریق یک اعلان نمایه بود، که در آن یک نمایه یک نوع رسمی تعریف شده از یک استاندارد است. مشخصات و استاندارد ، و همچنین روابط بین آنها و بخش‌های آن‌ها توسط The Profiles Vocabulary [ ۲۱ ] تعریف می‌شوند.

انگیزه اولیه برای این دو مورد بود: تشخیص SWG مبنی بر اینکه GeoSPARQL 1.0 از چندین بخش تشکیل شده است که کشف همه آنها آسان نبود، بنابراین برخی از کاربران GeoSPARQL از منابع GeoSPARQL بی اطلاع بودند که برخی از آنها به طور تصادفی کپی شده یا تا حدی دوباره پیاده سازی شده اند. و میل به اشکال قابل خواندن ماشینی از هر چه بیشتر قطعات استاندارد.

توصیف استانداردهای چند قسمتی با استفاده از واژگان پروفایل ها توسط OGC به عنوان بهترین روش آتی آنها برای ارائه استانداردها پیش بینی شده است (این امر از طریق ارتباط شخصی با کارکنان اداره نامگذاری OGC که یکی از آنها یکی از سردبیران The Profiles بود مشخص می شود. واژگان ).

همانطور که عناصر GeoSPARQL 1.1 ایجاد شده اند، آنها نیز با استفاده از واژگان نمایه توصیف شده اند، و GeoSPARQL 1.0 به عنوان نمایه، یعنی زیر مجموعه ای از GeoSPARQL 1.1 نشان داده شده است، زیرا همه عناصر GeoSPARQL 1.0 در GeoSPARQL وجود دارند. ۱٫۱٫

اعلامیه مشخصات GeoSPARQL 1.0 و تمام قطعات آن در کنار موارد GeoSPARQL 1.1 منتشر خواهد شد که در حال حاضر در اوایل سال ۲۰۲۲ انتظار می رود. در حال حاضر، همه منابع پیش نویس ۱٫۰ و ۱٫۱ در مخزن کد آنلاین SWG در دسترس هستند ( https://github.com /opengeospatial/ogc-geosparql ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱).

منابع نمایه نسخه های ۱٫۱ که با استفاده از نقش های داده شده در واژگان پروفایل ها شرح داده شده اند عبارتند از:

یک اعلامیه پروفایل
- تعریف نمایه به چیزهایی که نمایه می‌کند و فهرستی از قطعات آن پیوند دارد
- Nn انسان (HTML) و ماشین (RDF) فرم های قابل خواندن
یک منبع مشخصات
- مطابق GeoSPARQL 1.0، سند هنجاری استاندارد GeoSPARQL
- شامل الزامات و کلاس های انطباق است
- ارائه شده به‌عنوان یک سند به شکل قابل خواندن برای انسان (پی‌دی‌اف) اما حاوی کدهای هنجاری (شما ) و جداول و مثال‌های تعریف تابع
یک منبع طرحواره مدل RDF/OWL
- هستی شناسی GeoSPARQL 1.1، در هر دو فرم RDF و HTML
چندین منبع واژگانی
- عمدتاً از طرحواره مشتق شده است
- ارائه شده در اشکال قابل خواندن توسط انسان و ماشین مدل طبقه بندی سیستم سازماندهی دانش ساده (SKOS) [ ۲۲ ]
- علاوه بر تعاریف ویژگی‌های ساده GeoSPARQL 1.0، واژگانی برای توابع، قوانین، کلاس‌های انطباق وجود دارد.
نگاشت «زمینه» JSON- LD
- نگاشت بین نام های محلی و شناسه های هستی شناسی کاملاً واجد شرایط برای هستی شناسی GeoSPARQL 1.1 و همچنین واژگان تعاریف ویژگی های ساده
یک منبع اعتبارسنجی
- یک سری اشکال زبان محدودیت شکل (SHACL) [ ۲۳ ] برای اعتبارسنجی داده های RDF.

تمام عناصر نمایه GeoSPARQL 1.1 در پیش نویس فعلی اعلامیه نمایه ، مکان آنلاین، فهرست شده و به آنها پیوند داده شده است:

پیش نویس اعلامیه پروفایل GeoSPARQL 1.1

هنگامی که در نهایت منتشر شد، این منبع در فضای نام خود، مکان IRI در دسترس خواهد بود: http://www.opengis.net/def/geosparql ، در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است.

۲٫۲٫ پسوندهای هستی شناسی

GeoSPARQL 1.1 هستی شناسی GeoSPARQL را با افزودن چندین ویژگی جدید و سه کلاس مجموعه گسترش می دهد. در ابتدا، SWG یک کلاس SpatialMeasure را برای نمایش اندازه‌گیری‌های فضایی اسکالر پیشنهاد کرد، اما در نهایت این کلاس فقط به نفع یک سری ویژگی‌های «اندازه» اضافه نشد. برای یک نمای کلی از جریان، شکل ۱ را ببینید که ترسیم مجدد نمودار کلی هستی شناسی GeoSPARQL 1.1 است.

۲٫۲٫۱٫ ویژگی های فضایی اسکالر

ویژگی‌های اسکالر اجسام فضایی، مانند حجم، طول، اکنون می‌توانند در GeoSPARQL 1.1 با ویژگی «متریک» – یکی که مقدار حرفی را بر حسب متر نشان می‌دهد – یا یک ویژگی غیر متریک که ممکن است یک مقدار اندازه‌گیری را نشان دهد، نشان داده شود. یک واحد اندازه گیری جفت‌های ویژگی متریک/غیر متریک همه ویژگی‌های فرعی یک ویژگی «اندازه» عمومی هستند و دامنه geo:SpatialObject را دارند به این معنی که می‌توانند با نمونه‌های geo:Feature یا geo:Geometry استفاده شوند. جفت ویژگی های تعریف شده عبارتند از:

geo:hasSize و geo:hasMetricSize – خاصیت عمومی
geo:hasLength و geo:hasMetricLength
geo:hasPerimeterLength & geo:hasMetricPerimeterLength
geo:hasArea و geo:hasMetricArea
geo:hasVolume &
geo:hasMetricVolume

هدف از تعریف دوگانه ویژگی‌های متریک و غیر متریک، امکان استفاده ساده و دقیق‌تر است. خصوصیات متریک به طور غیر رسمی برای استفاده ترجیح داده می شوند. SWG فقط شمول آنها را در نظر گرفت. با این حال، گزینه های غیر متریک در نهایت گنجانده شدند تا امکان استفاده از واحدهای تاریخی را فراهم کنند که هیچ تبدیلی به سیستم متریک برای آنها مشخص نیست. فهرست ۱ دو جفت متریک/غیر متریک را نشان می‌دهد که برای مساحت و طول محیط استفاده می‌شوند، و شکل ۲ شامل نمونه‌های اندازه‌گیری فضایی اسکالر در کنار سایر نمونه‌های اجرای هستی‌شناسی است.

گنجاندن اندازه‌گیری‌های فضایی اسکالر در GeoSPARQL به خودی خود نگرانی‌های مطرح‌شده توسط جامعه کاربر را برطرف می‌کند (به منشور SWG مراجعه کنید ) مبنی بر اینکه استفاده فضایی اسکالر با GeoSPARQL رخ می‌دهد اما غیراستاندارد یا هدایت‌نشده است و بنابراین لزوماً قابل همکاری نیست. الگوی خاص اندازه گیری فضایی اسکالر غیر متریک انتخاب شده از الگوهای رایج برای چنین اندازه گیری هایی در هستی شناسی هایی مانند SOSA W3C [ ۲۴ ، ۲۵ ] تقلید می کند.

۲٫۲٫۲٫ ویژگی های هندسه جدید

GeoSPARQL 1.1 ویژگی های فرعی بیشتری از geo:hasGeometry را معرفی کرد. جایی که GeoSPARQL 1.0 تنها یک ویژگی از آن را تعریف می‌کند، geo:hasDefaultGeometry ، GeoSPARQL 1.1 geo:hasCentroid را برای نشان دادن هندسه‌هایی با نقش مرکز و سایر ویژگی‌های مشابه، مانند geo:hasBoundingBox تعریف می‌کند . شکل ۳ چندین هندسه را برای یک ویژگی نشان می دهد و فهرست ۲ نمایشی از آنها را در RDF با این ویژگی های جدید استفاده شده نشان می دهد.

SWG تشخیص داد که می‌تواند تعداد بیشتری از ویژگی‌های فرعی geo:hasGeometry به GeoSPARQL 1.1 اضافه شود تا تعداد کمی که در نهایت اضافه کردند. با این حال، هیچ منطق شمول/حذف توسط گروه تعیین نشد و یا ویژگی‌ها عمداً حذف نشدند. یکی از مسیرهایی که برای اکتشافات آینده در این منطقه مطرح شد اما برای GeoSPARQL 1.1 اجرا نشد، مفهوم نقش‌های هندسه – ماهیت نقش هندسه با توجه به یک ویژگی – بود و SWG درباره ایجاد واژگان نقش‌های هندسه بحث کرد. این موضوع دوباره در بخش ۵ ذکر شده است.

۲٫۲٫۳٫ روابط توپولوژیکی

GeoSPARQL 1.1 هیچ رابطه یا ویژگی توپولوژیکی جدیدی را در مقایسه با GeoSPARQL 1.0 برای آنها تعریف نمی کند (نگاه کنید به جدول A1 )، با این حال، نسخه مشخصات جدید حاوی مطالب پشتیبانی بسیار بیشتری برای کاربران این روابط و GeoSPARQL به طور کلی، به طور کلی، در نمونه های خاص است. داده های هندسه دنیای واقعی که در RDF مطابق GeoSPARQL 1.1 نشان داده شده است. شکل ۴ و فهرست مربوط به آن، فهرست ۳، انواع نمونه های ارائه شده در سند مشخصات GeoSPARQL 1.1 (ضمیمه C) و همچنین مخزن GeoSPARQL نمونه های توسعه یافته را نشان می دهد ( https://github.com/opengeospatial/ogc-geosparql/ tree/master/1.1/examples ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱).

۲٫۲٫۴٫ پشتیبانی از مجموعه ها

GeoSPARQL 1.1 پشتیبانی از مجموعه‌ای از ویژگی‌ها ( geo:FeatureCollection ) و Geometries ( geo:GeometryCollection ) را معرفی می‌کند که هر دو زیر کلاس‌های کلاس عمومی‌تر geo:SpatialObjectCollection هستند. این امکان گروه‌بندی ویژگی‌ها و هندسه‌ها را با ویژگی‌های خاص فراهم می‌کند و مجموعه‌های اشیاء تعریف‌شده در داده‌ها نیز توسط استانداردهایی مانند OGC’s Features API [ ۲۶ ] مورد نیاز است.

در حالی که جامعه GIS معمولاً ویژگی‌های مکانی را در قالب مجموعه‌ها سازمان‌دهی می‌کند، از جمله در نرم‌افزارهایی مانند ArcGIS ( https://www.arcgis.com/ ، دسترسی به ۳۰ اکتبر ۲۰۲۱) یا QGIS ( https://www.qgis.org ) / ، در ۳۰ اکتبر ۲۰۲۱ مشاهده شد، قبل از گنجاندن کلاس‌های مجموعه خاص در GeoSPARQL 1.1، کاربران داده GeoSPARQL مجبور بودند مجموعه‌های مجازی را از نتایج جستجوهای SPARQL برای سازگاری با بسیاری از ابزارهای خود پیاده‌سازی کنند. این امر مستلزم کار بیشتری از طرف نگهبانان ابزار برای ابزارهایی مانند پلاگین SPARQLing Unicorn QGIS ( https://github.com/sparqlunicorn/sparqlunicornGoesGIS ، در ۳۰ اکتبر ۲۰۲۱) بود.

SWG تشخیص داد که تفاوت معنایی کمی بین مجموعه های مجازی و تعریف شده از نقطه نظر مدل سازی OWL وجود دارد. با این حال، آنها همچنین دریافتند که سایر کاربران داده‌های وب معنایی ممکن است استفاده از مجموعه‌های تعریف‌شده را بسیار آسان‌تر بیابند، از این رو شامل نهایی آن‌ها می‌شود. این به دنبال استانداردهای اخیر وب معنایی است، به عنوان مثال، ایجاد یک افزونه برای هستی شناسی SOSA W3C برای مجموعه های مشاهده [ ۲۷ ].

۲٫۳٫ ترازهای هستی شناسی

GeoSPARQL ممکن است پرکاربردترین هستی‌شناسی برای نمایش داده‌های مکانی باشد، اما بسیاری از واژگان دیگر در حال استفاده هستند که سعی می‌کنند مکان‌های جغرافیایی را رمزگذاری کنند. بسیاری از این هستی‌شناسی‌ها، مانند نمایش‌های W3CGeo، Geonames یا Wikidata از مکان‌های جغرافیایی ممکن است فقط برای رمزگذاری هندسه‌های نقطه‌ای استفاده شوند. با این حال، برخی از واژگان مانند NeoGeo یا schema.org نیز امکان نمایش هندسه‌های پیچیده‌تر را فراهم می‌کنند، به‌عنوان مثال در کلمات شناخته شده متن. تراز با GeoSPARQL 1.1 و ۱۵ واژگان دیگر حاوی عناصر فضایی در ضمیمه استاندارد آینده ارائه شده است. علاوه بر اظهارات مکتوب و جداول ترازها، ترازها نیز به عنوان فایل RDF برای استفاده مجدد مستقیم در پایگاه های داده RDF ارائه شده است. فهرست ۵ دو تراز منفرد را نشان می دهد – از طرحواره.

۲٫۴٫ هندسه جدید انواع تحت اللفظی

سه سریال هندسی جدید در GeoSPARQL 1.1 معرفی شده است:

GeoJSON (نشان‌گذاری شی جاوا اسکریپت) [ ۲۸ ].
KML (Keyhole Markup Language) [ ۲۹ ].
DGGS (سیستم شبکه جهانی گسسته) [ ۳۰ ].

۲٫۴٫۱٫ GeoJSON و KML

GeoJSON و KML بسیار مورد انتظار بوده و توسط SDWWG و بسیاری از کاربران GeoSPARQL به دلیل محبوبیت آن فرمت ها درخواست شده است. فرمت DGGS از این جهت آینده‌نگرتر است که توسط تقاضای کاربر هدایت نمی‌شود، بلکه توسط تقاضای پیش‌بینی‌شده هدایت می‌شود.

نمونه هندسه GeoJSON، یک نقطه، نشان‌دهنده محل مرکز ناحیه انتخاباتی بریزبن از شکل ۳ در فهرست ۶ آورده شده است، فهرست ۷ همان هندسه را در KML برای مقایسه نشان می‌دهد، و گنجاندن آن هندسه در GeoSPARQL 1.1. RDF در فهرست ۸ آورده شده است.

در GeoSPARQL 1.1، فرمت‌های داده‌های هندسی که امکان اطلاعات ویژگی‌ها را فراهم می‌کنند، مانند GeoJSON، فقط به نمایش هندسه‌ها محدود می‌شوند تا از احتمال تضاد اطلاعات تحت اللفظی و RDF جلوگیری شود. این مطابق با GeoSPARQL 1.0 است که همان محدودیت را بر داده های GML اعمال می کند. در مثال شکل ۳ ، GeoJSON برای نشان دادن نوع هندسه - "نوع": "نقطه" – و همچنین دادن مختصات هندسه، اما نه حاشیه نویسی ویژگی، مانند نام، استفاده می شود.

Keyhole Markup Language (KML) یک فرمت هندسی معروف مبتنی بر XML و GML است. استفاده از آن در GeoSPARQL 1.1 ساده است.

۲٫۴٫۲٫ DGGS Literals

توصیفات سیستم شبکه جهانی گسسته (DGGS) از اشیاء فضایی را می توان در GeoSPARQL 1.1 با استفاده از حروف اللفظی نیز نشان داد، و گنجاندن آنها در GeoSPARQL 1.1 بسیار بیشتر از GeoJSON یا KML مورد توجه قرار گرفت. فهرست ۹ یک AusPIX ( https://w3id.org/dggs/auspix ، دسترسی به ۳۰ اکتبر ۲۰۲۱) DGGS از ناحیه منطقه انتخاباتی بریزبن را از شکل ۳ نشان می دهد.

GeoSPARQL 1.1 برای DGGS literal های خاص، به عنوان مثال AusPIX ، به طور مستقیم، بلکه فقط برای یک DGGS انتزاعی با نوع داده geo :dggsLiteral و ویژگی هندسه مربوطه geo:asDGGS ارائه نمی دهد ، از این رو از فضای نام مثال http://example استفاده می شود. com/thing/ در فهرست ۹٫ این به این دلیل است که DGGS هایی که در حال حاضر وجود دارند، که AusPIX تنها یکی از آنهاست، فرمت های نمایش بسیار متفاوتی دارند. انتظار می‌رود که کاربران ویژگی هندسه geo:asDGGS GeoSPARQL 1.1، DGGS خاصی را که توسط پیاده‌سازی ویژگی‌های نوع داده تحت اللفظی سفارشی استفاده می‌شود، مطابق فهرست ۹ نشان دهند.

برای کمک به درک اینکه داده‌های DGGS چیست، شکل ۵ داده‌های فهرست ۹ و همچنین تقریب‌های دقیق DGGS چندضلعی مرزی ناحیه انتخاباتی بریزبن را نشان می‌دهد. DGGS مانند AusPIX مناطق، نقاط، خطوط و سایر اشکال هندسی را با مجموعه‌ای از سلول‌ها در اندازه‌های مختلف در سطوح مختلف نشان می‌دهد. هیچ محدودیت نظری برای تعداد سطوح وجود ندارد، و بنابراین AusPIX ممکن است از سلول‌های ظریف استفاده کند، بنابراین، هیچ محدودیتی برای وضوح نظری وجود ندارد.

۲٫۴٫۳٫ مناسب بودن داده های DGGS به عنوان هندسه Literals

مناسب بودن افزودن GeoJSON و KML به GeoSPARQL 1.1 به‌عنوان قالب‌های تحت اللفظی هندسی جدید بحث‌برانگیز بود، با توجه به یک ماده، حذف اطلاعاتی غیر از اطلاعات هندسه از GeoJSON، همانطور که در بالا ذکر شد.

گنجاندن مکان یا خاصیت انتزاعی و نوع داده برای واژه‌های DGGS به دلیل برداشت‌های متفاوت از آنچه داده‌های DGGS نشان می‌دهد کاملاً بحث‌برانگیز بود. اعضای SWG همه موافق نیستند که داده‌های DGGS هندسه‌ها یا ویژگی‌ها را نشان می‌دهند، و به دلیل جدید بودن و مکانیسم‌های DGGS که بسیار متفاوت از سیستم‌های داده‌های مکانی سنتی هستند، هیچ مورد نظری ساده‌ای وجود ندارد.

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

در نیمه اول سال ۲۰۲۱، در طول عمر SWG، یک کتابخانه نرم افزاری تولید شد که تمام عملکردهای Simple Features را به جز geof:sfCrosses اجرا می کرد ( برای توضیحات پیاده سازی به بخش ۳٫۱ مراجعه کنید). در حالی که نه همه توابع Simple Features برای سایر خانواده‌های روابط فضایی پیاده‌سازی شدند، SWG تعیین کرد که با توجه به شواهد پیاده‌سازی تاکنون، داده‌های AusPIX DGGS می‌توانند به‌عنوان واژه‌های هندسی از دیدگاه GeoSPARQL عمل کنند. بنابراین، واژه‌های DGGS حداقل از دیدگاه GeoSPARQL می‌توانند به‌طور رضایت‌بخشی به‌عنوان هندسه عمل کنند. بحث SWG در مورد این موضوع در مخزن کد آنلاین آنها ثبت شده استمسأله ۱۱۲ .

۲٫۵٫ توابع تبدیل هندسه جدید

GeoSPARQL 1.1 توابع تبدیل geof:asWKT ، geof:asGML ، geof:asKML ، geof:asGeoJSON و geof:asDGGS را برای تبدیل بین انواع تحت اللفظی مختلف در حالی که قابلیت‌های انواع تحت اللفظی را در نظر می‌گیرد، فراهم می‌کند. به عنوان مثال، تبدیل یک WKT تحت اللفظی در EPSG:25832سیستم مختصات به KML یا GeoJSON منجر به تبدیل هندسه به سیستم جهانی ژئودتیک ۱۹۸۴ می شود، زیرا این تنها سیستم مرجع مختصات معتبر در دو نوع تحت اللفظی مربوطه است. از این رو، تبدیل از GeoJSON یا KML به WKT در سیستم مرجع مختصات سیستم ژئودتیک جهانی ۱۹۸۴ باقی خواهد ماند. برای اینکه بتوان هندسه‌ها را به دیگر سیستم‌های مرجع مختصات تبدیل کرد، GeoSPARQL 1.1 تابع geof:transform را اضافه می‌کند ، که اگر قالب‌های تحت اللفظی چنین تبدیلی را اجازه دهند، یک هندسه لغوی را به سیستم مرجع مختصات دیگری تبدیل می‌کند.

یکی دیگر از موارد اضافه شده، یک تابع طرح ریزی است که امکان تغییر ابعاد هندسه ها را به احتمال زیاد می دهد ( https://github.com/opengeospatial/ogc-geosparql/issues/231 ، در ۳۰ اکتبر ۲۰۲۱ مشاهده شد).

با این افزوده‌ها، پیاده‌سازی‌های سه‌گانه آتی در ارائه انواع تبدیل‌های هندسی حتی بدون وابستگی به سرویس وب میانی دیگری برای تبدیل مختصات/فرمت، بسیار انعطاف‌پذیر می‌شوند.

۲٫۶٫ توابع مجموع فضایی

در حالی که توابع تجمیع فضایی در بسیاری از پایگاه‌های اطلاعاتی غیرمعنای جغرافیایی مانند PostGIS یا Oracle Spatial معمول هستند، در زمان تعریف استاندارد GeoSPARQL 1.0، توابع تجمع هنوز در استاندارد SPARQL معرفی نشده بودند، اما با SPARQL 1.1 بودند. ۶ ]. توابع تجمیع فضایی مشابه توابع تجمع سنتی (پایگاه داده رابطه ای) مانند AVG، MAX یا MIN به نتایج تجمیع جستجوهای هندسه اجازه می دهد، به عنوان مثال، اتحاد مجموعه ای از هندسه های سریالی انتخاب شده را ایجاد کند. در حالی که محاسبه این مجموعات مطمئناً خارج از پایگاه داده معنایی امکان پذیر است و بنابراین GeoSPARQL، گنجاندن توابع مزایای متمایزی را ارائه می دهد:

برای ایجاد یک نتیجه هندسی انبوه، به کتابخانه سمت مشتری نیاز نیست.
نتایج کمتر/مناسب‌تر برگردانده می‌شوند، برای مثال یک نتیجه اتحادیه.
پرس و جوهای SPARQL فدرال می توانند نتایج را از چندین نقطه پایانی جمع آوری کنند.

علاوه بر geof:union ، geof: envelope و geof:convexHull که در GeoSPARQL 1.0 برای استفاده در عملیات SPARQL FILTER تعریف شده است، ۱٫۱ geof:aggUnion و همچنین geof:aggBoundingCircle ، geof : aggCentroid . linestrings- و geosf:aggConcaveHull که می‌تواند نتایج جمع‌آوری شده را برگرداند. لیست ۱۰ یک عملکرد جدید در حال استفاده را نشان می دهد.

توابع برای بازیابی مقادیر حداقل/حداکثر مختصات هندسه ها اضافه می شوند: geof:minX و geof:maxX ، geof:minY و geof:maxY و geof:minZ و geof:maxZ .

۲٫۷٫ مقایسه قابلیت های پرس و جو

منطقی است که تعیین کنیم نسخه جدید GeoSPARQL 1.1 چگونه با سایر زبان های پرس و جو غیرمعانی که با بازنمایی های مکانی سروکار دارند مقایسه می کند. ما در مورد زبان های پرس و جو قابل مقایسه CQL [ ۳۱ ]، ویژگی های ساده برای مشخصات SQL، و پسوندهای پیاده سازی PostGIS به عنوان معمول ترین نمایندگان زبان های پرس و جوی داده های مکانی علاوه بر GeoSPARQL بحث می کنیم.

۲٫۷٫۱٫ زبان پرس و جو رایج CQL

Common Query Language CQL برای استفاده با خدمات وب OGC توسعه داده شده است و قابلیت های فیلتر را برای جمع آوری ویژگی یا داده های پوشش ارائه می دهد. زبان پرس و جو CQL همچنین بخشی از استاندارد ویژگی های OGC API در حال توسعه [ ۳۱ ] است که مشخصات جانشین سرویس های وب OGC است. ویژگی‌های OGC API استفاده از زبان پرس و جو مشترک (CQL) را برای فیلتر کردن پیشنهاد می‌کند، اما برای پیاده‌سازی زبان پرس و جوی دیگر مانند GeoSPARQL نیز باز است. هنگام مقایسه قابلیت های فیلتر CQL با GeoSPARQL، می توان مشاهده کرد که دو زبان پرس و جو عملکرد فضایی قابل مقایسه ای را ارائه می دهند ( جدول ۱ را ببینید.). با این حال، CQL پیشنهادی از عملگرهای فضایی-زمانی پشتیبانی می‌کند، که ممکن است افزوده‌ای به GeoSPARQL باشد تا در فرآیند توسعه مستمر آن مورد بررسی قرار گیرد.

برای نشان دادن رابطه بین CQL و زبان پرس و جو GeoSPARQL، SWG یک سند بهترین تمرین ( https://opengeospatial.github.io/ogc-geosparql/bestpractice/bestpractice_cql.html ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) را منتشر خواهد کرد که شامل توصیف دقیق معادلات بین دو زبان پرس و جو.

۲٫۷٫۲٫ ویژگی های ساده برای SQL

مقایسه جالب دیگری را می توان بین قابلیت های پرس و جو GeoSPARQL و ویژگی های ساده برای مشخصات SQL انجام داد [ ۱۰]. تا به امروز، می‌توان نتیجه گرفت که برابری ویژگی با مشخصات ویژگی ساده با توجه به بیان روابط مکانی با استفاده از ویژگی‌ها و با استفاده از توابع فیلتر به دست آمده است. ویژگی هایی که هنوز در استاندارد GeoSPARQL 1.1 وجود ندارند، توابعی هستند که به طور خاص به ویژگی های انواع هندسه خاص می پردازند. به این ترتیب، دسترسی به نقاط خاصی از LineStrings (مانند نقاط شروع و پایان) و بسته بودن آنها در پرس و جو و دسترسی به حلقه های چند ضلعی و مختصات منفرد نقاط با استفاده از توابع پرس و جو غیرممکن است. این توابع برنامه‌ریزی شده‌اند تا در به‌روزرسانی آینده و احتمالاً جزئی GeoSPARQL 1.1 پیاده‌سازی شوند. ما یک جدول مقایسه بین SQL و مشخصات GeoSPARQL اضافه می کنیم تا تفاوت ها را در جزئیات برجسته کنیم.

۲٫۷٫۳٫ قابلیت های پرس و جو PostGIS

در پایگاه داده های فضایی رابطه ای، می توان انواع بیشتری از توابع فضایی را در مقایسه با ویژگی های ساده برای مشخصات SQL مشاهده کرد. علاوه بر این، انواع بیشتری از بازنمایی های جغرافیایی را می توان پردازش کرد. در نهایت، می توان به پیاده سازی های قابل مقایسه در سیستم های پایگاه داده رابطه ای، مانند PostGIS نگاه کرد. به طور خاص، این برای نمایش داده های پوشش، به عنوان مثال، رسترها در PostGIS صادق است. پایگاه داده شامل مقایسه داده های شطرنجی با نمایش داده های برداری، عملیات جبر شطرنجی بر روی شطرنجی، و اصلاحات بیشتر شطرنجی است. این قابلیت‌های پرس‌وجو در حال حاضر بسیار فراتر از قابلیت‌های GeoSPARQL 1.1 هستند و ممکن است در توسعه بیشتر با آنها مقابله شود.

۲٫۸٫ شکل‌های شاکل برای اعتبارسنجی نمودار

از زمان پذیرش SHACL [ ۲۳ ] به عنوان روش توصیه شده برای نشان دادن محدودیت ها بر روی نمودارهای RDF توسط W3C، جامعه وب معنایی شکل هایی را برای حوزه های دانش مختلف ایجاد کرده است. این اشکال اهداف مختلفی را برآورده می کنند، از بررسی ساختار نمودار برای سازگاری گرفته تا بررسی محتوای نمودار. همراه با GeoSPARQL 1.1، اشکال SHACL وجود دارد که ساختار نمودار را همانطور که در GeoSPARQL 1.1 در جنبه های زیر تعریف شده است، تأیید می کند:

تشویق ساختار نمونه هندسه یکپارچه: GeoSPARQL 1.1 نمونه های geo:Geometry را تشویق می کند که فقط به یک سریال سازی پیوند دهند. هدف پشت این قانون این است که تمام سریال‌های هندسی که GeoSPARQL 1.1 پشتیبانی می‌کند، قابل تبدیل ۱:۱ نیستند. کاربران همچنان می‌توانند از بیش از یک سریال‌سازی متصل به هندسه استفاده کنند، اما باید در مورد این واقعیت هشدار داده شود که سریال‌سازی‌ها ممکن است ۱۰۰٪ معادل نباشند. زمانی که یک هندسه با یک WKT در یک سیستم مرجع مختصات غیر CRS84 و یک Literal GeoJSON مرتبط است، یک مثال ساده از این عدم هم ارزی را می توان مشاهده کرد. به دلیل محدودیت لفظ GeoJSON برای پذیرش فقط یک سیستم مرجع مختصات، مقادیر تحت اللفظی آنها به لفظ نمی توانند معادل باشند.
بررسی ابتدایی محتویات تحت اللفظی : محتویات تحت اللفظی هندسه از نظر قابل قبول بودن بررسی می شوند. این بررسی‌ها شامل تجزیه لفظ هندسه و اعتبارسنجی آن نمی‌شود، بلکه هدف آن بررسی این است که آیا محتوای هندسه لغوی با توجه به نوع لغوی آن صحیح به نظر می‌رسد یا خیر.
استفاده صحیح از کلاس های GeoSPARQL : چندین شکل SHACL استفاده صحیح از کلاس های GeoSPARQL را آزمایش می کنند. به طور خاص، انتظار می‌رود SpatialObjectCollections حداقل یک رابطه عضو داشته باشد، و نمونه‌های geo:Feature انتظار می‌رود حداقل به یک نمونه geo:Geometry مرتبط باشند ، در حالی که انتظار می‌رود هر نمونه Geometry حداقل به یک سریال‌سازی Geometry مرتبط باشد.
سازگاری ویژگی هندسی: اشکال SHACL بیشتر برای سازگاری مقادیر و اصلی بودن ویژگی‌های یک geo:Feature یا geo:Geometry آزمایش می‌کنند. برای مثال، یک شکل SHACL سازگاری ویژگی‌های ابعادی یک geo:Geometry را آزمایش می‌کند.

برای محدوده استاندارد، GeoSPARQL 1.1 در تعریف اشکال SHACL فوق الذکر متوقف می شود. با این حال، SWG نیاز جوامع تحقیقاتی مختلف را برای تعریف بررسی‌های روابط هندسه و بررسی‌های بیشتر سازگاری محتویات هندسه و روابط آنها با یکدیگر شناسایی کرده است. مستقل از تلاش‌های SWG [ ۳۲ ] GeoSHACL را دقیقاً برای این منظور معرفی کرد و SWG قصد دارد یک گروه اجتماعی برای مجموعه‌ای از اشکال اعتبارسنجی مفید بیشتر ایجاد کند. اشکال در یک مخزن جدید Github ایجاد خواهند شد ( https://github.com/opengeospatial/ogc-geosparql-shapes ، در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).

ما سودمندی اشکال تعریف شده GeoSPARQL 1.1 SHACL را با استفاده از یک مثال حداقل در فهرست ۱۱ نشان می دهیم.

این مثال اشتباهات رایج احتمالی در نمودارهای GeoSPARQL را با توجه به جنبه هایی که قبلا ذکر شد نشان می دهد. هر اشتباهی را نمی توان با استفاده از روش های استدلال OWL شناسایی کرد. در حالی که یک geo:FeatureCollection خالی و یک نمونه ویژگی غیر متصل لزوماً نمونه های اشتباهی در یک نمودار نیستند، ما آنها را بی فایده می دانیم. از این رو آنها نقض در اعتبار سنجی SHACL ایجاد می کنند. در مقایسه با این، استفاده از نوع لغوی اشتباه ( xsd:string ) یا محتوای تحت اللفظی اشتباه ( geo:kmlLiteralبرای محتوای WKT) یک خطای واضح در اعمال مشخصات استاندارد است. موضوع آخر، نشان دهنده دو سریال سازی مرتبط با یک هندسه، چیزی قابل توجه است. یا نویسنده داده‌های داده‌شده می‌داند که هندسه‌ها در سریال‌سازی‌های مختلف لزوماً معادل نیستند زیرا دقت و تبدیل CRS ممکن است متفاوت باشد، یا نویسنده باید ایجاد نمونه‌های مختلف هندسه را در نظر بگیرد که می‌تواند جنبه‌های مختلف کیفیت داده‌های مکانی را نشان دهد.

۲٫۹٫ زمینه های JSON-LD

GeoSPARQL 1.1 زمینه های JSON-LD [ ۳۳ ] را برای ویژگی های ساده و واژگان GeoSPARQL فراهم می کند که امکان انتشار نمایش های ساده تر از داده های GeoSPARQL را فراهم می کند. فهرست ۳ داده‌های نمونه‌ای را به‌عنوان JSON بدون زمینه ارائه می‌کند، که همچنان می‌تواند از طریق پیوند دادن به منبع زمینه GeoSPARQL 1.1 JSON-LD به عنوان RDF تفسیر شود. JSON بدون زمینه ساده‌تر از JSON-LD پرمخاطب‌تر برای تولید سیستم‌ها و درک توسعه‌دهندگان است. ارائه یک زمینه JSON-LD برای GeoSPARQL همچنین با هدف کمک به پیاده‌کننده‌های APIهایی است که می‌خواهند هر دو رابط API داده پیوندی و ویژگی‌های OGC API [ ۲۶ ] را ارائه کنند: ترکیب JSON بدون متن در هر دو مشخصات مورد نیاز بسیار آسان‌تر خواهد بود. خروجی ها. آزمایش‌های چنین سیستم‌هایی در حال توسعه هستند (نگاه کنید بهhttps://github.com/surroundaustralia/ogcldapi ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) برای ترکیبی از یک چارچوب داده پیوندی و OGC API و ( http://floods.surroundaustralia.com ، در ۳۰ اکتبر ۲۰۲۱) برای نمونه استفاده از آن این سیستم قصد دارد بارهای RDF خود را به JSON بدون زمینه منتقل کند.

۲٫۱۰٫ الزامات و واژگان کلاس انطباق

همانطور که OGC دستور می دهد، تمام الزامات GeoSPARQL و کلاس های انطباق با استفاده از یک URI توصیف می شوند. با این حال، در مشخصات GeoSPARQL 1.1، این شناسه‌های منحصربه‌فرد نیز در RDF به عنوان بخشی از مشخصات مشخصات استاندارد مدل‌سازی می‌شوند. این امکان ترکیب واژگان گفته شده با منابع مختلف RDF را فراهم می کند.

تا به امروز در دو مورد می توان به سودمندی این طرح پی برد.

۲٫۱۰٫۱٫ معیار انطباق

شیوه های خوب استانداردها از هر نوعی این است که ابتدا تعریف شده و سپس در پیاده سازی مرجع پیاده سازی می شوند. برای آزمایش اینکه آیا پیاده‌سازی مرجع و همه پیاده‌سازی‌های بعدی معیارهایی را که مجموعه‌های استاندارد داده شده مطابقت می‌دهند یا خیر، می‌توان از معیار انطباق استفاده کرد. [ ۱۳ ] اولین معیار انطباق را برای GeoSPARQL 1.0 با استفاده از پلتفرم معیار HOBBIT ایجاد کرد [ ۳۴ ]. هنگامی که اجرای معیار انطباق GeoSPARQL به پایان رسید، ممکن است یک نتیجه معیار در RDF ایجاد کند ( https://github.com/hobbit-project/platform/issues/531، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱). از آنجایی که تعریف الزامات GeoSPARQL 1.1 و واژگان کلاس انطباق، این نتایج را می توان با تعاریف واقعی الزامات GeoSPARQL در RDF همانطور که در شکل ۶ نشان داده شده است، مرتبط کرد .

ارائه نتایج معیار مرتبط با الزامات یک استاندارد در RDF باعث می شود این نتایج به عنوان یک منبع قابل خواندن توسط ماشین قابل دسترسی باشد.

۲٫۱۰٫۲٫ ادعاهای انطباق جزئی داده ها

علاوه بر سیستم‌هایی که ادعا می‌کنند توابع GeoSPARQL را پیاده‌سازی می‌کنند، داده‌ها ممکن است ادعای انطباق با هستی‌شناسی GeoSPARQL داشته باشند. چنین ادعاهایی ممکن است هم با استدلال‌کننده‌های RDF و هم با استفاده از اعتبارسنجی‌های SHACL که GeoSPARQL 1.1 ارائه می‌دهد، آزمایش شوند (به بخش ۲٫۸ مراجعه کنید ). از آنجایی که GeoSPARQL شامل بخش‌های زیادی است، ممکن است داده‌های مفیدی ایجاد شود که تنها با بخشی از GeoSPARQL مطابقت داشته باشد، و واژگان کلاس‌های انطباق امکان نشان دادن انطباق داده‌ها با بخش‌هایی از GeoSPARQL، نه فقط کل را فراهم می‌کند.

علاوه بر این، جوامع کاربری خاص GeoSPARQL ممکن است اعتبار سنجی های SHACL محدودتری ایجاد کنند تا اطمینان حاصل شود که داده های GeoSPARQL با یک الگوی پیاده سازی خاص از مجموعه ای از الگوهای ممکن مطابقت دارد. یک مثال، الگویی است که به موجب آن هر geo:feature تنها با حداکثر یک geo:Geometry مرتبط است. در این مورد، یک جامعه می‌تواند کلاس‌های انطباق اضافی را مانند کلاس‌های GeoSPARQL تعریف کند و انطباق داده‌ها را نیز با آنها نشان دهد. فهرست ۱۲ یک اعتبارسنجی سفارشی را نشان می دهد که محدودیتی را بر روی ویژگی های GeoSPARQL 1.1 اعمال می کند: اینکه آنها باید یک و تنها یک سریال سازی هندسی GeoJSON داشته باشند.

۳٫ پیاده سازی مرجع

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

۳٫۱٫ RDFLib DGGS

بسته پایتون توابع ساده rHEALPix DGGS [ ۳۵ ] کتابخانه ای از توابع است که در اواسط سال ۲۰۲۱ ساخته شده است تا نشان دهد که هندسه های DGGS در خانواده rHealPix DGGS [ ۳۶ ]، که AusPIX عضوی از آن است، می تواند در محاسبه Simple استفاده شود. روابط توپولوژیکی را نشان می دهد. با استفاده از این توابع و قابلیت RDF و SPARQL از RDFlib (RDFlib یک زبان برنامه نویسی Python متن باز و پرکاربرد است، جعبه ابزار دستکاری RDF: https://github.com/RDFLib/rdflib ، در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است) بسته پایتون ، توابع RDFlib GeoSPARQL برای DGGS [ ۳۷] سپس ساخته شد که توابع محاسبه ویژگی های ساده مبتنی بر هندسه DGGS را در مفسر SPARQL RDFlib از طریق توابع پسوند SPARQL نشان می دهد. فهرست ۱۳ کد برنامه پایتون را نشان می دهد که استفاده از توابع RDFlib GeoSPARQL برای DGGS با برخی از داده های AusPIX را نشان می دهد.

در زمان نگارش، تمام توابع روابط توپولوژیکی Simple Features به جز sfCrosses پیاده‌سازی شدند ، اما انتظار می‌رود که به زودی پیاده‌سازی شود: به نظر می‌رسد که این فقط توسط مسائل برنامه‌نویسی متوقف شود، نه مسائل نظری. در حالی که در حال حاضر فقط خانواده rHealPix DGGS مورد توجه قرار گرفته است، به نظر می رسد هیچ دلیل نظری وجود ندارد که چرا دیگر DGGS ها، مانند H3 ( https://eng.uber.com/h3/ ، در ۳۰ اکتبر ۲۰۲۱) نمی توانند مورد استفاده قرار گیرند. برای.

۳٫۲٫ GeoSPARQL-Jena

پیاده‌سازی GeoSPARQL کتابخانه نرم‌افزار Apache Jena GeoSPARQL-Jena [ ۳۸ ]، طبق معیارهای اخیر [ ۱۳ ]، تنها پیاده‌سازی کامل مشخصات GeoSPARQL 1.0 را ارائه می‌کند. علاوه بر این، GeoSPARQL-Jena در یک مورد استفاده اولیه برای پشتیبانی از داده های شطرنجی در [ ۳۹ ] گسترش یافته است. این پیاده سازی دارای پشتیبانی نمونه اولیه شطرنجی در GeoSPARQL-Jena بود و هدف آن اجرای انواع توابع تعریف شده در ویژگی های ساده بود.استاندارد پیاده سازی کار توسط اعضای SWG برای پیاده سازی توابع روابط توپولوژیکی DGGS در Jena در اجرای آینه ای در RDFlib که در بالا توضیح داده شد در حال انجام است. ترکیبی از الگوریتم‌های DGGS از پیاده‌سازی RDFlib و مدیریت شطرنجی از [ ۳۹ ] احتمالاً اولین پیاده‌سازی یک کتابخانه RDF و فروشگاه سه‌گانه همراه آن را برای ارائه پشتیبانی کامل از مشخصات GeoSPARQL 1.1 در Jena فراهم می‌کند.

۳٫۳٫ پلاگین SPARQLing Unicorn QGIS

پیاده‌سازی دیگری که قبلاً از مشخصات GeoSPARQL 1.1 استفاده می‌کرد، پلاگین SPARQLing Unicorn QGIS [ ۴۰ ] است. این افزونه، طبق دانش نویسندگان، تنها کتابخانه مشتری است که داده‌های برداری جغرافیایی را به صورت لایه‌های برداری در نرم‌افزار محبوب، منبع باز، نرم‌افزار دسکتاپ QGIS GIS ( https://qgis.org/en/site/ ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱). هدف این افزونه ارائه سه عملکرد اصلی است: (۱) Querying Data Linked; (۲) آماده سازی داده های جغرافیایی برای انتشار به عنوان منابع داده های پیوندی. و (۳) غنی سازی داده های مکانی از منابع داده های پیوندی.

برای گسترش قابلیت‌های جستجوی افزونه برای GeoSPARQL 1.1، پشتیبانی از KML و GeoJSON literals اضافه شده است، و همچنین پشتیبانی از پردازش و بازبینی نمونه‌های geo:FeatureCollection و geo:GeometryCollection (به شکل ۷ مراجعه کنید ) در یک فروشگاه سه‌گانه اضافه شده است.

به عنوان جنبه ای از پردازش و یکپارچه سازی داده ها، این افزونه قالب های تحت اللفظی جدید تعریف شده را در گفتگوی تبدیل داده های پیوندی خود پیاده سازی می کند ( شکل ۸ را ببینید). این گفتگو امکان تبدیل لفظ هندسی در داده های پیوندی را به سایر CRSهای پشتیبانی شده توسط QGIS یا سایر فرمت های هندسی تحت اللفظی در مشخصات GeoSPARQL 1.1، همانطور که در بخش ۲٫۴ ذکر شد، می دهد.

با این پیاده سازی، عموم مردم می توانند داده های آماده شده توسط GeoSPARQL1.1 را کشف، دسترسی، تهیه و تبدیل کنند.

۴٫ نمونه هایی از استفاده از GeoSPARQL 1.1

در این بخش، استفاده از قطعات جدید GeoSPARQL 1.1 را نشان می دهیم.

۴٫۱٫ اعلامیه مشخصات

دولت استرالیا در حال حاضر پروژه ای را انجام می دهد که «استاندارد ملی تبادل داده» (NDES) را برای داده های تنوع زیستی تعریف می کند . ndesgateway.surroundaustralia.com/ ، در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است. این مکان احتمالا تا ژوئیه ۲۰۲۲ فعال باقی خواهد ماند و در آن زمان به یک مکان وب طولانی مدت بخش منتقل می شود. این سیستم اعتباردهنده‌های چندگانه مورد نیاز برای استفاده را از بسیاری از استانداردهای نمایه‌های NDES، از جمله GeoSPARQL، از طریق روش‌های پیروی از پیوند داده‌های پیوندی به دست می‌آورد که مستلزم آن است که استانداردها به‌صورت آنلاین به شکل ماشین‌خوان (RDF) با محمولات RDF مرتبط شوند. هر منبعی با اعتبارسنجی نقشکه آنها تعریف می کنند و همچنین استانداردها با هم مرتبط هستند و یک سلسله مراتب پروفایل مبتنی بر وابستگی را تشکیل می دهند . با چنین اطلاعاتی به صورت آنلاین، API NDES قادر است از طریق سلسله مراتب نمایه بازیابی کند، تمام منابع اعتبار سنجی تعریف شده را بازیابی کند و سپس آنها را برای استفاده به طور خودکار ترکیب کند، و در صورت به روز رسانی اعتبارسنجی استانداردها، صرفه جویی در زمان به روز رسانی سیستم و نگهداری را داشته باشد.

حتی در فرم پیش نویس فعلی، سیستم NDES از انتشار GeoSPARQL 1.1 برای اعتبار سنجی نظرسنجی می کند. نظرسنجی برای بازیابی آخرین نسخه های اعتبار سنجی ها مفید بوده است زیرا SWG به توسعه آنها ادامه داده است.

۴٫۲٫ استفاده از قالب های هندسی جدید

«نقشه ملی» دولت استرالیا ( https://nationalmap.gov.au/ ، دسترسی به ۳۰ اکتبر ۲۰۲۱) یک کره مبتنی بر وب است که می‌تواند داده‌های مکانی را در قالب‌های مختلفی نمایش دهد، اما هیچ‌یک از آن‌ها که GeoSPARQL تا این نسخه ۱٫۱ پشتیبانی نمی‌کرد. . اکنون، با پشتیبانی لغوی هندسه GeoJSON، از triplestores می‌توان برای ذخیره و فیلتر کردن داده‌های مکانی استفاده کرد که اکنون کره زمین می‌تواند به راحتی آن‌ها را مصرف و نمایش دهد. یک پیاده‌سازی triplestore/Globe اکنون عملیاتی شده است ( https://globe.surroundaustralia.com/ ، دسترسی به ۳۰ اکتبر ۲۰۲۱) که داده‌های یک فروشگاه سه‌گانه را می‌خواند، که در آن هندسه ویژگی‌ها به عنوان GeoJSON ذخیره می‌شود. با هندسه‌هایی در آن قالب، فقط ترجمه‌های بسیار ساده چند ویژگی RDF به JSON برای geo:Featureنمونه‌هایی برای Globe ضروری هستند که می‌تواند ابرداده‌های ویژگی، مانند برچسب‌ها، و همچنین هندسه‌ها را نمایش دهد. شکل ۹ نمونه ای از چند ضلعی های آزمایشی فهرست Globe را برای ایالت کوئینزلند استرالیا و همچنین سه ویژگی آن را نشان می دهد.

همانطور که در شکل ۹ نشان داده شده است، از آنجایی که فروشگاه سه‌گانه Globe نیز دارای روابط Simple Feature است، اکنون می‌توان پیوندهای ویژگی به ویژگی را در نمونه کره نشان داد. این پیوندها قابل اجرا هستند و جهان می تواند دوباره بر روی ویژگی هایی که به آنها پیمایش می شود تمرکز کند.

۴٫۳٫ ویژگی های OGC API Backend

زیرساخت‌های سنتی داده‌های مکانی از ارائه‌دهنده داده‌های مکانی تنها از طریق سرویس‌های وب مشخص شده به زیرساخت‌های دانش مکانی تبدیل می‌شوند [ ۴۱ ، ۴۲ ]. این زیرساخت‌های دانش فضایی داده‌های مکانی را به دو طریق فراهم می‌کنند، همانطور که در شکل ۱۰ نشان داده شده است. راه اول ارائه داده های مکانی با استفاده از خدمات وب جغرافیایی است. راه دوم ارائه داده های مکانی به عنوان داده های پیوندی است که دومی توسط هستی شناسی هایی مانند GeoSPARQL فعال می شود. با این حال، سرویس‌های وب فضایی در حال حاضر در مشخصات ویژگی‌های OGC API، که، همانطور که قبلاً در بخش ۲٫۲٫۴ توضیح داده شد ، به پشتوانه‌های داده‌های پیوندی اجازه می‌دهد.

یک نمونه زنده از داده های ارائه شده بر اساس اصول داده های پیوندی، مشخصات ویژگی های OGC API، و همچنین یک پروتکل SPARQL ( https://www.w3.org/TR/sparql11-protocol/ ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) سرویس Geoscience است. API Australia’s Floods ( http://floods.surroundaustralia.com/ ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱)، که تصویری از آن در شکل ۱۱ نشان داده شده است . از طریق برنامه‌ای از CQL به نگاشت‌های SPARQL که SWG ایجاد می‌کند (به بخش ۲٫۷ مراجعه کنید )، Floods API همچنین قادر خواهد بود به جستارهای CQL پاسخ دهد.

این API اطلاعاتی را مطابق با ساختارهای URL ویژگی های OGC API با پرس و جوهای بسیار ساده به GeoSPARQL 1.1 ارائه می کند. باطن سادگی به دلیل مدل‌سازی GeoSPARQL 1.1 امکان‌پذیر است که امکان geo:FeatureCollection ، geo:Feature و geo:Geometry را فراهم می‌کند، که اولین مورد همانطور که در GeoSPARQL 1.1 معرفی شد به طور خاص برای APIهایی مانند ویژگی‌های OGC API ارائه شده است.

APIهایی مانند این Floods API مشابه APIهای داده مکانی نسل قبلی، مانند سرویس معروف Web Feature Service (WFS) ( https://www.ogc.org/standards/wfs ، دسترسی به ۳۰ اکتبر ۲۰۲۱) عمل می کنند. ویژگی‌های OGC API مشتق شده‌اند، اما همچنین می‌توانند رابط‌های کاربر انسانی (صفحه وب)، نقاط پایانی SPARQL و فرمت‌های داده بیشتری را ارائه دهند.

۴٫۴٫ مثال برنامه DGGS

DGGSها داده‌های فضایی برداری و شطرنجی را به عنوان مجموعه‌ای از شناسه‌های سلولی نشان می‌دهند. از زمان GeoSPARQL 1.1، سیستم ذخیره سازی داده های DGGS ممکن است یک فروشگاه سه گانه باشد.

داده‌های API در شکل ۱۱ ابتدا به صورت رستر و داده‌های استاندارد جغرافیای آماری استرالیا (ASGS) ( https://www.abs.gov.au/websitedbs/D3310114.nsf/home/Australian+Statistical+Geography ) ثبت می‌شوند. مجموعه داده +Standard+ (ASGS) ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱) به صورت برداری ثبت شده است. هر دو مجموعه داده می‌توانند با استفاده از سه‌گانه Apache Jena TDB ( https://jena.apache.org/documentation/tdb/index.html ، دسترسی به ۳۰ اکتبر ۲۰۲۱) به عنوان داده GeosPARQL 1.1 با هندسه‌هایی در قالب AusPIX DGGS ذخیره شوند.

مجموعه داده‌های Floods & ASGS در واقع در پلتفرم داده Loc-I for Disaster Recovery ( https://ldr.surroundaustralia.com/ ، دسترسی به ۳۰ اکتبر ۲۰۲۱) با چندین رستر و مجموعه داده برداری دیگر ذخیره می‌شوند که همه آنها می‌توانند پرس و جوی متقابل و ارائه شده به عنوان ویژگی هایی با هندسه به صورت برداری، ویژگی ها با هندسه به شکل شطرنجی یا به عنوان سلول های درون شبکه های منظم با مقادیر سلولی داده ها یا شناسه ویژگی های مربوطه آنها.

پلتفرم Loc-I نیاز به تبدیل داده های هندسی اولیه به DGGS و اطلاعات ویژگی به GeoSPARQL RDF دارد، اما استفاده از داده های مکانی و غیر مکانی بسیار ساده است -پرس و جوهای SPARQL- و همه عناصر داده را می توان در یک مورد استفاده کرد. سیستم.

۵٫ کار آینده

۵٫۱٫ نهایی سازی GeoSPARQL 1.1

GeoSPARQL 1.1 از نوامبر ۲۰۲۱ در مراحل نهایی تهیه پیش نویس است. عناصر جدید نسخه، به استثنای یک استثنا احتمالی که در زیر توضیح داده شده است، نهایی شده اند و وظایف اصلی باقی مانده عبارتند از:

نسخه جدید را برای بازبینی بیشتر به پیاده‌کنندگان سیستم ارسال کنید.
به بازخورد مجریان پاسخ دهید.
IRI های جدید را در نسخه ۱٫۱ در اداره نامگذاری OGC ثبت کنید.
دوره اعلان به روز رسانی استاندارد OGC اجباری را آغاز کنید.

با توجه به ماهیت ساده بسیاری از افزوده‌های نسخه ۱٫۱ و این واقعیت که اعضای SWG توانسته‌اند حداقل یک پیاده‌سازی از تقریباً همه عناصر و توابع هستی‌شناسی جدید ایجاد کنند، انتظار می‌رود که بازبینی گسترده‌تر پیاده‌سازها منجر به نتایج عمده نشود. تغییر می کند.

۵٫۲٫ فراتر از GeoSPARQL 1.1 کار کنید

هدف اولیه GeoSPARQL SWG، زمانی که در سال ۲۰۱۹ تشکیل شد، انتشار نسخه ۱٫۱ GeoSPARQL و سپس احتمالاً ۱٫۲ و ۲٫۰ بود، همانطور که در بخش ۱ توضیح داده شد . در حالی که دامنه GeoSPARQL 1.1 مطابق با تخمین‌های اولیه برای آن نسخه بوده است و هنوز درخواست‌های تغییر نامنظم شناخته شده‌ای وجود دارد که SWG برای نسخه احتمالی ۱٫۲ برچسب‌گذاری کرده است ( https://github.com/opengeospatial/ogc را ببینید. -geosparql/milestone/2 ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱)، SWG افکار زیادی را در مورد رسیدگی جامع‌تر به نگرانی‌های وب معنایی فضایی که ممکن است به جهت متفاوتی نیاز داشته باشد، برای مثال، هندسه‌های غیرزمینی، مدیریت جامع شطرنجی‌ها به ذهن متبادر کرده است. (به شماره ۱۸ مراجعه کنید) یا یک مدیریت هستی شناختی جدید از سیستم های مرجع مختصات.

اگر تمایل زیادی برای کارهای غیرجغرافیایی وجود داشته باشد، و اگر فراتر از زبان جستجوی SPARQL باشد، ممکن است نه بخش های «Geo-» یا «-SPARQL» GeoSPARQL به طور معقولی در مورد آن اعمال نشوند، بنابراین چیزی دیگر. ممکن است به GeoSPARQL 1.2 یا حتی ۲٫۰ نیاز باشد. SWG پس از انتشار GeoSPARQL 1.1 درباره این موضوع مشورت خواهد کرد.

بخش‌های فرعی زیر جزئیات بیشتری را در مورد جهت‌های بالقوه GeoSPARQL 1.1+ ارائه می‌دهند.

۵٫۳٫ گنجاندن انواع داده های مکانی بیشتر

در حال حاضر، GeoSPARQL 1.1 استانداردی برای توصیف داده های برداری دوبعدی و سه بعدی و یک سیستم مرجع شبکه واحد است. با این حال، اعضای SWG قبلاً به نیاز به نمایش تلفن همراه (مثلاً مش های سه بعدی) و اشیاء فضایی بی حرکت بیشتر و گنجاندن قابلیت های جستجوی داده های شطرنجی اشاره کرده اند.

۵٫۴٫ نقش های هندسه

همانطور که در بخش ۲٫۲٫۱ اشاره شد ، عناصر هستی شناسی جدید برای GeoSPARQL 1.1 پیشنهاد شد تا نقش هندسه ها را با توجه به ویژگی ها نشان دهد. اعضای SWG ویژگی‌های جدید ویژه geo:hasGeometry مانند geo:hasCentroid و geo:hasBoundingBox را دیدند که هندسه‌هایی با نقش‌های خاص را نشان می‌دهند و GeoSPARQL احتمالاً می‌تواند با ایجاد واژگانی از آن‌ها، راه قابل‌توجهی برای نشان دادن نقش ارائه دهد که می‌توان آن‌ها را اضافه کرد. به، به جای توصیف آنها در تعدادی ویژگی که باید پس از انتشار نسخه GeoSPARQL ثابت باقی بمانند.

زمان‌بندی و تلاش شرکت‌کنندگان SWG اجازه نمی‌دهد نقش‌ها در GeoSPARQL 1.1 اضافه شوند، و افزودن آنها ممکن است برای GeoSPARQL 1.2 معقول باشد.

۵٫۵٫ قابلیت همکاری با داده های ساختمان

اشتهای رو به رشدی برای داده‌های وب معنایی در جوامع مدل‌سازی اطلاعات ساختمان (BIM) وجود دارد که با وجود گروه‌های کاری مانند گروه انجمن داده ساختمان پیوندی W3C ( https://www.w3.org/community/lbd/ ، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱)، و وجود پروژه‌هایی مانند BRICK [ ۴۳ ]، IFC/Ontology mappings [ ۴۴ ] و “Building Topology Ontology” ( https://w3id.org/bot )، قابل دسترسی در ۳۰ اکتبر ۲۰۲۱). همه اینها به طور طبیعی دارای اجزای فضایی هستند و برخی قبلاً از GeoSPARQL 1.0 (BRICK) استفاده می کنند. همچنین مشخص است که اعضای گروه انجمن داده‌های ساختمان پیوندی با اعضای SWG کار کردند تا موارد استفاده مرتبط با ساختمان و برخی کاستی‌های GeoSPARQL 1.0 را برای اهداف خود در یک «کاغذ سفید» در آماده‌سازی برای تشکیل SWG [ ۱۷]، که GeoSPARQL برای مدت طولانی برای آن جامعه مهم در نظر گرفته شده است. متأسفانه، همه نیازهای این جامعه در GeoSPARQL 1.1 برآورده نشد، بنابراین می‌توان کارهای بیشتری برای پشتیبانی از آن انجام داد، برای مثال، گنجاندن سایر روابط توپولوژیکی تخصصی برای حفره‌ها و ویژگی‌های غیر خالی. نقش های هندسی (طبق بخش بالا)؛ خصوصیات هندسی غیر مختصات، به عنوان مثال، استوانه. و هندسه زیرسطحی.

۵٫۶٫ رسمی سازی سیستم های مرجع فضایی

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

۵٫۷٫ پشتیبانی از قطعات داده پیوندی

مجموعه داده‌های GeoSPARQL می‌تواند بسیار بزرگ باشد، چه از نظر تعداد ویژگی‌ها یا هندسه‌های ذخیره‌شده، اندازه لفظ هندسی آنها یا هر دو. APIهایی که مایل به ارائه تعداد زیادی از ویژگی‌های GeoSPARQL یا نمونه‌های هندسه هستند، از توانایی ارائه آنها به صورت جریانی سود می‌برند، و برای این، رویکرد به اصطلاح “قطعات داده پیوندی” (LDF) [ ۴۵ ] در نظر گرفته شده است. به نظر می رسد که اگر رویکرد LDF برای جریان داده ها از یک API اجرا شود، امکان پرس و جو توپولوژیکی GeoSPARQL سمت کلاینت را فراهم می کند. یک سناریوی مثال می تواند این باشد که یک کاربر API بخواهد بداند که آیا یک API دارای ویژگی است که با یک ویژگی محلی همپوشانی دارد یا خیر. اگر قرار بود API ویژگی‌ها را از یک geo:FeatureCollection پخش کندیا در نتیجه یک جستار فیلترینگ، کاربر می تواند به صورت تدریجی همپوشانی را آزمایش کند و با یافتن مطابقت، جلسه پخش را متوقف کند.

۶٫ نتیجه گیری

برنامه مرحله‌ای از به‌روزرسانی‌های این وب معنایی ضروریاستاندارد فضایی با تغییرات ساده و کاملاً سازگار با عقب اکنون در GeoSPARQL 1.1 آغاز شده است. پیاده سازی مرجع برای همه ویژگی های جدید GeoSPARQL 1.1 ساخته شده است. نمونه هایی از تمام عناصر استفاده شده را می توان به صورت آنلاین نشان داد. ویژگی‌های مورد بحث برای GeoSPARQL 1.2 شامل رسمی‌سازی سیستم‌های مرجع مختصات در RDF، به تصویر کشیدن دقت و سطح جزئیات، و افزودن انواع بیشتر – احتمالاً باینری – تحت اللفظی است. کار روی GeoSPARQL 1.2 در اواسط سال ۲۰۲۲ آغاز خواهد شد. GeoSPARQL 2.0 که هنوز مشخص نشده است، احتمالاً تغییرات اساسی تری را در استاندارد ایجاد می کند. تغییرات پیشنهادی برای GeoSPARQL 2.0 شامل گسترش دامنه GeoSPARQL به گونه‌ای دیگر از داده‌های مکانی است. در این راستا، پشتیبانی کامل از هندسه های سه بعدی و پشتیبانی از پوشش ها در سطح نمایش داده ها مورد بحث قرار می گیرد. این پیشنهادها به برخی علاقه رو به رشد در جامعه وب معنایی در ارائه داده‌های مکانی بیشتر مربوط به اطلاعات ساختمان مربوط می‌شوند.۴۶ ] و داده های پوشش [ ۳۹ ]. همچنین ممکن است پس از دریافت بازخورد از نسخه‌های GeoSPARQL 1.1 و ۱٫۲، نیازمندی‌های بیشتری معرفی شوند.

اختصارات

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

API	رابط برنامه نویسی کاربردی
BIM	مدلسازی اطلاعات ساختمان
CQL	زبان پرس و جو رایج
CRS	سیستم مرجع مختصات
DGGS	سیستم شبکه جهانی گسسته
EPSG	گروه بررسی نفت اروپا
GeoSPARQL	پروتکل جغرافیایی SPARQL علاوه بر این، زبان پرس و جو RDF
GIS	سیستم اطلاعات جغرافیایی
GML	زبان نشانه گذاری جغرافیا
HTML	زبان نشانه گذاری فرامتن
KML	زبان نشانه گذاری سوراخ کلید
JSON	نشانه گذاری شی جاوا اسکریپت
LDF	قطعات داده مرتبط
NDES	استاندارد ملی تبادل داده
OGC	کنسرسیوم فضایی باز
جغد	زبان هستی شناسی وب
QGIS	GIS کوانتومی
RDF	چارچوب شرح منابع
RDFS	طرح چارچوب شرح منبع
RIF	قالب تبادل قوانین
SDWWG	داده های مکانی در گروه کاری وب
SHACL	زبان محدودیت اشکال
SKOS	سیستم سازماندهی دانش ساده
SOSA	هستی شناسی شبکه حسگر معنایی
SPARQL	پروتکل SPARQL علاوه بر این، زبان پرس و جو RDF
SRS	سیستم مرجع فضایی
SWG	کارگروه استاندارد
W3C	کنسرسیوم وب جهانی
WKT	متن معروف
XML	زبان نشانه گذاری توسعه پذیر

منابع

کاکس، اس. براونینگ، دی. بلتران، AG; آلبرتونی، آر. پرگو، ا. Winstanley, P. Data Catalog Vocabulary (DCAT)—نسخه ۲٫ W3C Recommendation, W3C. ۲۰۲۰٫ در دسترس آنلاین: https://www.w3.org/TR/vocab-dcat-2/ (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
دوئر، ام. هیبل، جی. ایدی، Ø. CRMgeo: پیوند CIDOC CRM به GeoSPARQL از طریق یک پالایش مکانی و زمانی . گزارش فنی؛ گروه کاری استانداردهای اسناد CIDOC-CRM: ژنو، سوئیس، ۲۰۱۳; در دسترس آنلاین: https://cidoc-crm.org/crmgeo/sites/default/files/Technical%20Report435-CRMgeo.pdf (دسترسی در ۳۰ اکتبر ۲۰۲۱).
هیبل، جی. دوئر، ام. عید، Ø. CRMgeo: توسعه فضایی و زمانی CIDOC-CRM. بین المللی جی دیجیت. Libr ۲۰۱۷ ، ۱۸ ، ۲۷۱-۲۷۹٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
پری، م. Herring, J. OGC GeoSPARQL—یک زبان پرس و جوی جغرافیایی برای داده های RDF . استاندارد اجرای OGC; کنسرسیوم فضایی باز: Rockville، MD، ایالات متحده آمریکا، ۲۰۱۲٫ [ Google Scholar ]
سیگانیاک، ر. وود، دی. Lanthaler, M. RDF 1.1 Concepts and Abstract Syntax ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۴٫ [ Google Scholar ]
گروه کاری W3C SPARQL. SPARQL 1.1 نمای کلی ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۳; در دسترس آنلاین: http://www.w3.org/TR/sparql11-overview/ (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
Seaborne، A.; Harris, S. SPARQL 1.1 Query Language ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۳; در دسترس آنلاین: http://www.w3.org/TR/sparql11-query/ (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
کیفر، م. Boley, H. RIF Overview , ۲nd ed.; یادداشت گروه کاری W3C; کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۳; در دسترس آنلاین: https://www.w3.org/TR/rif-overview/ (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
موتیک، بی. Patel-Schneider، PF; پارسیا، بی. OWL 2 زبان هستی شناسی وب: مشخصات ساختاری و نحو عملکردی ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۰۹; در دسترس آنلاین: https://www.w3.org/TR/owl2-syntax/ (دسترسی در ۳۰ اکتبر ۲۰۲۱).
ISO 19125-1:2004 ; اطلاعات جغرافیایی – دسترسی به ویژگی های ساده – قسمت ۱: معماری مشترک. سازمان بین المللی استاندارد: ژنو، سوئیس، ۲۰۰۴٫
ماشین، نیوجرسی؛ Homburg, T. GeoSPARQL 1.1: یک به روز رسانی تقریباً ده ساله برای مهم ترین استاندارد LOD جغرافیایی ؛ Yaman, B., Sherif, MA, Ngonga Ngomo, AC, Haller, A., Eds. کارگاه داده های پیوندی جغرافیایی ۲۰۲۱; CEUR-WS: هرسونیسوس، یونان، ۲۰۲۱؛ جلد ۲۹۷۷، ص ۲۶-۳۳٫ [ Google Scholar ]
ون دن برینک، ال. برنقی، پ. تندی، جی. اتمزینگ، جی. اتکینسون، آر. کاکرین، بی. فتحی، ی. Troncy, R. بهترین شیوه ها برای انتشار، بازیابی و استفاده از داده های مکانی در وب. سمنت. وب ۲۰۱۸ ، ۱۰ ، ۹۵-۱۱۴٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
جووانوویک، م. هامبورگ، تی. Spasić، M. معیار انطباق GeoSPARQL. ISPRS Int. J. Geo-Inf. ۲۰۲۱ ، ۱۰ ، ۴۸۷٫ [ Google Scholar ] [ CrossRef ]
ترومپوکیس، ا. کنستانتوپولوس، اس. موچکیس، جی. پروکوپاکی-کوستوپولو، ن. پاریس، سی. بروزون، ال. پانتازی، DA; Koubarakis، M. GeoFedBench: معیاری برای پردازشگرهای جستجوی فدرال GeoSPARQL . ISWC (نمایش/صنعت): آتن، یونان، ۲۰۲۰٫ [ Google Scholar ]
Ioannidis، T. گاربیس، جی. کیزیراکوس، ک. برتا، ک. Koubarakis، M. ارزیابی ذخیره‌های RDF جغرافیایی با استفاده از معیار Geographica 2. J. Data Semant. ۲۰۲۱ ، ۱۰ ، ۱-۴۰٫ [ Google Scholar ] [ CrossRef ]
هوانگ، دبلیو. رضا، س. میرزوف، او. Harrie, L. ارزیابی و معیار ذخیره‌های RDF با قابلیت فضایی برای نسل بعدی زیرساخت داده‌های مکانی. ISPRS Int. J. Geo-Inf. ۲۰۱۹ ، ۸ ، ۳۱۰٫ [ Google Scholar ] [ CrossRef ] [ نسخه سبز ]
ابهایاراتنا، ج. ون دن برینک، ال. ماشین، ن. اتکینسون، آر. هامبورگ، تی. Knibbe، F. Thiery، F. OGC مزایای نمایش داده های مکانی با استفاده از فن آوری های معنایی و نموداری . OGC White Paper; کنسرسیوم فضایی باز: Rockville، MD، ایالات متحده آمریکا، ۲۰۲۰٫ [ Google Scholar ]
ابهایاراتنا، ج. ون دن برینک، ال. ماشین، ن. هامبورگ، تی. منشور Knibbe، F. Ogc Swg. در منشور OGC GeoSPARQL 2.0 SWG ; کنسرسیوم فضایی باز: Rockville، MD، ایالات متحده آمریکا، ۲۰۲۰٫ [ Google Scholar ]
کاکس، اس. لیتل، سی. هستی شناسی زمان در OWL . توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۷٫ [ Google Scholar ]
ماشین، نیوجرسی؛ هامبورگ، تی. پری، م. شاه ماهی، جی. Knibbe، F. کاکس، SJD؛ ابهایاراتنا، ج. Bonduel، M. OGC GeoSPARQL – یک زبان پرس و جو جغرافیایی برای داده های RDF. ۲۰۲۱٫ در دسترس آنلاین: https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
اتکینسون، آر. Car, NJ The Profiles Vocabulary ; یادداشت گروه کاری W3C; کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۲۰٫ [ Google Scholar ]
مایلز، ای. Bechhofer, S. SKOS مرجع سیستم سازمان دانش ساده ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۰۹٫ [ Google Scholar ]
کنوبلاچ، اچ. Kontokostas, D. Shapes Constraint Language (SHACL) ; توصیه W3C؛ W3C: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۷٫ [ Google Scholar ]
هالر، ا. یانوویچ، ک. کاکس، اس. لو فوک، دی. تیلور، ک. Lefrançois, M. هستی شناسی شبکه حسگر معنایی ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۱۷٫ [ Google Scholar ]
کامپتون، ام. برنقی، پ. برمودز، ال. گارسیا کاسترو، آر. کورچو، او. کاکس، اس. گریبیل، جی. هاوسویرث، ام. هنسون، سی. هرتزوگ، آ. و همکاران هستی شناسی SSN گروه انکوباتور شبکه حسگر معنایی W3C. J. وب سمنت. ۲۰۱۲ ، ۱۷ ، ۲۵-۳۲٫ [ Google Scholar ] [ CrossRef ]
کنسرسیوم فضایی باز OGC API—ویژگی ها—بخش ۱: هسته ; استاندارد پیاده سازی؛ کنسرسیوم فضایی باز: Rockville، MD، ایالات متحده آمریکا، ۲۰۱۹٫ [ Google Scholar ]
Cox، SJ الحاقات به هستی شناسی شبکه حسگر معنایی . پیش نویس کاری W3C. کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۲۰٫ [ Google Scholar ]
باتلر، اچ. دالی، م. دویل، ا. گیلیز، اس. شاوب، تی. Schaub, T. فرمت GeoJSON ; RFC 7946; گروه کاری مهندسی اینترنت: Reston، VA، ایالات متحده آمریکا، ۲۰۱۶٫ [ Google Scholar ] [ CrossRef ]
نولان، دی. زبان نشانه گذاری Lang، DT Keyhole. در XML و فناوری های وب برای علوم داده با R ; Springer: نیویورک، نیویورک، ایالات متحده آمریکا، ۲۰۱۴; صص ۵۸۱-۶۱۸٫ [ Google Scholar ] [ CrossRef ]
سحر، ک. سفید، دی. کیمرلینگ، سیستم‌های شبکه جهانی گسسته ژئودزیک AJ. در نقشه کشی و علوم اطلاعات جغرافیایی ; تیلور و فرانسیس: لندن، انگلستان، ۲۰۰۳; جلد ۲، ص ۱۲۱-۱۳۴٫ [ Google Scholar ]
Vretanos، PA; Portele, C. OGC API—ویژگی ها—بخش ۳: فیلتر کردن و زبان پرس و جو رایج (CQL) ; پیش نویس استاندارد کنسرسیوم زمین فضایی باز. کنسرسیوم فضایی باز: Rockville، MD، ایالات متحده آمریکا، ۲۰۲۱٫ [ Google Scholar ]
دبروین، سی. McGlinn، K. مولفه های محدودیت SHACL قابل استفاده مجدد برای اعتبارسنجی داده های مرتبط جغرافیایی. CEUR-WS ۲۰۲۱ ، ۲۹۷۷ ، ۵۹-۶۶٫ در دسترس آنلاین: http://ceur-ws.org/Vol-2977/paper8.pdf (دسترسی در ۳۰ اکتبر ۲۰۲۱).
Champin، PA; لانگلی، دی. Kellogg, G. JSON-LD 1.1 ; توصیه W3C؛ کنسرسیوم وب جهانی: کمبریج، MA، ایالات متحده آمریکا، ۲۰۲۰؛ در دسترس آنلاین: https://www.w3.org/TR/2020/REC-json-ld11-20200716/ (دسترسی در ۳۰ اکتبر ۲۰۲۱).
رودر، ام. کوچلف، دی. Ngonga Ngomo، AC HOBBIT: پلت فرمی برای محک زدن داده های پیوندی بزرگ. اطلاعات علمی ۲۰۲۰ ، ۳ ، ۱۵-۳۵٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
Habgood, D. توابع ویژگی ساده برای rHEALPix DGGS. نرم افزار پایتون ۲۰۲۱٫ در دسترس آنلاین: https://pypi.org/project/rhealpix-sf/ (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
گیب، آر. رایچف، آ. Speth، M. سیستم شبکه جهانی گسسته rHEALPix ; تحقیقات مراقبت از زمین نیوزیلند: لینکلن، نیوزلند، ۲۰۱۶٫ [ Google Scholar ] [ CrossRef ]
توابع Habgood، D. RDFlib GeoSPARQL برای DGGS. ۲۰۲۱٫ در دسترس آنلاین: https://pypi.org/project/geosparql-dggs/ (در ۳۰ اکتبر ۲۰۲۱ قابل دسترسی است).
آلبیستون، جی ال. عثمان، تی. Chen, H. GeoSPARQL-Jena: پیاده سازی و محک زدن یک graphstore GeoSPARQL. ۲۰۱۸٫ موجود به صورت آنلاین: https://www.semanticscholar.org/paper/GeoSPARQL-Jena%3A-Implementation-and-Benchmarking-of-Albiston-Osman/224bcc2ca5b39294e14eb1202f29ac63f534e (۲۳۰۸/۲۰۱۳).
هامبورگ، تی. استاب، س. Janke ، D. GeoSPARQL+: نحو، معناشناسی و سیستم برای جستجوی یکپارچه نمودار، رستر و داده های برداری. وب معنایی-ISWC 2020 ؛ Springer: برلین/هایدلبرگ، آلمان، ۲۰۲۰٫ [ Google Scholar ] [ CrossRef ]
تیری، اف. Homburg, T. SPARQLing Unicorn QGIS Plugin ; Zenodo: ژنو، سوئیس، ۲۰۲۱٫ [ Google Scholar ] [ CrossRef ]
داکهام، ام. آرنولد، ال. آرمسترانگ، ک. مک میکین، دی. موتولینی، دی. به سوی زیرساخت دانش فضایی. در مجموعه مقالات AGILE 2018، لوند، سوئد، ۱۲ تا ۱۵ ژوئن ۲۰۱۸٫ [ Google Scholar ]
ایوانووا، آی. سیائو هیم فا، جی. مک میکین، دی. آرنولد، ال.ام. دیکین، آر. ویلسون، ام. از داده های فضایی تا زیرساخت دانش فضایی: معماری پیشنهادی. ترانس. GIS ۲۰۲۰ ، ۲۴ ، ۱۵۲۶-۱۵۵۸٫ [ Google Scholar ] [ CrossRef ]
فیرو، جی. کوه، جی. آگاروال، ی. گوپتا، RK; Culler، DE Beyond a House of Sticks: رسمی کردن تگ های فراداده با آجر. در مجموعه مقالات ششمین کنفرانس بین‌المللی ACM در مورد سیستم‌های ساختمان‌ها، شهرها و حمل‌ونقل کارآمد انرژی، نیویورک، نیویورک، ایالات متحده آمریکا، ۱۳ تا ۱۴ نوامبر ۲۰۱۹؛ صص ۱۲۵-۱۳۴٫ [ Google Scholar ] [ CrossRef ]
ترکاج، و. Šojić، A. بازنمایی مبتنی بر هستی‌شناسی قوانین IFC EXPRESS: بهبود هستی‌شناسی ifcOWL. خودکار ساخت و ساز ۲۰۱۵ ، ۵۷ ، ۱۸۸-۲۰۱٫ [ Google Scholar ] [ CrossRef ]
وربورگ، آر. واندر ساند، م. هارتیگ، او. ون هرویگن، جی. دی ووشت، ال. دی میستر، بی. Haesendonck، G. Colpaert، P. قطعات الگوی سه گانه: یک رابط گرافیکی دانش کم هزینه برای وب. J. وب سمنت. ۲۰۱۶ ، ۳۷–۳۸ ، ۱۸۴–۲۰۶٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
ژانگ، سی. بیتز، جی. de Vries, B. BimSPARQL: پسوندهای SPARQL عملکردی خاص دامنه برای جستجوی داده های ساختمان RDF. سمنت. وب ۲۰۱۸ ، ۹ ، ۸۲۹–۸۵۵٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]
Renz, J. یک مدل متعارف از حساب ارتباط منطقه. J. Appl. غیر کلاسی. منطق ۲۰۰۲ ، ۱۲ ، ۴۶۹-۴۹۴٫ [ Google Scholar ] [ CrossRef ][ نسخه سبز ]

شکل ۱٫ نمودار نمای کلی هستی شناسی GeoSPARQL 1.1 شامل ویژگی های جدید کلاس ها. پس از نمودار نمای کلی خود GeoSPARQL 1.1 .

شکل ۲٫ گزیده ای از هستی شناسی GeoSPARQL 1.1 شامل یک ویژگی مثال.

شکل ۳٫ هندسه های ناحیه انتخاباتی فدرال استرالیا در بریزبن. GeoSPARQL 1.0 فقط دارای ویژگی geo:hasGeometry برای نشان دادن یک نمونه geo:Geometry برای یک نمونه geo:Feature بود. GeoSPARQL 1.1 حاوی ویژگی های تخصصی geo:hasCentroid و geo:hasBoundingBox است که می تواند هندسه هایی با نقش های خاص را نشان دهد. فهرست ۲ را برای نمایش RDF از عناصر این شکل ببینید.

شکل ۴٫ هندسه حوزه های انتخاباتی فدرال استرالیا پتری و بریزبن و رای دهندگان ایالتی مک کانل ( سمت چپ ) و دوباره بریزبن و رای دهندگان ایالتی کلیفیلد ( راست ). بریزبن نیز مانند شکل ۳ است. روابط فضایی توپولوژیکی که ممکن است بین این هندسه ها به طور مستقیم یا بین ویژگی هایی که این هندسه ها برای آنها هستند اعلام شود. روابط ممکن برای این موارد عبارتند از: Brisbane geo:sfContains McConnel، McConnel geo:sfWithin Brisbane، Brisbane geo:sfTouches Petrie و McConnel geo:sfDisjoint Petrie. برای نمایش RDF عناصر این شکل به فهرست ۳ مراجعه کنید.

شکل ۵٫ نمایش سیستم شبکه جهانی گسسته AusPIX از هندسه ناحیه انتخاباتی بریزبن. چند ضلعی اصلی در بالا با چهار تصویر پایین نشان داده شده است که سلول‌های AusPIX DGGS را با وضوح بالاتر و بالاتر نشان می‌دهد که اصطلاحاً سطوح ۷، ۸، ۹ و ۱۰ نامیده می‌شوند.

شکل ۶٫ واژگان الزامات اعمال شده برای نتایج معیار معیار انطباق GeoSPARQL که در پلت فرم HOBBIT اعمال می شود. نتایج محک را می توان به مفاهیم RDF که نشان دهنده الزامات و کلاس های انطباق مشخصات مورد آزمایش است، ترسیم کرد.

شکل ۷٫ پلاگین SPARQL Unicorn QGIS با پشتیبانی از FeatureCollections و GeometryCollections همانطور که در GeoSPARQL 1.1 تعریف شده است گسترش یافته است.

شکل ۸٫ گفتگوی تبدیل در حال توسعه برای فایل های داده های پیوندی مکانی با هدف پشتیبانی کامل از تبدیل واقعی GeoSPARQL 1.1.

شکل ۹٫ یک نسخه توسعه‌یافته از نرم‌افزار «نشنال نقشه» استرالیا که داده‌هایی را نشان می‌دهد که از مجموعه داده‌های GeoSPARQL 1.1 RDF به دست آمده است. کادر محاوره‌ای روی رابط نقشه، ویژگی‌های مربوط به ویژگی «کوئین‌لند» را از طریق روابط Simple Features مانند geo:sf در داخل که نرم‌افزار National Map قبلاً قادر به نمایش آن نبوده است، نشان می‌دهد.

شکل ۱۰٫ گزیده ای از برخی از اجزای زیرساخت دانش فضایی. فروشگاه سه گانه با GeoSPARQL 1.1. پشتیبانی به‌عنوان پشتوانه داده برای زیرساخت خدمات پشتیبانی شده با ویژگی‌های OGC API که توسط مشتریان GIS سنتی استفاده می‌شود، ارائه می‌شود.

شکل ۱۱٫ تصویری از یک API داده پیوندی که توسط Geoscience استرالیا اجرا می‌شود و داده‌های منطقه سیل‌زده را به صورت آنلاین در فرم‌های HTML و RDF از یک باطن GeoSPARQL 1.1 ارائه می‌دهد. API همچنین یک API سازگار با ویژگی های OGC API است زیرا RDF در صورت نیاز به (Geo)JSON تبدیل می شود.

ونوس نصیرفام

5 ژانویه 2023

مقالات