Workgroup

This chapter describes workgroup features of Jude Applications and mechanisms used to implement them.

Introduction

Workgroup computing occurs when there is a collection of individuals working together on a task using computers connected together. The connection can be temporary, for example in the case of laptop or computers with a dial-up connection to internet, or permanent. The work on a computer disconnected temporary from the net is called off-line work.

A workgroup system and an office automation suite requires lots of features, as already described in section . A workgroup system is difficult to design because it must suggests policies to follow but also grant freedom to each user because the involved process are subject to changes and exceptions.

This chapter describes powerful tools and mechanisms that can coherently interact together using the shared knowledge-base as communication medium. Every tool suggests a particular process to follow, but the user can always switch between different tools in order to view or add information on the knowledge-base.

User Interface

Compound-Documents

Jude user interface is a framework of Jude-Agents having the scope to display and edit objects defined in the knowledge-base. The framework is based on compound-documents.

A compound-document is a document that contains elements from a variety of computer applications. For example, a single compound document might include text from a word processor, graphics from a draw program, and a chart from a spreadsheet application. Most importantly, each element in the compound document is stored in such a way that it can be manipulated by the application that created it. Examples of compound-document technologies are OLE, OpenDoc, JavaBean, KParts and Bonobo. Compound-document framework is the most effective way to build a document-centric user interface.

On the contrary a document-centric user interface is a work environment where applications can inter-operate easily and the user can focus on the content. In compound-document environments ``applications inter-operate in a seamless fashion by using a single shared user interface (UI). It frees the user to view one's work in a document-centric fashion, instead of as a set of applications between which one must move.''[Rush 1994] This type of environment is ideal for a collaboration product because permits a better sharing of documents contrary to the application-centric environment that dominates the old age of computer history.

An application-centric environment is a work environment where applications are not much inter-operable and the choice of the application to use is crucial. In order to be useful to a broad range of users applications tend to be huge and complex, while each user is interested only at a little subset of its features.

In the Jude user interface framework there are viewers and editors.

A viewer is a Jude-Agent that displays the content of all the objects of the knowledge-base of a certain type. A viewer can be classified as lite-viewer and normal-viewer. A lite-viewer uses the little needed available space to represents the object. Typically it is used inside tables, trees and in other places where compactness is important. It must not represent all the values of the object. A normal-viewer can use all the needed space and should represent all the state of a given object.

An editor is a viewer that permits users to edit its own content.

There are general viewers and editors for contents of any type. During the implementation of a specific application also specific viewers and editors should be needed. If you implement a new viewer and associate it to a certain type, then it is used as default viewer when an object of the given type must be displayed. For example in the chemical domain there are molecule 2D/3D viewers, NMR Graphs viewers etc.

Relation-viewers and relation-editors are viewers and editors associated to a certain type and to a certain relation. They are more reusable than object viewers. For example the relation-viewer GenericSwingRelationEditorAsTable display as a Swing table any relation of any object. The BinaryNoTransitiveRelationViewerAsTree permits to view as a Swing tree any binary, no transitive relation of any object.

The current implementation of Jude user interface is based on Java Swing library, that contains many features needed by a compound-document framework. However you can implement the Jude user interface using other libraries, for example for web browser access.

The figure 9.1 shows two different views of the object file_croconic_xyx. The view on the right shows the structure using a graphical viewer, while the view on the left shows the content of the file using an ASCII file viewer. The figure shows also a pop-up menu that permits user to select different views of file_b100020i that is a document related_to_substance product_lm036.

Figure: Compound Document Environment

Hypertext Views

The descriptive nature of knowledge-base can be used to generate a description of an object collecting all base and derived facts having the object as argument. Each argument can be selected from the user. This data view resemble an hypertext representation of data because the user can follow different pathways through the facts of knowledge-base. This process is similar to web navigation.

Figure: Hypertext View of an Object

Knowledge-Base Explorer

