Berichten in deze discussie

Permalink Antwoord van Nadia Favié-Slaar op 3 Juni 2016 op 15.35

Ik begrijp uit bovenstaande discussie dat er nog geen duidelijkheid over is?

Permalink Antwoord van Arjan Kloosterboer op 28 Oktober 2016 op 12.03

Ten aanzien van de discussie over het uniek zijn van de identificatie van een record binnen en tussen organisaties het volgende.

Elke archiefvormer moet er voor zorgen dat records unieke identificaties hebben binnen de organisatie, ongeacht de verspreiding daarvan over de organisatie. Dat kan door technische voorzieningen maar ook simpelweg door het maken van afspraken. Stel dat met twee applicaties documenten beheerd worden waarbij beide applicaties documenten identificeren door ze een nummer te geven, beginnend bij 1. De afspraak is dan dat bij uitwisseling van die documenten het nummer voorafgegaan wordt door een uniek kenmerk voor die applicatie. De combinatie van kenmerk en nummer geeft dan een organisatiebrede unieke identificatie. Ook andersoortige afspraken zijn mogelijk. 

Een wereldwijd unieke identificatie wordt verkregen door bij uitwisseling tussen organisaties de organisatiespecifieke identificatie vooraf te laten gaan door een unieke identificatie van die organisatie en van het land waarin die organisatie haar activiteiten uitvoert. Die organisatieID kan een ISIL-code zijn maar ook een ID uit het nHR zoals het KvK-nummer. Dus voor alle organisaties toepasbaar. En: dit is slechts een werkwijze om een unieke identificatie samen te stellen. Als deze eenmaal is samengesteld dan wijzigt deze niet meer en moet beschouwd worden als een betekenisloze identificatie. Dus ook bij fusies van organisaties wijzigen de identificaties van reeds gevormde records niet! Aan de onderdelen van de identificatie mag geen betekenis ontleend worden, daarvoor zijn er andere elementen. Het maakt dus ook niet uit of een KvK-nummer na 100 jaar nog bestaat. Wil je vastleggen dat de na de fusie nieuw gevormde organisatie verantwoordelijk is voor die records dan moet dat met element 15C.1: Actor (en ik zou iets met Eventgeschiedenis doen).  
 
Marco Klerks zei:

In de toelichting wordt ervan uitgegaan dat binnen een organisatie geborgd is dat een registratienummer uniek is. Dit is echter vaak niet geborgd. Archief kan gevormd en bewaard worden in diverse applicaties, die ieder een eigen nummering hanteren. Een nummer kan dan wel uniek zijn binnen een applicatie, maar het is niet gegarandeerd dat het nummer niet voorkomt in een applicatie elders in de organisatie. Daarnaast kunnen door reorganisaties zoals gemeentelijke herindelingen archieven geadopteerd worden (Archiefwet 1995, art. 4). In dat geadopteerde archief kunnen kenmerken voorkomen die ook al in het eigen archief voorkomen. In het e-Depot kunnen daardoor identificatiekenmerken dubbel voorkomen. Is dit erg?

Permalink Antwoord van Nadia Favié-Slaar op 28 Oktober 2016 op 12.28

@ Marco, is laatstgenoemde procentueel niet heel klein?

Vooral als je het ID laat voorgaan door een KVKnr. En in principe voegt het e-depot ook een kenmerk toe. Combinatie van beide is dan uniek zou ik zeggen.

Garantie is het nooit, zelfs niet bij GUIDs (SP): https://sharepointinterface.com/2011/04/03/finding-duplicate-guids-...

dus dan inderdaad Actor en eventgeschiedenis erbij hanteren en het aloude 'pastoeofleguit'

Permalink Antwoord van Wout van der Reijden op 1 December 2016 op 8.46

Voorstel naar aanleiding van een discussie tijdens een van de workshops voor het informatiemodel TMLO:
Archiefstuk is uniek, bestanden kennen versies.
Overweging: nieuw versie, betekent een nieuw bestand en dit heeft een nieuwe ID. Maar moet er hier een (sub)element toegevoegd worden om versies aan te kunnen geven?

Permalink Antwoord van Wout van der Reijden op 1 December 2016 op 8.50

Mijn persoonlijke idee is dat je hier element 21 voor gebruikt (voor het beschrijven van verschillende bestanden, element is immers herhaalbaar). De aanbeveling voor het onderscheiden van verschillende versies aan de hand van het identificatiekenmerk van een bestand zou dan eerder aan de toelichting van 21.1 toegevoegd moeten worden.

Wout van der Reijden zei:

Voorstel naar aanleiding van een discussie tijdens een van de workshops voor het informatiemodel TMLO:
Archiefstuk is uniek, bestanden kennen versies.
Overweging: nieuw versie, betekent een nieuw bestand en dit heeft een nieuwe ID. Maar moet er hier een (sub)element toegevoegd worden om versies aan te kunnen geven?

