[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

XML encapsulation



Phil Coombs wrote:
> In fact, we can read any object created in the past forty or so
> years as long as someone has kept a viewer application to it and
> some clue what's in the object.

I find this hard to agree with, unless "viewer application" is taken to
include all of the following (plus some others I probably forgot):
- hardware to read the physical medium,
- operating system,
- drivers or other interfaces to peripheral devices,
- peripheral devices themselves,
- application to recognize and read the given file format,
- all associated applications that may be called by the application
above,
- paper or other electronic documentation to which it was originally
assumed users had access.

Reference Model for an Open Archival Information System (OAIS) does a
much better job of describing many of these issues than I could in this
message:
http://ssdoo.gsfc.nasa.gov/nost/isoas/ref_model.html

There are also descriptive and administrative elements that would be
important to maintain along with a record.  The Pittsburgh Functional
Requirements
http://www.sis.pitt.edu/~nhprc/
and numerous documents that have drawn from them over the past few years
make this pretty clear.  There's research underway on how some or all of
the above elements can be emulated, rather than actively migrating all
of them periodically.  But I don't see any viable way to ever avoid them
entirely.

Even if emulation is a viable option in some cases (which is still yet
to be determined, pending more research), and Jeff Rothenberg's recent
report on emulation is any indication,
http://www.kb.nl/nedlib/results/emulationpreservationreport.pdf
even using emulation to keep around the native file formats requires
considerable work upfront and a fair degree of work over time.

> The prevailing belief is that technology won't get any smarter in the
> years ahead and that we should convert stored objects to a 1985 or
> earlier format so we can read it in fifty years.

Could you please clarify what this is referring to?  Would this be the
conversion of proprietary text formats to ASCII?  XML is, in fact, a
variant on SGML, which has been around since 1986.  And both XML and
SGML use ASCII text as their character encoding mechanism.  It's my
belief that the persistence of something like ASCII over decades should
not be viewed as a liability but rather as an asset.  No format or
medium is permanent (even ASCII is giving way to Unicode in many cases)
but some are considerably more stable than others.

I think that, if anything, the fact that technology continues to grow in
complexity means we must be even more aware of the large number of
technological dependencies within and between digital objects.  We must
either maintain systems along with the records or extract a great deal
of information from those systems and maintain it along with the
records.

> There is, however, a solution about to go public.  It is called
> encapsulation of the native object with rich metadata.  In short,
> it wraps any (e.g., .dll, .exe, .wpd, .doc, .mpg) object
> (or collections) with an XML (or, optionally, HTML) file that
> contains metadata of the origination's choice (e.g., Dublin Core,
> FGDC, WAGILS).  This turns the package into a markup language file
> (e.g., .xml or .html) that can be stored independently of a catalog
> and 'crawled' to build an accurate index.  When someone wants
> to see the object, they unwrap a copy (or original if desired).

Any tool that can facilitate metadata creation is a step forward.  But
I'm still not sure which part of the preservation scenario metaPackager
is providing.  The HiSoftware web site says it is "to use rich metadata
to catalog and archive files that do not have the capability or facility
to embed metadata or where the standards change so frequently that is is
[sic] not advisable to do."  I understand the former much better than
the latter.  If I have a TIFF image of a page, then I could certainly
see the value of easily wrapping some metadata around it, which couldn't
be embedded in the file itself.  But I see two major issues:
(1) a huge amount of recordkeeping metadata is required that goes for
beyond Dublin Core, FGDC, or WAGILS in order to preserve reliable and
authentic records (though FGDC specifies a lot more access and
provenance metadata than the other two),
(2) a proprietary file format that's now saved as a file that wraps
metadata around that proprietary format is still far from
self-describing or self-preserving.  One must first have the software to
get to the proprietary file inside and all the appropriate software to
make sense of the metadata that's part of the wrapper.

The idea of object encapsulated metadata is certainly not new, by any
means.  I guess I just don't quite understand what magic bullet
metaPackager will be providing.

=======================================================
Cal Lee
Electronic Records Project Archivist
Kansas State Historical Society
Phone: 785-272-8681, ext. 280         Fax: 785-272-8682
http://da.state.ks.us/itab/erc/
http://www.kshs.org/archives/recmgt.htm
                  "Obsolete power corrupts obsoletely."
                                           - Ted Nelson

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>