Skal konvertering knyttes til kilde eller mål-dokumentobjekt? #17
Comments
|
Jeg er usikker på hva konvertering skal beskrive. Hovedscenario 1: Det opprettes et nytt dokumentobjekt når en dokumentfil konverteres, som refererer til den konverterte filen ved egenskapen referanseDokument, eventuelt med ulike versjonsnummer. Scenario 1a): En dokumentfil A konverteres til flere nye dokumentfiler B, C, D osv. på ulike tidspunkt, med ulike verktøy eller andre omstendigheter som gjør at samme dokumentfil A konverteres flere ganger. Da må konvertering knyttes til dokumentobjektene B, C, D osv. Da blir det bare én konvertering per dokumentobjekt, og multiplisiteten burde være 0..1. Scenario 1b): En dokumentfil A konverteres til en ny dokumentfil B, som deretter konverteres til en ny dokumentfil C osv. I dette scenariet er også det bare én konvertering per dokumentobjekt, og multiplisiteten burde være 0..1. Også i dette scenariet må konvertering knyttes til dokumentobjektene B, C osv. Hovedscenario 2: Det opprettes ikke noe nytt dokumentobjekt når en dokumentfil konverteres. Siden det bare kan være én dokumentfil per dokumentobjekt, må originalfilen erstattes av den konverterte filen, og vi mister originalfilen. Da vil konvertering være en dokumentasjon på konverteringen, og det vil være behov for flere konverteringer per dokumentobjekt, slik at multiplisiteten må være 0..*. Den gjeldende modellen vil støtte begge hovedscenariene. Jeg vil imidlertid anbefale Hovedscenario 1, hvor originalen og alle de konverterte filene tas vare på ved versjonering av dokumentobjektet, så kan man vurdere hva som eventuelt skal overføres til depot. |
|
Dette var lærerikt. Jeg hadde ikke forestilt meg hovedscenario 2 som en mulighet, gikk ut fra at dokumentobjekt inneholder filsjekksum og jeg hadde det for meg at det sto en eller annen plass at dokumentobjekt ikke skulle endres men erstattes hvis filinnholdet skulle erstattes. For meg gir hovedscenario 1 mest mening, og tror forslaget fra #14 om en attributt referanseKildefil er godt. Er det en offisiel beskrivelse i en eller annen spesifikasjon for bruk av XML-formatet som kan oppdateres med forklaring om hvordan disse konvertering-verdiene skal brukes, slik at alle har en sjanse til å gjøre det på samme vis? |
|
Jeg synes vi skal skjære gjennom og beslutte at det bare kan finnes én konvertering per dokumentobjekt, dvs. multiplisitet 0..1 fra dokumentobjekt til konvertering. Videre skal konvertering knyttes til dokumentobjektet det konverteres til. Ved å innføre konvertertFra som en systemID til dokumentobjektet det konverteres fra, trenger vi verken konvertertFraFormat eller konvertertTilFormat, da disse vil være det samme som dokumentobjekt.format i dokumentobjektene det er konvertert hhv. fra og til. I tillegg kan vi fjerne konvertering.konvertertDato og konvertering.konvertertAv, fordi det vil være det samme som dokumentobjekt.opprettetDato og dokumentobjekt.opprettetAv. Det man kan vurdere er om vi skal ta med konvertertTil som en systemID til objektet det er konvertert til. Jeg synes det er uheldig, fordi man da må oppdatere begge dokumentobjektene ved konvertering og man kan risikere inkonsistens. Med mitt forslag vil objekttypene se slik ut (nye elementer i kursiv): dokumentobjekt konvertering Assosiasjonen fra dokumentobjekt til konvertering har multiplisitet [0..1]. |
|
Har ikke studert forslaget i detalj ennå, men etter en rask
gjennomlesning, så slår det meg at forslaget ser ut til å legge opp til
å enten beholde dokumentobjekt-oppføringer også når underliggende fil
slettes etter konvertering, eller at enp slutter å slette underliggende
fil etter konvertering. Stemmer dette?
Jeg tror jo det er lurt fra et bevaringsperspektiv å ta vare på
originalfilen også etter konvertering, slik at en for hvert dokument har
en "rosettastein" som fremtidens forskere kan bruke til å håndtere
eventuelle feil i konvertering.
Hvis jeg forstår forslaget ditt korrekt, så legger det opp til følgende
struktur ved en konvertering fra P til A:
dokumentbeskrivelse +-> dokumentobjekt A -> konvertering -+
| +---------------------------+
| V
+-> dokumentobjekt P
For to konverteringer fra P til A1 til A2 (for eksempel
docx->pdf->pdf/a):
dokumentbeskrivelse +-> dokumentobjekt A2 -> konvertering -+
| +---------------------------+
| V
+-> dokumentobjekt A1 -> konvertering -+
| +---------------------------+
| V
+-> dokumentobjekt P
Utfordringen jeg lurer på er dermed hva som skjer hvis dokumentobjekt P
og A1 slettes fra arkivet på grunn av at de underliggende filene er
fjernet? For Noark har jeg tidligere antatt en struktur ala dette, uten
referanse fra konvertering tilbake til opprinnelig dokumentobjekt:
dokumentbeskrivelse +-> dokumentobjekt A2 +-> konvertering A1-A2
| +-> konvertering P-A1
+-> dokumentobjekt A1 -> konvertering P-A1
+-> dokumentobjekt P
Her kan dokumentobjekt-oppføringer slettes uten at
konvertering-oppføringer får referanser som ikke lenger peker på noe.
Hvis jeg forstår ditt forslag riktig, så påvirker det hvorvidt
dokumentobjekt-instanser skal slettes, og spørsmålet er om det betyr at
slike ikke lenger skal slettes når tilhørende filinnhold slettes, eller
om det betyr at en skal slutte å slette produksjonsformat men heller
avlevere de sammen med arkivformatet. Jeg tror jeg vil foretrekke det
siste, men det er litt uklart for meg når filer kan og skal slettes i en
dannelseskontekst, dvs. mens dokument er utkast som bruker arkivet som
lager (for å sikre at dokumenter ender opp i arkivet når de er ferdige).
…--
Vennlig hilsen
Petter Reinholdtsen
|
|
Først: Jeg ser at jeg var litt for opphengt i vanen med at referanser alltid har en tekstlig tvilling. Det er selvsagt feil. Vi har ikke bruk for konvertertFra [1..1] (nytt metadataelement av typen Tekststreng), jeg vet ikke hva det skulle inneholde. Det er tilstrekkelig med referanseKonvertertFra [1..1] (nytt metadataelement av typen systemID) som refererer til dokumentobjektet det er konvertert fra. Jeg har forstått det slik at ved kassasjon skal dokumentobjektet også slettes sammen med dokumentfilen. Når dokumentobjektet slettes, slettes også konvertering-objektet. Dermed har vi ingen mulighet til å spore konverterings-kjeder ved kassasjon av dokumentobjekter i kjeden. Nå er disse sporene heller ikke så mye verd dersom filen det konverteres fra er slettet. Jeg tror at den eneste måten å få bevart konverterings-historikken er å ta vare på dokumentobjektet ved kassasjon. |
|
Oppsummert foreslår jeg: 1. konvertering knyttes til dokumentobjektet det konverteres til 2. Det opprettes et nytt metadataelement
3. dokumentobjekt og konvertering endres til (nye elementer i kursiv): dokumentobjekt konvertering konvertertFraFormat og konvertertTilFormat vil være unødvendige, da disse er ivaretatt av elementet format i henholdsvis dokumentobjektet som refereres i referanseKonvertertFra og dokumentobjektet konvertering er knyttet til. Assosiasjonen fra dokumentobjekt til konvertering har multiplisitet [0..1]. 4. dokumentobjekt tas vare på ved kassasjon og avleveres På denne måten kan man spore konverteringskjeder. Ved kassasjon vil da noen dokumentobjekter mangle dokumentfil. Vi kan derfor i disse tilfellene ikke få verifisert sjekksummene tilbake til originalfilen, men vi kan identifisere sekvensen av konverteringer. Hva mener dere om dette, @joergen-vs, @[email protected], @monadan, @AnnKnu og @oivkru? |
I følge XSD for n5v5 så kan et dokumentobjekt inneholde ingen eller flere (aka 0..*) oppføringer av konvertering. Dette gjør det uklart hvordan konvertering skal brukes. Gitt et dokumentobjekt A i produksjonsformat som konverteres til et dokumentobjekt B i arkivformat, skal tilhørende konvertering K knyttes til A eller B? Dokument A kan konverteres flere ganger (f.eks. til dokumentobjekt B, C, D osv), men et gitt dokument B kan kun være resultat av en enkelt konvertering.
XSD indikerer at det kan være potensielt uendelig mange konvertering knyttet til et gitt dokumentobjekt, hvilket taler for at slike konvertering-oppføringer skal kobles til dokumentobjekt A i eksemplet over. Men det virker mer fornuftig å knytte konvertering-oppføringen til resultatet av konverteringen, dokumentobjekt B i eksemplet over.
Er det beskrevet noe sted hvilket dokumentobjekt i en slik konverteringsprosess en gitt konvertering-oppføring skal knyttes til? Jeg har ikke klart å finne det. Kan noen avklare om det er dokumentobjekt det konverteres fra eller til som skal ha konvertering-oppføringen?
Eventuelt er det feil multiplisitet på konvertering i XSD-en, og det skulle vært 0..1? Hvis 0..* er riktig og konvertering skal være knyttet til resultatet av konverteringen, kan noen forklare hva det er ment å bety?
The text was updated successfully, but these errors were encountered: