search

arkivverket / noark5-standard

Noark 5 versjon 5.0 – innspill før versjonering til Noark 5 versjon 5.1
Other
3 stars 5 forks source link

Noark metadata for nasjonale identifikatorer #77

Closed sturtzel closed 3 years ago

sturtzel commented 3 years ago

Ref. vedlagte dokument med forslag.

Forslagene er basert på metadata som er i bruk i GeoIntegrasjon 1.1 og som er vesentlige for å identifisere personer, organisasjoner og objekter.

Metadata er dels også i bruk i Noark 5 tjenestesnitt.

Noark metadata for nasjonale identifikatorer.docx

tsodring commented 3 years ago

Som du sier er flere av disse definert i tjenestegrensesnittet og da bør de komme i standarden. Videre bør de også være med i XSD-beskrivelsene. Jeg savner veldig at dette er ikke standardisert i XSD-beskrivelsene.

sturtzel commented 3 years ago

Det er en skrivefeil i kommentarene til M03x organisasjonsid: Landkoden er firesifret, ikke tosifret (som det også fremgår av eksempelet)

hanber commented 3 years ago

Skal vi å ha landkode som a) et eget metadataelement for personID og organisasjonsID? b) en restriksjon som sier hvordan utenlandske personID-er og organisasjonsID-er skal skrives etter henholdsvis ISO3166 og ISO6523? Alternativ a) gjør det enklere å f.eks. gruppere og filtrere på land, samt å skreddersy registreringsgrensesnitt til hver enkelt lands standard. Alternativ gjør modellen litt enklere, mens man da må analysere verdi-strengen for å oppnå det samme. Hva sier dere til dette? @sturtzel: Skrivefeilen er registrert.

hanber commented 3 years ago

@petterreinholdtsen: Nå har jeg laget yaml-filer for nasjonale identifikatorer. Kan du kjøre en regenerering av metadatakatalogen? Er det forresten den objektsorterte metadatakatalogen generert ut fra filer for hvert enkelt objekt (på samme måte som yaml-filene) , eller må jeg redigere direkte i filen 120-vedlegg_2_metadatakatalog_objektsortert.rst for å legge inn de nye objektene med nasjonale identifikatorer? @oivkru: Jeg har kalt koordinetene x-koordinat, y-koordinat og z-koordinat i stedet for x, y og z. Er det akseptabelt med bindestrek i metadatanavnene? Eller skal jeg bare bruke x, y og z?

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

@petterreinholdtsen: Nå har jeg laget yaml-filer for nasjonale identifikatorer. Kan du kjøre en regenerering av metadatakatalogen?

Ja visst. Det er nå gjort.

Er det forresten den objektsorterte metadatakatalogen generert ut fra filer for hvert enkelt objekt (på samme måte som yaml-filene) , eller må jeg redigere direkte i filen 120-vedlegg_2_metadatakatalog_objektsortert.rst for å legge inn de nye objektene med nasjonale identifikatorer?

Kun 110-vedlegg_1_metadatakatalog-auto.rst avledes fra YAML-filene i metadata/. YAML-filene har ikke nok informasjon til å gjenskape 120-vedlegg_2_metadatakatalog_objektsortert.rst.

@oivkru: Jeg har kalt koordinetene x-koordinat, y-koordinat og z-koordinat i stedet for x, y og z. Er det akseptabelt med bindestrek i metadatanavnene? Eller skal jeg bare bruke x, y og z?

I tjenestegrensesnittet har klassen Posisjon, som tilsvarer GeoIntegrasjon.Geometri.Punkt, brukes følgende attributter:

Er det noen grunn til å bruke noe annet enn bare x, y og valgfri z? Bør definisjonene nevne at x er øst/vest/breddegrad og y er nord/sør/lengdegrad, ikke bare øst og nord, og slik samkjøres med definisjonene i tjenestegrensesnitt og geointegrasjon?

-- Vennlig hilsen Petter Reinholdtsen

petterreinholdtsen commented 3 years ago

Jeg ser forresten fra 3d5aa5700cd5056de9b618691f23b4cb805bd51c at tre M-nummer har byttet navn:

Det betyr videre at det ikke lenger er en metadata-oppføring for foedselsnummer, dNummer og organisasjonsnummer. Både foedselsnummer, dNummer og organisasjonsnummer i bruk i tjenestegrensesnittet. Dette er muligens første gangen jeg ser en Noark-M-kode som bytter navn. Kan det være lurere å i stedet ta i bruk ubrukte M-nummer for disse nye navnene, for å slippe å måtte introdusere versjonsnummer når en henviser til M-nummer?

-- Vennlig hilsen Petter Reinholdtsen

hanber commented 3 years ago

Siden disse metadataene ikke har vært i bruk (i metadatakatalogen) er organisasjonsnummer endret til organisasjonsID og foedselsnummer endret til personID for å ta høyde for andre (utenlandske) identifikatorer. dNummer er fjernet fordi det er en personID. Endelig har jeg flyttet personID og organisasjonsID til M048 og M049 for at de ikke skal komme midt inni metadataene for matrikkel, geografi og bygninger.

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

Siden disse metadataene ikke har vært i bruk (i metadatakatalogen) er organisasjonsnummer endret til organisasjonsID og foedselsnummer endret til personID for å ta høyde for andre (utenlandske) identifikatorer. dNummer er fjernet fordi det er en personID. Endelig har jeg flyttet personID og organisasjonsID til M048 og M049 for at de ikke skal komme midt inni metadataene for matrikkel, geografi og bygninger.

Aha. Jeg ser du la dem inn i fjor sommer, og at de dermed aldri har vært med i en utgitt utgave av noark 5-metadatakatalogen.

Merk, endring til organisasjonsID og personID gjør at tjenestegrensesnittet (og implementasjonen Nikita) må endres ganske mye. Er det forresten noen som vet hvorfor dNummer i utgangspunktet ble skilt ut fra foedselsnummer? De to er jo strukturmessige like og enkle å skille ved å se på hvilke siffer som er brukt, slik at jeg aldri har forstått hvorfor tjenestegrensesnittet delte dem i to ulike typer.

Hvis jeg forstår denne endringen du beskriver så er ideen å slå sammen norske og utenlandske person-ID-verdier til et felt, dvs. samle foedselsnummer og dNummer med også utenlandske identifikatorer. Det får meg til å undres om behovet som førte til deling av dNummer og foedselsnummer også blir oppfylt med personID. Noen som vet?

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Identifikatoren benyttes for entydig identifisering av kontakt og er det som i dag benyttes for adressering.

Men mulighet for tagging av nummeret i henhold til internasjonale standarder kan de benyttes også for andre ID-er enn de norske, f.eks. på tvers av infrastrukturen i EU, eks 9908:987654321 som et norsk organisasjonsnummer. Fant ikke den tilsvarende standarden for personidentifikator, men den er forskjellig.

hanber commented 3 years ago

Vi har vist til ISO 3166 for person og ISO 6523 for organisasjon i kommentarene. Det kan kanskje være behov for et eget element som sier hvilken standard som er benyttet (på samme måte som koordinatsystem for punkter), men det tror jeg kanskje ikke er nødvendig.

hanber commented 3 years ago

@petterreinholdtsen:

Behovet for et eget element for d-nummer var nok ikke nøye gjennomtenkt, men det er viktig at det blir dokumentert hvilket d-nummer som ble brukt når en handling ble registrert, når man eventuelt får et ordinært fødselsnummer på et senere tidspunkt.

Bare for å være helt klar. Det du sier over er at jeg må redigere direkte inn i 120-vedlegg_2_metadatakatalog_objektsortert.rst for å legge til nye objekttyper.

hanber commented 3 years ago

Er det flere som har synspunkter på om metadataene i punkt skal hete x, y og z uten å si at det er koordinater?

sturtzel commented 3 years ago

Nei, det holder at det står i dokumentasjonen at feltet kan inneholde tagg for nasjon (for norske numre i Norge bør det ikke være noe krav). Jeg visste det var behandlet, men fant ikke referansen i farten. Ser nå at referansen (uten eksempler) sto over.

Så lenge x, y og z er inni et punkt-objekt har jeg ingen preferanser om eksakt navn. Også her kan nærmere forklaring ligge i dokumentasjonen.

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

Bare for å være helt klar. Det du sier over er at jeg må redigere direkte inn i 120-vedlegg_2_metadatakatalog_objektsortert.rst for å legge til nye objekttyper.

Ja.

-- Vennlig hilsen Petter Reinholdtsen

hanber commented 3 years ago

