Table of Contents | Ch 1 | Ch 2 | Ch 3 | Ch 4 | Ch 5 | Chapter 6 | Conclusions | References

Chapter 6 The On-line Institute - A Model

Introduction

To illustrate the functional usage of the many technologies and concepts discussed so far it is intended to propose a model that is based upon a central component of any educational institute which uses on-line technologies. That is, this model will focus upon the components involved in the process of a student negotiating the design of a lesson and then completing that lesson with the on-line lesson/tutorial generator.

This student session is chosen for the reason that its process is the `heart and soul' of the on-line institute and all functions of the system are subservient to this learning process. Administration systems, resource bases and on-line engineering technologies should all co-operate to deliver the learner with an uninterrupted immersion in the learning process.

As discussed in section 5.3.1 the model is designed with the adult, autonomous learner in mind. Each learning event is either negotiated or chosen from a predefined menu. Expert systems are incorporated but only in support of the learner's lesson negotiation and not in a comparative mode. This model is a resource-based learning model.

By restricting the design of the model in this fashion it would allow a typical corporate organisation to move some or all of its training on-line fairly quickly by allowing students mediated access to perhaps previously unavailable materials. The addition of further specialised and expensive task support tools and more use of expert systems in a comparative teaching mode could come later.

As an `engine' to facilitate the navigation and selection of appropriate resources the model could find usage in all three sectors of education with consideration for the target audience when implementing the human interface components.

The term engine is used to describe the key component which encompasses the on-line transactions and processes which takes inputs from and provide outputs to the learner. To continue with this analogy the engine also requires the fuel tank, which is the resource base or knowledge pool, and the body, which is the administrative or institutional shell. Many institutions already have the latter components but lack an on-line transaction engine. Further their `fuel' more than likely needs converting for use with this engine and perhaps the `body' needs remodelling to accommodate this radical new form of propulsion.

Prior to discussing the functional model there are a number of issues which need to be resolved in the design process.

6.1 Decisions

Before moving existing educational material or creating new material on-line several crucial decisions are required which will affect the scope and the deployment of the on-line institute. It is possible to build a system which satisfies both a small school, offering some electronic services, or a fully automated virtual college.

6.1.1 Granulation

Perhaps the most crucial decision is to do with the granulation of the knowledge base or other institutional data. An organisation's knowledge base can take many forms. A typical late twentieth century organisation has much of its information about the organisation and how it is run in word processing documents which may describe ordering systems or customer relation procedures. Larger organisations may have their business-rules embedded in a data management system. An educational institute has much of its knowledge encapsulated in courseware, tutorials, academic papers, examinations and the like. All organisations can choose to share or remodel existing data, or develop new data which would form the core of their on-line institute. It is the building and sharing of knowledge which drives the on-line revolution.

If then all data is digitised and available for serving to a remote client what is the size of the serving? Is it a complete tutorial or lesson or is it a Document Like Object (DLO) such as a word processing document or is it an even finer grained chunk such as paragraph, sentence, word, syllable or character? The chunk may also be defined logically such as in a hierarchy of topics and sub-topics or lessons and modules and therefore be of no fixed length.

The definition of the chunk size will have an impact upon the storage system chosen to store the raw data which then defines the interface system to manipulate that data which may also define what the client needs in the way of hardware and software to view that data.

The current standard format for writing and storing Internet data is the Hyper Text Markup Language (HTML) and is viewed with its associated browser or viewing device. This allows the publishing of text, images, sounds and other related documents via hyperlinks. Other more sophisticated elements can be added to this standard page in the form of executable code (as in JavaScript) and meta-data describing the contents etc. One advantage of the HTML file is that its basic storage container utilises the parent operating system's file structure and available tools for ordering and searching files on that operating system. Also as the language is a standard and the document itself is text based it is interchangeable between operating systems.

By choosing the HTML page as the basic chunk any organisation could be delivering informational resources very quickly using just the standard Internet technologies currently available. Current Hyper Text Transfer Protocol (HTTP) systems using Uniform Resource Locators (URL) offer a logical view of related HTML files which is all the client requires for a basic interface to any on-line system. The HTML standard should remain the dominant standard for a number of years to come.

