معناشناسی خدمات وب: آزمونی در کاربردهای علوم GIS

چکیده

وب سرویس یک راه حل فناورانه برای قابلیت همکاری نرم افزار است که از یکپارچه سازی یکپارچه برنامه های کاربردی مختلف پشتیبانی می کند. در چشم انداز معماری وب سرویس، وب سرویس ها توسط زبان توصیف وب سرویس (WSDL) توصیف می شوند، از طریق توصیف جهانی، کشف و یکپارچه سازی (UDDI) کشف می شوند و توسط پروتکل دسترسی به اشیاء ساده (SOAP) ارتباط برقرار می کنند. چنین پیشگویی هرگز به طور کامل انجام نشده است. اگرچه مورد انتقاد قرار گرفت که WSDL فقط یک تعریف نحوی از خدمات وب دارد، اما معنایی ندارد، ابتکارات قبلی در خدمات وب معنایی یک روش صحیح برای حل مشکل ایجاد نکرد. این مقاله به بررسی تمایز و رابطه بین تعاریف نحوی و معنایی برای سرویس‌های وب می‌پردازد که اهداف مختلف را در محاسبه سرویس مشخص می‌کنند. علاوه بر این، این مقاله پیشنهاد می‌کند که معنایی سرویس وب خنثی و مستقل از تعریف رابط سرویس، انواع داده‌ها و پلت فرم است. چنین نتیجه گیری می تواند یک قانون جهانی در مهندسی نرم افزار و محاسبات خدمات باشد. چندین مورد استفاده در کاربرد GIScience در این مقاله بررسی می‌شود، در حالی که رسمی‌سازی خدمات جغرافیایی باید توسط جامعه GIScience به سمت هستی‌شناسی جامع تعاریف مفهومی و روابط برای محاسبات مکانی ساخته شود. پیشرفت در تحقیقات خدمات وب معنایی در کاربردهای علمی حوزه اتفاق خواهد افتاد. چنین نتیجه گیری می تواند یک قانون جهانی در مهندسی نرم افزار و محاسبات خدمات باشد. چندین مورد استفاده در کاربرد GIScience در این مقاله بررسی می‌شود، در حالی که رسمی‌سازی خدمات جغرافیایی باید توسط جامعه GIScience به سمت هستی‌شناسی جامع تعاریف مفهومی و روابط برای محاسبات مکانی ساخته شود. پیشرفت در تحقیقات خدمات وب معنایی در کاربردهای علمی حوزه اتفاق خواهد افتاد. چنین نتیجه گیری می تواند یک قانون جهانی در مهندسی نرم افزار و محاسبات خدمات باشد. چندین مورد استفاده در کاربرد GIScience در این مقاله بررسی می‌شود، در حالی که رسمی‌سازی خدمات جغرافیایی باید توسط جامعه GIScience به سمت هستی‌شناسی جامع تعاریف مفهومی و روابط برای محاسبات مکانی ساخته شود. پیشرفت در تحقیقات خدمات وب معنایی در کاربردهای علمی حوزه اتفاق خواهد افتاد.

کلید واژه ها:

معنایی ; خدمات وب ; GIScience

1. مقدمه

در انگلیسی، خدمات به معنای « کار انجام شده برای دیگران » [ 1 ]، « کمک به رفاه دیگران » [ 2 ] یا « کار انجام شده برای کسی » [ 3 ] است. برای سایرینی که می خواهند از «خدمات» استفاده کنند، پیش نیاز این است که بتوانند خدمات مورد نیاز را پیدا کنند. اگر چنین پیش نیازی برآورده نشود، دیگر هیچ خدماتی برای دیگران وجود ندارد. در سال 2007، مایکل برودی نوشت: «چگونه سرویس‌ها خدمات مناسبی را که الزامات خاص را در چنین محیطی برآورده می‌کنند، کشف می‌کنند؟ ما در حال حاضر با این مقیاس فاصله داریم.» [ 4]. اگر از کشف خدمات مناسب فاصله داریم، پس چگونه می‌توانیم از آنها در تحقیقات و توسعه‌های متنوع مرتبط با خدمات در چند سال گذشته استفاده کنیم؟ پیش از این، در سال 2005، یان فاستر در Science (“علم خدمات محور”، 6 مه 2005) اظهار داشت که “سرویس های (وب) ارزش کمی دارند اگر دیگران نتوانند آنها را کشف کنند، به آنها دسترسی پیدا کنند و آنها را درک کنند” [ 5 ]، که همچنین به این معنی است. ، به نظر می رسد کشف سرویس اولین سفارش برای دیگران برای استقرار خدمات مفید باشد. در اصل، کشف خدمات کلید و نقطه شروع در محاسبات خدمات است.

