Strukturen i avleveringen

[sturtzel]

Nivåene Klassifikasjonssystem og Klasse bør utgå fra avleveringen / strukturen. Disse er elementer for fysisk klassifikasjon og er mindre egnet som hierarkiske elementer i et elektronisk arkiv.

Klassifikasjonssystem bør inn som attributt i Arkivdel for å angi primært klassifikasjonsprinsipp. Elementet bør være 0-1.

Klasse bør erstatte sekundær klassifikasjon i Mappe og være 0-n. SystemID bør da utgå mens Klassifikasjonssystem bør inkluderes (navngitt da klassifikasjonen inkluderer andre systemer enn de som ligger som primært prinsipp i Arkivdel). Dagens måte å håndtere sekundær klassifikasjon strider med det hierarkiske prinsippet ved at alle benyttede klassifikasjonssystemer og klasser må legges inn under Arkivdel for at referansen med systemID skal ha noen mening.

[petterreinholdtsen]

@sturtzel Hva mener du med "Disse er elementer for fysisk klassifikasjon og er mindre egnet som hierarkiske elementer i et elektronisk arkiv"? Det er jo vesentlig for gjenfinning og dermed veldig nyttig å klassifisere også informasjon i et elektronisk arkiv. Hvorfor tenker du det er mindre egnet?

Når du sier at "Klasse bør erstatte sekundær klassifikasjon i Mappe", hvilket felt snakker du om da? saksmappe.referanseSekundaerKlassifikasjon er i følge tillegg B klasse.systemID, dvs. skal henvise til en klasse allerede, så jeg antar du snakker om et annet felt som jeg ikke forstår hvor befinner seg i spesifikasjon og XSD. Mulig det blir enklere hvis du forklarer hvor i spesifikasjon og XSD du foreslår endringer.

[sturtzel]

Ja, Klasse er nyttig for klassifikasjon, men ikke nødvendigvis som en del av et hierarki.

Min erfaring er at spesielt i kommunal sektor er det en del arkiver organisert som objektarkiver. Primær klassifikasjon er da oftest matrikkelnummer, fødselsnummer og ansattnummer. Ofte er det i tillegg en eller flere arkivkoder som kan angi prosess eller emne. K-kodene er mer emne og kan f.eks. angi at dette er en byggesak. Med K-kodene er det ofte både fellesklasse og fagklasse.

Det er unaturlig at de siste er lagt inn i hierarkiet da de ikke vil ha noen mapper ordnet under seg og da klassifikasjonssystemet ikke stemmer med den klassifikasjonen som benyttes for arkivdelen. Men det må de hvis referansen via referanseSekundaerKlassifikasjon skal ha noen verdi. En systemID som ikke inngår i avleveringen sier jo ingenting.

Det er derfor mer naturlig, mer brukervennlig og mer hensiktsmessig at klassifikasjonen ligger som et tilleggsattributt til mappene i stedet for en del av et hierarki. Enten er første forekomst primærklassifikasjonen eller så kan man angi rekkefølge som et attributt.

[petterreinholdtsen]

[Ragnar Sturtzel]

Ja, Klasse er nyttig for klassifikasjon, men ikke nødvendigvis som en del av et hierarki.

Min erfaring er at spesielt i kommunal sektor er det en del arkiver organisert som objektarkiver. Primær klassifikasjon er da oftest matrikkelnummer, fødselsnummer og ansattnummer. Ofte er det i tillegg en eller flere arkivkoder som kan angi prosess eller emne. K-kodene er mer emne og kan f.eks. angi at dette er en byggesak. Med K-kodene er det ofte både fellesklasse og fagklasse.

Kan du forklare dette nærmere? Det du beskriver, arkiver organisert som objektarkiver, er vel arkiver der hovedhierarki (med ett nivå) er klassifikasjonstype (M086) er gårds- og bruksnummer, fødselsnummer og ansattnummer, mens eventuelle K-koder er sekundærklassifikasjon. Slik organisering utgjør jo et hierarki like godt som arkiver organisert etter K-koder, og bør la seg representere helt utmerket i uttrekks-XML.

Det er unaturlig at de siste er lagt inn i hierarkiet da de ikke vil ha noen mapper ordnet under seg og da klassifikasjonssystemet ikke stemmer med den klassifikasjonen som benyttes for arkivdelen. Men det må de hvis referansen via referanseSekundaerKlassifikasjon skal ha noen verdi. En systemID som ikke inngår i avleveringen sier jo ingenting.