@petterreinholdtsen: Takk for korrigeringen av manglende anførselstegn i yaml-filene. Er det ingen måte å få skjult tabellinformasjonen over hver tabell? For øvrig burde ikke objekttabellene inneholdt datatype, den bør ligge i metadatakatalogen (som den også gjør, men tas ikke med i autogenereringen). Når jeg får veldig god tid, skal jeg gå gjennom metadatakatalogen og den objektsorterte for å verifisere at det er overensstemmelse.

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

Er det ingen måte å få skjult tabellinformasjonen over hver tabell?

Kan du forklare i mer detalj hva du mener? Forstår ikke hva du spør om.

For øvrig burde ikke objekttabellene inneholdt datatype, den bør ligge i metadatakatalogen (som den også gjør, men tas ikke med i autogenereringen). Når jeg får veldig god tid, skal jeg gå gjennom metadatakatalogen og den objektsorterte for å verifisere at det er overensstemmelse.

Merk at typeinformasjonen i YAML-filene gjør det mulig å kjøre 'make avledet/metadatakatalog.xsd' og få en XSD-fil som kan sammenlignes med den offisielle XSD-filen og oppdage avvik mellom dem. Det er stor forskjell akkurat nå.

Eller er jeg enig i at det kan være lurt å ikke ha typeinformasjon flere plasser i spesifikasjonen, for å fjerne muligheten for at de kommer ut av synk.

-- Vennlig hilsen Petter Reinholdtsen

hanber commented 3 years ago

Jeg mener linjen :widths: 2 11 6 2 1 7 :header-rows: 1 over hver tabell.

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

Jeg mener linjen :widths: 2 11 6 2 1 7 :header-rows: 1 over hver tabell.

Aha. Du sier ikke hvor du ser dette og for hvilket format du ser den, men jeg mistenker du snakker om githubs RST-visning, da den ikke finnes i PDF- og HTML-utgaven når jeg bygger her lokalt.

Github har desverre en versjon av RST-tolkeren som ikke støtter denne notasjonen (antagelig en eldre utgave av verktøyene jeg bruker, men jeg vet ikke hva de faktisk kjører på github.com), og eneste måten å gjøre noe med det er å overtale github til å endre/oppgradere sitt installerte verktøy. Jeg ville satt stor pris på om du lyktes med det.

Selv har jeg sagt meg fornøyd med å ha lokalt installerte verktøy som gjør det riktig, men innser at det kunne vært gjort mer.

-- Vennlig hilsen Petter Reinholdtsen

hanber commented 3 years ago

Det er helt korrekt. Er det noen måte jeg kan generere pdf fra rst on the fly?

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

Det er helt korrekt. Er det noen måte jeg kan generere pdf fra rst on the fly?

Jeg bruker en Debian Buster-boks med dblatex etc installert, og skriver 'make' i git-depotkatalogen for å bygge PDF. Det er eneste måten jeg vet om, men antar Windows kan presses til å gjøre det samme. Vet at folk bruker både latex, dblatex, pandoc og python på Windows, som er verktøyene som er brukt. Selv hadde jeg nok laget en virtuell maskin med Debian og gjort jobben der hvis jeg ble tvunget til å bruke Windows.

-- Vennlig hilsen Petter Reinholdtsen

petterreinholdtsen commented 3 years ago

Noark 5 tjenestegrensesnitt har følgende klassenavn for nasjonale identifikatorer (fellesnavnet for alle er "Nasjonalidentifikator"):

Jeg ser master for Noark-5-spesifikasjonen derimot har gått for følgende navn:

Det vil være en fordel både for konsistens, foroverkompatibilitet og enkel implementasjon om noark 5-avleveringsformatet brukte de samme navnene som tjenstegrensesnitt-API-et. Hva er grunnen til at det er valgt andre navn enn det som allerede er tatt i bruk i Noark 5 tjenestegrensesnitt?

Personlig synes jeg posisjon er et mye bedre navn enn punkt, og synes det blir merkelig med både bruk av 'nummer', 'ident' og 'ID'.

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Det er langt flere integrasjoner der ute på GeoIntegrasjon 1.1 enn på Noark 5 tjenestesnitt.

De som kommer fra andre standarder bør følge disse. Ref. bl.a.: https://www.test.matrikkel.no:7004/matrikkelapi/wsapi/v1/dokumentasjon/implementasjonsmodellAPI/index.htm

