WO2000026822A1 - A computer-implemented project knowledge management facility - Google Patents

Abstract

A method of creating a mode-driven virtual community (10) having at least one objective (12) includes accessing a collection of templates that constitute partial descriptions of respective elements of the virtual community. The collection of templates are instantiated to generate the elements of the virtual community. The elements of the virtual community specifying structural and behavioral constructs of a model (22) according to which the virtual community is structured. The instantiating of the collection of templates may be performed utilizing a decision framework (34) constructed utilizing input derived from participants (26) within an earlier virtual community instantiated utilizing the collection of templates. In an alternative embodiment, instantiating of the collection of templates is performed utilizing a decision framework (34) constructed utilizing domain-specific knowledge (42).

Description

A COMPUTER-IMPLEMENTED PROJECT KNOWLEDGE MANAGEMENT FACILITY

The present application claims the benefit of U.S. provisional applications serial nos. 60/107,036 and 60/118,709, filed November 3, 1998 and February 5, 1999, respectively, which are incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to the field of automated project management, knowledge management, and facilitation. More specifically, the present invention relates to a computer-implemented project management facility, with emphasis on gathering and managing project knowledge in the context of conducting business electronically, and to the presentation of information on a graphical user interface associated with the computer- implemented project management facility.

BACKGROUND OF THE INVENTION

A number of methods of improving productivity have been proposed in the prior art. Such prior art methods have typically been either processed- focused (i.e., based on workflows), data-focused (i.e., centered on the design of data structure and interfaces) or conversation-focused (i.e., centered on the structuring of communications). The use of project management tools is also well-known in the prior art.

Project management, in particular, has been the target of a number of efforts to improve business productivity. Project management is becoming increasingly complex and is accordingly posing a number of challenges to traditional management technique and tools. For example, the scale of projects and degree of expertise required to achieve objectives and goals of projects is increasing. Project management often requires access to specialized skills and expertise, and the ability to provide technological support to loosely coupled team structures. Team members may also expect more flexibility in the choice of their work locations and times. Further, shortages in particular skill areas may require that the skills be drawn from a widely distributed resource pool. The geographic and temporal dispersion that characterizes team members and resources provides a challenge to available project management techniques, as successful teams typically require a high degree of coordination and communication. Customers of a project are often considered to be members of the project team. The requirement to involve customers at the outset and throughout a project further complicates the project information sharing and communications requirements.

The increasing complexity of projects, and the increasing number of resources that are employed to achieve the objectives of projects, make it difficult for all resources of the project to remain focused on the objectives and in proper communication with other resources. The lack of focus on the objectives of the project may result in resources being employed in a less than optimal manner and, in certain situations, to feel isolated from the other resources.

The lack of communication between resources of a project renders the project team less able to respond quickly and appropriately to changes in the project circumstances or environment. Further, this lack of communication may result in the insufficient coordination of information with respect to project resources.

Further, traditional management tools may be limited in the extent to which they can be "recycled" and utilized to improve the performance of future projects based on the experiences of a specific project. In other words, there is a lack of experienced-based reuse of expertise developed during the performance of a previous project in the performance of future projects.

SUMMARY OF THE INVENTION

According to an aspect of the invention there is provided a method of creating a model-driven virtual community having at least one objective. The method includes accessing a collection of templates that constitute partial descriptions of respective elements of the virtual community and instantiating the collection of templates to generate the elements of the virtual community, the elements of the virtual community specifying structural and behavioral constructs of a model according to which the virtual community is structured and operated to progress towards achievement of the at least one objective.

The instantiating of the collection of templates may be performed utilizing a decision framework constructed utilizing input derived from participants within an earlier virtual community instantiated utilizing the collection of templates. In an alternative embodiment, instantiating of the collection of templates is performed utilizing a decision framework constructed utilizing domain-specific knowledge. In one embodiment, the instantiating of at least one template of the collection of templates includes generating a value for an attribute of the at least one template. The value for the attribute of the at least one template may be specified by a literal specification or by a variable specification. The at least one template may also include a specification of operations to generate the value for the attribute of the at least one template. The operations may include retrieving the value from a storage location associated with a computer system, calculating the value based on the least one input, or requesting an input of the value by an instantiator of the at least one template. The value for the attribute of the at least one template may also be specified by a further template.

In a further embodiment, a further template may be only partially instantiated to generate a community template, the community template being included within the virtual community.

The collection of templates may include a grouping template that holds first and second templates and wherein the instantiation of the first and second templates is coordinated to generate corresponding first and second elements of the virtual community. The use of first and second elements within the virtual community may furthermore the coordinated.

A purpose element of the virtual community that defines a reason for the existence of the virtual community may be instantiated.

An objective element of the virtual community that defines an objective of the virtual community may be instantiated in a further embodiment.

A measure element that facilitates measurement of progress of the virtual community toward achieving the objective defined by the objective element may be instantiated in a yet further embodiment.

A role element that defines responsibilities and access privileges of a community role within the virtual community may be instantiated in an even further embodiment.

A conversation element that defines a structure for interactions among multiple community roles defined by multiple role elements may also be instantiated in an embodiment. The conversation element may, in an embodiment, comprises a plurality of interaction channels including a primary interaction channel and a secondary interaction channel, and wherein a first participant is granted access to both the primary and the secondary interaction channels and a second participant is granted access to only the primary interaction channel.

A glossary element that specifies a shared vocabulary of the virtual community may, in one embodiment, also be instantiated.

A setting element that defines a setting, comprising a structure of interactions toward achieving the objective defined by the objective element, may be instantiated in one embodiment.

At least one subject element may be instantiated as part of the setting, the subject element being descriptive of interactions in the setting and having attributes that represent potential deliverables of the setting.

At least one reference element may be instantiated as part of the setting, the reference element representing knowledge constructed outside the setting defined by the at least one setting element but for use within the setting.

At least one special setting role element that extends responsibilities and access privileges of a community role within the setting may be instantiated as part of the setting.

At least one knowledge flow map element that defines communication of information between the at least one setting element and a further setting element may be instantiated as part of the setting. The knowledge flow map element may optionally define at least one input for first information defined outside the setting, the at least one input to receive the first information into the setting. The knowledge flow map element may also define at least one outcome for second information defined within the setting, the at least one outcome to output the second information from the setting. The knowledge flow map element may further define a control flow specifying an ordered sequence of access to multiple settings according to event occurrences within the virtual community. The knowledge flow map element may also define a control flow specifying an ordered sequence of access to multiple settings according to availability of deliverables of the multiple settings.

In one embodiment, the at least one setting element defines either role- based or identity-based naming for participants within the setting.

A conversation element that facilitates communications within the virtual community outside the setting defined by the at least one setting element may optionally also be instantiated.

A narrative element that captures narrative of participants within the setting, the captured narrative being presentable outside the setting as a description of interactions within the setting may optionally also be instantiated.

According to a further aspect of the present invention there is provided a system for creating a model-driven virtual community having at least one objective. The system includes a collection of templates that constitute partial descriptions of respective elements of the virtual community and an instantiation mechanism to facilitate instantiation of the collection of templates to generate the elements of the virtual community, the elements of the virtual community specifying structural and behavioral constructs of a model according to which the virtual community is structured and operated to progress towards achievement of the at least one objective.

Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example in the following drawings in which like references indicate similar elements. The following drawings disclose various embodiments of the present invention for the purposes of illustration only, and are not intended to limit the scope of the invention.

Figure 1 is a block diagram illustrating an exemplary embodiment of a project community.

Figure 2 is a block diagram illustrating an exemplary embodiment of a system for developing a project model and a project community.

Figure 3 is a block diagram illustrating further details regarding an exemplary embodiment of instantiation of a project model to develop a project community.

Figure 4 is a block diagram of an exemplary network-based communication system that may be utilized to implement a project community.

Figure 5 is a high level illustration showing an exemplary embodiment of utilization of an application server with an object model and compiled scripts.

Figure 6 is a block diagram illustrating the architectural detail of exemplary embodiments of a client module and an application server.

Figure 7 is a flow chart illustrating an exemplary method by which an application server may handle a request received form a client module within a network-based project knowledge management system.

Figure 8 is a flow chart illustrating an exemplary method by which an application server may construct a response to a client request within a network-based project knowledge management system. Figure 9 illustrates an exemplary response pattern in the form of an XML-formatted string.

Figure 10 is a flow chart illustrating an exemplary method by which a client module processes a request received from an application server responsive to a client request within a network-based project knowledge management system.

Figure 11 is a block diagram illustrating the structure of an exemplary setting object.

Figure 12 is a flow chart illustrating an exemplary embodiment of a method by which a client module may process and respond to the occurrence of a user event in a network-based project knowledge management system.

Figure 13 is a flow chart illustrating an exemplary embodiment of a method by which a client module may poll an application server for the purpose of identifying changes pertaining to a project community implemented utilizing a network-based project management facility.

Figure 14 is a flow chart illustrating an exemplary embodiment of a method by which a client server may export data to an external tool application via a tool bridge within a network-based project knowledge management system.

Figure 15 is a diagrammatic representation of a machine in the exemplary form of an computer system in which a set of instructions, for causing the machine to perform any of the methodologies of the present invention, may be executed.

Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows. DETAILED DESCRIPTION

A method and apparatus for generating, operating and updating a computer-implemented project knowledge management facility are described below. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present inventions. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific and exemplary details.

OVERVIEW

The present invention pertains to a network-based communication system in which members of a team working towards a common objective may communicate and interact in the pursuit of activities required to achieve the common objective. The network-based communication system, in one exemplary embodiment of the present invention, provides a number of virtual contexts (or settings) within which the communication and interaction occur, defines participants for the communications and interactions, specifies a number of metrics for measuring progress towards the common objective, defines a number of activities or communications that should be undertaken in achieving the common objective, and provides the mechanism by which previous communications and activities may be reviewed or recalled.

The present invention also pertains to a method of generating and maintaining such a network-based communication system, and to a method of employing or operating such a network-based communication system within the context of a business process or transaction.

It is helpful to consider the import of the terms "project model" and "project community". The present invention proposes a method by which a project community is generated as an instantiation of a more general project model. For the purposes of the present application, the term "project model" may be taken to refer to a generic system that may include (1) project components (e.g., purpose, objectives and measures, roles, processes, information, conversations, and reports) and (2) relations among the project components. As such, a project model may be said to refer to an explicit structure of information creation, update and conversations about that information which relates to the accomplishing of a shared result. As such a project model may consist of specific project activities, and a description of the context in which these activities should be performed to produce desired outcomes. The description of context includes the inputs to the activities, the outcomes that should be produced, who does the work, the structure of the information that contributes to producing the desired outcomes, and how this information is located, used and modified. A project model may be viewed as a partial description of elements of a project community. The partial description may embody accumulated knowledge of "best practices" for a specific project community type (e.g., a magazine publishing project community). For example, project models may be established for a number of project community types (mainframe development, package application installation, newsletter production and standards development), each project model embody accumulated knowledge of the best practices with respect to the project community type. The term "project community" may be taken to refer to a network-based communication system utilizing a set of contexts in which team resources perform activities to achieve the purpose of the project, and incorporating techniques for navigating among the contexts, and exchanging information among the contexts. Accordingly, a "project community" may be viewed as a model-driven virtual community designed to support team communications, management and accountability of commitments, and learning.

The user of a "project community" interacts with other users in the context of one or more settings. The user is represented in a setting in terms of a user's identity or role, according to whether the setting is identified as an identity-based or a role-based setting. The user is presented with two aspects of the setting, namely (1) the application of the setting, in which subjects are created and updated and in which later application may be displayed and (2) the tools of a setting with which the user prepared contributions according to the function defined in the application.

