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.