RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Julie J. Colgan" <[log in to unmask]>
Reply To:
Records Management Program <[log in to unmask]>
Date:
Mon, 25 Mar 2013 16:18:46 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (51 lines)
Dwight asked - "Just curious - what is "the stub"?"

Some systems, usually as a part of an archiving process, will create what
is called a stub in the original location and move the content to another
repository.  A stub is essentially a pointer to the full content, but
usually retains a varying amount of original data (the nature and amount of
data included in the stub is often configurable).  Stubs are usually a
convenience feature so end-users can find content that has been moved for
some reason (usually it is moved to cheaper or more secure storage).

For example, email archiving systems often use stubbing.  The archive will
sweep mail servers and pull messages off of the mail server into an
archive, leaving behind a stub ... which can look and generally act like
the original message, at least with the majority of the header info and
potentially some of the content remaining in place for searching, sorting
and browsing purposes.  When a user opens the message, it will either just
display the stubbed content, or it will reach into the archive and display
the full content, depending on configuration settings.

When a user deletes a stub, depending on the wide variety of systems and
configurations, they may or may not delete the actual message or document
(usually deleting the stub will not delete the content in the archive - all
they are doing is deleting a pointer).

The issue with stubs as disposition documentation in email archives or
other similar systems/processes lies in how much and what kind of data is
included in the stub, the potential complexity of the stubbing process,
how/if end-users interact with stubs and what kind of influence they have
on the source data, whether stubs can be proven to have integrity, and so
on.  Just too many "what if's" for my taste.

To Larry's point, there absolutely are valid reasons to retain metadata ...
but stubs can be much more than mere metadata.

All of this is overly generalized for simplicity's sake.  Caveat utilitor.

Julie


-- 
Julie J. Colgan, CRM

[log in to unmask]
http://twitter.com/juliecolgan
http://www.linkedin.com/in/juliejcolgan

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]

ATOM RSS1 RSS2