چرا هنوز تا کشف خدمات مناسب فاصله داریم؟ هنگام توسعه به اصطلاح فناوری خدمات وب، قول داده شد که وقتی یک سرویس به زبان توصیف وب سرویس (WSDL) تعریف می‌شود، یک ارائه‌دهنده خدمات می‌تواند سرویس را در یک رجیستری سرویس منتشر کند (مانند توضیحات جهانی، کشف و یکپارچه‌سازی (UDDI) ، و یک درخواست کننده سرویس می تواند سرویس را از طریق UDDI پیدا کند و از طریق پروتکل دسترسی به شی ساده (SOAP) سرویس را مصرف و فراخوانی کند. کنسرسیوم وب جهانی (W3C) (2004) سه رویکرد را برای کشف سرویس پیشنهاد کرد که شامل ثبت خدمات، فهرست و همتا به همتا (P2P) است [ 6]. P2P غیرممکن است، زیرا تحت فناوری وب سرویس موجود، یک سرویس فقط دارای یک تعریف واسط مشخص شده در WSDL است، در حالی که یک پیام را می توان از طریق پروتکل SOAP رد و بدل کرد. هیچ مکانیزمی برای “سرویس” وجود ندارد که از همسایگان خود در جستجوی یک وب سرویس مناسب پرس و جو کند. رویکرد شاخص نیز امکان پذیر نیست و با چالش ها و مشکلات مختلفی مواجه می شود [ 7 ]. هنگامی که UDDI Business Registry (UBR) در اوایل سال 2006 بسته شد [ 8 ]، هیچ راه موفقیت آمیزی برای دیگران برای کشف خدمات وجود نداشت، چه رسد به خدمات مناسب. در عمل، ممکن است پیشرفت خاصی در کشف داده ها وجود داشته باشد. با این حال، در این مقاله، یک سرویس بنا به تعریف یک ماژول نرم افزاری است. کشف داده ها ممکن است تمرکز این مقاله نباشد.

به دلایل مختلف، توصیف خدمات با معنای کمی باید مسئله کلیدی باشد. با این حال، این که معنای خدمات وب چیست، یک سوال اساسی علمی، مدت زیادی است که روشن نشده است. این مقاله بحث در مورد مفهوم خدمات وب را آغاز می کند و سعی می کند شکاف بین سرویس های وب مبتنی بر SOAP و انتقال وضعیت نمایندگی (REST) را کاهش دهد. یک کشف سرویس یکپارچه را می توان با هدف قرار دادن مرکز خدمات وب به عنوان ماژول های کاربردی نرم افزار ترکیب کرد. می توان توضیح داد (1) چرا معنایی سرویس های وب خنثی و مستقل از تعاریف رابط برنامه نویسی برنامه نحوی (API) است. (2) چرا معناشناسی خدمات وب هیچ ارتباطی با کسی که خدمات را توسعه می دهد ندارد. و (3) چرا هر مفهومی در تعاریف معنایی یک همتای نحوی متناظر ندارد. چنین قوانین کلی اصول علمی را برای ساخت معناشناسی سرویس های وب ایجاد می کند و می تواند توسط کاربردهای علمی حوزه های مختلف مورد بررسی و اعتبار قرار گیرد. یک نمونه اولیه برای بررسی رویکردهایی برای رسمی کردن خدمات مکانی به سمت هستی شناسی جامع تعاریف مفهومی و روابط برای خدمات مکانی و ماژول های محاسباتی پیشنهاد شده است که برای مهندسی نرم افزار GIS و آموزش علوم GIS نیز مفید خواهد بود. یک چارچوب دانش جغرافیایی مبتنی بر هستی شناسی به سازماندهی ماژول ها و ابزارهای نرم افزاری به روشی معنادارتر یا معنایی تر در محصولات نرم افزار GIS کمک می کند. در نتیجه، نرم افزار معنی دار GIS به دانش آموزان کمک می کند تا مفاهیم GIScience را درک کنند و ابزارها و ماژول های مناسب را برای انجام وظایف مختلف برای تجزیه و تحلیل و پردازش داده ها بیابند. قوانین پیشنهادی و خدمات مکانی رسمی‌شده را می‌توان از طریق یک سیستم ثبت پایدار که دارای مکانیزم سایبرنتیکی برای اعمال مشخصات نحوی و معنایی است، پیاده‌سازی کرد، در حالی که روش پیشنهادی می‌تواند به سایر کاربردهای علمی حوزه گسترش یابد.

2. آشفتگی در مفهوم و شرح خدمات وب

در چشم انداز معماری وب سرویس یا معماری سرویس گرا، باید مکانیزم یا مؤلفه ای وجود داشته باشد که به ارائه دهندگان خدمات اجازه دهد خدمات خود را منتشر کنند و درخواست کنندگان خدمات را قادر می سازد تا خدمات مورد نیاز را پیدا کنند. مفهوم وب سرویس، با این حال، می تواند با جنبه های مختلف تفسیر شود، در حالی که توصیف خدمات وب به عنوان غیر معنایی مورد انتقاد قرار گرفته است. اگر چه هستی شناسی و تحقیقات معنایی در مورد مفاهیم و روابط بین مفاهیم است، در محاسبات سرویس گرا، اگر مفاهیم اصلی و توصیف خدمات وب مشخص نباشد، آنچه می تواند کشف شود می تواند یک معما باشد. درک هرج و مرج در چارچوب مفهومی خدمات وب برای ایجاد یک زمینه مشترک برای بحث و کشف راه حل های بالقوه مفید است. این بخش ابتدا مفاهیم مختلف خدمات وب را بررسی می کند تا موضوع اصلی مورد بحث در این مقاله را روشن کند. هرج و مرج در تعریف نحوی و شرح خدمات وب توضیح داده می شود تا به درک اینکه چرا کشف سرویس ممکن است بر اساس اشیاء نحوی و ماژول های تعریف شده در WSDL موفق نباشد، توضیح داده می شود. چنین بحثی برای بررسی معنایی سرویس های وب اساسی است و در بخش بعدی به تفصیل توضیح داده می شود.

2.1. مفهوم وب سرویس

تحقیقات علمی باید دارای چارچوب مفهومی دقیق و منسجم باشد. اگرچه تحقیق و توسعه مرتبط با «خدمات» مد در دانشگاه و صنعت بود، اما چنین تحقیقاتی زمانی که از یک مفهوم پیچیده، اما نادقیق شروع می‌شوند، ممکن است دقت علمی چندانی نداشته باشند. در طول دوره توسعه و تکامل فناوری، چیزی که باید بر آن تاکید شود این است که وب سرویس، به عنوان یک نسل از فراخوان رویه از راه دور (RPC)، در ابتدا راه حلی برای قابلیت همکاری نرم افزار بود و جای معماری کارگزار درخواست مشترک شی (CORBA) را گرفت. و مدل شیء جزء توزیع شده (DCOM). متأسفانه، خود این مفهوم به طور مبهم با “وب” مرتبط است، اگرچه این فناوری ممکن است حتی هیچ ارتباطی با وب نداشته باشد.

روی فیلدینگ (2000) [ 9 ] مفهوم انتقال حالت نمایندگی (REST) را برای توصیف سبک معماری سیستم های شبکه ای پیشنهاد کرد. او توضیح داد: «انتقال حالت نمایندگی برای برانگیختن تصویری از نحوه رفتار یک برنامه وب با طراحی خوب در نظر گرفته شده است: شبکه ای از صفحات وب (یک ماشین حالت مجازی)، که در آن کاربر با انتخاب پیوندها (انتقال وضعیت) از طریق یک برنامه پیشرفت می کند. ، در نتیجه صفحه بعدی (نماینده وضعیت بعدی برنامه) به کاربر منتقل شده و برای استفاده او رندر می شود.” [ 9 ]. در علم، REST بر اساس پایان نامه روی، در مورد برنامه های کاربردی وب یا صفحات وب است. سرویس REST از طریق تعریف URL با استفاده از روش های HTTP GET|POST فراخوانی می شود.

به ناچار، نتیجه تحقیق و توسعه مرتبط با خدمات محکوم به مبهم بودن و پر از هرج و مرج یا پارادوکس بدون مفهوم دقیق است. ما از سال های اولیه دهه شاهد بحث بین خدمات SOAP و REST بوده ایم. بعداً مفهوم “وب سرویس” به عنوان خدمات در وب تبدیل شد. سپس، چنین «سرویس‌هایی» می‌توانند وب‌سایت‌ها و برنامه‌های کاربردی وب باشند، زیرا «خدمات» را به کاربرانی که از وب برای مقاصد مختلف استفاده می‌کنند، ارائه می‌دهند، اگرچه خدمات مبتنی بر SOAP، نسل RPC، می‌تواند در چنین دسته‌بندی گسترده‌ای قرار گیرد. از “خدمات”. علاوه بر این، می‌توانیم بسیاری از دسته‌های دیگر «خدمات» [ 10 ] را بدون تعجب پیدا کنیم.

مفهوم “خدمات وب” برای بیش از یک دهه زمانی که خدمات مبتنی بر SOAP و REST در اوایل سال 2000 سرچشمه گرفتند، آشفته بود . ]. دیدن این استدلال که یک سرویس مبتنی بر وب یک سرویس وب واقعی نیست یا یک وب سرویس را می توان به عنوان یک سرویس در وب تفسیر کرد، غیرعادی نیست [ 12 ]. در دنیای «سرویس وب معنایی»، «سرویس وب معنایی» به وضوح با «وب سرویس معنایی» متفاوت است، زمانی که خط فاصله به طور متفاوتی قرار داده شود. اما در تحقیقات علمی، اگر از مفهومی مبهم شروع کنیم، چگونه می‌توانیم بفهمیم که همدیگر در مورد چه چیزی صحبت می‌کرده‌اند و به یک نتیجه روشن و درست دست یابیم؟

هنگامی که شبکه جهانی وب یا W3C مفهوم «وب سرویس‌ها» را تعریف کرد، برخلاف بسیاری چیزهای دیگر، W3C [ 13 ] مجبور بود ادعا کند:

–: در کل دنیا چیزهای زیادی وجود دارد که می توان آنها را “وب سرویس” نامید. اما برای اهداف این کارگروه و این معماری و بدون تعصب نسبت به تعاریف دیگر، از تعریف زیر استفاده خواهیم کرد:
–: وب سرویس یک سیستم نرم افزاری است که برای پشتیبانی از تعامل ماشین به ماشین قابل کار بر روی یک شبکه طراحی شده است. دارای یک رابط است که در قالب قابل پردازش ماشین (به طور خاص، WSDL) توضیح داده شده است. سیستم‌های دیگر با سرویس وب به روشی که شرح آن با استفاده از پیام‌های SOAP، که معمولاً با استفاده از HTTP با سریال‌سازی XML در ارتباط با سایر استانداردهای مرتبط با وب، منتقل می‌شود، با وب سرویس تعامل دارند.

در واقع، بیانیه W3C به این معنی است که بسیاری از چیزها ممکن است اصلاً خدمات وب نباشند. هرج و مرج در سطح مفهومی، مشکلات در کشف خدمات را افزایش می دهد. با توجه به اینکه هر دو سرویس مبتنی بر SOAP و REST می توانند عملکردهای مشابهی را فعال کنند که محاسبات (جغرافیایی) را روی شبکه کامپیوتری پیاده سازی می کنند، نیاز به یکپارچه سازی فرآیند کشف سرویس وجود دارد که بتواند هر دو نوع سرویس را پوشش دهد. در واقع، اگر سرویس به عنوان یک ماژول کاربردی نرم افزار GIS مورد بررسی قرار گیرد، آنگاه شکاف و بحث بین سرویس های مبتنی بر SOAP و REST می تواند کاهش و ترکیب شود. مهم نیست که یک سرویس در چه پروتکلی پیاده سازی شده است، یک سرویس، یا ماژول عملکردی، دارای یک چارچوب نحوی است که از چرخه عمر مهندسی نرم افزار پیروی می کند تا ورودی ها، خروجی ها، پیش شرط ها و اثرات (IOPEs) [ 14 ، 15 ] عملکرد یا سرویس را تعریف کند. بدیهی است که تعریف نحوی IOPE برای فراخوانی سرویس استفاده می شود، نه برای کشف سرویس.

2.2. آشفتگی در توصیف نحوی سرویس های وب

اگرچه WSDL زبان توصیف برای خدمات وب نامیده می‌شود، اما تعریف نحوی رابط‌های برنامه‌نویسی کاربردی (API) سرویس‌هایی را که اطلاعات IOPE را برای ماژول‌های عملکردی خاص در سرویس پوشش می‌دهند، توصیف می‌کند. از آنجایی که WSDL با الگوی برنامه نویسی شی گرا ارتباط مستقیم دارد، تعاریف در WSDL با داده ها، نوع داده، تابع، اشیاء و غیره در ماژول های تابعی مطابقت دارند. از آنجایی که چنین تعاریفی را می توان به صورت تصادفی نامگذاری کرد، می توان نتیجه گرفت که همان ارائه دهنده خدمات می تواند از رابط های سرویس مختلف تعریف شده در اسناد WSDL حتی در هنگام توسعه یک نوع سرویس استفاده کند. از سوی دیگر، ممکن است که الفارائه دهندگان خدمات مختلف می توانند از رابط های سرویس مشابه تعریف شده در اسناد WSDL حتی در هنگام توسعه انواع خدمات استفاده کنند. به همین دلیل، توضیحات نحوی متنوعی از خدمات در واقع پر از هرج و مرج است که از کشف موفقیت آمیز سرویس جلوگیری می کند. هنگامی که چنین اسناد شرح خدمات آشفته ای آزادانه و به طور تصادفی در یک رجیستری خدمات منتشر شد، مانند UDDI، که به طور مستقیم با تعاریف WSDL مطابقت دارد، شکست در کشف سرویس اجتناب ناپذیر بود.

