Koncepcja identyfikatorów

Transkrypt

1 Koncepcja identyfikatorów Agenda: 1 Wprowadzenie Założenia Zagadnienia i ich rozwiązania Budowa identyfikatora

2 Koncepcja Identyfikatorów O projekcie Wprowadzenie 2 Jednolity Model Danych, opracowany został w ramach projektu: Wypracowanie i wdrożenie innowacyjnych metod integracji danych katastralnych, mapy zasadniczej i Bazy Danych Topograficznych oraz modernizacja usług publicznych świadczonych przez Służbę Geodezyjną i Kartograficzną współfinansowanego z Mechanizmów Finansowych Europejskiego Obszaru Gospodarczego Zadanie: Prace eksperckie mające na celu opracowanie zintegrowanego modelu danych katastralnych oraz mapy zasadniczej, zaprojektowanie struktury bazy danych według przyjętego modelu danych, określenie niezbędnych standardów technicznych dla projektu, opracowanie zasad aktualizacji Bazy Danych Topograficznych danymi zawartymi w zintegrowanej bazie danych oraz przeprowadzenie szkoleń w tym zakresie

3 Koncepcja Identyfikatorów Szkolenie, dzień drugi Na jakim etapie szkolenia jesteśmy Wprowadzenie 3 1. Wprowadzenie 2. Interoperacyjność zbiorów danych przestrzennych 3. Przegląd Wyników Analizy Zasobów 4. Przegląd Specyfikacji OOP i OOG 5. Koncepcja identyfikatorów obiektów, wersjonowania, reguły nil reason 6. Przegląd specyfikacji modeli georeferencyjnych 7. Rekomendacja aktów prawnych, implementacja modelu, system zbierania uwag, kursy e-learning 8. Dyskusja i podsumowanie

4 Koncepcja Identyfikatorów Wprowadzenie Produkty prac eksperckich 4 Raport z analizy porównawczej Specyfikacja dla OOP Opis zasad interoperacyjności oraz opracowanie szczegółowych zasad logicznych i procedur organizacyjnych wymiany danych pomiędzy bazami danych Konsultacje środowiskowe Specyfikacja dla OMG Specyfikacja dla PMG Opis koncepcji identyfikatorów, koncepcji wersjonowania, koncepcji nil reason opis wytycznych i zaleceń implementacji schematu aplikacyjnego w środowisku relacyjnej lub relacyjno-obiektowej bazy danych oraz wymagań dla systemów zarządzania tymi bazami danych Rekomendacje aktów prawnych

5 Koncepcja Identyfikatorów Wprowadzenie Produkty prac eksperckich (5) 5 Opis koncepcji identyfikatorów, wersjonowania, reguł nil reason ; zawiera opis i uzasadnienie: koncepcji jednolitego dla całego kraju systemu unikalnych i jednoznacznych identyfikatorów dla obiektów objętych opracowywanym modelem, koncepcji opisu zmian stanu obiektów w czasie; dla każdego typu obiektu opracowane zasady definiujące warunki zmiany wersji obiektu oraz zakończenia/rozpoczęcia jego cyklu życia, reguły dotyczące przypadków, w których podczas wypełniania poszczególnych wartości atrybutów obiektu nastąpi problem niemożności ich wypełnienia Model musi wspierać te koncepcje pasować do nich.

6 Koncepcja identyfikatorów Koncepcja Identyfikatorów Wprowadzenie 6 EGB: Budynek B1 Zabytki: Budynek Z1 EGB: Budynek B2 BDOTMZ: Drzewo D1 Pamiętamy z wykładu o interoperacyjności jak wielkie znaczenie ma dla nas identyfikowanie obiektów (reprezentujących obiekty świata rzeczywistego), które mają swoje miejsce w Infrastrukturze Informacji Przestrzennej (krajowej, europejskiej) Chcemy teraz szczegółowo opisać koncepcję identyfikatorów, która spełni wszystkie wymagania i założenia, jakie przyjęliśmy na początek przejrzyjmy te założenia

7 Koncepcja identyfikatorów Koncepcja Identyfikatorów Wprowadzenie 7 EGB: Budynek B1 Zabytki: Budynek Z1 EGB: Budynek B2 BDOTMZ: Drzewo D1 Identyfikator jak z nazwy wynika - musi pozwolić nam zidentyfikować każdy obiekt, któremu taki identyfikator przydzieliliśmy. Musi mieć więc unikalną wartość. Zatem: B1 B2 B1 Z1 B1 D1 Z1 D1 itd. To podstawowy wymaganie, ale wcale nie jedyne

