EP1224570A1 - A system for composing applications based on explicit semantic models, event driven autonomous agents, and resource proxies - Google Patents

Abstract

A system for dealing with entities from various aspects by applying models (209) to the entities. The models are graphs whose vertices represent the entities and whose edges represent relationships between the entities represented by the vertices. The models are user-definable and belong to user-definable model types. The model types are defined separately from the models and establish operations which are common to all models of the type. In one application, the vertices represent concepts and the edges represent relationships between the concepts. The concepts are further related to instances (309i) which may represent items (303i) that are examples of the concepts, agents, or other models. Agents (304j) are user-defined programs that execute in the context of the model (209) and use the operations defined for the model's type. Because model types are separate from models and concepts are separate from instances (309i), models may be quickly constructed and given a model may be applied to different sets of instances. In a preferred embodiment, the model type is further employed in the user interface to simplify construction of models by the user.

Description

A system for composing applications based on explicit semantic

models, event driven autonomous agents, and resource proxies

Cross references to related applications

This patent application claims priority from the U.S. provisional application, USSN

60/116,257, J. Anthony, et al., A system for composing applications based on interacting multimodal models and the explicit separation of models and their subjects, filed 1/16/99

Background of the invention

1. Field of the invention

The invention pertains generally to techniques for organizing, accessing and processing data and pertains more specifically to techniques for organizing, accessing, and processing data so that it can be dealt with according to a variety of aspects.

2. Description of related art

Data is useless until it is turned into information. An essential part of turning data into information is organizing the data. For instance, a collection of books does not become a library until the books are classified according to some system, each book is given a code that indicates the classification, and the books are arranged on the shelves according to their codes. A problem with any classification system is that it is good for some uses and not for others. For example, libraries generally classify their books according to subject matter; if a user wants to find a book by the name of the author, the subject matter classification is no help. Even where a user knows what topic he is interested in, the subject matter classification may not be helpful: most books deal with more than one topic, but a book can only occupy a single position on the shelves, so the librarian must choose one topic to determine where the book will be placed on the shelves. For example, a history of World War II may contain a great deal of information on Winston Churchill; the librarian will, however, classify it as being about World War II, not Winston Churchill. The reverse may of course be tme with a biography of Winston Churchill. Libraries have long dealt with the need to provide a variety of classification systems for books in a library by means of card catalogs. Each catalog contains cards that refer to books, and each card for a book has the code that specifies where the book can be found on the shelf. The cards in each catalog can be arranged differently. For example, in one catalog, the cards my be arranged alphabetically by author; in another, they may be arranged alphabetically by title; and in a third, they may be arranged alphabetically by subject matter. Since a book may have any number of cards in the card catalog, a book with more than one author may have a card for each author, and a book that is about more than one subject may have a card for each subject. For example, the history of World War II may have a card under the subject "Winston Churchill" and one under the subject "World War II." In effect, the card catalog offers the user multiple aspects of the library's collection of books.

As any user of card catalogs knows, they have their limitations. For instance, a card catalog is generally no help in figuring out which Boston authors published a book in 1998, because there is no category "Boston authors" in the card catalog. Similarly, when a new way of looking at things produces a new subject matter category (for example, gender studies), it's generally not feasible to figure out which older books in the library belong to that category and put cards for them in the new category. As the examples show, the limitations come down to this:

• in order to be usable for a given task, the card catalog must be organized in a way which is useful for the task; and

• making a new card catalog or changing the organization of an old one is difficult.

The advent of the computer has greatly reduced the cost of organizing data and has thus made it possible to view data in many more ways than was possible in the day of the card catalog and its relatives. For example, if a library has a relational database of its collections and the information in the database includes the author of a book, the year of publication of the book, and the author's place of residence, it is easy to make a query which will return a list of Boston authors who published a book in 1998. Modem database systems further include powerful data processing capabilities and are highly programmable. It would not be difficult, for example, to make a query which would compute the average age of the books in the library. Nevertheless, the limitations of the card catalogs remain. As with card catalogs, the organization of a database still limits what can be done with the data in it. As database systems have gotten cheaper, people have built more and more special-purpose databases. These databases are organized in ways which make particular kinds of analysis of the data easier. Put in general terms, when new categories of analysis are required, the only solution is to build a new database.

In many cases of course, the new databases use the same data as the older ones. However, because the new database has a different organization, it cannot simply share the old database's data. The data is gotten into the new database by making a copy of the data in the old database that is needed for the new database and then transforming the data so that it is organized as required for the new database. Thus, while special purpose databases expand the number of views of the data that are possible, they do so at the cost of moving and transforming the data and at the cost of keeping the many copies of the data current.

The reason why both the card catalog and the database must be completely reorganized when a new category is added is that the concepts by which the data is organized in the card catalog or database system are part of the structure of the data in the card catalog or database system. A change in conceptual organization consequently results in a change in the structure of the data. Efforts have been made in so-called knowledge base systems to separate the conceptual organization of the data from the stmcture of the data itself. One such knowledge base system is described in United States Patent 5,418,943, Borgida, et al., Information system with knowledge base and data base, issued May 23, 1995. As shown in FIG. 1 of that patent, the system disclosed in the patent combines a database management system and a knowledge base. The knowledge base describes information in terms of concepts. The concepts include primitive concepts which are defined by means of a set of entities and compositional concepts which are defined using previously-defined concepts. The knowledge base classifies each concept as it is added to the knowledge base, that is, it uses the concept's definition to order the concept among the concepts already in the database by the degree of generality of the concept relative to the other concepts in the database. More formally, for a given concept, it finds subsumption relationships between the concept and other concepts in the knowledge base. If a concept is more general than the given concept, the concept subsumes the given concept; otherwise, the concept is subsumed by the given concept. For example, if the knowledge base has the concept CAT and the new concept CAT-WITH-BLUE-EYES is added to the knowledge base, the knowledge base will classify CAT-WITH-BLUE-EYES as being subsumed by the concept CAT.

The system of FIG. 1 of Borgida includes a query translator which translates a query written using the concepts of the knowledge base into a query of the type understood by the database management system; it thus permits users to make conceptual queries of the database system. It further permits the user to add information returned by a conceptual query to the knowledge base system, which uses the conceptual query to properly classify the information in the knowledge base. Additionally, the classification system used in the knowledge base permits operations that are not possible in the database management system, including application of forward-chaining rules based on the classification of the concepts, inferential propagation of information in the knowledge base, and execution of user- written code that is based on objects in and functions of the knowledge base.

While the use of concepts in the system of Borgida and their classification makes it possible to add concepts to the knowledge base and to use the knowledge base to do things that cannot be easily done in a standard database system, the problem of inflexibility that was found with the card catalog and the database system remains: what one can do with the concepts, and thus with the underlying data, is limited by the fact that the knowledge base deals only with subsumption relationships between the concepts. If a relationship between concepts cannot be expressed as a subsumption relationship, the system of Borgida can do nothing with it.

What is needed is systems for organizing, accessing, and processing data that not only can deal with the data in terms of concepts, but that can further organize the data in terms of a number of different kinds of relationships between concepts. Such systems should not only be able to organize data in terms of known kinds of relations between concepts, such as the subsumption relation used in the system of Borgida, but also in terms of new kinds of relations and in terms of relations that are particular to a given situation. Further, such systems should permit application of several different kinds of relations between concepts to a given set of concepts and should permit a kind of relationship that was developed for one set of concepts to be easily reused with another set of concepts. It is thus an object of the present system to provide a system for organizing, accessing, and processing data which permits data to be organized in terms of many different kinds of relationships between concepts, that permits different relationships to be applied to the same set of concepts, and that permits reuse of kinds of relationships.

Summary of the invention

The present invention provides such a system by using models to relate entities to each other. Different models can be applied to the same set of entities, and each model deals with the entities according to a different aspect. Each model has a model type separate from the model which defines a set of graphs connecting the entities and a set of operations on the graphs. A processor performs the operations specified by the model's model type on the entities in the model. The entities of the model are related to instances which represent objects, including user-defined agent programs which may be executed on the model and which use operations defined for the model's type. The objects may further be other models. The models are particularly useful when the entities are concepts and the instances include objects which are examples of the concepts they are related to. Model types, models, and agents are all user- definable.

Other objects and advantages will be apparent to those skilled in the arts to which the invention pertains upon perusal of the following Detailed Description and drawing, wherein:

Brief description of the drawing FIG. 1 illustrates how graphs may be used to show relationships among entities;

FIG. 2 shows a complex model;

FIG. 3 shows how the concepts of a model are related to instances and agents;

FIG. 4 shows the structures that represent model types, models, concepts, and instances in a preferred embodiment; FIG. 5 is an overview of a system in which models and model types are implemented;

FIG. 6 is an overview of views and viewers in the system of FIG. 5;

FIG. 7 shows a user interface for defining a new model; FIG. 8 shows a user interface for defining a root concept;

FIG. 9 shows a user interface for adding a subclass concept to a model of the taxonomy type; FIG. 10 shows a user interface for adding an instance to a concept of a model; FIG. 11 shows a user interface for adding a referent to an instance; FIG. 12 shows a user interface for displaying a model; FIG. 13 shows the events model in Ariadne; FIG. 14 shows the actions model in Ariadne; FIG. 15 shows the operations model in Ariadne;

FIG. 16 shows two agents attached to the root of a taxonomy model; and FIG. 17 shows a user interface for attaching an agent to a model.

Reference numbers in the drawing have three or more digits: the two right-hand digits are reference numbers in the drawing indicated by the remaining digits. Thus, an item with the reference number 203 first appears as item 203 in FIG. 2.

Detailed Description

The following Detailed Description will begin with a simple example of how the invention may be used and a description of an implementation of the example and will conclude with a generalized description of the invention.

Using graphs to specify multiple aspects of a collection of data: FIG. 1

For purposes of the following informal discussion, the term graph is used in the sense of a set of points where at least one of the points is connected to itself or another point by an arc. The points are termed the vertices of the graph and the arcs are termed its edges. In the graphs used in the invention, the vertices represent entities such as concepts and the edges represent relationships between the concepts. In FIG. 1, graphs are used to represent a taxonomy 101 of concepts relating to clothing. The concepts belonging to a given taxonomy are related to each other in both a top-down fashion, i.e., from the most general concept to the least general concept, and a bottom-up fashion, i.e., from the least general concept to the most general. In the top-down relationship, the concepts are related as class and subclass; for example, in taxonomy 101, footwear is a subclass of clothing and insulated boots is a subclass of footwear. The bottom-up relationship is termed an is a relationship, i.e., insulated boots is one of the concepts of footwear and footwear is one of the concepts of clothing. Thus, in taxonomy 101, each vertex 103 represents a concept relating to clothing, and edges 105 connect the vertices 103. The arrowhead on the edge indicates the direction of the relationship. There are two graphs in FIG. 1 ; one graph, indicated by dashed straight lines 107, indicates the subclass relationships between the concepts represented by the vertices; the other graph, indicated by solid arcs 109, indicates the is a relationships. Thus, graph 107 shows that outerwear 113 and footwear 115 are subclasses of clothing 111 and parkas 117 and raingear 119 are in turn subclasses of outerwear 113. Further, as shown by solid arcs 109, sandals 121 has an is a relationship to footwear 115, footwear 115 has an is a relationship to clothing 111, and so forth for the other concepts. Each concept has a solid arc 119 pointing to itself because each concept is itself, and therefore has an is a relationship with itself.

Subclass graph 107 and is a graph 109 thus organize the set of clothing concepts in FIG. 1 according to two aspects: a subclass aspect and an is a aspect. Subclass graph 107 tells us that outerwear 113 has two subclasses: parkas 117 and raingear 119; is a graph 109 tells us that outerwear 113 is clothing 111. Graphs 107 and 109 make it possible to consider any concept in taxonomy 101 from the point of view of its subclass relationships to other concepts and from the point of view of its is a relationships to other concepts. The operation of considering an entity in taxonomy 101 first as it belongs to one of the graphs and then as it belongs to another of the graphs is termed pivoting. The concepts of FIG. 1 can of course have relationships other than those of taxonomy 101, and those relationships, too, can be represented by graphs made up of concepts belonging to the set shown in FIG. 1 and edges connected to them. Each such graph organizes the set of clothing concepts according to another aspect, and pivoting permits a given concept to be seen according to any of the aspects represented by any of the graphs that the concept belongs to.

Models and facets: FIG. 2

Taxonomy 101 is of course only one of many possible ways of organizing the set of concepts shown in FIG. 1. In the following discussion, a particular way of organizing a set of concepts or other entities is termed a model. Thus, in FIG. 1, the concepts are organized according to a taxonomy model. As we have seen, when concepts are organized in this fashion, the relationships between them are shown by two graphs: subclass graph 107 and is a graph 109; each of these graphs is termed a facet of the model; thus the taxonomy model of FIG. 1 has a subclass facet 107 and an is a facet 109. The pivoting operation permits a concept in the set to be considered according to each of the facets that the concept belongs to.

The model of FIG. 1 is simple, i.e., it is a single taxonomy. A model may, however, also be complex, i.e, composed of two or more models. FIG. 2 shows such a complex model 201. In FIG. 2, the set of concepts of FIG. 1 has been expanded so that the items of clothing can be organized according to the season they are appropriate for. The new concepts represent the five seasons of the New England climate: winter 205, mud season 206, spring 213, summer 207, and fall 215. The set of concepts shown in FIG. 2 is organized according to complex model 201, which in turn is made up of two simple models. Clothing taxonomy model 209 is the taxonomy model shown in FIG. 1; seasonal clothing model 211 is a model of type simple graph which relates concepts representing clothing to concepts representing the five New England seasons. The facets of model 211 relate a season concept to clothing concepts for the kinds of clothing worn in the season and a clothing concept to the seasons in which the clothing is worn. The concepts parkas 117, raingear 119, sandals 121, and insulated boots 123 belong to both models. Considered as part of clothing model 209, sandals 121 is a subclass of footwear 115; considered as part of the seasonal clothing model, sandals 121 is related to the seasons in which sandals are worn, namely spring, summer, and fall. Outerwear 113, on the other hand, belongs only to clothing model 209, while winter 205 belongs only to seasonal clothing model 211.

Complex models permit additional operations. For instance, pivoting may be used with complex model 201 to consider a given concept according to each facet of each of the models the concept belongs to. For example, the concept sandals may be considered on the one hand as it is related to the concepts of clothing model 209 and on the other as it is related to the concepts of seasonal clothing model 211. Moreover, since each model organizes the concepts in different ways, the models define different sets of concepts and set operations such as union, intersection, difference, and set xor may be applied.

Model types Any set of entities which belongs to a taxonomy can be organized by means of a taxonomy model like model 209. Just as all taxonomies are alike in how they organize the entities that belong to them, any taxonomy model will have an is a facet and a subclass facet and similar relationships will exist between the entities belonging to a given facet. Moreover, any user of a taxonomy model will want to perform similar operations using the taxonomy. For example, a user will want to display all of the concepts that are subclasses of a given concept or all of the concepts that a given concept has an is a relationship with. One can thus speak of the taxonomy model type, and all other models will similarly belong to model types. As with models, a model type may be either simple or complex. Because all models belonging to a given model type have similar operations, it is possible to define those operations for the model type and make them automatically available for any model of the type.

In the present invention, users of the invention may define their own model types or use model types defined by others. A model type is defined as follows: • a facet specifier specifies each of the facets belonging to models of the type;

• within each facet specifier, a relation specifier that specifies how entities joined by an edge of the facet are related;

• propagation specifiers for the facets and/or the entire model; a propagation specifier specifies how operations belonging to models having the model type are performed.

The model type for the taxonomy model thus has a subclass facet specifier for the subclass facet and an is a facet specifier for the is a facet. The relation specifier for the subclass facet specifies that the subclass relationship is transitive, non-reflexive, and non-symmetric. The fact that the relationship is transitive means that if entity A is a subclass of entity B and entity C is a subclass of entity B, then entity C is a subclass of entity A, or in terms of FIG. 1 , that parkas 117 is a subclass of clothing 111. The fact that the subclass relationship is non-reflexive means that an entity cannot be a subclass of itself (which is why there are no edges of subclass graph 107 connecting an entity to itself). The fact that the relationship is non-symmetric means that if entity B is a subclass of entity A, entity A cannot be a subclass of entity B or in terms of FIG. 1, if parkas 117 is a subclass of outerwear 1 13, outerwear 1 13 cannot be a subclass of parkas 117. The relation specifier for the is a facet specifies that the is a relationship is transitive, reflexive, and non-symmetric. Thus, as shown in FIG. 1 , parkas 111 is itself as well as outerwear and clothing, but if parkas are outerwear, then outerwear cannot be (just) parkas.

The relation specifiers are used to define procedures for adding concepts to models belonging to the class. For instance, if new concepts, say swimwear, bathing suits, and wetsuits are added to the model of FIG. 1, with swimwear being a subclass of clothing and bathing suits and wetsuits being subclasses of swimwear, the relation specifiers will ensure that there are edges in the subclass facet connecting clothing to swimwear and swimwear to bathing suits and wetsuits, but no edges in the subclass facet connecting clothing to wetsuits or bathing suits to wetsuits, and will similarly ensure that there are edges in the is a facet connecting each of the new concepts to itself and wetsuits and bathing suits to swimwear and swimwear to clothing, but no edges connecting wetsuits and bathing suits to clothing and none connecting wetsuits and bathing suits to each other.

One example of a propagator for a taxonomy is a subclass display propagator that displays all of the subclasses belonging to a class. The subclass display propagator works by simply following the subclass facet beginning at the specified class. Thus, if the class is clothing, the display propagator will display outerwear 113, parkas 117, raingear 119, otweαrl l5, sandals 121, and insulated boots 123. Another example is an is a display propagator that displays the concepts that the specified concept belongs to. This propagator simply follows the is a facet beginning at the specified concept. Thus, for sandals 121, it will display sandals 121, footwear 115, and clothing 111.

Relating concepts to the world: FIG. 3 In order to be useful, the cards in a library card catalog relate the concepts used in the catalog to books in the library. The same is true with concepts organized by models. In order for the concepts to be useful, they must be related to entities that are examples of the concepts. In the invention, an entity that is or may be an example of a concept is termed an instance, and an instance that is an example of a concept is termed an instance of the concept. It should be pointed out here that one of the things which may be an example of a concept is a model, and thus, an instance may be a model. Using models as instances in other models is one way of making complex models. All of the instances available to a system in which the invention is implemented is termed the world of the system. In general, one makes a model to deal with a given area from several aspects, and this area is termed the model's subject. For example, the subject of model 209 is clothing and all of the instances of its concepts represent items of clothing. One thus makes a model for a subject and then relates the model to instances in the world that are relevant to the model's subject. The instances in the world that are relevant to a given subject are termed the subject's collection.

FIG. 3 shows how concepts are related to instances in a preferred embodiment. Fig. 3 shows a set 301 of instances representing objects accessible to the system upon which model 209 is being used. This set 301 is termed herein the world of the model. The subject of model 209 is clothing; in FIG. 3, instances belonging to clothing's collection are surrounded by a curve, as shown at 306. Thus, in FIG. 3, model 209 is being applied to world 301, but the instances with which it is actually concerned belong to clothing collection 306. Item instances in clothing collection 306 are consequently termed clothing instances 307. The instances in clothing collection 306 with which model 209 is concerned all represent items of clothing or agents, as will be explained below; however, other instances in clothing collection 306 may represent models. Of course, more than one set of concepts may apply to a subject or a world and a given set of concepts may be applied to different subjects or worlds.

There are two kinds of instances in world 301 : item instances 303, which represent items, including other models, that may be related to concepts, and agent instances 304, which represent programs that are executed by models in response to the occurrence of events such as the addition of a concept to the model or a request by a user to view items belonging to a given concept. While the program represented by an agent may be any program at all, the program executes in the context of the model and can thus take advantage of the model's facets and propagators. In effect, the operations defined for the model are available to agents in the same fashion that programs belonging to run-time libraries are available to application programs.

The mechanism by which an item instance 303 or an agent instance 304 is related to a concept is an instance facet 309. There is an instance facet 309 for each instance that is related to a given concept. Thus, instance facets relate clothing instances 307(b and c) to concept 121. Of course, an instance may have instance facets connecting it to more than one concept and even to concepts belonging to different models. Generally, the item represented by an instance has another representation, termed an object, in the computer system. What kind of object an instance represents will depend on the application for which the invention is being used. For example, the clothing instances might represent database identifiers of rows describing products in a database table describing a clothing company's products or they might be URLs of WEB pages describing the products.

Propagators may work on instances as well as concepts. For example, a propagator may be defined for the taxonomy model type which retrieves all of the instances associated with a concept and its subclasses. It does so by first following the instance facets for the concept and retrieving all of the concept's instances. Then it follows subclass facet 107 from the concept to its subclasses, their subclasses, and so on down to concepts which have no subclasses. At each concept, the propagator retrieves the instances associated with the concept. Thus, in FIG. 3, when the propagator is applied to concept 115, it will retrieve the clothing instances 307 labeled a,b,c,d in collection 306.

One agent instance is shown in collection 306: the instance for refinement agent 308. Refinement agent 308 is executed when a concept representing a new subclass is added to model 209. For example, in model 209 as shown in FIG. 1, the concept footwear 115 has two subclasses: sandals 121 and insulated boots 123. Instances which belong to neither of those subclasses belong to footwear. One such instance, 307(a), is shown in FIG. 3. The instance represents gardening clogs. Now, the user of the model is planning to sell more kinds of clogs and consequently decides to add the concept clogs as a subclass of footwear. When that is done, instance 307(a) should become an instance of clogs rather than an instance of footwear. This process of moving an instance into the proper subclass concept is termed refinement, and refinement agent instance 308 automatically does refinement whenever a subclass concept is added to model 209.

In FIG. 3, refinement agent instance 308 is shown attached to clothing concept 111 and to footwear concept 115. Clothing concept 111 is the broadest concept in the model and is termed the root concept of the model. Of course, every model of type taxonomy has a root concept. In models of the taxonomy type, an agent attached to a concept propagates along subclass facet 107; thus, any concept which is a subclass inherits the agent. Consequently, each concept in model 209 has its own copy of refinement agent instance 308. In FIG. 3, only the copies for clothing 111 and footwear 115 are shown. Since each concept has its own copy of refinement agent instance 308, execution of the agents can be done in parallel.

When the user adds the new subclass clogs to footwear 115, that event causes refinement agent instance 308(k) to execute. The program follows the subclass facet to the new subclass concept clogs and examines it to determine whether any of the item instances that are related to it are also related to footwear 115. One such item instance, garden clogs, is, and the program rearranges the instance facets 309 so that there is now an instance facet relating clogs to garden clogs, but no longer an instance facet relating footwear to garden clogs. As can be seen from the foregoing, an agent, while user-defined, operates within the context of the environment provided by the model and takes advantages of the operations defined for the model's type.

Representing models, concepts and instances: FIG. 4

FIG. 4 shows at 401 how the representations of model types, models, concepts, and instances are structured in a preferred embodiment. In overview, as shown by the arrows in FIG. 4, each model definition 413 refers to a model type definition for its model type and to a set of node structures. Some of the node structures represent concepts belonging to the model and others represent instances of the concepts. Each concept node 425 refers to its model and each instance node 437 refers to the concepts the node is instances of. There may be many models of a given model type, a given model may have many concepts, a given concept may have many instances and a given instance may be an instance of many concepts. A model type definition may thus be located from any model definition of its type, a model definition may be located from any of its concepts, and a concept may be located from any of its instances.

Continuing in more detail, model type definition 403 includes the model type's name 405, a description 407 of the model type, a facet specifier list 409 that specifies the kinds of facets that models of the type have, and a propagator list 411 that specifies the propagators for models of the type. Model definition 413 includes the model's name and description at 415 and 417, a list 419 of the concept and instance nodes in the model, a facet list 421 showing how the model's nodes are related by each facet of the model, and a model type name 423, which refers back to the model type definition 403 for the model.

Concept node 425 includes the concept's name and description at 427 and 429, a property list 431, which is a list of user-defined properties of the concept, and attribute list 433, which is a list of attributes for the concept. Each attribute specifies the name of a facet to which the concept node belongs and the name of the node which is the next neighbor of the concept node in the facet. The facets, and correspondingly, the attributes may be subdivided into model facets, which specify facets whose vertices are made up only of concepts of the model, and instance facets, which specify facets connecting concepts and instances. What kinds of model facets a model has is determined by its model type; in a preferred embodiment, there are three kinds of instance facets that run from the concept to an instance:

• item facets, which connect a concept to an item instance representing an item that belongs to the concept;

• exhibitor facets, which connect a concept to an item instance representing an item that possesses a property specified by the concept; and • action facets, which connect a concept to an agent instance.

Exhibitor facets are used to deal with concepts like color. A blue clog, for example, exhibits the property of being blue and would therefore be connected to a concept representing the color blue by an exhibitor facet. Owning model 435, finally, refers to model definition 413 for the model the concept belongs to.