More sophisticated services such as searching are available via additional applications running on the server. The basic navigation of HTML pages is via browsing of hyperlinks and indexes of pages or topics which relate to pages. Typical search engines index the basic elements of the resource base, words. These words may be embedded in a document or part of a DLO title or abstract. The user then searches this index via word and phrase matching with the use of logical operators such as and, or and not. While the search is done at word level the basic deliverable is the document which the user must then still open to evaluate. The search engine seeks basic elements such as words and phrases but displays them in a logical manner to allow the user to `zero in' on a topic or fact.

In future it will require much finer grained chunks in the form of distributed objects to offer an ontological view to the end user with a corresponding increase in the complexity of the system. Further the found objects could then themselves be search agents which find related words, topics and relationships. This would be particularly useful in an on-line educational system.

6.1.2 Automation

The next decision relates to the amount of automation required of the system as discussed in an earlier chapter. The expense and time involved in moving from active to fully-interactive publishing can be considerable. For instance in large systems it becomes crucial at some point for the system administrators to have no involvement of the coding of HTML tags in HTML documents as this can be a laborious task. Yet the programming of a suitable HTML generator is not trivial. Further there should be no manual keying in of data captured via the web site. It must be sorted, catalogued and stored with all related links updated automatically. This requires strong database knowledge with even more programming as most flat and relational databases are unsuited to the dynamic nature of Internet data.

These decisions will be put into context as a functional model is discussed.

6.2 Model of an On-line Tutorial Engine

When contemplating the design of the system which will be the core of an organisation (since this organisation could exist solely on-line) it is difficult not to fall back on existing models of education for inspiration. But one must avoid this trap as the learner-centred system is vastly different to most that have come before it. In a full service institution the presumption is that the learner comes to the institution of their choice and it is the responsibility of the institution to supply everything to satisfy their learning needs. This is the opposite of the institutional centric focus of many current universities, and particularly schools and TAFE, where the student has little choice of learning styles, content, time or place. It is with this learner-centred philosophy in mind that the new on-line institute should be designed and built.

6.2.1 The On-line Tutorial Engine - Design Specifications

It is useful to describe some of the main features of the virtual over the physical institute from a student's perspective before discussing this model. Many of these functions would relate directly to the stated objectives of the system which would form the basis of the system specification:

All enrollment and administration is done on-line;

As much, if not all, courseware and related resources as required are available on-line and use the HTML standard;

With correct bona fides and a suitable and available choice of program, access to learning materials is immediate;

Pacing could be based upon progress or time, with fees and credits being adjusted automatically if required;

All functions are carried out on-line. There are several layers of interactivity including:

asynchronous services;

browse, search, enquire for resource based materials, simulation/test, tutorial, tutor, mentor.

synchronous services;

peer engagement via chat, audio/video conference.

personal services via on-line technologies;

seminar, class, tutorial, coaching, interview.

Student progress is continually tracked and assessed, the results of which are available at any time to authorised enquiries;

Changes in enrollment are accommodated at any time with credits given for work done if relevant;

(Student achievements would need to be universal and fully transportable between similar national and international institutions);

Assessment could be either via peer (normalised) or self comparison;

Individual 'dossiers' and/or 'learning accounts' could be established.

6.2.2 Overview and approaches

There are some starting models which, with adaptation, can be used for this model design. Park (Park et al,1987) suggest a crucial aim of such a model is to separate subject content, student information and instructional strategy. A further review of the literature (Harmon,1987; Wallach,1987; Begg & Hogg,1987) finds a common set of components which combine to form an on-line transaction system. The major components are:

Various terms are also used to describe the environment these components operate in which effectively forms the shell of the system such as the expert system or the intelligent tutoring system. One important aspect of the overall system depends upon the intended usage of the system - whether it is designed for performance support as in your typical CBT project or whether it is designed around an expert system.

These two approaches to the design eventuate in distinctly different systems and pedagogical styles. Park (1987) lists terms used by both approaches to highlight the differences and show that the CBT approach utilises task analysis as its basis as opposed to the use of an expert rules based system. The model using an expert system incorporating elements of task orientated learning where necessary is most useful. Similarly with this proposed model the use of micro rules (if-then-else constructs) at the knowledge level would be replaced with macro rules (choice guidance) at the tutorial or course levels. It is imperative the system supports the learner's engagement with the knowledge base.

The ability of the learner to roam the knowledge base and administrative systems will require some sophisticated support applications to assist them. These are tools such as the lesson generator, the page generator and the administration system itself. The overall design and some of the interactions of this proposed model are presented in Figure 6.1. This model is adapted from a "Model of Adaptive Instruction (adapted from Seidel,1971)" (Park, 1987).

Figure 6.1 - On-line Tutorial Session Model

The building of this model has been simplified greatly by Internet technologies and standards such as HTML. This means the system designer has little need to be concerned with the client capability and does not need to write proprietary interfaces for each hardware platform. Any HTML browser is sufficient. Other components are not so easily dealt with and depending on the complexity of the system may require unique designs and programming.

6.2.3 Resources - Not Expert Rules

This model is fundamentally different to many previously proposed Intelligent Computer Aided Instruction (ICAI) systems in that the knowledge base is not seen as a compilation of expert rules but as a compilation of resources. There is then no comparison of the student model with the expert model during a session. Rather the comparison is with pre-negotiated objectives for progress and usage of the resource materials and via continual assessment using traditional testing. The very ethos of constructivist approach to learning requires the learner to decide how resources are utilised. This system takes its design focus not from the classroom, but from the library model, where the librarian is not a teacher but a resource facilitator. It is then the borrower's decision whether learning shall take place. (Alessi & Trollop,1991: Begg & Hogg,1987)

6.2.4 The System Flow of a Student Session

Figure 6.1 shows a collection of software processes interacting with and between a typical student and a resource base. This diagram is session-based in that it illustrates the flow of the typical session and the functions required to accommodate it over time. Each student initiates a session with the administration system which creates a unique ephemeral student model for that session. Drawing on historical and current student data this student model advises the lesson generator. The lesson `genie' then creates the session lesson or tutorial. The page `genie' creates each page offered to the student dynamically, drawing on instructions from the lesson genie and data from the resource pool. The student then either works her way through the given material setting physical checkpoints as she goes or doing the evaluation exercises. This progress (or lack of it) is monitored by the session monitor which then advises the student model and hence lesson and page genies. Finally with the lesson satisfactorily completed, or perhaps interrupted or abandoned, the session monitor informs the administration system of the outcome of this session.

By scaling hardware and software it is envisaged that tens, or hundreds, of simultaneous sessions could run together.

6.2.5 The Resource Base

The resource base is the core of the system and provides a user with both tasks and topics to browse. Romiszowski (1981:81) describes a task as an element of a job (to be done) and describes a topic as an element of a subject (to be learnt) - jobs specify performance while subjects specify information. The user of the resource base comes seeking both. What is of greatest use though is their relationship. Tasks need concepts and vice versa.

This simplified view offered to the user will veil the more complex view of the designer or the academic who needs to place resources in their correct location. Figure 6.1 shows the resource base as a collection of `objects' which can simultaneously be described by their:

Abstraction - an abstraction denotes the essential characteristics of an object. Is it a movie, a file, or an image etc.?;

Encapsulation - provides details of what can be done with this object such as open, close, run, read etc. yet hides the details of how it does it;

Modularity - a higher level grouping of abstractions into containers such as fact sheets, task lists, tables, jigsaw puzzles, lessons etc;

Hierarchy - is a ranking or ordering of abstractions and the two most important types "in a complex system are its class structure (the "is a" hierarchy) and its object structure (the "part of" hierarchy)" (Booch,1994:59).

While this classic object model serves the designer well much front-end analysis of topics and tasks must take place before the building of the system. As new tasks or topics are added new modules must be created which may contain existing abstractions and hierarchies. One problem is that these objects are difficult to move about as many of their attributes are inherited from their class relationships. While this is a useful compromise for the designer it leaves the learner with a preconceived set of relationships which may not match their own view and so is considered a shortcoming in the learner-centred model. It is this opinionated view of topic areas which could ultimately render the data obsolete as views, technologies and factual information changed.

The above classic object model is used by programmers of monolithic programs where the parameters are easily fixed. One could build a useful but partially inflexible resource base with it. The world though is moving away from the monolithic software application of the past 40 years to component based applications comprised of distributed objects assembled in virtually any combination when and where the user or application developer desire. This revolution driven by object oriented programming changes the way we can store and manipulate data. Yet its fundamental object is now a distributed object which has both data and processes associated with it, and can exist outside normal applications. Unlike static task procedures these objects can now form a semantic network which has been discussed for many years and could consist of:

"nodes representing objects, concepts, and situations in the domain knowledge and links between nodes representing their relationships. This method is based on psychological models of human associative memory (Norman & Rumelhart, 1975; Quillian, 1968)" (in Park,1987:16).

It is this associative memory which resonates with the ontological interface discussed previously. The use of Relational DBMS (Database Management Systems) is useful for fixed hierarchical data with predetermined relationships but dynamic learning and the construction of knowledge requires an Object DBMS and its associated framework.

The distributed object is the perfect representation of what was recently discussed as the chunk. Unlike the static database the relationships are not predetermined. The designer can choose to add static relationships and dynamic relationships to a distributed object. This means objects can have the ability to associate themselves with another object or disassociate themselves. They can contain the rules, like earlier expert systems, as well as the processes of object oriented programming languages. By building a resource pool of these `intelligent' objects the designer can put the learner in direct contact with the chunks to manipulate and use them as they desire. As the objects themselves are capable of actions they can keep the other components in the on-line system informed. ie updating their usage to the session monitor and student model. Authors such as Clancey (1987) have in the past wrapped their expert system around the rules of the knowledge base and then wrapped this with an intelligent tutoring system. This proposed model inverts this system. With the intelligence attached to the resource object it can move between systems.(Orfali et al,1996)

