Alle modelentiteter skal modelleres med persistent, unik identifikation

Nummer:
6.1
Version:
1.1.0
Høringsversion
Ændring

Ny struktur til datatypen for identifikation

Attributnavn ændret til “globalID”

Anbefaling af UUID fjernet - det er stadig en god og anvendelig løsning til brug for en lokalidentifikator.

Ændringsargumentation

Konsekvensvurdering

For eksisterende modeller vil der være en lille ommodellering - anvendelsen i ny modeller anses for værende svarende til tidligere regel

Regel

Alle entiteter skal modelleres med persistent, unik identifikation.

 

Rationale

Alle dataobjekter og dataobjekters attributter samt relationer, skal kunne identificeres entydigt på tværs af den samlede grunddatamodellen og de mange delmodeller der anvendes som input til den samlede model.

 

Ofte vil data-objektet, ud over den unikke identifikation, have en eller flere forretningsnøgler, fx har en matrikel et matrikelnummer. Men forretningsnøglerne kan ikke stå alene, da grunddatamodellen generelt skal understøtte historik, hvilket betyder, at data-objektet kan have forskellige forretningsnøgler over tid, ligesom den samme forretningsnøgle løbende kan indgå i flere forvaltningsobjekter.

Derfor er det essentielt, at objektets identifikation er persistent i hele data-objektets levetid.

 

Til brug for entydig og uforanderlig identifikation har anvendelse af HTTP-URI vist sin værdi gennem mange års praktisk anvendelse, blandt andet i XML Schema.

En HTTP-URI har yderligere den fordel at den kan anvendes som URL, Uniform Resource Locator. Når HTTP-URIen anvendes som URL, og dermed som et link, gøres det muligt at tilgå yderligere oplysninger om det HTTP-URIen identificerer. URI’en er blevet “opløsbar” ( http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier )

 

Dette giver det globale id to funktioner:

  • Global entydig identifikation af en entitet på tværs af Grunddatamodellen og på tværs af øvrige modeller.

  • Mulighed for at referere direkte til data-objektet, således at et givet data-objekt potentielt kan adresseres direkte - også vha. en generisk web-applikation.

Implikationer

Alle entiteter skal modelleres med attributten ‘globalID’, med typen GlobalID

 

globalID

 

Betydning

Unik identifikation af objektet

Værdi

Objektets unikke id

Datatype

GlobalID

Krav

Obligatorisk

Eksempel:

Datatypen GlobalID.

 

En instans af GlobalID er sammensat af en instans af datatypen Namespace og en instans af datatypen LokalID. Begge disse er specialiseringer af den standardiserede type CharacterString. Yderligere gælder det, at Namespace og LokalID skal kunne kombineres til en HTTP-URI, som specificeret i IETF RFC 3986 (http-scheme). Denne skal være universelt unik, og vil være opløsbar.

 

En HTTP-URI kan sammensættes på følgende måde - baseret på IETF RFC 3986, afsnit 3, Syntax Components:

 

Skemaangivelse + “://” + Autoritet + “/” + Sti + “#” + Objektidentifikator

 

Indhold:

Komponent

Værdi

Skemaangivelse

“http”

Autoritet

“data.gov.dk”

Sti

Valgfri, men se nedenfor

Objektidentifikator

Værdi som i det mindste er unik inden for domænet

 

HTTP-URI’en skal i sin helhed være universelt unik.

Dette kan opnås på en række måder:

 

 

Det er domænets ansvar, at sikre, at den samlede, identificerende HTTP-URI er universelt unik.

 

Komponenterne Skemaangivelse, Autoritet og Sti kan sammensættes til et Namespace, som modelleres med datatypen Namespace. Objektidentifikatoren modelleres med datatypen lokalID

 

namespace

 

Betydning

Identifikation af et namespace inden for hvilket lokalId er unik

Værdi

