Speciale tekens in SIP
- 8 jul
- D Heemstra
- 2
- 265
- 1
Beste collega's,
Gemeente Emmen heeft in samenwerking met het Drents Archief van 2021-2024 pilots uitgevoerd om te achterhalen hoe informatie en documenten van overheden tot in eeuwigheid beschikbaar kunnen blijven. Hierbij liepen we in de praktijk tegen het feit aan dat namen van informatieobjecten en bestanden karakters kunnen bevatten zoals spaties. Volgens de richtlijnen van het Nationaal Archief moeten de namen dan in de SIP geschoond worden van deze karakters voor aanlevering aan het e-depot. Vermoedelijk heeft dit te maken de vindbaarheid (zoekfunctie) van de informatie in het e-depot.
Nu is het zo dat er richtlijnen kunnen worden opgesteld voor bestandsnamen die door de gemeente zelf worden gecreëerd, maar hoe zit het met namen van bestanden die vanuit de burger zijn aangeleverd? Zouden die omgezet mogen worden in een bestandsnaam zonder ongeoorloofde tekens en spaties? Wat heeft dit voor gevolgen voor de integriteit van het informatieobject? En met oog op toekomstige informatieobjecten zou dit ten koste gaan van de betrouwbaarheid van het informatieobject wanneer het wijzigen van bestandsnamen plaatsvindt voordat het in een vakapplicatie wordt opgeslagen? Omdat dit wellicht leidt tot verlies aan inzicht in welke wijzigingen hebben plaatsgevonden en of deze geautoriseerd zijn?
Iemand die hier toevallig ook tegenaan gelopen is en een mogelijke oplossing heeft?
Reacties
Goedemorgen,
Waar ik in het verleden wel eens tegenaan gelopen ben is het corrupt raken van bestanden vanwege de spaties. Daar was de oplossing om de spaties te vervangen door het underscore teken ( _ )
Daarmee veranderd de samenstelling van de naam/titel niet.
Misschien helpt dit ook in dit geval
Goedemorgen,
Een spatie is bij mijn weten niet een ongeldig teken, de lijst die we in de exportvoorwaarden hebben is:
< > : “ / \ | ? * # &
De reden hiervoor is dat deze op bestandssystemen speciale betekenis hebben.
Maar, dat geldt alleen voor de naam van het fysieke bestand in de SIP bij aanlevering. In de ToPX (of MDTO) metadata kun je wel aangeven wat de echte bestandsnaam is, zodat het in het e-depot bekend is. Datzelfde kun je ook gebruiken wanneer bestanden waren opgeslagen in een DMS of zaaksysteem en daar een interne code hebben gekregen, terwijl de oorspronkelijke bestandsnaam wel beschikbaar is als metadata om op te zoeken.
Een voorbeeld om het misschien wat duidelijker te maken: één van onze eerste overbrengers had een systeem waarin bestanden random namen kregen, in dit geval bijvoorbeeld "84c01!.PDF" Dus ook nog met een ongeldig teken erin. In de metadata in het DMS stond dat de oorspronkelijke bestandsnaam "Getekende overeenkomst m.b.t. huisvesting.PDF" was.
Om dit op te kunnen nemen moest in de export het uitroepteken in de random bestandsnaam worden veranderd, in dit geval hebben we gekozen voor in een underscore (dus 84c01_.PDF) omdat die door het DMS niet gebruikt werd en dus nooit tot problemen kon leiden. In ToPX hebben we toen op bestandsniveau:
In de mapping van ToPX naar ons e-Depot hebben we gekozen om element 21.2.1 leidend te laten zijn bij hoe het e-Depot het bestand noemt. Voor ons e-Depot is de bestandsnaam dus "Getekende overeenkomst m.b.t. huisvesting.PDF" omdat de opsteller die naam ooit gegeven heeft. In ToPX is wel bekend dat die in het DMS ooit "84c01!.PDF" heeft geheten, mocht daar ooit op gezocht moeten worden.
De naam "84c01_.PDF" die voor de export nodig was komt nergens meer terug, die was alleen tijdelijk nodig voor het maken van de SIP.