در عمل GIScience، ESRI، پیشرو جهانی در توسعه نرم‌افزار و فناوری GIS، خدمات وب کدگذاری جغرافیایی را در چندین نسخه ارائه می‌کند. در ابتدا، خدمات وب کدگذاری جغرافیایی آدرس آن ( http://arcweb.esri.com/services/v2/AddressFinder.wsdl ) تابعی به نام findAddress داشت که شیئی به نام LocationInfo را برمی گرداند . در نسخه جدیدتر، دقیقاً همان تابع ( http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl ) به findLocationByAddress تغییر نام داده شد که یک شی به نام GeocodeInfo را برمی گرداند . این می تواند شواهد خوبی برای حمایت از نتیجه گیری فوق باشد که ارائه دهنده خدمات مشابه می تواند از موارد متفاوتی استفاده کندرابط های سرویس تعریف شده در اسناد WSDL حتی در هنگام توسعه همان نوع سرویس.

با توجه به مثال دیگر، در حالی که geocoder.us خدمات وب geocoding را نیز در نسخه های مختلف ارائه می دهد، مانند http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl و http://geocoder.us/dist/ eg/clients/GeoCoderPHP.wsdl ، تعریف رابط سرویس آن با خدمات وب کدگذاری جغرافیایی آدرس ESRI متفاوت است. چنین واقعیتی نشان می‌دهد که ارائه‌دهندگان خدمات مختلف می‌توانند رابط‌های سرویس متفاوتی را که در اسناد WSDL تعریف شده‌اند، هنگام توسعه یک نوع سرویس ایجاد کنند.

در مورد سرویس های REST، URL های ساخت یافته را می توان برای فراخوانی یک سرویس از طریق روش HTTP GET ایجاد کرد. در این مورد، URL با داده های ورودی یا اطلاعات تعریف شده در قالب یا بدون قالب جاوا اسکریپت Object Notation (JSON) دنبال می شود. متغیرهای مورد استفاده در ایجاد URL می توانند به صورت تصادفی تعریف شوند، که اغلب منجر به سردرگمی می شود مگر اینکه مستندات دقیق ارائه شود. هنگامی که همان تابع با استفاده از روش HTTP POST پیاده سازی می شود، ممکن است داده های ورودی در نوشتن URL پیوست نشوند. همان وضعیت آشفته توصیف شده در سرویس های مبتنی بر WSDL/SOAP در بالا می تواند در سرویس های REST تکرار شود. در نتیجه، محتوای موجود در تعریف نحوی سرویس مبتنی بر SOAP یا REST هیچ ارتباطی با معنایی خدمات وب ندارد.

3. معناشناسی خدمات وب در خدمات وب معنایی

معناشناسی خدمات وب چیست؟ این سوال بعد از اینکه ابتکار تحقیقاتی خدمات وب معنایی (SWS) حتی با تعداد زیادی از انتشارات برای بیش از یک دهه در حال تکامل است، نابهنگام به نظر می رسد. این بخش ابتدا تعریف جدیدی را پیشنهاد می کند که کاملاً با کارهای قبلی متفاوت است و با بررسی مختصری در مورد ابتکارات قبلی در خدمات وب معنایی در دهه گذشته برای کمک به درک تمایزات دنبال می شود. می توان روشن کرد که فراخوانی سرویس پویا ممکن است به موضوع معنایی مرتبط نباشد، اگرچه ادعا شد که سرویس وب معنایی به فراخوانی سرویس پویا کمک می کند.

3.1. معناشناسی خدمات وب

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

این تعبیر متفاوت است. زیرا در کارهای قبلی، معنایی سرویس‌های وب در مورد مؤلفه‌هایی است که در تعریف نحوی سرویس توضیح داده شده در WSDL، از جمله IOPEها، همراه با اطلاعات دیگر، مانند نمایه‌های ارائه‌دهنده خدمات. در آغاز این ابتکار، تحقیقات SWS در علوم کامپیوتر و جریان اصلی IT عمدتاً بر مدل‌های مختلف مبادلات تجاری مانند «خرید کتاب»، «خرید بلیط هواپیما»، «رزرو هتل و اتومبیل» و غیره متمرکز بود.هنگامی که چنین خدماتی در برنامه های کاربردی وب (معنی) استفاده می شد، تعاریف API یا IOPE در WSDL بی معنی بود. در نتیجه، نحوه حاشیه نویسی API های سرویس یا IOPE توسط فناوری وب معنایی در فرآیند ترکیب بندی به منظور زنجیره خدمات برای انجام معاملات تجاری آنلاین بسیار مهم بود.

بدیهی است که تعداد کمی از محققین به رابطه بین خدمات وب «خرید کتاب»، «خرید بلیط هواپیما» و «رزرو هتل و اتومبیل» اهمیت می‌دهند. در واقع، اگر فقط چنین سناریوهای تجاری درگیر باشد، چند مفهوم تجاری مجزا در این موارد استفاده ساده و یکنواخت کافی است. با این حال، اگر چارچوب SWS را در یک حوزه دانش سیستماتیک، مانند GIScience بررسی کنیم، می‌توانیم نتیجه‌گیری کاملاً متفاوتی داشته باشیم. شکل 1 برای توضیح برخی از قوانین کلی برای درک و بازسازی چارچوب مفهومی برای رسمی کردن هستی شناسی و معناشناسی خدمات وب بصری و ساده است :

معنای خدمات خنثی و مستقل از تعاریف API نحوی (IOPEs) است.
معنایی خدمات وب هیچ ارتباطی با کسی که خدمات را توسعه می دهد ندارد.
هر مفهومی در تعاریف معنایی همتای نحوی مربوطه ندارد.

شکل 1 یک معماری طبقه بندی از معنای خدمات وب کدگذاری جغرافیایی را توصیف می کند. ژئوکدینگ یک عملکرد رایج در GIS است. این طبقه بندی شامل مفاهیم سلسله مراتبی از سرویس های وب است که عملکرد کدگذاری جغرافیایی را انجام می دهد ، که اطلاعات مکان (طول و عرض جغرافیایی) را از اشیاء ورودی مختلف که می تواند یک نقطه عطف ، یک مکان پرجمعیت ، یک آدرس خیابان یا یک آدرس IP یا یک شماره تلفن باشد، استخراج می کند. در حالی که چنین مفاهیمی را می توان در زیر مجموعه های زیادی طبقه بندی کرد.

شکل 1. معماری تاکسونومیک معنایی خدمات وب کدگذاری جغرافیایی.

تعریف API نحوی آشکارا با مفهوم معنایی خدمات متفاوت است، زیرا APIها در مورد IOPEها هستند، مانند متغیرهای ورودی و خروجی، قالب‌های داده و نام توابع. همانطور که در بالا توضیح داده شد، ESRI چندین نسخه از خدمات کدگذاری جغرافیایی آدرس خیابان را ارائه کرده است. همه نسخه‌های سرویس‌ها دقیقاً عملکرد مشابهی را انجام می‌دهند، اما هر کدام از آنها یک API متفاوت دارند [ 16 ، 17 ]. در همین حال geocoder.us با استفاده از یک API متفاوت [ 18 ]، خدمات رمزگذاری جغرافیایی یکسانی را ارائه می دهد ، در حالی که Google و Yahoo! این تابع کدگذاری جغرافیایی را به صورت آنلاین از طریق رویکرد REST ارائه دهید.

بنابراین می توان نتیجه گرفت که معنایی سرویس وب خنثی و مستقل از تعاریف API نحوی (و IOPEs) است و هیچ ارتباطی با کسی که خدمات را توسعه می دهد ندارد. مهم نیست که سرویس کدگذاری جغرافیایی چگونه توسعه یافته است و مهم نیست که چه کسی سرویس رمزگذاری جغرافیایی را توسعه می دهد، معنایی سرویس های وب ژئوکدینگ در طبقه بندی شرح داده شده در شکل 1 یکسان است، اگرچه API ها یا IOPE ها می توانند متفاوت باشند. علاوه بر این، هر مفهومی در طبقه بندی معنایی خدمات، مشابه نحوی مربوط به آن را ندارد.. در واقع، مفهوم وب سرویس کدگذاری جغرافیایی باید به مجموعه ای از خدمات وب در این طبقه بندی معنایی اشاره داشته باشد. مفهوم سرویس وب جغرافیایی خود یک API نحوی مرتبط با این مفهوم معنایی ندارد، در حالی که نحوه توسعه وب سرویس‌ها (API) به تعریف معنایی وابسته نیست.

هنگامی که درک این موضوع آسان است که ورودی ها و خروجی ها (IO) را می توان به عنوان بخشی از تعاریف API در نظر گرفت و بنابراین، به معنایی سرویس های وب مرتبط نیست، پیش شرط ها و اثرات (PE) نباید به معنایی سرویس های وب مرتبط باشند. یا یک پیش شرط برای اطمینان از برآورده شدن تمام الزامات ورودی قبل از فراخوانی سرویس بررسی می شود. افکت یا پس افکت مربوط به نتایج پس از فراخوانی سرویس است. با توجه به مثال “طبقه بندی تصویر بدون نظارت”، برای فراخوانی چنین سرویسی، پیش شرط شامل چهار متغیر است ( یعنی.، فایل منبع تصویر، تعداد کلاس ها، حداکثر تعداد تکرار و نسبت آستانه برای خاتمه عملکرد) که باید تعریف شود. اگر هر یک از پیش شرط ها برآورده نشود، عملکرد یا سرویس فراخوانی نخواهد شد. در مورد اثر فراخوانی سرویس، یکی از نتایج احتمالی می تواند شکست تماس سرویس، به عنوان مثال، به دلیل مشکلات حافظه باشد. مهم نیست که پیش شرط (P) یا اثر (E) چه می تواند باشد، ربطی به مفهوم این سرویس ندارد ( یعنی.، “طبقه بندی تصاویر بدون نظارت”). این مفهوم بدون توجه به موفقیت آمیز بودن یا نبودن فراخوان خدمات یکسان است. در نتیجه، PE مربوط به «معناشناسی سرویس‌های وب» نیست، زیرا ما هرگز مفهوم یک سرویس را تغییر نمی‌دهیم، زیرا درخواست‌کننده سرویس نمی‌تواند پیش‌شرط فراخوانی یک سرویس را برآورده کند یا به این دلیل که سرویس به دلایلی از کار می‌افتد.

ژئوکدینگ یک مفهوم حرفه ای در GIS است. از طرف دیگر، همان مفهوم را می‌توان با عبارات مشابه یا مرتبط با سایر توسعه‌دهندگان برنامه‌ها یا خدمات، مانند «موقعیت» [ 19 ]، «موقعیت یاب» یا «موقعیت‌یابی» سرویس نامید. همه این اصطلاحات در مورد مفهوم سرویس هستند، اما در سطح معنایی متفاوت هستند . بنابراین، آنها را می توان به عنوان کلاس معادل خدمات geocoding از طریق رسمی کردن هستی شناسی و معناشناسی خدمات وب تعریف کرد. بدیهی است که معنایی سرویس های وب، یعنی مفاهیم سرویس ها و رابطه بین سرویس ها، هیچ ارتباطی با API یا IOPE ندارند.

طبقه بندی نمونه در شکل 1 بخش بسیار کوچکی در دانش حوزه GIScience است، زیرا نرم افزار GIS ممکن است بیش از 600 عملکرد داشته باشد که از نظر تئوری می تواند به خدمات تجزیه شود. خدمات محاسباتی پوشش برداری ممکن است عملیات اتحاد ، تفاوت ، OR انحصاری (XOR) یا تقاطع را روی مجموعه داده های ورودی انجام دهند. انواع خدمات محاسبات شطرنجی ممکن است شامل درون یابی ، سایه تپه ، نمای و طبقه بندی مجدد باشد. خدمات شبکه ممکن است عملکردها را برای انواع مختلف پوشش دهدشبکه هایی مانند حمل و نقل ، هیدرولوژی ، برق ، آب و تاسیسات فاضلاب . مفاهیم مربوط به خدمات آماری مکانی آشکارا به دو حوزه دانش مرتبط است.

همه این کلمات به صورت موربمربوط به معنایی خدمات وب جغرافیایی هستند، به این معنی که آنها در چارچوب مفهومی خدمات وب جغرافیایی قرار دارند. در این چارچوب مفهومی، رابطه بین هزاران مفهوم خدمات تعریف و رسمیت یافته است. این چارچوب مفهومی هستی شناسی و معناشناسی صدها توابع و خدمات مکانی است که خنثی و مستقل از API ها یا IOPE ها هستند. مهم نیست که چه کسی هر یک از این خدمات وب جغرافیایی را در هر API با IOPE های متنوع توسعه می دهد، معنایی سرویس های وب جغرافیایی در چارچوب مفهومی یکسانی است. نتیجه کشف سرویس بر اساس معنایی سرویس‌های وب شامل URI سرویس‌ها خواهد بود که می‌تواند شناسه‌های ارائه‌دهندگان خدمات یا توسعه‌دهندگان باشد. در این مورد، جزئیات مشخصات معنایی خدمات را می توان بیشتر مورد بررسی قرار داد. تأثیر مشخصات معنایی و کشف خدمات تأثیر گسترده‌تری بر تحقیق در مورد کیفیت خدمات خواهد داشت که ممکن است بر رفتار کاربران نیز تأثیر بگذارد.

3.2. کارهای قبلی روی خدمات وب معنایی

در حالی که خدمات وب مورد انتقاد قرار می گرفتند، زیرا آنها فقط دارای تعاریف نحوی بدون معناشناسی بودند، مدتهاست که انتظار می رفت که تحقیقات خدمات وب معنایی بتواند کشف خودکار و پویا سرویس، مطابقت، ترکیب و فراخوانی سرویس های وب را امکان پذیر کند. با این حال، باید روشن شود که فراخوانی خدمات مبتنی بر تعریف نحوی خدمات است، نه معنایی خدمات. تعریف یا مشخصات معنایی برای فرآیند کشف خدمات اساسی است، در حالی که به فرآیندهای مطابقت و ترکیب که بر اساس نتایج کشف سرویس است کمک می کند. متأسفانه، سه عضو ارسالی به W3C [ 20 ، 21 ، 22]، از جمله حاشیه نویسی معنایی به WSDL (SAWSDL)، زبان هستی شناسی وب برای سرویس های وب (OWL-S) و هستی شناسی مدل سازی سرویس وب (WSMO)، نمی تواند به کشف موفقیت آمیز سرویس کمک کند، زیرا این کارهای قبلی همگی بر اساس یا مرتبط با WSDL بودند. ، در حالی که ثابت شده است که معنای خدمات خنثی و مستقل از تعاریف API نحوی (IOPEs) در WSDL است.

3.2.1. SAWSDL و SAREST

در حالی که ادعا می شد [ 23 ] که “SAWSDL اولین گام برای القای معناشناسی به سرویس ها و SOA است”، نشان داده شده است که معناشناسی وب سرویس خنثی و مستقل از تعریف رابط سرویس مشخص شده در سند WSDL است ، زیرا معنای سرویس یکسان را می توان از طریق یک تعریف رابط سرویس متفاوت مشخص شده در WSDL پیاده سازی کرد، در حالی که همان تعریف رابط مشخص شده در WSDL می تواند معنای خدمات متفاوتی داشته باشد. علاوه بر این، افزودن حاشیه‌نویسی معنایی به WSDL به هر ارائه‌دهنده خدمات مختلف اجازه می‌دهد تا تعریف رابط سرویس را به روشی متفاوت حاشیه‌نویسی کند – نتیجه ممکن است منجر بههرج و مرج معنایی ، اگرچه نویسندگان این آگاهی را نداشتند که معنایی خدمات وب هیچ ارتباطی با WSDL ندارد. با توجه به مثالی از خدمات کدگذاری جغرافیایی که در بالا مورد بحث قرار گرفت، مشروح کردن تعاریف نحوی « findAddress »، « LocationInfo »، « findLocationByAddress » و « GeocodeInfo » نمی تواند معادل معنایی بین همان سرویس های کدگذاری جغرافیایی ایجاد شده در نسخه های مختلف ایجاد کند. به طور مشابه، به اصطلاح SAREST سعی می کند حاشیه نویسی معنایی را به یک صفحه وب اضافه کند که خدمات REST را توصیف می کند، اما چنین رویکردی ارزش کمی برای فعال کردن کشف سرویس معنی دار به دلایل مشابه دارد.

3.2.2. OWL-S و WSMO

هر دو OWL-S و WSMO [ 20 ، 21 ] مملو از پارادوکس ها و فرضیات هستند ، زیرا مفهوم وب سرویس را با وب سایت مخلوط می کنند. وقتی در مورد نقش ارائه دهندگان خدمات متنوع در ارسال و آموزش خود بحث می کنند، درک اینکه آیا آنها در مورد یک وب سرویس صحبت می کنند یا یک وب سایت آسان نیست . هر دو رویکرد بر تجمیع خدمات از طریق مدل‌های منطقی متنوع تمرکز دارند. در واقع، OWL-S و WSMO ممکن است به کشف سرویس مربوط نباشند، زیرا هر دو عمدتاً در مورد ایجاد خدمات در وب (معانی) بودند. در نهایت، هر دو رویکرد به خودی خود اختصاصی هستند و بنابراین با یکدیگر سازگار نیستند، چه رسد به راه حلی برای قابلیت همکاری معنایی.

3.2.3. فراخوانی دینامیک وب سرویس

فراخوانی پویا از خدمات وب به عنوان یکی از اهداف گسترده SWS ادعا شده بود. برخلاف فراخوانی سرویس ایستا، فراخوانی سرویس پویا به این معنی است که برنامه مشتری هیچ پیوندی به قسمت‌های خرد سرویس از پیش آپلود شده ندارد که کلاس‌های سرور تعریف‌شده و مشخص‌شده در سند WSDL را پیاده‌سازی می‌کند. فراتر از این جنبه برنامه نویسی ، فراخوانی سرویس پویا به صورت زیر پیش بینی می شد: ” بدون هیچ گونه برنامه ریزی مجدد، یک سیستم نرم افزاری می تواند انعطاف پذیری برای استفاده از سرویس های مختلفی را داشته باشد که کار مشابهی را انجام می دهند اما API های متفاوتی دارند ” [ 25 ]. در صورتی که درخواست کننده سرویس بتواند چندین سرویس مورد نیاز را پیدا کند، درخواست کننده می تواند هر یک از سرویس های کشف شده را فراخوانی کندبدون نیاز به برنامه ریزی مجدد

با توجه به مثال خدمات وب کدگذاری جغرافیایی، همان سرویس را می توان به روش های مختلف با API ها و IOPE های مختلف توسعه داد. مهم نیست که مفاهیم معنایی چگونه بر روی چنین API یا IOPE ها حاشیه نویسی می شوند، فراخوانی سرویس پویا یا خودکار امکان پذیر نیست . با توجه به نمونه‌ای از نسخه‌های چندگانه ESRI از یک سرویس رمزگذاری جغرافیایی یکسان، ESRI راهنمای دقیقی را ارائه می‌کند تا به مصرف‌کنندگان سرویس درباره نحوه مهاجرت از نسخه قدیمی به نسخه جدید بگوید. فراخوانی سرویس پویا مهم نیست که چگونه نسخه‌های مختلف API یا IOPE را با برچسب‌های معنایی نشانه‌گذاری می‌کنید، اگرچه ارائه‌دهنده سرویس یکسان خدمات مشابهی را در نسخه‌های مختلف ارائه می‌دهد. بین ارائه دهندگان مختلف، مانند ESRI در مقابل.geocoder.us، فراخوانی سرویس پویا امکان پذیر نیست، زیرا API ها و IOPE ها متفاوت هستند.

به طور خلاصه، فراخوانی پویا وب سرویس هیچ ارتباطی با معنایی سرویس های وب ندارد. فراخوانی سرویس توسط مشخصات نحوی تعیین می شود، نه تعریف معنایی . فراخوانی پویا سرویس وب در صورتی امکان پذیر است که مشخصات نحوی سرویس را بتوان استاندارد کرد [ 26 ]. تنها به این ترتیب، درخواست کننده می تواند هر یک از سرویس های کشف شده را بدون نیاز به برنامه ریزی مجدد ، هنگامی که API های استاندارد شده روی سرویس هایی با مشخصات معنایی یکسان اعمال می شود، فراخوانی کند.

دانشمندان GIS در دهه 1990 در مورد مسائل قابلیت همکاری بحث کرده بودند [ 27 ]. در سطح فنی ( نحوی)، قابلیت همکاری نسبتاً آسان است. در سطح معنایی، بسیار دشوارتر است. چالش برانگیزترین کار در سطح نهادی است اگر کسی مایل به مصالحه و توافق نباشد. اگر مشخصات نحوی و معنایی مربوط به قانون گذاری باشد، برای اجرا به اجرای قانون نیاز داریم. اگرچه جهان هرگز یکنواخت نخواهد شد، اما نوعی یکنواختی در دنیای سایبری وجود داشته است.

در یک انتشار اخیر [ 28]، خطاب شد که «از همان ابتدا، فناوری اینترنت/وب رویکردی از بالا به پایین اتخاذ کرده بود که ابتدا قوانین و پروتکل ها را تعریف می کرد. توسعه برنامه از طریق اینترنت/وب تحت کنترل دقیق پروتکل های مختلف اینترنتی بوده است. به عنوان مثال، می دانیم که انواع تصاویر مانند TIF، BMP، GIF، JPG و PNG در اینترنت پشتیبانی می شوند. در حالی که بسیاری از انواع تصاویر دیگر مانند IMG، GRID، MrSID، BIL، BIP، BSQ و برخی دیگر برای تصاویر ماهواره‌ای، عکس‌های هوایی و مدل‌های دیجیتال ارتفاع رایج هستند، نمی‌توان آنها را مستقیماً در اینترنت منتشر کرد. در اینجا، مرورگر وب در واقع یک ابزار سایبرنتیک یا مجری قانون است که پروتکل‌های HTTP/HTML را پیاده‌سازی می‌کند، یا در غیر این صورت، مرورگر وب نمی‌تواند محتوا را با فرمت مناسب رمزگشایی کند. فراخوانی سرویس پویا را می توان تحت شرایط خاصی تحقق بخشید که رابط نحوی استاندارد شده را بتوان در عمل اجرا کرد. در جامعه GIScience، انواع استانداردهای خدمات وب OGC (OWS) برای مدت طولانی به تصویب رسیده و با موفقیت پیاده سازی شده است، مانند خدمات نقشه برداری وب (WMS)، خدمات ویژگی های وب (WFS) و خدمات پوشش وب (WCS)، که ساختار نحوی را برای قالب بندی درخواست و پاسخ HTTP مشخص کرد.

4. رسمی کردن خدمات وب جغرافیایی برای ثبت خدمات پایدار

اگر معناشناسی وب سرویس ها در مورد مفاهیم خدمات و ارتباط بین سرویس ها باشد، رسمی کردن سرویس های وب جغرافیایی می تواند یک کار چالش برانگیز برای دانشمندان GIS باشد که ابتدا باید تمام مفاهیم ماژول های عملکردی را به عنوان خدمات در نرم افزار GIS شناسایی و بسازند. طبقه بندی برای سازماندهی مفاهیم محاسبات مکانی به ترتیب سلسله مراتبی. این مقاله چنین ابتکاری را با نمونه‌سازی چند نمونه برای کمک به درک پیچیدگی و چالش‌های ساخت هستی‌شناسی و طبقه‌بندی کامل محاسبات و خدمات جغرافیایی ترویج می‌کند. اگر هدف از مشخصات معنایی فعال کردن کشف سرویس باشد،

4.1. رسمی سازی خدمات وب جغرافیایی

طبقه بندی نمونه خدمات وب کدگذاری جغرافیایی که در شکل 1 توضیح داده شده استتنها یک بخش در دانش حوزه GIScience است، زیرا یک GIS ممکن است بیش از 600 عملکرد داشته باشد که از نظر تئوری می توان آنها را به خدمات تجزیه کرد. از آنجایی که ارائه دهندگان خدمات مختلف می توانند یک سرویس را به روش های مختلف توسعه دهند، همان سرویس دارای API یا IOPE های متفاوتی در سند توضیحات سرویس خود است. همانطور که ثابت شده است که معنای سرویس خنثی و مستقل از تعاریف API نحوی (IOPEs) است، هنگامی که توسعه دهندگان سرویس های مختلف خدمات خود را در یک رجیستری یا مخزن سرویس، مانند UDDI منتشر می کنند، کشف سرویس امکان پذیر نیست، زیرا ثبت خدمات سنتی فقط اجزای نحوی را در سرویس API یا IOPE دستکاری کنید. ناگزیر، کشف سرویس بر اساس آن عناصر بی معنی و گسسته API یا IOPE امکان پذیر نیست.

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

برای فعال کردن یک کشف معنادار و موفقیت‌آمیز وب سرویس‌های فضایی، رسمی کردن صدها سرویس وب مکانی یک پیش نیاز است. طبق تعریف آن، یک GIS سخت افزار، نرم افزار و داده ها را برای جمع آوری ، مدیریت ، تجزیه و تحلیل و نمایش همه اشکال اطلاعات جغرافیایی ارجاع داده شده یکپارچه می کند [ 29 ]. به همین دلیل، خدمات وب جغرافیایی را می توان به چهار زیرمجموعه سلسله مراتبی به عنوان خدمات مدیریت داده ، خدمات ایجاد داده ، خدمات تجزیه و تحلیل داده و خدمات تجسم داده رسمیت داد. شکل 2یک طبقه بندی نمونه از خدمات وب جغرافیایی را که مفاهیم جزئی محاسبات جغرافیایی را پوشش می دهد، توصیف می کند. طبقه بندی سرویس های وب کدگذاری جغرافیایی نشان داده شده در شکل 1 تنها یک گره تحت سرویس های ایجاد داده در شکل 2 است.

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

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

شکل 2. نمونه طبقه بندی خدمات وب جغرافیایی.

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

تجسم داده ها شامل مفاهیم تجسم فضایی از طریق نقشه های دو بعدی یا سه بعدی، تجسم غیرمکانی، مانند نمودارها و گرافیک های متنوع، و توضیحات آماری است. زیرمجموعه های مفاهیم برای تجسم ممکن است شامل هستی شناسی نمادشناسی، رنگ، فونت و سایر مفاهیم نقشه برداری باشد که در مشخص کردن ویژگی های IOPE برای خدمات تجسم استفاده می شود.

این طبقه بندی نمونه خدمات وب جغرافیایی، در اصل، قواعد کلی برشمرده شده در بخش 4 را تقویت می کند . با توجه به مثال سرویس Intersection ، تعاریف API نحوی یا IOPE ها می توانند برای عملیات بولی یا عملیات توپولوژیکی در محاسبات همپوشانی فضایی یکسان باشند، زیرا ورودی دو مجموعه داده چند ضلعی و خروجی یک مجموعه داده چند ضلعی است. با این حال، معنای این دو سرویس می تواند متفاوت باشد. هنگامی که عملگر Boolean استفاده می شود، سرویس Intersection هیچ ویژگی جدیدی ایجاد نمی کند، بلکه فقط ویژگی ها را از یکی انتخاب می کند.مجموعه داده ورودی (که در اصطلاحات حرفه ای GIS لایه پایه نامیده می شود) به عنوان ویژگی های خروجی. هنگامی که عملگر توپولوژیکی استفاده می شود، سرویس Intersection چند ضلعی های جدیدی ایجاد می کند که از دو مجموعه داده ورودی مشتق شده اند. به همین دلیل، مفهوم مشابه سرویس Intersection با APIهای سرویس یا IOPE یکسان را می توان در دو دسته مختلف از خدمات وب جغرافیایی طبقه بندی کرد. جدول 1 و جدول 2برخی از عملگرهای بولی و توپولوژیکی را در محاسبات همپوشانی چند ضلعی توصیف کنید. مفهوم “تقاطع” یا “تقاطع” می تواند معنای متفاوتی در عملیات بولی و توپولوژیکی داشته باشد. چنین تفاوتی ممکن است به راحتی توسط تعاریف نحوی IOPE توضیح داده نشود، اما می توان با طبقه بندی مفهومی شرح داده شده در شکل 2 ، آن را روشن کرد .

جدول 1. عملگرهای بولی برای محاسبه همپوشانی (ویژگی جدیدی ایجاد نشده است).

جدول 2. عملگرهای توپولوژیکی یا منطقی برای محاسبه همپوشانی (ویژگی(های) جدید ایجاد شده است). Symmetric Difference عملیات XOR (OR انحصاری) را پیاده سازی می کند.

با توجه به مثالی دیگر، درون یابی نوعی تجزیه و تحلیل فضایی است که یک سطح شطرنجی را با استفاده از مقادیر مشاهدات همسایه برای تخمین ارزش ویژگی ها در مکان های نمونه برداری نشده درون یابی می کند. وزن معکوس فاصله (IDW)، اسپلاین و کریجینگ سه الگوریتم متداول برای محاسبه درون یابی هستند. هنگامی که الگوریتم IDW برای محاسبه درون یابی استفاده می شود، تعاریف API نحوی یا IOPE ها شامل: مبدا (مختصات x,y) شبکه خروجی، اندازه سلول خروجی، تعداد سطرها و ستون ها، مجموعه داده ای از مشاهدات نمونه برداری شده و چگونگی بسیاری از نزدیکترین همسایگان در محاسبه استفاده می شوند. تعریف نحوی معنای چگونگی یافتن نزدیکترین همسایگان را آشکار نمی کند. اعمال فاصله اقلیدسی در مقابلفاصله دایره‌ای زیاد برای یافتن نزدیک‌ترین همسایه‌ها، نتایج متفاوتی را در درون‌یابی ایجاد می‌کند، به‌ویژه در اطراف ناحیه قطبی و مناطقی در طول 180 درجه طول جغرافیایی. این بدان معنی است که توضیحات API یا IOPE سرویس باید روشن کند که آیا از فاصله اقلیدسی یا فاصله دایره بزرگ برای یافتن نزدیکترین استفاده می شود.همسایگان، به طوری که کاربر می تواند از سرویس مناسب برای تکمیل کار بر اساس وسعت فضایی مجموعه داده استفاده کند. با این حال، چنین پارامتر یا گزینه ای در توضیحات API یا IOPE در مورد نحوه یافتن نزدیکترین همسایگان هیچ تاثیری بر نام یا مفهوم سرویس های “interpolation” ندارد. فرقی نمی‌کند که از فاصله اقلیدسی یا فاصله دایره بزرگ برای انجام محاسبات درون‌یابی استفاده شود، «درون یابی» نامیده می‌شود. به همین دلیل، تمایز مفاهیم مورد استفاده برای تعریف «خدمات» از مفاهیم مورد استفاده در تعاریف IOPE ضروری است. به دلیل پارامترهای مختلف در IO یا PE، نام یا مفهوم سرویس را تغییر نخواهیم داد، و بنابراین، معنای سرویس در واقع خنثی و مستقل از تعاریف API نحوی (IOPEs) است.

به طور کلی، همه آن مفاهیم در شکل 2 مربوط به معنایی خدمات وب جغرافیایی است، به این معنی که آنها در چارچوب مفهومی خدمات وب جغرافیایی قرار دارند. در این چارچوب مفهومی، رابطهبین هزاران مفهوم خدمات جغرافیایی تعریف و رسمی شده است. این چارچوب مفهومی هستی شناسی و معناشناسی صدها توابع و خدمات مکانی است که خنثی و مستقل از API ها یا IOPE ها هستند. مهم نیست که چه کسی هر یک از این خدمات وب جغرافیایی را در هر API با IOPE های متنوع توسعه می دهد، معنایی سرویس های وب جغرافیایی در چارچوب مفهومی یکسانی است. بدون درک معنایی یا معنای محاسبات مکانی، دستکاری تعاریف API نحوی یا IOPEهای یک سرویس وب برای استخراج معنایی سرویس‌های وب جغرافیایی عاجز است. در نتیجه کشف خدمات مناسب امکان پذیر نیست.

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

در اوایل دهه 1990، مشکلات قابلیت همکاری در جامعه GIS در سه سطح فنی، معنایی و نهادی مورد بررسی قرار گرفت [ 27 ]. قابلیت همکاری فنی می تواند ساده ترین راه برای دستیابی باشد، مانند WSDL، که نشان دهنده یک “توافق” بین طرف های مختلف است. تمایز یا مشکلات معنایی را می توان در یک حوزه دانش مشخص، مانند مفهوم خدمات کدگذاری جغرافیایی، شناسایی کرد. بزرگترین مشکل محدود کننده قابلیت همکاری معنایی در سطح نهادی است، زیرا عدم تمایل مؤسسات به رعایت استانداردهای مشترک یا بحث بین محققان می تواند مانع از اجماع بر رسمی شدن دانش حوزه محاسبات مکانی شود.

4.2. ثبت پایدار برای کشف سرویس معنایی و فراخوانی سرویس پویا

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

کلید ثبت خدمات پایدار و کشف خدمات موفق، ایجاد پایگاه دانش برای کنترل و تنظیم عملکرد سیستم ثبت، با پیروی از اصول علمی در علم سیستم، سایبرنتیک و روانشناسی شناختی است [ 28 ].]. اگر سیستم رجیستری به عنوان انبار خدمات در نظر گرفته می شود، ابتدا باید چنین انباری را قبل از قرار دادن اقلام ورودی در آن دسته بندی کرد تا بتوانیم اجزای لازم را به نحو احسن پیدا کنیم. UDDI و کارهای قبلی شکست خوردند، زیرا آنها هیچ برنامه مدیریتی عملی برای سازماندهی منابع نداشتند، چه رسد به یافتن خدمات معنادار. در مقابل، چنین سیستم باز به ارائه دهندگان خدمات اجازه می داد تا خدمات را به صورت آزاد و تصادفی در سیستم منتشر کنند، که منجر به هرج و مرج و شکست ناگزیر، همانطور که توسط علم سیستم ها و نظریه اطلاعات تفسیر می شود [ 28 ].

رویکرد موسوم به SAWSDL از توسعه دهندگان خدمات خواسته است تا قبل از اینکه سرویس را به انبار رجیستری رها کنند، IOPE سرویس خود را علامت گذاری کنند. متأسفانه، همانطور که ثابت شده است (1) همان ارائه دهنده خدمات می تواند از رابط های سرویس متفاوت تعریف شده در اسناد WSDL حتی در هنگام توسعه یک نوع سرویس استفاده کند، (2) ارائه دهندگان خدمات مختلف می توانند از رابط های سرویس مشابه تعریف شده در اسناد WSDL استفاده کنند. حتی زمانی که انواع مختلف سرویس‌ها را توسعه می‌دهند و (3) ارائه‌دهندگان خدمات مختلف می‌توانند رابط‌های سرویس متفاوتی را که در اسناد WSDL تعریف شده‌اند، هنگام توسعه یک نوع سرویس ایجاد کنند، رویکرد SAWSDL ممکن است فقط آشفتگی را تشدید کند، زیرا IOPE‌ها هیچ رابطه مستقیمی با معنایی ندارند. از خدمات

از آنجایی که معناشناسی خدمات با تعریف نحوی خدمات ارتباطی ندارد، کشف سرویس بر اساس تعریف معنایی و چارچوب دانش با کارهای قبلی متفاوت خواهد بود. یعنی یک ارائه دهنده خدمات در رجیستری ثبت نام می کند تا بر اساس تعریف معنایی این سرویس، نوعی سرویس ارائه دهد. در نتیجه، کشف خدمات مشخص می‌کند که کدام ارائه‌دهنده خدمات، نوع خاصی از خدمات را ارائه می‌دهند. در این مورد، ارائه دهندگان مختلف ممکن است یک سرویس را به روش های مختلف توسعه دهند، مانند استفاده از رویکرد SOAP یا REST، یا IOPE های همان سرویس می تواند متفاوت باشد. نتیجه کشف سرویس، فهرستی از ارائه دهندگان خدمات است که خدمات مربوطه را همراه با URL ها به عنوان محل سرویس ارائه می دهند. نحوه فراخوانی چنین خدماتی به تعریف نحوی IOPEها بستگی دارد که به معنایی خدمات و کشف سرویس مربوط نیست. با توجه به مثال خدمات Geocoding، سرویس اکتشاف باید بتواند چنین خدماتی را پیدا کند که توسط ESRI، geocoder.us، Yahoo! و Google، مهم نیست که آیا چنین خدماتی بر اساس رویکردهای SOAP یا REST هستند یا اینکه سرویس‌ها به‌عنوان findAddress، findLocationByAddress، GeoCoder، locator یا چیز دیگری در تعریف نحوی نام‌گذاری شده‌اند.