En HTTP-URI uden Objektidentifikator (Skemaangivelse + “://” + Autoritet + “/” + Sti)

Datatype

CharacterString

Krav

Obligatorisk

 

lokalId

 

Betydning

Identifikation af objektet

Værdi

Objektets id

Datatype

CharacterString

Krav

Obligatorisk

 

Permanent URL til denne artikel: http://arkitekturguiden.digitaliser.dk/node/829

Kommentarer

Høringssvar: MBBL

Ændringen i sig selv virker fornuftig. MBBL finder det dog uheldigt at ændre på den unikke identifikation af grunddata på et tids-punkt, hvor et af grunddataregistrene, nemlig DAGI, er modelleret efter version 1.0.0 af modelreglerne og allerede sat i produktion. Da der er tale om et GST-system, vil vi dog henholde os til GST’s vurdering af denne ændring, under forudsætning af, at den i øvrigt kan gennemføres uden at have negative implikationer for Adresseprogrammet (GD2). En mulig løsning kunne være at beskrive en konverteringsregel fra version 1.0.0 til version 1.1.0, således at de unikke identifikationer kan skifte datatype, når data overføres til Data-fordeleren.  

Høringssvar: ATP

  • Med den nye fri definition for GlobalID kender vi ikke længden for den LokalID og kan risikere at skulle modtage ”vilkårligt” lange id’er. Det er en ulempe for os som datamodtager. Vi vil gerne have begrænsning for længden af både namespace og LokalID
  • GlobalID bør hedde GlobalIdentifikator for at opfylde OIO-navnestandard
  • Vi tolker ændringen sådan at når en dataleverandør lægger sin datamodel om skal den nye datamodel overholde reglerne for UUID, som beskrevet i version 1.0.0. Dermed er ændringen en overgangsregel som tager højde for problemer for de nuværende datamodeller hos dataleverandørerne. Er det rigtigt forstået?
  • Vi vil følge den oprindelige standard  for en GlobalIdentifikator på de personer uden CPR og de virksomheder uden CVR som vi selv skal oprette. Vores GlobalIdentifikator kan se sådan ud: http://atp.dk/BG#xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

   

Svar på: Høringssvar: ATP

  • Med den nye fri definition for GlobalID kender vi ikke længden for den LokalID og kan risikere at skulle modtage ”vilkårligt” lange id’er. Det er en ulempe for os som datamodtager. Vi vil gerne have begrænsning for længden af både namespace og LokalID
    - Længden på namespace var heller ikke kontrolleret i modelregler version 1.0. Det forekommer ikke tidssvarende at bekymre sig om strenglængder - mon ikke der kan opsættes datafiltre, som modificerer modtagne data, så de kan behandles af legacy-systemer. (hvis der skal argumenteres ud fra NDR - som i det følgende - så se evt regel STD-3)
  • GlobalID bør hedde GlobalIdentifikator for at opfylde OIO-navnestandard
    - Her tænkes muligvis på OIOXML NDR regel GNR-2d om repræsentationstermer. Disse regler gælder kun for OIOXML skemaer. 
  • Vi tolker ændringen sådan at når en dataleverandør lægger sin datamodel om skal den nye datamodel overholde reglerne for UUID, som beskrevet i version 1.0.0. Dermed er ændringen en overgangsregel som tager højde for problemer for de nuværende datamodeller hos dataleverandørerne. Er det rigtigt forstået?
    - Jeg har svært ved at gennemskue, hvordan denne forståelse er kommet til: Den ændrede regel vil gælde for alle afleverede modeller.
  • Vi vil følge den oprindelige standard  for en GlobalIdentifikator på de personer uden CPR og de virksomheder uden CVR som vi selv skal oprette. Vores GlobalIdentifikator kan se sådan ud: http://atp.dk/BG#xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    - Regelen (både version 1.0 og den foreslåede ændring) siger ellers, at grunddata skal modelleres med autoriteten "data.gov.dk". Jeres namespace kunne så fx være "http://data.gov.dk/ATP/BG

Svar på: Høringssvar: ATP

  • Vi tolker ændringen sådan at når en dataleverandør lægger sin datamodel om skal den nye datamodel overholde reglerne for UUID, som beskrevet i version 1.0.0. Dermed er ændringen en overgangsregel som tager højde for problemer for de nuværende datamodeller hos dataleverandørerne. Er det rigtigt forstået?

    - Jeg har svært ved at gennemskue, hvordan denne forståelse er kommet til: Den ændrede regel vil gælde for alle afleverede modeller.
    Vores svar:
    Det var et forståelsesspørgsmål fra vores side
     

  • Vi vil følge den oprindelige standard  for en GlobalIdentifikator på de personer uden CPR og de virksomheder uden CVR som vi selv skal oprette. Vores GlobalIdentifikator kan se sådan ud: http://atp.dk/BG#xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
     

    - Regelen (både version 1.0 og den foreslåede ændring) siger ellers, at grunddata skal modelleres med autoriteten "data.gov.dk". Jeres namespace kunne så fx være "http://data.gov.dk/ATP/BG

    Vores svar:
    Vi vil følge den oprindelige standard  for en GlobalIdentifikator på de personer uden CPR og de virksomheder uden CVR som vi selv skal oprette. Vores GlobalIdentifikator kan se sådan ud: http://data.gov.dk/udk/BG#xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
     
  • Med den nye fri definition for GlobalID kender vi ikke længden for den LokalID og kan risikere at skulle modtage ”vilkårligt” lange id’er. Det er en ulempe for os som datamodtager. Vi vil gerne have begrænsning for længden af både namespace og LokalID

    - Længden på namespace var heller ikke kontrolleret i modelregler version 1.0. Det forekommer ikke tidssvarende at bekymre sig om strenglængder - mon ikke der kan opsættes datafiltre, som modificerer modtagne data, så de kan behandles af legacy-systemer. (hvis der skal argumenteres ud fra NDR - som i det følgende - så se evt regel STD-3)

    Vores svar:
    ATP har brug for at lave en lokal kopi af visse grunddata, og heri ligger vores særlige interesse for definitionen af id-felter.
    Vi anerkender, at det ikke er muligt at sætte begrænsninger på den maksimale længde af felter, men antager, at det er muligt at anvende den autoritative datakildes definition som udgangspunkt.

     

  • GlobalID bør hedde GlobalIdentifikator for at opfylde OIO-navnestandard
    - Her tænkes muligvis på OIOXML NDR regel GNR-2d om repræsentationstermer. Disse regler gælder kun for OIOXML skemaer. 
    Vores svar:
    Da vi benytter felt-navne fra tabellerne direkte i vores OIOXML_skemaer, mener vi, at det er det mest praktiske, at disse overholder OIO-standarden.
    Så vi vil kalde den og andre ID’er identifikator i stedet for ID. Men det er jo bare vores valg.

Høringssvar fra KL

Angående identifikatorer, er der jo igangsat et projekt med henblik på at opdatere gældende standard.Vores krav er at man følger nuværende standard. Og det vil sige: Et objekt skal kunne identificeres med en nøgle som besidder følgende egenskaber:

  • Global unik
  • Betydningsløs 
  • Uforanderlig
  • Skal nemt kunne tildeles af en vilkårlig aktør (itsystem) 
  • Må ikke forudsætte central nøgleudstedelse
  • Må ikke være knyttet til en bestemt teknologi eller protokol

  Dette understøtter udkast til version 1.1. umiddelbart ikke. 

Svar på: Høringssvar fra KL

Projektet med henblik på opdatering af gældende standard når desværre ikke at levere input til denne proces. Forhåbentlig vil projektetes resultater kunne inkorporeres i grunddatamodelleringen. 

Til grund for opdateringsprojetet ligger de samme ønsker om tilpasning af identifikation, som lå til grund for version 1.0 af Modelregler - ønsket om at kombinere lokal generering af nøgler med behovet for globalt unikke nøgler. Anvendelse af HTTP-URI lå allerede fast i modelregler 1.0, og vi kan ikke på nuværende tidspunkt fratræde dette valg.

Der kan argumenteres for, at den beskrevne anvendelse af HTTP-URI opfylder de fordrede egenskaber: 

  • Global unik - 
    - Ja
  • Betydningsløs 
    - Nok snarere "ikke betydningsbærende" ;-).
    - Det centrale her er, at identifikatoren ikke afhænger af forretning eller organisation på en måde, som nødvendiggør opdatering af identifikatoren i forbindelse med ændringer i forretningsobjektet (fx ændring af en persons køn jvf CPR) eller i organiseringen af data-ejerskabet. Bekymringen kunne her være, at komponenterne 'autoritet' eller 'sti' ville skulle ændres, hvis datas administrative kontekst ændres.
    Vi vil pointere i reglerne, at "data.gov.dk" skal forstås som et namespace - ikke en organisation eller et website - og derfor uforanderligt, og at 'sti' ikke må betegne en administrativ kontekst (fx. /miljøministeriet/kort_og_matrikelstyrelsen/) men udelukkende et logisk (infomationsmodels-) domæne (fx. /geodata/søer/)
    Note: ITST/2006 standarden - kapitel 2.5 angiver iøvrigt at :Identifikatorerne skal: - ikke nødvendigvis være betydningsbærende (min understregning)  
  • Uforanderlig
    - Ja, det skal pointeres i reglen jvf ovenfor
  • Skal nemt kunne tildeles af en vilkårlig aktør (itsystem) 
    - Ja, alle kan sammesætte en unik HTTP-URI-identifikator (fx af formen http://data.gov.dk/[UUID]), uden forudgående aftale med nogen
  • Må ikke forudsætte central nøgleudstedelse
    - item
    N
    OTE 2006-standarden (ibid.) siger: Identifikatorerne skal: Ikke nødvendigvis registreres centralt, da det er omkostningsfuldt økonomisk og administrativt.
  • Må ikke være knyttet til en bestemt teknologi eller protokol
    -HTTP-URI er hverken mere eller mindre knyttet til teknologi eller protokol end andre standardskemaer som URN eller UUID. HTTP-URI er grundlæggende en unik tekststreng uden yderligere bindinger end angivelse af autoritet.

Af disse grunde foreslår vi, at vedstå regelforslaget - dog med ovennævnte tilføjelser