XSD tillater registrering rett under klasse, så dette bør la seg representere med dagens XSD. Forøvrig enig i at enhver systemID oppgitt referanseSekundaerKlassifikasjon trenger sin tilhørende klasse i XML-en. Dette løses vel enklest ved å ta med flere klassifikasjonssystem i XML-en for hvert arkiv / hver arkiv del, der kun et av dem har mapper og registreringer og mapper under seg.

Det er derfor mer naturlig, mer brukervennlig og mer hensiktsmessig at klassifikasjonen ligger som et tilleggsattributt til mappene i stedet for en del av et hierarki. Enten er første forekomst primærklassifikasjonen eller så kan man angi rekkefølge som et attributt.

Vil ikke dette føre til mye duplisering av informasjon i XML-en, med mulighet for sprik mellom ulike opplistinger av klasser? Kanskje du kan lage et konkret endringsforslag for XSD, slik at det blir enklere å se hva du tenker på her?

-- Vennlig hilsen Petter Reinholdtsen

[sturtzel]

Sekundærklasseringer benyttes som tilleggsinformasjon eller alternativ strukturering på linje med parter. Reelt er mappene ordnet i en flerdimensjonal matrise der arkivdel/periode er en av strukturene, klassene et annet sett, mens f.eks. parter kan være nok et sett.

Med krav til unike systemID-er og klasser som ordning på tvers at arkivdeler passer de ikke inn i et hierarki. Selv om det blir duplisering av informasjon er det bedre å ha kassene som tillegg til mappene på lik linje med parter.

Forslaget er at klassifikasjonssystem og klasse fjernes fra hierarkiet og erstatter referanseSekundaerKlassifikasjon. Hvor mange felt som skal tas med er vi åpne for. Type klassifikasjon, klasseID, beskrivelse og evt. skjerming er mest naturlig. Merk at skjerming av klasse vil være pr. mappe.

[palm72]

Duplisering av informasjon rundt klassering er allerede en utfordring. Vi har mottatt arkivuttrekk bestående av svært mange arkivdeler (120 i samme uttrekk). Mange av disse hadde de samme klassifikasjonssystemene definert.

Uttrekket var gjort i versjon 3.1, men hadde hadde unike systemIDer for hvert klassifikasjonssystem og klasse - selv om det i prinsippet var det samme klassifikasjonssystemet som ble repetert i uttrekket. Det ble benyttet både K-koder (fordelt på klassifikasjonssystemene "Fellesklasser", "Fagklasser" og "Tilleggsklasser") og enkelte objektbaserte klassifikasjonssystemer.

Samtidig ønsker vi å motta beskrivelse av sekundærklassene som er benyttet i uttrekket. Selv om K-koder er basert på en nasjonal standard, er det noe rom for tilpassinger. Vi ønsker ikke å miste informasjon om disse tilpassingene - som definisjon av nye klasser. Vi opplever også at det i noen arkivdeler er benyttet K-koder som primær klassifikasjon - mens objektklasser (person eller eiendom) er lagt til som sekundærklassering. Dette er definitivt viktig informasjon å bevare.

Jeg har lyst til å foreslå andre endringer enn det Sturtzel her foreslår. Her er to alternativer: 1) Klassifikasjon og arkivdeler leveres som hver sin del av arkivuttrekket ved at klassifikasjonssystem trekkes ut fra arkivdel og blir lagt direkte under arkiv - sidestilt med arkivdel. Hvert unike klassifikasjonssystem defineres og beskrives. Mapper og/eller registreringer inneholder referanse til systemID for klassene som er benyttet (tilsvarende dagens referanseSekundaerKlassifikasjon, men nå også til primær klasse). Dette gjør klassering mindre visuelt tilgjengelig enn i dag, men reduserer redundansen i uttrekket. Det fordrer imidlertid kontroll på at klassene er med i uttrekket.