Ser at matrikkelen opererer med Posisjon (med x, y, z) i modellen over. Men det er Matrikkelnummer, ByggIdent. Matrikkel er overordnet, så også Bygning. Her snakker vi om identifikatorer for disse, ikke om det komplette objektet (som inneholder langt mer informasjon).

Fødselsnummer er en norsk personidentifikasjon, mens korrespondanse også går til utenlandske uten norsk fødselsnummer. Vi må forvente av SvarUt og eFormidling etter hvert støtter forsendelse også til utenlandske mottagere (allerede på plass for eFaktura). Da bør identifikatorene gjenspeile dette.

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Det er langt flere integrasjoner der ute på GeoIntegrasjon 1.1 enn på Noark 5 tjenestesnitt.

Merk, støtten for nasjonale identifikatorer i Noark 5 Tjenestegrensesnitt er i stor grad basert på tilsvarende i GeoIntegrasjon, men i og med at tjenestegrensesnittet har rikere funksjonalitet ble det gjort justeringer for å sikre full funksjonalitet også for nasjonale identifikatorer.

De som kommer fra andre standarder bør følge disse. Ref. bl.a.: https://www.test.matrikkel.no:7004/matrikkelapi/wsapi/v1/dokumentasjon/implementasjonsmodellAPI/index.htm

Her falt jeg av. Hva mener du med "De som kommer fra andre standarder bør følge disse"?

Ser at matrikkelen opererer med Posisjon (med x, y, z) i modellen over. Men det er Matrikkelnummer, ByggIdent. Matrikkel er overordnet, så også Bygning. Her snakker vi om identifikatorer for disse, ikke om det komplette objektet (som inneholder langt mer informasjon).

Jeg oppfatter at vi er enige om attributtlisten, som i stor grad er definert av Brønnøysundsregistrene, Folkeregisteret og Kartverket. Diskusjonen jeg tar opp gjelder navngivingen.

Fødselsnummer er en norsk personidentifikasjon, mens korrespondanse også går til utenlandske uten norsk fødselsnummer. Vi må forvente av SvarUt og eFormidling etter hvert støtter forsendelse også til utenlandske mottagere (allerede på plass for eFaktura). Da bør identifikatorene gjenspeile dette.

Enig.

Jeg ser forslaget er at en skal bruke landskode og skråstrek for person- og enhets-ID, mens en skal bruke kolon som skilletegn i koordinatsystemverdiene. Hvorfor ikke kolon begge steder?

Kunne jo ha "no:110180010101" i stedet for "no/110180010101". Hva med land som har flere ulike ID-serier? Det bør vel håndteres på felles vis? Trengs det et register over prefikser?

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Identifikatorer som er standardisert i matrikkelen bør ha samme navngivning på objekter og attributter i Noark. Derfor Matrikkelnummer (skjønt matrikkelen sier Matrikkelenhetident...) og ikke kun Matrikkel, ByggIdent og ikke bygningsnummer. For eiendommer etc. bør det også ses på standardiseringen rundt eByggesøknad og eByggesak m.fl. i regi av KS og Kartverket. Her er det gjennomgående objekter fra matrikkel til søknad til saksbehandling til matrikkel. Det hadde vært nyttig å fått f.eks. Tor Kjetil / Arkitektum inn i debatten.

Skilletegnet og prefikset er dessverre standardisert forskjellig for enhets- og personidentifikasjon. Her bør vi følge standardene.

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Skilletegnet og prefikset er dessverre standardisert forskjellig for enhets- og personidentifikasjon. Her bør vi følge standardene.

Aha. I så fall synes jeg beskrivelsen i metadatakatalogen bør henvise til relevant standard, f.eks. ved å legge inn en kommentar og lenke ala 'formattert i tråd med , med skråstrek mellom landskode og id-verdi' eller lignende, for å gjøre det klart hva en ønsker å oppnå. Ragnar, hva er standardene du henviser til her for enhets-id, person-id og koordinatsystemer? Har du lenker til dem?

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Hans Fredrik har referanse til ISO-standardene lenger oppi denne saken: ISO 3166 (mest brukt) og ISO 6523 (Peppol). Synes å huske at dette har vært diskutert i en annen sak. Her bør Digdir drar inn.

Koordinatsystemer ligger innenfor Kartverkets område, lenke til matrikkelen som inkluderer posisjon lenger oppe i denne i saken. Matrikkelen er svær, det er noen få elementer som er tatt ut her.

hanber commented 3 years ago

