Well,
Having worked with Steve at Duke Energy I can give you some information.
Duke's solution was similar in approach to what VERS and NARA are doing, ie
storing the documents in both Native and PDF rendered format with Metadata
that includes both indexing and transactional information. This solution was
based on a somewhat customized version of FileNET. Since the solution was
used to store engineering drawings it also had to have the capability to
hold hybrid (raster+vector overlay) documents and render those to PDF
accurately. One of the biggest challenges was being able to plot scaled
architectural drawings from the PDF. The entire system had redundent hot
standby backup to ensure availability and the documents were still backed up
on microform (Just in case).
OVERKILL? I don't think so. Duke engineers sometimes had to work with
engineering documents for our hydro plants that dated back easily 80 years.
The retention on some of the nuclear station documents is going to be quite
lengthy and the cost of recreating or recoverng information is much higher
than retaining it.
John Gahrmann
Liberty Insurance Services
Manager, Imaging Technologies
Opinions and attitudes are mine personally, not Duke's or my current
employer.
-----Original Message-----
From: Justine Heazlewood [mailto:[log in to unmask]]
Sent: Thursday, April 12, 2001 3:09 AM
To: [log in to unmask]
Subject: Re: Victorian (Australia) Electronic Records Strategy Media
Release
Our ref: 99/90
Hello all
Just to clarify some of the matters raised in the media release on VERS and
to address some of the issues which have arisen in the subsequent
discussion. Solution 6 has been engaged to provide a VERS compliant
recordkeeping system to the Victorian Department of Infrastructure. They
are basing this system on TRIM (Tower Software) and Fulcrum (Hummingbird)
plus some purpose built stuff to do things like encapsulate into XML.
The debate over whether to capture the native format *or* a generic long
term format is an interesting one, and in some respects both Bill and Chris
(Muller) are right. There are solid reasons for retaining the native format
(not least that it makes it easier to re-use a document or record). But
there are also reasons for using a long term generic format especially if
you are an archival authority and have to worry about the long term (30+
years) accessibility of records in electronic form. It is far easier to
worry about maintaining access to one format than it is to an unknown
number.
The VERS approach to this issue is to have our cake and eat it. The XML
record 'object' was designed so that it could contain multiple renditions
of the record (so, for example, a rendition in ASCII, in PDF and in MS
Word). The decision of how many renditions is left up to the government
agency which is implementing VERS and would depend on analysing risk,
importance and patterns of re-use. In the case of the Department of
Infrastructure, they have decided to store records in both native format
and PDF (for document type records) - thanks to Melinda for pointing this
out.
In order to forestall the inevitable deluge of correspondence on the
weaknesses (and strengths) of PDF, can I just state that we are aware of
the problems associated with choosing PDF as one of our long term formats
but that our requirements are not met by any other existing document
format. I also refer people to the PDF FAQ on the VERS website for an in
depth discussion on why we went with PDF. <
http://www.prov.vic.gov.au/vers/faq.htm >
On a side note, I was also interested to see Steven's comment about Duke
Energy and like Chris (Halonen) I would like to know more about it.
Regards
Justine
Justine Heazlewood
Business Development Manager, Victorian Electronic Records Strategy
Public Record Office Victoria
PO Box 2100
NORTH MELBOURNE VIC 3051
(03) 9285 7938; 0413 733 299; fax (03) 9285 7953
[log in to unmask]
http://www.prov.vic.gov.au/vers/
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
|