Permalink Antwoord van Wout van der Reijden op 13 December 2016 op 16.46

Wijzigingsvoorstel naar aanleiding derde workshop Informatiemodel TMLO:

Subelement 'versie' toevoegen op niveau archiefstuk (optioneel subelement). In te vullen door datumTijd  (volgens ISO 8601) voor onderscheid verschillende versies.

Permalink Antwoord van Arjan Kloosterboer op 8 Maart 2017 op 11.32

N.a.v. de discussie is het element in het Informatiemodel MLO (versie 0.8) t.o.v. het TMLO gesplitst in drie subelementen aangezien deze onderdelen van de identificatie ieder voor zich semanische beketenis hebben:
- de prefix die de organisatiespecifieke identificatie internationaal uniek maakt;
- de organisatiespecifieke identificatie;
- een versie-aanduiding, indien van toepassing d.w.z. als er meerdere versies van de informatieset archiefwaardig zijn. Elke versie leidt dan tot een separaat record cq archiefstuk met eigen metagegevens. Als het alleen relevant is om verschillende versies van een bestand als onderdeel van één archiefstuk vast te leggen, dan krijgt elk bestand bij dat archiefstuk een versie-aanduiding als onderdeel van de bestandsidentificatie. Al die bestandsversies hebben gezamenlijk één set aan metagegevens als archiefstuk. Eén en ander is in de toelichting toegelicht.

Permalink Antwoord van Anje van der Lek op 23 Maart 2017 op 17.09

In TMLO 1.1 is bij waardeverzameling van element 2 opgenomen dat het unieke ID zo opgebouwd moet zijn: landcode, organisatiecode (ISIL, RSIN, KvK of Vestigingsnummer) en de unieke ID die het record heeft binnen de organisatie (bijvoorbeeld zaak- of documentnummer). Het unieke ID heeft daardoor een semantische structuur, de verschillende delen van de ID hebben betekenis. In het ImMLO is dat overgenomen en verder gefaciliteerd door de id op te delen in verschillende elementen. In mijn ogen is de semantisch opgebouwde ID sowieso onwenselijk, dus als je de semantiek hier uit haalt, is deze aanpassing in het ImMLO ook niet meer nodig.

Er wordt dus uitgegaan van de unieke ID die een record had in de ontstaanscontext (bijv het zaaksysteem/DMS), maar omdat deze code niet uniek is in een bredere context, worden er elementen die land en organisatie identificeren aan toegevoegd. Dit dient alleen om de uniciteit van de ID te waarborgen, de betekenis van deze elementen is voor de toegankelijkheid niet van belang. Zoals Arjan Kloosterboer eerder in deze discussie al stelde:  “Als deze (de ID) eenmaal is samengesteld dan wijzigt deze niet meer en moet beschouwd worden als een betekenisloze identificatie. […] Aan de onderdelen van de identificatie mag geen betekenis ontleend worden, daarvoor zijn er andere elementen.”

Het lijkt me handiger om de semantiek helemaal te schrappen uit de unieke ID (dan kunnen daar ook geen fouten insluipen…) en vanaf dat een record in een archiefcontext terechtkomt, een nieuwe ID aan te maken en dan gebruik te maken van automatisch gegenereerde UUID’s (of GUID’s).

Het gebruik van een semantisch opgebouwde ID leidt tot nodeloos lange ingewikkelde ID’s en fouten bij migraties/conversies. Een semantisch opgebouwde ID kan erg lang worden als er veel hiërarchische niveaus in een archief (serie en verschillende dossierniveaus) zitten. Voor elk record (serie, dossier) dat in de hiërarchie wordt toegevoegd, zal ook weer een deel aan de ID worden toegevoegd. Bij het maken van een specificatie voor de export van “Videotulen” (digitale structureerde raadsinformatie, inc audiovisuele bestanden) kwamen we er op uit dat er ontzettend ingewikkelde, lange ID’s door de leverancier moesten worden gegenereerd en toegevoegd, daar moet een script voor worden gemaakt hoe de ID’s moeten worden opgebouwd.Terwijl het verder niets zouden toevoegen aan de toegankelijkheid van de informatie. Want de enige eis aan element 2 is, dat het een uniek ID betreft.

Let wel: het behoud van de unieke ID uit het bronsysteem (bijvoorbeeld kenmerk, zaak/ of documentnummer) is wel belangrijk voor de toegankelijkheid! Je wilt immers kunnen zoeken op deze nummers. De uniciteit van deze nummers is voor dit doel niet van belang. Je kunt deze nummers dan ook beter opnemen in element 10 “externe identificatie”. 

• ‹ Vorige
• 1
• 2
• Volgende ›
• Pagina