I kommentarene til personID og organisasjonsID står det "For utenlandske personer, to-bokstavers landkode i hht. ISO 3166 etterfulgt av skråstrek etterfulgt av nasjonal person-identifikator." og "For utenlandske organisasjoner, firesifret landkode i hht. ISO 6523 etterfulgt av kolon etterfulgt av nasjonal organisasjons-identifikator." Dette burde være klart nok om formatering.

Kunne vi fått til en like presis beskrivelse av koordinatsystem slik at vi unngår "normalt ..." og "kan også ..."?

Jeg har forresten rettet 32632 (Nord-Norge, Norge generelt) til 32633.

sturtzel commented 3 years ago

Koordinatsystemer er det så mange av at det der ikke er mulig å være helt presis. Eksemplene er de som oftest brukes (med rettelsen). Snakk med noen som er enda mer inni kartverdenen. Start med Tor Kjetil.

petterreinholdtsen commented 3 years ago

[Hans Fredrik Berg]

I kommentarene til personID og organisasjonsID står det "For utenlandske personer, to-bokstavers landkode i hht. ISO 3166 etterfulgt av skråstrek etterfulgt av nasjonal person-identifikator." og "For utenlandske organisasjoner, firesifret landkode i hht. ISO 6523 etterfulgt av kolon etterfulgt av nasjonal organisasjons-identifikator." Dette burde være klart nok om formatering.

Jeg kjenner ikke ISO 6523, men finner den litt beskrevet på <URL: https://en.wikipedia.org/wiki/ISO/IEC_6523 >. Den sier intet om kolon vs. skråstrek. Hvilken bit av ISO 6523 er det som sier at det skal være kolon som skilletegn?

Jeg kjenner derimot ISO 3166 bedre, og der er det så vidt jeg vet intet om skilletegn, slik at vi står fritt til å bruke kolon, skråstrek eller et hvilket som helst tegn som ikke er bokstaver og tall. Hva er grunnen til at det er foreslått skråstrek for person-id, når det brukes kolon for enhets-ID?

Kunne vi fått til en like presis beskrivelse av koordinatsystem slik at vi unngår "normalt ..." og "kan også ..."?

Så vidt jeg vet er EPSG det mest komplette register over koordinatsystemer tilgjengelig, og den brukes både av geonorge og kartverket for å identifisere koordinatsystemer. Jeg tror ikke vi trenger mer enn dette. I tjenestegrensesnittet er det en beskrivelse som kanskje kan brukes til å gjøre det klart at verdiene skal være EPSG-referanser?

[Ragnar Sturtzel]

Koordinatsystemer er det så mange av at det der ikke er mulig å være helt presis. Eksemplene er de som oftest brukes (med rettelsen). Snakk med noen som er enda mer inni kartverdenen. Start med Tor Kjetil.

Kan du forklare hva du mener med "koordinatsystemer er det så mange av at det der ikke er mulig å være helt presis"?

Katalogen til EPSG har presise definisjoner på en enorm mengde koordinatsystemer, og ved å begrense seg til å henvise til EPSG-nummer vil en så vidt jeg forstår dekke alle geografiske koordinatsystemer brukt i Norge i dag, og antagelig hele verden med. De eksemplene som er brukt i M043 er så vidt jeg kan se seks ulike måter å oppgi tre identiske koordinatsystemer (EPSG:32632 = EUREFSone32, EPSG:32633 = EUREFSone33, EPSG:32635 = EUREFSone35). Det gjør at jeg mener varianten med EUREFSone## kan droppes. Har jeg misforstått, og det er forskjell på disse koordinatsystemene? Fant desverre lite informasjon om EUREFSone##.

Ved å gå for EPSG-referanser blir det trivielt å omforme enhver posisjon i arkivdatabasen slik at de kan sammenlignes og søkes i med geografiske områdesøk. Det finnes ferdige fri programvarebiblioteker for å jobbe med EPSG-referanser og koordinater med tilhørende koordinatsystem definert i EPSG-katalogen. Jeg har aldri hørt om EUREFSone##-referanser og aner ikke hva som brukes slike. Er det bare en måte å oppgi UTM-soner?