Knowledge-base-explorer is a viewer that permits users to interact with knowledge-base in a way similar to navigation inside directories of a traditional operating system. In this case SimpleLogic types are considered as directories and SimpleLogic subtypes as subdirectories. The definition rules of a type and its associated descriptions are used as general documentation of the content of the corresponding directory. For example if you have a rule that says:

assert S is_a body_centered_tetragonal 

if S is_a tetragonal_system

and S has_ions_per_cell 9;

then the rules is used as documentation for body_centered_tetragonal type. This is possible because the knowledge-base are high-level and readable enough to be used also as documentation source.

Objects of the given type are considerate as files/resources of the corresponding directory. Note that on the contrary of traditional application-centric environments, the same object often can stay in multiple directories because an object can have multiple types. In particular if an object stays in a subdirectory then it stays also in super directory.

Jude classification mechanism of objects/resources/files takes advantage from usage of rules. For example if you specify something like:

assert my_element is_a tetragonal_system;

assert my_element has_ions_per_cell 9;

then my_element is an element also of body_centered_tetragonal type according to the previous rule. Rules permit automatic classification of objects.

Figure: Knowledge-Base Explorer

Query Viewer

A query supports different views.

A first view is related to query definition. Using this view the user can intuitively build new queries. The compound-document user interface permit users to select through drag and drop interesting objects to use inside the query.

Figure: Query Body Viewer

A second view of the query is a table having as column headers names of variables, and as cell values the corresponding values that are solution of the query.

A third view of the query is a list of facts satisfying it.

Document Management

Document-Management systems are systems focused on document management, in particular viewing, editing and retrieval. They should permit to set access rights for documents and manage different versions of the same document. A document-management system transforms a traditional work environment based on applications and files in a work-group environment . Often this is accomplished adding meta informations to files and storing it in a central repository. This is also the mechanism used by Jude.

In Jude a file having a format that differs from SimpleLogic formalism is called external-resource. Jude associates to the external-resource a meta description using SimpleLogic rules and facts. This information can entered by the user or also by automatic classification tools able to read a certain file format. The meta information permits users to use the retrieval mechanism of Jude in order to find relevant files. When a relevant file is found it is transferred from the central repository on the server to the client, where is displayed using the proper Jude viewer or a native application.

Workflow

Every organization uses a business process, that is ``a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organizational structure defining functional roles and relationships.''[wfmc 1999]

Workflow is ``the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.''[wfmc 1999] A Workflow system takes in consideration the problem of users coordination, that happens when users work together by participating in structured or semi-structured processes.

Using Jude the developer can build workflow applications. In Jude you can freely classify objects using powerful rules and the observer pattern can be used to notify users or agents of relevant changes of certain object state. Classification and notification are the heart of a workflow system.

For example the chemlab.simplelogic cluster defines the type to_classify_product as the set of all synthesis products needing a classification. If you discover the cell of a product inside to_classify_product then it leaves the set and became an instance of substance_with_cell and interesting_unclassified_product according these rules:

assert PRODUCT is_a substance_with_cell

if  PRODUCT is_a synthesis_product 

and PRODUCT has_cell true;

 

assert TO_CLASSIFY is_a interesting_unclassified_product

if  TO_CLASSIFY is_a substance_with_cell

and not(TO_CLASSIFY has_chemical_formula _);

When you discover also the chemical formula of the product then it became a classified_product. The same object, the synthesis_product, is moved from a type to another and during each step proper agents and proper users are informed.

In a Workflow system a central role is played by process definition that is ``the representation of a business process in a form which supports automated manipulation, such as modeling, or enactment by a workflow management system. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc.''[wfmc 1999] Probably SimpleLogic is powerful enough for specification of different process definitions. A first attempt is represented from cluster person.simplelogic that defines persons, organizations, roles of persons inside organizations, projects, sub projects, etc.

Prototype Pattern

In [Gamma 1995] there is a description of the prototype pattern:

``Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.[...]

Prototypes let you incorporate a new concrete product class into a system simply by registering a prototypical instance with the client.[...]

This kind of design lets users define new ``classes'' without programming. In fact, cloning a prototype is similar to instantiating a class.''

