managing electronic records in governmental bodies - National ...
managing electronic records in governmental bodies - National ...
managing electronic records in governmental bodies - National ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
39<br />
<strong>records</strong>.<br />
Archiv<strong>in</strong>g<br />
Electronic <strong>records</strong> can be archived <strong>in</strong> two ways:<br />
- When <strong>records</strong> are archived with an <strong>electronic</strong> document management system<br />
the documents are moved from central magnetic disk storage to offl<strong>in</strong>e or less<br />
expensive storage media. The <strong>electronic</strong> document management system<br />
supports the ability to search document profiles as if they were onl<strong>in</strong>e, and the<br />
documents can be retrieved from offl<strong>in</strong>e storage to onl<strong>in</strong>e use.<br />
- With an <strong>electronic</strong> <strong>records</strong> management system the <strong>records</strong> are physically<br />
removed from the repository entirely and they are transferred to an archives<br />
repository or to off-site storage and the <strong>governmental</strong> body gives up<br />
custodianship of the <strong>records</strong>.<br />
The <strong>records</strong> management software chosen must <strong>in</strong>clude both possibilities and<br />
should preserve the format, profiles, and support<strong>in</strong>g contextual <strong>in</strong>formation (the<br />
metadata) of each document when it is archived.<br />
Long term format<br />
The <strong>electronic</strong> <strong>records</strong> management system must provide the functionality to store<br />
<strong>records</strong> <strong>in</strong> non-proprietary formats, or to convert <strong>records</strong> to such formats upon<br />
check<strong>in</strong>g them <strong>in</strong>to the <strong>electronic</strong> repository. Because non-proprietary formats are<br />
better suited for migration than proprietary ones. The adoption of <strong>in</strong>ternationally<br />
recognised data <strong>in</strong>terchange and document format standards will simplify the<br />
migration process. Data <strong>in</strong>terchange is the ability to store files on the media us<strong>in</strong>g<br />
one type of computer and then to access the content of the storage media by us<strong>in</strong>g<br />
any other type of computer, while non-proprietary format implies that <strong>records</strong> created<br />
<strong>in</strong> a specific format should be able to be read by other software packages <strong>in</strong> the<br />
same way as the creators and users orig<strong>in</strong>ally saw them. There are no guarantees<br />
that any of the formats that exist at present would be able to be read <strong>in</strong> a few years’<br />
time. However, the <strong>in</strong>ternational community seems to be settl<strong>in</strong>g for PDF and XML<br />
as the long term formats. It might therefore be necessary to convert the data written<br />
<strong>in</strong> proprietary formats to standard hardware and software <strong>in</strong>dependent formats (e.g.<br />
PDF, TIFF, XML) to enable migration strategies to be put <strong>in</strong> place.<br />
An option at this stage is to ensure that <strong>records</strong> are self-sufficient by add<strong>in</strong>g<br />
encod<strong>in</strong>g metadata to the record. This is done by add<strong>in</strong>g simple textual encod<strong>in</strong>g<br />
that describes the data to <strong>in</strong>dicate its extent, syntactic mean<strong>in</strong>g, semantic mean<strong>in</strong>g,<br />
and relationship to other data <strong>in</strong> the record, and a reference to the specification of<br />
the standard format that was used. This will enable future users to extract<br />
<strong>in</strong>formation from the <strong>records</strong> even if they do not have the specific format the <strong>records</strong><br />
were created <strong>in</strong>, because they will be able to obta<strong>in</strong> the specifications of the formats<br />
that were used.<br />
Manag<strong>in</strong>g <strong>electronic</strong> <strong>records</strong>_Policy Guidel<strong>in</strong>es.doc<br />
First Edition<br />
Version 1.1<br />
April 2003