Foreslår koordinatsystemdiskusjonen flyttes til <URL: https://github.com/arkivverket/noark5-standard/issues/91 >, så kan de andre temaene diskuteres her.

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Ref. dokumentet som var starten. I kommentarene ligger det URL-er etter anbefaling fra Digdir. For enhetsidentifikasjon via Peppol: https://www.galaxygw.com/iso6523/ For personidentifikasjon via ID-porten (eIDAS): https://docs.digdir.no/oidc_func_eidas.html Her fremkommer de forskjellige syntaksene. Det hadde vært fint med entydighet, men her tror jeg vi bør følge EU og Digdir.

hanber commented 3 years ago

Da har jeg skiftet fra x,y,z-koordinater til x,y,z, og lukker dette issuet, slik at koordinat-diskusjonen fortsetter i #91. Jeg legger inn lenkene Ragnar nevner her i metadatakatalogen.

petterreinholdtsen commented 3 years ago

Betyr det at du ikke vil diskutere navnene på de andre klassene, som punkt/posisjon?

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Ref. dokumentet som var starten. I kommentarene ligger det URL-er etter anbefaling fra Digdir. For enhetsidentifikasjon via Peppol: https://www.galaxygw.com/iso6523/

Forstår jeg deg riktig i at tanken er å bruke innkjøpsstandarden Peppol til å definere referanser til enheter i arkivet? Intet i mot det, men det bør komme klarere frem at det er dette som gjøres.

Noen som vet hva brønnøysundsregistrene bruker for utenlandske eiere i eierskapsregisteret?

Jeg ser OpenCorporates bruker katalogstrukturen å URL-ene til å oppgi enhets-ID-er, og har et egen tre for identifiers:

For personidentifikasjon via ID-porten (eIDAS): https://docs.digdir.no/oidc_func_eidas.html

Jeg finner ingen forekomst av "NO/" i denne spesifikasjonen, men lette bare raskt for å se om jeg fant det du henviser til. Det nærmeste jeg finner er "eidas-personidentifier" : "SE/NO/199008199391", som bruker doble landkoder (SE og NO). Er ideen å lage sin egen variant med bare en landkode, eller har jeg gått glipp av hvor det står i eIDAS?

Her fremkommer de forskjellige syntaksene. Det hadde vært fint med entydighet, men her tror jeg vi bør følge EU og Digdir.

Både skråstrek og kolon er entydig, så det er ikke et problem. Mitt poeng her når det gjelder formatet på feltene for person-id og enhets-id er fordelene med konsistens i Noark 5, hvilket for meg betyr å bruke enten kolon begge steder eller skråstrek begge steder. Eller er poenget at en skal kunne vite at 123:123123415 er en enhets-id, mens NO/123123415 er en personide ved å se at de inneholder holon eller skråstrek?

-- Vennlig hilsen Petter Reinholdtsen

hanber commented 3 years ago

Punkt/posisjon kan eventuelt tas opp som eget issue. Jeg synes posisjon er et bedre ord, men har ingen sterke meninger om det. Det viktigste er at vi navner objektene slik at de er i overensstemmelse med autoritetene. Hva sier Kartverket?

sturtzel commented 3 years ago

Matrikkelen sier posisjon (ref. lenken til test matrikkel).

Eksemplene ang. enheter og personer fikk jeg via GI 2.0 fra Digdir. Snakk med Leikangermiljøet for dokumentasjon og anbefalinger.

petterreinholdtsen commented 3 years ago

Jeg la nettopp merke til, etter å ha sammenlignet, at det som er sjekket inn i master når det gjelder nasjonale identifikatorer har mye mindre funksjonalitet enn det som i dag er definert i tjenestegrensesnittet.

Tjenestegrensesnittet introduserer en ny type nasjonalidentifikator (med undertyper Bygning, Enhetsidentifikator, Matrikkel, Personidentifikator, Plan og Posisjon) som kan knyttes null eller flere ganger til både Registrering og Mappe. I tillegg kan Enhetsidentifikator knyttes null eller flere ganger til PartEnhet (spesialisering av Part) og KorrespondansePartEnhet (spesialisering av KorrespondansePart), samt at null eller flere Personidentifikator kan knyttes til PartPerson (spesialisering av Part) og KorrespondansepartPerson (spesialisering av KorrespondansePart).

Det som er definert i forslaget sjekket inn i master for Noark 5 nå er mer begrenset. Her kan kun byggident, matrikkelnummer, planident og posisjon kun kobles null eller flere ganger til saksmappe. I tillegg kan personID og organisasjonsID knyttes null eller en gang til part og korrespondansepart.