In an exemplary embodiment, a graphical user interface (GUI) through which the user interacts with the project community and participates within a setting, that includes a (1) shared area and a (2) private area. Information concerning the application is displayed in the shared area, and any information viewable in this shared area is shared with all participants in the setting. The information and tools available to the participants are displayed in the private area and, until a participant takes action to share the information prepared with the tools, this information is considered private to the user. Private information is stored in a persistent representation of the project community as belonging within the setting and to a particular role identity, depending on whether the setting is identity-based or role-based.

Certain aspects of an application in a setting, such as whether the application functions are accessible or which application is viewable, can be defined as accessible only by certain special setting roles. Similarly, tools can be constrained as being available only to certain special setting roles. When a user enters a setting, the system managing the project community recognizes the user as an identity or a community role, determines whether the user should be assigned a special setting roles, and then presents the application or tools to which the particular user has access.

Monitors and watch scripts (that are detailed below) may belong to a setting or to a project community generally, but are owned by a particular identity or a role, and offer a mechanism by which a user (either as an identity or as a role) expresses interest in events and relationships among project elements of a project community, and is informed about these events or updates to the relationships. When a user enters the community, any monitors defined as belonging to the user's identity are displayed. When the user chooses a role, or switches to a new role, that role's monitors are displayed along or with any identity monitors. If another user assumes a role for which monitors were previously created by some other user, this new user is presented with the relevant monitors. The monitors, via the GUI, signal to a user that an associated setting should be visited. A user may select to visit the setting by use-selecting the relevant monitor (e.g., double clicking on a graphic icon associated with the monitor).

Watch scripts are also used as a way to express when to update a metric value as part of a mechanism for observing progress towards objectives.

Figure 1 is a block diagram illustrating a project community 10, according to an exemplary embodiment. The project community 10 is shown to include a number of components that each comprises a project element (PE). A detailed explanation of the structure, contents and purpose of each of the shown project elements will be provided below following a high level overview.

The project community 10 is shown to include a number of project elements 12-44. While only a single example of each of the element types is shown and described below, it will be appreciated that a project community 10 will typically include a number of elements of each element type. A purpose element 12 defines the reason why the relevant project community 10 was instantiated. An objective project element 14 provides a time targeted and quantifiable statement of an aspect of the purpose of the project community 10. An objective is formulated from either a business, team, or individual perspective. A measure project element 16 provides the statement of a question whose answer helps determine whether an objective stated by the objective project element 14 is obtained or not, and may provide a specific calibration or reference indicator to measuring progress towards a stated objective. A metric project element 18 refers to a data item utilized in the calculation of a measure stated by a measure element 16, and to be utilized to measure the current status of an objective or progress towards an objective as stated by an objective element 14.

A role project element 20 provides a representation of the assignment of responsibilities and skills to a team member within the project community. Within a single project community 10, a number of such "community roles" will be defined, and it is possible to assign a single member more than one role. Role project elements 20 may be utilized to organize team structure, assign project authority in terms of access to project activities, and give access to project elements. Multiple individuals may be assigned to a single role project element 20 (termed a "reference group") to indicate collective responsibility and authority.

Each role project element 20 may be defined as existing or participating within any number of settings, defined by setting project elements 22 described in further detail below. Further, a role project element 20 may be defined as a "special setting role" that has special responsibility and access privileges within the context of a specific setting. One or more community roles are associated with each special setting role, thereby extending, for the purpose of that setting, the responsibilities and authorities of the individual or individuals assigned to the community roles. When a role is defined as a collection of individuals, any message (e.g., a notification) that is sent to the role is sent to, or accessible by, all individuals, of the collection of individuals, simultaneously. Any contribution to community information (e.g., changing an attribute of a project element or submitting text to a conversation), is understood as having originated from all individuals associated with the role, and not from any one of them, regardless of the actual individual that made the contribution. However, only one individual acts on behalf of the collection of individuals (i.e., "holds the batton") at any one time and it is possible to trace which individual action made the particular contribution on behalf of the collection of individuals assigned to a role.

A role defined by a role project element 20 must be distinguished from an "identity" that is assigned to each team member who participates within the project community 10. Specifically, an identity is unique to each team member, and serves to indicate a true and constant identity of the team member to other team members. Accordingly, an identity may be utilized by a team member when interacting with other team members in a social context within the project community 10 (that is, in a setting in which community roles are not essential to the function of the setting).

A setting project element 22 defines a framework or context within which activities and communications take place towards achieving one or more of the objectives of the project community 10. A setting project element 22 states, inter alia, subject elements 24, special setting role elements 26, reference elements 28, and knowledge flow map elements 32, each of which in turn comprises a project element. Settings defined by a setting project element 22 may be "locations" of the virtual community within which team members can access and share, information, participate in shared applications, communicate with respect to certain topics or with respect to the achieving of certain objectives. Settings may also be locations of the virtual community in which team members may congregate for the purpose of social interaction. Examples of settings that may be defined within a project community 10 by respective setting elements 22 are a task scheduling setting, a design review setting, a defect reporting and review setting, a budgeting setting, a team cafe setting, and a vocabulary negotiation setting.

A setting may be role-based or identity-based, depending on the purpose of the setting. For example, a work-intensive setting may be role- based, whereas a setting having a more social flavor may be identity-based. The decision whether a setting should be role-based or identity-based may be made by the creator of the project model that forms the basis for the project community or users within the community creating an instance of a setting, and may be made by taking into consideration whether the interactions within the setting are linked solely to the individual or should be shared among individuals assuming a particular community role.

In one embodiment of the present invention, a collection of setting project elements 22 may define a network of settings having a hierarchical structure that represents a project work breakdown and thereby the exchange of information among the various aspects of the project work.

The subject elements 24 constitute project elements 66, discussed below with reference to Figure 3, that are defined in the context of the relevant setting, and therefore accessible for change only within the context. Each subject element 24 represents the knowledge being constructed about interaction within the setting defined by the relevant setting project element 22. The special setting role elements 26 each record the assignment of authority to access certain activities within the setting, or to read, update, insert or delete aspects of a project element defined within the setting.

A special setting role element 26 is declared in a setting, and used to control access to the setting subjects, references, activities, and parts of the project map within that setting and to define extended responsibility to a participant within a setting.

A reference element 28 is the name and type declaration of a project element 66, or a template for a project element (to be detailed below), as defined in the context of the setting project element 22 and therefore accessible for change only within that setting context. A reference element 28 embodies additional useful knowledge constructed outside the relevant setting element 22. Such project elements 66 may comprise scripts (to be detailed below) or templates 64 also discussed below with reference to Figure 3.

A channel element 30 defines a channel (or pipeline) for the transport of data from one setting to another. The channel elements 30 may define various filtering or transformation functions. Channels may be used to communicate, for example, moods, current opinions, and side comments. A channel may also be used to keep conversation participants aware of the key issues being raised or of priorities for the topics, and so on. Every participant in a conversation has access to the main channel of interaction, but not all participants will necessarily have access to every side channel. Consider the following example from a popular television show, recast as a project community conversation.

The purpose of the Conversation is to argue a position in front of a judge and jury. The various community identities are mapped to special setting roles: Judge (one of these), Juror (several of these), Plaintiff, Plaintiff Attorney, Defendant, Defendant Attorney, Recorder, and Audience Member (several of these). In this example, four channels may be provided utilizing four corresponding channels elements 30: 1. Main interaction channel: Only the Judge, Plaintiff, Plaintiff Attorney, Defendant, and Defendant Attorney have the tool to make contributions in this channel. Everyone else can view the sequence of contributions.

2. Voting channel: Only Audience Members have a tool to make a contribution in this side channel. They can choose either the response thumbs up or "thumbs down". The Recorder can see the channel, but no one else has access. Any Audience Member can choose to change their thumbs at any time.

3. Side Bar channel: Only the Judge, Plaintiff Attorney, and Defendant Attorney have access to this side channel and all three have a tool to make contributions as well as view all contributions.

4. Decision channel: Only the Jurors have access for their own discussion.

A knowledge flow map element 32 defines an ordered or unordered sequence of process steps, each of which comprises a way to access project settings. These steps may specify the flow of information from one setting to another. Accordingly, a knowledge flow map element 32 may define multiple inputs, each input being declared as a subject in a current setting containing the knowledge flow map. A knowledge flow map element 32 may also define multiple outcomes, each outcome being declared either as a subject element 24 or a reference element 28 within the current setting. A process step of a knowledge flow map element 32 is typically named with an identifier and acts as a gateway to either one or more other settings. When a process step provides access to more than one setting it is referred to as a "collection" of settings. A process step may include start conditions, indicating whether any role or identity might access the setting or settings associated with the step. It may also include a sequencing connector indicating the requirement to wait on the result of another process step before access to it becomes available.

The project community 10 also includes a decision framework element 34 that provides a specific description of a set of decisions to be made by an instantiator creating an instance of a project model or a template defined as part of the project model. Associated with each decision is a set of alternatives (choices or options) and criteria for picking one of these alternatives. Accordingly, a decision framework element 34 provides a project team with options for carrying out a specific project, and provides criteria for selecting options. These criteria are typically determined based on an historical record of prior use of the project model in other project communities.

The virtual project community 10 also includes a decision framework element 34 that provides a specific description of a set of decisions that an instantiator 54 creating an instance of a project model should make. Each decision is termed a "decision topic." Associated with each decision topic is a set of alternatives (choices or options) and criteria for picking one of these alternatives. Accordingly, a decision framework element 34 provides a project team with options for carrying out a specific project, and provides criteria for selecting options. These criteria are typically determined based on an historical record of prior use of the project model in other project communities.

A conversation project element 36 provides a structure for a managed dialogue among roles defined by respective role elements 20. Specifically, each conversation project element 36 is a setting designed to provide services appropriate to managing synchronous or asynchronous discussion contributions by the roles. Accordingly, conversations may be agenda (topic) driven and may be controlled with special leadership (special setting roles) and queuing rules. As an example, discussion contributions can be organized as a tree structure in which each child node is a comment made in response to the comment stored in a parent node. Such discussions may conveniently be termed "threaded discussions".

A chat/page element 38 provides the ability to hold discussions within the community but outside the context of any one setting. A "chat" is an informal realtime or asynchronous exchange among one or more community users. (Holding a conversation with oneself can be a useful method for keeping personal memos). A "page" is a short message sent for the purpose of getting a user's attention to some event or notifying a user of some event. The chat/page element 38 may provide the capability for responding to a page, and constructing and participating in multiple chats.

A narrative project element 40 provides a story, or report, based on the status or history of the project community 10, and may include an application in which to generate and interact with a "story" about the project community 10. Three primary forms of narratives may be provided for a project community 10, namely status reports, team member opinion on current status, and replays /reviews of history. A glossary project element 42 provides an explanatory vocabulary list (i.e., a list of terms and definitions that explain each term) for use within the project community 10. As such, the glossary project element 42 provides a shared vocabulary that is part of an organizational model and may reflect the culture of a team. The historical recording of events in the project community records, among other events, changes to the vocabulary. This historical record may be used, for example, to assist in understanding discussions held at different points in time, with awareness of any changes in definitions for terms.

A library element 44 provides a collection of reusable project elements, such as, for example, settings, narratives, or roles. For the most part, these reusable project elements are partial descriptions that can be instantiated for use in different project communities. We use the term "template" to refer to a partial description, as defined in more detail later. The use of special setting role names that are independent of the role names defined in a particular project community may allow an instantiator of the project community 10 to design a setting that is reusable in different project communities 10 with different community roles.

GENERATION OF PROTECT MODEL AND PROTECT COMMUNITY Figure 2 is a block diagram illustrating a system 50, according to an exemplary embodiment of the present invention, for developing a project model and a project community. The system 50 includes a modeler 52 who is responsible for the creation of a project model, an instantiator 54 who is responsible for the creation of an instantiation of a project model (i.e., a project community), and a team 56 that operates within the context of the project community to achieve the objectives of a project.

