-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skal klienter ikke få lov til å sette mappeID ? #113
Comments
Interessant problemstilling, som vi er interessert i løsningsforslag på. For saksmapper i sakarkiv er det en obligatorisk kobling mellom M003 mappeID og M011/M012 (saksaar/sakssekvensenummer). Dvs. at et fagsystem som arkiverer mot en arkivkjerne med saksmapper ikke kan sette mappeID som er bygd opp på andre måter, for oppbyggingen av mappeID er bestemt for saksmapper. Fagsystemet kan godt sette mappeID, men da etter disse reglene. (Om regelen er riktig kan også diskuteres, men det tenker jeg er en egen diskusjon.) For andre arkivstrukturer gjelder ikke dette, og da står man fritt til å la fagsystemet definere mappeID på andre måter. Bakgrunn for spørsmålet, slik jeg tolker det, er at fagsystemets lokale mappeidentifikator må/bør overføres til og tas vare på av arkivkjernen. Spørsmålet er hvordan. Bør mappeidentifikator fra fagsystemet alltid avbildes mot mappeID i en Noark 5 arkivkjerne? Også når dette strider mot reglene for mappeID for saksmappe? (Bør M003 i så fall, eller uansett, være uavhengig av M011 og M012?) Eller kan den overføres som VSMD? Eller som eksternreferanse? |
Jeg tenker at fagsystemet bør overføre attributtet for sin mappe identifikator med et navn som gjenspeiler bruken i fagsystemet. Feks "goodPPT:DOB" (Date of Birth) fordi systemet et utviklet på engelsk i utlandet. VSM kan brukes til å fange opp attributtet og verdien. Forskning (ikke spør meg etter referanse nå) sier at brukere ofte søker etter informasjon men nøkkelverdier som feks saksnummer. Dato, nøkkelord og tittel er vel også brukt. Så det gir mening at et fagsystem vil sette en verdi i et felt det er naturlig å søke i, og det er mappeID. mappeID er i en vanskelig situasjon. Det skal brukes på en streng måte for sakarkiv, men i andre sammenheng kan den brukes litt mer fleksibel. La oss ta en case. Fagsystemet sender over en PPT mappe som skal bli til en saksmappe. PPT mappen bruker objektbasert klassifikasjon med fødselsnummer. PPT systemet da har en mappe identifikator som er feks "010205121234". Så kan arkivkjernen velge flere måter å registrere dette på.
Alle tre tilnærminger er riktig. Noe av det viktigste er at det mulig å finne fram til denne mappen senere. VSM i utgangpunktet oppleves ikke som en god identifikator for gjenfinning. Det vil være vanskelig å huske attributt navnnet. Jeg er også usikker på hvor utbredt nasjonale identifikatorer er, men det er et godt felt å søke i. Det vil også være lett å søke etter personen som en klasse. I depot perspektiv er det kanskje viktig at identifikatoren er brukt i mappeID, da dette kan bli en viktig felt å søke i. Kanskje løsningen er at det er veldig case avhengig. For noen mappetyper skal verdien i mappeID settes kun av arkivkjernen, mens i andre tilfeller kan fagsystemet gjøre det. Utfordringen i dag er at standarden sier at fagsystemet ikke har lov til å sette verdien. I praksis kan vi komme rundt denne tolkningen der arkivkjernen setter en verdi i mappeID fra en annen attributt. Altså, dersom arkivkjernen ser at det kommer inn en mappe med en nyttelast {"goodPPT:DOB":"010205121234"} så kan arkivkjernen være konfigurert til å kopiere nummeret inn i mappeID feltet. Senere hvis mappen gjøres om til en saksmappe vil verdien i mappeID som var "010205121234" nå bli noe som "2021/00234". Forhåpentligvis vil endringsloggen fange dette, men det holder ikke. Jeg har ikke en svar akkurat nå, men det er nok noe det går an å tenke litt mer på. Kanskje noen andre har tanker. |
[Thomas Sødring]
La oss ta en case. Fagsystemet sender over en PPT mappe som skal bli
til en saksmappe. PPT mappen bruker objektbasert klassifikasjon med
fødselsnummer. PPT systemet da har en mappe identifikator som er feks
"010205121234". Så kan arkivkjernen velge flere måter å registrere
dette på.
1. nasjonale identifikator / fødselsnummer
2. legge til VSM attributt "goodPPT:DOB"
3. legge til en sekundærklasse koblet til en objektbasert
klassifikasjon
Gitt at enhver mappe når som helst kan bli gjort om til saksmappe og
journalført, så er det kanskje lurt å bruke samme struktur på mappeID
for alle typer mapper, dvs. at mappe får samme type mappeID som
saksamappe? Det vil jo være uheldig om fagsystemets ID forsvinner hvis
dens mappe gjøres om til saksmappe, og er et godt argument for at
fagsystemets ID bør plasseres en annen plass enn i mappeID, slik du
skisserer over.
For en klient av Noark 5 Tjenestegrensesnitt ville nok jeg gått for å
plassere det i en VSM-atributt hvis det ikke passet i en a vde nasjonale
identifikatorene, og heller forbedret søk til å gi fritekstsøk i alle
relevante felt og entiteter.
…--
Vennlig hilsen
Petter Reinholdtsen
|
Er det nødvendig at mappeID = saksaar/sakssekvensnummer for sakarkiver? Hvorfor ikke bare la mappeID være vilkårlig, og bruke saksaar og sakssekvensnummer til å identifisere mappene i sakarkivene der det er hensiktsmessig? |
I metadatakatlogen (beskrivelsen i docx format) bør henvisning til feltet saksår/sekvensnummer fjernes. Mappeid er en ny egenskap som kom i N-5. Saksår og sekvensnummer finnes på mapper av typen "saksmappe". Mappeid bør være en fortløpende teller. |
[Steinar Abrahamsen]
I metadatakatlogen (docx) bør henvisning til feltet
saksår/sekvensnummer fjernes. Mappeid er en ny egenskap som kom i
N-5. Saksår og sekvensnummer finnes på mapper av typen "saksmappe".
Mappeid bør være en fortløpende teller.
Hvorfor mener du mappeid bør være en teller, og bør det gjelde over alt?
Selv om du nevner docx, så antar jeg du snakker om beskrivelsen av M003 i
https://github.com/arkivverket/noark5-standard/blob/master/metadata/M003.yaml .
Hva konkret mener du bør formuleres annerledes der?
…--
Vennlig hilsen
Petter Reinholdtsen
|
@petterreinholdtsen Hvis mappeid er en fortløpende teller, kan den brukes som intern id for mapper. Det har i tidligere runder vært tale om å opprette ekstern referanse som et eget objekt. Ekstern referanse skal da inneholde referanse til "mappe" i eksternt system. |
[Steinar Abrahamsen]
Hans Fredrik Berg skrev en kommentar basert på innholdet Noark-5
versjon 5 metadatakatalogen i docx format. Her er mappeid koblet mot
NOARK-4 feltene saksår og sekvensnummer sak.
I og med at Det finnes mange utgaver som flyter rundt, så er det greit å
peke til gjeldende autorativ utgave for Noark 5-standarden, slik at vi
snakker om samme ting og jobber på siste utgave.
Hvis mappeid er en fortløpende teller, kan den brukes som intern id
for mapper.
Det vil en vel også kunne gjøre om den er en UUID, unionen av årstall og
saksnummer eller en hvilken som helst annen unik identifikator. Kjenner
du noen argumenter for å spesifikt gå for fortløpende teller, som ledet
opp til din konklusjon "mappeid bør være en fortløpende teller"?
Merk, jeg er ikke i mot a bruke en sekvensielt økende teller, men vil
helst at det valget gjøres basert på eksplisitte argumenter. Det er
litt uklart hva slags funksjon mappeID fyller som ikke systemID også
fyller, dermed håpet jeg noen med mer erfaring kunne bidra til
opplysning.
Det har i tidligere runder vært tale om å opprette ekstern referanse
som et eget objekt. Ekstern referanse skal da inneholde referanse til
"mappe" i eksternt system.
Diskusjon rundt ekstern referanse kan nøstes opp ved å starte på
#96 og
arkivverket/noark5-tjenestegrensesnitt-standard#184 .
For slike referanser holder det med en unik identifikator.
…--
Vennlig hilsen
Petter Reinholdtsen
|
Vi hadde samme diskusjon i forbindelse med NOARK-5 tjenestesnittet. Hva skal mappeid inneholde? M003 Bør inneholde en verdi som en bruker kan forholde seg til. Foreslår da et heltall. |
I et Noark perspektiv trenger ikke mappeID å inneholde en UUID som et tilleggs-systemID. Det er kanskje der feltet kan gjenbrukes med en integrasjon for et fagsystem at det det er nyttig. Feks kan fagsystemet ha sitt eget mappeidentifikator og man ønsker å gjenbruke den. Kanskje mappe fra fagsystemet skal utvides til en saksmappe og da blir verdien overskrevet av saksaar/sakssekvensnummer. Det at en klient ikke kan sette verdien, kun arkivkjernen har gjort meg skeptisk til hvilken verdi mappeID har. Jeg tror mange brukere liker å søke opp ting i arkivet basert på identifikatorer som saksnummer og dersom saksnummer er noe vi skal fortsette med i framtiden så tror jeg en bruker trenger et attributt å forholde seg til. Når jeg underviser dette i Noark undervisningen er det alltid en "Noark gjør dette på en litt rar måte"-forklaring til at brukergrensesnittet skal vise saksnummer som attributt men når vi ser på metadata eller lager en spørring så bruker vi mappeID. Jeg er usikker om vi får noe igjen for det. To tilnærminger som kan diskuteres:
Selv foretrekker jeg (1) da den vil oppleves litt mer "bakover"-kompatibel i standarden. Jeg tror VSM som dokumentasjons- og gjennfinningsmetodikk er veldig underkommunisert og undervurdert i Noark og da det ikke er noen entydig måte å beskrive (bare i tjenestegrensesnittet) så blir det litt vanskelig å se hvordan VSM kan spille rollen til mappeID. Det er vanskelig for en konseptuell standard som sier noe, men ikke nok om dette til at det er matnyttig.
Jeg tror ikke vi trenger å begrense verdiene til mappeID, men si at det er åpent. Kanskje det kan bli en diskusjon om datatype men da er det kanskje naturlig å bruke en streng Angående:
Jeg er både enig og uenig. I et bevaringsperspektiv er det viktig at feltene saksaar/sakssekvensnummer framkommer som en identifikasjons- og gjennfinningselement. Selv om vi i dag har god forståelse for dette betyr det ikke at i framtiden at man vil skjønne det så jeg tror saksaar/sakssekvensnummer bør være et eget attributt. |
Historikken for mappeid: Referanse fra fagsystem |
systemID skal være unik identifikator på en arkivenhet (og fortrinnsvis globalt unik, etter Noark 5 versjon 5). Da er det alltid den ene, unike arkivenheten det vises til, om man bruker systemID som referanse, samme hvilket arkiv det er i. mappeID er ment å være en mer logisk identifikator, som det er mulig for en bruker (person) å forholde seg til, og referere til når man henvender seg til et offentlig organ. (Jeg har tilleggsopplysninger i min sak ##, eller jeg vil ha innsyn i, osv.) Det er mulig å skrive det eller si det uten at det blir for komplisert. Når man henvender seg til riktig organ, vil man som regel da vise til riktig sak/mappe, siden mappeID som regel vil være unik innenfor organet. For de fleste sakarkiver vil mappeID være en videreføring av saksnummeret fra tidligere Noark-versjoner, på formen saksår/sakssekvensnummer. Men dette er ikke obligatorisk for alle mappetyper, da andre arkiv enn sakarkiv ofte har andre (logiske) oppbygninger av mappeidentifikator Og. saksaar og sakssekvensnummer ble tatt med som obligatorisk for saksmapper, for å videreføre dette, selv om mappeID også er obligatorisk og da vil være et duplikat av disse. Men mappeID for andre arkiver kan altså være hva som helst, og det er ikke noe i veien for at fagsystemet kan sette mappeID i en arkivkjerne. Da slipper man å ha to ulike identifikatorer på samme objekt i hhv. fagsystem og arkivkjerne, og fagsystemets identifikator vil være mer tro mot ønsket om å kjenne registreringens opphav (altså ikke bare registreringen av informasjonsobjektet i arkivkjernen, men det faktiske opphavet i fagsystemet.) |
M003 Mappeid er forklart slik i NOARK tjenestegrensesnittet Siste setning medfører at samme informasjon vil bli duplisert: M011 Saksår og M012 Sekvensnummer sak finnes som egne egenskaper for mappe. Siste setning burde fjernes Hvis "M016 Fagsystem" og "M017 Ekstern nøkkel" skal innføres i NOARK er det disse egenskapene fagsystem skal forholde seg til se #124 |
Hei,
Noen som kan gi innsikt i M003 mappeID feltet. Jeg oppfattet mappeID som et felt et fagsystem kunne bruke for å sette inn sin lokale mappe identifikator. Mens jeg jobbet med mappe->utvid-til-saksmappe så slo det med at utvidelsen ville skrive over mappeID feltet med sakens saksnummer, dersom mappeID hadde en verdi. Jeg ser i metadatakatalogen at det står følgende:
Er det meningen at mappeID ikke skal kunne settes av et fasystem?
The text was updated successfully, but these errors were encountered: