The
other level is the task (or sometimes query) level, in which the configured
collections of agents actually do something. What they do, how they do it, and
what they say to each other as they do it is all application/implementation
dependent, and UMDL makes no commitments and imposes no constraints other than
to insist that they can describe themselves in the conspectus language
adequately so that the configured teams really can work together to accomplish
their tasks.
There are thus two different levels of activity that traditionally go on in the UMDL: conspectus/architecture level activity involves such things as agent registration, task/capability description, capability location, and deal formation; while task level activity involves such things as document retrieval, text translation, query reformulation, and result visualization.
Conspectus search and retrieval is concerned with the former activities. Specifically, we define the task of conspectus search and retrieval in the following way. An agent with a task that it needs done initiates conspectus search. The ultimate result of conspectus search is a (possibly empty) set of agent-deals for accomplishing the desired task. An agent deal specifies which agent has agreed to accept the task, and any other parameters about the use of that agent (the price the agent is charging to do the task, the timeframe in which it will do the task, etc. etc.) that the initial agent might need to know. (Many of these are still TBD.)
A conspectus search can also return intermediate responses such as requests for further information about the task to be done, requests about constraints on what agent-deals might be acceptable, suggestions about how the task might be modified to reach better agent-deals, etc. The initiating agent should also be able to asynchronously provide additional information to an ongoing conspectus search.
The (currently) canonical example of a conspectus search is for the task of answering a query. With the help of a UIA, the user formulates the query task such that the capabilities of agents who can accomplish the task is discernable. Glossing over how deals are made during the conspectus search itself (for the time being), the UIA then forwards the task to a mediator that has enough knowledge to forward it in turn to a query-task planning agent that has expertise for planning this particular type of query. In a way to be elaborated as we go along, that agent in turn interacts with various authorities, thesauri, query broadeners/narrowers, and so on, possibly going back to the UIA for more information, until it has finally been handed the conspectus entries for possible collections that can handle the query. It calls on dealmaking facilitators to construct agent-deals with the collections, and returns (a subset of) these to the UIA. Of course, as described a little more below, the information flow between the various agents will vary depending on what happens at each. The UIA then selects one or more agent-deals, and contacts the agent(s), passing the task in the particular task (query) language specification, rather than at the conspectus level.
Thus, the objective of conspectus search is to return agent-deals that have been set up, such that the recipient of those deals can work with the other agents at the task level.
More generally, it is probably the case that what we are dealing with here is a continuum of tasks. Conspectus search is a task; we just distinguish it from other tasks as being special in some way. Other tasks might similarly have some "special" characteristics, or be more or less "special." If we think about the tasks and the languages to support them, we might identify at least the following:
1. Languages for describing agents, and tasks of sharing these descriptions. If our architecture is going to succeed, agents need to be able to describe their capabilities (goods and services) in a language that everyone can understand; they need to be able to publicize their capabilities; and they need to be able to find each other based on these descriptions. These are the basic notions of ontologies of capabilities, and of updating/querying the registry.
2. Languages for describing deals, and tasks of sharing/consumating these deals. If there are economic principles behind our architecture, then there must be agreement on what the commitments that agents make among themselves mean, the terms of those commitments, the facilities for transactions, etc.
3. Languages for describing and enacting queries.
4. Languages for describing the conspectus search task.
5. Languages for supporting tasks within conspectus search, such as interactions with name authorities, thesauri, etc.
6. Languages for tasks involving information manipulation, such as translation.
There are likely to be many, many more. The point to raise here, however, is that some task languages might need to be more or less universally adopted. We have generally assumed that any agent that is going to be part of the UMDL has to speak the language for item 1: agents must be able to describe themselves, understand descriptions of others, and use the basic performatives to interact with the registry. In a way, we can think of the registry as a single logical agent (although it could well be physically distributed); we are saying that the minimal requirements are that all agents within UMDL support interactions with the registry agent.
The second item might or might not be something that we have to insist on being universally adopted (it could be that the item in fact mixes up more or less universal issues). It seems clear that, at some level, there must be some shared semantics for what it means when an agent is supplying its capabilities in support of another agent. Whether this is implicit in the architecture or explicit in a language for describing "deals" among agents is debatable; in the long run, though, it appears like flexibility will dictate explicit descriptions of deals (e.g. contracts among agents).
The third item has been one that we have debated over often. Is there a common query language? The answer generally seems to be both yes and no. No, we should not dictate a particular language for conducting queries to particular collections. But, on the other hand, yes, we should have a common language so that we can have a single query that can be understood by many different collections. I think the answer to this is that we don't want to make an architectural commitment to having a common language for queries (while we do want to make an architectural commitment to a common language for item 1 and possibly item 2), but we do want to make a local commitment to each other to adhere to a common language for our current development efforts.
The fourth item is much like the third. Describing a conspectus search task - the description of the task that a configuration of agents is desired to accomplish - seems to be a language that certainly only a subset of agents need to speak (for example, a thesaurus agent need not understand it). Thus unlike item 1 (and possibly 2), and like item 3, this need not be a common language. That said, like item 3 this could be a language that we should set local standards for, and make local commitments to.
The fifth item is like the fourth. It focuses on languages that only a specialized subset of agents need to be able to speak, but for which we probably want to make a local commitment to.
The sixth item is intended to be a placeholder for the variety of other task languages that we might not even make a local commitment to. Frankly, as the number of agents within UMDL that could use the language gets smaller, the motivation for standardizing the language gets weaker.
Overall, this leads to some general groupings of the languages for tasks within UMDL: there are architecturally-committed languages (item 1 and possibly 2), that anyone who wants to introduce agents into UMDL must ensure their agents speak; there are locally-standardized languages (items 3-5) that we adhere to within our development efforts and that we might recommend to others - but not enforce; and there are non-standard languages for supporting arbitrary execution of tasks across agents.
I would say that, in its basic form, conspectus search and retrieval is a process that takes as input a description of capabilities required and a description of the terms of the deal(s) for providers of those capabilities, all within the universal languages. Conspectus search and retrieval provides as output a set of agent-deals (agents with the capabilities and specific terms of the deals with them).
In this rudimentary form, conspectus search and retrieval should be accomplished only by using the registry (to retrieve the agent(s) with the needed capabilities) and a market facilitator (to establish the terms of the deal).
Of course, as in any such system, things need not always be so simple. We could (and should) define a UMDL-standard language for conspectus search and retrieval that subsumes the simple registry-retrieval-and-deal aspects of the basic form above. Our richer language allows more interesting descriptions of the conspectus search and retrieval task, including specifications on such things as constraints on the search effort, precedence relationships among phases of the search process, conditions under which to modify search behavior, and so on. These complex search strategies can be encoded within agents, and to some extent within the richer language. Eventually, however, agents that speak this language must generate basic conspectus search and retrieval tasks.
For some of the UMDL tasks, the knowledge and symbol levels have been successfully brought together. The UIA comes to mind, where the same researchers are simultaneously considering what interface/profiling capabilities are needed along with how they can be provided. The same can be said for the (now subgroup of) CIA, which is concerned with the processing of domain-level queries at collections, drawing on IR concepts and techniques. But in the middle, things have gotten very fuzzy, because it becomes hard to look at knowledge capabilities (and their physical realizations) in isolation to the rest of the "middleware."
This is why, for example, the development of mediators has become intertwined with issues of conspectus search and retrieval: the physical, architectural development of mediators must support the logical functionality that they have to demonstrate in UMDL. Or, once again, the limitations of what can be physically realized should inform the more logical design of the UMDL, in terms of what functionality to strive for, at least in the near term. The same can be said for relationships between the physical realization of a distributed registry, and the logical distribution of meta-data among various "authorities." And so on.
So, in an effort to articulate the knowledge-level (logical) and symbol-level (physical) distinctions, below we look at a snapshot of the "conspectus search" task to first figure out what needs to go on, and then how it can be realized.
In words, some of the things that need to happen are that:
* There must be capabilities for user interaction with the system (a given).
* The interaction capabilities must work with formulation capabilities to capture the essence of the (in this case) Query Task (Qtask) the user wants done. Some of these capabilities might be enumerated separately, such as the capability of "serving terms" to tell the formulation system about permitted terms in the conspectus language. Such breakdowns of capabilities are not shown.
* The formulated Qtask then needs to be pursued, meaning that deals must be struck with agents that can accomplish the actual task that the Qtask formulation describes. Expertise about how to best try to accomplish tasks is domain dependent, but will often require many capabilities.
* For complex Qtasks, the capability to decompose the task into simpler tasks is needed.
* For cases where the Qtask is too specific (too few candidate collections are found), accomplishing the task might require that some of the terms used in the query are broadened. For example, a name authority might broaden the range of formulations of the author's name.
* Alternatively, when the Qtask is too general (too many candidate collections are found), accomplishing the task might require that some of the termsused are narrowed.
* Depending on the kind of Qtask, finding appropriate collections might be facilitated by using query-type-specific indices, such as an author catalogue.
* For cases where an index returns only a partial collection description (partial conspectus entry) or when no index is relevant, pursuing the Qtask could require an additional query to the registry/conspectus database. For example, the author catalogue might not know which of the documents it points to are of type "image."
* In turn, the registry might request updates about particular collections, of course...
* Having found some appropriate collections, further accomplishment of the Qtask requires that a deal with the collections must be brokered, which requires that the collections (their interfaces) know what deals are acceptable to them, and so on.
Of course, even at this level of detail, the description of what needs to go on is inadequate. Ignoring many of the possible objections/elaborations and so on, let me just point out three addenda to the example.
First, it should be abundantly clear that there is no simple sequential movement among these capabilities. The order in which a Qtask is pursued will depend on the task and the feedback from other capabilities. For example, broadening or narrowing terms makes sense if the original terms have been found to be lacking. And whether this decision is made at the time that candidate collections are identified, or waits until after the success or failure of dealmaking has been discovered, is a matter of opinion. Of course, at any time during the pursuit of the task, the user might be asked for a reformulation, or the user might volunteer a new reformulation on his or her own. In short, the diagram is purposely unspecific about the order of actions and about the nature (and use) of the information/feedback exchanged among the agents. To actually realize this complex web of capability interactions within UMDL, however, requires that we be specific about what the capabilities do - their inputs, outputs, and behaviors.
Second, this in turn means that, during the process of conspectus search, there could be a variety of task-level activities going on. It is possible that all of the exchanges between different planners, authorities, facilitators, and so on are formulated in the conspectus language, but making such a commitment seems premature at best. More likely, the agents with these capabilities will converse in a particular task language, once they have discovered who they should talk to through a conspectus search.
Third, therefore, it should also be clear that there are many other conspectus searches going on during this overall conspectus search. Qtask planners need to find term broadeners, and registries, and so on. This is why, in the general formulation of conspectus search above, we just say that an agent (could be a UIA, but need not be) with a task to do does a conspectus search to know about deals that are available with agents that can do those tasks. This raises the fear that dealmaking climbs the infinite "meta-level" ladder. In UMDL (and probably most electronic commerce systems), the way out of this is that there will be the equivalent of "standing deals" within the system. For example, the registry will always process lookup requests, and a facilitator representing the auction of some service/good will always accept bids and offers.
Thus, the diagram depicts how a set of capabilities collectively solves a particular task. But it should never be forgotten that forming such a collective is itself a task that must be done in the UMDL. Thus, it goes without saying that there are a variety of capabilities for team building, capability identification, negotiation, dealmaking, monetary transfer, and so on that supports the level of interaction described here.
Where does this view get us? Well, it decouples what agents should do based on what they know, their goals, and their beliefs, from the nitty-gritty issues of how they do what they do (and all the performance concerns that come along with that). We get an understanding of the knowledge-level capabilities (and thus the knowledge engineering requirements) of the UMDL. I would assert that it is at this level that we should encourage the SILS-oriented faculty (especially) to work, because it is precisely this level of knowledge that the engineering faculty, as a whole, lack.
Similarly, the physical level must be concerned with architectures for mediator agents that can embody the capabilities required at the logical level. Some of these might similarly involve database implementations (for thesaurus capabilities, for example); others might require more proactive capabilities (for registry maintenance or for the persistent and flexible pursuit of a particular task, for example).
The logical level also identifies the inputs, outputs, and behaviors of agents, which provides the basic requirements of the language(s) used between the capabilities and their semantics (performatives). How these are physically realized is based on the available tools; what they should say/do is dictated by the logical needs. The "how" of implementation, whether it be of low-level protocols, architectures for individual agents, or databases for agents, seems to fall mostly on the shoulders of the EECS faculty
We need to provide the capabilities specific to UMDL's task of searching for collections. This means we need to identify the important capabilities/knowledge that people (librarians) use for deciding what collections to go to, including criteria for choosing collections, tools for supporting the search, how feedback from some activities impacts later decisions, and so on. This will give us a handle as to what particular mediators we need to implement in a reasonably fleshed out version of the UMDL.
We need to realize the general and UMDL-specific capabilities described above in real implementations, considering issues of performance and reliability. Assuming the registry will have "standing" deals and will be at the core of locating capabilities/collections, it is crucial that it be implemented in a distributed manner to improve retrieval time and reliability, even if it is viewed by other agents as if it were within a single agent. We need to implement (or borrow implementations of) the relevant services - name authorities, term broadeners/narrowers, and so on. We need to encode the complex web of procedures that librarians use to identify sources, and do so in a way that allows these procedures to be invoked proactively when appropriate.
We have our work cut out for us! What we need to do, in the short term, is to invest our energy in a subset of this work. Toward this end, Amy is detailing some scenarios of how librarians identify sources, to give us some examples of what capabilities are most needed and how/when they are used. Our goal for November should be to build the mediators and distributed registry that encode knowledge that allows us to duplicate this kind of reasoning. To the extent that this can include real dealmaking by facilitators, and interact richly with the UIA, so much the better. It is likely, however, that we won't worry about the "meta-level" conspectus searches at this point, instead assuming that we have standing deals among the mediators; we just need to strike new deals between the CIAs and the UIAs.
That's my 2 cents.