8 Koncepcja Identyfikatorów Założenia dla koncepcji identyfikatorów Lp. Założenie Por. punkt 1. Każdy Obiekt IIP powinien posiadać atrybut, który pozwoli na jego Jednolitość identyfikatora identyfikowanie w jednolity sposób (atrybut ten nazywany będzie w dalszej częsci Identyfikatorem IIP). 2. Jeśli Obiekt IIP może być użyty jako referencyjny powinien Unikalność identyfikatora posiadać unikalną w skali całego kraju wartość Identyfikatora IIP, w innym wypadku nie powinien mieć określonej wartości Identyfikatora IIP. 3. Identyfikator IIP musi zapewnić możliwość użycia obiektu przez inne organizacje, jako jednoznacznych referencji do obiektów. Jednolitość identyfikatora Niezmienność identyfikatora 4. Przy opracowaniu koncepcji identyfikatorów IIP należy zachować maksymalną zgodność z koncepcją identyfikatorów wg zaleceń INSPIRE, zgodnie z Generic Conceptual Model. Uniwersalność identyfikatora Budowa jednolitych dla całego kraju identyfikatorów 5. Struktura identyfikatora IIP powinna składać się z trzech części: a. przestrzeni nazw identyfikującej źródło danych, b. lokalnego identyfikatora, nadanego przez dostawcę danych, który musi być unikalny w ramach przestrzeni nazw c. identyfikatora wersji obiektu IIP 6. Dla wszystkich obiektów IIP przestrzenie nazw powinny być zdefiniowane w sposób, który będzie gwarantował unikalność identyfikatora IIP (pod warunkiem unikalności lokalnego identyfikatora w ramach przestrzeni nazw). 7. Wartość przestrzeni nazw i identyfikatora lokalnego dla obiektu IIP nie może ulec zmianie przez cały jego cykl życia. 8. Identyfikator IIP nie musi dostarczać informacji, kto jest dostawcą danych dla obiektu. 9. Struktura identyfikatora IIP powinna być tak dobrana, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. Budowa jednolitych dla całego kraju identyfikatorów Budowa jednolitych dla całego kraju identyfikatorów Niezmienność identyfikatora Identyfikowalność źródła danych Uniwersalność identyfikatora Budowa jednolitych dla całego kraju identyfikatorów Założenia Założenia zebrano w dokumentacji w formie tabeli. Każde z nich posłużyło za kanwę szczegółowego opracowania poszczególnych zagadnień (podanych w ostatniej kolumnie). Sprawdźmy jedno z założeń jako przykład 8

9 Koncepcja Identyfikatorów Zagadnienia i opis ich rozwiązania Założenia dla koncepcji identyfikatorów Lp. Założenie Por. punkt 1. Każdy Obiekt IIP powinien posiadać atrybut, który pozwoli na jego Jednolitość identyfikatora identyfikowanie w jednolity sposób (atrybut ten nazywany będzie w dalszej częsci Identyfikatorem IIP). 2. Jeśli Obiekt IIP może być użyty jako referencyjny powinien Unikalność identyfikatora posiadać unikalną w skali całego kraju wartość Identyfikatora IIP, w innym wypadku Lp. nie powinien Założenie mieć określonej wartości Identyfikatora IIP. 3. Identyfikator IIP musi zapewnić możliwość użycia obiektu przez Jednolitość identyfikatora 7 inne organizacje, jako jednoznacznych Wartość referencji do przestrzeni obiektów. Niezmienność nazw identyfikatora i 4. Przy opracowaniu koncepcji identyfikatorów IIP należy zachować Uniwersalność identyfikatora maksymalną zgodność z koncepcją identyfikatorów wg zaleceń Budowa jednolitych całego identyfikatora lokalnego dla INSPIRE, zgodnie z Generic Conceptual Model. kraju identyfikatorów 5. Struktura identyfikatora IIP powinna składać się z trzech części: Budowa jednolitych dla całego a. przestrzeni nazw identyfikującej obiektu źródło IIP danych, nie może kraju identyfikatorów ulec b. lokalnego identyfikatora, nadanego przez dostawcę danych, który musi być unikalny w ramach przestrzeni nazw c. identyfikatora wersji obiektu IIP życia. 6. Dla wszystkich obiektów IIP przestrzenie nazw powinny być Budowa jednolitych dla całego zdefiniowane w sposób, który będzie gwarantował unikalność kraju identyfikatorów identyfikatora IIP (pod warunkiem unikalności lokalnego identyfikatora w ramach przestrzeni nazw). 7. Wartość przestrzeni nazw i identyfikatora lokalnego dla obiektu IIP Niezmienność identyfikatora nie może ulec zmianie przez cały jego cykl życia. 8. Identyfikator IIP nie musi dostarczać informacji, kto jest dostawcą Identyfikowalność źródła zmianie przez cały jego cykl danych dla obiektu. 9. Struktura identyfikatora IIP powinna być tak dobrana, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. danych Uniwersalność identyfikatora Budowa jednolitych dla całego kraju identyfikatorów Zagadnienie Niezmienność identyfikatora Jako przykład przeanalizujmy nieco dokładniej to zagadnienie 9