2) Klassifikasjon defineres innenfor hver arkivdel - og samtlige klassifikasjonssystemer og klasser som brukes i arkivdelen beskrives i den enkelte arkivdel - slik de fleste leverandørene leverer uttrekkene i dag. Dette medfører at referanseSekundaerKlassifikasjon kan referere til klasseID istedenfor systemID for klasse - siden klasseID vil være unik innenfor arkivdel. Dette vil gi bedre lesbarhet og like god lenkbarhet sammenlignet med bruk av systemID. Ulempen med denne metoden er at vi får redundans når flere arkivdeler benytter samme klassifikasjonssystem. SystemID for klassifikasjonssystem og klasse bør være tillatt repetert innenfor arkivuttrekket så lenge det er snakk om samme klassifikasjonssystem.

[sturtzel]

Jeg synes forslaget til @palm72 er godt. Enda bedre blir det ved å kombinere 1 og 2, legge all info om klassifikasjonen under arkiv, men bruke klasseID i referansene (fordrer unik klasseID). Da får man god lesbarhet, ingen duplikasjon av klassifikasjonssystemene og helt greie referanser. Alternativt kan label med klassifikasjonssystem og klasse benyttes på referansene slik at man får med både systemID og klasseID uten at klasseID må være unik på tvers av klassifikasjonssystemer (kan skje at n objektkode har samme verdi, men er forskjellig objekt i forskjellige klassifikasjonssystemer): <systemID label="FE-000">c945a82c-908b-4829-86ed-c707088a5b00</systemID>

[hanber]

Jeg tror det er stor enighet om at klassehierarkiet (det er ofte minst ett hierarkisk klassifikasjonssystem) bør tas ut av aggregeringshierarkiet, slik at mappe henger rett under arkivdel, og at mappene har minst én referanse til klasse. Jeg synes den naturlige plasseringen av klassifikasjonssystem fremdeles er arkivdelen, bl.a. for å sikre at det gjeldende klassifikasjonssystemet blir avlevert sammen med mappene. Ellers må vi ha en annen måte å håndtere endringer i klassifikasjonssystem på for å sikre at riktig klassifikasjonssystem blir avlevert sammen med arkivdelen. Jeg forutsetter at det fremdeles skal være et krav om at det må opprettes en ny arkivdel når det skiftes klassifikasjonssystem. Da får vi en arkivdel som inneholder to hoveddeler - én for klassifikasjon og én for aggregering. En mappe vil dermed ikke være en del av klasse, som i dagens xml-skjema, men referanse til klassen må være en egenskap (av typen systemID).

