Endring av dokumentobjekt for å ta vare på grunnlagsdata

[joergen-vs]

---

       Prosjekt  Noark 5 standard
       Kategori  Noark 5.5.0
Brukerreferanse  jorvik@arkivverket.no

---

Forslag til metadataelement

Egenskap	Beskrivelse
Navn	dokumentobjekt
Definisjon	Dokumentobjekt er det laveste metadatanivået i arkivstrukturen. Et dokumentobjekt skal enten referere til én og kun en dokumentfil, eller inneholde de grunndata som gjør opp et dokument.

Hvis det er av interesse å ta vare på mer spesialisert dokumentasjon, og ikke måtte produsere dokumentfiler for arkivering, vil en slik åpning bl.a. gjøre det enklere for fagsystem som ønsker å drive arkivering.

[petterreinholdtsen]

[Jørgen]

| Egenskap | Beskrivelse | |----------|-------------| | Navn | dokumentobjekt | | Definisjon | Dokumentobjekt er det laveste metadatanivået i arkivstrukturen. Et dokumentobjekt skal _enten_ referere til én og kun en dokumentfil, _eller inneholde de grunndata som gjør opp et dokument_. | Hvis det er av interesse å ta vare på mer spesialisert dokumentasjon, og ikke måtte produsere dokumentfiler for arkivering, vil en slik åpning bl.a. gjøre det enklere for fagsystem som ønsker å drive arkivering.

Kan du forklare litt nærmere? Jeg forstår ikke hvordan dette er forskjellig fra dagens dokumentobjekt. Hva mener du med 'mer spesialisert dokumentasjon' og 'produsere dokumentfiler for arkivering'? Et dokumentobjekt er jo bare en bitstrøm som kan lagres.

…

-- Vennlig hilsen Petter Reinholdtsen

[joergen-vs]

En hendelse i et fagsystem utløser saksbehandling, som "Varsel fra tidevaluering. 31.12.23 01 Medarbeideren er ikke til stede".

Mottatt pdf har tittel "Varsel fra tidevaluering", og kan ha flere betydninger. Så forståelsen er låst til innholdet av pdf-en. Og før mottaker i det hele tatt åpner dokumentet, blir økonomi kontaktet for "mer informasjon". Og det de som kan gå inn på saken kan gjøre for å hente mer informasjon om saken, er

1. åpne sendt pdf
2. bruke fagsystemet og lete etter informasjon om aktuelle person

Hvis første dokumenterte arkivnotat (e.l.) på saken var informasjonen fra fagsystemet som utløste saken [person, dato for hendelse, avviksmelding], og informasjonen lå tilgjengelig som data og metadata direkte på saken, trenger man ikke lage et eget dokument med informasjonen, eller "se fagsystem for mer informasjon".

b67f8d5c-47ac-42fa-ab7e-f2d2196a39b5 1 Strukturert informasjon xml 2024-01-01T09:05:35 Fagsystem 1 Person A 2023-12-31 Medarbeideren er ikke til stede

Dokumentet direkte i løsningen, ikke binært.

[petterreinholdtsen]

[Jørgen]

Hvis første dokumenterte arkivnotat (e.l.) på saken var informasjonen fra fagsystemet som utløste saken [person, dato for hendelse, avviksmelding], og informasjonen lå tilgjengelig som data og metadata direkte på saken, trenger man ikke lage et eget dokument med informasjonen, eller "se fagsystem for mer informasjon".

Jeg forstår. Mistenker det er en ulempe for sletting og kassering om informasjonen er innbakt i databasen og ikke i en separat fil, men har ikke klart for meg hvor mye av "meta"-data det er greit å slette fra databasen ved sletting og kassering. Det er verdt a merke seg at det er fullt mulig å lagre det du foreslår tilsvarende med dagens struktur, ved å legge ekstrainformasjonen i en ekstern fil, dvs. noe ala dette: I arkivstruktur.xml: <dokumentobjekt > <systemID label="dokumentobjekt-1234-1-FS">b67f8d5c-47ac-42fa-ab7e-f2d2196a39b5</systemID> <versjonsnummer>1</versjonsnummer> <variantformat>Arkivformat</variantformat> <format>fmt/1189</format> <opprettetDato>2024-01-01T09:05:35</opprettetDato> <opprettetAv>Fagsystem</opprettetAv> <referanseDokumentfil>dokumenter/faginfo.xml</referanseDokumentfil> </dokumentobjekt> I dokumenter/faginfo.xml: <?xml version="1.0" encoding="UTF-8"?> <dokument xmlns:fs="fagsystem/hendelse"> <fs:hendelse> <fs:nummerrekkefølge>1</fs:nummerrekkefølge> <fs:mottaker>Person A</fs:mottaker> <fs:dato>2023-12-31</fs:dato> <fs:avvik>Medarbeideren er ikke til stede</fs:avvik> </fs:hendelse> </dokument>