10 Niezmienność identyfikatora Koncepcja Identyfikatorów Zagadnienia i opis ich rozwiązania Niezmienność identyfikatora 4.4.1Opis zagadnienia 4.4.2Uzasadnienie 4.4.3Przykład Typowe elementy dla każdego zagadnienia Fragment szczegółowego opisu (w tym powiązanie z założeniami)

11 Niezmienność identyfikatora Koncepcja Identyfikatorów Zagadnienia i opis ich rozwiązania 11 Fragment opisów przyjętego rozwiązania zagadnienia

12 Niezmienność identyfikatora Koncepcja Identyfikatorów Zagadnienia i opis ich rozwiązania 12 Fragment uzasadnienia przyjętego rozwiązania zagadnienia

13 Niezmienność identyfikatora Koncepcja Identyfikatorów Zagadnienia i opis ich rozwiązania 13 Fragment przykładu wykorzystania przyjętego rozwiązania zagadnienia W analogiczny sposób przedstawiono każde z zagadnień związanych z koncepcją identyfikatorów My prześledzimy to, które niejako wieńczy dzieło Budowa jednolitych dla całego kraju identyfikatorów

14 Koncepcja Identyfikatorów Budowa identyfikatorów a lista zagadnień Budowa identyfikatora 14 Opis tego zagadnienia, jak powiedzieliśmy, wieńczy dzieło (dlatego właśnie ten fragment wybraliśmy na dzisiejsze szkolenie). Pamiętajmy jednak, że w znacznej mierze opiera się na rozwiązaniach przedstawionych i uzasadnionych we wcześniejszych punktach (jednolitość, unikalność, niezmienność, identyfikowalność źródła, uniwersalność). Ze względów czasowych nie możemy omówić ich wszystkich dokładnie jak zawsze po szczegóły odsyłamy do strony Przeanalizujmy zatem zagadnienie budowy identyfikatorów

15 Budowa jednolitych dla całego kraju identyfikatorów Koncepcja Identyfikatorów Budowa identyfikatora 15 Opis zagadnienia 1. Odpowiednia budowa identyfikatora jest warunkiem koniecznym (nie zawsze wystarczającym) do spełnienia większości założeń, jakie przedstawiono. 2. Budowa identyfikatora oparta jest na specyfikacji identyfikatora opisanej w dokumentacji. 3. W modelu JMD ustalono strukturę identyfikatora i zdefiniowano jako typ (klasa) IdentyfikatorIIP (por. Specyfikacja Ogólnego Obiektu Przestrzennego ). 4. Ustalono, że atrybut, który jest identyfikatorem obiektu IIP będzie miał nazwę idiip i typ IdentyfikatorIIP. 5. Atrybut idiip jest jednym z atrybutów klasy Ogólny Obiekt Przestrzenny (OOP); przyjęto, że każdy obiekt IIP dziedziczy swoje własności z OOP. 6. Klasa IdentyfikatorIIP ma następujące atrybuty namespace, localid, versionid (za INSPIRE Generic Conceptual Model). Zobaczmy proponowany sposób użytkowania identyfikatorów...

16 Koncepcja Identyfikatorów Budowa identyfikatora 16 Powiększymy poszczególne fragmenty diagramu

17 Idea użytkowania jednolitych dla całego kraju identyfikatorów Koncepcja Identyfikatorów Budowa identyfikatora 1. Na poziomie centralnym zarządzane są przestrzenie nazw dla krajowej Infrastruktury Informacji Przestrzennej - rozpoczynające się od PL. 2. Na poziomie centralnym ustala się listę unikalnych oznaczeń zasobów informacji przestrzennej i przydziela się zarządzanie 17

18 Idea użytkowania jednolitych dla całego kraju identyfikatorów Koncepcja Identyfikatorów Budowa identyfikatora Poszczególne zasoby mogą obejmować różne zbiory danych i mogą zawierać obiekty IIP różnych typów, które dostarczane są przez różnych dostawców danych. 4. Organy wiodące zarządzają przyznawaniem praw poszczególnym dostawcom do używania przestrzeni nazw przewidzianej dla ich zasobu.

19 Idea użytkowania jednolitych dla całego kraju identyfikatorów Koncepcja Identyfikatorów Budowa identyfikatora Może być wielu dostawców danych, którzy udostępniają dane przestrzenne. Poszczególne obiekty IIP otrzymują od każdego dostawcy unikalne identyfikatory lokalne generowane jako UUID. Identyfikator UUID nie powtórzy się, mimo, że różni dostawcy danych używają tej samej przestrzeni nazw i nie korzystają z centralnego rejestru do koordynowania nadawanych wartości identyfikatorów.