Jude uses this pattern in the user interface. The user can save a lot of work because, instead of starting from scratch he can clone from a document similar to needed document. Note that in Jude all informations can be grouped in documents. This permits users to use the clone method also to insert fine grained informations and not only to duplicate traditional documents containing large chunks of informations.

Each relation in SimpleLogic is weak or strong. By default a relation is weak. When you clone a base fact involving a strong relation you perform a clone of all objects that are arguments of the fact. On the contrary the clone of a fact of a weak relation is the same fact without any clone operation involved.

The object clone is the result of clone of all base facts having the given object as argument.

The clone of an external-resources is the copy of the associated file and the clone of all meta information.

Figure: Clone of Compound-Content B0 containing the image A0.

Security

At the moment Jude does not implement a security mechanism, so this section contains only hints and ideas.

In a workgroup not all users have the same privileges. There are documents and informations that can be accessed only from certain users and other data available to everyone. So in a workgroup system security mechanisms play a central role. Security is the protection of data against unauthorized read and write access.

In Jude security access are determinate at level of single fact. The local cache of a user can contain only facts for which the user as a read-grant. The user can assert or retract a fact on the server database only if he has a write-grant. The user can change access rights to a fact only if he has protection-grant. Protection-grant implies write-grant and write-grant implies read-grant.

Obviously users can not specify security access for all facts, but they must specify the access rights at level of object. Then Jude system assign to a fact the access right corresponding to the more restrictive access right of each of his arguments. The Jude system must assign access right at fact level because it must decide when it can send a fact to a client (only if the user has read-grant), when assert or retract fact on the server knowledge-base (only if the user has write-grant) and when accept changes in access rights of other objects (only when the user has protection-grant). A schema for assigning access rights could be something like this:

declare relation user has_access grant for object;

 

assert grant is_subtype_of object;

assert read_grant is_a grant;

assert write_grant is_a grant;

assert protection_grant is_a grant;

 

assert X has_access read_grant for Y

if  X has_access write_grant for Y;

 

assert X has_access write_grant for Y

if X has_access protection_grant for Y;

The user can specify access rights also using rules. Doing so, security policies are powerful but easy to understand and maintain. For example a professor can assign read-grant for document in progress only to his collaborators, using this simple rule:

assert COLLABORATOR has_access read_grant for DOCUMENT

if  braga has_access protection_grant for DOCUMENT 

and COLLABORATOR has_role_of collaborator for braga at today

;

Another example is an user that when absent gives all grants to his collaborator:

assert maini has_access GRANT for DOCUMENT

if  braga has_access GRANT for DOCUMENT

and not(DOCUMENT is_a confidential_document)

and not(braga is_at_work today);

Access rights are specified at level of objects. This permits a big precision. On the other hand rules can specify many access rights in a concise and powerful way. Contrary to security mechanism of traditional operating systems this is an high-level mechanism because specifies access rights in terms of real-world policies and not only at level of files and directories.

Off-Line Work

Working on a computer wich is temporary disconnected from the net is called off-line work. At the moment Jude does not support this type of work because every query and update involves the server database interaction. The current local cache is stupid because it contains only association between queries and results.

Probably a better design involves usage on the client side of a deductive database in order to support off-line work. Note that there are compilers from Prolog source to native Java virtual machine byte code. Probably this type of tools can be used instead of XSB. Usage of a local inference engine in some case can also increase speed because there is no communication overhead occurring between client and server database.

Long Transactions

!! This section is too naive. I must read some papers about synchronization issues and rethink at the problem with more insight. The main concept is that each synchronization phase must leave the database in a consistent. DB_A + DB_B = DB_C + SYNCRONIZATION_CONFLICTS , SYNCRONIZATION_CONFLICTS are facts that can arise some consistent problem if automatic integrate in DB_C, so the must integrate by human intervention. A lock can be view in Jude as a statement that says that when the owner of the look synchronize then all synchronization problems will be resolved in favor of the lock owner. A lock is an exception to the rule that the user who synchronize first is in advantage over other users. !!

