زبان اختصاصی دامنه برای معاملات سیستم مدیریت زمین

چکیده

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

کلید واژه ها:

اداره زمین ؛ معاملات اداره زمین ; زبان دامنه خاص

۱٫ مقدمه

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

ثبت اسناد رسمی ثبت رسمی حقوق مربوط به زمین یا اسناد مربوط به تغییرات در وضعیت حقوقی واحدهای تعیین شده زمین است. این به این سؤالات پاسخ می دهد که چه کسی مالک ملک خاص است و آن مالکیت بر چه سند قانونی استوار است [ ۱ ].

کاداستر فهرستی عمومی از داده های مربوط به املاک در یک شهرستان یا منطقه خاص را نشان می دهد. داده ها در کاداستر بر اساس بررسی مرزها هستند. این نشان دهنده ثبتی از داده های مکانی است که برای توصیف خواص استفاده می شود و به سؤالات مربوط به مکان یک ویژگی خاص پاسخ می دهد [ ۱ ]. داده‌هایی که ممکن است در کاداستر ظاهر شوند شامل داده‌های هندسی (مختصات، نقشه‌ها) [ ۲ ، ۳ ، ۴ ]، آدرس‌های دارایی [ ۵ ، ۶ ]، کاربری زمین [ ۷ ، ۸ ]، اطلاعات ملکی، ماهیت و مدت تصدی است. , جزئیات در مورد ساخت و ساز ساختمان ها و آپارتمان ها [ ۹ , ۱۰ ,۱۱ ، ۱۲ ] و ارزش مالیات بر زمین [ ۱۳ ، ۱۴ ]. علاوه بر این، مدل‌های داده‌های کاداستر به جمع‌آوری و ارائه اطلاعات مرتبط برای مدیریت بلایا [ ۱۵ ]، توسعه پایدار [ ۱۶ ]، امنیت غذایی [ ۱۷ ، ۱۸ ]، مدیریت پس از جنگ [ ۱۹ ] و برنامه‌ریزی فضایی [ ۲۰ ] کمک می‌کنند.

در “کاداستر ۲۰۱۴” [ ۲۱ ] چشم اندازی برای یک سیستم کاداستر “بدون کاغذ و مداد” ارائه شده است. در نتیجه این تحقیق، یک ابتکار بین المللی برای توسعه مدل داده مشترک آغاز شد. نتیجه ایجاد ISO 19152:2012 اطلاعات جغرافیایی — مدل دامنه مدیریت زمین (LADM) بود. LADM یک مدل داده مفهومی است که به طور گسترده به عنوان استاندارد توصیفی برای اداره زمین پذیرفته شده است [ ۲۲]. بسیاری از پروفایل های کشور و تحلیل های کاربردی LADM تا به امروز منتشر شده اند. پس از «کاداستر ۲۰۱۴»، تمرکز دانشگاه بر روی «کاداستر ۲۰۳۴» و آنچه می‌توانیم از LAS در سال‌های آینده انتظار داشته باشیم، است. پژوهش در دو جهت متمرکز است. اولین جهت مبتنی بر دستاوردهای فناوری جدید است که می تواند دقت نظرسنجی، طراحی شی گرا، ترتیبات ۳D/4D، اطلاعات بلادرنگ، پیوندهای جهانی و ویژگی های ارگانیک را به عنوان ویژگی های اصلی کاداسترهای آینده به ارمغان بیاورد [ ۲۳ ]. جهت دوم مربوط به اولویت بندی برنامه های مهم اجتماعی، قانونی و زیست محیطی مانند تامین حقوق اساسی، تامین عدالت، انصاف، شفافیت، پاسخگویی و حاکمیت قانون و تمرکززدایی دولت است [ ۲۴ ].

یکی از وظایف LAS این است که داده ها را با تغییرات در دنیای واقعی مربوط به حوزه مدیریت زمین به روز نگه دارد. این تغییرات شامل تغییر مالکیت (خرید/فروش، ارث)، ایجاد حقوق (مانند رهن)، و تقسیم یا ادغام قطعات [ ۲۵ ] می شود.]. مدیریت داده های LAS با اجرای تراکنش هایی انجام می شود که ثبت زمین و داده های کاداستر را به روز می کند. در عصر دیجیتال، LAS داده‌های قانونی را مدیریت می‌کند که مالکان، املاک و مستغلات، حقوق و محدودیت‌های مالکیت را توصیف می‌کند، مانند نام مالک، مساحت بسته یا سهم مالکیت. از سوی دیگر، LAS همچنین باید داده های نظرسنجی را که شکل و موقعیت املاک و مستغلات را با گرافیک برداری با استفاده از یک سیستم مرجع مختصات مناسب توصیف می کند، مدیریت کند. برخی از LASها ممکن است حاوی داده‌های موضوعی اضافی باشند که استفاده از زمین یا داده‌های مشابهی را که هدف ویژگی‌های فضایی در زمین را توصیف می‌کنند، توصیف می‌کنند [ ۲۶ ].

تفاوت هایی بین LAS ها در کشورهای مختلف وجود دارد. سیستم های ثبت اراضی ممکن است بر اساس سند یا عنوان باشد. LAS ممکن است به عنوان یک سیستم دوگانه، با یک کتاب زمین جداگانه (دارندگان عنوان املاک و مستغلات) و کاداستر زمین (اموال غیرمنقول) یا به عنوان یک سیستم یکپارچه با یک ثبت (در برخی کشورها به آن کاداستر املاک و مستغلات گفته می شود) پیاده سازی شود. در هر دو مورد، مشکل یکپارچگی ثبت اسناد و املاک و داده‌های کاداستر به دلیل این واقعیت که این دو زیرسیستم به طور ضعیفی با هم مرتبط هستند، یک موضوع مهم باقی می‌ماند. علاوه بر این، هر دو زیرسیستم قوانین تجاری و معاملات خود را دارند [ ۲۷ ].

پس از ایجاد حالت اولیه LAS با جمع آوری و ترتیب داده های دنیای واقعی، فعالیت اصلی در مدیریت LAS به روز نگه داشتن آن داده ها با اجرای تراکنش هایی است که منعکس کننده تغییرات دنیای واقعی هستند، مانند تغییرات حقوق مالکیت، ثبت ساختمان جدید، به روز رسانی آدرس مالک و غیره. این تراکنش‌ها باید صحت و یکنواختی داده‌ها را حفظ کنند، که ممکن است به خصوص اگر یک تراکنش در هر دو بخش ثبت زمین و کاداستر باشد، نقض شود. تجزیه و تحلیل ارائه شده در [ ۲۸ ] نمونه ای از ناسازگاری قابل توجه بین داده های ثبت زمین و کاداستر را نشان می دهد.

ISO 19157:2013 اطلاعات جغرافیایی – کیفیت داده شش عنصر کیفیت داده را تعریف می کند: کامل بودن، دقت موضوعی، ثبات منطقی، کیفیت زمانی، دقت موقعیتی و قابلیت استفاده [ ۲۹ ]. کیفیت داده ها باید بر اساس ابرداده های ذخیره شده همراه با داده های قانونی و نظرسنجی در LAS ارزیابی شود. ISO 19115-1:2014 اطلاعات جغرافیایی — فراداده — بخش ۱: مبانی و ISO 19115-2:2019 اطلاعات جغرافیایی — فراداده — قسمت ۲: برنامه های افزودنی برای کسب و پردازش، طرح مورد نیاز برای توصیف اطلاعات و خدمات جغرافیایی را با استفاده از فراداده تعریف می کند [ ۳۰ ] ، ۳۱ ]. کیفیت داده و همچنین معناشناسی و اصطلاحات هنوز چالش اصلی در LAS های معاصر است.

امروزه، در عصر سیستم های کامپیوتری قدرتمند، LAS به طور موثر داده ها را در قالب دیجیتال ذخیره، به روز رسانی و مدیریت می کند. به‌روزرسانی داده‌های LAS معمولاً توسط کارکنان LAS از طریق برنامه‌های رابط کاربری گرافیکی (GUI) انجام می‌شود. این برنامه ها با استفاده از زبان های همه منظوره مختلف (GPL) توسعه یافته اند. استفاده از برنامه‌های رابط کاربری گرافیکی به مهارت‌های اولیه استفاده از رایانه نیاز دارد اما دانش برنامه‌نویسی ندارد.

زبان‌های اختصاصی دامنه (DSL) زبان‌هایی هستند که همانطور که از نام آن پیداست، بر خلاف GPL در یک دامنه خاص استفاده می‌شوند. GPL ها را می توان برای ساخت نرم افزارهای کامپیوتری عمومی استفاده کرد و معمولاً امکانات و انعطاف پذیری زیادی دارند، در حالی که DSL ها معمولاً برای استفاده و نوشتن دستورات آسان هستند، بنابراین کاربران باید دانش دامنه مناسب و مهارت های برنامه نویسی اولیه داشته باشند. سپس عبارات DSL به برخی از عبارات GPL ترجمه یا تفسیر می شوند.

تعریف و استفاده از DSL ها نوعی توسعه نرم افزار مدل محور است. اولین گام در توسعه، ایجاد نمایش‌های رسمی و قابل پردازش ابزاری از جنبه‌های خاص سیستم‌های نرم‌افزاری است. این نمایش‌ها (عبارات DSL) می‌توانند مستقیماً توسط مفسران تفسیر شوند یا توسط تولیدکنندگان کد به عبارات GPL تبدیل شوند [ ۳۲ ].

