[Bitrepository-devel] opsplitning af collection

[Mikis Seth Sørensen]

Her Jun's input som det ikke er lykkes ham at sende på maillisten endnu:

Kære alle

I princippet er audit er offline medier ikke anderledes end online medier.
Alle operationer logges som person+objekt+tidspunkt+handling tuples ned i persistent storage, f.eks en database.
Så på audit siden betyder det, at vi skal kunne håndtere at objekter skifter navn, uden at bryde audit trailen. Det skal vi vel alle sammen.

Den store forskel til off-line medier er, at vi meget, meget nødigt genskriver et medie (en fysisk DVD/Tape) medmindre det er fordi mediet er ved at være kaput.
Dette medfører, at vi aldrig ændrer navn på arkivalier. Til nød laver vi nye udgaver i stedet.
Så en delete/re-ingest er en meget ubekvem løsning for os.

Vi har en tilsvarende problemstilling i vores navngivning af arkivalier, men så længe navnet er unikt ved ingest, så er det godt nok, for navne ændrer sig ikke. Dette medfører (teoretisk set), at selv om et arkivalie skulle flytte fra et arkiv til et andet, så beholder det det oprindelige CollectionID i sit navn. Derfor indgår collectionID eksplicit i filnavnet.
En flytning hos os er derfor ikke en navneændring men alene en operation, hvor en fil flytter fra et ”credentialscope” til et andet.
Omvendt: Så længe CollectionID indgår i det unikke navn, så er enhver flytning en navneændrings operation.

Ud over det ovenstående, kan jeg her og nu se to andre mulige løsninger:
1) Den hurtige: Forbyde alle navneændringer.
2) Den besværlige: Dvs. arbejde med interne navne som aldrig ændrer sig.
Brugerens navne på filer ”oversættes” til interne navne via en database. Umiddelbart giver dette lidt mere kompleksitet, men det er da til at leve med. En anden konsekvens er dog, at vi ikke kan genskabes en totalhavareret database ved at læse alle DVD’er igennem. Løsningen på det sidste er, at tilføje det der vist hedder en AIP i OAIS til filen ved lagring. AIP’en skal blot indeholde tilstrækkelige informationer til at genskabe de oprindelige eksterne navne. Sammen med en log, kan en database genetableres.

Det sidste er lidt besværligt. Jeg vil da langt foretrække at CollectionID indgår i filnavnet.

Mvh Jun

From: Christian Vandel <CSV at kb.dk<mailto:CSV at kb.dk>>
Reply-To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Date: Thu, 23 Jun 2011 17:24:43 +0200
To: List for the Bitrepositorys developers <bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>>
Subject: Re: [Bitrepository-devel] opsplitning af collection

Jeg ville nok foretrække at re-ingeste og dernæst slette :)

Jeg har et bud:
Vi opfinder en speciel operation, som involverer trust til både det gamle og det ny collectionID. Noget i retning af en 2-fase-ting, hvor man først med det gamle collectionID markerer at filen må flyttes til det nye collectionID og dernæst med det nye collectionID gennemfører/committer handlingen. Audit skal så følge filen… Det forudsætter selvfølgelig at filnavnet er globalt unikt – eller i hvert fald ikke kolliderer med den nye collection.

Hvordan håndteres Audit i forbindelse med offline-medier?

/Christian


Fra: bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org> [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Eld Zierau
Sendt: 23. juni 2011 16:25
Til: List for the Bitrepositorys developers
Emne: Re: [Bitrepository-devel] opsplitning af collection

Blot en tilføjelse – ønske kan også begrundes i opsplitning af hvem der skal have rettigheder på grund af f.eks. organisatoriske forandringer.

Mvh. Eld

Fra: bitrepository-devel-bounces at ml.sbforge.org<mailto:bitrepository-devel-bounces at ml.sbforge.org> [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Eld Zierau
Sendt: 23. juni 2011 12:04
Til: bitrepository-devel at ml.sbforge.org<mailto:bitrepository-devel at ml.sbforge.org>
Emne: [Bitrepository-devel] opsplitning af collection

Hej

Det er gået op for mig at vi nok har et par krav, som ikke er dækket af vores beskrivelser indtil nu, - og som kan have grundlæggende betydning.

Casen er at en institution starter med at ligge sit digitale materiale ind i en bit repository collection og senere finder ud af at der er dele af collection som skal sikres bedre. Dvs. institutionen ønsker i stedet at dele collection op i 2 dele, hvor eneste forskel er at den ene del skal have en ekstra kopi.
Jeg går her ud fra at man som kunde har sikret at alle id’er er unikke uafhængigt af de collections som kunden har.
Jeg er temmelig sikker på at det ikke er acceptabelt svar at filer kun kan flyttes ved:

·         Slette og re-ingeste (totalt ulogisk for institution – audit trail bliver brudt – potentiel risiko for at miste data …)

·         Give alle data i collection større sikkerhed (bliver dyrt)

Jeg kan være nervøs for at dette er noget grundlæggende idet BR’en ser en unik id som collection+id, mens kunden ikke lægger samme semantik i en collection.

Mvh. Eld

[cid:image001.jpg at 01CC31C4.E970B310]

Det Kongelige Bibliotek
Nationalbibliotek og Københavns Universitetsbibliotek

Eld Zierau
IT-konsulent | Digital Preservation Specialist

Det Kongelige Bibliotek | The Royal Library
Afdelingen for Digital Bevaring | Digital Preservation
P.O. Box 2149 | DK-1016 København K
tel +45 3347 4690 | Fax +45 3393 2218 | elzi at kb.dk<mailto:elzi at kb.dk> | www.kb.dk<http://www.kb.dk>

Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1
Leveringsadresse | Delivery address | Christians Brygge 8 | 1219 København K

EAN 5798 000 79 52 97 | Bank 0216 4069032583 | CVR 28 98 88 42
IBAN DK2002164069032583 | Swiftcode DABADKKK


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20110628/e7df25e1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14433 bytes
Desc: image001.jpg
URL: <http://ml.sbforge.org/pipermail/bitrepository-devel/attachments/20110628/e7df25e1/attachment-0001.jpg>