با این حال، اگر به یاد داشته باشیم که فراخوانی سرویس پویا آخرین و نهایی خدمات وب معنایی است که در بخش 5 مورد بحث قرار گرفت ، ما همچنین باید IOPE یا تعریف نحوی را برای خدمات وب استاندارد کنیم. به این ترتیب، بدون برنامه‌ریزی مجدد، یک سیستم نرم‌افزاری می‌تواند انعطاف‌پذیری برای استفاده از سرویس‌های مختلفی داشته باشد که کار یکسانی را انجام می‌دهند و APIهای یکسانی دارند، مهم نیست که از رویکردهای مبتنی بر SOAP یا REST استفاده می‌کند. بنابراین هدف نهایی یک ثبت خدمات پایدار بر اساس دو مجموعه از مشخصات اجرا می شود. مشخصات معنایی راهنمای ثبت و کشف خدمات خواهد بود. مشخصات نحوی تضمین می کند که فراخوانی پویا خدمات قابل اجرا خواهد بود.

5. گسترش اصول علمی تثبیت شده به دانش سایر حوزه ها

سه قانون کلی که در بخش 4 مورد بحث قرار گرفت ، اصول علمی را در ساختن هستی شناسی یا چارچوب مفهومی ایجاد کرده است تا امکان توسعه خدمات وب معنایی، نه تنها برای GIScience، بلکه برای هر دانش دامنه را فراهم کند. با توجه به مثال در حوزه علمی آمارماژول های محاسباتی در محصولات نرم افزاری معروف مانند R، MATLAB، SAS و SPSS می توانند به عنوان خدمات وب در معرض دید قرار گیرند. اگرچه تعاریف نحوی API یا IOPEهای یک وب سرویس آماری می تواند متفاوت باشد، معنایی سرویس باید یکسان باشد. برای مثال، سرویسی که انحراف استاندارد یک مجموعه داده را محاسبه می‌کند یا تحلیل رگرسیون را برای مدل‌سازی و تجزیه و تحلیل چندین متغیر پیاده‌سازی می‌کند، می‌تواند توسط ارائه‌دهندگان خدمات مختلف با APIهای مختلف توسعه یابد، اما هر نوع سرویس ( محاسبه انحراف استاندارد یا تجزیه و تحلیل رگرسیون ) دارای معنای خدمات مشابه در علم حوزه بیوانفورماتیک ، تعریف API نحوی یا IOPEs برای WebServiceBlast [ 30] بی معنی است. بدون ایجاد یک طبقه بندی در دانش حوزه بیوانفورماتیک، هیچ کس معنایی خدمات بیوانفورماتیک را با اجزای تعریف شده در API یا IOPE نمی داند.