انگیزه این تحقیق توسعه یک DSL برای حوزه مدیریت زمین بود تا کاربر بتواند بیانیه ای بنویسد که به عنوان یک تراکنش در LAS اجرا شود. این تحقیق بر اساس استفاده از معاملات مدیریت زمین در صربستان است. LAS صربستان، و همچنین LASهای دیگر کشورهای بالکان غربی، بر اساس ثبت زمین و کاداستر اتریش-مجارستان است. مزایای پیاده سازی DSL متعددی وجود دارد. عبارات DSL را می توان برای اجرای عملیات های پیچیده مختلف استفاده کرد که اجرای آنها با استفاده از برنامه های GUI استاندارد دشوار است. ارائه و گزارش بیانیه های DSL می تواند در همان قالبی که نوشته شده اند انجام شود. عبارات DSL را می توان توسط یک محیط توسعه یکپارچه مناسب تأیید و تأیید کرد، بنابراین کارایی کاربر نهایی بهبود می یابد. این عبارات برای کاربری که دانش یا مهارت برنامه نویسی ندارد قابل درک است. عبارات DSL را می توان به زبان های چند هدف ترجمه کرد [۳۳ ]. این مقاله DSL را برای تراکنش‌های LAS پیشنهاد می‌کند که کارمندان اداره زمین را قادر می‌سازد تا بیانیه‌هایی بنویسند که برای به روز نگه داشتن داده‌های LAS با تغییرات دنیای واقعی اجرا می‌شوند.

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

این مقاله به شرح زیر سازماندهی شده است: بخش ۲ برخی از زمینه های نظری زمینه های LAS و DSL را ارائه می دهد. انواع مختلفی از معاملات LAS در بخش ۳ مورد بحث قرار گرفته است. در بخش ۴ ، معماری سیستم برای DSL برای تراکنش های LAS مورد بحث قرار می گیرد. راه حل پیشنهادی با مثال هایی از بیانیه های تراکنش LAS در بخش ۵ ارائه شده است. بحث و دستورالعمل های کار آینده در بخش ۶ آورده شده است.

۲٫ کارهای مرتبط

در سال ۲۰۱۲، سازمان استاندارد بین المللی (ISO) ISO-19152: 2012 اطلاعات جغرافیایی — مدل دامنه مدیریت اراضی (LADM) را منتشر کرد، که یک مدل دامنه مرجع را برای پوشش دادن مؤلفه های مرتبط با اطلاعات اولیه مدیریت زمین تعریف می کند [ ۲۲ ]. LADM راه حل جهانی مناسب برای هر LAS خاصی ارائه نمی دهد. در عوض، به عنوان مرجعی برای ایجاد مدل های دامنه مناسب برای یک نمایه کشور خاص توصیه می شود. در حوزه اطلاعات جغرافیایی، نمایه عبارت است از «مجموعه‌ای از یک یا چند استاندارد پایه یا زیرمجموعه استانداردهای پایه، و در صورت لزوم، شناسایی بندهای انتخاب شده، کلاس‌ها، گزینه‌ها و پارامترهای آن استانداردهای پایه که برای آن ضروری است. انجام یک عملکرد خاص» [ ۳۴]. در نتیجه، بسیاری از پروفایل های کشوری بر اساس LADM منتشر شده اند، مانند [ ۳۵ ، ۳۶ ، ۳۷ ، ۳۸ ]. طبق [ ۳۹ ] LADM عمدتاً کانون دانشگاه است. موضوعات اصلی تحقیق ایجاد پروفایل های کشور LADM جدید و نحوه مطابقت سیستم های فعلی با LADM است. در برخی موارد، LADM برای افزودن لایه‌های اضافی از داده‌ها، مانند کاربری زمین [ ۲۶ ]، و همچنین برای مشخص کردن محدودیت‌های اضافی که در LAS وجود دارد، گسترش می‌یابد، به‌ویژه در مورد سازگاری داخلی داده‌ها بین ثبت زمین و کاداستر [ ۲۷ ].]. تراکنش‌های مربوط به LAS خارج از محدوده LADM هستند، زیرا تراکنش‌ها به طور قابل توجهی مختص کشور هستند. اصطلاح «معامله» در اینجا برای توصیف دگرگونی حالت استفاده می‌شود که دارای ویژگی‌های اتمی، قوام، انزوا و دوام است. در سال ۲۰۱۸، یک پیشنهاد کاری جدید برای ویرایش دوم LADM پیشنهاد شد که شامل چندین افزونه، از جمله تراکنش‌ها و استفاده از فناوری‌های بلاک چین بود [ ۳۶ ، ۴۰ ].

به طور کلی، معاملات در LAS نه تنها می تواند شامل تغییر مالکیت املاک، ایجاد حقوق مربوط به املاک مانند رهن یا توسعه و حق ارتفاق، و ادغام و تقسیم املاک باشد، بلکه می تواند با بهبود وضعیت املاک نیز مرتبط باشد. کیفیت داده های ذخیره شده در LAS [ ۲۵ ]. همانطور که گفته شد، این رویه ها از کشوری به کشور دیگر بسیار متفاوت است و بازیگران مختلفی در آن دخیل هستند. به عنوان مثال در مورد ترکیه، اداره کل ثبت زمین و کاداستر ۲۵ تراکنش مختلف کاداستر و ثبت اراضی را انجام می دهد که به اسناد مختلف از موسسات خارجی مختلف نیاز دارد [ ۴۱ ].]. در مورد اسلوونی، انتقال معمول زمین کشاورزی شامل حداقل پنج بازیگر است: فروشنده، خریدار، دفتر اسناد رسمی، دفتر اداری، و LAS و شامل اجرای حداقل ۱۲ مرحله / فعالیت بین بازیگران [ ۴۲ ]. فرآیند معاملات املاک و مستغلات در سوئد نیز شامل چندین بازیگر می شود: فروشنده، خریدار، عوامل املاک، دفتر اداره زمین، فروشنده و بانک های خریدار و شامل ۳۴ مرحله است [ ۴۳ ]. حتی با ذکر چند مثال، واضح است که ثبت معاملات املاک و مستغلات می‌تواند فرآیند نسبتاً پیچیده‌ای باشد و می‌تواند از کشوری به کشور دیگر یا به عبارت دقیق‌تر، از یک حوزه قانونی به حوزه قضایی دیگر متفاوت باشد.

مشخصات فنی ISO (ISO/TS) 19103:2015 (ISO 19103: اطلاعات جغرافیایی – زبان طرح مفهومی، ۲۰۱۵) زبان مدلسازی یکپارچه (UML) را به عنوان یک زبان طرحواره مفهومی برای مشخصات اطلاعات جغرافیایی تعریف می کند [ ۴۴ ]]. بنابراین، در بیشتر موارد، UML برای توصیف فرآیند جاری معاملات املاک، معمولاً از طریق نمودارهای کلاس، موارد استفاده و نمودارهای توالی استفاده می شود. بر اساس آن نمودارهای UML، LAS معاصر معمولاً به عنوان برنامه های کاربردی مبتنی بر رابط کاربری گرافیکی با اجزای اختصاصی برای پشتیبانی از دستکاری داده های مکانی توسعه می یابد. این در برخی از GPLهای ایجاد شده برای توسعه راه حل های نرم افزاری برای دامنه های مختلف انجام می شود. UML و GPL ابزارهای اصلی برای ایجاد راه حل های نرم افزاری هستند که توسط متخصصان فناوری اطلاعات استفاده می شود. اگرچه فرآیندهای معاملات مدیریت زمین در حوزه های قضایی خاص متفاوت است، بازیگران و فعالیت های درگیر در این فرآیندها مشابه هستند و می توانند ایجاد یک DSL برای معاملات LAS را توجیه کنند.

یک DSL نشان دهنده زبان برنامه نویسی یا مشخصاتی است که برای حل مشکلات در یک دامنه خاص ایجاد شده است. DSL ها نمادها و ساختارهایی را برای کاربرد در یک دامنه خاص ارائه می دهند، و به این ترتیب، DSL ها گویاتر و آسان تر از GPL هستند. علاوه بر این، در مقایسه با GPL، DSL دامنه های برنامه را به روی گروه بزرگتری از توسعه دهندگان نرم افزار [ ۴۵ ] و همچنین کارشناسان حوزه باز می کند. با استفاده از DSL، متخصصان دامنه می توانند بیشتر در ایجاد راه حل برای یک مشکل مشارکت داشته باشند، زیرا آنها می توانند به راحتی کد را درک و اعتبار سنجی کنند و بفهمند که یک تغییر خاص چه تاثیری خواهد داشت [ ۴۶ ].]. برای رفتن یک گام فراتر، بر خلاف GPL، DSL برای کاربر نهایی در نظر گرفته شده است که نیازی به توسعه نرم افزار ندارد. بنابراین، کاربر می تواند وظایف برنامه نویسی ساده را با استفاده از برخی زبان های ماکرو یا برنامه نویسی انجام دهد [ ۴۷ ].

برخی از مزایای اصلی DSL عبارتند از:

DSL امکان بیان تراکنش ها را در سطح انتزاع دامنه مشکل فراهم می کند و به نوعی این امکان را برای متخصصان دامنه می دهد تا برنامه های DSL را درک، اعتبار سنجی، اصلاح و در برخی موارد توسعه دهند.
DSL به دلایلی که در بیانیه قبلی ذکر شد تا حد زیادی مستند است.
DSL می تواند بهره وری، قابلیت نگهداری، قابلیت اطمینان و قابلیت حمل را بهبود بخشد.
DSL دانشی را در مورد یک دامنه خاص از برنامه ترکیب می کند، به این ترتیب آن را حفظ می کند و برای استفاده در آینده در دسترس قرار می دهد.
DSL انجام اعتبار سنجی و بهینه سازی در سطح دامنه را ممکن می سازد [ ۴۷ ].

یک DSL را می توان با سه بعد طبقه بندی کرد: ظاهر، مبدا و پیاده سازی [ ۴۵ ]. Appearance DSL را به صورت متنی، گرافیکی، جدولی یا نمادین طبقه بندی می کند. با توجه به مبدأ، یک DSL می‌تواند داخلی باشد، از GPL یا DSL موجود، یا خارجی و با تکیه بر زیرساخت‌های خودش توسعه یابد. با توجه به پیاده سازی، DSL ها به عنوان اجراهای شناخته شده طبقه بندی می شوند، DSL هایی که به عنوان ورودی برای مولدهای برنامه عمل می کنند. DSLهای غیر قابل اجرا، که با این وجود، به عنوان ورودی برای تولیدکنندگان برنامه مفید هستند. و DSLهایی که برای اجرا طراحی نشده اند [ ۴۶ ].