Dokumentet direkte i løsningen, ikke binært.

Samme informasjon kan legges inn i dag. Det er opp til brukergrensesnittet hvordan dette presenteres. En trenger ikke gå den meningsløse veien om PDF.

…

-- Vennlig hilsen Petter Reinholdtsen

[joergen-vs]

Sett fra et sak/arkivsystem som driver saksbehandling. Men i et fagsystem vil "dokumentet" kanskje gjengis i et webgrensesnitt, som datagrunnlag for et skjema. Der vil en noark-kjerne være for streng til å fange opp innebygde loggdata (med mindre de lagres som vsmd).

Samtidig som arkivlova legger til rette for denne typen "logisk avgrensa informasjonsmengder", og man burde kunne fange dokument som ikke er begrenset til fil-begrensninger (IO-operasjoner, format, tilgjengelighet).

[petterreinholdtsen]

[Jørgen]

Sett fra et sak/arkivsystem som driver saksbehandling. Men i et fagsystem vil "dokumentet" kanskje gjengis i et webgrensesnitt, som datagrunnlag for et skjema. Der vil en noark-kjerne være for streng til å fange opp innebygde loggdata (med mindre de lagres som vsmd).

Hvilken begrensing i spesifikasjonen er det du snakker om når du skriver "der vil en noark-kjerne være for streng til å fange opp innebygde loggdata"? Dette høres ut som en begresning i konkrete implementasjoner og ikke i spesifikasjonen.

Samtidig som arkivlova legger til rette for denne typen "logisk avgrensa informasjonsmengder", og man burde kunne fange dokument som ikke er begrenset til fil-begrensninger (IO-operasjoner, format, tilgjengelighet).

Forstår ikke hva du mener her. Enhver samling informasjon i en datamaskin kan jo lagres som en serie bit i en fil. Hva er 'fil-begresninger'?

…

-- Vennlig hilsen Petter Reinholdtsen

[petterreinholdtsen]

Jeg mistenker jeg misforstår noe, for jeg ser ikke helt hva som er den store fordelen med å bruke <dokument> i stedet for å legge informasjon i separat fil. Det er verdt å merke seg at Noark 5-spesifikkasjonen i 2021 med innsjekk av <URL: #100 > fikk støtte for virksomhetsspesifikkeMetadata i dokumentobjekt. En kan dermed legge inn feltene du fører opp under <dokument> som en blokk under <virksomhetsspesifikkeMetadata> i stedet.

…

-- Vennlig hilsen Petter Reinholdtsen

[tsodring]

Kassasjon opplever jeg som noe som skjer med dokumenter ikke (meta)data i databasen. Dersom det er ønskelig med en arkivstruktur.xml eksempel her:

<virksomhetsspesifikkeMetadata>
  <fs:hendelse>
    <fs:nummerrekkefølge>1</fs:nummerrekkefølge>
    <fs:mottaker>Person A</fs:mottaker>
    <fs:dato>2022-11-09</fs:dato>
    <fs:avvik>Medarbeideren er ikke til stede</fs:avvik>
  </fs:hendelse>
</virksomhetsspesifikkeMetadata>

der rotnoden i arkivstruktur.xml ser slik ut:

<arkiv xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xmlns="http://www.arkivverket.no/standarder/noark5/arkivstruktur" 
            xmlns:n5mdk="http://www.arkivverket.no/standarder/noark5/metadatakatalog" 
            xmlns:fs="https://www.fs-integrasjon.no/hendelse" 
            xsi:schemaLocation="http://www.arkivverket.no/standarder/noark5/arkivstruktur arkivstruktur.xsd https://www.fs-integrasjon.no/hendelse fs_hendelse.xsd">

og XSD ser slik ut:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                     xmlns="https://www.fs-integrasjon.no/hendelse" 
                     xmlns:fs="https://www.fs-integrasjon.no/hendelse" 
                     targetNamespace="https://www.fs-integrasjon.no/hendelse" 
                     elementFormDefault="qualified" version="1.0">
  <xs:element name="hendelse" type="hendelse"/>
  <xs:complexType name="hendelse">
    <xs:sequence>
      <xs:element name="nummerrekkefølge" type="xs:integer"/>
      <xs:element name="mottaker" type="xs:string"/>
      <xs:element name="dato" type="xs:date"/>
      <xs:element name="avvik" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

[tsodring]

Her er kilde filene til eksempelet over:

arkivstruktur.xml.txt

fs_hendelse.xsd.txt

github tilater ikke opplasting av XML/XSD, derfor fikk de .txt filendelse.