One of the advantages of this, and a design goal of MoReq2010®, is the potential for interoperability between MoReq2010® compliant records systems (MCRS). An MCRS does not only understand its own entities and its own processes, it can export them to a standardised format that can be understood by another MCRS. (MoReq 2010, p.21)En, nog interessanter misschien: de export-functionaliteit moet zodanig zijn dat alles geexporteerd kan worden. En met alles bedoelt MoReq 2010 dus ook "event histories" en audit trails:
In MoReq2010® every entity has an event history associated with it. This is particularly important in supporting interoperability, where entities are transferred from one records system to another. Each entity is transferred as a whole, including its metadata, event history, access controls, and so on. The event history is an integral part of the entity and this approach allows all MCRS to import and fully understand events that occurred to an entity while it was part of a previous records system. (MoReq 2010, p.27)Alleen jammer dat import niet als "core service" gedefinieerd wordt:
It should be noted that import is not part of the core services of an MCRS, but every MCRS must be able to export its information to the MoReq2010® common XML export format. Import requires a far higher level of application sophistication than export, and mandating it for all records systems would preclude many dedicated business systems from adopting MoReq2010®. (MoReq 2010, p.22)Iets anders wat hier mee samenhangt zijn de Universally Unique IDentifiers (UUID) die verplicht zijn. Iedere entiteit en service moet een eigen unieke code krijgen, omdat alleen op die manier export uit en import in een MCRS probleemloos kan verlopen.
The use of a UUID is mandatory for compliance with the specification. This means that any entity can be exported from one MCRS and imported into another MCRS and will continue to be uniquely identified. The importing MCRS can even match up different copies of the original entity that were exported at different times or were transferred to it via an intermediate MCRS. All entities can be traced back to the specific instance of their originating service where they were created. (MoReq 2010, p.36)Naast "export" onderscheidt MoReq 2010 ook nog "delete" en "destroy"
Unlike the entities in other information systems, entities in an MCRS are destroyed, rather than deleted, leaving a residual entity that remains in the MCRS. Residual entities are an important concept in records systems as they indicate entities that were once present in the system. Without them it would not be possible to reconstruct the full context of an historic record. (MoReq 2010, p.23)Met andere woorden: iedere "vernietiging" moet traceerbaar residu achter laten in het systeem zelf.
Uit het plaatje hierboven zou je kunnen opmaken dat je een archiefstuk nadat het is aangemaakt, maar nog niet is "gebruikt" zou kunnen verwijderen zonder een residu achter te laten. Dat is uiteraard niet het geval:
It is not possible to delete entities from an MCRS as if they had never been created unless they are deleted before they are used. Entities that have been used may not be deleted.
Some entities, most importantly records and their components, (but also entities such as events, access control entries, system metadata element definitions, and so on) do not have a first used timestamp and may never be deleted. Once they have been created, entities of these entity types may never be erased without trace from an MCRS. (MoReq 2010, p.36)
Gerelateerd
Archiefstukken in MoReq 2010
RMA, SOA en MoReq 2010
Bewaren is makkelijk, vernietigen dat is moeilijk!
Een paar dingen zijn (is?) mij nog niet helemaal helder, maar ik heb MoReq2010 ook nog niet gelezen - die bewaar ik voor naast het zwembad. :) Wat MoReq2010 definieert als een 'records system', is dat nou alleen de applicatie of het geheel van voorzieningen voor recordsmanagement (zoals bedoeld in ISO 15489).
BeantwoordenVerwijderenMoReq2010 stelt hier ook dat je een archiefdocument (record) verwijderd, de metadata of althans een deel daarvan moet bewaren. Wat doe je met records die (grotendeels) uit diezelfde metadata bestaan, en hoe ga je om met bijvoorbeeld persoonsgegevens hierin. En hoe voorkom je dat raadpleging door gebruikers van het 'systeem' bemoeilijkt wordt door een voortdurend groeiende berg van registraties: laat je in het eerste zoekresultaat alleen de registraties zien waaraan nog wel een record is gekoppeld, of registraties die hun 'record-ness' nog niet hebben verloren? En hoe geef je dat dan aan?
En zijn er wel voorbeelden van archiefdocumenten die niet 'gebruikt' worden. Ik zou zeggen dat een record aan het begin al wordt gebruikt, bij de creatie zelf, maar dat hangt ervan af hoe je 'gebruik' definieert.
Goede vragen Joost en, beter laat dan nooit, hier wat pogingen tot antwoorden:
BeantwoordenVerwijderenEen "records system" wordt in MoReq2010 omschreven als:
An information system which captures, manages and provides access to records through time (ISO 15489-1:2001, 3.17).A MoReq2010® compliant records system delivers the functionality of a records system in a standardised way through its implementation of a set of core services, defined by the MoReq2010® specification, which may be further extended, adapted and localised through additional modules.
Dit lijkt dus vooral over een applicatie te gaan en niet zo zeer over het "hele" systeem.
MoReq2010 geeft geen antwoord op de vraag hoe iets moet, dat is aan de "leverancier" om te bedenken. Bij vernietigde records kan ik me een oplossing voorstellen die vergelijkbaar is met die van bol.com, waar een "vervolg-zoekopdracht" leidt naar "niet-beschikbare titels."
Dat verhaal over die "niet-gebruikte" archiefdocumenten vond ik ook een beetje vreemd. Maar ik zou me kunnen voorstellen dat je moet denken aan een concept-brief, die wel is opgemaakt en opgenomen in het systeem, maar uiteindelijk niet verstuurd wordt, om wat voor reden dan ook.
Ik hoop komende weken weer verder te kunnen lezen en zal eventuele nieuwe inzichten even rapporteren.