``A long transaction is a series of DBMS commands that extend over a long period- hours, day, weeks, or even months . A long transaction contrasts with the short transaction supported by conventional DBMSs, which ordinarily resolves within a few seconds. Long transaction arises in cooperative design, in which someone is responsible for a portion of a project and must perform extensive work before sharing the results.''[Blaha 1998]

Workgroup systems should support long transactions, especially when they permit off-line-work mode. Off-line-Work happens when there are clients working temporarily disconnected from the server database. In this case all editing operations are long transaction. When the client reconnect to the server database Jude must performs a synchronization between client knowledge-base and server knowledge-base. A synchronization process can be used also for replication support.

When a Jude client loads objects from knowledge-base it starts a long-transaction that ends when the client resynchronize its data with server knowledge-base. If another Jude client retrieves the same objects then there are two parallel version of the same object. This could cause synchronization conflicts.

In case of conflicts the first synchronized object is considered as default valid object. The later object is considered as a conflict to resolve. The conflict is resolved from one user that can discard completely the conflicting object or can integrate in the current object the changes of the other object. This policy favors user who tend to update data more frequently. It can also be justified thinking about an user that starts a long transaction on a given document and closes it after some days. In the meantime the document was modified from different users, so the most updated copy is the already synchronized copy on the knowledge base, not the last copy saved from the first user.

Synchronization of an object is performed synchronizing base facts having the given object as argument. This permit working with little pieces of information and not with the entire object at all, decreasing the possibility of synchronization conflicts. In reality what you are synchronizing is not the object but base facts. Note that synchronization is performed only on base facts because derived facts are automatically derived from it using knowledge-base rules. Synchronization of a base fact is simple:

• If you assert a new fact in the client knowledge-base then this is always added to the server knowledge-base. From a conceptual point of view asserting facts equals to adding information to an object, and this is always possible.
• If you change a fact this is equivalent to retract the old fact and assert the new fact.
• If you retract a fact on the client knowledge-base then there is a synchronization conflict if the base fact is present on the server knowledge-base. This is equivalent to say that all users must be informed before to retract informations from the system.
• If a fact on the client knowledge-base is present but it was retracted on the server knowledge-base then there is a synchronization problem. This is the symmetric counterpart of previous rule.

This policy permits concurrent work on the same document until an user add information to it. Conflicts arise when some user retract facts without informing the other user working on the same parallel version of the object.

Retraction is not always permitted because while assertion of facts rarely leaves the database in a inconsistent state, retraction does. For example if we have:

assert product_1 is_a synthesis_product;

assert maini has_acknowledgement_of product_1;

and after a synchronization we retract ``assert product_1 is_a synthesis_product'' then ``assert maini has_acknowledgement_of product_1'' is an invalid fact because product_1 is not an acknowledgeable object as required from has_acknowledgment relation.

On the contrary assertion of new facts only on rare case produces errors in the knowledge-base. The problematic cases are related to not-operator usage. These cases can be detected inspecting the elements of bad_object set.

In conclusion the synchronization mechanism allows concurrent work on the same object with little risk of synchronization problems.

Actions

Transaction Logic permits to execute actions on object. An editor can supply an effective way to invoke an action on a given object knowing only action declaration. The editor can represent the action as a series of slot to fill with object representing the parameters of the action and a button in order to execute the action. This permits developers to specify actions in an easily way using SimpleLogic and to obtain an usable user-interface, at least to use in the application prototype phase.

Office Automation Suite

Office-Automation-Suite is a suite of programs able to execute a variety of office operations, such as word processing, accounting, and e-mail. Jude permits the management of files created using traditional application (see section ) or also the direct implementation of an office automation suite because Jude supports a rich data format that, as in the case of XML, can be directly used to express a lots of informations.

Conclusion

Jude elegant design pays now that we want implements high-level features. Every mechanism examined works reading or updating knowledge-base and so indirectly it interact with each other mechanism.