[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: XML encapsulation
Justine has discussed the reason why VERS recommended PDF,
but as this list has drifted somewhat from the initial topic
I thought I might expand on some of the ideas behind VERS.
I make no claim that what follows is the definitive answer
to preservation (a better solution may be developed tomorrow).
But I believe that these ideas allow you to preserve objects
today with a strong expectation that they will be available
tomorrow.
Information about VERS can be found at http://www.prov.vic.gov.au/vers/
1. Encapsulation
VERS is based on encapsulation. The preservation object is
referred to as a 'VERS Encapsulated Object' (VEO). A VEO
contains a record. A record consists of one or more documents.
Each document consists of one or more encodings.
Documents are intended to represent components of the record
which are logically distinct, but must all be present to form
the record. For example, an agenda for a meeting would consist
the one page agenda itself (one document), and the supporting
documentation for each item (each would be a separate document).
An encoding is a physical representation of the document (e.g.
in Word format, RTF, PDF, etc). The ability to include multiple
encodings of a document within a VERS record is to:
* improve the chance of successful preservation
* aid re-use of information
* allow the preservation of different features of the document
Physically, a VERS Encapsulated Object has the following
layout:
VERS Encapsulated Object (VEO)
VEO Metadata
Record (one)
Record Metadata
Documents (one or more)
Document Metadata
Encodings (one or more)
Encoding Metadata
Physical Content
Signature Blocks (zero or more)
Note that the metadata is divided amongst the four layers -
VEO, Record, Document and Encoding.
The VEO Metadata describes the VEO itself and the encapsulation
format used.
The Record metadata describes the record as a whole. Different
types of organisations may have different record level metadata.
As VERS was for an archive, the record level metadata is based
on archival practice (specifically the National Archives of
Australia Recordkeeping metadata, with extensions based on
the Pittsburgh set). In particular, much of the archival record
level metadata is concerned with the provenance of the record
to ensure that the record is accurate and authentic. Record
level metadata for a library is likely to have a different
emphasis and be subtly different (e.g. have less emphasis on
provenance and more on rights management). I would expect that
most record metadata, however, would be ultimately based on
Dublin Core.
The Document metadata describes the document *within* the
context of the record. In particular, it can describe the
system that produced the document.
The Encoding metadata describes this specific encoding of the
document. In particular, it describes the format (e.g. PDF),
and the process which the content underwent to be included
in the VEO.
The contents of a VEO may be digitally signed. The information
about these signatures is included in a signature block. Note
that more than one digital signature may be applied if required.
The encapsulation and the metadata it contains has a day to day
use in allowing the users to access the preserved information.
But it is important to realise that the ultimate purpose of the
encapsulation and metadata is to *preserve* the information.
To this end, it is vital that the encoding and metadata be
readable by *humans* using the simplest possible tools (e.g.
Notepad or Vi). If the archival system that holds the preserved
object fails, a human readable encapsulation allows the system
to be recreated by inspecting the objects.
The main modification that I would make to the VEO now, after
nearly two years of experimentation, would be to have a
standard method for allowing the documents to refer to each
other.
2. Preservation Formats.
When discussing preservation formats, it is important to start
off with an indication of what features or characteristics it
is important to you to preserve.
For example, in VERS we decided to preserve the original
appearance of the object as the creator saw it. We did not
preserve 'hidden' features of the object (e.g. macros, style
information). Our criteria was to preserve the information we
believed the original readers used as the basis for making
decisions.
However, we explicitly recognise that other groups will have
different preservation criteria, and hence require the
preservation of different features or characteristics. It was
for this reason that the VERS encapsulation allows the inclusion
of *any* format, and can contain multiple representations of the
same document.
Having said that, we believe that a characteristic of a good
preservation format is that it is you can re-implement it. That
is, in the future a technical expert can sit down and write
software to read and process the format. The software may be
a viewer, or it may migrate the object to a new format. To
re-implement the software it is necessary to have a
specification of the format. Note that we do not require that
it be cheap or easy to re-implement the software (though this
is a desirable characteristic :-), just that it be possible.
The best re-implementable format is so simple that you can
completely specify it within the VEO encoding metadata. The VEO
is then completely self sufficient.
In practice, most formats are too complex to fully document
within the VEO. As Justine noted, we then fall back to the
'public library' test. Has the format been formally published
(and so should be available in a legal deposit library)? Or in
an Internet equivalent (such as the Internet RFCs)?
It is preferable to choose a widely implemented formally
published format. Wide implementation is some guarantee that
the implementations actually implement the published format
(and don't use unpublished extensions).
Note that I have not mentioned 'international' standards vs
'proprietary' standards yet. From a preservation standpoint,
the issue of de facto or de jure standards is largely
irrelevant; the ability to re-implement the format is what is
important. Indeed, I would prefer a widely used proprietary
standard over a little used international standard.
Focussing on the ability to re-implement a standard highlights
the error in the common complaint about standards, that new
standards are constantly being developed. The development of
a new standard does not affect the ability to preserve objects
using an old standard provided it is possible to re-implement
software to read the old standard. It may, of course, affect
the economics of accessing the object which is why formats
should be chosen with care :-)
Finally, what if there is no suitable re-implementable format?
We recommend that you choose a widely used format. New products
are *likely* to read widely used formats (otherwise they cannot
capture any market share) and so you have a reasonable chance
of being able to migrate the preserved object when a suitable
preservation format does become available. If there is no widely
used format, the object just has to be saved in the application's
native format. At least the encapsulation will describe what
this native format is. You may be lucky enough to find software
that can read the format.
Andrew Waugh
A posting from the Archives & Archivists LISTSERV List!
To subscribe or unsubscribe, send e-mail to listserv@listserv.muohio.edu
In body of message: SUB ARCHIVES firstname lastname
*or*: UNSUB ARCHIVES
To post a message, send e-mail to archives@listserv.muohio.edu
Or to do *anything* (and enjoy doing it!), use the web interface at
http://listserv.muohio.edu/archives/archives.html
Problems? Send e-mail to Robert F Schmidt <rschmidt@lib.muohio.edu>