20 Idea użytkowania jednolitych dla całego kraju identyfikatorów Koncepcja Identyfikatorów Budowa identyfikatora Odbiorca danych korzysta z obiektów IIP udostępnionych od różnych dostawców, pochodzących z różnych zbiorów danych.

21 Idea użytkowania jednolitych dla całego kraju identyfikatorów Koncepcja Identyfikatorów Budowa identyfikatora Budowa identyfikatorów spełnia założenia INSPIRE, użytkownicy Infrastruktury Informacji Przestrzennej z innych krajów mogą stać się użytkownikami danych z polskiej infrastruktury. Jeszcze raz rzut oka na cały diagram

22 Koncepcja Identyfikatorów Budowa identyfikatora 22 Przeanalizujemy teraz budowę pojedynczego identyfikatora

23 Koncepcja Identyfikatorów Budowa identyfikatora Klasa IdentyfikatorIIP 23 W specyfikacji Ogólnego Obiektu Przestrzennego przedstawiono klasę IdentyfikatorIIP. Atrybut idiip który występuje w klasie OgolnyObiektPrzestrzenny jest właśnie tego typu. Budowa klasy IdentyfikatorIIP i znaczenie jej poszczególnych własności jest zgodna ze specyfikacją za INSPIRE Generic Conceptual Model Zobaczmy dokładny opis tej klasy...

24 Koncepcja Identyfikatorów Budowa identyfikatora IdentyfikatorIIP namespace 24

25 Koncepcja Identyfikatorów Budowa identyfikatora IdentyfikatorIIP localid 25

26 Koncepcja Identyfikatorów Budowa identyfikatora IdentyfikatorIIP localid 26 Na koniec przykład wypełnionego wartościami identyfikatora...

27 Koncepcja Identyfikatorów Budowa identyfikatora Przykładowy identyfikator OOP.idIIP 27 Przechodzimy teraz do drugiej częsci wykładu koncepcja wersjonowania

28 Koncepcja wersjonowania Agenda: 28 Wprowadzenie Założenia Zagadnienia i ich rozwiązania Opis zmian stanu obiektu w czasie

30 Koncepcja wersjonowania Koncepcja wersjonowania Wprowadzenie 30 EGB: Budynek wersja 1 Zabytki: Budynek wersja 1 EGB: Budynek wersja 1 BDOTMZ: Drzewo wersja 1 Podobnie jak identyfikowanie obiektów wielkie znaczenie ma dla nas jednoznaczne, jednolite, uniwersalne określanie wersji obiektów (reprezentujących obiekty świata rzeczywistego), ich aktualności, zmian, sposobu uzyskania wersji historycznych Chcemy teraz szczegółowo opisać koncepcję wersjonowania, która spełni wszystkie wymagania i założenia, jakie przyjęliśmy na początek przejrzyjmy te założenia

31 Koncepcja wersjonowania Koncepcja wersjonowania Wprowadzenie 31 EGB: Budynek wersja 1 Zabytki: Budynek wersja 1 EGB: Budynek wersja 1 BDOTMZ: Drzewo wersja 1 Podobnie jak identyfikowanie obiektów wielkie znaczenie ma dla nas jednoznaczne, jednolite, uniwersalne określanie wersji obiektów (reprezentujących obiekty świata rzeczywistego), ich aktualności, zmian, sposobu uzyskania wersji historycznych Chcemy teraz szczegółowo opisać koncepcję wersjonowania, która spełni wszystkie wymagania i założenia, jakie przyjęliśmy na początek przejrzyjmy te założenia

32 Koncepcja wersjonowania Koncepcja wersjonowania Wprowadzenie 32 EGB: Budynek wersja 1 Zabytki: Budynek wersja 1 BDOTMZ: Drzewo wersja 2 Oznaczenie wersji jak z nazwy wynika - musi pozwolić nam rozpoznać różne wersje (stany) obiektów przestrzennych. EGB: Budynek wersja 2 Zatem: wersja 1 wersja 2 a jeszcze lepiej wersja 1 < wersja 2 To podstawowy wymaganie, ale wcale nie jedyne

