Larry, I think you've captured the essence of the relationship of file
plans, retention schedules, and metadata perfectly in your response below.  

This concept should be clear to those who understand how databases work.
Think of the file plan and retention schedule as two separate tables within
the ERMS that are linked to a particular record through the magic of a
relational database.  When, as Jon noted, a user enters a record into the
ERMS (or a workflow process automatically enters it), the record must be
assigned a file classification.  This is but one metadata element that the
ERMS will attach to that particular record.  But it is the key one to relate
the record to the file plan, and through the file plan to the retention
schedule.  

With the file classification, the system can ping against the file plan
table to retrieve the metadata that it contains about that record:  record
series title, series description, how the record is used in normal
operation, when the record is closed, where it is stored at various stages
of its lifecycle, and whatever other information is designed into the file
plan.  The file plan will also provide a link to the records retention
schedule table item that applies to that record series.  The retention
schedule supplies all the information about retention periods and
disposition for the record series.  All the data in the file plan and
retention schedule tables are maintained at the record series level, and it
flows down and attaches to an individual record when that record is assigned
the file classification.

Whether the system for managing your organization's records is manual or
electronic, it needs to have a file plan and a retention schedule.  As Ginny
and Larry have both made clear, these are separate documents/tables that
serve different purposes.  (There may be some degree of duplication and
overlap between them, particularly in the paper environment.)  But they are
linked to each other and tied to a particular record through a file
classification metadata item.  That file classification is stored in a field
in your ERMS database, typed on the file folder label sitting in your file
cabinet, and written on the individual record that is placed into the file
folder.  It helps the user find, use, and replace the record during active
use, and facilitates the disposition process after the record has become
inactive.

Greg Schildmeyer, CRM

-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf
Of Larry Medina
Sent: Thursday, October 25, 2007 10:54 AM
To: [log in to unmask]
Subject: Re: Metadata Was Bucket Theory

>
> Why do we need store electronic or paper in file plans when we can store
> them in "big buckets" and capture the important metadata and associate it
to
> the record.  I thought about RM practices and if I agree.  Applying holds,
> applying retention, dispostion, discovery, etc all would work, I believe.


A comment here... your statement above is accurate if there is a blurring of
the definitions of the terms "file plan" and "metadata", but I think as
indicated by many it's sort of like the discussion about "not all documents
are records, and not all records are documents"... there are distinct
differences between the two.  Certainly, the argument can be made that
sufficient volumes of information can be added to either to allow them both
to serve the same purpose, and the same is true for just about anything, but
that defeats the purpose they each are designed to serve.

As Ginny noted, when the concepts of metadata were introduced to RIM, they
were related to the addition of elements to electronically generated
information to assist in identifying it.  A file plan, or a classification
system, was used for similar but different purposes.  It not only assisted
in identifying information, but it was designed to relate to the function
the information served within an organization. And as stated earlier, you
could add this "field" to metadata and populate it as well, and you might
want to do that... but you don't NEED to do that.

This discussion could go on forever and I think there isn't a right answer,
there are a lot of opinions though.  Are any opinions wrong?  Nope...
they're all right for some reasons and for some people.

The only thing I have is "How does the metadata get applied?".  I have
> implemented ERM systems at multiple companies. Usually a filing profile is
> used to put a record into the record series in the ERMS.  The filing
profile
> has defaulted metadata associated with it.  This minimizes the amount of
> work a user has to do to enter the record into the system.  From my
> experience, users want to capture a lot of metadata but don't want to
enter
> it all.


This is a very important topic, one that many involved in RIM need to get
their arms around, especially when it'as being developed for use in your
organization.  The concept of auto classification, whether it is "rule
based" or "role based", or a combination of both.  And a term I hear a lot
of vendors jokingly use when trying to sell the concept is "automagically"
classified.  There needs to be a level of human intervention in the
classification of information when it is categorized to ensure that not only
the CONTENT is understood, but also the CONTEXT.

In certain situations where there is extremely routine work being done, such
as the completion and filing of form based data, or reports say in a
customer service environment, or shipping and receiving  or procurement
paperwork in and order entry and fulfillment environment this would
obviously work. There is little margin for error, tables can be developed to
compare content of fields against, and information can be classified based
on "pass or fail" criteria.

But in more subjective working situations, systems would need to be
constantly adjusted and "tweaked" to ensure accuracy... and after extensive
work, there could be some level of acceptance, but someone would have to
periodically go back and verify/validate the classifications until they were
close enough to 100% that they were acceptable.  The option in these
environments is to develop pull down menus that allow users to participate
in the selection of elements to classify the information and subsequent
evaluation of the classifications to attempt to narrow the elements to a
point where eventually a semi-automated model can be used with acceptable
results.

I guess you could still use multiple filing profiles into the big buckets,
> but then why not keep a more detailed file plan. You could then narrow the
> scope of searches, narrow the scope of holds, etc.


And THIS is exactly what both Ginny and I were pointing out.  There is not
mutual exclusivity in the use of metadata and file plans.   A file plan says
where things are, in many cases based on the function (or organization
segment) they support by category...  the metadata (drawer labels, file
indexes, file folder labels in a paper world; servers, folders,  file names
in an electronic world) is used for finer levels of finding aids.

Hmmmm... ironic how the identifiers in the examples of paper/electronic
above are very similar in nature...

Larry
-- 
Larry Medina
Danville, CA
RIM Professional since 1972

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]

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]

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]