I dagens struktur må alle mapper tilhøre en klasse i "primærklassifikasjonssystemet", mens ikke alle mapper må ha en sekuundærklassifikasjon. Ved å skille ut klassifikasjonssystemet (og klassene) blir dette ikke lenger en strukturell nødvendighet, og må dermed sikres på andre måter. Da det i prinsippet ikke er noen rekkefølge mellom klassifikasjonssystemene bør vi ikke legge på regler som at det "første" er primærklassifikasjonssystemet, de "etterfølgende" er sekundær, tertiær osv. Jeg mener det bør ivaretas ved et obligatorisk metadataelement "referansePrimaerklasse [1..1]" i tillegg til "referanseSekundaerklasse" [0..*]. Ved å benytte systemID som identifikator på klassene, er det for så vidt også mulig å flytte klassifikasjonssystemet ut av arkivdelen, men da blir arkivdelen mindre "self contained", som så vidt jeg forstår det er et poeng med arkivdelen. Når en arkivdel svarer til en arkivperiode er det naturlig at ett uttrekk svarer til en arkivdel, som igjen naturlig vil være en arkivpakke i depot (OAIS' AIP). Det forhindrer likevel ikke at man skal kunne referere på tvers av avleveringsuttrekk ved hjelp av systemID.

Når vi først er i gang: Hvordan håndteres objektbaserte klassifikasjoner i dagens løsninger? Hvis man f.eks. har et klassifikasjonssystem basert på personnummer, opprettes en ny klasse hver gang man støter på et nytt personnummer?

[sturtzel]

Samme klassifikasjonssystem benyttes ofte for flere arkivdeler. F.eks. vil man ikke innføre ny klassifikasjon bare fordi man går inn i en ny arkivperiode. Klassifikasjonssystemet / systemene kunne derfor vært avlevert som et obligatorisk tillegg på linje med journalrapportene og endringsloggen.

Primær/sekundær: Evt. gjøre som i Noark 4 og ha et rekkefølgenummer der primær har rekkefølgenummeret 1. Da vil det være et antall objekter med referanseKlassifikasjon.

Objektbasert klassifikasjon håndteres litt forskjellig mellom systemene. Men normalt vil nytt objekt automatisk gi ny klasse. Objektbasert klassifikasjon som bruker nasjonale identifikatorer (fødselsnummer, organisasjonsnummer, matrikkelnummer) vil normalt deles mellom flere arkivdeler (samme objekt, men i annen sammenheng). Fødselsnummer som klassifikasjonssystem vil normalt inkludere D-nummer da begge peker på mennesker og ikke har overlappende verdier.

Lesbarheten til XML-filene ville vært langt bedre hvis referansene var tagget slik at man så ikke bare systemID, men også klasseID og evt. også klassetittel. Det gjelder generelt etter innføringen av UID som systemID.

[hanber]

Label eller ikke på systemID

ID er definert i XML-skjemaet metadatakatalog.xsd som metadataelement M016. Det er ennå ikke definert i metadatakatalog-standarden. Jeg forstår det slik at ID (M016) slik den er definert i metadatakatalog.xsd er innført først og fremst for å påtvinge standardformatet for skriving av UUID-er.

Jeg foreslår å ta M016 inn i dokumentasjonen, men vil heller kalle det UUID, siden det er det vi mener.

systemID er utvidet i XML-skjemaet med label i tillegg til ID. Det er heller ikke definert i metadatakatalog-standarden. Jeg ser poenget med lesbarhet av systemID-ene, og det er vel en god grunn til at det allerede er tatt med i XML-skjemaet. Jeg har to kommentarer til det, den ene er at vi har vært nøye på å benytte norsk i standarden, så jeg synes vi burde kalle det noe annet, gjerne noe som indikerer at det skal være lesbart. Label finnes ikke i språkrådet/UiB sine ordbøker, og i Det Norske Akademis ordbok er det bare brukt om plateselskap.

Jeg foreslår at vi kaller det merkelapp inntil noen kommer med et bedre forslag. Siden vi ønsker merkelapp på alle referansene til systemID, må vi erstatte ID med systemID i alle "restriction base" i metadatakatalog.xsd.

Den andre er at systemID blir det eneste metadataelementet som er "complex type", hvilket vi ikke har noe standard oppsett for i metadatakatalog-standarden. Bør merkelapp ha sin egen oppføring i metadatakatalogen, altså et Mxxx-nummer? ID har fått et nummer i metadatakatalogen, hvilket taler for at også merkelapp får det. Alternativt kan vi skrive det inn i "betingelser" for systemID på samme måte som vil har lagt inn verdilister i metadataelementene med forhådsdefinerte verdier (kodelister).

Jeg foreslår at vi innfører merkelapp, inntil noen foreslår et bedre navn, som et eget metadataelement i matadatakatalogen som nr M017 for å vise at det har en sammenheng med identifikatorene.

For øvrig synes jeg beskrivelsene i metadatakatalogene burde vært XML-elementer i metadatakatalog.xsd slik at vi bare hadde metadatabeskrivelsene ett sted - selv om @petterreinholdtsen har gjort en stor jobb med å få opprettet yaml-filene som inneholder metadata-beskrivelsene i dag, og som metadatakatalogen genereres ut fra.

Klassifikasjon utenfor arkivdelen

Som flere har påpekt, er det gode argumenter for å holde klassifikasjonssystem utenfor arkivdelen.

Jeg foreslår at vi flytter klassifikasjonssystem til arkiv, med assosiasjon fra arkiv til klassifikasjonssystem med multiplisitet [0..*]. Samtidig definerer et nytt metadataelement M231 referansePrimaerKlassifikasjon, som er referanse til primærklassifikasjonssystemet, og beholder referanseSekundaerKlassifikasjon som referanser til øvrige klassifikasjonssystemer. Så får vi bli enige om hvordan klassifikasjonssystemet med underliggende klasser skal avleveres, @joergen-vs, @geihau@arkivverket.no og @TerjePD

Er denne endringen for inngripende til å bli med i versjon 5.1 @monadani, @AnnKnu, @oivkru@arkivverket.no, @TerjePD, @geihau@arkivverket.no og @joergen-vs?

[sturtzel]

Dette berører kun avleveringen og burde derfor være kurant.

Kommentar til XSD-en: Hvis det legges for mye tekst inn i denne vil datamodellen drukne for oss som også leser denne direkte. Full dokumentasjon av objektene ligger jo også i PDF-en.