33 Koncepcja wersjonowania Założenia dla koncepcji wersjonowania Lp. Założenie Por. punkt 1. Każdy Obiekt IIP powinien posiadać atrybuty, które pozwolą na Jednolitość wersjonowania jego wersjonowanie w jednolity sposób (atrybuty te nazywane będą w dalszej części atrybutami wersjonującymi). 2. Możliwość wersjonowania nie musi być wykorzystywana w danym Uniwersalność wersjonowania zbiorze danych lub dla danego typu obiektu. 3. Jeśli obiekt IIP jest wersjonowany powinna być zapewniona Uniwersalność wersjonowania możliwość odtworzenie jego stanu w dowolnym momencie jego życia. 4. W zbiorze danych przestrzennych mogą wystąpić różne wersje tego samego obiektu IIP w takim wypadku wersje te muszą mieć takie same wartości przestrzeni nazw i lokalnego identyfikatora a różne wartości identyfikatora wersji. Opis zmian stanu obiektu w czasie 5. Koniec życia obiektu świata rzeczywistego musi powodować (z pewnym dopuszczalnym opóźnieniem) koniec życia reprezentującego go obiektu IIP. 6. Schemat opisu cyklu życia obiektu IIP oparty jest o zasadę celowości życia obiektu, tj. życie obiektu przestrzennego trwa w celu reprezentacji obiektu świata rzeczywistego lub pewnych faktów z nim związanych (jest to zasada niezależna od własności poszczególnych, konkretnych typów obiektów). 7. Koncepcja niniejsza nie określa aspektów wersjonowania zewnętrznych obiektów (danych) powiązanych z obiektem IIP zarówno w sposób jawny (zamodelowany, np. informacje o właścicielach działki EGB), jak i ukryty (niemodelowany, ale znany, np. informacje z ewidencji dróg). 8. Zasady wersjonowania powinny być tak dobrane, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. Opis zmian stanu obiektu w czasie Uniwersalność wersjonowania Uniwersalność wersjonowania Uniwersalność wersjonowania Opis zmian stanu obiektu w czasie Założenia Założenia zebrano w dokumentacji w formie tabeli. Każde z nich posłużyło za kanwę szczegółowego opracowania poszczególnych zagadnień (podanych w ostatniej kolumnie). 33 Sprawdźmy jedno z założeń jako przykład

34 Założenia dla koncepcji wersjonowania Lp. Założenie Por. punkt 1. Każdy Obiekt IIP powinien posiadać atrybuty, które pozwolą na Jednolitość wersjonowania jego wersjonowanie w jednolity sposób (atrybuty te nazywane będą w dalszej części atrybutami wersjonującymi). 2. Możliwość wersjonowania nie musi być wykorzystywana w danym Uniwersalność wersjonowania zbiorze danych lub dla danego typu obiektu. 3. Jeśli obiekt IIP jest wersjonowany powinna być zapewniona Uniwersalność wersjonowania możliwość odtworzenie jego stanu w dowolnym momencie jego życia. 4. W zbiorze danych przestrzennych mogą wystąpić różne wersje tego samego obiektu IIP w takim wypadku wersje te muszą mieć Opis zmian stanu obiektu w czasie takie same wartości przestrzeni nazw i lokalnego identyfikatora a różne wartości identyfikatora wersji. 5. Koniec życia obiektu świata rzeczywistego musi powodować (z Opis zmian stanu obiektu w pewnym dopuszczalnym 3 opóźnieniem) Jeśli koniec obiekt życia IIP jest czasie reprezentującego go obiektu IIP. 6. Schemat opisu cyklu życia obiektu IIP oparty jest o zasadę Uniwersalność wersjonowania celowości życia obiektu, wersjonowany tj. życie obiektu przestrzennego trwa powinna być w celu reprezentacji obiektu świata rzeczywistego lub pewnych faktów z nim związanych (jest zapewniona to zasada niezależna od własności możliwość poszczególnych, konkretnych typów obiektów). 7. Koncepcja niniejsza nie określa odtworzenie aspektów wersjonowania jego Uniwersalność stanu wersjonowania w zewnętrznych obiektów (danych) powiązanych z obiektem IIP zarówno w sposób jawny (zamodelowany, np. informacje o właścicielach działki EGB), dowolnym jak i ukryty (niemodelowany, momencie ale znany, jego np. informacje z ewidencji dróg). 8. Zasady wersjonowania powinny być tak dobrane, aby ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. Uniwersalność wersjonowania Opis zmian stanu obiektu w czasie Koncepcja wersjonowania Zagadnienia i opis ich rozwiązania Lp. Założenie Zagadnienie życia. Uniwersalność wersjonowania 34 Jako przykład przeanalizujmy nieco dokładniej to zagadnienie

35 Uniwersalność wersjonowania Koncepcja wersjonowania Zagadnienia i opis ich rozwiązania Uniwersalność wersjonowania 5.3.1Opis zagadnienia 5.3.2Uzasadnienie 5.3.3Przykład Przykład 2 Typowe elementy dla każdego zagadnienia Fragment szczegółowego opisu (w tym powiązanie z założeniami)

36 Uniwersalność wersjonowania Koncepcja wersjonowania Zagadnienia i opis ich rozwiązania 36 Fragment opisów przyjętego rozwiązania zagadnienia

