There are several motivations for creating a generic access layer for
FRS services. An application programmer may wish to use more than one
FRS during the life of the application because of their different
performance profiles. An application that initially used the
representation services of FRS 
might later use FRS 
because
FRS is faster, or more expressive, or cheaper, or better
supported. Or, an application might use FRS in addition to
FRS -- FRS might be more expressive for a subset of tasks, or
the application might newly require access to a knowledge base (KB)
that was implemented using FRS . Consider also utilities that
users might want to employ in conjunction with a number of FRSs and
applications, such as a graphical knowledge editor, or a machine
learning program.
Although there are significant differences among FRS implementations, there are enough common properties that one can describe a generic model of frame representation and specify a set of access functions for interacting with frame representation systems. An application or tool written to use these access functions has the potential of portability over a variety of systems and knowledge bases.