[Bitrepository-devel] opsplitning af collection

[Eld Zierau]

Det var det svar jeg frygtede

Uanset hvordan det gøres, så er en operation direkte på data en risiko for data, og dette er efter min faste overbevisning ikke acceptabelt i forbindelse med ændringer af hvem der må tilgå data.

Jeg tror vi er kommet til at få to begreber ind i bit repository collection:

-       Det der definere entydig identifikation af en fil

-       Sætte attributter på data/filer om hvordan de skal sikres

Jeg tror dette er en grundlæggende fejl og at vi bør indføje et source/data-ejer... begreb (SA, SB, Netarkivet, KB) hvor forskellige collections kan laves for hver af dem. Dvs. vi stiller krav om at hver source/data-ejer har unik angivelse af filer og at collections kun kan dække filer fra én source/data-ejer. source/data-ejer kan altså være en del af set-up for en bit repository collection, og så er spørgsmålet hvilke operationer det evt. kan påvirke.

Mvh. Eld

Fra: bitrepository-devel-bounces at ml.sbforge.org [mailto:bitrepository-devel-bounces at ml.sbforge.org] På vegne af Christian S. Vandel
Sendt: 23. juni 2011 17:25
Til: List for the Bitrepositorys developers
Emne: 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] 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] På vegne af Eld Zierau
Sendt: 23. juni 2011 12:04
Til: 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

[http://support.kb.dk/images/kb_logo.jpg]

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/20110624/c18c5eff/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/20110624/c18c5eff/attachment-0001.jpg>