37 Uniwersalność wersjonowania Koncepcja wersjonowania Zagadnienia i opis ich rozwiązania 37 Fragment uzasadnienia przyjętego rozwiązania zagadnienia

38 Uniwersalność wersjonowania Koncepcja wersjonowania Zagadnienia i opis ich rozwiązania 38 Fragment przykładu wykorzystania przyjętego rozwiązania zagadnienia W analogiczny sposób przedstawiono każde z zagadnień związanych z koncepcją wersjonowania My prześledzimy to, które niejako wieńczy dzieło Opis zmian stanu obiektu w czasie

39 Koncepcja wersjonowania Opis zmian stanu obiektu w czasie Opis zmian( ) a lista zagadnień 39 Tak jak w wypadku identyfikatorów tak i w wypadku wersjonowania: opis tego zagadnienia, jak powiedzieliśmy, wieńczy dzieło (dlatego właśnie ten fragment wybraliśmy na dzisiejsze szkolenie). Pamiętajmy jednak, że w znacznej mierze opiera się na rozwiązaniach przedstawionych i uzasadnionych we wcześniejszych punktach (jednolitość, uniwersalność). Ze względów czasowych nie możemy omówić ich wszystkich dokładnie jak zawsze po szczegóły odsyłamy do strony Przeanalizujmy zatem zagadnienie opisu zmian stanu obiektów w czasie

40 Koncepcja wersjonowania Opis zmian stanu obiektu w czasie Opis zmian stanu obiektów w czasie 40 1

41 Koncepcja wersjonowania Opis zmian stanu obiektu w czasie Opis zmian stanu obiektów w czasie 41 2

42 Koncepcja wersjonowania Opis zmian stanu obiektu w czasie Opis zmian stanu obiektów w czasie 42 2 Pomijamy dodatkowe uwagi, które mogłyby uściślić zasady opisu, który przedstawiliśmy w formie tabelarycznej (zachęcamy jak zwykle do przejrzenia specyfikacji)

43 Typ zdarzenia Nowy obiekt M1 Zmiana atrybutu obiektu M1 Usunięto obiekt M1 Podjęta akcja Utwórz obiekt przestrzenny O1 Nowy obiekt O1 musi mieć odpowiednio ustawione atrybuty, które go opisują Modyfikuj obiekt przestrzenny O1 Obiekt O1 w starej wersji i nowej wersji musi mieć odpowiednio skorygowane atrybuty, które go opisują 43 Modyfikuj obiekt przestrzenny Obiekt O1 musi mieć odpowiednio skorygowane atrybuty, które go opisują; obiekt nie jest usuwany obsłużony musi być atrybut statusu Atrybut wersjonujący O1.nowy O1.stary O1.nowy O1.stary O1.nowy startobiekt Opis zmian ( ) zbiór wersjonowany [data utworzenia O1] koniecobiekt [ISO 19136: inapplicable] startwersjaobiekt [startobiekt] [poprzednia wartość] koniecwersjaobiekt [ISO 19136: inapplicable] idiip.versionid [startwersja Obiekt] [data modyfikacji O1] [Poprzednia wersja] Bez zmian Bez zmian Bez zmian Bez zmian [data modyfikacji O1] [data modyfikacji O1] [ISO 19136: inapplicable] [startwersja Obiekt] Koncepcja wersjonowania Opis zmian stanu obiektu w czasie [poprzednia wartość] [data modyfikacji O1] [Poprzednia wersja] [data modyfikacji O1] [ISO 19136: inapplicable] [startwersja Obiekt]

