Portal Architecture
Christopher J. Hogger, Frank R. Kriwaczek and Mohd S. Ahmad
Department of Computing,
Imperial College London,
South Kensington Campus,
London SW7 2AZ, U.K.
{cjh, frk, msa2}@doc.ic.ac.uk
Abstract
We describe a portal architecture model that employs plans and constraints to facilitate the performing of user
roles. The model is sufficiently abstract to serve as a generic specification for a variety of concrete portal
implementations, besides being directly implementable in its own right. A key feature of the model is its treatment
of constraints. In particular, its use of a constraint engine to process constraints over finite domains enables us to
model many interesting and novel operational schemes for cohering individual and communal working practice.
1. Introduction
In broad terms a portal [4, 6, 9, 16] is a computing environment suitably shaped to workplace
requirements. Typically it provides ready access to personalised information and it facilitates decisionmaking and the performing of roles. Depending on the context, it may function as a tolerant, useradaptable personal assistant or, at the other extreme, as a prescriptive institutional regime. Our work is
concerned with modeling a transparent and general architecture for, primarily, portals of the former
kind, and applies to both single and multi-user contexts.
This architecture entails a combination of procedural plans and logical constraints expressing key
aspects of the roles undertaken by the portal’s users. The plans are programmatic schemes of actions
that construct and communicate electronic artefacts residing in the users’ local workspaces. The
constraints assist the determination of those artefacts’ attributes and their scheduling and resource
demands in the course of executing the plans. The architecture is tolerant of constraint failure, offering
mechanisms for failure recovery through appropriate revision of plans and constraints. It also enables
roles to be assigned or delegated by users to other users through the handling of particular kinds of
artefact. Features of the architecture are illustrated here using concrete formulations of artefacts, but
the underlying model is sufficiently abstract to support other formulations appropriate to the context.
**** here a motivating sentence, giving our expectations as to how the architecture might be used by
others, etc... *** The wonderful congeniality and generality of our representations. *** Brief comment
on implementation, case-studies, etc. ***
2. Outline of the Model
Figure 1 outlines the model’s core features. The enterprise being modeled is presumed to comprise
some set of roles, each assigned to some portal user who is thereby a role-holder. Each role is
characterized by two parts. One part is a plan comprising one or more concurrent tasks that jointly
constitute the role, each being a simple program of actions. The other part is a set of constraints. The
plan and the constraints are viewable in the portal interface. Actions performed in the plan may create,
access or modify electronic artefacts residing in the role-holder’s local workspace, or may transact
them between that workspace and databases shared with other role-holders. The constraints from the
separate roles form a set that applies globally to all role-holders. They may constrain in any manner the
various attributes of the artefacts and the various timepoints at which actions are initiated or completed.
role-holder
other role-holders
communal
databases
plan
workspace
time axis
constraints
Figure 1. Outline of the architecture.
2.1 Representing Plans
We represent plans in a very simple manner, in order that they may be easily devised, modified and
interpreted. A plan is a block-structured presentation of action declarations, each having the basic form
action(role_id, block_id, index, action_predicate).
which identifies the role to which it belongs, the block that contains it, its position within that block
and—most importantly—the specific nature of the action as described by the action-predicate. Figure 2
shows a fragment of a plan for a role r3. One of this role’s tasks, say task4, has a program containing a
block b2, part of which is shown in the figure.
:
action(r3, b2, 5, et4<365, do_block(wantdiary(no), b7, st5, et5)).
action(r3, b2, 6, import(db1, template, st6, et6)).
action(r3, b2, 7, create([template], appts, st7, et7)).
action(r3, b2, 8, create([appts], diary, st8, et8)).
action(r3, b2, 9, export(db3, diary, st9, et9)).
:
Figure 2. Fragment of a plan.
Loosely, the actions there express a decision to create a diary for the next year by importing a suitable
template from a database, filling this in to produce a set of appointments for that year, arranging them
as a diary and exporting this to some other database.
Action-predicates take various forms, but always include two arguments st and et denoting the
action’s start-time and end-time. The most frequently used types are create(...), import(...) and
export(...). Others, however, serve to express simple species of control-flow through the plan, such as
branching and iteration. All types may include a precondition inserted before the action-predicate. In
Figure 2 the first declaration poses a precondition about a time-point et4 which, if satisfied, causes a
branching action do_block(...) to be executed; this in turn tests whether a diary is required, in default of
which control is diverted to some other block b7. Space does not allow for the entire grammar of the
plan language to be given here, but the examples should give a reasonable indication of its nature.
Associated with each task in a role is a unique entry-point declaration identifying the block in
which the task’s execution is to begin, and this has the general form
entry_point(role_id, task_id, block_id).
For the example in Figure 2 the entry point for task4 might be declared thus:
entry_point(r3, task4, b2).
2.2 Role Ontologies
The arguments db1, template, st6, et6, etc. that appear in Figure 2 are called ontological variables. They
name the entities that the role-holder works with. Associated with each role R is a set of declarations
declaring particular ontologies whose variables are used by R. An ontology named own declares those
variables devised by R; if named public it declares enterprise-wide variables available to all roleholders; if named by the name R2 of some other role-holder it enables R to make use of R2’s variables.
Figure 3 sketches some ontology declarations that might be used to formulate a finance-director’s role,
augmenting his own variables with some public variables and also some variables local to another roleholder named auditor.
ontology(financedir, own, [account1, account2, st1, et1, ... etc.]).
ontology(financedir, public, [sales_acc, expenses_acc, ..., etc.]).
ontology(financedir, auditor, [annual_report, ..., etc.]).
Figure 3. Ontology declarations for a role.
Ontological variables are used not only in the plans but also in the constraints. As plans are performed,
and constraints evaluated, the variables become progressively instantiated to concrete values for
artefact attributes and time-points, in a manner described presently.
2.3 Representing Constraints
We represent constraints as atomic calls (predicates) over ontological variables. Each one is either a
primitive known to the system or is otherwise defined by some associated constraint program. The
constraints contributed by all role-holders must be satisfied, sooner or later, if the latter are to
discharge their roles successfully. Each one is declared by a constraint declaration of the form
constraint(role_id, task_id, index, call).
as in the example
constraint(financedir, task4, 3, short_elapse(et1, et2)).
Here, the finance director has stipulated some constraint upon the elapse between the end-times of two
of his actions. Its precise nature will be set out in some program defining the short_elapse predicate.
The two middle arguments record, solely for internal book-keeping, that the constraint is considered
relevant to task4 and is the 3rd such constraint.
2.4 Execution of Roles
With the plans and constraints in place, together with their associated ontologies and constraintdefining programs, the operational functioning of the model is as follows. The plans of all role-holders
are executed concurrently. Each role-holder interacts with his plan through the portal interface. This
displays, among many other things, those actions which are ready to start or — if already started —
await completion. In particular, as soon as any action is ready to start the interface presents a dialog as
a prompt. When the role-holder signals that he has started the action, the latter’s associated start-time
st is bound to the current value of the portal clock. Likewise, a signal that the action has been
completed binds the action’s associated end-time et. Meanwhile, the interface is also informing the
role-holder of what the constraints (if any) are expecting of these time-points and of the attributes of
those artefacts being acted upon.
The architecture therefore requires two engines, operating concurrently — a plan interpreter for
executing the plans, and a constraint evaluator for shaping and regulating their outcomes, both
contributing to the determination of values for the ontological variables. This is the operational model
in outline. Some finer details are discussed in the sections that follow.
3. Artefact Management
The main activities undertaken by a role-holder are the creation and management of electronic
artefacts, each characterized by attributes that the system can implement concretely. For example, one
such attribute is CrTool denoting the name of the tool (application program) used to create an artefact,
whilst another is Owner naming the role-holder who owns the artefact. Presented with an artefact
having these attributes, the system applies appropriate mechanisms for managing tool invocation and
artefact ownership.
A set of compatible attributes inherently defines some artefact type. We have experimented mostly
with three types — text document, email and database table — but others may be easily
accommodated. They have some primary attributes (e.g. CrTool) in common, besides secondary
attributes specific to themselves. The internal representation of any artefact is some instance of the
schematic term
art(Name, Type, Loc, CrTool, Owner, Rights, Atts)
holding the artefact’s name, type, location, creator tool, the owner, the rights of the owner and, finally,
a set of secondary attributes whose details depend upon the type. An example of such an instance is
art(diary, txt, ‘c:/MyDocs’, notepad, r3, [read, write], null)
This represents an artefact named diary which is a text document currently residing in a local ‘c-drive’
directory; it was created using the notepad tool; its owner is role-holder r3 who has both read and write
permissions for this artefact. The null reflects that no secondary attributes are required for a text
document. Another example of an artefact instance is
art(table2, dbtable, ‘c:/accts’, ‘Mini-SQL’, r3, [read, write], atts(view2, schema1))
This represents an artefact named table2 which is a database table whose secondary attributes are a
schema named schema1 and a specification in the form of a view-definition named view2.
******************** HERE SO FAR ***************************
An artefact comes into existence through some role-holder enacting a particular kind of action in
his plan. This is the ‘create’ action whose predicate has the form
create(As, A, st, et)
in which A identifies the artefact being created and As is a set whose members identify other
artefacts upon which the creating of A is stipulated to depend. As usual, st and et denote the action’s
start and end times. Examples of two such actions appear in the plan in Figure 2. There, each artefact is
identified by a term of the form L(N) where L denotes its location and N—an ontological variable—
denotes its name. When the plan interpreter prompts a role-holder R to create an artefact A, R
undertakes whatever steps are necessary for creating it. The detailed contents of A are not constrained
by the portal and are left to R’s offline decision-making. However, the creation process is constrained
by whatever the declared constraints may require of A’s attributes and the action’s start and end times.
Moreover, the creation process requires that any artefacts cited in the As argument shall exist and that
they likewise shall satisfy any declared constraints upon their attributes. The manner in which
constraints refer to and constrain artefact attributes is described in Section 5. The portal imposes no
constraint upon the relation between the detailed contents of As and A, leaving this as a matter for R’s
off-line deliberations.
Each role-holder has a personal local workspace in which the artefacts he is working with reside.
The workspace contents are directly visible in the portal interface. It is in this workspace that an
artefact is stored when produced by a ‘create’ action.
The framework’s support for online collaboration between role-holders has two aspects—the
communication of artefacts and the testing of their joint satisfaction of constraints. Communication is
achieved whenever plans perform particular actions named ‘import’ and ‘export’, examples of which
can be seen in Figure 2. Each kind entails accessing some communal database capable of storing
artefacts. An action predicate of the form
import(Db, Loc_db(N), Loc_wsp, st, et)
accesses an artefact named N at location Loc_db in database Db and imports a copy of it to location
Loc_wsp in the role-holder’s local workspace. Conversely, an action predicate of the form
export(Db, Loc_wsp(N), Loc_db, st, et)
accesses artefact named N at location Loc_wsp in the local workspace and exports a copy of it to
location Loc_db in database Db. In general there will exist various such communal databases, whose
individual structure and management is suitably adapted to the types of the artefacts stored in them. For
text documents the database may be some disk volume offering a file-oriented directory structure; for
emails it may be the mailboxes within an email client application; for database tables it may be the
storage provisions of a conventional relational database.
In our portal model, constraints are logical formulas whose arguments denote various aspects of
artefacts and their scheduling. They are evaluated concurrently with the performing of tasks by the role
holders. The initial construction of appropriate tasks and constraints is undertaken (currently offline)
mainly by the role holders when their roles are first assigned to them, although some details may be
imposed a priori by their superiors.
It is during this construction phase that role holders must consult and plan as to how best to achieve
the goals of the enterprise. The goals consist concretely of the artefacts – and their timescales –
intended to arise from the performing of tasks. They will necessarily be solutions both of the actionbased programs defining the tasks and of the constraints.
Occasional violation of constraints in inevitable, if only because of slippage in intended timescales
or deadlines. When this occurs, role holders may revise or relax appropriate constraints or tasks in
order that their work can resume in a compliant fashion. Subject to these provisions, the overall goals
of the enterprise should eventually be achieved. Fig. 1 illustrates this concept.
2.2
Alignment of Tasks and Constraints
The tasks established by role holders are essentially plans, which they follow with the aim of
achieving their goals. In general, these plans are nondeterministic in that they may specify alternative
courses of action dependent upon unpredictable aspects of the run-time state, such as availability of
artefacts or the passing of time points. Whichever courses of action they do take, however, their
observable effect will be the creation of particular workspace artefacts at particular times. These timelabeled artefacts can be viewed as solutions ‘computed’ by task execution.
The constraints established by role holders can likewise be viewed as a means of computing
solutions also in the form of time-labeled artefacts. The constraints too are nondeterministic in that
their solutions may vary according to unpredictable aspects of the run-time state.
The model therefore operates concurrently two main processes – task execution and constraint
evaluation – whose common solutions represent achievable goals of the enterprise. It is not guaranteed
that they will exist. In principle, tasks could be devised such that no possible outcomes from them
could satisfy the constraints; similarly, constraints could be devised having no solutions that the tasks
could construct. In practice, role holders aim for a symbiotic relationship between tasks and constraints
that is analogous to the ‘decision and control’ paradigm of management. The intent is that their
solution-sets shall have a non-empty intersection. When this is so, we say that the tasks and constraints
are mutually aligned.
The constraints are formulated within the finite-domain paradigm of SICStus Prolog. Their effect is
to limit the framework's variables to values within specified finite sets. Those variables are typically
attributes of the artefacts or time points relating to task actions. The evaluation of such constraints upon
variables whose values have been already determined is to check whether those values fall within the
specified sets. Evaluation of constraints upon so-far-undetermined variables, by contrast, has the effect
of offering (through the portal interface) sets of values that could be assigned to them.
The balance between these two kinds of behaviour is determined by how lazily or how eagerly the
constraint evaluation is performed relative to task execution. Lazy evaluation permits the tasks, under
the control of the role holders, to exercise unfettered initiative in choosing values for the variables – in
concrete terms, fixing various attributes of the artefacts and fixing timescales for the actions that
manipulate them. In this case there is significant scope for role holders to make choices that will
subsequently be rejected by the constraints. Eager evaluation, on the other hand, presents to role
holders selections of choices assuredly satisfying the constraints, although such choices are still not
obligatory.
Thus in both modes there remains the possibility of constraint failure, but with differing degrees of
probability. As noted earlier, constraint failure must eventually be eliminated if the goals are to be
achieved. An important feature of the framework is therefore the machinery allowing role holders to
revise constraints or plans, as they see fit (and as far as they are permitted). Ultimately, all such failures
should be eliminable by sufficient revision of beliefs or actions. A key technical issue here is the
localisation of responsibility for a failure, in order that such revisions can be conducted efficiently. We
are exploring various mechanisms for this, with emphasis upon those not dependent upon specific
internal features of the constraint evaluator.
3
The Knowledge Derived by the Portal
As tasks are executed, artefacts accumulate within the role holders' workspaces. They are created by
particular kinds of action, and are communicated between workspaces by other kinds of action. Each
artefact can be regarded as having two components - template and data. The template is essentially an
abstraction of the artefact, holding its identity, its type and its type-specific attributes. These are the
features, named by appropriate variables, to which constraints may refer. The framework supports
defined template types for document-oriented artefacts such as emails, text files and database records.
An artefact's data component, by contrast, has no features to which constraints may refer. It comprises
material presumed to be established by the role-holder in a manner opaque to the framework. An
example might be the message content within an email. The dividing line between template and data is
a pragmatic one. Generally, we define the data as comprising those aspects (if any) of the artefact that
the constraints are not required to know about.
Besides the document-oriented artefacts just exemplified, there exists a special type of artefact
called an activation record. Its template holds its type, an action identifier and that action's start and end
times. These features are likewise named by variables to which constraints may refer. Its data
component is empty. When any action is initiated within some task, a corresponding activation record,
appropriately instantiated, is automatically created in the role holder's workspace. When the action is
completed, the activation record is further instantiated with the end time. The creating of activation
records proceeds independently of what the actions are themselves achieving.
The action identifier in an activation record contains sufficient information to locate the originating
action at some point on some branch in some task. Each branch in a task has some (possibly null)
precondition, and likewise each action in a branch has some (possibly null) precondition. Such
preconditions are predicated upon the same class of variables as employed by the constraints. Thus, for
any action to have been initiated, some conjunction of preconditions along its branch must have
become true. We call this the action's (overall) enabling condition. A concrete example might be that
the date be less than 2004 and that an email has arrived from a particular sender.
In the long run, after however much revision has proved necessary, every artefact in a portal
workspace should satisfy the constraints. In addition, for every activation record in a portal workspace,
the enabling condition for its associated action should hold. The functioning of the framework therefore
accumulates two species of knowledge, both expressible in logic: first, that the constraints hold for
those values of their variables as determined by the current pool of artefacts; second, that the enabling
conditions hold for those values of their variables as determined by the actions performed. Together
they constitute the Derived Knowledge manifested by the enterprise being modeled. It corresponds to
what some refer to as explicit knowledge [11]. Clearly, it evolves with time, and is defined only at
those times when tasks and constraints are mutually aligned. The semantics of the framework at any
such time can be formulated in terms of the logical models of the currently derived knowledge. The
values assigned to the variables determine features of the artefacts representing the enterprise goals
achieved so far.
4
Agent Representation: A Brief Illustration
Each role holder is implemented as an agent represented by a role script written in Prolog. This
defines the agent’s ontology, tasks and constraints. Below we illustrate a role script for an agent pgas
(“postgraduate admissions secretary”), restricted here to one task (task1) whose entry point is the start
of the action-sequence script1:
% The agent's ontology - private (own) and public components.
ontology(pgas, own, [session, msc_student, res_student, st1, st2,
st3, et1, et2, et3]).
ontology(pgas, pub, []).
% The agent’s entry point for a task.
primary_script(pgas, task1, script1).
% The agent's actions in this task.
action(pgas, script1, 1, import(mscdb, nxtsess(session), pgs, st1,
et1)).
action(pgas, script1, 2, create([pgs(session)], pgs(msc_student),
st2, et2)).
action(pgas, script1, 3, export(mscdb, pgs(msc_student), data, st3,
et3)).
% The agent’s constraint - here, just one for this task.
constrain(pgas, task1, 1, pgasc111(et1, et3)).
pgasc111(T1, T3) :- T3 - T1 #=< 5.
role_manager(pgas) :- common_role_manager(pgas).
The ontology declares the terms used by the agent to refer to the entities (including time points such
as st1) that it deals with. They serve as variables within both actions and constraints. They are
presented as ground atoms to preserve their identities when propagated through the computation. An
action is identified by an agent id (pgas), script id (script1), index number (e.g. 3) and action primitive
(e.g. export). The index numbers govern the order in which actions are performed.
The role manager defines how the agent coordinates the execution of actions with the evaluation of
constraints. In this example the agent simply invokes a standard protocol called the common role
manager.
Each constraint is declared by an assertion of the form:
constrain(Agent_Id, Task_Id, Constraint_Index, Call).
whose Call argument accesses the separately-defined logic of the constraint. As with actions, the
declaration employs the agent’s ground ontology. In the example, this logic simply constrains the
difference between two time points. More generally, the constraints can also constrain the attributes of
artefacts manipulated by the actions. In all cases they are evaluated using a finite-domain constraint
evaluator.
For a more detailed description of the framework’s architecture, including the structure and
operation of role scripts, the reader is referred to [1].
5. Constraints
The system’s plan interpreter is responsible for executing autonomous actions and alerting the roleholder of required off-line actions, in accordance with the schedules expressed by the tasks, whilst
honouring the satisfaction of any action preconditions and task block related tests. Constraints in the
system state those requirements of the tasks and artefacts, not expressed by such preconditions and
tests, and provide an extra level of control that is both powerful and flexible.
We do not stipulate within our logical formulation the point at which constraints are checked. At one
extreme, it would be possible to simulate in advance the complete course of role-holders’ actions,
checking constraints eagerly and determining whether, and under what circumstances, the plans could
lead to the successful accomplishment of the role-holder’s tasks. At the other extreme, constraint
checking could be left to the end, simply testing whether the actions had been carried out according to
the temporal constraints and whether the artefacts attributes satisfied their constraints. A middle ground
would perform constraint checking in “real time”, notifying the user of the deadlines he needed to
meet, with regard to action completion, and providing tools and other facilities for artefact creations, in
accordance with attribute constraints. Under this last regime, temporal constraint processing would
resemble traditional critical path analysis.
A constraint is a relation between one-or-more role-holders’ ontological variables, including start
and end times of actions carried out by those persons and artefacts employed or created by them. In a
later section, dealing with delegation, we shall explain how constraints involving action times and
artefacts of more than one role-holder can be included in the system. In this section, we shall restrict
ourselves to constraints involving a single role-holder.
As mentioned in the previous section, each such constraint is asserted via a constraint declaration of
the form:
constraint(role_id, task_id, index, call)
The first argument refers to the role, the second to the particular task within that role, index is a
positive integer and the last argument is a call to a logic program, most generally in CLP(FD),
Constraint Logic Programming over Finite Domains, effectively a superset of Prolog.
Here is a fragment of code for role-holder “pgas” (postgraduate admissions secretary) to illustrate
the handling of temporal constraints. It deals with the actions of the secretary importing a database
“artefact” to determine the dates of the next academic session, the creation of a list of MSc applications
and its export to the database on the server:
ontology(pgas, own, [session, st1, st2, st3, et1. et2. et3]).
ontology(pgas, pub, null).
action(pgas, block1, 1, import(mscdb, session, pgs, st1, et1)).
action(pgas, block1, 2, create([session], msc_student, st2, et2)).
action(pgas, block1, 3, export(mscdb, msc_student, data, st3, et3)).
…
constraint(pgas, task1, 1, pgasc111(et1, st2)).
constraint(pgas, task1, 2, pgasc112(st2, et2)).
constraint(pgas, task1, 3, pgasc111(et2, st3)).
pgasc111(ET1, ST2) :on_or_after(ET1, ST2),
pgasc112(ST, ET) :current_year(CY),
ST = D1/M1/Y1,
ET = D2/M2/Y2,
Duration #> 0,
Duration #=< 2,
date_diff(ST, Duration, ET),
on_or_after(18/6/CY, ST),
on_or_after(ET, 1/7/CY),
working_day(ST),
working_day(ET).
Figure 4. Constraint fragment for pgas.
pgasc111 simply constrains the consecutive import and create actions (block 1 – actions 1 and 2)
so that the second cannot commence before the first has been completed.
pgasc112 constrains the start and end times for the create action to be between 18 th June and 1st
July of the current year and the non-zero duration of this action to be no more than two days.
Furthermore the start and end times must not fall on a weekend or public holiday. The comparison
operators #> and #=< are built into CLP(FD) and apply to variables that range over finite domains of
integers. The conditions date_diff, on_or_after and working_day are themselves simple
CLP(FD) programs that involve translating between dates and serial numbers, the latter also being
domain variables.
Assuming that the import action was completed on 19 th June, and that the constraints are set to run
in real time, the constraint engine will compute the possible times of all remaining actions and, in
particular, the possible start and end dates of the following create action. It displays the possible dates
on the screen, a fragment of which is displayed below:
June
July
14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5
S S M T W T F S S M T W T F S S M T W T F S
import(mscdb, nxtsess(session), pgs, st1, et1)
create([pgs(session)], pgs(msc_student), st2, et2)
et1 
st2 "
et2
Assuming that the role-holder actually commences the create action on 23rd June. By clicking on the
appropriate cell in the row marked with the diamond, the start time of the create action will be
instantiated to 23rd June in the system, the constraints will be re-run and the display will be updated to
indicate the new possible end times for the create action (24 th or 25th June):
June
14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1
import(mscdb, nxtsess(session), pgs, st1, et1)
create([pgs(session)], pgs(msc_student), st2, et2)
2
July
3 4
et1 
st2 
et2 "
In fact, it is perfectly possible for the role-holder to employ this portal tool in “what-if?” mode,
experimenting with various start times and exploring the repercussions on the times of remaining
actions.
Constraints are not only concerned with temporal variables but also with the attributes of artefacts
that the role-holder is involved in creating. Each artefact dealt with by a role-holder will be amongst
her ontology variables. The following fragment of code for role-holder “hods” (the Head of
Department’s secretary) illustrates the handling of one of the attribute constraints of a role-holder:
ontology(hods, own, [jobadvert, st1, st2, st3, et1. et2. et3]).
ontology(hods, pub, null).
action(hods, block1, 1, create(null, jobadvert, st1, et1)).
action(hods, block1, 2, export(advertsdb, jobadvert, latestad, st2, et2)).
constraint(hods, task1, 1, hods123(jobadvert, [type(txt)]).
hods123(Artefact, ConstraintList) :Handles = [name(N),type(Ty),tool(Tl),owner(Ow),Rights(R),scndryAtts(Scnd)]
establish_handles(Handles, ConstraintList),
cross_check(Handles),
Artefact = art(N, Ty, Tl, Ow, R, Scnd).
5
establish_handles(Handles, ConstraintList) :onList(Handles, Handles, ConstraintList),
infer(Handles, Handles),
default(Handles, Handles),
infer(Handles, Handles),
ask(Handles, Handles).
onList([], Handles, ConstraintList).
onList([H|Hs], Handles, ConstraintList) :member(H, ConstraintList),
onList(Hs, Handles, ConstraintList).
onList([H|Hs], Handles, ConstraintList) :onList(Hs, Handles, ConstraintList).
infer([], Handles).
infer([type(T)|Hs], Handles) :member(tool(Tl),
tool(Tl, TypeList, _, _, _, _),
member(T, TypeList),
infer(Hs, Handles).
infer([tool(Tl)|Hs], Handles) :member(type(T),
tool(Tl, TypeList, _, _, _, _),
member(T, TypeList),
infer(Hs, Handles).
infer([H|Hs], Handles) :infer(Hs, Handles).
ask([], Handles).
ask([H|Hs], Handles) :\+ ground(H),
write(‘Please enter the attribute for ‘), write(H), write(‘ : ‘),
read(H),
infer(Handles, Handles),
ask(Hs, Handles).
The artefact jobadvert is characterised by its attributes, which are accessed via a set of handles.
6
Related Work
The development of portals has proceeded in three general directions, which may be classified as the
‘business’ approach, the ‘specialised community’ approach and the ‘web-technology’ approach.
Analysts and portal developers including major software developers such as IBM and Sun
Microsystems predominantly undertake the business approach to portal development. Portals
developed by this approach can be broadly classified as Internet Portals, the Yahoo!-like portals that,
in most cases, support general searches and have sets of preorganised categories of information, and
Enterprise Information Portals, or Corporate Portals, the corporate version of enterprises’ internet
portals.
Special interest groups and communities have also embarked on developing dedicated portals to
serve the interest of their members. An example is the Java Architectures Special Interest Group (JASIG), an independent organisation promoting the use of Java technologies and architectures within the
higher education community. One of the activities of the group is to develop and share a free, open
source, open standard portal for higher education, known as uPortal1. The group’s efforts have
produced a number of university portals, developed and deployed by its members [8].
An example of a user community portal is the knowledge acquisition community portal [17]. The
portal, known as the KA2 2 portal, is developed based on an ontology as a semantic backbone for
accessing and contributing information as well as for developing and maintaining the portal. The
ontology presents explicit knowledge that structure all information in different formats for the
community, at various levels of granularity. Although not directly concerned with the technical
development of a portal, there are other community portals that are built merely to serve their intended
communities. The BDD Portal [14] is a community portal developed to serve those researching binary
decision diagrams. It provides common features of a portal such as links to resources, literature search
and a system that allows use and evaluation of decision diagram heuristics.
The web-technology approach is by no means an attempt to specifically develop portals, but the
technical aspects of this approach are usually consolidated in a portal. The most prominent research
area in this approach is search. The problem of finding precise information when using general-purpose
search engines such as Google has prompted research on developing new search algorithms [2]. A
good example is CiteSeer [7], a web site for seeking papers in all areas of computer science. CiteSeer is
an autonomous citation indexing system, which indexes academic literature in electronic formats.
Other techniques attempted include agent-based browsers [10], [12], adaptive web sites [15], machine
learning [13], declarative specification [5] and the Semantic Web [3]. The latter is an attempt by the
W3C to make the Web more intelligent so that trivial tasks could be delegated to intelligent software
agents, the key components of the Semantic Web.
1 http://mis105.mis.udel.edu/ja-sig/uportal/
2 http://ka2portal.aifb.uni-karlsruhe.de
7
Conclusions and Further Work
Our Workspace Portal framework is based upon the dual deployment of procedural and declarative
elements in the characterisation of a multi-agent enterprise. The agents' plans making up the procedural
element can be viewed as the outcomes of compiling and concretizing some portion of the enterprise's
internal logic. The residual uncompiled portion of that logic then makes up the declarative constraints
attending the plans. The balance between the two elements is not prescribed by the framework,
allowing flexibility in its application to different forms of enterprise.
Our use of finite-domain constraint evaluation has, we believe, the potential for novel contributions
to the modeling of collaboration. In particular, it opens the way for modeling a diversity of mechanisms
concerned with the avoidance, detection, localisation or amelioration of dysfunctionality.
Dysfunctionality, meaning the failure to achieve enterprise goals, concerns not only the nature of the
artefacts produced by the agents but also their scheduling, which is why our framework includes both
artefactual and temporal variables in the agents' ontologies, actions and constraints.
Space limitations preclude detailed discussion in this paper of other features in our framework
dealing with the agent hierarchy through which roles may be assigned, retracted or delegated. These
features offer interesting possibilities for the control of agents' responsibilities in their response to
constraint failures, which we intend to develop further in future work. We intend also to investigate the
sharing of derived knowledge within the organisation – one of the key aims of Knowledge
Management.
References
1. Ahmad M. S., Hogger C. J., Kriwaczek F. R., Implementing Collaborative Agent System using Prolog,
Proceedings of the International Conference on Information Technology and Multimedia at UNITEN, (2001).
2. Arasu A., Cho J., Garcia-Molina H., Paepcke A., Raghavan S.: Searching the Web, ACM Transactions on
Internet Technology, Vol 1, No. 1, (2001).
3. Berners-Lee T., Hendler J., Lassila O., The Semantic Web, Scientific American, Vol. 284, No. 5, May 2001.
4. Davydov M. M.: EIP: The Second Wave, Intelligent Enterprise Magazine, Vol. 3 - No. 4, (2000).
5. Fernandez M., Florescu D., Kang J., Levy A., Suciu D., Catching the Boat with Strudel: Experience with a Web
Site Management System, Proceedings of the ACM SIGMOD, International Conference on Management of
Data, (1998).
6. Firestone J. M.: Defining the Enterprise Information Portal, Executive Information Systems Inc., White Paper
No. 13, (1999).
7. Giles C. L., Bollacker K. D., Lawrence S., CiteSeer: An Automatic Citation Indexing System, Third ACM
Conference on Digital Libraries, (1998).
8. Gleason B. W., Boston College University-Wide Information Portal - Concepts and Recommended Course of
Action, (2000).
9. Grammer J., The Enterprise Knowledge Portal, Stay Informed: Current Issue Article, (2000).
10.Joachim T., Mitchell T., Freitag D., Armstrong R.: WebWatcher: A Tour Guide for the World Wide Web,
IJCAI '97, Vol. 2, (1997).
11.Kidwell J. J., Vander Linde K. M., Johnson S. L., Applying Corporate Knowledge Management Practices in
Higher Education, EDUCAUSE Quarterly, No. 4, (2000).
12.Lieberman H., Van Dyke N., Vivacqua A., Let's Browse: A Collaborative Web Browsing Agent, (1997).
13.McCallum A. K., Nigam K., Rennie J., Seymore K.: Automating the Construction of Internet Portals with
Machine Learning, Information Retrieval, Vol. 3, Issue 2, (2000).
14.Meinel C., Wagner A., WWW.BDD-PORTAL.ORG, Proceedings of the IEEE IWLS 2000, (2000). Available
at http://citeseer.nj.nec.com/meinel00wwwbddportalorg.html.
15.Perkowitz M., Etzioni O.: Towards Adaptive Web Sites: Conceptual Framework and Case Study, Artificial
Intelligence, Vol. 118, (2000).
16.Shilakes C. C., Tylman J.: Enterprise Information Portals, (1998).
Available at http://www.sagemaker.com/Company/WhitePapers/eip_indepth.pdf.
17.Staab S., Angele J., Decker S., Erdmann M., Hotho A., Maedche A., Schnurr H.-P., Studer R., Sure Y.,
Semantic Community Web Portals, Computer Networks, Vol. 33, (2000).
--------- dumped frag --------
Our Workspace Portal is driven by the performance of tasks subject to constraints defining goals.
Tasks are programmed sets of actions capable of creating and manipulating artefacts, such as
documents and database records. Sets of related tasks make up roles. Role holders work collaboratively
by operating upon artefacts in their workspaces and by sharing those artefacts with one another.
Collaboration is ensured by their joint compliance with the given constraints. The following sections
describe these features in more detail.