با بهترین دانش نویسندگان، به غیر از چندین مقاله مرتبط با فرآیندهای مدلسازی در مناظر [ ۴۸ ، ۴۹ ، ۵۰ ] و کاربری زمین [ ۵۱ ، ۵۲ ] که ارتباط نزدیکی با تحقیقات ارائه شده در این مقاله ندارند، هیچ تحقیقی انجام نداده است. برای توسعه DSL در زمینه LAS یا به طور خاص تر، برای مدیریت تراکنش های LAS انجام شده است. با پیشنهاد DSL برای تراکنش های LAS، سطح جدیدی از انتزاع، اعتبار سنجی بیانیه و امکان تفسیر پلتفرم های مختلف معرفی می شود. متخصصان دامنه می توانند تراکنش های LAS را با نوشتن بیانیه های DSL راحت تر انجام دهند.

۳٫ معاملات سیستم مدیریت زمین

تمام داده های LAS ممکن است به دو مجموعه داده اصلی تقسیم شوند: حقوقی و نظرسنجی. ماهیت متفاوت این مجموعه داده ها، اجرای تراکنش در LAS یکپارچه را کمی چالش برانگیز می کند. یکی از وظایف مهم LAS این است که داده های حقوقی و نظرسنجی را در یک وضعیت ثابت و صحیح نگه دارد. برخی از داده های LAS، مانند یک منطقه بسته برای مثال، در هر دو مجموعه داده ثبت می شوند. به عنوان یک مقدار عددی در مجموعه داده قانونی ثبت می شود و همچنین می تواند از مختصات رأس چند ضلعی از مجموعه داده بررسی محاسبه شود. این افزونگی از LAS های قدیمی که از نقشه های کاداستر آنالوگ استفاده کرده اند به ارث رسیده است. محاسبه مساحت چند ضلعی خودکار نبود و بلافاصله امکان پذیر نبود، بنابراین مساحت محاسبه شده در یک مجموعه داده قانونی ثبت شد. این روش ثبت دوبار داده های مشابه در مجموعه داده های مختلف، امکان بروز ناسازگاری داده ها را ایجاد می کند.۵۳ ، ۵۴ ].

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

برخی از تراکنش‌های LAS به گونه‌ای اجرا می‌شوند که نیاز به چندین عملیات قانونی و نظرسنجی CRUD (ایجاد، خواندن، به‌روزرسانی، حذف) دارد تا کل فرآیند به پایان برسد. یکی از نمونه های چنین معامله ای تقسیم بسته است. سناریوی مورد استفاده برای این تراکنش به شرح زیر است:

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

در مثال قبلی، در مرحله ۲، داده های قانونی ورودی تراکنش داده های نظرسنجی هستند و بعداً، در مرحله ۴، داده های نظرسنجی ورودی تراکنش داده های حقوقی هستند.

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

در شکل ۱ ، نویسندگان یک نمودار کلاس UML برای انتزاعات کلید تراکنش LAS از مطالعه موردی صربستان ارائه می دهند.

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

یکی از الزامات LAS ها این است که تمام معاملات انجام شده را پیگیری کند و در صورت نیاز مقامات قانونی، برخی از آنها را برگردانده و داده های کاداستر را در حالت قبل از انجام معامله بازیابی کند. یک چالش در این شرایط ممکن است این باشد که داده هایی که باید بازیابی شوند متعاقباً تغییر می کنند. در این شرایط، یک رویکرد معمولی “لغو” نمی تواند انجام شود.

معاملات در LAS ممکن است اتمی یا ترکیبی باشد. برای مدل سازی ساختار و اجرای آن، از یک الگوی طراحی ترکیبی استفاده شده است [ ۵۵ ]. این الگو یک کامپوننت کلاس انتزاعی را پیشنهاد می‌کند که دارای عملیات مشترک با تخصص‌های آن است: برگ برای نمونه‌های اتمی و ترکیب برای نمونه‌های ترکیبی. در مورد تراکنش های LAS، کلاس انتزاعی LATransaction است و عملیات انتزاعی آن execute(); دو کلاس اتمی LegalTransaction و SurveyTransaction و کلاس ترکیبی CompositeTransaction است. با اعمال یک الگوی طراحی ترکیبی، امکان ثبت و اجرای تراکنش های ترکیبی، مانند آنچه در سناریوی مورد استفاده در بالا توضیح داده شد، به همان روشی که برای تراکنش های اتمی وجود دارد، وجود دارد.

۳٫۱٫ معاملات حقوقی

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

۳٫۱٫۱٫ مدل دامنه برای معاملات حقوقی

مدل دامنه داده قانونی LAS در شکل ۲ نشان داده شده است . چند کلاس وجود دارد که انتزاعات کلیدی را نشان می دهند.

حزب طبقه نماینده مالکانی است که می توانند افراد یا انواع مختلفی از سازمان ها (شرکت ها، مؤسسات و غیره) باشند. کلاس SpatialUnit نشان دهنده املاکی است که ممکن است یک قطعه زمین، ساختمان یا بخشی از ساختمان (آپارتمان، گاراژ و غیره) باشد. کلاس RightRestrictionResponsibility نشان دهنده محدودیت مالکیت یا مسئولیت یک طرف در یک واحد فضایی است. از آنجایی که احزاب ممکن است روابط را در یک واحد فضایی به اشتراک بگذارند، یک سهم ویژگی در کلاس تعریف می شود. این مدل همچنین شامل کلاس BasicAdministrationUnit است که در سیستم های مختلف کاداستر رایج است. واحد مدیریت پایه مجموعه ای از حقوق، مسئولیت ها و محدودیت ها را با روابط مالکیت یکسان نشان می دهد. به عنوان مثال، اگر طرف p1 حق انحصاری واحدهای فضایی su1 و su2 را داشته باشد (سهم ۱)، این دو حق در یک واحد اداری پایه گروه بندی می شوند. اگر طرفین p1 و p2 حقوق su3 و su4 را به ترتیب در سهام ۰٫۷ و ۰٫۳ به اشتراک بگذارند، این حقوق در واحد مدیریت پایه دیگری ثبت می شود. اگر طرفین p1 و p2 هر کدام نیمی از حقوق واحد فضایی su5 را به اشتراک بگذارند، در واحد آمایش سرزمین دیگری ثبت می شود.

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

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

۳٫۱٫۲٫ محدودیت در معاملات حقوقی

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

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

۳٫۲٫ بررسی معاملات

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

۳٫۲٫۱٫ مدل دامنه برای معاملات نظرسنجی

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

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

کلاس LATransaction یک یا چند geoaggregate را به عنوان یک وضعیت فعلی ایجاد می کند و یک یا چند geoaggregate را غیرفعال می کند که نشان دهنده وضعیت قبلی همان قلمرو است. به طور مشابه، به عنوان حقوق در مدل دامنه تراکنش قانونی، هر مجموعه جغرافیایی باید حاوی اطلاعاتی باشد که توسط کدام تراکنش ایجاد شده است، و در صورت وجود، کدام یک غیرفعال شده است.

توصیف دقیق‌تری از مدل دامنه نشان‌دهنده انتزاع داده‌های نقشه کاداستر و روابط آن‌ها با مفاهیم حقوقی کاداستر در [ ۲۶ ] موجود است.

۳٫۲٫۲٫ محدودیت در معاملات نظرسنجی

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

برای اطمینان از ثابت ماندن پوشش یک تراکنش پیمایشی، مرزهای تراکنش باید یک مسیر را پوشش دهند، نه لزوماً با همان تعداد رئوس. نمونه ای از تقسیم ساده بسته که این قانون را به تصویر می کشد در شکل ۴ آورده شده است.

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

در این مثال، مشاهده می شود که هندسه بسته های همسایه با برچسب ۹۹ و ۱۰۱ تحت تأثیر این تراکنش قرار می گیرد، حتی اگر آنها بخشی از حالت قبلی نبودند. پس از انجام معامله، هر دو بسته همسایه به جای چهار راس اصلی، اکنون دارای پنج رأس هستند. برای اطمینان از تغییر شکل بسته های همسایه تحت تأثیر، هر رأس جدید باید با نقاط انتهایی خط تقسیم شده هم خط باشد.

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

۳٫۳٫ معاملات ترکیبی

همانطور که قبلا ذکر شد، تغییراتی که هم شامل داده های حقوقی و هم داده های نظرسنجی می شود، تراکنش های ترکیبی نامیده می شوند. نمودار فعالیت که جریان اجرای کامل تقسیم بسته ساده را نشان می دهد در شکل ۵ ارائه شده است .

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

در حالی که داده های قانونی معمولاً مناطق را به عنوان مقادیر عدد کامل ثبت می کنند، نواحی چند ضلعی داده های نظرسنجی محاسبه شده بر اساس مختصات رأس آنها دارای مقادیر اعشاری هستند. گرد کردن مقادیر ناحیه چند ضلعی اعشاری می تواند منجر به تفاوت بین مساحت کل حالت قبلی و وضعیت فعلی در مجموعه داده قانونی شود. با فرض اینکه چند ضلعی نشان دهنده بسته ۱۰۰ از شکل ۴ استبه عنوان مثال دارای مساحت ۲۰۰٫۶ متر مربع است، قطعه ۱۰۰ در دفتر حقوقی دارای مساحت ۲۰۱ متر مربع خواهد بود. اگر بگوییم چند ضلعی های معرف بسته های ۱۰۰/۱ و ۱۰۰/۲ به ترتیب دارای مساحت های ۱۲۰٫۴ و ۸۰٫۲ هستند، مساحت آنها به ۱۲۰ و ۸۰ گرد می شود، بنابراین، پس از انجام معامله، وضعیت فعلی یک متر مربع کمتر از حالت قبلی خواهد بود. حالت. این مشکل در روند تغییرات قانونی با تسطیح مناطق قبل و بعد از معامله برطرف می شود. به طور کلی، می‌تواند تعداد زیادی بسته تحت تأثیر معامله وجود داشته باشد و اختلاف مساحت برای تسطیح به نسبت مساحت بسته تحت تأثیر معامله توزیع می‌شود.

تجزیه و تحلیل جامع یک مورد استفاده از تقسیم املاک در سوئد، با تجزیه و تحلیل ساختاری انجام شده با استفاده از LADM، در [ ۵۶ ] شرح و بحث شده است.

