VE as a venue for academic work - joining faculty and students.

In today's mass academic education, a student can no longer be his master's apprentice , like in bygone days. Students don't even have a private research environment, i.e. a room to call their own. CMC tools can be used as a medium that create a virtual work environment, when a physical one is not feasible. Textual work oriented VEs, descendants of community building oriented ones, are in common use during the last five years, i guess the first was MIT's 'Media MOO'.

Textual VEs are in essence an integration of CMC tools, combining both synchronous and asynchronous ones. The products of these tools, can be kept in a repository, usually a memory resident DB. In general, the DB is centralized, and contain only conventional DB data types like texts and numbers.

Another way to approach the issue might be through the use of a standards based SQL RDBMS, to build a repository of academic products (papers, bibliographies, student's works, mail, discussion groups, chats). If an ORDMBS is used instead of an RDBMS, diverse kinds of data types (text, graphics, video, sounds, presentations, etc.) can be kept.
 

The role of objects in a VE.

Apart from CMC tools, these virtual environments contains measures that help make the place more 'life like', and are mainly an assortment of objects, which visitors can have and manipulate. The main role of these objects is context creation, with the result of making the place more suitable for community building then stripped down CMC tools, like IRC.
 
In a MOO, there are 'master objects' (or object classes), which are mainly created by the more knowledgeable denizens, having a 'programmer's bit', or by the 'wizards', the rulers of the VE and it's DB. The master objects can be customized, simply by textually changing their description, while keeping their functionality. For example, a player, which is an instance of a master player object, can be easily customized by giving it a textual description. In this way, a rich and complex community can be built, based on the technical expertise of some, and the literary abilities of the many.
 

The move from textual to graphical 3D VEs.

Textual VEs have the strength of simplicity. It is easier for most of us to textually describe ourselves or our surroundings, than it is to draw a graphical representation of it. However, textual VE has it's limitations. It is still easier to represent yourself by using everyday objects, your wristwatch, shoes, the family pictures on the desktop, then it is to textually describe them. So, in order to avoid the need for describing, and on the other hand avoid the need for the high graphical skills needed for making up graphical representations of one's everyday objects, a method of pre-fabricated objects can be used. These objects should be easy to customize, using simple mouse clicks, and picking characteristics like color and size (i.e. instances of a master object) from a menu.

Moving into your virtual room should be as easy as moving into your office or cubicle, which someone else designed and built for you, leaving you with the ability to tack pictures to the board (or put GIFs on the VRML table), as well as to customize your computer backdrop (or fixing an HTML browser to your VE's wall).

Vernacular building will surely be allowed, but as it requires higher skills and dedication, should not be the sole basis for this working community/environment.
 

The need for disk-based, distributed DB.

As we move from a local and small community, into the realm of a large scale, or a global one, a centralized DB can no longer be used. MOOs are suffering from lags, mainly because of network bandwidth limitation. But if the community is in the thousands, then the web example should be used, i.e. a dispersed file system, or better, a distributed DB.

These DBs can be based on an architecture having:
1. 'master objects' and more central DBs
2. local 'instances' DB.

While the 'master' DB holds the classes and located on centralized servers which can be replicated as needed, the local 'instances' DB can reside on the user's hard-disks, or workgroup server, the same way web servers are used to serve from a centralized area, and from private home directories.
Your VRML world could be built on the client side, by assembling master classes retrieved from the 'master objects' DBs, and description (instances) retrieved from the local DBs. Or, it can be assembled on an intermediate server, and delivered as a complete entity. Furthermore, an ORDBMS can be used to provide object inheritance, and the instance object can be a child of the master object in the 'classes DB'.
By making these DBs standards based, i.e. SQL, or more precisely ORDBMS DBs, and by using standard ways of communications between them (like CORBA or RMI), we will be able to build on available technologies, rather then reinventing working segments of the industry.
 

The use of standards based CMC tools and protocol.

Much in the same way, it will be best to use current CMC techniques and protocols, like HTTP, FTP, SMTP, NNTP (and of course VRML). The only needed addition is in the interface. For example, instead of using FTP, you'll 'put' a paper, or a visiting card, i.e. a graphical representation of such objects, on your colleague's table. An HTTP browser can be hung on the room's wall, view able by all present in the room.

The result would be an easy to understand and assimilate work environment, which on the one hand uses proven CMC tools, and on the other use naturally learned 'real life' spatial human experiences. After all, giving directions on where to find a certain book in the library, in the form of 'second floor, third row on your right side, fifth book from the left-hand side', is more natural to most people then 'http://construct.haifa.ac.il/~nakhshon/vrml98.htm'.