So while the subject matter expert may still order the tasks and topics in a hierarchical manner, which makes sense for the human building or maintaining the system, the user would only see the ontological view which may, or may not, relate to the physical and logical views. This expert logical view may itself be what the novice is studying or the user may also reconstruct the logical views to suit their current problem using different techniques such as behaviour analysis or domain analysis to shape the chunks (Booch,1994).

6.2.6 The Student Models

The Student model in this proposed model is comprised of two parts. One is the more traditional idea of a student model which contains historical data in a form or nomenclature that can be interpreted by both human and system alike and is owned by the administrative system. The other student model is session related and dynamic and contains each individual's current and future record of their interaction with the learning system. This planning component contains such items as next chunk, lesson etc and time lines but may be built from information contained in the historical record such as learning level and preferences. It is possible for each student to have more than one dynamic record but only one historical record.

The CASMAC initiative, an initiative of the Australian Vice-Chancellors' Committee to provide a common university administration system, describes a historical student record system which provides facilities for "course structures, admissions, enrollment, timetable, fee management, assessments, graduation, accommodation, alumnus and distance education" (CHA, 1992). The CASMAC initiative is obviously the design of a static, physical system. Still, existing student record systems of this type could be utilised by the dynamic on-line system by providing persistent state storage for the dynamic student model. The historical student model would receive information from intelligent objects regarding their usage and this would then be stored for the administrative system to utilise at the next session.

The major task of the student model in a dynamic system would be to gather and make decision support on dynamic components such as the current lesson or tutorial, its history, current state and planned and negotiated progress. If at anytime the client was disconnected the dynamic student model should be capable of restoring the client to the previous logical state in any process with all memory intact. This persistent view would be held in the historical record.

While it may seem object environments need more programming it should not be the case. For instance a unique student model would be created for each user. In fact each user could have several with differing privileges etc. The object, which each model is based upon, needs only be written once with its primary actions and relationships pre-programmed. The dynamic data is written at run time and the historical data is stored persistently by the object.

6.2.7 The lesson and page generators

In a typical session after clearance from the security and finance sections of the system the student would be put in touch with the lesson generator. This process would respond to a learner in a number of ways. Previous learners are restored to their last location and state. New learners may either have already chosen a pre-packaged tutorial or course which is promptly generated for them. The process could also supply macro level decision support for first time learners to help them achieve negotiated goals. This interaction could be done via simple menu selections or a higher level expert system operating as a course adviser.