The modeler 52 is responsible for defining a project model and generates an instance of the model that is tailored for a specific project. An exemplary project community in the form of a design studio project community is described below. In the context of this example, the modeler 52 may utilize a general business model for achieving a broad business objective (i.e., the design studio business itself) to generate a project that is more focused towards a specific environment (i.e., the design environment for creating a magazine, a design project consistent with the purpose of the design studio business). The instantiator 54 is responsible for instantiating the project model developed by the modeler 52 to provide the specific project elements (structure, templates, and other information) of a project community. The instantiator 54 is accordingly responsible for defining a project community based on an instance of a project model, for deploying the project community for use in an actual project, and for updating the project model based on a review of the history of the use of the model in one or more project communities. The project team 56 is responsible for utilizing the project community developed by the instantiator 54 to facilitate achievement of the objectives of the project specified within the context of the project community.

Of course, the modeler 52 and the instantiator 54 may comprise a single person, or team of persons, and accordingly be responsible for both the development of the project model and the project community. The person responsible for updating the project model need not be the same person as the one fulfilling the responsibilities of the instantiator 52.

As shown in Figure 2, the project team 56 provides feedback to the instantiator 54 regarding the team experiences within the project community. Feedback might be provided in the form of the historical record of how the project team used the project model. The modeler 52 or instantiator 54 may then utilize this feedback information to improve the project model and /or to modify future instantiations of a specific project model. One form of improvement and /or modification is to extend the criteria and /or options of a decision topic in the project model's decision framework. Similarly, the instantiator 54 provides feedback to the modeler 52 regarding experiences pertaining to the project model, and the modeler 52 shares these experiences and those of the modeling activity to the creators of the project modeling capabilities (language, tools, library).

PROTECT ELEMENTS AND TEMPLATES

Figure 3 is a block diagram showing further detail regarding the instantiation of a project model 60 to deliver a project community 62. Specifically, the project model 60 may present a number of templates 64 that are instantiated by the instantiator 54 to deliver corresponding project elements 66 specific to the project community 62. For example, an instantiator 54 may wish to create an instance of an objective template 64. The objective template 64 is a partial description for an objective project element, to be a part of every project community based on this project model. A project element consists of one or more attribute-value pairs. A description of a project element may, in one embodiment, be regarded as partial when at least one attribute is associated with instructions for determining the value, rather than a literal value. Possible instructions are to retrieve a value from an external persistent store, to ask the instantiator for a value, or to evaluate a script. A script is itself a project element that is made up of a sequence of well-formed expressions in a Project Modeling Language (PML), as defined in more detail later. Completing the template's partial description creates instances (i.e., project elements 66).

Figure 3 also illustrates the partial instantiation of a template 64 to generate a community template 67 that is included within the project community 67. This partial instantiation may include associating value with certain attributes of the template, while maintaining certain other attributes without values. These other attributes may optionally be assigned values by participants within the project community 67.

A project model 60 may specify that the project community 66 based on the model 60 includes a set of templates, for example, templates representing partial descriptions for possible settings, conversations, or narratives that may be created in the community. A project team 56 that uses a project community 62 created by an instantiator 54 can modify or extend that community 62 by creating instances of one or more included templates 64, if any.

To explain these and other aspects of a project community 62, an explanation is given below of exemplary project elements 66, templates 64, and the Project Modeling Language, including scripts.

Elements

Project elements 66 (hereinafter referred to simply as "elements") may be instances of templates 64 and may be defined in terms of a set of attributes and values. Some of these attributes are expected for every element, while other attributes are added to further specify the element. A template 64 is a partial description in the sense that at least one of the values is not provided. Rather a specification is given of how to obtain the omitted value or values. Such specification takes the form, for example, of a sequence of expressions to be evaluated that might, in turn, calculate the value or retrieve the value from a persistent data store, or request that the user either provide a value or select it from a list of decision framework options. Creating an instance of a template means to create a new project element whose attributes are the same as those provided in the template and whose values are those provided in the template, either literally or as determined by the specifications.

The attributes shown in Table 1 for an exemplary element 66 may be present in all elements 66 (instances of templates 64) in a specific project community 62.

Table 1

Name. The identifier that can be used to refer to the element 66 in scripts or attribute values of other elements 66.

Type. Indicates whether the element is an Instance or a Template.

Owner. The role that created the element 66. Only the owner or a role holding a write access may modify the values of the element.

Comment. A text string that describes the intended use for the element in the project community. Limit. If the element type is Template, then it is possible to specify the maximum number of instances that can be created. If no number is specified, then an unlimited number is allowed. Timestamp. The date and time of day when the element was created. Discussion. A String or an R_Script (these project modeling language elements are described below) that serves as a reference to a project element, either the name for an element within the project community or a URL to commentary (including possibly to a threaded list of commentaries) accessible from outside the community (for example, a Web page). Access. A list of roles that give access permissions to this element. A role's access may be defined as Read, Edit, or Evaluate. For a project community 62, a default role is defined and set up as the default role for any element. Roles named Reader, Writer, and Evaluator role may also be provided. Reader is typically the default special setting role. By default, community roles are assigned the default special setting role on entry to the project community.

Value. The primary value of the project element 66, which by default is the element itself.

Templates

It may not always be possible to fully specify all of the project elements 66, settings, or other aspects of a project community 62, in advance of actually creating a particular community 62. Indeed, it is not always possible to fully specify everything in advance of the use of a particular project community 62. Project elements 66, such as reports or settings, might be created as a consequence of user action. Accordingly, the present invention proposes a mechanism for instantiating partial descriptions or templates 64 in order to support:

• The ability to define a general project model 60 and create instances of that model 66;

• The ability to define project elements 66, such as narratives and settings, whose instances can be created by team members; and

• The ability to specify that two or more project elements 66 should be grouped together for purposes of coordinated creation and use.

A template 64 is a way to define a data structure, and instantiation of a template is a way to create replications of the data structure A template incorporates the use of references to design topics defined as entries to the project model decision framework. The use of design topics within a template 64 provides a way to specify alternative instance values, including values that refer to reusable project elements. The use of decision framework provides a way to incorporate the experience of prior related project communities into the definition of the project model 60.

The construction of the information structures that form a project model 60 are based on two component types: template and grouping_template. All attributes defined for a template 64 in a particular project community are repeated for all instances 66 of that template in the community. A template 64 is a partial description that has all the attributes specified, but the values of these aspects may be literal or are determined at the time of instantiation. A user-defined template is created from an existing template by copying the attributes and literal values, and replacing only some of the value specifications. Or a user-defined template is created from an existing template by copying the attributes and values (literals and specifications) and then adding new attributes with values that are either literals or specifications.

It is possible that a value of the attribute of a project element template 64 is itself a template, for example, the value could be a textual string but not all phrases in the string are known. Rather, these phrases are specified as to be determined at the time that an instance of the project element template is to be created. These variables may, for example, be given within angle brackets < >, and specified in terms shown in Table 2.

Table 2

The values are obtained as part of the process of creating an instance of the template 64. When an instance is to be created, each attribute is considered. The value of the attribute can be a literal (a constant in the Project Modeling Language, such as an Integer, as noted later), or a variable. Whenever a variable is encountered, the value is retrieved either by creating a reference to the project element, creating an instance of the named template, executing a script, interacting with the user who in turn provides a value, or presenting decision topic alternatives to the user for user selection.

The specification for interacting with the user is a user inquiries of the form:

<Identifier>: <String> where Identifier is the name of a primitive element in the Project Modeling Language, as defined later, thereby denoting the type of value to be provided (for example, Integer, String, Boolean), and the String is a comment to be presented to the user to request the value of this type.

As noted earlier, a template 64 can contain templates, that is, the specification for a value of an attribute can name a template, and therefore the desired value for the attribute is intended to be an instance of the named template. Implementation of the instantiation process may be depth first (recursively create the instance of a template specified as a value), or breadth first (complete all attributes of a template whose values are not themselves templates before creating instances of templates that are values).

The instantiation process continues until no further variables are encountered.

String Template

A string_template is a special kind of template that can serve as the value of an attribute of a project element. It is basically a string with one or more embedded user requests, where a user request can be of the form: <STRING: 'request to provide a string' > <NUMBER: 'request to provide a number'> <BOOLEAN: 'ask a question whose answer is true or false'>

Grouping Templates

A grouping_template is itself a template 64. It holds onto two or more other templates 64. These templates 64 have been grouped together because, whenever an instance of one of these templates 64 is to be created, an instance of each of the others must also be created. Moreover, the use of all of these instances has to be coordinated. For example, in one implementation of a user interface for a project community, coordination may be specifically designed to keep all instances in the same user work areas, either in the user's private work space, or the team's setting shared work space.

An exemplary definition for a grouping_template is shown in Table 3.

Table 3

Templates. The templates 64 in this list have to be coordinated, notably kept together when moved about the works of the community. Names. These are temporary names created while the instance of the grouping_template is being created. The list of Names has to be at least as long as the list of templates 64. The instances of the templates 64 are created and given the next name in the Names list. Initialize. When an instance of a grouping_template is requested, two actions are taken:

• Create instances of each held template 64. Give these instances temporary names from the Names list, in the order presented.

• Create the relations, if any, among the newly created instances, for example, by having the value of an attribute of one of the new instances reference one or more of the other instances. This action is specified as the value of the attribute Initialize for the groupingjemplate.

For the example, supposing that ST is a SettingCollection Process Step, then a grouping_template is:

Table 4

PROTECT ELEMENT CHANGE NOTIFICATION As a part of the general capability for watching events and monitoring values of project elements described when detailing the basic templates for constructing a project model, the expressiveness of the project modeling language, and architecture of a project community (all detailed later), it should be noted here that it is possible for the modeler 52 or member of the project team 56 to declare an interest in the change of value for an attribute of a project element, and to specify how the project team 56 member should be notified that such a change occurred.

EXAMPLE BASIC TEMPLATES OF A PROTECT MODEL The details of a number of exemplary templates 64 that may be provided in the form of a project model 60 to an instantiator 54 are described below. In giving these examples, to present the values of attributes, we adopt the notation that terms enclosed in angle brackets denote that a particular instance of an element of the Project Modeling Language or of a template is to be provided as the value. Any other value is assumed to be literal as written. Since all examples are of templates, the Type attribute with value Template is omitted. In addition, most of the other basic attributes presented in Table 1 are not shown. Their omission is not to imply that they are not part of the specification of the example template. Explanation of an attribute is given where not already provided in the description for Table 1, or where further explanation is deemed useful. Also where useful, behavior that should be provided as part of the project community for each of these basic templates is also presented.

Vertical bar denotes alternative possible values. The term "none" is used if no value is required. Where names reference terms not yet explained, the explanation is given at a later point.

1. Purpose

Table 5

Value. A generic description of the purpose of this type of project. 2. Objective

Table 6

Value. Statement. Natural language statement of the objective, a refinement of the project purpose.

Target_time. The date by which the objective must be reached.

Maximum_bounds. Latest possible completion date. None denotes that the target is the latest possible date.

Minimum_bounds. Earliest anticipated date. None denotes that the target is the earliest. Completion_criteria. A measure that answers the question as to whether the objective has been successfully attained, and whether progress is being made.

Status. Indicator of a level of acceptance (various status names should be set by the modeler and then used in specifying any scripts within the community).

Priority. Measure of importance compared to other objectives; a numerical ordering of objectives.

Behaviors. Queries to find out whether objective is reached, or whether progress is being made towards reaching the objective.

3. Measure

Table 7

Question. Statement of a question whose answer helps determine whether an objective is attained or not.

Value. A script that answers the question as a computable or retrieval value. May include names of one or more metrics, as specified in a

Metric_Table. This script may convert a metric value to suitable scale or for geographic or seasonal adjustment, and so on.