Instance node 439, finally, has an instance name 439, an instance description 441, and a property list 443 for the instance. Included in property list 443 is referent 445, which specifies how to locate the object represented by instance node 439. What the referent is depends on what kind of object the instance node represents. For example, if the instance node represents a Web page, the referent will be the page's URL; if it represents an agent, it may be a pathname for the agent's code; if it represents another model, the referent will be the model's name. Attribute list 447, finally, specifies the instance facets that run from the instance to the concepts it belongs to. There is one such facet corresponding to each of the instance facets running from the concept to the instance. Each of these facets is termed the dual of the corresponding facet. Thus, the item of facet is the dual of the item facet; exhibitor of is the dual of the exhibitor facet; and action of is the dual of the action facet.

Applying all of the foregoing to concept 115 of model 209, we see that concept node 425 for that concept has model attributes for the subclass facet for concepts 121 and 123 and for the is a facet for itself and for concept 111, an item instance attribute for clothing instance 307(a), and an action instance attribute for refinement agent instance 308(k). Instance node 437 for clothing instance 307(a) has an item of instance attribute for concept 115 and the instance node for refinement agent instance 308(k) has an action of attribute for concept 115.

In a preferred embodiment, the structures that make up the components of a model are all linked by name, and hash functions and hash tables are used to relate names in the structures to the locations of the structures in memory. For example, to find a concept instance, the preferred embodiment takes the name and presents it to a hash function, which hashes the name to obtain an index of an entry in a hash table and uses the index to find the entry for the name in the hash table; that entry contains a pointer to the location of the concept instance. In other embodiments, other techniques such as pointers might be used to link the components of the structures 401 that represent a model.

A system that uses models to organize information: FIG. 5

FIG. 5 is an overview of a system 501 that uses models to organize information. The system, called Ariadne, has three major components: • server 509 maintains the data structures 401 that implement model types, models, and instances, together with views 513, which provide logical descriptions of models and their parts, but do not specify how the model will appear in a specific GUI. • a number of viewers 507, which present the contents of the views as required for particular graphical user interfaces (GUIs); and • ERIS (external resource interface system) 505, which provides access to the systems

503 that contain the objects represented by instances 407. Server 509 may be implemented on any kind of computer system, and viewers 507 may be monitors, Web browsers, PC's or other systems that have either local or remote access to the computer system upon which server 509 is implemented. As shown in FIG. 5, the outside systems accessed via ERIS 505 may include relational database systems, with the objects being records or queries, Web servers, with the objects being Web pages, email systems, with the objects being email messages, and systems that use XML as their interface to other systems. The viewers 507 and the components of ERIS 505 interact with the model types, models, agents, views, and instances by way of interfaces 51 1 defined using Interface Definition Language (IDL).

An example of how system 501 functions is the following: A user of a viewer 507(i) is interacting with clothing model 209 via a graphical user interface and wishes to see all of the instances of footwear that are currently available in collection 306 of clothing model 209. The user specifies footwear concept 115 and a "display instances" operation. This operation specification arrives via IDL 511 in server 509, and the propagator for the taxonomy model type which retrieves instances retrieves the instances that are related to concepts footwear 115, sandals 121, and insulated boots 103. Ariadne server 509 then typically makes a list of the instances represented by the objects for display in viewer 507(i). If the user of the viewer selects one or more of the instances from the list, Ariadne server 509 provides the referents 445 for the objects represented by the selected instances to ERIS 505, which retrieves the objects referred to by the referents and returns them to Ariadne, which then makes a display using the retrieved objects and sends the display to viewer 507(i). For example, if the clothing instances represent Web pages containing catalog descriptions of the items, when the user of viewer 501 selects an item from the list, Ariadne server 509 will provide the URL for the item's web page to ERIS 505, ERIS 505 will fetch the Web pages, and Ariadne 509 will provide them to viewer 507(i). Ariadne server 509 also provides views 513 which permit a user at viewer 507(i) to define, examine, and modify models. The user interfaces for doing so will be explained in detail later on.

Details of views 513: FIG. 6

Fig. 6 shows details of the implementation of views 513 in a preferred embodiment. Models may have multiple views and views may have multiple presentations. The implementation supports different presentations of the same model concurrently, collaborative modeling and real time knowledge sharing, and independent yet sharable knowledge explorations.

In Ariadne, views are implemented in a subsystem known as Calyx. Calyx 601 is a CORBA server which exports via IDL specifications an abstract interface for views. Calyx 601 could also be any other distributed middleware server (for example, proprietary RPCs or DCE or possibly DCOM). A view 603 is a collection of bins 605 of information about the target source: A model or a world. Bins hold information such as the current objects being shown, whether the attributes of an object along any given facet are expanded, what facet a bin is looking at, etc. The typical representation 601 of a view is a structure containing (among other things) a container of bins 605.

All views and bins (as well as any other externally accessible resource) are referenced by opaque IDs which are presented to any viewer 607 logging into Ariadne. A viewer 607 is a active object through which the abstract information is displayed. Each viewer takes the abstract information maintained by Calyx in a view 601 and presents it in a manner which is consistent with the interface requirements and look and feel of a given GUI. For example, a taxonomy might be represented by a graph, an outline, or simply as an indented list of text and the viewer will use whatever resources are provided by its GUI to make the representation. For example, an outline might be presented by a Java Swing tree widget or an MFC tree widget.

As may be seen from the dashed lines in FIG. 6, a view 601 may be shared by a number of viewers 607. Calyx ensures that all viewers 607 that use a given view 602 l(i) are synchronized to the most recent changes in view 602(i). When a viewer 607(j) requests Calyx to update or otherwise change part of the view (say, expand a node in a bin), Calyx performs this operation for viewer 607(i) and then asynchronously sends the update information to all other viewers actively using the view in question. These requests by Calyx to such viewers are client requests to server portions in those viewers. Hence, Calyx is a client and the viewers must implement a server interface for these asynchronous updates. Calyx also supports (via the model and world infrastructure) various operations on the contents of bins. Specifically, various set operations (union, set difference, intersection, etc.) may be applied to arbitrary sets of bins. Additional operations may be defined by the user. The effect of the set operations is to apply the operation on the sets of information represented in the bin to produce a new bin (called a composition bin) with the computed resulting information. This is then propagated to all connected viewers. Further, bins may be combined in this way to create constraint networks of composition bins. If any bin in the network is changed (manually or via automated updates) the effect is propagated throughout the entire affected subnetwork in which the bin is connected. These propagated results are sent to all viewiers via the asynchronous operations described above.

Separation of levels of information in the implementation: FIGs. 3-6

An important characteristic of Ariadne is the manner in which complexity is reduced and flexibility increased by separating various levels of information from each other. One of these is the separation of model types from models, as seen in the separation of model type definition 403 from model definition 413 in FIG. 4. Another is the separation of models from instances, as seen in FIGs. 3 and 4; this permits multiple models to be built independently of each other and yet work over the same world. It also permits models to be reused in different worlds. Yet another is the separation of an instance from the object that it represents, so that the instance serves as a j-.ro y for the object, as seen in with regard to referent property 445 in

FIG. 4 and the use of ERIS interface 505 to retrieve objects represented by referents from a number of different information sources 503. Then there is the agent/model separation: agents run in the context of models, but they are defined in terms of model types, not the individual models. For example, the refine agent will work with any model that has the taxonomy type.

Finally, as seen in FIGs. 5 and 6, views 601 are separated from models and worlds and viewers

607 are separated from views 601.

The user interface for building, modifying, and displaying models: FIGs. 7-12 A particular advantage of model types is that they greatly simplify the construction and modification of models. They do so because the part of Ariadne which constructs models can use the information in the model type to automatically place concepts in the proper facets and in the proper locations in those facets and to propagate information provided by the user to the concepts that require it. One example of such propagation is the propagation of the refinement agent from the root of a model of the taxonomy type via the subclass facet to all of the concepts in the model.

FIG. 7 shows the dialog box 701 used in a preferred embodiment to create a new model. At 703 there appears a list of the presently-available model types; the user has selected simple taxonomy, indicating that the new model is to have the simple taxonomy model type; in the name box, the user has input "usr: Clothing", indicating that that is to be the name of the new model; at 709, the user may input the description. The result of these inputs is of course the construction of a model definition 413 for the new model, with model name 415 being "usr: Clothing" and model type name 423 being "Simple Taxonomy". List 705 gives an example of what can be done with models. In Ariadne, models themselves are instances in a model whose concepts are model types; one can thus simply select an already-made model from that model. In instance node 437 for an instance representing a model, referent 445 simply specifies the location of the model's model definition 413. The action model similarly treats agents as instances of a model whose concepts are the model types the agents are written for.

FIG. 8 shows the dialog box 801 used to add a root concept to the subclasses facet of the new model "Clothing". At 803 would normally appear the concepts that are presently in the model; the field is empty, as the model as yet has no concepts. At 805, the user writes the name of the root concept, and as before, the user may also add a description. The result of these inputs is the creation of a concept node 425 with the name "Clothing" in field 427 and the model name "usr: Clothing" in field 435. Since " Clothing" is a root concept and there are no other nodes, the taxonomy type requires that there be as yet no subclass attributes in attribute list 433, but a single is a attribute for "Clothing" itself, and Ariadne automatically adds these to "Clothing'"s concept node 425. FIG. 9 shows the dialog box 901 used to add subclasses to an existing taxonomy model. Here, the model already has as subclasses of the root concept clothing the concepts accessories, apparel, swimmwear, and footwear, and further subclasses are being added to to the apparel subclass. At 903, the name apparel of the concept to which subclasses is being added appears; at 904, names of aready existing concepts appear; since only the first level of concepts have as yet been defined, the names are those of concepts at the same level as apparel; at 905, finally, is a field for adding a newly-made concept.

A user may add a subclass either by selecting from among concepts listed in 904 or by using field 905 to add a newly-made subclass. For each newly-made subclass concept that is added, Ariadne creates a concept node 425 with the name of the concept at 427 and the name of the model at 435; for each concept being added as a subclass, Ariadne adds attributes in attribute list 433 for the is a facet specifying the new concept node itself and the concept node for the apparel concept. Ariadne further creates an attribute in attribute list 433 in the concept node for the apparel concept for the subclass facet which specifies the new concept node. Thus, when all of the subclasses have been added, they all belong to the subclass and is a facets in the manner required for the taxonomy model type. It should be pointed out here that if the user attempts to select one of the concepts listed in 904 to be added to apparel, Ariadne will determine from the model type that this is not possible in the taxonomy model type (in a taxonomy, a concept at one level of the taxonomy may not be a subclass of another concept at the same level) and will not add the concept but will indicate an error. In other embodiments, Ariadne may simply not display concepts that cannot be added to the concept selected at 903.

FIG. 10 shows dialog box 1001 used to relate instances to a concept. Dialog box 1001 has the same form as dialog box 901, with area 903 containing the name of the concept to which the instances are being related, area 905 containing the names of instances that are available to be added to the concept, and field 1007, which can be used to add a newly-made instance. When a newly-made instance is added, an instance node 437 is created for the instance, with the instance's name at 439 and any description provided by the user at 441. For a newly-made or prevously-existing instance, an attribute for the item of facet that indicates the concept sweaters is added to the instance node's attribute list 447, and one for the item facet that indicates the instance is added to the concept node's attribute list 433. Similar dialog boxes are used to add agents and items that are exhibitors, with corresponding modifications in the attribute lists of the concept and instance nodes. Ariadne also has a copying interface that can be used to select instances belonging to a concept in one one model to become instances of a concept in another. The attribute lists 433 off the instance nodes for the copied instances are modified to add attributes for the instance of facet specifying the concept, and the other concept's attribute list 433 is modified to include attributes for the instance facet for the newly added instances.

FIG. 11 shows how referent fields 445 are set in instance nodes 437. Window 111 has three sub windows: two show models that apply to the clothing world: "clothing categories" and "fabrics". Both models belong to the taxonomy type, and thus both can be displayed as outlines, as shown at 1103. The user wishes to add referents, in this case the URLs of Web pages that show the items represented by the instances, to the instances that belong to the concept "apparel". In terms of facets, that is all of the instances which have an is a relationship to "apparel", that is, the instances that are related to "apparel" and all of its subclasses. To perform this operation the user selects "apparel" in outline 1103; Ariadne then uses a propagator for the taxonomy model type to generate the list seen at 1107, which is the list of all of the instances that belong to "apparel" and its subclasses. To assign an URL to an instance, the user writes the URL opposite the instance in field 1109. The URL for a given instance goes into referent 445 in node 437 for the instance.

FIG. 12 shows how Ariadne displays a model. Model 1201 is a taxonomy of the events handled by Ariadne. The boxes are the model's concepts and the arcs 1203 are the arcs of one of the facets, in this case, the is a facet. Selection of facets to be viewed is controlled by check box 1205; as seen there, model 1201 is to be displayed showing its concepts and its is a facets. More than one facet may be selected, in which case, the arcs for each selected facet are displayed simultaneously.

Architecture of model types Facets and Facet Specifiers

As could be seen from the taxonomy models explored in the foregoing, all models of a given type have the same kinds of facets. To define a model type, therefore, one defines its facets. Each facet of a model is defined by its corresponding facet specifier. All the facets available to a model are determined by the set of facet specifiers given in the model's corresponding model type definition (see below).

Each facet specifier defines the set theoretic relational properties of the base relation captured by the facet and provides an interpretation of what the relation is intended to convey. This interpretation provides the meaning of the facet through semantic constraints on what concepts may be related by the facet and how the facet is mapped to facet descriptions in other model types. Hence, the set of facet specifiers defines the complete semantics of the model type at any given concept in an instance of that model type.

Def: Facet-specifier. A facet specifier F is defined by a tuple: F = (N, l)

where

-V = the name of the facet and 1= the interpretation of the facet

We will often refer to a facet specifier as simply a facet and let context ensure the sense of use. A facet name is a simple string (actually an interned symbol).

Def: Facet Interpretation. A facet interpretation I is defined by a tuple:

I = {R, P)

where • R - The specification of the relation semantics governing the facet

• P = Designates a propagator for the facet. P may be null.

While a propagator may be null an interpretation can never be null, since a relation specifier can never be null as it must at least provide the basic set theoretic properties of the relation. Def Relation Specifier. A relation specifier R is a tuple which describes the relation of the facet in terms of its set theoretic character and the local semantic constraints imposed on concepts connected to each other through the facet.

R = {C, SC

where

• C = the set theoretic character of R. This is a list selected from the following set of properties (note that other properties can be deduced from this, such as equivalence relation, partial order, etc.):

• reflexive, xRx

• nonreflexive

• symmetric, xRy=>yRx

• nonsymmetric

• transitive, xRy and yRz => xRz

• nontransitive

• trichotomy, for any z and y, exactly one of x=y, xRy, yRx holds

• nontrichotomy

• SC = the semantic constraints of R governing the structure of the graph represented by the facet. These are given by a semantic constraint specifier. Def: A semantic constraint specifier: A semantic constraint specifier for a relation R of a facet F in a model type MT is a set of sentences r which determines when two concepts in a model M of type MT can be connected along F and how that relationship is mapped relative to possibly connected models of other model types and to instances in the world. That is, -^supply necessary conditions on R (and thus F): c_/Rc =>r, -T can be null and we adopt the convention that anything implies the null set: c/Rc₂ =>0fo all possible cj, c_2> and R. Each sentence φ e F is a statement with free variables over the concepts in the model M, possibly free variables over the concepts in a related model FM of some model type FMT, and possibly free variables over the instances in the world. These variables are implicitly bound to the specific values of their corresponding sets provided by the context of each specific constraint action. In addition any global predicates and operators defined for all model types can be used as can R and any R_FM associated with the related FMT. There may be several such related model types involved in a semantic constraint. Such related models and their model types are often referred to as "feature models" and "feature model types" and the concepts in them as "features", though this terminology is a bit misleading (they do not have to be related via a "feature" facet - any facet may have such relationships, but for historical reasons we often use this terminology).

Both universal and existential quantification are available for binding variables ranging over explicitly specified sets. Quantifiers can be mixed and nested to any level. Deeper sentences may refer to the quantifier variables of outer sentences with the expectation that any binding is properly maintained.

Additionally a constraint may assert a condition to hold provided another condition holds. This supports actions which must be atomic with respect to the overall constraint. For example, if a concept Ci is added to the concept C in the subclasses facet of a model with a taxonomic model type having facets subclasses and superclasses, then the constraint for the facet can assert the dual relationship: C₂ added to Ci in the superclasses facet.

Language for semantic constraints

Letting M be a model of model type MT and FM be a model of model type FMT and F be a facet defined in MT, then the following lexical elements are available for use in semantic constraint specifiers:

• Cj, i = 1, ..., k, ... = the set of natural numbers. The free variables available for concepts in M

• f_jj = 1, ..., k, ... = the set of natural numbers. The free variables available for concepts in FM • x, y_}, i and j = 1, ..., k,... = the set of natural numbers. The free variables available for instances.

• R - the relation of facet F to which the semantic constraint belongs

• simple-name, the name of a facet of the model type MT • (simple-name simple-name), the designator for a facet in model type FMT, where the first name is that of FMT and the second is the name of the facet.

• The following set of quantifiers (listed with their semantic interpretation): for-every, universal quantification: for-every var set forms, where var is a free variable in the sentences of forms and set is the universe set for this quantifier instance. Forms is a set of sentences which may contain var, and if so it must be a free variable. Yields true if all sentences informs are true for every binding of var from set. there-exists, existential quantification: there-exists var set forms, where var is a free variable in the sentences of forms and set is the universe set for this quantifier instance. Forms is a set of sentences which may contain var, and if so it must be a free variable. Yields true if there is at least one binding of var from set which makes all sentences in forms true.

The following set of connectors (listed with their semantic interpretation):

• =>, logical implication not, logical negation • and, logical conjunction or, logical disjunction

• <, numerical less than

• >, numerical greater than

• =, equality (across all types) • (, start enclosing s-expr

• ), close enclosing s-expr

• The names of all predefined operators on models of all types. This set is subject to continual change, but has at least the following (listed with their semantic interpretation): card, cardinality • inst, instances of attr, binary operator, takes a concept and attribute name and returns attribute value prop, binary operator, takes a node (concept or instance) and property name and returns the value of the property. Note this includes the standard property of referent. A referent is the connection information for a resource (file, url, model, spreadsheet, accounting system, etc.) in, set membership intersect, set membership intersection union, set membership union set-diff, set membership difference • subset, set inclusion deg, takes a concept and facet name and returns the degree of a concept (vertex) in a facet graph

The syntax for sentences is standard s-expression forms, where any quantifier, operator, relation, and connector may define a clause. Additionally, since all of _T are implied by a constraint, -T can be represented as a single conjunctive expression (there is no need for an explicit set of sentences).

Ex-1 Constraint: Suppose MT is a model type with a facet specifier F containing the following constraint:

(=> (R cl c2) (or ( (> (card (attr c2 features) )

(card (attr c2 features) ) (there-exists fl (attr nl features) (there-exists f2 (attr n2 features) (FM Rfm) fl f2) )) ))

Then for any two concepts c and c₂ of a model M of type MT if cιRc₂ then either there is a related model of type E with facet (and relation) R/_m for which there are features// and/2, in the features of c and c₂ respectively, for which fiR/nf_? in the related model or the cardinality of the feature set of c₂ is larger than the cardinality of the feature set of c/ The second disjunct of the or-ciause in this example illustrates a particularly interesting constraint between models of two model types. It induces a homomorphism between two such models with respect to the graphs of the two facets involved. Hence, this sort of constraint ensures that sets of models are constructed to ensure such homomorphisms and this can be relied upon by agents or other processing of the models involved. One obvious use of this is the standard technique of exploring and investigating questions concerning one structure by looking at one or more of its homomorphic images. In such a technique, the issues would typically already have been resolved for the images or the images would be significantly simpler to explore. This can be particularly useful in agent autoclassifying and configuration scenarios.

Ex-2, Facet Specifier. If MT is a model type for a simple graph without edge constraints (a so called '"weak" semantic model type) then the following simple facet specifier could capture the edge set of models of type MT:

(adjacent - vertices, ((symmetric), nil), nilj)

The facet's name is adjacent-vertices, its interpretation specifies no propagators and inside the relation specifier of the interpretation, no semantic constraints are given and the relation's properties are the singleton symmetric (standard character for simple graphs).

Ex-3, Facet Specifier: If MT is a simple taxonomic model type then the following facet specifiers could capture simple notions of subclasses and features (given in s-expr clause form):

(subclasses

( ( (transitive nonreflexive nonsymmetric)

(> (card (attr ?c2 features)) (card (attr ?c2 features)))) nil))

(features

( ( (nontransitive nonreflexive nonsymmetric) nil) inherit -features) ) The facets are subclasses and features. The subclasses facet has a simple constraint requiring the addition of some new feature(s) for a subclass to be legal and a null propagator. The features facet has a null constraint but designates a propagator.

The purpose of the propagator on features is to ensure that features of concepts of models of type MT obey the expected standard class based inheritance behavior for concept features (or characteristics).

Propagators and Propagation Specifiers

As noted earlier, a propagator provides a degree of expected behavior for all models of the model type containing the propagator's specification. Propagation specifiers define what and how values of attributes of models are moved, i.e., propagated, between concepts - both within the model and between concepts in related models.

Def: Propagation Specifier. A propagation specifier PS is a tuple which describes an expected intrinsic piece of behavior for information movement between selected attributes along a path in a given facet graph for any model whose model type contains the specifier.

PS = {N, A„ A_J , D, 0,W, F)

where

N = the name of the propagator (a simple-name)

A, = the attribute in the model type whose value is to be propagated, the from attribute

A_j = the attribute in the model type to which the value is to be propagated, the to attribute

D = the direction of propagation as given by:

>, A,→A_j <, A_j→A,

O = the form :on <condition>, where condition is one of

access, propagate when the from attribute of a concept is accessed • update, propagate when the from attribute of a concept is updated

• change, propagate when the from attribute of a concept is changed (not just updated, but changed)

• W= the form :when s-expression. propagate only when expression is true F = the form :along <facet>, where facet denotes a facet that exists in the model type.

While A, and A_} may be different attributes, the most typical case is where they are the same attribute. The along facet E controls whether propagation is one step or continues until all concepts along the facet from the starting concept have been visited. If the relation of F is transitive, then propagation continues for all concepts in the potential path, otherwise propagation stops after the first step.

In many cases, the global propagation semantics provided by propagation specifiers may need to be supplemented with context specific aspects. This is accommodated by providing two predefined properties for concepts in models of any type. These are,

• pre-propagation-actions: A set of ordered pairs of names and functions:

{ (N, /) I N names PS and/an operator for the space of A, of PS}

post-propagation-actions: A set of ordered pairs of names and functions:

{ (N, /} j N names PS and/an operator for the space of A_j of PS}

On a propagation event, if the propagator involved has a prepropagation action, then the corresponding function is called on the value of the from attribute before propagation; if the propagator has a postpropagation action, then the corresponding function is called on the updated value of the to attribute.

Ex-4: Suppose MT is a typical taxonomic model type including the facets superclasses and features, with the facet interpretation for features designating the following propagation specifier (also included in M s definition): We also presume the typical case that the relation of superclasses is transitive.

(inherit-features features features > :on access : along superclasses)

Then any access designating features on a concept c in a model of type MT will obtain all the features directly attributed to c and any features in any superclass of c, i.e., the result is standard class based inheritance. Ex-5, Propagation Specifier: Suppose MT is as above in example 1. All model types have the predefined attribute instances (and a simple predefined facet specifier for this) and so MT has this. Assume the typical further condition that MT includes a facet specifier subclasses whose relation is also transitive and that instances' interpretation designates the following propagation specifier (also included in MT):

(instances-of instances instances > :on access :along subclasses)

Then any access designating instances on a concept c in a model of type MT will obtain all the instances directly connected to c and any instances of any subclass of c, i.e., the result is standard class based instance set covering.

Ex-6, Propagation Specifier: Suppose MT is some example of a causal network model type. Let MT have facets causes, effects, and happened and assume that the facet interpretation of happened designates the following propagation specifier which is also defined in MT:

(happened happened happened >

: on change -.when (> 0) -.along effects)

If effects are transitive (each effect is a cause for something else), then any change to happened at a concept c in a model of type MT, where the value is greater than zero, will "fire" all the causes along the causal chains connected to c whose values are not the same as the value supplied.

Model Type Definition We are now in a position to give the definition of a model type. A model type definition requires the following basic set of information:

• A set of attributes for its models. This includes both predefined attributes for all model types and those specific to the requirements of the style of modeling being captured in the model type. A set of facets defined over the attributes for specifying the semantics of how concepts in its models may be connected in order to capture the intended semantics of the facet graphs in the style modeling being captured

• A set of propagators that provide the expected base behavior in its models for the style of modeling captured by the model type.

• In order to satisfy any intermodel connection constraints in the semantics of the facets, there need to exist the set of model types referenced in the constraints along with any of their facets that are designated.

The last point can be made implicit. Any currently extent model types are available for use in semantic constraint specifications of facet specifiers of the model type. We assume this scenario.

Def: Model Type: A model type T is defined by a tuple of sets which collectively describe the complete semantics of the model type:

where

• Ai = The attributes that are specific to the requirements of the modeling style being captured. These are simply a list of simple names. The following may be (this is an implementation 's choice) predefined attributes which are always included (whether explicitly specified or not): • Instances, ties concepts to the world as examples of the concepts

Exhibitors, ties concdpts to the world as characters of the concepts

• P_j = The propagation specifiers that capture the intrinsic behavior expected of the style of modeling being captured by the model type.

• F_k - The facet specifiers that tie together the attributes and propagators along with the relational character and semantic constraints for the set of graphs required to support the modeling style.

The P_j and F_k are, specified per the definitions and descriptions covered in the relevant sections given earlier. This completes the definition of model type and this definition allows the description of the various styles of models mentioned earlier. We give some examples here to illustrate the technique for capturing a style with the machinery. All the examples are given in s-expression clausal form.

Ex-7, Model Type: ne of the simplest model types possible is that of the basic simple graph from graph theory. The following model type definition provides this most basic structure:

(simple-graph nil ; ; Specific attributes nil ; ,- Propagator is null => no expected behavior

; ; Now the facet specifier set

( (adjacent-vertices " concepts" here are simply vertices ( ( (symmetric) nil Simple graph def has symmetric relation & no constraints nil) ) ) ; And no propagators...

While not explicitly specified, there are also attributes and facets for instances and exhibitors (as required by the definition of model type). Note that there is also no need to specify attributes which have explicit facet specifiers, as these imply the corresponding attributes.

Ex-8, Model Type: A somewhat more interesting example is that of a very simple taxonomy. This style of model is the one where there are no "features" and subclassing proceeds essentially by fiat.

(simple-taxonomy nil ; ; No attributes without explicit facet specifiers

; ,- Propagators

( (instances-of instances instances > -.on access :along subclasses))

; ; Now the facets

,ιs-a

[ transitive ref lexive nonsymmetric ) nil ) nil ! (subclasses

( (transitive nonreflexive nonsymmetric) nil) nil) (instances

( (nontransitive nonreflexive nonsymmetric) nil) instances-of) ) )

Note that if we had decided to use a "superclasses" facet instead (or perhaps in addition to) the is-a facet the relational character would be slightly different: it would specify nonreflexive: a rose is a rose is a rose, but a rose is not a superclass of itself. As pointed out in the example introduction, there are no semantic constraints on any of the facets so what is or isn't a legal subclass or instance is left completely up to the modeler when building a specific instance of simple-taxonomy.

Lastly note the propagator. It is the same as that given in Ex-5 and it is designated by facet instances. This means that whenever the facet instances is accessed at a concept c, the propagator instances-of will run in order to obtain the correct value for instances at c. When the propagator runs it will first get the instances directly attached to c, then it will move along the subclasses facet to all the immediate subclasses of c and get the instances of each of these. Since subclasses' s relation is defined to be transitive, the propagator will then recurse.

We could augment simple-taxonomy a little to get automatic "what am I" kind of semantics (the standard "is-a" game). We would do this by adding a propagator:

(i-am-a is-a is-a > : on access :along is-a)

and designating it as the propagator for the is-a facet:

( (is-a ( ( (transitive reflexive nonsymmetric) nil) i-am-a)

Since is-a is transitive, on access to the is-a facet of a concept c, the result will be c and all concepts along the entire chains of is-a rooted at c.

Global structural semantics

It is worth noting that our definition of model type is silent concerning certain global semantic properties of possible models of the types that may be constructed. It is, however, not always silent as there are cases where it may be deduced that a given model type provides sufficient conditions for that property and thus all models of the type will have the property. However, this is the unusual case. The canonical example is that of all model to world (and vice-versa) facets which are bipartite. A more specific example comes from our definition of simple- taxonomy, which states that subclasses is transitive and nonreflexive and thus we know that (the graph of) subclasses is acyclic.

Typically, however, the above machinery is silent for individual models with regard to the following important global properties of facets:

• Whether a facet is acyclic Whether a facet is connected Whether a facet is eulerian Whether a facet is hamiltonian Whether a facet is bipartite • Whether a facet is planar

Whether the graph resulting from the combination of two or more facet graphs has any of the above properties. In large measure, these issues must be answered by looking at the particular graphs in question and running an analysis on them. In many cases such analyses will be unable to answer the question. This can be due to the fact that the graph does not exhibit known necessary or sufficient conditions for the property in question or that the required computational complexity to determine such conditions exceeds "allowable limits". In any event, various intrinsic predicates and path finders are provided for such analyses for all model types Notice that this is possible since the scope of the styles of models captured by model types is constrained by the requirement that they are all a graph in their most fundamental character.

Intrinsics for Model walks

The set of supplied intrinsic model walkers and predicates should behave in a functional manner. This is not an issue with respect to predicates as they simply take a model and proceed to (attempt to) determine whether the graph in question is of the sort specified by the predicate. There are two possible sorts of output from such predicates:

• Often, the determination of a property will involve finding a particular kind of path through the graph. In this case, it makes the most sense to return as the value the actual path found: the ordered list of nodes defining the path. Note, we allow for the case where both instances and concepts may be mixed in such a path.

Certain other properties should simply return nil or t.

The available intrinsics The set of model intrinsics is subject to continual update, but includes at least the following set of capabilities:

Transitive closure walks: generalized facet "applier"

• Model traversals and search forms. These may be invoked with various predicate or predicate sets to determin when to termininate and whether and what to collect and return:

• Along a facet

• Along a sequence of facets Randomly (nondeterminancy)

• If tree

• depth first with pre-, in-, and post-order application • breadth first with pre-, in-, and post-order application

• Search depth first breadth first

• best first • beam search hill climbing A* search

Special graph predicates

• Eurlerian • Hamiltonian

• Bipartite Connected

Details of agents and events: FIGs. 13-17 Agents and Events

Ariadne agents reflect the typical set of required properties for agents such as autonomy, mobility, reactiveness (sometimes called "responsive"), proactiveness, and social ability. These all have explicit constructs in the agent language to allow for direct and simple descriptions involving such characters. However, constructs for such more controversial agent aspects as the "Belief, Desire, and Intent" (BDI) model have been deemed too vague and problematic. In addition these latter are more concerned with large scale agents with internalized "symbolic models" of their world. Ariadne explicitly parts company with such traditional Al techniques.

Agents are specified by means of constructs arising out of a family of interrelated languages that all "play together". Model types in Ariadne provide various specialized "formats" to organize and structure information. As such, agent descriptions for moving within and among the models built upon these should have access to the more specific and higher level semantics that the model types present. Additionally models in an Ariadne application present semantic interpretations (perspectives) of the various subjects on which the application is focused. Collections of such interrelated models provide the contextual, or "domain level" semantics of the application. Again, descriptions of agents for processing these structures should have constructs which more directly reflect this level of semantic for the subject.

Hence users should have access to corresponding families of agent (mini) languages. In order to satisfy these highly desirable qualities and keep the results consistent and manageable, these "mini" languages are in turn part of a family of extensible languages layered on top of a more general base language. The base language has a fuller but "lower level semantic" capacity for agent descriptions and at any point a (power) user can dip down into it from a higher level child language to access this capacity.

Such layered languages creating families of inter-related languages can be built by various means, but the most straightforward method would be to define a very simple consistent syntax with a macro style compile time constructor. All new constructions are defined by means of this constructor and each construction itself becomes a new construct in a language layer.

Hence, the constructor always has access to all previous constructions when defining a new construct. At compile time of a set of constructions for an agent's definition, each construct is first expanded according to its definition into the lower level constructs upon which it is based.

The process recurses. The recursion stops when the base level constructs are all that is left. The resulting base level version of the original code is then compiled into machine code. The design and implementation of such an extensible base language for agent descriptions needs to take into account these notable points:

• Ariadne agents are largely reactive in nature, in the sense that they do not have internalized semantic structures reflecting a model or their external environment. • Nevertheless, agents will have access to and will directly utilize the conceptual information of many models to synthesize their results.

• Despite their largely reactive nature, Ariadne agents have various degrees of proactive behavior. This allows users to create agents with a goal(s) which can run periodically in the background over a set of models.

• Ariadne agents are independent - they each have their own thread of execution. Hence, the base language will account for such parallelization.

• Agents can be highly communicative (requesting services and replying to such requests). The base language provides an event based messaging service for the expression of all such communication. Agent construction and definition takes place within the context of the overall Ariadne system and makes use of three basic models:

• An event model for Ariadne. Event model 1301, shown in FIG. 13, includes events received from the core level infrastructure, agent actions, Star interface, Calyx interface, any conforming GUI, and ERIS brokered external resources.

• An actions model, shown at 1401 in FIG. 14. This model includes the various sorts of active processes that can be invoked via events. One of the subclasses of this model is agent 1405; among the instances of this concept is the refine agent discussed earlier; the instance is at 1407.

• An operations model 1501 (FIG. 15) for describing the various parameter lists of actions and in particular the signatures of agents.

In addition, as we have seen, all models that have agents have the standard actions facet that relates agents to concepts. All of these standard models are user extensible and manipulatable like any other model. The ability of users to access and change the models provides a very high degree of flexibility to users in changing and contexualizing the processing model of Ariadne to their specific needs.

Details of event model 1301 Continuing in more detail with event model 1301, that model is used to indicate the event classes with which an agent may be registered. If an agent has been registered with an event class, the agent will be invoked and run whenever an event of the class occurs in a context where the agent is available. Each agent invocation creates an activation copy of the agent which runs as a separate thread. There can be any number of agents (modulo system resources) ranning at any given time. The event class for an agent indicates what sorts of events that the agent should respond to when it is configured for use. An agent is available in a given context if either:

1. It has been connected along the actions facet of a given concept (FIG. 16) or

2. It is in the extent of some concept "A" connected along the subclasses facet to the "Agent" concept in the actions model and further that there is an instance I connected to "A" in the caller's facet (FIG. 14) or

3. It is manually selected and dropped onto a set of objects. This last option manually invokes an agent on a model. (FIG. 17)

Continuing in more detail with the above three options, FIG. 16 shows a fabric model 1601 which belongs to the taxonomy class. The actions facet of model 1601 has two agents attached to the root concept fabric, as shown at 1605. The two agents respond to the events of adding a concept to the model and adding an instance to the model. Since they are attached to the root of model 1601 and by the rules of the taxonomy class are inherited by all of the concepts of the model, one or the other of the agents runs whenever a concept is added to the model and whenever an instance is added to the model.

The predefined actions facet has several constraints on it which prevent various possible misconfigurations. Again all of this setup, configuration and enforcement is done via standard

Ariadne model and model type definitions and manipulations. The actions facet (like any other) may also have a variety of propagation behaviors for any given model type. For example, in a typical taxonomy it may well be the case that the Actions facet will be inherited down the subclasses facet, as described above for the agents 1605. This basically gives all the capabilities of standard object oriented method inheritance, but is far more flexible and is also end user configurable. Many other scenarios are possible.

FIG. 17 shows how the user interface permits a user to manually invoke an agent. In interface 1701, the instances representing the agents are listed at 1705. The user has selected one of them, named FIND-BLANKS. When invoked with two taxonomy models, this agent finds concepts of the one model that have no instances which belong to a given concept of the other model. The instances representing the models are listed at 1703; the user has selected two models, gender and clothing. Ariadne will respond to this input by invoking the selected agent on the two models. The effect of invoking the agent is the following: for any combination of a clothing and a gender concept for which there are no instances, Ariadne will dislpay both the clothing concept and the gender concept.

In addition to the models, there is a subsystem for event handling which fully supports asynchronous event processing, including posting, dispatching and handler threads for each top level event class (concept in the events model). Part of this subsystem is an event activation layer for the core level capabilities. This layer supports various core level actions (adding and deleting objects, adding and deleting neighbors along facets, agent invocation, etc.) with transparent posting of associated events. Each event consists of the event's event class in event model 1301, a universal identifier for the particular event, and an argument list. The latter, together with the event class, serve as a "signature" to determine what code is executed for the event. A component which generates the event posts it to a main event queue. Each of the GUI, Agent, Core, and IR classes of events has its own event queue and a main event dispatcher reads the events in the main queue and places each event in the proper queue for its class. The queues are read by an event dispatcher for each class. Each of the class event dispatchers runs in its own thread and dispatches each event in turn as it reads it from the class queue. The event dispatcher for the core class further runs in its own separate task. This split between the core event dispatcher and the other class event dispatchers supports clustering of event actions and increases flexibility and performance of core actions. An extensive palette of out-of-the-box agent "prototypes" is provided for intermediate level users - those not expected to write agent level code. These prototypes can be completed by configuring various properties and registering them with a set of events. Both of these actions are performed by the standard model manipulation capabilities of Ariadne and the GUI: most typically selection, bin element addition, and copy a set of objects and paste along a facet of other objects. This will result in an agent definition instance (in the world) which can then be attached (along the actions facet) to any concept in any model of a model type, where the type is one that is included in the agent's model type list.

Typically the actions facet for a model type will have a propagator (though none of these are implicitly provided - the model type defmer must decide to make one for the specific case). For example FIG.16 shows a fabric model 1601 used in an Ecatalog application dealing with clothing. The model 1601 belongs to the model type Simple Taxonomy which is a kind of taxonomy. It has facets is-a (not displayed), subclasses 1611, actions 1607, and a propagator for facet actions :

(inherit-actions actions actions > : on access : along is-a)

(actions ( ( (nontransitive nonreflexive nonsymmetric) nil) inherit-actions) ) ; Actions are inherited from parents

This propagator causes actions to be inherited by subclass concepts from their parents (in the direct analogue to OO class based inheritance of "methods"). For example, agent refine- content-on-clas-add 1605 is connected in facet actions 1607 to root concept Fabric 1613 and thus it will be available to all concepts throughout the underlying tree. This would be equally true if it were attached to any concept C in the subclasses facet: 1605 would be available to the subclasses under C.

Continuing further, let agent 1605 be registered with the event class "Neighbor addition" 1207 of FIG.12. This indicates that the events that 1605 should watch for in any model where it is attached along the actions facet, are those where some concept (or instance) is being added to one of the existing concepts in the model. For example, if the new concept Chamois is added to the Cotton concept 1609 along subclasses facet 1611, this will generate a "Neighbor addition" event. Agent 1605 would then become active (in its own thread) and perform its actions based on the context of the event: the model where the event happened (model 1601), the concept being added to (Cotton concept 1609), the neighbors being added (new concept Chamois), and the facet involved (subclasses facet 1611).

Agent 1605 would then reclassify any chamois fabric instances attached to the originating concept (Cotton concept 1609) down into the more specific new Chamois concept. Note how this uses the context specific information of working with only the instances that are known to be only cotton (not some other existing specialization of cotton or all instances in the world).

As an example of an agents code we present here the definition for agent 1605:

(defagent refine-content-on-class-add ( (owner node facet neighbors) " eighbor addition¹'

"Simple Taxonomy' ' )

(when (is= facet (the-facet "Subclasses"))

(with ( (new-concept (element 0 :of neighbors) )

(insts (all x : in (the-direct-instances-of node) : suchthat

(matches new-concept (the-description-of x)))))

(the-name-of x) : case- fold t ) (move insts : f rom node : to new-concept ) ) )

Conclusion

The foregoing Detailed Discussion has disclosed to those skilled in the relevant technologies how to make and use a system wherein models belonging to model types are used to deal with entities according to different aspects, and has further disclosed the best mode presently known to the inventor of practicing the invention. It should be pointed out at this point, however, that embodiments using the principles of the invention can be implemented in ways other than those disclosed herein and that those embodiments may be employed in ways other than those disclosed herein. For example, in the preferred embodiment, the models apply to concepts, which in turn have instances. In other embodiments, the models may be applied directly to instances. Further, the invention is by its very nature extensible, so that other embodiments may employ model types and models different from anything disclosed herein. Moreover, the manner in which models, model types, and instances are represented may vary in other embodiments without departing from the principles of the present invention. Further, the invention may be used in systems different from the Ariadne system disclosed herein.

For all of the foregoing reasons, the Detailed Description is to be regarded as being in all respects exemplary and not restrictive, and the breadth of the invention disclosed here in is to be determined not from the Detailed Description, but rather from the claims as interpreted with the full breadth permitted by the patent laws.

Claims

What is claimed is:

1. A system for dealing with entities according to a plurality of aspects, the system comprising: at least one representation of a model type, the model type defining a set of facet types and a set of operations; at least one representation of a model, the model representation being separate from the model type representation, the model having the model type defined by one of the model type representations, and the model representation including representations of one or more of the entities, the entity representations being connected by facets of the types defined for the model's model type; and a processor for performing operations belonging to the set thereof defined for the model's model type on the representation of the model.

2. The system set forth in claim 1 wherein the system further comprises: one or more instances, each instance representing an object accessible to the processor; and one or more instance facets, each instance facet relating an instance to an entity representation; and the operations belonging to the set thereof defined for the model's model type include an operation that involves the instance.

3. The system set forth in claim 2 wherein: at least one of the instances represents a definition of an operation to be performed on the model.

4. The system set forth in any one of claims 1 through 3 wherein: the entities are concepts.

5. The system set forth in claim 4 wherein: at least one of the instances represents an item that is related to the concept.