The functional result of the lesson generator is that a series or cluster of chunks or technical resources are placed at the learner's disposal. Elements of the typical lesson would be: objectives, theory, tasks, summaries, related resources and tests. These could be either served or selected as required. The page generator could present these hyperlinks in a sequential form on a HTML page or as a cluster on a map using the Meta Content Format. These present a 2D and 3D logical view of the links respectively. The page generator may then also be asked to present the ontological view. That is a 2D or 3D map which emphasises the relationships of the data, both overt and covert. At all times the student should be able to search/browse (the physical and logical systems) or inquire (the ontological system) using knowledge sharing languages such as KQML.

6.2.8 The System Bus

Much of the early work in the area of Intelligent Computer Aided Instruction (ICAI) was written for stand alone applications on desktop computers or via distributed terminals in computer labs. By the use of available global networks we now have the situation where the ICAI program can make use of surrounding systems and be distributed and accessed regardless of geographical constraints. This allows the designer to utilise a system of systems which can work interactively to provide services to the end user. The Object Management Group (OMG) is charged with the design and implementation of standards to define the interaction of distributed objects in this system of systems which may entail some objects traversing the globe to embed themselves in other objects and systems and so on. This work is defined in the Common Object Request Broker Architecture bus or CORBA. (Orfali et al,1996; Booch,1994)

It is only with standards such as CORBA that data and objects or agents can operate between proprietary systems. Functional uses of such systems for an on-line institute could be as diverse as using other institute's services for assessment or allowing students to study a course comprised of units from several schools or universities at once.

6.3 Scaling the On-line Transaction Engine

The engine and its major parts described above could easily be scaled between a small school-based system up to a multi-campus university system using the same principles. The main elements of scalability would be hardware and software related so as to accommodate a resource base which could grow sideways indefinitely. New subjects and tasks would create an even greater complexity of associations which may eventually come close to emulating the real world we live in. If even a small portion of this was captured digitally it would be helpful. It would also be immediately out of date. But with the help of dynamic objects gathering their own data this problem may be overcome.

It is important to appreciate the scope and difference of this 'negotiation' with an 'intelligent' system. In our case we are using it to negotiate in an educational context but any 'knowledge pool' could be plugged in to the system. For instance the knowledge pool could be your home environment (heating, cooling, music etc.) or your travel itinerary where the distributed object, or agent, released under your authorisation has the power to make and delete bookings etc. Unlike earlier AI systems our new emphasis is on assimilating, relating and linking knowledge domains. Artificial Intelligence lost a lot of followers because of its perception as a know-it-all teaching system. Using distributed objects we can now use AI as a patient, supportive and controllable learning system. A major flaw of CBT is that the system is always right due to rigid design whereas an ILS should always defer to the learner.

While this described object sounds daunting it has in fact been with us for many years in a number of forms. For instance the basic component of the HyperCard application, (popular in organisations using Apple Macintosh computers and as an original hypertext application the inspiration for the WWW), the card, is just such an object. Like its physical counterpart, the index card, it contains data but also has the ability to implement actions. It is also transportable, can create and delete itself, share data with other applications and form hierarchical relationships. It is the fore bearer of the `modern' distributed object which will more than likely be written in an OOPs language such as Java, C++, Common Lisp or SmallTalk. The real object will be far more robust and much faster than the HyperCard equivalent. As we put `wheels' on some of our stand-alone technologies we can give them power unenvisaged in their original format. (Booch,1994)

Conclusion

This chapter shows the design of any component of an on-line system will need to be iterative with decisions taken early in the piece affecting elements diverse as workflow and technology choices. Distributed objects offer some relief from this rigidity by allowing flexibility in the most dynamic parts of the system.

Fully programmed purpose built object systems will be built for the larger on-line engines and utilise well mapped software engineering processes to deliver learner, academic and administrative services. As stated earlier, it is with the complexity of the back-end that we can deliver the simplicity of the front-end and a learner-centred environment.

*****

Table of Contents | Ch 1 | Ch 2 | Ch 3 | Ch 4 | Ch 5 | Chapter 6 | Conclusions | References
© 1997 Paul McKey