Metrics. The Metric_Table in which to find the values for tokens in the

Value script.

4. Metric Table

Table 8

Includes one or more (Identifier, Metric) pairs. The Metric_Table is a Dictionary of Metrics, whose names may appear in scripts associated with a Measure. Each time a value for a Metric is requested, it is stored in a ValueCache:

Table 9

Where <Element> refers to any project element (an instance of a project model template or a basic element of the Project Modeling Language.

Table 10

The name of an instance of metric can be used in a script that determines the value of a measure.

Source. A script for obtaining a value for the metric.

Trigger. A W_Script that determines the next time to obtain a value for the metric. It is basically of the form:

WHEN time_condition_occurs

DO MetricName.Value add (MetricName.Source); Expected value. In order to know whether the value for this metric is converging on the target, the target value should be specified. Maximum_value. The desired value could be in a range, in which case this is the upper bound.

Minimum_value. The desired value could be in a range, in which case this is the lower bound. Value. A cache of each value that was computed, paired with its time and date (that is, timestamp), so that it is possible to examine the history of values for this Metric.

5. Role (Community Role)

Table 11

Role_Type. Single means that the role is fulfilled by only one team member; multiple means that the role can be fulfilled by more than one team member. If the RoleType is Multiple, then any information accessible to one team member is immediately accessible to the others. A message or notifier sent to one is sent to all. Only one team member can be acting on behalf of the role at any time. This team member is referenced as the value of Active_Member.

Responsibilities. A list of text strings, each describing a duty of any team member assuming this role. Could be a template 64 in order to be able to specialize the description for particular projects. Often thought of as the role tasks.

Qualifications. A list of text strings, each describing a qualification that a team member should have in order to assume this role. Could be a template 64 in order to be able to specialize the description for particular projects.

Active_Member. If this is a multiple role, then the identity is one of the team members assuming this role and acting on behalf of the multiply- assigned team members.

6. Special Setting Role

A user displays his or her identity in an identity-based setting, and otherwise his or her current role in a role-based setting. Special Setting Roles are roles that are used to extend a user's responsibilities, skill expectations, as well as authority (access to process steps and project elements 66). The use of a Special Setting Role to define access, rather than an identity or community role, support reuse of settings across project communities 62 by serving as a placeholder for identity or role names that are typically quite different in different project communities. Roles are mapped to the Special Setting Roles as part of defining the instance of the project model.

Table 12

Limit. None, if there is no limit, a number otherwise to indicate the maximum number of users that can assume this Special Setting Role. Read, Edit, Evaluate. Each of these attributes of a Special Setting Role extend the notion of a role to specify different access permission within a setting.

tting

Table 13

Purpose. Statement as to why the team members are using this special context in which to carry out a well-defined set of activities.

SettingType. Role indicates role-based naming for the user. Identity indicates the user identity is the user's preferred name in the setting.

Access. List the names of users, either using Identity or Role, who are allowed to enter this setting.

Subjects. The name and type declaration of project elements 66, defined in this setting context and therefore accessible for change only in this context. May be defined as a basic component by the modeler or by a team member.

Special Setting Roles. The Special Setting Roles, given as a set of one or more pairs (identifier name, reference to the corresponding project element).

References. The name and associated R_Scripts, that provide access to relevant information either within the project community or accessible from external sources, such as a Web site. Templates. The name and associated project elements 66 or templates 64, defined in this context and therefore accessible for use, change, or instantiation only in this context. The templates 64 are either the general ones provided for all project communities, ones created by the modeler, or ones created by a team member during the use of the project community. In an exemplary implementation, the user interface for accessing these templates might offer a step-by-step procedure that the user can follow to create instances of the templates or review the scripts. Knowledge flow map. The List of the names of the Processes that defines the expected behaviors in this setting.

8. Process Map

Table 14

Identifiers in the process definition are subjects or resources of the setting in which the process is defined. These are all project elements 66 whose types have to be declared so that it is possible to make sure, at the time of construction, that the process definition is consistent. Inputs. A process can have multiple inputs. Each input is declared as a subject of the current setting. Process inputs are used to bring references to information defined outside the setting into the current setting. (By "outside", reference is made to the process step holding the setting in which this process is held.) In this regard, the mapping from the step on the outside to the process input may be viewed as declaring the input to be an R_Script.

Outcomes. A process can have multiple outcomes. Each outcome is declared as either a subject or a resource of the current setting. Process outcomes are used to directly export information to the setting in which the current setting is contained. The outcomes may be mapped to the outcomes of the step holding the current setting. The transfer of information is by copying the values of the elements in the current setting and making the corresponding elements declared as the outcomes referenced to these copies.

Note that the sequence of information exchanges among settings, whereby one setting provides input to another, or delivers results

(outcomes) to another, may be implemented as publish/take versioning system as detailed below.

Steps. A process consists of a set of steps, each of which acts as a gateway to a setting, including a conversation as a special kind of setting. step might also represent access to a collection of settings or conversations. Every step is named with an Identifier.

Access to a process step is determined by its contents. In particular, access to a step is the same as the access of its setting or the aggregation of all settings in a collection.

Step Precondition. A Boolean expression that checks the status of the setting and any inputs to the step to decide whether to take some actions prior to allowing access to the step's setting. Typically answers true or false, whether the user can access the step.

Step Inputs. A step has one or more inputs. The inputs are passed to the action or setting held by the step. Information is passed for read only use only, i.e., a reference is passed. Step Action. A step action can be one of two kinds of elements 66. A setting might be a conversation and it is possible that this distinction is made visually in a user interface of an implementation for project communities.

Setting Invoking a step within a setting creates a change in context to the referenced setting. This action is one possible form of navigation through the project community. The only information passed from the current setting to the new one is information specified as inputs to the step. Setting Collection A Setting Collection step is a placeholder for zero or more steps that cannot be specified at the time the process is defined. Rather, there are several choices of templates 64 for Settings, defined as Templates of the setting. The user selects a template 64 to create an instance, and places it in the process. If the instance is placed in an SettingCollection, then all the inputs to the SettingCollection are passed to the Setting. The outcome of the SettingCollection is an ordered collection of outcomes of each Setting that was placed in the SettingCollection.

Step Outcomes. A step has one or more outcomes. Each outcome is declared as either a subject of the current setting. If the names of inputs and outcomes are the same, then they refer to the same subject of the current setting.

Step StepType. Only relevant if the step is a SettingCollection.

Provides a list of names of the templates 64 whose instances can be placed into the step. Connections. The purpose of a connection is to specify sequencing control among process steps. A connection is either on or off. If it is on, then the implied precondition that the source step be ready is set to true. If the connection is off, then the implied precondition that the source step be ready is set to false. In this circumstance, the step associated with the input is not accessible to any user.

Name. Connection names are simply integers.

From. <Identifier> names the step that is the source of the connection.

To. <Identifier> names the step that is the destination of the connection.

Status. On' or 'Off, the current status of the connection. Script. A connection can have an Action_Script. As such, the connection can examine the status of the inputs or outcomes, or other aspects of the current setting, and take action to change one or more aspects of the setting. Of especial interest, for example, is to test whether an outcome has an assigned value or has changed its value, and based on the test, decide whether to change the status of the connection.

If an input to a step is not defined in a connection as coming from another step, then that input is obtained directly from the context of the current setting (i.e., it is simply one of the subjects of the setting). Access to a step is therefore determined in three ways:

1. whether the user identity or role is named in the access list,

2. whether the precondition of the step is satisfied, and

3. whether all input connections are "on". Connections are, by default, turned on.

Applications. A setting is in reality an application context, a place where a related set of activities can be presented, invoked, and coordinated, in the context of named information. The modeler has the ability to specify subapplicafions that can be shared or appear in a private work area. The particular details of what an individual can do in either the shared or private work areas can be dependent on who the individual is and what role the individual may have currently assumed.

Applications can be shared or private as noted:

Shared. A description of any special activities to occur in the shared work area, where typically process team members with access to the setting can view the current status of shared information.

Private. A description of any special activities to occur in the private work area of an individual team member.

9. Decision Framework

Table 15

Name. As noted earlier, the name of the instance of a decision topic may appear as a value for the attribute of a project element. If so, when the project model is instantiated, the user will be asked to examine the decision framework and make a choice as to the actual value to be inserted.

Value. Statement explaining the decision that needs to be made.

Table 16

A Decision_Framework is a table, keyed on the names of each <Decision_Toρic>. Associated with each topic are:

Choices. A list of possible decision choices, each a <String>. Criteria. For each decision choice, an explanation of the circumstances under which a choice is best made. Each explanation is a <String>.

Discussion. Possible discussion held by the modeler or modeler with instantiator about one of the possible choices.

0. Conversation

Table 17

Purpose. Statement as to why this conversation is being carried out.

SettingType. A conversation is a special kind of setting and as such has the choice as to which names are used to refer to users, either users' current role names or actual identities.

Access. The list of roles or identities with access to participate in the conversation.

Subjects. Information to be shared as part of the conversation.

Special Setting Roles. As in setting.

References. As in setting.

Templates. As in setting.

Organizer. A list of topics to be discussed, or a rule by which topics are selected for discussion. If none, then the conversation may be about anything.

Participants. A list of the roles that participate in this conversation.

Although access via roles might be sufficient to identity who can participate in the conversation, the purpose of this attribute is to provide an explicit list to which the Organizer or Process can refer as to who current is in the queue to contribute.

Channels. A list of channels, which are side conversations to the main conversation, and which may represent additional aspects of the conversation application, for example, summaries of issues, suggestions, voting, moods, and so on.

A Conversation is an exchange of comments on some topic among two or more team members. It is represented as a collection of commentaries. The commentary structure may be linear, tree structured (often called a threaded conversation), or some other organization of information as needed to represent the manner in which the exchange has or is taking place.

A Conversation may be represented as an application that is used to create, modify, and explore the commentary structure.

11. Narrative

A narrative may conveniently be viewed as a "story". In some respects, the modeler's job is to propose a "story" about how a yet-to-be-defined team of workers will carry out a project. The project is then formed, the team members assigned, and the project carried out. While the project is carried out in the context of a project community 62, two things transpire:

(1) The state of the project evolves; and

(2) Memory of the evolution is retained as a log of project transactions.

In addition, project team members might contribute explicit statements to be incorporated into a narrative that the team constructs about the current state of the project.

The story about a project is about how the project evolved and why. The project model 60 may be viewed as the story line and the team members the primary characters. There are other characters, observers who can comment on how the project state and evolution was predicted by the modeler 52, and observers who can discuss where and why there are differences in the prediction. These "observers" of course are provided as a service of the project community narrative functions.

There are any number of stories that can be told about a project, depending on the readers' interests. Four examples of kinds of narratives that may be provided for a project community include: Status reports Constructed much like templates 64 as a series of literals and embedded variables that query the community for the current facts and present them in a possibly preset format.

Setting Narratives An aggregation of textual contributions made by any team member with access to a particular setting, that serves to describe or explain what is going on or has transpired in a particular Setting. May be useful as a way to give information about a Setting to individuals who otherwise do not have access to the Setting.

Histories There are many possible stories referencing the history of events in a project. As an example, a history may be constructed as a sequence of significant milestones and summaries from the project history log of how these milestones were reached. The milestones may represent a storyline, roles that participate in creating these milestones are characters in the story, and other interested team members and other observers are commentators on the story.

Replays Constructed by using the events in the history log as the data for an event-driven simulation.

Table 18

Structure. The narrative is an unformatted report, simply a sequence of literals and scripts. In an alternative approach, the script elements may be provided as special insertions in a word processor so that a report can be written by a team member and sent into the community to effect change. Trigger. The report can be generated by user request for an instance or a Watch Script can be set up to choose a condition, such as a date and time, when the report should be generated. PROTECT MODELING LANGUAGE (PML)

The present invention proposes a language (namely a Project Modeling Language) utilizing which a modeler 52, instantiator 54, or member of the project team 56 may express how a particular project is to be carried out.

The purpose of the project modeling language (PML) is to provide a textual language by which a modeler 52 can define both the structure of a project community 62 and the processing to take place in that project community 62. The structure consists of instances of elements 66, user-defined templates 64, and instances of the basic project templates 64. The project modeling language may be used to define a project model 60 in a general way (e.g., templates) that can be reused in multiple project communities 62.

The language provided for the PML can be any programming language, as long as the language includes the ability to interface with the notification and other project community library functions. Languages such as Smalltalk or Java satisfy this requirement. We also describe here a new language, specifically designed to be used by team members who are not programmers but who may wish to define PML action sequences as part of their use of the project community 62.

Within the project community 62, PML action sequences define:

• Resources in settings (Q_Scripts, R_Scripts, and W_Scripts);

• Subjects in settings (Action_Scripts), typically used in process steps for actions; and

• How Objectives are measured (questions associated with Measures, ways to determine Metrics, when to compute the value of a Metric).

The design for a language is based on declarative statements with no assignment to variables occurring in any action sequences. Elements in the language are constructed as dictionaries of attributes and behaviors, which are collectively referred to as the aspects of the element. Changes in values are handled as accessing operations inserting new values to the existing aspects. The early variables that may be assigned to the value of those predicted as the aspects of an element 66 or a template 64.

Primitive Data Types

These elements are the literals of the language.

String an ordered, indexable collection of characters. Literal notation: characters delimited by single quote.

Standard magnitude comparison operators (= < >

>= <= ).

Indexing operations.

Concatenation (produces new string).

String_Template string with embedded scripts. Number a magnitude representing an integer or a floating point number; these are expressed as literals

Standard literal notation for integers, floats

Standard magnitude comparison operators (= < >

>= <= ).

Standard arithmetic operators (+ - / * % ).

List an ordered, indexable collection of data elements, either primitive data types or project elements 66.

Literal notation: list of element names and literals, separated by commas, and enclosed in matching parentheses.

Behavior for a List include: first, last, add, delete,

<index>.

Dictionary an unordered collection of values that serve as a key, value pair; the key is the name of the value; hence, in truth, a dictionary is a set indexed by the names of its elements.

Behavior for a Dictionary include: at (index), atput

(index, value).

Time a magnitude representing time of day

Time now current clock. Standard magnitude comparison operators (= < > >= <= ).

Date a magnitude representing day in a month in a year.

Date today current day. Standard magnitude comparison operators (= < > >= <= ).

Boolean true, false.

Boolean operators AND, OR, XOR, NOT. none Denotes that no value is required. Expressions

Identifier

An Identifier is a sequence of alphanumeric characters containing no white space (space or tab or line feed), and no special characters other than underbar.

The identifier none is used in component definitions to indicate where no value is required.

Special Identifiers self Refers to the project element 66 that is processing a request, true One of two Boolean elements and is typically the desired condition for IF and WHILE statements, false One of two Boolean elements, nil Denotes an uninitialized value for any element. All values can determine whether they are nil or not nil, as in

PE.value.isNil; Returns true if the value is nil, false otherwise

PE.value.notNil; Returns true if the value is not nil, false otherwise

Statement Delimiters

Statements are separated by a semicolon (;) and grouped by curly brackets { }. Arithmetic follows normal rules for precedence. Parentheses are used for grouping. Line change, white space, and indentation have no meaning in the language.

Curly brackets with nothing inside is an empty statement and is legal.

Accessing and Setting Values

Where PE is an element 66, and aspect is a legal attribute name of that element, then:

PE.aspect; Returns the value of evaluating the aspect.

PE.aspect (args); Returns the value of evaluating the aspect with args, a list of one or more arguments. SET PE.aspect TO value; Store value as the new value for PE.aspect. DEF PE.aspect TO statements; Store the statements as a sequence that can be evaluated on invoking PE.aspect. The system is largely nondeterministic in the sense that multiple users, with access to the same setting and a role that can edit a project element 66, can all change a value of an attribute of that element 66. This change can take place at any time, which means potentially in the middle of a statement evaluation. The modeler 52 may use special setting roles to provide locks on apparent arbitrariness.

The general form of the notation for referencing aspects of the community

62 is:

<pathway > / <element> . <attributel > . <attributen>

Note that attributes of any project element 66 may be either a single identifier, or an identifier followed by one or more arguments. In writing scripts, a scripter can expect to obtain values. The value is the value of the last statement, or the value explicitly returned.

RETURN value; Returns value as the result of a sequence of statements.

RETURN valuel, value2; Constructs a list as the value returned.

Conditional statements

IF condition THEN actionSequencel ELSE actionSequence2; IF conditionl THEN actionSequencel;

ELIF condition2 THEN actionSequence2;

ELSE actionSequence99;

WHEN condition DO actionSequence;

Here a condition can be any event that might occur or time (clock reaches some particular time) or value of an element 66 gets set to anticipated value, and so on for any anticipated event.

WHEN_CHANGE Element.attribute DO actionSequence;

This statement sets up the special condition that if an attribute's value changes, then the actionSequence will be evaluated.

'Iterative statements BREAK; Terminate the innermost loop. Continue outside the loop or in a declared handler for the BREAK. A BREAK in a non-iterative statement is illegal. CONΗNUE;

Used in an iterative statement to stop processing the current iterative step and continue with the next iteration value. A CONΗNUE in a non- iterative statement is illegal. WHILE condition DO actionSequence;

As long as condition is true, evaluate the actionSequence. WHILE condition DO actionSequencel ON_BREAK actionSequence2;

As long as condition is true, evaluate the actionSequencel. If the condition is exited by a BREAK statement, then actionSequence2 is evaluated. FOR var IN collection DO actionSequence; actionSequence uses var to reference successive items from the collection. FOR var IN collection DO actionSequencelON_BREAK actionSequence2;

If actionSequencel exits using BREAK, then evaluate actionSequence2. FOR varl, var2 IN collection DO actionSequence; actionSequence uses varl, var2 to reference successive pairs of items from the collection. FOR varl, var2 IN collection DO actionSequencel ON_BREAK actionSequence2;

In addition to DO, there are comparable enumeration statements for

COLLECT and COUNT.

Communication Statements

NOTIFY list_of_roles THAT string;

Set up a datagram (page, message) to each of the roles in the list, containing the string. The datagram is from self and remembers the setting from which it was sent.

External Program Interface Statements CALL program WITH list_of_arguments;

Call on a program written in a nonPML language, passing arguments to it. No call back is supported. SCRIPTS A script is a type of project element 66 that computes a reference to other project elements 66 or takes some action that alters other project elements 66. Like all project elements 66, a script has a name, an owner, and permissions for access. The purpose of a script is to express the relation between resources in a container (the project community 62 itself or one of the settings) and information formed and managed outside that container.

Action Scripts

An Action_Script is the representation for a sequence of statements defined as part of the PML. Action_Scripts are used:

• As a named subject in a setting;

• As the action part of a Watch Script.

Table 22

Program. The sequence of well-formed PML statements. Names in the program have to be defined in the context in which the program is executed.

Value. The principal value of an Action_Script is the result of evaluating its program.

Retrieval Scripts

A Retrieval_Script (R_Script) is used to manage the namespace for a setting to allow access both to external documents (for example, via the Web) and to internal project elements 66 stored in the project community persistent store. Expression of an R_Script takes the form of a URL: scheme:/lhostlpath/extra-path-info&query-inf; and scheme is http: oτfip: or file: and so on.

An R_Script cannot alter any project element 66. Its use in a setting is to help the user maintain an awareness of information related to the current work focus. In all cases, information is referenced via a URL. The URL may be fully specified or it may be relative. A relative URL is converted internally to a full URL by pre-pending to it the path to the enclosing setting. R_Scripts are used in two contexts. In both cases, the R_Script acts as a local proxy for an external object:

• As a named reference in a setting, a local name for an object outside the current setting. Note that access to finding the URL of the R_Script requires read access; and

• To provide the project element's attributes in the current setting. If /oo is an R_Script referencing FOO outside the current setting with a defined attribute, bar, then foo.bar is delegated to FOO.value in its home setting.

Table 23

Value. For an R_Script, the principal value is the object pointed to by the URL.

Run. When this aspect is invoked, if the MIME-type of the element 66 referenced is bound to a known application, the application is run on the URL referenced data. When an application can be launched, the principal value returned is true; otherwise false is returned. URL. Returns the script's URL as a string in the form originally specified.

Query Scripts

A Query_Script (Q Script) is used to make simple queries of elements 66, either those in a current setting 22 or outside of the setting 22 and even outside the project community 62. In all cases, all information sources are in the current setting 22 either because they are local to that setting 22 or have been imported to it using an appropriate R_Script.

A Q_Script returns a list of values that match the query. It cannot be used to change any project element 66. Q_Scripts are used in two contexts:

• As a named Resource in a setting;

• As a condition for entering a step, existing a step, or taking some other action (W_Script guard condition). Table 24

Value. For a Q_Script, the principal value is the list of the data which satisfies the query from each of a list of URLs.

Query. A query expressed in the PML. Names in the query have to be defined in the context in which the query is evaluated. Query_URLS. A list of URLs to be searched.

Watch Scripts

A Watch Script (W_Script) is used to watch for events in a setting.

A W_Script is necessarily of the form:

WHEN <guard condition> DO <action_script>; where the guard condition must return a Boolean, true or false. The action_script can alter project elements 66 in its local context. Access rights of the action_script to alter elements 66 are the access rights of the action_script owner. Once the guard condition becomes true and the action_script is evaluated, the decision whether to reset the W_Script to be able to check again is determined by its condition_policy. W_Scripts are used:

• As a named resource in a setting, to monitor future events. When the guard condition is met, execute the action script associated with the condition.

Table 25

Value. Returns the principal value of a project element 66. For a W_Script, the principal value is determined by evaluating the W_Script. Returns nil if the guard condition is false; otherwise returns the value of the action_script.

Install. Installs the W_Scr.pt by making it active. Required initially and after every change. Uses self.condition_policy to identify how to install itself. Returns true on success, false otherwise.

Uninstall. Uninstalls the W_Script by making it inactive. Uses self.condition-policy to identify how to uninstall itself. Returns true on success (uninstall complete); false otherwise.

Condition. Returns the guard-condition language expression which, when true, causes the script to fire.

Action. The sequence of statements that are evaluated when the guard condition becomes true.

Condition_Policy. Sets the policy by which the condition gets tested.

Typically the condition is tested whenever a message from a registered dependent is received (that is, a project element 66 whose change implies the need to check the condition). Other options include evaluating at regular intervals, or evaluating manually.

Monitors

In one embodiment, a Monitor is used to present information about a single value, or about a relationship among two or more values, where the values are attributes of subjects of a setting.

A Monitor is a specialized Watch Script, in that it includes a guard condition that watches for a change in one or more values. The Action associated with the Monitor presents a view of a particular relationship among these values. In one embodiment, this view if graphical and chosen as an easy way for a user to understand the status of the value or relationship. For example, the relationship between two numbers (e.g., a planned and actual budget number) may be shown as a meter or thermometer, progressing to a "red zone" when the difference between the values approach zero.

A Monitor element is defined to have a structure substantially similar to that of Watch Scripts, as defined above, but with additional attributes that contain a list or references to values to be watched, and a way of naming these values so that they can be referenced appropriately in the Action part of the Watch Script. SYSTEM AND SOFTWARE ARCHITECTURE Figure 4 is a block diagram illustrating a network-based communications system 100, according to an exemplary embodiment of the present invention, that may be utilized to implement a project community 10. The system 100 includes a number of client modules 102 that communicate with an application server 104 and a replay server 106 compatible with the Hypertext Transfer Protocol (HTTP) 108 via a network (not shown) such as a Local Area Network (LAN), a Wide Area Network (WAN) or the Internet. In the situation where the client modules 102 access the servers 104 and 106 over the Internet, a web server (not shown) may front the application and replay servers 104 and 106, or the application server itself may provide the standard function of a web server. In the exemplary embodiment of the present invention, the client modules 102 may exchange Extensible Markup Language (XML) packets with the application server 104 utilizing protocol compatible with the HTTP protocol 108. Specifically, once the application server 104 has been initialized, a client module 102 may generate requests to the application server 104 or may poll the application server 104 on a periodic basis.

The client module 102 may itself be a commercially available web browser, a Java enabled browser, or a browser written in some other computer programming language. The application server 104 and the replay server 106 may each be implemented on any one of a number of commercially available software platforms such as, for example Windows NT ® developed by Microsoft Corp. of Redmond, Washington, the Solaris operating system developed by Sun Microsystems of Mountain View, California, or some variant of the Unix operating system, such as the Linux operating system.

The application server 104 is in communication with a database management system (DBMS) 110 that manages the storage and retrieval of data from a database 112. The application server 104 may communicate with the database management system 110 using the Open Database Connectivity (ODBC) protocol. In an exemplary embodiment of the present invention, the database management system 110 may be an SQL server developed by Microsoft Corp. or by Sybase Inc. of Emeryville, California. Other database management systems are available from Informix Corp. of Menlo Park, California, Oracle Corp. of Redwood City, California, and IBM of Armonk, New York. The application server 104 is also shown to be in communication with a software module referred to as a "toolbridge" 114 via which the application server 104 is able to export information to, and import information from, a number of external application programs (or tools) 116. Examples of such external tools may include a word processor application 118 (e.g., Microsoft Word), a spreadsheet application 120 (e.g., Microsoft Excel) or an e-mail and calendaring application 122 (e.g., Microsoft Outlook). In addition, the toolbridge may support the ability for such external applications to export information to, or import information from, the project community application server 104.

In the exemplary embodiment of the present invention, the application server creates and extends a history log 124 of some or all events that take place during the operation of the project community. A replay server 106 provides access to this history log 124 for purposes that will be explained below.

Figure 5 is a high-level diagrammatic illustration showing the initialization of the application server 104 with an object model 130 and compiled scripts 132. Specifically, for purposes of initialization of a project community 62, the application server 104 will read an extensible markup language (XML) model 133 (i.e., an XML representation of the project model 60) to initialize the data in the database 112 and populate the application server 104 with an object model 130 (i.e., the application server's representation of the project model 60 in terms of project community 62 structure) and the compiled scripts 132. The compiled scripts 132 are the compiled code representation of scripts as detailed earlier. The structure of the project community 62 typically resides in the application server 104 whereas the data that is presented using the structure is typically stored in the database 112 but may be cached in the application server 104 for performance purposes. In an alternative embodiment of the present invention, the model 133 may be defined in terms of another derivative language of the standard generalized markup language (SGML).

Figure 6 is a block diagram illustrating further architectural details regarding an exemplary client module 102 and an exemplary application server 104. The client module 102 operates to provide a superset of functionality with which to build tools necessary for expression within, and interaction with, the project community 62 by a team member. The client module 102 is characterized in that it provides a non-continuous connection to a project community 62, interprets XML object descriptions, is primarily stateless, and dynamically loads capabilities (both setting specific and role specific applications and tools, and data) as such capabilities are specified.

With respect to the non-continuous connection, the client module 102 registers itself with the application server 104, which then issues the application module 102 with an identifier. The client module 102 then utilizes this identifier to identify a specific login session for each communication with the application server 104. As there is no continuous connection to the application server 104, all communications are, in the present exemplary embodiment, initiated by the client module 102.

Alternatively, the system can be implemented to include a continuous connection, whereby the server is aware of the client and can decide to push information to the client.

The client module 102 communicates to the application server 104 utilizing HTTP messages specifying POST operations, and utilizes URLs that are specified by the application server 104. The application server 104 communicates to the client module 102 as a response to a particular client query. All information is communicated from the client module 102 to the application server 104 in the form of XML expression.

XML Expressions Representing an Exemplary Project Element The client module 102 architecture and functionality is focused on the presentation and interpretation of project elements 66 included within the application server 104. Specifically, the application server 104 encodes project elements 66 in the form of XML expressions that are then communicated to the client module 102. Before providing the specifics of the respective architectures of a client module 102 and application server 104, it is useful to describe the expression of a project element 66 in XML notation.

While a detailed description of a project element is described earlier with reference to Table 1, a project element 66, for present purposes, may be regarded as having the following properties:

1. A class that describes the type of the project element 66;

2. A name that provides a human readable symbolic identifier; and

3. An identifier that is guaranteed to be unique for the element class. To exactly identify a project element 66, the class to identify should accordingly be used.

As a result of the features in the design and interpretation of project elements 66, the client module 102 is able to be primarily stateless and to load capabilities dynamically as they are required for the user's interaction with the project community 62.

An example of XML expression for a project element 66 and explanation is provided below.

<IAScheduleItem id="404" name="Concept_Review" read="true" edit="true" evaluate="true" type="IAScheduleItem" action="IAModifyProjectElementsQuery"> <field name="name" type="shortString" readOnly ="false">Concept_Review< / field> <field name="Date" type="shortString" readOnly="false">July 28, 1999 08:00</field>

<field name="Duration" type="shortString" readOnly="false">24 hours</field>

<field name-Εvent" type="shortString" readOnly="false">Concept review meeting to disc</field> <field name="Invitees" type="longString" readOnly-"false">Everyone< / field> <field name="Caller" type="shortString" readOnly ="false">Project_Manager< / field> <details x="20" y="15" lod="0"/> <viewer class="Defalut Viewer" / > < / 1 AScheduleItem>

The " IAScheduleltem " tag describes the class of the project element 66 from which the XML statement is generated. The identifier for the relevant project element 66 is "404". Accordingly, the content of the "IAScheduleltem" tag together with the identifier "404" constitutes a composite key for the project element 66. The name of the underlying project element 66 is shown to be " Concept_Review ", and the attribute "action" specifies URL information to be used in notifying the application server 104 about changes done the project element on the client.

To support a full, rich object structure, greater type information may be needed that can be captured in the type-less "attribute" portion of the XML statement. Three examples of special tag sections included within the above XML expression are:

1. A Field Section;

2. A Detail Section; and 3. A Viewer Section.

Further details regarding each of these sections is provided below.

Field Sections

Turning first to the field section, a proprietary tag "field" designates a named property of the object. The actual data pertaining to property is located in the text between the start and end portion of the XML expression (i.e., in the pcData portion of the XML expression). All other information concerning a field is encoded in the "attribute" portion of the XML expression. According to the present invention, the modeler 52 or instantiator 54 may specify a number of field types. Examples of various field types proposed by the invention are shortString, longString, timeStamp, and number.

Project elements 66 may be embedded within other project elements 66, thus creating a tree structure of project elements. This embedding can be either as an explicit field within the field type "project Element" listed above or simply as a direct sub element.

Detail Sections

In order to have the client module 102 retain as little as possible information, project elements 66 may have information specified within a "detail" section there of that allow display states descriptions to the stored on the application server 104 in a per object/per user/per role fashion.

The detail section of a project element 66 may contain at least location and size information for display of a project element by binding the display end-user interaction logic of a client module to the description detailed below. A detail section of a project element 66 may also specify the level of detail regarding the project element 66 that is to be presented to a user.

Viewer Sections

Project elements 66 can provide information about how they should be presented by the display and user interaction logic of a client module 102 for viewing by a user. This information is specified within a "viewer" tag section of a corresponding XML expression. An example of such a "viewer" tag section is shown in the above example. A detailed description of the utilization of information contained within a "viewer" tag section is provided below when describing the graphical user interface. The client module 102 is shown to include display and user interaction logic 134 that generates and controls the display of graphic information pertaining to a project community 10 on a display unit (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) or active matrix display) associated with a computer system (not shown) on which the client module 102 is hosted. Linked to the display and user interaction logic 134, an inteφreter 135 provides a conduit to marshal logic 136 that marshals information created in the client 102 into XML expressions and to unmarshal logic 138 that unmarshals XML expressions received from the application server 104 A communications interface 140 is shown to include an HTTP client 142 and polling logic 144. The HTTP client 142 issues requests to a corresponding HTTP server 152 included within a communications interface 150 of the application server 104. Information from the server 152 is provided as a response to the HTTP request.

The application server 104 also includes marshal and unmarshal logic 154 and 156, that communicate through an interpreter 160 with application objects 162 and database objects 164. The database objects 164 are shown to issue ODBC queries 168 to, and to receive ODBC responses 166 from, the database management system 110. The database management system 110 includes a number of stored procedures 170 that access tables 172 and data 174 stored within the database 112.

Having now described the architecture of an exemplary client module 102, application server 104 and database management system 110, the handling of client requests received from the client module 102 by the application server 104, and the constructing of responses to such client requests by the application server 104, will be described further. The methodologies by which a client module 102 handles responses from the application server 104 and handles user events will also be described.

METHODOLOGY- APPLICATION SERVER HANDLING OF A CLIENT

REQUEST Figure 7 is a flowchart illustrating a method 200, according to an exemplary embodiment of the present invention, by which the application server 104 may handle a request received from a client module 102.

The method 200 commences at step 202, where the application server 104 receives an XML packet from a client module 102 via the HTTP server 152 of the communications interface 150 of the application server 104. The XML packet is embodied in a standard HTTP POST request. At step 204, the unmarshal logic 138 converts the received XML packet to an internal representation. Specifically, the XML is converted into a tree structure by building instances of an object class named XMLTreeNode with three instance variables: tag, attributes, and elements. Specifically, tag is a String; attributes is an array of key-value pair to represent the attributes; and elements is an array of XMLTreeNodes if any exists. This format provides the object model representation expected by the server application code.

At step 206, the inteφreter 160 looks up an Uniform Resource Indicator (URI) portion as a key in a dictionary (not shown) to obtain a handler class. At decision box 208, a determination is made as to whether a key has been located or not. If no key has been located, the handler class is designated as the "default" class at step 211, which provides a classic web server. A determination is then made at decision box 213 whether the internal representation is a valid Unix-like path name. If not, an error is registered at step 215. If so, at step 217, the inteφreter 160 goes to a default directory to get a specified file, and to look up the Multi-puφose Internet Mail Extension (MIME) for the specified file. At step 219, the response to the received client request is identified as being the specified file and its accompanying MIME.

On the other hand, should a key be located, the method 200 proceeds from the decision box 208 to step 210, where the inteφreter 160 creates an instance of the handler class. At step 212, the created instance is given control to enable it to acquire information from the internal representation (generated at step 204) and to create an instance of a class matching client request instance (CRI). The instance CRI is the entry point into server behavior. Accordingly, at step 213 and in the application objects layer 162 , the CRI executes and modifies application objects 162. Specifically, a method associated with the CRI executes, and possibly initiates interaction with an application object. Other application objects may be in the application server 104 on account of being instances of extension classes or DLLs that were loaded when the past matching client request was loaded into the server as part of its working set of extension classes. Alternatively, the objects may be primitives of a project community 10, such as a setting element (IASetting) or a role element (IARole). The other objects may also be database objects 164 that each application object 162 is aware of. Specifically, there may be a many-to-one relationship between database objects 164 and application objects 162, whereas the database objects 164 have a one-to-one relationship with the database tables 172.

At decision box 214, a determination is made as to whether the application object layer 162 has cached any required database information. If not, at step 216, application objects 162 may interact with database objects 164, which in turn create SQL queries to the database management system 110. At step 218, the database objects 164 receive the relevant data from the database management system 110, and fill in the database object values to be given to the relevant application objects 162. At step 220, the database data is marshaled.

METHODOLOGY- APPLICATION SERVER CONSTRUCTS RESPONSE TO

CLIENT

Figure 8 is a flowchart illustrating a method 230, according to an exemplary embodiment of the present invention, by which the application server 104 may construct a response to a client request. The method 230 commences at step 232, where a response pattern for the received request is retrieved. Specifically, the CRI, created at step 212 shown in Figure 7, knows where to look for the response pattern in an external file or an internal string. Referring to Figure 9, the response pattern 240 is an XML-formatted string that represents a pattern for an appropriate response to a specific client request. The XML-formatted string may be parsed into an internal structure in the form of a tree structure 242. Accordingly, at step 234, a tree walk is executed to generate the internal structure (i.e., a tree structure 242). The tree walk tree treats each node of the tree structure 242 as either a literal or a script. A script may define how to populate the internal structure with live data. For example, a script may be (1) a simple type of executable software (e.g., written in Java or Smalltalk) that returns a value, (2) a switch to select a script by returning a value for the selected script, or (3) a response pattern or a pointer to a file containing a response pattern that returns a populated sub-tree.

At step 236, the internal structure is converted to an XML-formatted string (i.e., an XML packet) that is then propagated to the client module 102 at step 238 as a response to the received client request.

METHODOLOGY-CLIENT MODULE HANDLES RESPONSE FROM

APPLICATION SERVER Figure 10 is a flowchart illustrating a method 250, according to an exemplary embodiment of the present invention, by which a client module 102 processes a response received from the application server 104 responsive to a client request. A client request, furthermore, may be a specific request issued via the HTTP client 142 within the communications interface 140 of a client module 102 or may be a scheduled poll issued from the polling logic 146 of the communications interface 140. Polling is performed because, although the application server 104 is controlling of the state of the client module 102, the HTTP protocol does not facilitate server-initiated interactions with a client module 102. The response to such a client request is either "no" or an XML packet containing information regarding the change states of any settings.

The method 250 is performed with a view to setting up or updating client objects that are inteφreted by the display and user interaction logic 342 to generate a graphical user interface with which a user can interact. Further details regarding the implementation of the graphical user interface, and user interaction therewith to navigate and operate within the project community 10, are described below.

Figure 11 is a block diagram illustrating the structure of an exemplary client setting object 280, according to one embodiment of the present invention. Specifically, the client setting object 280 is shown to include an identifier 282 that is treated as a string, and a tag name 284 such that the identifier 282 is unique within the tag name 284. The client object 280 may be a setting client object, representative of a setting element within the project community 10 and containing information concerning the setting element. Accordingly, a client setting object 280 will include a process component 286 associated with a process element 32, a subject component 288 associated with a subject element 24, a references component 290 associated with a references element 28 and a tool element 292. A client setting object 280 may also include viewer components 294 that each include a name 296, a class 298 and a version number 300 for the class 298. It should be noted that when one aspect of a client setting object 280 is to be displayed, the client module 102 will generate a client request to the application server 104 to provide the class for appropriate viewers for inclusion within the setting client object 280, unless a default viewer component 294 is provided.

The method 250 commences at step 252 at which the client module 102, in response to a client request, receives the XML packet propagated from the application server 104 at step 238 shown in Figure 8. At step 254, the unmarshal logic 138 within the client module 102 proceeds to unmarshal the received XML packet and to convert the packet into an internal representation. To this end, the XML packet may contain prototype information, originated within the response pattern 240, that specifies the internal representation. At step 256, the inteφreter 135 performs a walk of the internal representation (that is in the form of a tree structure) in a "depth first" manner looking for XML tag names. At step 258, the inteφreter 135 inteφrets tag names as dispatching into code that in turn can parse more of the internal structure.

At decision box 260, a determination is made as to whether the special case of entering a setting has occurred. By "entering a setting" is meant that the user, acting with regard to the user Identity or having assumed a community Role, is given access to and selects a particular setting as the current context in which the user works. In this regard, "entering a setting" denotes a context switch for the user. Following a positive determination at decision box 260, the method 250 proceeds to step 262, where information concerning the setting entered is extracted from the internal structure. At step 264, a tree walk of the internal structure is again performed for the puφose of examining context. Tools that allow the user to interact with the setting application within the context may be loaded. At step 266, classes that may be required by viewers 294 of a client object 280 are downloaded from the application server 104 as required.

Following a negative determination at decision box 260, or following completion of step 266, the method 250 proceeds to step 268, where the context update or setup, as the case may be, is performed and a graphical presentation presented by the display and user interface logic 134 is updated or setup accordingly. The method 250 then terminates at step 270.

METHODOLOGY-CLIENT HANDLES USER EVENT Figure 12 is a flowchart detailing a method 310, according to an exemplary embodiment of the present invention, by which a client module 102 may process and respond to the occurrence of a user event. Such user events may include a request from the user for interaction with the project community 10, for example by importing or exporting data from the project community 10. The request for user interaction may be indicated by the user by the supply of information into a specific text field, by the selection of an action button, or by the selection of a tool presented by the display and user interaction logic 134 via a graphical user interface.

The method 310 commences at step 312 with the occurrence of a user action event. The display and user interaction logic 134 then determines, at step 314, what information is to be propagated from the client module 102 to the application server 104 responsive to the user action. Specifically, a graphical user interface element (not shown) associated with the user action is utilized by the client module 102 to fill parameters of an appropriate internal structure. The graphical user interface element will have been specified to pass certain information to the application server 104 responsive to the user action. The graphical user interface element will furthermore have a record of which code within the application server 104 requires notification of the user action, as this information is communicated to the graphical user element from the application server 104. This information is also included within the appropriate internal structure by the client module 102.

At step 316, the marshal logic 136 converts the internal structure into an XML packet that is then propagated to the application server at step 318 from the HTTP client 142 of the communications interface 140. The method 310 then terminates at step 320.

METHODOLOGY-CLIENT POLLS APPLIC ATION SERVER TO OBTAIN

SERVER UPDATES

As stated above, in the described embodiment of the present invention, the HTTP protocol prevents the application server 104 from advising client modules 102 regarding changes pertaining to a project community 10 hosted on the relevant application server 104. For this reason, the polling logic 146 of each client module 102 periodically polls the application server 104 for the puφose of learning about such changes.

So as to enable the client module 102 to identify changes in the state of project elements hosted on the application server 104 corresponding to client objects within the client module 102 representative of such project elements, each client module 102 and the application server 104 store respective tables of numbers. The table of numbers maintained by the application server 104 is termed an "element change table". The element change table includes a series of object numbers, each associated with an application object (e.g., project element), that are incremented every time the associated application object changes. The table of numbers stored by each client module 102 is termed a "table of client numbers" and corresponds to the element change table that was extant on the application server 104 at the time the relevant client module 102 last polled the application server 104. Accordingly, by comparing the table of client numbers stored by a client module 102 at any specific time with the current element change table maintained by the application server 104, a change in the state of any of the application objects that should be reflected by the client module 102 may be identified.

Figure 13 is a flowchart describing a method 330, according to an exemplary embodiment of the present invention, by which a client module 102 may poll an application server 104 for the puφose of identifying changes pertaining to a project community 10. The method 330 commences at step 332, with the client module 102 propagating the table of client numbers (in the form of a vector of client numbers) representing the current states of client objects 280 (e.g., setting client objects), to the application server 104. More specifically, a client number may be indicative of the state of a setting client object, presence (i.e., who is within the setting), and monitors, (to be described in further detail below) that are active with respect to the relevant setting client object.

At step 334, the application server 104 examines the received table of client numbers to identify changes that have occurred within the project community 10 since the last client update. To this end, the application server 104 compares the received table of client numbers to the element change table that contains a record of any objects (e.g., subject or reference project elements) hosted on the application server 104 that have changed and that have dependencies.

At decision box 336, a determination is made as to whether there are any discrepancies between the received table of client numbers and the content of the element change table. Specifically, if an object number within the element change table is greater than a corresponding client number within the table of client numbers, this indicates that the relevant application object has changed since the last polling operation performed by the client module 102. If so, the application server 104 records these changes in an XML packet at step 340. It should be noted that only information concerning the modified or changed application objects are included within the XML packet. This XML packet is then propagated from the application server 104 to the client module 102 at step 342. At step 344, the application server 104 also propagates an updated vector of client numbers to the client module 102 so that the table of client numbers maintained by the client module 102 might be updated to correspond to the element change table.

Following a negative determination at decision box 336, or following completion of step 344, the method 330 then terminates at step 346. METHODOLOGY- APPLICATION SERVER REQUESTS AN EXTERNAL

TOOL

Figure 14 is a flowchart describing a method 350, according to an exemplary embodiment of the present invention, by which the application server 104 may export data to the external tool application 116 via the tool bridge 114.

The method 350 commences at step 352 with the occurrence of a user action, via a graphical user interface provided by the display and user interaction logic 134. The user action is of the type that requires application server 104 interaction with an external tool application 116, examples of which are described above with reference to Figure 4. Accordingly, the application server 104 generates an "external tool request". For the puφoses of illustration, it shall be assumed that the user action required the generation of a report by a word processor application 118.

At step 354, the application server 104 initiates a call to the toolbridge 114, for example to initiate generation of the report. This call is not implemented using the HTTP protocol, and specifies which external tool application 116 is to be utilized and a response pattern to be utilized by the specified tool application 116.

At step 356, the toolbridge 114 queries the application server 104, using the HTTP protocol, for data that is required to execute the tool request. Depending on the tool request, the toolbridge 114 may issue a series of queries to the application server 104.

At step 358, the application server 104 provides responses, including relevant data, to the toolbridge 114. At step 360, the toolbridge 114 processes the received responses and translates the responses into a format suitable for the specified tool application 116 (e.g., into a format suitable for Microsoft Word). At step 362, the toolbridge 114 invokes (which may or may not comprise launching) the specified tool application 116, and provides the tool application 116 with the data received from the application server 104. The toolbridge 114 thereafter stores the resulting work product (e.g., the generated Microsoft Word document).

At step 364, the toolbridge 114 sends information concerning the storage location of the work product to the application server 104. This communication is made utilizing the HTTP protocol. The method 350 then terminates at step 366. While the exporting of data from the application server 104 to a tool application 116 has been described above, the toolbridge 114 may also be utilized for the importing of data from an external tool application 116 to the application server 104 for the puφose of making such data available to a project community 10. Specifically, the application server 104 requests the toolbridge 114 provide a document for the puφose of extracting embedded data from the relevant document. The toolbridge 114 may furthermore be utilized by a user to "command" or utilize a tool application 116 via a client module 102 and the application server 104. Specifically, a user may launch a tool application 116 to save a resulting work product, and send the work product, or reference about the work product, to the project community 10.

COMPUTER SYSTEM Figure 15 shows a diagrammatic representation of a machine in the exemplary form of a computer system 400 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. The computer system 400 includes a processor 402, a main memory 404 and a static memory 405, which communicate with each other via a bus 406. The computer system 400 is further shown to include a video display unit 408 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 400 also includes an alpha-numeric input device 410 (e.g., a keyboard), a cursor control device 412 (e.g., a mouse), a disk drive unit 414, a signal generation device 416 (e.g., a speaker) and a network interface device 418. The disk drive unit 414 includes a computer-readable medium 415 on which is stored a set of instructions (i.e., software) 420 embodying any one, or all, of the methodologies described above. The software 420 is also shown to reside, completely or at least partially, within the main memory 403 and /or within the processor 402. The software 420 may further be transmitted or received via the network interface device 418. For the puφoses of this specification, the term "machine-readable medium" shall be taken to include any medium which is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals. EXEMPLARY EMBODIMENT: DESIGN STUDIO PROTECT COMMUNITY Summary Design_Studio Community Definition

The first form presented is the static presentation format for an instantiated project community. Each value in the form names a project community element which is subsequently defined in this document.

Basic Data Structures of the Design_Studio Community

Graphic Project

By tracing projects carried out in behalf of a particular client, it is possible to track both the financial and work history with that client. Customer

Address of Customer

Models: General Project and Special Magazine

The definition for Project_Model is that it is a Model; the Model definition is taken from the description of the Project_Modeling_Community. It represents the information needed to form a project community based on a project model. All the settings of the Project_Modeling_Community are required in order to construct this project element, namely the settings named Modeling, Instantiations, and Improvement.

The Design_Studio maintains potentially several models. Project_Model is the most general description of the way in which all graphic projects are carried out. However, this description can be further refined, either for particular kinds of graphic projects, such as creating a magazine, a brochure, or a user interface for a computer application. A list of such refinements is maintained in the dictionary called Project_Descriptions. Only one Decision_Framework is needed for all these models since decision expectations or needs can be differentiated by choosing different decision topics.

Project_Descriptions AT 'Project_Model' PUT Project_Model; Past_Projects AT 'Project_Model' PUT Project_Model Project_Descriptions AT 'Magazine_Model' PUT Magazine_Model; where Project_Model and Magazine_Model are defined to be:

The difference shown here for Magazine_Model is the Puφose, fully described as: To support a community of designers, writers, and project leaders to create Font & Function Number <Number: 'magazine number'> for Adobe. For Magazine_Model, all the project elements defined for Project_Model are copied with additions as presented in Elements of Magazine_Model.

Elements of the Design_Studio Community Design Studio Glossary

Design Studio Purpose

Design Studio Objectives

There are two categories of objectives: modeling and business. Status of objectives are defined as acceptable or unacceptable, and priorities are set from l to 5.

Modeling Objectives Objectives acquired from the definition of

Project_Modeling_Community that monitor our project modeling work

Business Objectives Those objectives that clarify our business vision

Roles

Role assignments at initialization are as follows:

Identity Role

Susan Principal_Susan, Office_Manager, Bookkeeper, Marketing,

Facilities Greg Principal_Greg, Marketing, Systems_Administrator,

Modeler Deb Marketing, Librarian

Resources

Special Setting Roles

Special Setting Role mapping is as follows:

Principals special setting role given to instances

Principal_T

Modelers special setting role given to Modeler and

Instantiator

Environs special setting role given to System_Administrator,

Facilities, Office_Manager

Historians special setting role given to Librarian

Settings

Take the definitions for subjects, resources, and process from the PML document, Appendix B.

The setting subjects listed here are defined in the PML document. They are the settings needed to construct each aspect of the Model. The Project_Model and Project_Decisions are the outcomes of this setting.

Action Scripts

Business Process

00/26822

The decision framework does not as yet contain any items.

Elements of Project_Model

In this section, we define the templates and elements that populate the Dictionaries and Lists of Model named Project_Model. Objectives, Measures, Metrics

Glossary

Roles

Plus instances of Roles defined as templates and listed with Resources, created when project instance is created.

Role

Name

Account_Manager

Comment This role works as an advocate for the client, making sure the company services the client's interests, while also trying to figure out what other types of work the company could do for the client in the future. This role is in charge of the pre- and post- project relationship with the client.

RoleType Single

Responsibilities β Handle client communication. β Coordinate project strategy. β Develop project proposals and contracts. β Handle project invoicing.

Qualifications Good communication skills, inteψersonal skills, and a team worker. A competent sales person in the sense of knowing how to propose and close a contract. Resources

Special setting roles

Special setting role mapping are as follows:

Administrators special setting role given to Art_Director,

Project_Manager, Account_Manager

Freelancers special setting role given to Writers,

Production_Specialists, Photographers, Illustrators

AllDesigners special setting role given to Designers Customers special setting role given to guests would need a Guest

Role defined earlier.

Subjects

This dictionary references all the subjects, including the setting instances and action scripts.

.14

Design Process

Elements of Magazine_Model

Magazine_Model is a refinement of Project_Model. Whereas Project_Model represents a graphic design project in which there is one topic (or one design problem), in a Magazine there are several. Also, whereas no assumptions are made about the relationship between various project communities created directly as instantiations of ProjectJModel, the Magazine_Model is reused in a series of related project communities. The first being the first time a magazine is designed, the basics of masthead, grid, and number of pages, have to be determined. Subsequent projects reuse these basics but also use the previous project schedule and budget as a starting point for planning.

In this section, the templates and elements that populate the Dictionaries and Lists of the Model named Magazine_Model are defined, noting where appropriate the ones that are copied from Project_Model.

Objectives, Measures, Metrics

Definitions for Measures, Metrics and MetricTables come from Project_Model.

By reference, included in Magazine_Community will be: Objectives: Quality _of_Product, Budget_Met Measures: Quality_Measure, Budget_Measure Metric_Table: Project_Metrics Metrics: deadlines, budgetTarget

Glossan/

Roles

All of the roles defined for Project_Model are needed in a Magazine Community, including the Role templates listed in the dictionary of Resources. No additional roles are defined.

Magazine_Community will include the three listed roles definitions.

Resources

These resources, taken from Project_Model, define templates for additional roles, as well as subjects and settings. When forming a new Magazine Community, the required instances of these role resources should be created. In addition, the Magazine Community provides a Design_Development setting template, instances of which are created at runtime. To coordinate the creation of this template with the acceptance of design topics, a grouping template is also provided as a resource. The primary settings for concept, refinement, and production, are now grouped within Design_Development. The various instances of Review settings are used to discuss and review the interim and final results from all Design_Development.

Magazine_Community will include all of the listed templates, including process definition for settings. The last two templates are defined here.

Special setting roles

The list of special setting roles defined at the community level consist of:

Special setting role mapping are as follows:

Administrators special setting role given to Art_Director, Project_Manager,

Account_Manager

Freelancers special setting role given to Writers,

Production_Specialists,

Photographers, Illustrators

AllDesigners special setting role given to Designers

Customers special setting role given to guests

All of these Special setting roles are defined as in Project_Model. Subjects

This dictionary references all the subjects, including the setting instances and action scripts.

From Project_Model, include in Magazine_Community all of the named project elements: Phase, Signoff, Schedule, Assign_Resources (a setting), Resource_Allocation (a process), Manage_Budget (a setting), Budgeting_Process (a process), Plan_Project (a setting), Scheduling_Process (a process), andTask (resource of Plan_Project).

The Magazine_Community differs from the general project community for graphics projects in several ways. Instead of managing a single signoff, we create instances of TopicjSignoff for each DesignJTopic. Instead of having a single set of concept/refinement/production settings for the whole community, there is a repetition of these per DesignJTopic created. Hence these settings are represented in this community as Templates and instances created as part of the DesignJDevelopment setting whenever a new DesignJTopic is created. See Resources for the definitions.

Decisions

Decision_Framework

Name

Magazine_Project_Decisions

<Decision_Topic> Choices Criteria Discussion

Magazine Design Process

Thus, a method and apparatus for generating, operating and updating a computer-implemented project knowledge management facility have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

CLAIMSWhat is claimed is:

1. A method of creating a model-driven virtual community having at least one objective, the method including:

accessing a collection of templates that constitute partial descriptions of respective elements of the virtual community; and

instantiating the collection of templates to generate the elements of the virtual community, the elements of the virtual community specifying structural and behavioral constructs of a model according to which the virtual community is structured and operated to progress towards achievement of the at least one objective.

2. The method of claim 1 wherein the instantiating of the collection of templates is performed utilizing a decision framework constructed utilizing input derived from participants within an earlier virtual community instantiated utilizing the collection of templates.

3. The method of claim 1 wherein the instantiating of the collection of templates is performed utilizing a decision framework constructed utilizing domain-specific knowledge.

4. The method of claim 1 wherein the instantiating of at least one template of the collection of templates includes generating a value for an attribute of the at least one template.

5. The method of claim 4 wherein the value for the attribute of the at least one template is specified by a literal specification.

6. The method of claim 4 wherein the value for the attribute of the at least one template is specified by a variable specification.

7. The method of claim 4 wherein the at least one template includes a specification of operations to generate the value for the attribute of the at least one template.

8. The method of claim 7 wherein the operations include retrieving the value from a storage location associated with a computer system.

9. The method of claim 7 wherein the operations include calculating the value based on the least one input.

10. The method of claim 7 wherein the operations include requesting an input of the value by an instantiator of the at least one template.

11. The method of claim 4 wherein the value for the attribute of the at least one template is specified by a further template.

12. The method of claim 1 including only partially instantiating a further template that constitutes a partial description of an element of the virtual community to generate a community template, the community template being included within the virtual community.

13. The method of claim 1 wherein the collection of templates includes a grouping template that holds first and second templates and wherein the instantiation of the first and second templates is coordinated to generate corresponding first and second elements of the virtual community

14. The method of claim 13 wherein the use of the first and second elements within the virtual community is coordinated.

15. The method of claim 1 including instantiating a purpose element of the virtual community that defines a reason for the existence of the virtual community

16. The method of claim 1 including instantiating an objective element of the virtual community that defines an objective of the virtual community.

17. The method of claim 16 including instantiating a measure element that facilitates measurement of progress of the virtual community toward achieving the objective defined by the objective element.

18. The method of claim 1 including instantiating a role element that defines responsibilities and access privileges of a community role within the virtual community.

19. The method of claim 18 including instantiating a conversation element that defines a structure for interactions among multiple community roles defined by multiple role elements.

20. The method of claim 18 wherein the conversation element comprises a plurality of interaction channels including a primary interaction channel and a secondary interaction channel, and wherein a first participant is granted access to both the primary and the secondary interaction channels and a second participant is granted access to only the primary interaction channel.

21. The method of claim 1 including instantiating a glossary element that specifies a shared vocabulary of the virtual community.

22. The method of claim 16 including instantiating at least one setting element that defines a setting comprising a structure of interactions toward achieving the objective defined by the objective element.

23. The method of claim 22 including instantiating at least one subject element as part of the setting, the subject element being descriptive of interactions in the setting and having attributes that representing potential deliverables of the setting.

24. The method of claim 22 including instantiating at least one reference element as part of the setting, the reference element representing knowledge constructed outside the setting defined by the at least one setting element but for use within the setting.

25. The method of claim 22 including instantiating at least one special setting role element that extends responsibilities and access privileges of a community role within the setting.

26. The method of claim 22 including instantiating at least one knowledge flow map element that defines communication of information between the at least one setting element and a further setting element.

27. The method of claim 26 wherein the knowledge flow map element defines at least one input for first information defined outside the setting, the at least one input to receive the first information into the setting.

28. The method of claim 26 wherein the knowledge flow map element defines at least one outcome for second information defined within the setting, the at least one outcome to output the second information from the setting.

29. The method of claim 26 wherein the knowledge flow map element defines a control flow specifying an ordered sequence of access to multiple settings according to event occurrences within the virtual community.

30. The method of claim 26 wherein the knowledge flow map element defines a control flow specifying an ordered sequence of access to multiple settings according to availability of deliverables of the multiple settings.

31. The method of claim 22 wherein the at least one setting element defines either role-based or identity-based naming for participants within the setting.

32. The method of claim 22 including instantiating a conversation element that facilitates communications within the virtual community outside the setting defined by the at least one setting element.

33. The method of claim 22 including instantiating a narrative element that captures narrative of participants within the setting, the captured narrative being presentable outside the setting as a description of interactions within the setting.

34. A system for creating a model-driven virtual community having at least one objective, the system including:

a collection templates that constitute partial descriptions of respective elements of the virtual community; and

PAGES

137-140

NOT FURNISHED UPON FILING