سازگاری داده های حقوقی و نظرسنجی

سازگاری داده های حقوقی و نظرسنجی برای صحت داده های LAS بسیار مهم است. برخی از محدودیت هایی که باید بررسی شوند عبارتند از:

سازگاری با برچسب گذاری بسته ها و ساختمان ها؛
سازگاری منطقه؛
سازگاری داده های موضوعی

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

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

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

۴٫ معماری سیستم

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

با توسعه یک DSL برای تراکنش‌های LAS، زبانی را ارائه می‌کنیم که به کارمندان LAS قدرت می‌دهد تا تراکنش‌های LAS را با نوشتن بیانیه‌های DSL انجام دهند. این عبارات توسط نرم افزار نوشته شده در برخی از GPL تفسیر می شوند. ممکن است DSLهای مختلفی برای مفسران بیانیه تراکنش LAS وجود داشته باشد که هر یک از آنها برای نرم افزار نوشتاری GPL زیربنایی تطبیق داده شده است. ذخیره، جستجو یا ویرایش این عبارات آسان خواهد بود. می توان گفت که DSL برای تراکنش های LAS سطح جدیدی از انتزاع را به اجرای تراکنش های LAS اضافه می کند.

DSL برای تراکنش های LAS همچنین می تواند امکان اجرای دستورات را به صورت زمانی از حالت صفر LAS فراهم کند. این به کاربران این امکان را می‌دهد تا وضعیت LAS را در هر نقطه از زمان بازسازی کنند.

۴٫۱٫ معماری سیستم پیشنهادی

از نقطه نظر پشتیبانی پیاده سازی برای DSL، ما می توانیم دو معماری اصلی را شناسایی کنیم:

معماری مبتنی بر کامپایلر؛
معماری مبتنی بر مفسران [ ۳۲ ].

در مورد اول، عبارات DSL به زبان دیگری ترجمه می‌شوند که قبلاً دارای معناشناسی و یک کامپایلر است. معماری مبتنی بر مفسر تفسیر عبارات DSL را بدون ترجمه عبارات به زبان دیگر ارائه می دهد.

از آنجایی که DSL برای تراکنش های LAS برای اجرای تراکنش های LAS استفاده می شود، و هیچ زبانی وجود ندارد که از قبل معنایی برای این منظور تعریف کرده باشد، معماری مبتنی بر مفسر بدیهی است که انتخاب درستی است.

یک معماری سیستم نرم افزاری ممکن که عملکردی را برای نوشتن و اجرای دستورات DSL برای تراکنش های LAS فراهم می کند در شکل ۶ ارائه شده است .

۴٫۱٫۱٫ ردیف جلویی

برای نوشتن موثر عبارات DSL معتبر، کاربر باید با محیطی فراهم شود که به فرآیند نوشتن عبارت کمک کند، مانند برجسته کردن نحو، تکمیل کد، و غیره. اگر نحو و معنای صحیح باشد.

برای پر کردن بخش‌هایی از یک عبارت با مقادیر معتبر، سطح جلویی ممکن است به خدمات ارائه‌شده توسط API بک‌اند نیاز داشته باشد. به عنوان مثال، برای تکمیل عبارتی که مالکیت را از فروشنده به خریدار منتقل می‌کند، هنگام نوشتن شناسه‌های فروشنده و خریدار در ویرایشگر، مؤلفه جلویی می‌تواند API پشتیبان را فراخوانی کند تا بررسی کند که آیا مالکانی با شناسه‌های داده شده در آن وجود دارند یا خیر. پایگاه داده علاوه بر این، برای کاربرپسندتر بودن، بخش جلویی می‌تواند گزینه‌ای در اختیار کاربر قرار دهد تا به جای تعیین شناسه، مالکان را با نام جستجو کند. در آن صورت، front-end معیارهای جستجو را برای دسترسی به صاحبان با نام تصویب می کند، در حالی که API back-end خدماتی را برای بازگرداندن داده های مالکان که درخواست مشخص شده را برآورده می کند، ارائه می دهد.

پس از نوشته شدن عبارات، قسمت جلویی باید از تجزیه کننده برای بررسی نحو و معنای عبارات DSL استفاده کند. پس از اعتبار سنجی عبارت، می توان آن را اجرا کرد. اجرای عبارت با اجرای عبارات زبان مادری مناسب انجام خواهد شد. به طور معمول، این به عنوان فراخوانی به API های ارائه شده توسط سرویس های پشتیبان ختم می شود.

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

داده های تولید شده به این روش از DSL برای بیانیه های تراکنش LAS برای اجرای تغییرات در داده های LAS ارجاع خواهند شد. این رویکرد کاربران را قادر می سازد تا به جای تعیین هندسه و داده های موضوعی با استفاده از فرمت متنی، با استفاده از محیطی شبیه به CAD با داده های نظرسنجی به روشی کاربر پسند برخورد کنند. بر این اساس، اظهارات مربوط به داده های نظرسنجی ساده خواهد بود و تنها به فایل های داده های نظرسنجی ارجاع می دهد، زیرا کار اصلی اجرای تراکنش با استفاده از ابزار دستکاری داده های نظرسنجی انجام می شود.

۴٫۱٫۲٫ ردیف عقب

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

خدمات Back-end باید چندین نوع خدمات را ارائه دهند:

بازیابی دادهها؛
اعتبار سنجی داده ها؛
اجرای تراکنش

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

از سوی دیگر، لایه پشتیبان باید با لایه ذخیره‌سازی داده تعامل داشته باشد. بسته به اجرای ذخیره سازی داده ها، لایه back-end عملکرد مناسبی را برای شروع اجرای عملیات CRUD ارائه می دهد. اگر لایه ذخیره‌سازی داده API خود را برای اجرای عملیات CRUD داشته باشد، لایه پشتیبان باید شامل اجرای مصرف‌کننده خدمات باشد. اگر ذخیره سازی داده ها در یک سیستم پایگاه داده رابطه ای باشد، یک جزء نگاشت شی رابطه ای باید ارائه شود. در هر صورت، عملکرد ذخیره سازی بیانیه های DSL برای LAS در مقایسه با سایر سیستم های چند لایه به هیچ ویژگی خاصی نیاز ندارد.

۴٫۱٫۳٫ ذخیره سازی داده ها

انتظار می رود که داده ها باید در جفت های کلید-مقدار ذخیره شوند، جایی که کلید نشان دهنده شناسه (id) یک تراکنش است، در حالی که مقدار بیانگر بیانیه LAS DSL است. در این بخش، احتمالات مختلف برای ذخیره آن جفت‌های کلید-مقدار، مانند دفتر کل متمرکز (پایگاه‌های اطلاعاتی ارتباطی یا NoSQL) یا دفتر کل توزیع‌شده (بلاک چین) مورد بحث قرار خواهد گرفت.

معمولاً در یک محیط سازمانی، داده ها در پایگاه داده های رابطه ای ذخیره می شوند. پایگاه‌های اطلاعاتی رابطه‌ای بیش از ۵۰ سال است که با توسعه مداوم زیادی پشت سر آنها وجود داشته است. پایگاه‌های داده رابطه‌ای از DSL دیگر، زبان پرس و جوی ساختاریافته (SQL) پشتیبانی می‌کنند، که یک زبان قدرتمند برای مدیریت داده‌ها و پشتیبانی از سازگاری قوی است [ ۵۷ ]. پایگاه داده‌های رابطه‌ای با داده‌های ساختاری که می‌توانند «طبیعی» در جداول قرار بگیرند بهترین کار را دارند [ ۵۸ ].

بیش از یک دهه پیش، پایگاه‌های داده NoSQL ظاهر شد، و بر خلاف پایگاه‌های داده رابطه‌ای، یکی از مزایای اعلام شده امکان مدیریت بهبود یافته داده‌های بدون ساختار است. بسته به نیاز، در پایگاه‌های داده NoSQL، داده‌ها را می‌توان در مقادیر کلید، اسناد و ستون‌های گسترده [ ۵۹ ] و فروشگاه‌های گراف ذخیره کرد. تفاوت دیگر بین پایگاه داده های رابطه ای و NoSQL مربوط به مقیاس پذیری است. پایگاه داده های رابطه ای برای مقیاس پذیری افقی مناسب نیستند، در حالی که پایگاه های داده NoSQL به راحتی می توانند به صورت افقی مقیاس شوند. در صورت نیاز به منابع بیشتری در پایگاه داده های رابطه ای، به این معنی است که مقیاس پذیری عمودی مورد نیاز است. با توجه به [ ۶۰]، حتی اگر پایگاه‌های داده NoSQL برای ذخیره داده‌های کلید-مقدار بهینه‌سازی شده‌اند، همه پیاده‌سازی‌های پایگاه داده NoSQL در مقایسه با پایگاه‌های داده رابطه‌ای عملکرد بهتری در نمونه‌سازی، ایجاد، خواندن و حذف داده‌ها نشان نمی‌دهند. با توجه به مقیاس پذیری، ذخیره عبارات DSL نباید مقدار قابل توجهی از داده ها را در یک LAS نشان دهد، بنابراین انتظار نمی رود که ذخیره این داده ها دلیل اصلی نیاز به مقیاس سازی یک پایگاه داده باشد. با در نظر گرفتن این موضوع، بین پایگاه‌های داده رابطه‌ای و NoSQL، پایگاه‌های داده رابطه‌ای باید اولین انتخاب برای ذخیره عبارات DSL باشند، حتی اگر کاربرد NoSQL در LAS در [ ۶۱ ، ۶۲ ] پیشنهاد شده باشد.

