Open joergen-vs opened 1 year ago
[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
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".
Dokumentet direkte i løsningen, ikke binært.
[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:
I dokumenter/faginfo.xml:
<?xml version="1.0" encoding="UTF-8"?>
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
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).
[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
Jeg mistenker jeg misforstår noe, for jeg ser ikke helt hva som er den
store fordelen med å bruke
Det er verdt å merke seg at Noark 5-spesifikkasjonen i 2021 med innsjekk
av <URL: https://github.com/arkivverket/noark5-standard/pull/100 > fikk
støtte for virksomhetsspesifikkeMetadata i dokumentobjekt. En kan
dermed legge inn feltene du fører opp under
-- Vennlig hilsen Petter Reinholdtsen
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>
Her er kilde filene til eksempelet over:
github tilater ikke opplasting av XML/XSD, derfor fikk de .txt filendelse.
Forslag til metadataelement
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.