44 Koncepcja wersjonowania Opis zmian stanu obiektu w czasie Opis zmian ( ) zbiór nie-wersjonowany Typ zdarzenia Nowy obiekt M1 Zmiana atrybutu obiektu M1 Usunięto obiekt M1 Podjęta akcja Utwórz obiekt przestrzenny O1 Nowy obiekt O1 musi mieć odpowiednio ustawione atrybuty, które go opisują Modyfikuj obiekt przestrzenny O1 Obiekt O1 w starej wersji i nowej wersji musi mieć odpowiednio skorygowane atrybuty, które go opisują 44 Modyfikuj obiekt przestrzenny Obiekt O1 musi mieć odpowiednio skorygowane atrybuty, które go opisują; obiekt może być usunięty lub pozostawiony obsłużony musi być atrybut statusu Atrybut wersjonujący O1.nowy O1.stary O1.nowy O1.stary O1.nowy startobiekt [ISO 19136: missing] Bez zmian Bez zmian koniecobiekt [ISO 19136: inapplicable] Bez zmian Bez zmian [ISO 19136: missing] startwersjaobiekt [ISO 19136: missing] koniecwersjaobiekt [ISO 19136: missing] Bez zmian [ISO 19136: missing] [data modyfikacji O1] Bez zmian [ISO 19136: inapplicable] idiip.versionid [ISO 19136: missing/inappl. Bez zmian Bez zmian

45 Opis zmian ( ) przykład - zbiór wersjonowany Koncepcja wersjonowania Opis zmian stanu obiektu w czasie 45 Typ zdarzenia Nowy obiekt M1 Data i czas T12:12:12+01:00 Podjęta akcja Utwórz obiekt przestrzenny O1 Zmiana atrybutu obiektu M1 Data i czas T08:11:11+01:00 Modyfikuj obiekt przestrzenny O1 Zmieniono atrybut rzędna armatury górna. Usunięto obiekt M1 Data i czas T09:33:23+01:00 Modyfikuj obiekt przestrzenny Obiekt O1 musi mieć odpowiednio skorygowane atrybuty, które go opisują; obiekt nie jest usuwany obsłużony musi być atrybut statusu Atrybut wersjonujący O1.nowy O1.stary O1.nowy O1.stary O1.nowy startobiekt T12:12:12+01:00 Bez zmian: T12:12:12+01:00 Bez zmian: T12:12:12+01:00 koniecobiekt [ISO 19136: inapplicable] Bez zmian: [ISO 19136: inapplicable] Bez zmian: [ISO 19136: inapplicable] T09:33:23+01:00 startwersjaobiekt T12:12:12+01: T12:12:12+01: T08:11:11+01: T08:11:11+01: T09:33:23+01:00 koniecwersjaobiekt [ISO 19136: inapplicable] [ISO 19136: inapplicable] [ISO 19136: inapplicable] idiip.versionid T12:12:12+01: T12:12:12+01: T08:11:11+01: T08:11:11+01: T09:33:23+01:00

46 Reguła nil reason Agenda: 46 Wprowadzenie Założenia Zagadnienia i ich rozwiązania Konstrukcja reguły

48 Reguła nil reason Reguła nil reason Wprowadzenie 48 EGB: Budynek KatIstnienia Zabytki: Budynek KatIstnienia EGB: Budynek KatIstnienia BDOTMZ: Drzewo KatIstnienia? Podobnie jak identyfikowanie obiektów wielkie znaczenie ma dla nas jednoznaczne, jednolite, uniwersalne określanie wartości atrybutów obligatoryjnych w sytuacji, gdy nie ma możliwości ich wypełnienia Chcemy teraz szczegółowo opisać regułę nil reason, która spełni wszystkie wymagania i założenia, jakie przyjęliśmy na początek przejrzyjmy te założenia

49 Założenia dla reguły nil reason Reguła nil reason Założenia 49 Lp. Założenie Por. punkt 1. Dla każdego obiektu IIP należy określić jednolite zasady stosowania Jednolitość reguły nil reason reguły nil reason, tj. reguły postępowania w przypadkach, w których podczas wypełniania poszczególnych wartości atrybutów obiektu nastąpi problem niemożności ich wypełnienia wynikający np. z braku informacji lub braku dostępu do informacji, lub w szczególnych przypadkach, gdy informacje nie mają zastosowania w odniesieniu do opisywanego obiektu. 2. Zasady reguły nil reason powinny być tak dobrane, aby Konstrukcja reguły nil reason ograniczyć konieczne nakłady prac nad istniejącymi systemami (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. 3. Techniczne aspekty stosowania reguły nil reason w konkretnej implementacji modelu nie są analizowane w niniejszej koncepcji. Konstrukcja reguły nil reason Założenia zebrano w dokumentacji w formie tabeli. Każde z nich posłużyło za kanwę szczegółowego opracowania poszczególnych zagadnień (podanych w ostatniej kolumnie). Sprawdźmy jedno z założeń jako przykład

50 Założenia dla reguły nil reason Reguła nil reason Zagadnienia i opis ich rozwiązania 50 Lp. Założenie Zagadnienie Lp. Założenie Por. punkt 1. Dla każdego 3obiektu IIP należy Dla określić każdego jednolite zasady obiektu stosowania Jednolitość IIP należy reguły nil reason reguły nil reason, tj. reguły postępowania w przypadkach, w których podczas wypełniania poszczególnych wartości atrybutów obiektu nastąpi problem niemożności ich wypełnienia wynikający np. z braku informacji lub reguły braku dostępu nil do informacji, reason, lub w tj. reguły szczególnych przypadkach, gdy informacje nie mają zastosowania w odniesieniu do opisywanego postępowania obiektu. w przypadkach, w 2. Zasady reguły nil reason powinny być tak dobrane, aby Konstrukcja reguły nil reason ograniczyć konieczne nakłady których prac nad istniejącymi podczas systemami wypełniania (także danymi, którymi one zarządzają) niezbędne do zapewnienia zgodności z niniejszą koncepcją. 3. Techniczne aspekty stosowania reguły nil reason w konkretnej Konstrukcja reguły nil reason implementacji modelu nie są analizowane w niniejszej koncepcji. określić jednolite zasady stosowania poszczególnych wartości atrybutów obiektu nastąpi problem niemożności ich wypełnienia wynikający np. z braku informacji lub braku dostępu do informacji, lub w szczególnych przypadkach, gdy informacje nie mają zastosowania w odniesieniu do opisywanego obiektu. Jednolitość reguły nil reason Jako przykład przeanalizujmy nieco dokładniej to zagadnienie

51 Jednolitość reguły nil reason Reguła nil reason Zagadnienia i opis ich rozwiązania Jednolitość reguły nil reason 6.2.1Opis zagadnienia 6.2.2Uzasadnienie 6.2.3Przykład Przykład 2 Typowe elementy dla każdego zagadnienia Fragment szczegółowego opisu (w tym powiązanie z założeniami)

52 Jednolitość reguły nil reason Reguła nil reason Zagadnienia i opis ich rozwiązania 52

53 Jednolitość reguły nil reason Reguła nil reason Zagadnienia i opis ich rozwiązania 53 Fragment uzasadnienia przyjętego rozwiązania zagadnienia

54 Jednolitość reguły nil reason Reguła nil reason Zagadnienia i opis ich rozwiązania 54 Fragment przykładu wykorzystania przyjętego rozwiązania zagadnienia Prześledzimy teraz dokładniej opis zagadnienia Konstrukcja reguły nil reason

55 Reguła nil reason Konstrukcja reguły Konstrukcja reguły nil reason 55 Powiększymy ten fragment

56 Reguła nil reason Konstrukcja reguły Konstrukcja reguły nil reason 56 Definicja typu NilReasonType wg ISO NilReasonType stanowi unię wartości wyliczeniowych wg typu NilReasonEnumeration oraz składnika anyuri, który można użyć w celu wskazania adresu zasobu, gdzie znajduje się szerszy opis powodu niewypełnienia atrybutu Wyjaśnijmy jeszcze znaczenie poszczególnych wartości typu wyliczeniowego

57 Znaczenie wartości typu NilReasonEnumeration Reguła nil reason Konstrukcja reguły 57 Wartość Definicja z ISO inapplicable there is no value brak wartości missing template unknown withheld other the correct value is not readily available to the sender of this data. Futhermore, a correct value may not exist prawidłowa wartość atrybutu nie jest znana, właściwa wartość może nie istnieć the value will be available later prawidłowa wartość będzie dostępna w przyszłości the correct value is not known to, and not computable by, the sender of this data. However, a correct value probably exist prawidłowa wartość nie jest znana, ale właściwa wartość prawdopodobnie istnieje the value is not divulged wartość nie jest ujawniona (tajna?) other brief explanation inne zwięzłe wyjaśnienie Powiększymy ten fragment

58 Reguła nil reason Konstrukcja reguły Uzasadnienie 58 ISO Wybór standardowego rozwiązania opartego o normę ISO do konstrukcji reguły nil reason ogranicza potencjalne problemy z jej zastosowaniem w istniejących systemach. Standard GML ma ugruntowaną pozycję i jest dobrze znany i udokumentowany. Wiele istniejących systemów korzysta z niego w szerokim zakresie, w tym do wymiany danych i świadczenia usług przestrzennych. Zobaczmy na zakończenie przykład wykorzystania reguły nil reason

59 Reguła nil reason Konstrukcja reguły Przykład 59 W danych źródłowych atrybut obligatoryjny liczbakondygnacjinadziemnych dla budynku nie jest wypełniony ponieważ prawidłowa wartość nie jest znana, ale właściwa wartość prawdopodobnie istnieje. Zapisujemy (np. w celu udostępnienia przez usługę WFS) dane o tym budynku w formacie GML. Postać atrybutu liczbakondygnacjinadziemnych tego budynku jest wtedy następująca: <gml: liczbakondygnacjinadziemnych xsi:nil= true nilreason= unknown /> Kończymy nasz wykład pora na zwyczajową uwagę

60 Jednolity Model Danych Zakończenie Przydatne linki Zakończenie 60 Ponieważ Jednolity Model Danych związany jest różnymi zagadnieniami specjalistycznymi przy korzystaniu z kursu przydatne mogą być dodatkowe informacje zamieszczamy więc adresy stron www, z których warto naszym zdaniem w razie potrzeby skorzystać: O projekcie Kursy Model danych, UML, ISO O UML O normach ISO serii O INSPIRE Model wg INSPIRE Zapraszamy na następny wykład