تقریباً همزمان با NoSQL، فناوری دیگری ظاهر شد که برای مدیریت تراکنش ها ایجاد شد و آن فناوری بلاک چین است. فناوری بلاک چین، همراه با داده های بزرگ و هوش مصنوعی، به عنوان یک فناوری اطلاعاتی-ارتباطات مخرب شناخته می شود که پایه و اساس دولت ۳٫۰ خواهد بود [ ۶۳ ]. احتمالاً به همین دلیل است که ۱۰ کشور از ۱۲ کشور پیشرو در دولت الکترونیک به طور خاص به کاربرد فناوری بلاک چین در این زمینه اشاره می کنند [ ۶۴ ]]. واضح است که اگر بلاک چین و پایگاه‌های داده رابطه‌ای از نظر عملکرد مربوط به نمونه‌سازی، ایجاد، خواندن و حذف داده‌ها مقایسه شوند، پایگاه‌های داده رابطه‌ای برنده خواهند شد. علاوه بر این، بلاک چین به جای مجموعه کامل عملیات CRUD، تنها توانایی ایجاد و خواندن داده ها را به کاربران ارائه می دهد. با این حال، آنچه ارائه می دهد می تواند برای ذخیره سازی بیانیه های LAS DSL اهمیت داشته باشد. بلاک چین اولین پیاده‌سازی فناوری دفتر کل توزیع‌شده را نشان می‌دهد، و به این ترتیب، برخلاف دفتر کل متمرکز (رابطه‌ای و NoSQL) که دارای مقامات متمرکز هستند، کار می‌کند. داده‌های بلاک چین در تمام گره‌های کاملی که در شبکه همتا به همتا شرکت می‌کنند ذخیره می‌شوند، در حالی که در دفتر کل متمرکز، حفظ داده‌ها از طریق پشتیبان‌گیری ضروری است. داده های ذخیره شده در یک بلاک چین شفاف هستند، و این می تواند در مواردی مانند LAS که در آن تعداد قابل توجهی از ذینفعان وجود دارد، سودمند باشد، در حالی که در دفتر کل متمرکز، مدیر می تواند انتخاب کند که کدام داده می تواند به صورت عمومی نمایش داده شود. وجود یک مدیر احتمالاً مهم ترین تفاوت بین دفتر کل توزیع شده و متمرکز است. در دفتر کل متمرکز، امکان وجود یک عامل مخرب وجود دارد که می تواند داده های ذخیره شده در پایگاه داده را تغییر دهد. در کشورهای توسعه نیافته و در حال توسعه، سوء استفاده از داده ها یا دستکاری داده ها در نتیجه فساد و تقلب به عنوان یک مشکل بزرگ شناخته می شود. در دفتر کل متمرکز، امکان وجود یک عامل مخرب وجود دارد که می تواند داده های ذخیره شده در پایگاه داده را تغییر دهد. در کشورهای توسعه نیافته و در حال توسعه، سوء استفاده از داده ها یا دستکاری داده ها در نتیجه فساد و تقلب به عنوان یک مشکل بزرگ شناخته می شود. در دفتر کل متمرکز، امکان وجود یک عامل مخرب وجود دارد که می تواند داده های ذخیره شده در پایگاه داده را تغییر دهد. در کشورهای توسعه نیافته و در حال توسعه، سوء استفاده از داده ها یا دستکاری داده ها در نتیجه فساد و تقلب به عنوان یک مشکل بزرگ شناخته می شود.۶۵ ، ۶۶ ]. در یک دفتر کل توزیع شده، انجام حملات مخرب بسیار دشوارتر است و معمولاً به منابع بسیار بیشتری نیاز دارد.

از آنجایی که عبارات LAS DSL نقطه شروع تراکنش های LAS را نشان می دهد، منطقی است که آنها را به گونه ای ذخیره کنیم که در آینده توسط عوامل مخرب قابل تغییر نباشند، و این امر می تواند با ذخیره آن جفت های کلید-مقدار در بلاک چین به دست آید. . این را می توان با پیاده سازی قراردادهای هوشمند بر روی یک بلاک چین به دست آورد. قراردادهای هوشمند برنامه‌های رایانه‌ای هستند که بر روی بلاک چین مستقر می‌شوند و توسط مجموعه‌ای از قوانین که برای همه تراکنش‌های بلاک چین اعمال می‌شود، اداره می‌شوند. پس از ذخیره‌سازی، آن رکوردها می‌توانند به‌عنوان «منبع حقیقت» مورد استفاده قرار گیرند، و در صورتی که هرگونه تراکنش در دفتر کل متمرکز مشکوک باشد، می‌توان آن‌ها را با داده‌های DSL ذخیره‌شده در یک زنجیره بلوکی که باید نقطه شروع آن می‌بود، مقایسه کرد.

از آنجایی که بلاک چین برای ذخیره حجم بالایی از داده ها مناسب نیست، پیاده سازی کامل LAS را می توان از طریق یک فرم ترکیبی، همانطور که در [ ۶۷ ، ۶۸ ] پیشنهاد شد، که در آن سیستم های سنتی، مانند دفتر کل متمرکز، با قراردادهای هوشمند ترکیب می شوند، به دست آورد. کاربرد قراردادهای هوشمند برای مدیریت تراکنش های LAS نیز در [ ۶۹ ] مورد بحث قرار گرفته است، جایی که نمونه ای از یک قرارداد هوشمند برای مدیریت آن تراکنش ها ارائه شده است.

۵٫ راه حل پیشنهادی