Dette gjør at informasjon samlet inn i tjenestegrensesnittet ikke kan avleveres med Noark 5. Det bør være mulig å ta vare på informasjonen samlet inn med Noark 5 tjenestegrensesnitt i en Noark 5-avlevering.

Skal ikke forsøke å beskrive alt som mangler av funksjonaliteten, men kan nevne at i Noark 5 tjenestegrensesnitt kan et dokument og en sak kobles til flere organisasjonsnummer. Det er også mulig å koble en sak til både fødslesnummer og d-nummer for samme person, en slipper erstatte d-nummer med fødselsnummer hvis begge er aktuelle.

Foreslår på denne bakgrunn at denne mangelmeldingen gjenåpnes og at master oppdateres med litt mer funksjonalitet.

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Her er det greit å se på formålet med identifikatorene.

Hvis du registrerer flere organisasjonsnumre på en korrespondansepart og så skal sende til denne. Skal det da sendes flere brev? Burde det ikke da vært registrert flere korrespondanseparter?

Parter på mappe benyttes gjerne fordi det er aktuelt å ta de inn som korrespondanseparter.

Jeg tror ikke det finnes så mye materiale der ute med mange numre og jeg tror at de aller fleste brukere av brukergrensesnitt som må forholde seg til modellen vil være tilfreds med å slippe å ha en rekke mangekoblinger å måtte navigere / registrere i.

Rent praktisk her: Dupliser f.eks. korrespondansepart i avleveringen eller bruk merknad.

Selv om noen har endret ID er hovedpoenget for Noark et annet enn hovedpoenget for f.eks. folkeregisteret og enhetsregisteret. Så behold slik det har blitt nå! De få systemene der D-nummer over til fødselsnummer trengs å tas vare på innenfor samme mappe/registrering bør ikke komplisere for alle andre. VSM?

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Hvis du registrerer flere organisasjonsnumre på en korrespondansepart og så skal sende til denne. Skal det da sendes flere brev? Burde det ikke da vært registrert flere korrespondanseparter?

En kan ikke registrere flere organisasjonsnumre på part og korrespondansepart i Noark 5 Tjenestegrensesnitt. Det gjelder kun person-identifikatorer.

Selv om noen har endret ID er hovedpoenget for Noark et annet enn hovedpoenget for f.eks. folkeregisteret og enhetsregisteret. Så behold slik det har blitt nå! De få systemene der D-nummer over til fødselsnummer trengs å tas vare på innenfor samme mappe/registrering bør ikke komplisere for alle andre. VSM?

Husk at her snakker vi om avleverings- og kanskje utvekslingsformater, ikke brukergrensesnitt. Poenget mitt er at de systemene som har mulighet til å koble flere ID-er til dokument og sak bør ha mulighet til å avlevere det på standardisert format for å forenkle søk og samvirke. Det er jo riktig at alle felter kan gjøres om til Virksomhetsspesifikke metadatafelter, men det betyr ikke at det er en god ide for hverken samvirke, gjenbruk eller bevaring.

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Alt som kan registreres i arkivet bør reflekteres i et brukergrensesnitt. Og flere ID-er på en korrespondansepart må bety at alle skal motta når noe distribueres elektronisk. Modellene til Noark må favne videre enn kun langtidsbevaring. De skal brukes i FIKS Arkiv/Digdir eFormidling, dialoger, mot alle integrasjoner etc. Hvis man skal ha flere ID-er på en korrespondansepart må det være fordi dette er mer enn info om parten.

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Alt som kan registreres i arkivet bør reflekteres i et brukergrensesnitt. Og flere ID-er på en korrespondansepart må bety at alle skal motta når noe distribueres elektronisk. Modellene til Noark må favne videre enn kun langtidsbevaring. De skal brukes i FIKS Arkiv/Digdir eFormidling, dialoger, mot alle integrasjoner etc. Hvis man skal ha flere ID-er på en korrespondansepart må det være fordi dette er mer enn info om parten.

Mulig vi nærmer oss dette fra to ulike vinkler her. Poenget mitt er at avleveringsformatet som beskrives av Noark 5 bør kunne ta imot like mye eller mer enn et bestemt arkivsystem kan arkivere. Det bør kunne ta imot det som alle Noark 5-arkivsystemer kan arkivere, hvis et system kan registrere organisasjonsnummer, mens et annet system ikke kan registrere organisasjonsnummer, så bør avleveringsfomatet ha plass å putte organisasjonsnummer.