در برنامه‌های دامنه‌ای که توسط سازمان‌های دولتی آغاز شده‌اند، مانند سرویس‌های وب توسعه‌یافته توسط US EPA [ 31 ]، NOAA [ 32 ]، وزارت کشاورزی ایالات متحده [ 33 ]، NASA [ 34 ] یا توسط صنعت، مانند TerraService [ 35 ] مایکروسافت، و کسانی که از ESRI [ 16 ، 17]، ممکن است تمام توصیفات نحوی چنین سرویس‌هایی در چارچوب معماری سرویس‌محور برای کشف سرویس معنادار یا معنایی نباشد. در واقع، چنین سازمان‌هایی وب‌سایت‌های خاصی را برای تفسیر جزئیات خدمات ایجاد کردند تا به کاربران یا مصرف‌کنندگان در درک معنای خدمات کمک کنند. چنین تلاش هایی ممکن است ثابت کرده باشد که کشف سرویس از طریق رویکردهای رجیستری یا نمایه نمی تواند به کاربران کمک کند تا خدمات مناسب را بر اساس تعریف نحوی و شرح چنین خدماتی بیابند و درک کنند، زیرا تعاریف نحوی API یا IOPE آنها هیچ ارتباطی با معنایی سرویس ندارند. و برای فعال کردن کشف سرویس معنادار نبودند. به عنوان مثال، خدمات وب پایگاه داده ملی پیش بینی دیجیتالی NOAA (NDFD) [ 32] دارای نه تابع، از جمله NDFDgen()، NDFDgenLatLonList()، LatLonListSubgrid()، LatLonListLine()، LatLonListZipCode()، LatLonListSquare()، CornerPoints()، NDFDgenByDay()BBonyFayL(NDFDgenByDay()BonyFayL(ND. مفاهیم چنین خدماتی روشن نیست و روابط بین این خدمات تعریف نشده است. در واقع، خدمات NDFD، و همچنین خدمات وب CropScape و VegScape NASS/USDA [ 33 ] با هدف انتشار داده ها توسعه داده شده اند. بنابراین، آنها را می توان تحت دسته خدمات داده قرار داد و سازماندهی کرد.

از آنجایی که برنامه‌ها یا خدمات منفرد فقط موارد استفاده خاص را هدف قرار می‌دهند، مفاهیم خدمات مستقل به سختی می‌توانند برای ایجاد یک طبقه‌بندی با یک چارچوب سلسله مراتبی برای روشن کردن روابط بین خدمات سازماندهی شوند. به همین دلیل، توسعه یک پایگاه دانش دامنه به خوبی سازماندهی شده برای رسمی کردن ماژول‌های محاسباتی خاص دامنه برای فعال کردن کشف سرویس موفق ضروری است. به عنوان مثال، TerraService مایکروسافت شانزده تابع را ارائه می دهد، از جمله ConvertLonLatPtToNearestPlace()، ConvertLonLatPtToUtmPt()، ConvertPlaceToLonLatPt()، ConvertUtmPtToLonLatPt()، CountPlacesInRreatrom)،(GetPlacesInRectrom)،(GetPlacesInRectrom)،(GetPlacesInRectrom)،(GetPlacesInRectrom)،(GetPlacesInRectrom)،(GetPlacesInRectrom) GetPlaceFacts()، GetPlaceListInRect()، GetTheme()، GetTile()، GetTileMetaFromLonLatPt() و GetTileMetaFromTileId(). بدیهی است که برخی از این توابع رابطه نزدیکی با دانش دامنه علم GIS دارند، مانند آن دسته از توابع تبدیل داده که می‌توانند تحت دسته‌های طرح مجدد (مثلاً بین سیستم مختصات Mercator عرضی جهانی و Lat/Long) و نوع قرار گیرند. تبدیل (بین داده‌های غیرمکانی و مکانی، مانند ConvertLonLatPtToNearestPlace() و ConvertPlaceToLonLatPt()) تحت زیر کلاس تبدیل درشکل 2 . این توابع GET نیز می تواند تلاشی برای انتشار داده ها باشد.

در مورد راهنمای اصلی تغییر جهانی ناسا (GCMD) [ 34 ]، مفاهیم مرتبط با داده ها و خدمات علوم زمین با کلمات کلیدی سلسله مراتبی طبقه بندی شده اند تا پایگاه دانش را ایجاد و سازماندهی کنند تا جستجوی جستجو را بر روی منابع GCMD اصلاح کنند. با این حال، زمانی که داده ها، وب سایت و برنامه های کاربردی وب، سرویس های مبتنی بر SOAP و REST همه با هم ترکیب می شوند، ممکن است مفهوم “سرویس” واضح نباشد. برای مثال، «کتابخانه جغرافیایی هاروارد» یا «سیستم اطلاعات آتش‌سوزی جنگل‌های اروپا (EFFIS)» را می‌توان در زیر دسته «خدمات/ابزارها» یافت. با این حال، همانطور که در این مقاله تعریف شده است، یک سرویس یک ماژول نرم افزاری است که می تواند توسط پروتکل های مبتنی بر SOAP یا REST قابل دسترسی باشد. به نظر می رسد ترکیبی از همه چیز برای یافتن خدمات مناسب مفید نباشد.

6. نتیجه گیری

در سال 2007، مایکل برودی نوشت: «چگونه سرویس‌ها خدمات مناسبی را که الزامات خاص را در چنین محیطی برآورده می‌کنند، کشف می‌کنند؟ ما در حال حاضر با این مقیاس فاصله داریم.» [ 4 ]. اگر هنوز با کشف سرویس های مناسب فاصله داریم، جای تعجب نیست، زیرا حتی درک درستی از معنایی سرویس های وب وجود نداشت، در حالی که بیشتر سرویس های موجود در هیچ علم حوزه ای سازماندهی نشده بودند. کشف سرویس باید بر اساس معنایی سرویس های وب باشد که هیچ ارتباطی با API یا IOPE ندارند. در نتیجه، دستکاری API ها یا IOPE ها برای استخراج معنایی سرویس های وب و یافتن هر سرویس مناسب بی فایده است.

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

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

سه اصل تثبیت شده در مورد معنایی خدمات وب، معماری وب سرویس یا SOA و برنامه های کاربردی وب سرویس را به طور کلی به یک پارادایم جدید تبدیل می کند. رجیستری خدمات باید بر اساس هستی شناسی و چارچوب معنایی یک علم دامنه بازسازی شود. چنین هستی شناسی مفاهیم خدمات و روابط بین خدمات را پوشش می دهد. انتشار سرویس هیچ ارتباطی با اجزای نحوی API یا IOPE ندارد، بلکه بر اساس طبقه بندی معنایی سرویس خواهد بود. به این معنا که ارائه دهندگان خدمات ابتدا یک سرویس تعریف شده از نظر معنایی را در رجیستری پیدا می کنند و سپس خدمات خود را با URL منحصر به فرد آن ثبت می کنند. کشف سرویس بر اساس چارچوب هستی شناسی می تواند موفقیت آمیز باشد. وقتی بتوان یک سرویس را کشف کرد، رجیستری مجموعه ای از ارائه دهندگان خدماتی را که چنین خدماتی را ارائه می دهند شناسایی می کند. از آنجایی که سرویس‌ها تحت یک تعریف معنایی می‌توانند توسط ارائه‌دهندگان مختلف با اجزای نحوی مختلف تعریف شده در API یا IOPE توسعه یابند، فراخوانی سرویس پویا تنها زمانی قابل تحقق است که مشخصات نحوی استاندارد شود.

علاوه بر اهمیت آن در محاسبات سرویس گرا، تحقیق در مورد معنایی ماژول های محاسباتی در ساخت GIS در مهندسی نرم افزار و آموزش GIS نیز قابل توجه است. بدون چنین تحقیقات و تئوری تثبیت شده، بسیاری از محصولات نرم افزار GIS تنها انبوهی از ماژول ها و ابزارهای کاربردی هستند، زیرا معماری و ساختار نرم افزار نمی تواند دانش دامنه GIS را ارائه دهد. به ناچار، ماژول های تکراری و مفاهیم مبهم در محصولات نرم افزار GIS قابل شناسایی هستند. این مشکلی را برای آموزش GIS ایجاد می‌کند، زیرا ممکن است دانش‌آموزان با آن ماژول‌های تکراری که در مکان‌های مختلف نرم‌افزار قرار دارند گیج شوند، زیرا این ماژول‌ها دقیقاً عملکردهای مشابهی را انجام می‌دهند، در حالی که در شرایط دیگر، ماژول‌های عملکردی مشابه یا یکسان ممکن است از متفاوت استفاده کنند. نام ها اساسا، وب سرویس ها ماژول های محاسباتی محصولات نرم افزاری هستند. به همین دلیل، چارچوب مفهومی ساخته شده برای خدمات مکانی معنایی می‌تواند زیرساختی مشترک برای مهندسی نرم‌افزار GIS به منظور توسعه یک سیستم معنادارتر برای بهبود فرآیند یادگیری باشد. از آنجایی که هستی‌شناسی رسمی‌سازی مفهوم‌سازی مشترک دانش حوزه است، انتظار می‌رود که چارچوب مفهومی برای محاسبات مکانی در نهایت توسط جامعه GIScience توسعه و بهینه‌سازی شود. به طور کلی، رسمی‌سازی معنایی سرویس‌های وب می‌تواند شامل یک رابطه «is-a»، طبقه‌بندی کلاس‌ها و ویژگی‌ها، روابط کلاس-نمونه و غیره باشد. این مقاله تنها دو نوع رابطه را در رسمیت بخشیدن به مفاهیم وب سرویس های جغرافیایی مورد بحث قرار می دهد. با این حال،

منابع

سرویس. در دسترس آنلاین: http://www.thefreedictionary.com/Service (در 13 سپتامبر 2013 قابل دسترسی است).
سرویس. در دسترس آنلاین: http://www.merriam-webster.com/dictionary/service (در 13 سپتامبر 2013 قابل دسترسی است).
سرویس. در دسترس آنلاین: http://www.ldoceonline.com/dictionary/service_1 (در 13 سپتامبر 2013 قابل دسترسی است).
برودی، ام. فن آوری های معنایی: تحقق چشم انداز خدمات. IEEE Intell. سیستم 2007 ، 22 ، 13-15. [ Google Scholar ] [ CrossRef ]
فاستر، I. علم خدمات محور. علوم 2005 ، 308 ، 814-817. [ Google Scholar ] [ CrossRef ]
W3C. معماری خدمات وب 2004. در دسترس آنلاین: http://www.w3.org/TR/ws-arch/ (دسترسی در 13 سپتامبر 2013).
المصری، ا. محمود، QH کشف خدمات وب در موتور جستجو. محاسبات اینترنتی IEEE. 2008 ، 12 ، 74-77. [ Google Scholar ] [ CrossRef ]
کشف و ادغام توضیحات جهانی. در دسترس آنلاین: http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration (در 13 سپتامبر 2013 قابل دسترسی است).
فیلدینگ، سبک های معماری RT و طراحی معماری های نرم افزاری مبتنی بر شبکه. Ph.D. پایان نامه، دانشگاه کالیفرنیا، ایروین، کالیفرنیا، ایالات متحده آمریکا، 2000. [ Google Scholar ]
سینگ، نماینده مجلس؛ هانز، MN فصل 1 محاسبات با خدمات. در محاسبات خدمات گرا – معناشناسی، فرآیندها، عوامل ؛ John Wiley & Sons, Ltd.: West Sussex, UK, 2005; صص 11-12. [ Google Scholar ]
تو، اس. عبدالگرفی، م. خدمات وب برای سیستم های اطلاعات جغرافیایی. محاسبات اینترنتی IEEE. 2006 ، 10 ، 13-15. [ Google Scholar ]
Petrie, C. خدمات وب عملی. IEEE Int. محاسبه کنید. 2009 ، 13 ، 93-96. [ Google Scholar ] [ CrossRef ]
W3C. واژه نامه خدمات وب 2004. در دسترس آنلاین: http://www.w3.org/TR/ws-gloss/ (در 13 سپتامبر 2013 قابل دسترسی است).
لارا، آر. رومن، دی. پولرس، آ. Fensel, D. مقایسه مفهومی WSMO و OWL-S. لکت. توجه داشته باشید. محاسبه کنید. علمی 2004 ، 3250 ، 254-269. [ Google Scholar ] [ CrossRef ]
کابرال، ال. دومینگو، جی. موتا، ای. پین، تی. حکیم پور، ف. رویکردی به خدمات وب معنایی: مروری و مقایسه‌ها. لکت. توجه داشته باشید. محاسبه کنید. علمی 2004 ، 3053 ، 225-239. [ Google Scholar ] [ CrossRef ]
ESRI. ArcWebServices نسخه 2. موجود به صورت آنلاین: http://arcweb.esri.com/services/v2/AddressFinder.wsdl (در 13 سپتامبر 2013 قابل دسترسی است).
ESRI. ArcWebServices نسخه 2006. در دسترس آنلاین: http://www.arcwebservices.com/services/v2006_1/AddressFinder?wsdl (در 13 سپتامبر 2013 قابل دسترسی است).
Geocoder.us. در دسترس آنلاین: http://geocoder.us/dist/eg/clients/GeoCoder.wsdl (در 13 سپتامبر 2013 قابل دسترسی است).
توت سیاه. در دسترس آنلاین: http://us.blackberry.com/developers/platform/locateservice/ (در 13 سپتامبر 2013 قابل دسترسی است).
W3C. OWL-S: نشانه گذاری معنایی برای خدمات وب. 2004. در دسترس آنلاین: http://www.w3.org/Submission/OWL-S/ (در 13 سپتامبر 2013 قابل دسترسی است).
W3C. هستی شناسی مدل سازی وب سرویس (WSMO). 2005. در دسترس آنلاین: http://www.w3.org/Submission/WSMO/ (در 13 سپتامبر 2013 قابل دسترسی است).
W3C. حاشیه نویسی معنایی برای WSDL. 2006. در دسترس آنلاین: http://www.w3.org/2002/ws/sawsdl/spec/SAWSDL.html (در 13 سپتامبر 2013 قابل دسترسی است).
ورما، وی. Sheth، A. حاشیه نویسی معنایی یک وب سرویس. محاسبات اینترنتی IEEE. 2007 ، 11 ، 83-85. [ Google Scholar ] [ CrossRef ]
Shi, X. خدمات وب معنایی: یک وعده محقق نشده. پروفسور فناوری اطلاعات 2007 ، 9 ، 42-45. [ Google Scholar ] [ CrossRef ]
Burstein، MH فراخوانی پویا از خدمات وب معنایی که از هستی شناسی های ناآشنا استفاده می کنند. IEEE Intell. سیستم 2004 ، 19 ، 67-73. [ Google Scholar ] [ CrossRef ]
Shi, X. درخواست و پاسخ معنایی برای خدمات وب استاندارد. در دسترس آنلاین: http://www.ibm.com/developerworks/library/ws-semantic/ (در 13 سپتامبر 2013 قابل دسترسی است).
Goodchild، MF; Egenhofer، MJ; Fegeas, R. GISهای تعاملی. در دسترس آنلاین: http://www.ncgia.ucsb.edu/conf/interop97/report.html (در 16 سپتامبر 2013 قابل دسترسی است).
شی، ایکس. Nellis، MD محاسبات وب معنایی و خدمات در برنامه های GIScience: یک چشم انداز و آینده نگر. Geocarto Int. 2013 ، در دست چاپ. [ Google Scholar ]
ESRI، درک GIS: روش ARC/INFO . موسسه تحقیقات سیستم محیطی: ردلندز، کالیفرنیا، ایالات متحده آمریکا، 1990.
آلتونای، م. کلونز، دی. Warade, C. Web Services for Bioinformatics, Part 1. در دسترس آنلاین: http://www.ibm.com/developerworks/webservices/library/ws-bioinfo/index.html (در 13 سپتامبر 2013 قابل دسترسی است).
خدمات وب EPA STORET/WQX. در دسترس آنلاین: http://www.epa.gov/storet/web_services.html (در 13 سپتامبر 2013 قابل دسترسی است).
سرویس وب پروتکل دسترسی ساده به اشیاء (SOAP) پایگاه داده پیش بینی دیجیتال ملی NOAA (NDFD). در دسترس آنلاین: http://graphical.weather.gov/xml/ (در 13 سپتامبر 2013 قابل دسترسی است).
خدمات ملی آمار کشاورزی USDA. در دسترس آنلاین: http://www.nass.usda.gov/ (در 13 سپتامبر 2013 قابل دسترسی است).
فهرست اصلی تغییر جهانی ناسا. در دسترس آنلاین: http://gcmd.nasa.gov/ (در 13 سپتامبر 2013 قابل دسترسی است).
TerraService مایکروسافت. در دسترس آنلاین: http://terraserver-usa.com/TerraService2.asmx (در 13 سپتامبر 2013 قابل دسترسی است).

© 2013 توسط نویسندگان; دارنده مجوز MDPI، بازل، سوئیس. این مقاله یک مقاله با دسترسی آزاد است که تحت شرایط و ضوابط مجوز Creative Commons Attribution (http://creativecommons.org/licenses/by/3.0/) توزیع شده است.

;کاربردهای GIS مقالات

درخواست مشاوره

09120049370

8 صبح تا 12 شب