راه مناسب برای طراحی و پیاده سازی یک DSL، ایجاد نحو انتزاعی، نحو مشخص و معنایی است. نحو انتزاعی یک اسکلت اساسی یک زبان را نشان می‌دهد و می‌تواند به عنوان نقطه شروعی برای تعریف نحو مشخص و معناشناسی استفاده شود، اما یک ترتیب مشخص از مراحل می‌تواند استدلال شود [ ۷۰ ]. در این مورد، یک دستور زبان اول ایجاد شد و بر اساس آن دستور زبان، یک مدل متا ساخته شد. متا مدل سازی یک روش رایج برای تعریف نحو انتزاعی یک زبان است. گرامر DSL برای تراکنش های LAS با استفاده از textX ایجاد شد. TextX (مستندات کامل در مورد textX را می توان در پیوند زیر یافت ( http://textx.github.io/textX/3.0/) ، قابل دسترسی در ۲۸ ژوئن ۲۰۲۲) یک زبان فرا زبان و ابزاری است که برای تسهیل ساخت DSL ایجاد شده است. این بر روی تجزیه‌گر Arpeggio ساخته شده است، و این امکان را فراهم می‌کند که هم تجزیه‌کننده Arpeggio و هم متا مدل را از یک توصیف گرامری واحد در زمان اجرا بسازید [ ۷۱ ].

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

در فهرست ۱، قوانین انتزاعی برای File، Transaction، LegalTransaction و GeoTransaction اعلام شده است. نمونه ای از اعلان قانون را می توان در خطوط ۵ تا ۷ مشاهده کرد. در خط ۵، نام قانون انتزاعی با کلمه File و به دنبال آن یک ستون اعلام می شود. در خط ۶ آمده است که در File می تواند صفر یا چند تراکنش از نوع Transaction باشد که با علامت ستاره نشان داده شده است. در خط ۷، یک نیم ستون نماد پایان قاعده خاص وجود دارد. به روشی مشابه، قانون انتزاعی Transaction اعلام می‌شود که بیان می‌کند که معامله یا LegalTransaction یا GeoTransaction است. قانون انتزاعی LegalTransaction اعلام می‌کند که یک تراکنش حقوقی یکی از تراکنش‌های Transfer، Update یا Create است، در حالی که قانون انتزاعی GeoTransaction بیان می‌کند که معامله نظرسنجی یا CreateDevSite یا ApplyDevSite است.

فهرست ۱٫ دستور زبان DSL textX – فایل، تراکنش، تراکنش حقوقی، و معامله جغرافیایی.

در فهرست ۲، قوانین انتقال، حزب، بسته، ساختمان و اشتراک ارائه شده است. در قاعده انتقال، اعلام شده است که نقل و انتقالات باید دارای یک یا چند طرف باشد که یک یا چند قطعه با سهام خاص را به یک یا چند طرف در یک سهم خاص بفروشند. سهم یک قانون اختیاری است، زیرا در صورت عدم تعیین سهم، انتقال مالکیت کامل در نظر گرفته می شود. قانون Party با عبارات منظم تعریف می شود تا امکان نمایش یک حزب با رشته ها و/یا اعداد را فراهم کند. به طور مشابه، اعلامیه های Parcel، Building و Share، فرمت های مشترکی را برای نشان دادن بسته، ساختمان و سهم در LAS ها تعریف می کنند. به عنوان مثال در مورد قطعه ۳۴/۱۰۱/۲ به این معنی است که در شهرداری کاداستر با شناسه ۳۴، یک قطعه با شناسه ۱۰۱، با یک قطعه قطعه با شناسه ۲ وجود دارد. در مورد ساختمان. , ۳۷/۱۰۴/۳/۱۰, ۳۷ نشان دهنده شهرداری کاداستر با همان شناسه، ۱۰۴ نشان دهنده شناسه یک قطعه در آن شهرداری کاداستر، ۳ نشان دهنده شناسه ساختمان و ۱۰ نشان دهنده شناسه واحد است. برای یک سهم، کسری برای نشان دادن سهمی از مالکیت استفاده می شود که ۱/۲ به این معنی است که طرف با ۵۰٪ سهم مالکیت در انتقال شرکت می کند.

فهرست ۲٫ دستور زبان DSL textX — انتقال، مهمانی، بسته، ساختمان و اشتراک گذاری.

فهرست ۳ ، قوانین انتزاعی را برای Update و Right همراه با قوانین UpdateParty، UpdateUnit و Mortgage ارائه می‌کند. قانون انتزاعی Update بیان می کند که به روز رسانی تحت قانون UpdateParty یا قانون UpdateUnit قرار می گیرد. Rule UpdateParty اعلام می‌کند که دارایی‌ها (یعنی نام، نام خانوادگی، نام و آدرس) یک طرف می‌توانند به‌روزرسانی شوند، در حالی که قانون UpdateUnit اعلام می‌کند که کاربری و حق مالکیت می‌تواند برای قطعه یا ساختمان به‌روزرسانی شود. قاعده انتزاعی Right بیان می کند که مربوط به وام مسکن است و قانون وام مسکن ویژگی های مبلغ و نرخ بهره وام مسکن را تعریف می کند.

فهرست ۳٫ دستور زبان DSL textX—Update، UpdateParty و UpdateUnit.

در فهرست ۴ ، قانون Create برای افزودن/ایجاد یک ساختمان جدید مشخص شده است. برای افزودن ساختمان جدید، شناسه ساختمان و همچنین مشخصات یک یا چند طرف که دارای سهم خاصی از مالکیت هستند ضروری است.

فهرست ۴٫ دستور زبان DSL textX — ایجاد.

در فهرست ۵، قوانین CreateDevSite، ApplyDevSite، DevSiteID، GeoAggregateID و Comment اعلام شده است. CreateDevSite یک قانون برای انجام تراکنش های نظرسنجی است. بیان می‌کند که یک یا چند ژئوجمعیت باید انتخاب شود و یک سایت توسعه ایجاد شود. از آنجایی که این مربوط به دستکاری اشیاء فضایی است، ایجاد یک DSL متنی برای این اقدامات امکان پذیر نیست. در عوض، یک برنامه رابط کاربری گرافیکی باید راه‌اندازی شود و مجموعه‌های جغرافیایی انتخاب شده بارگیری شوند. پس از ایجاد تغییرات در داده های مکانی با استفاده از این رابط کاربری گرافیکی، از قانون ApplyDevSite برای شروع فرآیند ذخیره سازی تغییرات در ثبت قانونی استفاده می شود. قوانین باقیمانده، DevSiteID، GeoaggregateID، و Comment، نحوه قالب‌بندی سایت توسعه و شناسه‌های geoaggregate و همچنین نحوه افزودن نظرات به DSL پیشنهادی را بیان می‌کنند.

لیست ۵٫ گرامر DSL textX—CreateDevSite، ApplyDevSite، DevSiteID، و GeoAggregateID.

بر اساس گرامر textX توصیف شده، یک مدل متا برای DSL ایجاد می شود. در شکل ۷ ارائه شده است .

برای نشان دادن استفاده از DSL پیشنهادی، چندین مورد استفاده ایجاد شد. برای هر مورد استفاده، یک تست نوشته شد. در فهرست ۶ ، یک DSL برای انتقال ساده که در آن Party1 بسته ۲۳/۱۰۱ در سهم ۱/۱ را به Party2 می فروشد در خطوط ۱۱ تا ۱۶ نشان داده شده است.

لیست ۶٫ تست DSL – انتقال ساده.

در فهرست شماره ۷ ، طرف ۱۱ و حزب ۱۲، قطعه ۲۳/۱۰۱ را با سهم مالکیت ۱/۲ و ۱/۲ به ترتیب به طرف ۲۱ و حزب ۲۲ در سهام ۱/۳ و ۲/۳ می فروشند. DSL برای این انتقال در خطوط ۳۱ تا ۳۶ نوشته شده است.

لیست ۷٫ تست DSL – انتقال شامل چندین طرف و سهم متفاوتی از مالکیت.

در لیست ۸ ، نام و نام خانوادگی طرف۱ تغییر می کند. DSL برای این به روز رسانی در خطوط ۵۰ تا ۵۳ نوشته شده است.

لیست ۸٫ تست DSL—طرف به روز رسانی.

در لیست ۹ ، نام شرکت party1 تغییر کرده است. DSL برای این به روز رسانی در خطوط ۶۶ تا ۶۸ نوشته شده است.

لیست ۹٫ تست DSL – به روز رسانی طرف نماینده یک شرکت.

در فهرست ۱۰ ، آدرس party1 تغییر کرده است. DSL برای این به روز رسانی در خطوط ۸۰ تا ۸۲ نوشته شده است.

لیست ۱۰٫ تست DSL – به روز رسانی آدرس مهمان.

در فهرست شماره ۱۱ کاربری بخشی از قطعه ۳۴/۱۰۱/۲ تغییر یافته است. DSL این آپدیت در خطوط ۹۴ تا ۹۶ نوشته شده است.

فهرست ۱۱٫ تست DSL – به روز رسانی کاربری زمین.

در فهرست ۱۲ ، وام مسکن ۴۵۰۰۰٫۰۰ با نرخ سود ۷% در ساختمان ۳۴/۱۰۱/۲ از طرف طرف۱ تعیین شده است. DSL برای این به روز رسانی در خطوط ۱۱۰ تا ۱۱۴ نوشته شده است.

لیست ۱۲٫ تست DSL — حقوق به روز رسانی.

در فهرست شماره ۱۳ ، ساختمان جدیدی با شناسه ۳۴/۱۰۱/۲ اضافه/ایجاد می شود و حزب ۱ و حزب ۲ به عنوان مالک در سهام ۱/۳ و ۲/۳ تعیین می شوند. DSL برای این ایجاد در خطوط ۱۲۹ تا ۱۳۲ نوشته شده است.

لیست ۱۳٫ تست DSL-ایجاد ساختمان.

در فهرست ۱۴ ، توسعه جدیدی با شناسه ۳۴/۷۷ از geoagregates 34/17 و ۳۴/۱۸ در حال ایجاد است. DSL برای این ایجاد در خطوط ۱۴۹ تا ۱۵۰ نوشته شده است.

لیست ۱۴٫ تست DSL-ایجاد سایت توسعه.

در فهرست ۱۵ ، سایت توسعه تمام شده با شناسه ۳۴/۷۷ در ثبت قانونی اعمال می شود. DSL برای این عبارت application در خط ۱۷۰ نوشته شده است.

لیست ۱۵٫ تست DSL – استفاده از سایت توسعه.

کد کامل را می‌توانید در لینک زیر پیدا کنید ( https://github.com/djordjeprzulj/ladsl ، دسترسی به ۲۸ ژوئن ۲۰۲۲).

۶٫ نتیجه گیری

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

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

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

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

یکی دیگر از جهت‌گیری‌های تحقیقاتی، توسعه یک محیط توسعه یکپارچه کاربرپسند (IDE) است که به متخصصان دامنه در نوشتن DSL برای بیانیه‌های تراکنش‌های LAS کمک می‌کند. ابزارهای معمولی IDE، مانند برجسته کردن نحو، تکمیل کد، یا الگوهای کد، کاربران را کارآمدتر و کدنویسی را مستعد خطا می‌کنند.

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

منابع

Henssen، JG; ویلیامسون، ثبت زمین IP، کاداستر و تعامل آن – یک چشم انداز جهانی. در مجموعه مقالات کنگره XIX FIG، هلسینکی، فنلاند، ۱۰ ژوئن ۱۹۹۰; ص ۱۴-۴۳٫ [ Google Scholar ]
پترونیژویچ، م. Višnjevac، N.; پراچویچ، ن. باجات، ب. گسترش IFC برای پشتیبانی از هندسه LADM کاداستر سه بعدی. ISPRS Int. J. Geoinf. ۲۰۲۱ ، ۱۰ ، ۲۹۷٫ [ Google Scholar ] [ CrossRef ]
پااش، جی. ون اوستروم، پی. لمن، سی. Paulssond, J. مدل‌سازی بیشتر حقوق، محدودیت‌ها و مسئولیت‌های LADM (RRRs). سیاست کاربری زمین ۲۰۱۵ ، ۴۹ ، ۶۸۰-۶۸۹٫ [ Google Scholar ] [ CrossRef ]
ون اوستروم، پی. لمن، سی. مدل دامنه مدیریت زمین (LADM): انگیزه، استانداردسازی، کاربرد و توسعه بیشتر. سیاست کاربری زمین ۲۰۱۵ ، ۴۹ ، ۵۲۷-۵۳۴٫ [ Google Scholar ] [ CrossRef ]
بنت، تی. رجبی فرد، ع. ویلیامسون، آی. والاس، جی. در مورد نیاز به زیرساخت های اداره ملی زمین. سیاست کاربری زمین ۲۰۱۲ ، ۲۹ ، ۲۰۸-۲۱۹٫ [ Google Scholar ] [ CrossRef ]
چاگداش، وی. Stubkjær, E. Core Inmmobilable Property Vocabulary for European Land Landed Administration. Surv. Rev. ۲۰۱۵ , ۴۷ , ۴۹-۶۰٫ [ Google Scholar ] [ CrossRef ]
ایبان، م. آکسو، او. مدلی برای زیرساخت داده های بزرگ فضایی روستایی در ترکیه: رویکرد حسگر محور و یکپارچه. خط‌مشی استفاده از زمین ۲۰۲۰ ، ۹۱ ، ۱۰۴۳۷۶٫ [ Google Scholar ] [ CrossRef ]
اینان، اچ. مرتبط کردن اطلاعات کاربری/پوشش زمین با قطعات زمین ارائه شده در LADM. سیاست کاربری زمین ۲۰۱۵ ، ۴۹ ، ۶۲۶-۶۳۳٫ [ Google Scholar ] [ CrossRef ]
دروبژ، پ. کاسماتین فراس، م. فرلان، م. Lisec، A. انتقال از کاداستر املاک دو بعدی به سه بعدی: مورد کاداستر اسلوونی. محاسبه کنید. محیط زیست شهری. سیستم ۲۰۱۵ ، ۶۲ ، ۱۲۵-۱۳۵٫ [ Google Scholar ] [ CrossRef ]
Przewięźlikowska، A. جنبه های حقوقی همگام سازی داده ها در مورد مکان املاک و مستغلات در کاداستر لهستان و ثبت زمین و وام مسکن. خط‌مشی استفاده از زمین ۲۰۲۰ ، ۹۵ ، ۱۰۴۶۰۶٫ [ Google Scholar ] [ CrossRef ]
سیتل، وی. رویک، ام. Mastelic Ivic، M. به سوی یک کاداستر ملکی در کرواسی. Surv. Rev. ۲۰۱۲ , ۴۴ , ۱۷-۲۲٫ [ Google Scholar ] [ CrossRef ]
کیتساکیس، دی. آپوستلو، سی. Dimopoulou، E. مدل سازی سه بعدی کاداستر حقوق عرفی مالکیت منقول. Surv. Rev. ۲۰۱۵ , ۵۰ , ۱۰۷-۱۲۱٫ [ Google Scholar ] [ CrossRef ]
کارا، ا. چاگداش، وی. ایسیکداغ، یو. ون اوستروم، پی. لمند، سی. Stubkjaer، E. مدل اطلاعات ارزشیابی LADM و کاربرد آن در مورد ترکیه. خط‌مشی استفاده از زمین ۲۰۲۱ ، ۱۰۴ ، ۱۰۵۳۰۷٫ [ Google Scholar ] [ CrossRef ]
تومیک، اچ. ماستلیچ ایویچ، اس. رویچ، م. Šiško, J. توسعه یک سیستم ارزیابی دارایی کارآمد با استفاده از مدل اطلاعات ارزش گذاری LADM: مطالعه موردی کرواسی. خط مشی استفاده از زمین ۲۰۲۱ ، ۱۰۴ ، ۱۰۵۳۶۸٫ [ Google Scholar ] [ CrossRef ]
Unger، EM; زونبرگن، جی. بنت، آر. Lemmen, C. کاربرد LADM برای مناطق و جوامع مستعد بلایا. سیاست کاربری زمین ۲۰۱۹ ، ۱۸۰ ، ۱۱۸-۱۲۶٫ [ Google Scholar ] [ CrossRef ]
Unger، EM; بنت، آر. لمن، سی. Zevenbergen، J. LADM برای توسعه پایدار: یک مطالعه اکتشافی در مورد کاربرد مدل‌های داده خاص دامنه برای حمایت از SDGs. خط مشی استفاده از زمین ۲۰۲۱ ، ۱۰۸ ، ۱۰۵۴۹۹٫ [ Google Scholar ] [ CrossRef ]
راکسون، جی. بنت، آر. Groenendijk، L. مدیریت زمین برای امنیت غذایی: یک سنتز تحقیقاتی. سیاست کاربری زمین ۲۰۱۳ ، ۳۲ ، ۳۳۷-۳۴۲٫ [ Google Scholar ] [ CrossRef ]
زایسک، ای. داویدویچ، ا. نواک، م. فیگورسکا، ام. اشروبک، اس. اشروبک، آر. Burandt, J. جنبه های سازمانی مفهوم کاداستر سبز برای مناطق روستایی. خط مشی استفاده از زمین ۲۰۲۰ , ۹۱ , ۱۰۴۳۷۳٫ [ Google Scholar ] [ CrossRef ]
حبیب، م. توسعه استراتژی پایداری برای کاداستر چند منظوره در سوریه پس از جنگ. خط مشی استفاده از زمین ۲۰۲۰ , ۹۷ , ۱۰۴۷۸۲٫ [ Google Scholar ] [ CrossRef ]
ایندراجیت، ا. ون لونن، بی. پلوگر، اچ. van Oosterom, P. توسعه یک بسته اطلاعاتی برنامه ریزی فضایی در مدل دامنه مدیریت اراضی ISO 19152. خط‌مشی استفاده از زمین ۲۰۲۰ ، ۹۸ ، ۱۰۴۱۱۱٫ [ Google Scholar ] [ CrossRef ]
کافمن، جی. استودلر، دی. کاداستر ۲۰۱۴ – چشم اندازی برای سیستم کاداستر آینده ; فدراسیون بین المللی نقشه برداران (FIG): کپنهاگ، دانمارک، ۱۹۹۸٫ [ Google Scholar ]
ISO 19152:2012 ; اطلاعات جغرافیایی – مدل دامنه مدیریت زمین (LADM). کمیته فنی ISO/TC 211. سازمان بین المللی استاندارد (ISO): ژنو، سوئیس، ۲۰۱۲٫
بنت، آر. رجبی فرد، ع. کلانتری، م. والاس، جی. ویلیامسون، I. آینده های کاداستر: ایجاد چشم اندازی جدید برای ماهیت و نقش کاداستر. در مجموعه مقالات کنگره انجیر، سیدنی، استرالیا، ۱۱ آوریل ۲۰۱۰٫ [ Google Scholar ]
Lemmens, M. Towards Cadastre 2034. در دسترس آنلاین: https://www.gim-international.com/content/article/towards-cadaster-2034 (در ۲۲ ژوئیه ۲۰۲۲ قابل دسترسی است).
لمن، CHJ; اونگر، ای. ون اوستروم، PJM؛ کلانتری، م. De Zeeuw, K. بررسی گزینه‌های استانداردسازی فرآیندها و معاملات در اداره زمین. در مجموعه مقالات کنفرانس بانک جهانی زمین و فقر ۲۰۱۸: حاکمیت زمین در یک جهان به هم پیوسته، واشنگتن، دی سی، ایالات متحده آمریکا، ۱۹ مارس ۲۰۱۸٫ [ Google Scholar ]
پرژولج، ج. راداکوویچ، ن. اسلادیچ، دی. رادولوویچ، آ. Govedarica، M. مدل دامنه برای سیستم های کاداستر با مولفه کاربری زمین. Surv. Rev. ۲۰۱۷ , ۵۱ , ۱۳۵-۱۴۶٫ [ Google Scholar ] [ CrossRef ]
استفانوویچ، م. پرژولج، ج. استفانوویچ، دی. ووکمانوویچ، م. Ristić، S. OCL مشخصات محدودیت های یکپارچگی بین ثبتی در سیستم های مدیریت زمین. در مجموعه مقالات کنفرانس اروپای مرکزی در مورد اطلاعات و سیستم های هوشمند، واراژدین، کرواسی، ۲۷ سپتامبر ۲۰۱۷; صص ۲۷۳-۲۸۱٫ [ Google Scholar ]
ووچیچ، ن. مارکووینوویچ، دی. Mičević، B. LADM در جمهوری کرواسی – ساخت و آزمایش نمایه کشور. در مجموعه مقالات پنجمین کارگاه مدل دامنه مدیریت زمین، کوالالامپور، مالزی، ۲۴ سپتامبر ۲۰۱۳; صص ۳۲۹-۳۴۴٫ [ Google Scholar ]
ISO 19157:2013 ; اطلاعات جغرافیایی – کیفیت داده ها. کمیته فنی ISO/TC 211. سازمان بین المللی استاندارد (ISO): ژنو، سوئیس، ۲۰۱۳٫
ISO 19115-1:2014 ; اطلاعات جغرافیایی – فراداده – قسمت ۱: مبانی. کمیته فنی ISO/TC 211. سازمان بین المللی استاندارد (ISO): ژنو، سوئیس، ۲۰۱۴٫
ISO 19115-2:2019 ؛ اطلاعات جغرافیایی-فراداده-بخش ۲: برنامه های افزودنی برای اکتساب و پردازش. کمیته فنی ISO/TC 211. سازمان بین المللی استاندارد (ISO): ژنو، سوئیس، ۲۰۱۹٫
Voelter, M. مقدمه ای بر DSL. در دسترس آنلاین: http://dslbook.org/ (دسترسی در ۲۰ مارس ۲۰۲۲).
Tomassetti، F. زبان های خاص دامنه برای قراردادهای هوشمند. در دسترس آنلاین: https://tomassetti.me/domain-specific-languages-for-contacts/ (در ۲۹ مه ۲۰۲۲ قابل دسترسی است).
ISO 19106:2004 ; اطلاعات جغرافیایی – پروفایل ها کمیته فنی ISO/TC 211. سازمان بین المللی استاندارد (ISO): ژنو، سوئیس، ۲۰۰۴٫
رادولوویچ، آ. اسلادیچ، دی. گووداریکا، م. ریستیچ، ا. Jovanović، D. LADM کاداستر شبکه ابزار در صربستان. ISPRS Int. J. Geo-Inf. ۲۰۱۹ ، ۸ ، ۲۰۶٫ [ Google Scholar ] [ CrossRef ]
لیسژاک، جی. رویچ، م. تومیک، اچ. Mastelić Ivić، S. کرواسی توسعه مشخصات LADM برای مدیریت زمین کشاورزی دولتی. Land ۲۰۱۹ , ۱۰ , ۲۲۲٫ [ Google Scholar ] [ CrossRef ]
عبدالسلام عداد، م. الحسنه، س. الیاچی، م. Ibannaina، F. پشتیبانی از یکپارچه سازی و استانداردسازی داده های زمین از طریق استاندارد LADM: مورد نمایه کشوری مراکش MA-LADM. خط مشی استفاده از زمین ۲۰۲۰ , ۹۷ , ۱۰۴۷۶۲٫ [ Google Scholar ] [ CrossRef ]
لی، بی.-م. کیم، تی.-جی. کواک، بی.-ی. لی، ی.-اچ. Choi, J. بهبود نمایه کشوری LADM کره برای ساخت یک مدل کاداستر سه بعدی. سیاست کاربری زمین ۲۰۱۵ ، ۴۹ ، ۶۶۰-۶۶۷٫ [ Google Scholar ] [ CrossRef ]
کالوجیانی، ای. کلانتری، م. دیموپولو، ای. van Oosterom، PJM LADM توسعه پروفایل های کشور: جنبه هایی که باید منعکس و در نظر گرفته شوند. در مجموعه مقالات هشتمین کارگاه مدل دامنه مدیریت زمین (LADM 2019)، کوالالامپور، مالزی، ۱ اکتبر ۲۰۱۹٫ [ Google Scholar ]
لمن، CHJ; ون اوستروم، PJM؛ کلانتری، م. به سوی یک پیشنهاد کاری جدید برای ویرایش دوم LADM. در مجموعه مقالات هفتمین کارگاه بین المللی FIG در مورد مدل دامنه مدیریت زمین، زاگرب، کرواسی، ۱۲ آوریل ۲۰۱۸٫ [ Google Scholar ]
پولات، AA; Alkan، M. طراحی و پیاده‌سازی مدل داده‌های آرشیو خارجی مبتنی بر LADM برای معاملات ثبت زمین و کاداستر در ترکیه: مطالعه موردی شهرداری. سیاست کاربری زمین ۲۰۱۸ ، ۷۷ ، ۲۴۹-۲۶۶٫ [ Google Scholar ] [ CrossRef ]
لیسک، ا. فرلان، م. Šumrada، M. UML نشانه گذاری برای رویه معاملات زمین روستایی. Geod. وستن ۲۰۰۷ ، ۵۱ ، ۱۱-۳۴٫ [ Google Scholar ]
Kemoe, M. The Registry Land in the Blockchain–Testbed ; Kairos Future: استکهلم، سوئد، ۲۰۱۷٫ [ Google Scholar ]
ISO 19103:2005 ; اطلاعات جغرافیایی – زبان طرحواره مفهومی. کمیته فنی ISO/TC 211. سازمان بین المللی استاندارد (ISO): ژنو، سوئیس، ۲۰۰۵٫
مرنیک، م. هیرینگ، جی. Sloane، AM چه زمانی و چگونه زبان های مخصوص دامنه را توسعه دهیم. کامپیوتر ACM. Surv. ۲۰۰۵ ، ۳۷ ، ۳۱۶-۳۴۴٫ [ Google Scholar ] [ CrossRef ]
پولترونیری، آی. زورزو، AF; برناردینو، ام. مدیروس، بی. de Borba Campos، M. چک لیست ارزیابی اکتشافی برای زبان های دامنه خاص. در مجموعه مقالات شانزدهمین کنفرانس بین المللی مشترک بینایی کامپیوتری، تصویربرداری و نظریه و کاربردهای گرافیک کامپیوتری (VISIGRAP 2021)، آنلاین، ۶ فوریه ۲۰۲۱؛ صص ۳۷-۴۸٫ [ Google Scholar ]
ون دورسن، آ. کلینت، پی. Visser, J. زبانهای دامنه خاص: کتابشناسی مشروح. ACM Sigplan خیر. ۲۰۰۰ ، ۳۵ ، ۲۶-۳۶٫ [ Google Scholar ] [ CrossRef ]
دژنه، پ. لو سین، دی. پریگوت، دی. فوراکس، آر. تران، ا. آیت لاهچن، ا. کوره، او. Jeansoulin، R. طراحی یک زبان خاص دامنه برای فرآیندهای مدلسازی در مناظر. Ecol. مدل. ۲۰۰۹ ، ۲۲۰ ، ۳۵۲۷-۳۵۳۵٫ [ Google Scholar ] [ CrossRef ]
پاییز، A. Fall, J. زبان اختصاصی دامنه برای مدل‌های دینامیک چشم‌انداز. Ecol. مدل. ۲۰۰۱ ، ۱۴۱ ، ۱-۱۸٫ [ Google Scholar ] [ CrossRef ]
گوچرل، سی. گیبوایر، ن. هوئت، تی. بودری، جی. Burel، F. یک زبان دامنه خاص برای مدلسازی منظره تکه تکه: موزاییک کشاورزی بریتنی به عنوان یک مطالعه موردی. Ecol. مدل. ۲۰۰۶ ، ۱۹۴ ، ۲۳۳-۲۴۳٫ [ Google Scholar ] [ CrossRef ]
گرو، سی. Araújo، J. به سوی یک زبان مدل‌سازی خاص دامنه برای مدل‌های مبتنی بر عامل در علم استفاده از زمین. در مجموعه مقالات بیست و هشتمین سمپوزیوم سالانه ACM در محاسبات کاربردی، کویمبرا، پرتغال، ۱۸ مارس ۲۰۱۳٫ صص ۸۳-۸۵٫ [ Google Scholar ]
د سوزا، LM; دا سیلوا، AR یک زبان خاص دامنه برای سناریوهای شبیه سازی فضایی. Geoinformatica ۲۰۱۶ ، ۲۰ ، ۱۱۷-۱۴۹٫ [ Google Scholar ] [ CrossRef ]
زونبرگن، جی. دی وریس، دبلیو. Bennett, R. پیشرفت در مدیریت مسئول زمین . CRC Press: Boca Raton، FL، USA، ۲۰۱۶٫ [ Google Scholar ]
ویلیامسون، آی. Enemark، S. والاس، جی. رجبی فرد، الف. آمایش سرزمین برای توسعه پایدار ; ESRI Press: Boca Raton، FL، USA، ۲۰۱۰٫ [ Google Scholar ]
گاما، ر. هلم، آر. Vlissides، J. جانسون، آر. الگوهای طراحی: عناصر نرم افزار شی گرا قابل استفاده مجدد . Addison-Wesley: بوستون، MA، ایالات متحده آمریکا، ۱۹۹۴٫ [ Google Scholar ]
هجلمبلوم، م. پااش، جی. پالسون، جی. ادلوند، م. بوکمن، ام. به سوی اتوماسیون فرآیند تشکیل املاک سوئدی: تحلیل ساختاری و منطقی تقسیم‌بندی املاک. NJSR ۲۰۱۹ ، ۱۴ ، ۱۹-۶۳٫ [ Google Scholar ] [ CrossRef ]
وانگ، ز. وی، ز. لیو، اچ. تحقیق در مورد معماری با دسترسی بالا SQL و NoSQL. در مجموعه مقالات کنفرانس AIP، ووهان، چین، ۲۵ فوریه ۲۰۱۷٫ [ Google Scholar ]
لیویت، ن. آیا پایگاه های داده NoSQL به وعده خود عمل خواهند کرد؟ کامپیوتر ۲۰۱۰ ، ۴۳ ، ۱۲-۱۴٫ [ Google Scholar ] [ CrossRef ]
Cattell, R. Scalable SQL و NoSQL Data Stores. SIGMOD Rec. ۲۰۱۰ ، ۳۷ ، ۱۲-۲۷٫ [ Google Scholar ] [ CrossRef ]
لی، ی. Manoharan, S. مقایسه عملکرد پایگاه‌های داده SQL و NoSQL. در مجموعه مقالات کنفرانس حاشیه اقیانوس آرام IEEE 2013 در مورد ارتباطات، کامپیوترها و پردازش سیگنال، ویکتوریا، BC، کانادا، ۲۷ اوت ۲۰۱۳٫ [ Google Scholar ]
Višnjevac، N.; شوشکیچ، م. محجلویچ، ر. کوجتینوویچ، ژ. استفاده از پایگاه های داده NoSQL در حوزه کاداستر سه بعدی. Geod. وستن ۲۰۱۷ ، ۶۱ ، ۴۱۲-۴۲۶٫ [ Google Scholar ] [ CrossRef ]
Višnjevac، N.; میهایلوویچ، ر. شوشکیچ، م. کوجتینوویچ، ژ. Bajat، B. نمونه اولیه سیستم کاداستر سه بعدی بر اساس یک پایگاه داده NoSQL و یک برنامه تجسم جاوا اسکریپت. SPRS Int. J. Geoinf. ۲۰۱۹ ، ۸ ، ۲۲۷٫ [ Google Scholar ] [ CrossRef ]
پریرا، جی وی. چارالابیدیس، ی. الکسوپولوس، سی. موردو، اف. پاریچک، پی. رونژین، ا. سارانتیس، دی. فلاک، ال. ویمر، کارشناسی ارشد آموزش بنیادهای علمی و فعالیت‌های کارآفرینی در حوزه حکومتداری مبتنی بر فناوری اطلاعات و ارتباطات. در مجموعه مقالات نوزدهمین کنفرانس بین‌المللی سالانه تحقیقات دولت دیجیتال: حکمرانی در عصر داده، دلفت، هلند، ۳۰ مه ۲۰۱۸٫ [ Google Scholar ]
کمیسیون اقتصادی سازمان ملل متحد برای اروپا (UNECE) کارگروه اداره زمین (WPLA). بررسی سیستم های آمایش سرزمین ; سازمان ملل: ژنو، سوئیس، ۲۰۱۴٫
Vos, J. ثبت زمین مبتنی بر بلاک چین: نوش دارو، توهم یا چیزی در این بین؟ در مجموعه مقالات کنگره IPRA/CINDER، دبی، امارات متحده عربی، ۲۲ فوریه ۲۰۱۶٫ [ Google Scholar ]
Lemieux, V. Trusting Records: آیا فناوری بلاک چین جواب می دهد؟ ضبط مدیریت J. ۲۰۱۶ ، ۲۶ ، ۱۱۰-۱۳۹٫ [ Google Scholar ] [ CrossRef ]
بنت، آر. میلر، تی. پیکرینگ، ام. Kara, A. رویکردهای ترکیبی برای قراردادهای هوشمند در اداره زمین: درس هایی از سه اثبات مفهومی بلاک چین. Land ۲۰۲۱ , ۱۰ , ۲۲۰٫ [ Google Scholar ] [ CrossRef ]
اسلادیچ، جی. میلوساولیویچ، بی. نیکولیچ، اس. اسلادیچ، دی. رادولوویچ، الف. یک راه حل بلاک چین برای ایمن سازی معاملات املاک: مطالعه موردی برای صربستان. ISPRS Int. J. Geo-Inf. ۲۰۲۱ ، ۱۰ ، ۳۵٫ [ Google Scholar ] [ CrossRef ]
استفانوویچ، م. پرژولج، ج. ریستیچ، اس. استفانوویچ، دی. نیکولیچ، دی. درخواست قرارداد هوشمند برای مدیریت معاملات سیستم مدیریت زمین. دسترسی IEEE ۲۰۲۲ ، ۱۰ ، ۳۹۱۵۴–۳۹۱۷۶٫ [ Google Scholar ] [ CrossRef ]
آندووا، اس. ون دن برند، MGJ; انگلن، LJP; Verhoeff، T. MDE Basics با تمرکز DSL. در یادداشت های سخنرانی در علوم کامپیوتر ; Springer: برلین/هایدلبرگ، آلمان، ۲۰۱۲٫ [ Google Scholar ]
دیانوویچ، آی. وادرنا، ر. میلوساولیویچ، جی. ووکوویچ، ژ. TextX: یک ابزار پایتون برای پیاده سازی زبان های خاص دامنه. سیستم مبتنی بر دانش ۲۰۱۷ ، ۱۱۵ ، ۱-۴٫ [ Google Scholar ] [ CrossRef ]

شکل ۱٫ انتزاعات کلیدی تراکنش های LAS.

شکل ۲٫ انتزاعات کلیدی معاملات حقوقی.

شکل ۳٫ مدل دامنه تراکنش های نظرسنجی.

شکل ۴٫ تقسیم بسته ساده.

شکل ۵٫ نمودار فعالیت تقسیم بسته ساده.

شکل ۶٫ معماری سیستم ممکن.

شکل ۷٫ متا مدل DSL برای LA.