Og hvis et system bare kan ta vare på en personid-verdi koblet til en part, mens et annet system kan ta vare på flere personid-verdier koblet til part, så bør avleveringsformatet ha plass å putte flere personid-verdier.

Jeg har inntrykk av at din tilnærming er at hvis avleveringsformatet støtter noe, så må alle arkivsystemer også støtte det. Mulig det er riktig, men det virker som et litt unødvendig krav for min del.

Tjenestegrensesnittet støtter jo virksomhetsspesifikke metadataverdier, hvilket jeg har inntrykk av at få andre arkivsystemer støtter. Det bør jo være helt greit sett fra Noark 5-spesifikasjonens synsvinkel.

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Noark-formatet bør i størst mulig grad være likt for integrasjoner, brukergrensesnitt og avlevering. Selv om det ikke er noe formelt krav, vil det gjennom innkjøp der hele Noark uten nærmere vurdering stilles som krav, ende opp som et reelt krav at brukergrensesnitt skal støtte avleveringsformatet.

Jeg gjentar spørsmålet om hva som skal gjøres ved elektronisk distribusjon der det finnes flere elektroniske mottageridentifikatorer.

N5WS har aldri tatt av og VSM har i praksis ikke blitt tatt i bruk, dels grunnet for dårlig standardisering av fagområder der VSM hadde vært nyttig (som for eByggesak, ePlansak som kunne benyttet VSM for arkivering og avlevering). Jeg tror det kun er ESA som støtter VSM fullt ut via GeoIntegrasjon (tilleggsinformasjon kan være en blob og da også XML) som er det tjenestesnittet som hovedsakelig benyttes for integrasjoner som ikke er laget for kun én type arkivkjerne.

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Jeg gjentar spørsmålet om hva som skal gjøres ved elektronisk distribusjon der det finnes flere elektroniske mottageridentifikatorer.

Det vi snakker om her er vel flere personidentifikatorer i arkivet, som antagelig kan tolkes som mottageridentifikatorer, men slik jeg ser hvordan det skal håndteres som mottageridentifikator et tolkningsspørsmål for de som skal sende ut basert på informasjon i arkivet, ikke egenskaper med identifikatorene.

Hvis en person registrert som part har tilknyttet sin oppføring både dnummer, fødselsnummer, passnummer og USAs social security number, for å nevne en håndfull som eksempler, så ville vel jeg sett hva utsendingssystemet støtter og foretrekker. Eller tenkte du at en partsperson ville ha flere unike fødselsnummer registrert? Det har ikke falt meg inn, da de færreste har flere slike. Slik jeg har forstått feltets beskrivelse er det snakk om ID som identifiserer parten, og det er jo bare en part, så det bør jo da være forskjellige ID-er som identifiserer samme part.

Det bruksområdet jeg tenker mest på er søk, der en bør kunne søke på både d-nummer og passnummer (der det er aktuelt) og finne poster der personer med aktuelt nummer er part. Tilsvarende for dokumenter og saker.

-- Vennlig hilsen Petter Reinholdtsen

sturtzel commented 3 years ago

Det var snakk om korrespondansepart også? Alltid farlig med diskusjoner som endrer seg over tid og har lang hale. Med korrespondansepart har vi objektet som sendes til f.eks. eFormidling eller SvarUt, kanskje også med flere adressater slik at mottager kan sende svar til alle.

For søk vil det antagelig være behov for tjenester som kobler nåværende og tidligere identifikatorer (om man vil få tilslag på alle "mine"). En tidligere sak kan ha annen ID enn en ny sak selv om det er snakk om samme person.

petterreinholdtsen commented 3 years ago

[Ragnar Sturtzel]

Det var snakk om korrespondansepart også?

Se komplett liste over nasjonale identifikatorer støttet av tjenestegrensesnittet i melding datert 2021-03-23 15:38+01:00.

Merk, jeg ser jeg ved en inkurie skrev "i tillegg kan Enhetsidentifikator knyttes null eller flere ganger til PartEnhet (spesialisering av Part) og KorrespondansePartEnhet (spesialisering av KorrespondansePart)", og innser at det kanskje var her forvirringen dukket opp. Det korrekte som jeg mente å skrive er "null eller en gang", ikke "null eller flere ganger", for enhetsidentifikator. Beklager skrivefeilen.

-- Vennlig hilsen Petter Reinholdtsen