Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20020184401
Kind Code
A1
Kadel, Richard William JR. ; et al.
December 5, 2002
Extensible information system
Abstract
A framework enables data source components to be developed independently of data consumer components. A mediation layer, typically implemented as a group of APIs (application programming interface), handles and defines the mediation and interface between the source and data components. The framework, called XIS (extensible information system), is especially suited for development of information-handling systems and applications. Data source components and data consumer components are typically designed to communicate with each other via several interfaces. Domain, relationship, attribute/metadata, and change event interfaces are defined within the mediation layer. Other interfaces may also be defined. Data source components that are written for non-XIS aware environments or frameworks may still be used with XIS by "wrapping" such source components with code to conform to the interface requirements. Java objects are examples of data source components. Data consumer components thus are able to use or consume various source components regardless of the data types and the data source. Thus, once a data consumer component is developed within the XIS framework, any data source components within the XIS framework may be consumed by a data consumer component.
Inventors:
Kadel; Richard William JR.
(San Diego, CA)
, Herman; Jeffrey Stephan
(San Diego, CA
)
, Exline; Christopher Lee
(San Diego, CA
)
, Almilli; David Edward
(La Mesa, CA
)
, Priebe; Christopher C.
(San Diego, CA
)
Correspondence Name and Address:
Heller Ehrman White & McAuliffe LLP 6th Floor 4350 La Jolla Village Drive
David A. Hall
San Diego
CA
92122-1246
US
Series Code:
039306
Filed:
October 22, 2001
U.S. Current Class:
709/315
U.S. Class at Publication:
709/315
Intern'l Class:
G06F 009/44
Claims
We claim:
1. An extensible framework for use in a computer system that supports an object oriented programming environment and includes a memory in which data objects can be stored, the framework comprising a set of object classes that can be extended using object oriented principles to define an information handling application with data objects comprising a class of data source objects and a class of data consumer objects, and a mediation layer that defines an interface between the data source objects and the data consumer objects to permit data communications between the two data object classes, such that the class configuration of the data source objects can be specified independently of the class configuration of the data consumer objects.
2. A computer system that supports an object oriented programming environment and includes access to data storage containing specifications for a set of object classes that can be extended using object oriented principles to define an information handling application with data objects comprising a class of data source objects and a class of data consumer objects, and a mediation layer that defines an interface between the data source objects and the data consumer objects to permit data information exchange between the two data object classes, such that the class configuration of the data source objects can be specified independently of the class configuration of the data consumer objects.
3. A computer system as defined in claim 2, wherein the mediation layer defines a data interface that provides an information exchange standard between the data source objects and the data consumer objects.
4. A computer system as defined in claim 3, wherein the data interface includes at least one attribute/metadata object class that specifies attributes, including metadata, and that provide declarative and procedural information relating to attributes in said data object.
5. A computer system as defined in claim 3, wherein the data interface includes at least one Relationship object class that specifies relationships between data source class objects.
6. A computer system as defined in claim 3, wherein the data interface includes at least one Domain Policy object class that specifies a group of related attributes, methods, and semantic information that indicates data processing to be available for the specified attributes, including the specific intent of said attributes.
7. A computer system as defined in claim 3, wherein the data interface includes at least one Event Change object class that specifies change event registration for detecting changes in the data objects.
8. A computer system as defined in claim 4, further including a TypeMetaData class of objects that specify semantic information indicating data processing to be available for specified attributes and intended use of the attributes of a data object.
9. A computer system as defined in claim 8, further including a TypeIO class of objects that define a desired format of a data object attribute specified by a TypeMetaData class.
10. A computer system as defined in claim 6, wherein an attribute alias may be specified by a user to indicate any data source attributes of an attribute domain that may be substituted with attributes of a different attribute domain.
11. A computer system as defined in claim 4, wherein said attribute/metadata interface provides input/output functions for display and editing of the attribute during runtime.
12. A computer system as defined in claim 4, further including a FieldMetaData attribute that specifies processing criteria for an attribute of a data object.
13. A computer system as defined in claim 4, wherein the processing criteria relates to a selected attribute of the data object for display processing.
14. A computer system as defined in claim 5, wherein the indicated relationship may be resolved using a version of the Relationship object in cache of the computer system.
15. A computer system as defined in claim 2, further including a collaboration facility that permits a user at a network computer remote from the computer system to share a view of a data object at the remote network computer.
16. A computer system as defined in claim 15, wherein the collaboration facility comprises a Meta View class of data objects that lightweight encapsulate elements of a data object for visual reconstruction on a display screen of the remote network computer.
17. A computer system as defined in claim 4, wherein the data interface provides an override function that can override default metadata of the data object attributes.
18. A computer system as defined in claim 6, wherein the data interface provides an override function that can override default metadata of the data object attributes.
19. A computer system as defined in claim 3, wherein data objects provided through the data interface comprise information that specifies data attributes, relationships, event broadcasting of changes in all registered data consumer objects, metadata for attributes that provide declarative and procedural information and/or input/output functions for display and editing, and related data items, and wherein the data objects can store references without direct access to a related data item.
20. A computer system as defined in claim 19, wherein the attributes and relationships include contextual metadata, and the events and methods are defined with respect to the contextual metadata.
21. A computer system as defined in claim 3, wherein the mediation layer further includes object classes that include one or more methods that provide data exposure, and further including a Data Source Interface object class of data objects with methods that automatically determine which data exposure method will be used for data communications between the data source objects and data consumer objects.
22. A computer system as defined in claim 21, wherein the determined data exposure method comprises data object reflection and introspection.
23. A computer system as defined in claim 21, wherein the data exposure methods include a data source object method that provides a standard interface, a data source object and a Translator object that maps an alternate data interface to the standard interface, and a data source object that is inspected by the computer system to determine available data fields which are thereby exposed to data consumer objects by the standard interface.
24. A computer system as defined in claim 3, wherein the data interface of the mediation layer provides a wrapper for the data objects.
25. A computer system as defined in claim 24, wherein data exchange occurs without providing contextual data characteristics to a receiving data object.
26. A computer system as defined in claim 25, wherein the contextual data characteristics are supplied by the data object wrapper.
27. A computer system as defined in claim 3, wherein data exchange occurs without providing contextual data characteristics to a receiving data object.
28. A computer system as defined in claim 2, further including a plug-in manager object class that integrates service components into the application.
29. A computer system as defined in claim 28, wherein data service components interact with other components of the application to determine if a service is required and to determine parameters that are to be interchanged.
30. A computer system as defined in claim 29, wherein the service determination occurs upon introduction of newly loaded components.
31. A computer system as defined in claim 3, further including a translator facility that translates information concerning a data object into (1) attributes and metadata that define groups of data source and data consumer class attributes and (2) an object class that specifies at least one domain method for defining groups of data object attributes.
32. A computer system as defined in claim 24, further including an InfoModel data object class.
33. A computer system as defined in claim 27, wherein said contextual data characteristics are supplied by an InfoModel object.
34. A computer system as defined in claim 33, wherein the InfoModel object receives a data source object for exposure to the data consumer objects, selects available attributes and methods of the received data source object for data characterization, and determines if the addition of attributes or methods to the data source object are appropriate.
35. A computer system as defined in claim 6, wherein the domain is defined using XML schema.
36. A method of communicating data in a computer system that supports an object oriented programming environment and includes data storage or access to data storage containing data objects and specifications for a set of object classes that can be extended using object oriented principles to define an information handling application, the method comprising: receiving one or more data objects comprising a class of data source objects; representing the data source objects in accordance with an Information Model class of objects of a mediation layer that defines a data interface between the data source objects and a class of data consumer objects; wherein the Information Model objects include methods that permit data communications or information exchange between the two data object classes, such that the class configuration of the data source objects can be specified independently of the class configuration of the data consumer objects.
37. A method as defined in claim 36, further including specifying at least one attribute/metadata object class that specifies attributes, including metadata, and that provides declarative and procedural information relating to attributes in said data object.
38. A method as defined in claim 36, further including specifying a Relationship object class or classes that specify relationships between data source objects.
39. A method as defined in claim 36, further including specifying a Domain Policy or Domain object class or classes that specify a group of related attributes, methods, and semantic information that indicates data processing to be available for the specified attributes, including the specific intent of said attributes.
40. A method as defined in claim 36, further including specifying an Event Change object class or classes that specify change event registration for detecting changes in the data objects.
41. A method as defined in claim 37, further including specifying a TypeMetaData class of objects that specify semantic information indicating data processing to be available for specified attributes and intended use of the attributes of a data object.
42. A method as defined in claim 41, further including specifying a TypeIO class of objects that define a desired format of a data object attribute specified by a TypeMetaData class.
43. A method as defined in claim 39, further including specifying an attribute alias by a user to indicate any data source attributes of an attribute domain that may be subtitued with attributes of a different attribute domain.
44. A method as defined in claim 37, wherein the attribute/metadata interface provides input/output functions for display and editing of the attribute during runtime.
45. A method as defined in claim 37, wherein the attribute/metadata object class is a FieldMetaData attribute that specifies processing criteria for an attribute of a data object.
46. A method as defined in claim 37, wherein the processing criteria relates to a selected attribute of the data object for display processing.
47. A method as defined in claim 38, wherein the indicated relationship may be resolved using a version of the Relationship object in cache of the computer system.
48. A method as defined in claim 36, further including providing a collaboration facility that permits a user at a nework computer remote from the computer system to share a view of a data object at the remote network computer.
49. A method as defined in claim 48, wherein the collaboration facility comprises a Meta View class of data objects that lightweight encapsulate elements of a data object for visual reconstruction on a display screen of the remote network computer.
50. A method as defined in claim 37, wherein the data interface provides an override function that can override default metadata of the data object attributes.
51. A method as defined in claim 39, wherein the data interface provides an override function that can override default metadata of the data object attributes.
52. A method as defined in claim 36, wherein data objects provided through the data interface comprise information that specifies data attributes, relationships, event broadcasting of changes in all registered data consumer objects, metadata for attributes that provide declarative and procedural information and/or input/output functions for display and editing, and related data items, and wherein the data objects can store references without direct access to a related data item.
53. A method as defined in claim 52, wherein the attributes and relationships include contextual metadata, and the events and methods are defined with respect to the contextual metadata.
54. A method as defined in claim 36, wherein the mediation layer further includes object classes that include one or more methods that provide data exposure, and further including a Data Source Interface object class of data objects with methods that automatically determine which data exposure method will be used for data communications between the data source objects and data consumer objects.
55. A method as defined in claim 54, wherein the determined data exposure method comprises data object reflection and introspection.
56. A method as defined in claim 54, wherein the data exposure methods include a data source object method that provides a standard interface, a data source object and a Translator object that maps an alternate data interface to the standard interface, and a data source object that is inspected by the computer system to determine available data fields which are thereby exposed to data consumer objects by the standard interface.
57. A method as defined in claim 36, wherein the data interface of the mediation layer provides a wrapper for the data objects.
58. A method as defined in claim 57, wherein data exchange occurs without providing contextual data characteristics to a receiving data object.
59. A method as defined in claim 58, wherein the contextual data characteristics are supplied by the data object wrapper.
60. A method as defined in claim 36, wherein data exchange occurs without providing contextual data characteristics to a receiving data object.
61. A method as defined in claim 36, further including a plug-in manager object class that integrates service components into the application.
62. A method as defined in claim 61, wherein data service components interact with other components of the application to determine if a service is required and to determine parameters that are to be interchanged.
63. A method as defined in claim 62, wherein the service determination occurs upon introduction of newly loaded components.
64. A method as defined in claim 36, further including a translator facility that translates information concerning a data object into (1) attributes and metadata that define groups of data source and data consumer class attributes and (2) an object class that specifies at least one domain method for defining groups of data object attributes.
65. A method as defined in claim 57, further including an InfoModel data object class.
66. A method as defined in claim 60, wherein said contextual data characteristics are supplied by an InfoModel object.
67. A method as defined in claim 66, wherein the InfoModel object receives a data source object for exposure to the data consumer objects, selects available attributes and methods of the received data source object for data characterization, and determines if the addition of attributes or methods to the data source object are appropriate.
68. A method as defined in claim 39, wherein the domain is defined using XML schema.
69. A computer system that supports an object oriented programming environment, the system comprising: a processor that executes program instructions to provide the object oriented programming environment; and data store means for providing program instructions containing specifications for a set of object classes that can be extended using object oriented principles to define an information handling application with data objects comprising a class of data source objects and a class of data consumer objects, and a mediation layer that defines an interface between the data source objects and the data consumer objects to permit data information exchange between the two data object classes, such that the class configuration of the data source objects can be specified independently of the class configuration of the data consumer objects.
70. A computer system as defined in claim 69, wherein the mediation layer defines a data interface that provides an information exchange standard between the data source objects and the data consumer objects.
71. A computer system as defined in claim 70, wherein the data interface includes at least one attribute/metadata object class that specifies attributes, including metadata, and that provide declarative and procedural information relating to attributes in said data object.
72. A computer system as defined in claim 70, wherein the data interface includes at least one Relationship object class that specifies relationships between data source class objects.
73. A computer system as defined in claim 70, wherein the data interface includes at least one Domain Policy object class that specifies a group of related attributes, methods, and semantic information that indicates data processing to be available for the specified attributes, including the specific intent of said attributes.
74. A computer system as defined in claim 70, wherein the data interface includes at least one Event Change object class that specifies change event registration for detecting changes in the data objects.
75. A program product for use in a computer system that executes program instructions recorded in a computer-readable media to perform a method for information exchange in a computer system that supports an object oriented programming environment and includes access to data storage containing data objects, the program product comprising: a recordable media; and a program product of computer-readable instructions executable by the computer system to perform a method comprising: receiving data specifications for a set of object classes that can be extended using object oriented principles to define an information handling application, wherein the extended objects provide an information handling application that can receive one or more data objects comprising a class of data source objects, and represent the data source objects in accordance with an Information Model class of objects of a mediation layer that defines a data interface between the data source objects and a class of data consumer objects; wherein the Information Model objects include methods that permit data communications or information exchange between the two data object classes, such that the class configuration of the data source objects can be specified independently of the class configuration of the data consumer objects.
76. A program product as defined in claim 75, wherein the method further includes specifying at least one attribute/metadata object class that specifies attributes, including metadata, and that provides declarative and procedural information relating to attributes in said data object.
77. A program product as defined in claim 75, wherein the method further includes specifying a Relationship object class or classes that specify relationships between data source objects.
78. A program product as defined in claim 75, wherein the method further includes specifying a Domain Policy or Domain object class or classes that specify a group of related attributes, methods, and semantic information that indicates data processing to be available for the specified attributes, including the specific intent of said attributes.
79. A program product as defined in claim 75, further including specifying an Event Change object class or classes that specify change event registration for detecting changes in the data objects.
80. A method of operating a computer system to execute an information handling application in an object oriented programming environment and to receive data from a class of data source objects and provide a class of data consumer objects with data, the method comprising: selecting available attributes and methods of a data source object for characterization; determining attributes or methods to be added to the data source object during application execution; and receiving the data source object and determining whether to expose or hide available attributes and methods of the object from data consumer objects, wherein data communications between the two data object classes is supported, such that the class configuration of the data source objects can be specified independently of the class configuration of the data consumer objects.
Description
[0001] This application claims priority of co-pending U.S. Provisional Patent Application Ser. No. 60/242,041 entitled "Extensible Information System (XIS)" by R. Kadel et al., filed Oct. 20, 2000. Priority of the filing date of Oct. 20, 2000 is hereby claimed, and the disclosure of said Provisional Patent Application is hereby incorporated by reference.
[0002] A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND
[0003] 1. Field Of The Invention
[0004] The present invention relates generally to data processing systems and, more particularly, to systems that process, analyze, and display data or information.
[0005] 2. Description of the Related Art
[0006] The continuing inroads made by computer technology into the practices of information storage and manipulation have opened up new realms of possibility for intelligent, informed decision-making. From labor statistics and scientific databases like the human genome project to traffic patterns and aircraft positions, the availability of information in electronic form allows sophisticated analysis techniques and display methods to be applied at the touch of a button. However this diverse array of information also poses significant challenges in areas such as:
[0007] effective organization of information;
[0008] ability to interpret and manipulate information in an increasingly wide variety of formats so that data and processing software can be brought together in a compatible but also timely and effective way; and
[0009] recognizing and navigating relationships between disparate information types.
[0010] This task of information management has already grown beyond the ability of human operators to keep pace with it, and in most applications, there is far more relevant information electronically available on the web and elsewhere than is effectively used. The problem is that software affording display of and interaction with information must be custom-designed for the particular type and format of the information it will work with. This leads to high costs of software development and limited availability of software appropriate to information of interest, and poor integration between information from different sources. An analyst must use one program when dealing with geographic distribution data such as precipitation amounts or land use, another for rendering 3-dimensional terrain, another for examining congressional districts and voting records, and so on. Many desirable applications of available data, such as determining correlations between political party and land use strategy in this case, fall between the cracks left by specialized applications, and there is no easy way to allow them to interoperate.
[0011] The primary means for allowing one application to operate on the results of another are the limited cut and paste facilities offered by many operating systems, which allow plain or formatted text or images to be moved between programs. There is no independent way to transfer structured data such as a table of numbers with particular column headings, a set of lists of items under specified categories, or even something as simple as a single number with an associated unit of measurement.
[0012] From the discussion above, it should be apparent that there is a need for computer systems that have greater ability to develop, integrate, and interoperate with disparate sources of information, to more easily develop software applications, components, or objects, and to facilitate interoperation of data between software components. The present invention fulfills this need.
SUMMARY OF THE INVENTION
[0013] In accordance with the present invention, a framework for use with object oriented programming (OOP) systems provides a framework user with classes that comprise a mediation layer that defines an interface between data source components and data consumer components such that the configuration of the data source components can be specified independently of the data consumer components. The mediation layer specifies data relationships of the data objects, domain methods for defining groups of class attributes, attribute metadata for defining groups of class attributes, and change event registration for detecting changes in data values. Thus, when extended, the mediation layer of the framework can support runtime data manipulation between unrelated data source components and data consumer components. In this way, the framework provides an extensible information system. The framework will be referred to herein as "XIS", and is especially suited to assist in the development of information-handling systems or applications.
[0014] Data source components that are configured for a non-XIS-aware programming environment or framework may still be used with XIS by "wrapping" such source components with code to conform to the interface requirements. Data objects of the well-known "Java" programming language are examples of data source components. Data consumer components thus are able to use or consume various data source components regardless of the data types and the data source. Thus, once a data consumer component is developed within the XIS framework, any data source components within the XIS framework may also accordingly be used. The framework can be provided as a group of APIs (application programming interface).
[0015] The XIS framework of the present invention also includes libraries and APIs that provide information management technologies that enable developers and integrators to combine XIS-aware components, data sources, and off-the-shelf JavaBeans into complete systems designed around whatever architecture is best for the situation. XIS further supports multiple, dynamic domains and is scalable to n-tier systems using the latest technology. The framework enables many developers to choose architectures based on their requirements (e.g., server, client/server, application server, web server, standalone, hand-held, etc.).
[0016] Other features and advantages of the present invention should be apparent from the following description, which illustrates, by way of example, the principles of the invention.
BRIEF DESCRIPTIONS OF THE FIGURES
[0017] FIG. 1 is a diagram of the extensible information system (XIS) framework constructed in accordance with the present invention.
[0018] FIG. 2 is a more detailed diagram of FIG. 1, showing the various interfaces within XIS, constructed in accordance with the present invention.
[0019] FIG. 3A is a more detailed diagram of FIG. 1, including information and services available within XIS, constructed in accordance with the present invention.
[0020] FIG. 3B is a hierarchical structure diagram of an embodiment of an InfoModel constructed in accordance with the present invention.
[0021] FIG. 4 is a more detailed diagram of FIG. 1 showing various information available to components within XIS constructed in accordance with the present invention.
[0022] FIG. 5 is a diagram of the semantic representation of a data item within the XIS framework constructed in accordance with the present invention.
[0023] FIGS. 6A to 6F show data consumer components, particularly display components, constructed in accordance with the present invention.
[0024] FIG. 7 shows a consumer component displaying the properties exposed by a data source object constructed in accordance with the present invention.
[0025] FIG. 8 is a unified modeling language (UML) diagram of a Person object.
[0026] FIG. 9 lists a set of attributes exposed within the XIS framework by the Person object of FIG. 6 constructed in accordance with the present invention.
[0027] FIG. 10 illustrates that an object constructed in accordance with the present invention may subscribe to more than one domain policy or definition.
[0028] FIG. 11 shows a domain usage and sequence scenario between a consumer component and source component constructed in accordance with the present invention.
[0029] FIGS. 12A to 12D list information regarding a Type Metadata package class typically implemented in the mediation layer and constructed in accordance with the present invention.
[0030] FIG. 13 shows a relationship usage scenario diagram between a consumer component and source component constructed in accordance with the present invention.
[0031] FIG. 14 is a flow chart that shows a reference resolution scenario usage sequence in which an indirect reference to an information element is created, passed around, and then resolved by two separate data consumers, causing reconstruction to occur only the first time.
[0032] FIG. 15 lists an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0033] FIGS. 16A to 16B list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0034] FIG. 17 shows a data consumer component using a source component constructed in accordance with the present invention.
[0035] FIGS. 18A to 18B list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0036] FIGS. 19A to 19B list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0037] FIG. 20 shows a data consumer component using a source component constructed in accordance with the present invention.
[0038] FIG. 21 lists an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0039] FIGS. 22A to 22C list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0040] FIGS. 23A to 23D list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0041] FIGS. 24A and 24B show two data consumer components using a source component constructed in accordance with the present invention.
[0042] FIGS. 25A to 25C list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0043] FIG. 26 shows a data consumer component using a source component constructed in accordance with the present invention.
[0044] FIG. 27A and FIG. 27B show a flow chart of a data exposure facility within the XIS framework constructed in accordance with the present invention.
[0045] FIG. 28 is a diagram of how InfoModels constructed in accordance with the present invention provide contextualization with the XIS framework.
[0046] FIG. 29 is a diagram of the pluggable service facilities within XIS constructed in accordance with the present invention.
[0047] FIG. 30 shows a flow diagram of a wizard or an API constructed in accordance with the present invention that assists in creating XML (extensible markup language) DSIs and database DSIs.
[0048] FIG. 31 shows objects and methods involved in distribution collaboration facilities constructed in accordance with the present invention.
[0049] FIG. 32 shows semantic repositories for distributed agents constructed in accordance with the present invention.
[0050] FIGS. 33A to 33P list information regarding a ContentInfoBean class constructed in accordance with the present invention.
[0051] FIGS. 34A to 34D list an information management package typically implemented in the mediation layer and constructed in accordance with the present invention.
[0052] FIGS. 35A to 35F list an InfoModel interface package typically implemented in the mediation layer and constructed in accordance with the present invention.
[0053] FIGS. 36A to 36B list a package for handling change events typically implemented in the mediation layer and constructed in accordance with the present invention.
[0054] FIGS. 36C and 36D show two sequence diagrams showing how change events are handled and constructed in accordance with the present invention.
[0055] FIGS. 37A to 37D list an exemplary Java source file to implement an information-handling application constructed in accordance with the present invention.
[0056] FIGS. 38A, 38B, 38C, and 38D show two data consumer components using a source component constructed in accordance with the present invention.
[0057] FIGS. 39A, 39B, and 39C is list information concerning an AttributeAlias class of the framework.
[0058] FIG. 40 is a block diagram of a computer device that may be used to operate with the framework, in accordance with the present invention.
DETAILED DESCRIPTION
[0059] The following detailed description illustrates the invention by way of example, not by way of limitation of the principles of the invention. This description will clearly enable one skilled in the art to make and use the invention, and describes several embodiments, adaptations, variations, alternatives and uses of the invention, including what we presently believe is the best mode of carrying out the invention.
[0060] The invention will be described by way of illustration with reference to various classes, objects, sample codes, etc. written within the exemplary framework, but it should be understood that such classes, class libraries, application programming interfaces, interfaces, objects, etc. may be differently coded, implemented, designed, etc. and yet support the functions and features of the present invention.
[0061] Object-Oriented Technology Many application programs and APIs (application program interface) are developed using object-oriented (OO) technology. Using OO technology, a system is typically developed as a collection of interrelated cooperative objects that are instances of classes that typically include corresponding states and behaviors. A class is a blueprint or template that defines the variables and the methods common to all objects that are instances of the class. An object maintains its state in one or more variables and implements its behavior with methods or functions.
[0062] Object-oriented programming (OOP) techniques encapsulate, or bind together, data and the methods that operate on them. This encapsulation permits program development to more closely model real-world entities and breaks up program development efforts into smaller, more manageable pieces. Although OOP techniques have done much to improve program development efficiency, such techniques still require a great degree of code generation on the part of developers, which discourages program reuse.
[0063] Even with OOP techniques, specifying data sources and the way in which data will be retrieved or updated from the data sources are still typically hard-coded within the objects themselves. An object, for example, may be specified to display pricing data (for example, a price display object) and would likely be hard-coded such that the data source is predefined. Thus, an object may be written to retrieve data from a source such as a relational database management system (RDBMS), a spreadsheet file such as a spreadsheet in the format of "EXCEL" spreadsheet application by Microsoft Corporation, or the object may be written to an XML file. Nevertheless, in conventional systems, the price display object would be limited such that if a different source of data, for example, an XML file rather than an EXCEL file, has to be used, the object has to be modified to incorporate access to and manipulation of the XML file. Furthermore, if a different set of fields are retrieved, for example, latitude and longitude (i.e., data fields unrelated to pricing information), a new object to display latitude and longitude may have to be written to display such information in tabular format.
[0064] Table I below shows the data configuration of a typical object.
1 TABLE I State/Properties: Name, SSN, position, DOB, and . . . Behavior: Record[] getRecords(DateRange) promote () . . .
[0065] For an application to be able to use this data object, the application would need prior knowledge of object properties (state) and behavior. The application would be tightly coupled with the class from which the object was instantiated. The meaning and intent of the data might be found in the source code or by asking the original programmers (e.g., SSN is social security number stored as string rather than a numeric type).
[0066] Assuming the object was created by one application written independently of another, the object could not be intelligently exchanged between the first application and the other with the expectation that the object would be processed unless the applications were tightly coupled. A way to have objects be used in various applications is thus highly desirable to reduce programming time and resources.
[0067] Common OOP languages include "Java" from Sun Microsystems, Inc. of Palo Alto, Calif., USA, C++, Simula, and Smalltalk.
[0068] Framework
[0069] The concept of a framework is an important part of OO programming technique. A framework is a specification of the classes and the relationships between classes such that the framework defines a class hierarchy that can be used over and over again, with overrides and extensions. In this way, an initial problem solution specified by a class hierarchy can be adapted and customized for new circumstances, simplifying program maintenance. In essence, a framework is a set of OOP classes that embodies a predetermined set of attributes and methods for providing a common group of behaviors.
[0070] OOP frameworks have been developed in an effort to further reduce program development costs. An application program developer utilizes the framework and builds upon it, starting with the classes, attributes, and methods defined by the framework designer and adding subclasses and attributes and modifying methods depending on the problem to be solved. Such changes to the framework are typically referred to as framework extensions, and are made possible by the OOP notions of inheritance and polymorphism. Thus, a framework can speed the development of an OO application program. The challenge confronting framework developers, then, is to define a set of classes and methods that best supports the desired problem solution and will accept the most likely framework extensions. Thus, the designer of a framework must carefully assess what framework users will most likely need in the way of classes, attributes, and methods.
[0071] It is therefore a technical advantage of the present invention to provide a framework that allows information-handling software to adapt to new data types and formats of information, so that a single application built within this framework has a significantly broader range of compatibilities and domains of usefulness than a conventional application and, further, may automatically interoperate at a structured level with other similarly enhanced applications. In one embodiment of the present invention, desirable applications of data such as determining correlations between political party and land use strategy may be facilitated.
[0072] In an embodiment of the present invention, a single information visualization or manipulation application is able to handle many diverse types of information, even those that are conceived and developed subsequently to the completion of development of the application itself.
[0073] In another embodiment of the present invention, information from multiple and diverse sources yet sharing some basic feature in common--such as being distributed in geographic space, or being distances measured in meters--can be simultaneously displayed (superimposed) and manipulated within a single application. This invention further provides means of access to common data sources such as relational databases, extensible markup language (XML) streams, and "Java" programming language software objects.
[0074] In an embodiment of the present invention, an information-handling application is defined as any software application which is capable of utilizing digitally available structured information in bulk form, such as from electronic files, databases, or internet web sites to provide a display and/or a set of possible manipulations to a user, such as after some internal processing and transformation of the information such as summarizing it, performing computations on it, or selecting a subset. Examples include but are not limited to graphing programs, analysis tools (for handling financial data, statistical, time series, etc.), and interfaces to geographic information systems. Prototypical information-handling applications process structured information that has some form of hierarchical and/or modular structure. In one embodiment, image and word processing applications are not examples of what we term information-handling applications. In another embodiment of the present invention, structured information in bulk form does not include plain text or specific electronic media files such as MP3 files.
[0075] A conventional information handling application such as a graphing program comprises two major components: one component handles the intake of information, from storage devices, the network, or user input, and the other component handles the display of the information. There may also be parts of the application that perform computations or transformations on the information before it is displayed. From the developer's perspective, a modular piece of software that handles a portion of (or all of) the data intake function is a data source component, because it provides information to other components within the application. A modular piece of software that handles part of (or all of) either the computation, transformation, or display of information is a data consumer component, because it uses (consumes) information provided by the data sources.
[0076] Data sources and data consumers communicate with each other by making function calls. The particular functions and their parameters are defined as part of an internal version of an application program interface (API). The data consumer components handle data that is given them through specific calls on their respective API, so that information provided through data source components written for different applications will not be accepted. This situation provides little opportunity for reuse of data source or consumer components, since each is written to interoperate only with a specific instantiation of the other.
[0077] In an embodiment of the present invention, an internal mediation layer is inserted between the data source components and the consumer components that expose data structure in a standardized way. Consumer components are constructed to use this common API, which is suitable for expressing an extremely wide variety of information types. Data source components can be constructed to deliver the information they take in this format, or a small amount of code can be written to translate the output of another source component into the common format. The result of the construction is that any consumer component can work with any data source component regardless of the specific nature of the information involved, or whether one was anticipated during the design of the other. The common API allows consumer components to automatically extract whatever features of information from a particular source they are most suitable for displaying or computing with, and also allows them to utilize all the other features of that information in a generic, unspecialized fashion.
[0078] Other embodiments of the present invention comprise: (1) a system for representing information such that: (a) a single fixed interface suffices to describe a wide range of information types, (b) the information is rendered self describing to an extent, and (c) relationships between different information elements are expressed; (2) an apparatus for allowing this information representation to be employed as a medium between data source and data consumer software components; (3) a method and apparatus for attaching clarifying material on "intended use" to information so that consumer components can handle it more appropriately; (4) a method and apparatus for providing a context to all information consumption affording control over security and visibility of data; (5) a method and apparatus for allowing users to transfer information from one consumer component to another through intuitive "drag and drop" and "cut and paste" interfaces; (6) a method and apparatus for developing enhanced information handling applications based on the foregoing framework; (7) a method and apparatus for automatically re-representing data from partially self describing sources including relational databases, XML streams, and Java software objects; (8) a method and apparatus allowing end users using computers distributed over a network to collaboratively view and manipulate information; and (9) a method and apparatus allowing software components distributed over a network to automatically obtain annotations on intent and other aspects of encountered data.
[0079] Most aspects of this invention can be implemented in any object oriented programming language such as Smalltalk, Objective C, C++, or Java. Certain aspects of it, pointed out below, are especially suited to object oriented languages such as Java and Objective C that provide for run time self analysis by programs. However, these are in every case peripheral aspects, and the essential parts of the invention may be implemented in an object oriented language like C++ without these capabilities. We will from time to time make reference to a "preferred embodiment" implemented in Java, but this should not be taken to be limiting.
[0080] In a preferred embodiment the present invention provides a system and/or framework of software components for purposes of aiding development of information-handling applications. The system and/or framework of object-oriented software components aid the development of applications that read, gather, or receive electronic information and allow the display of such information to and manipulation by users. These applications are structured in a way so that there are distinct data source components and data consumer components. The crucial features of the system and/or framework are the fact that data is seen by consumers only through a standard, conventionalized interface that incorporates: a breakdown into attributes, relationships, semantically-annotated "domain methods", event-broadcasting of changes in the foregoing to all registered consumers, metadata for each attribute providing certain declarative and procedural information including unit of measure, content length, data quality, default value, comparator function, summary function, validation function, and input/output functions for display and user editing within an extensible set of interface modalities, related data items available for each data item including those in child or generic relationships, and including the ability to store a reference without direct access to the related item itself (it can be reconstructed if needed), and contextualization such that the attributes, relationships, events, and methods available for a data item depends on context (see below).
[0081] In a related embodiment, the system and/or framework includes methods for data exposure wherein the system determines automatically which method is employed in any particular case, and the choice is invisible to consumers. Exemplary methods such as, a data source component which directly provides the standard interface, a data source component which is accompanied by a separate Translator component which maps its interface to the standard interface; and a data source component which is automatically inspected by the system to determine what available data fields it has, these are exposed to consumers through the standard interface as detailed above.
[0082] In a preferred embodiment, the contextualization provided by the system and/or framework is accomplished by delegating the final responsibility for data exposure to an object termed an "InfoModel" which is able to choose which of the available attributes and methods on an object should be exposed or hidden, and is able to add additional attributes or methods. Preferably, the system and/or framework further provides facilities supporting transfer of data items between consumers, either by user manipulation (cut/paste or drag/drop) or by internal method calls. When a transfer is initiated, the data item is passed without its contextual characteristics (supplied by an InfoModel) to the receiver. The system and/or framework includes facilities supporting the automatic integration of service components (generally comprising management facilities such as menu provision or running of user dialog routines and may or may not have data source provider and/or user interface provider components) into an application. Integration is handled by a plug-in manager object and set of interfaces such that: each service provider is given the opportunity upon loading to query all components (data providers or consumers) existing within the application for whether they desire the service, and if so what parameters they would like to pass to it. The provider then acts on these responses. Whenever new client components are loaded, they will be queried and possibly responded to by all services loaded within the application.
[0083] In another embodiment a system for importing partially schematized or structured data sources (such as a database system or an XML document) into a system as described herein. Any application written using the disclosed system and/or framework can then utilize these data sources through a standard interface. In particular, a system and/or framework for performing all or a substantial portion of the functionality outlined herein--if it is in connection with a framework or application implemented using a framework falling under categories as disclosed such as an infrastructure for mediating between information sources and consumers and rapidly assembling applications using them.
[0084] Thus the present invention provides a method and apparatus involving two subsystems, one which processes the schema information for a data source to determine the type and metadata information for information attributes from the source, and one which processes the instance information. Preferably, the schema subsystem processes schematic information such as the type information contained in an XML schema document or the column information available from a relational database management system and sets up appropriate metadata and relationship structure for information elements, but it does not necessarily create any information elements. Optionally, additional annotations can be provided by a user in the form of a file specifying how to map attributes in the original data to metadata, relationships, or domain policy attribute or method definitions. Preferably, the instance subsystem processes instance information such as that available from an XML document or set of relational database rows, for which corresponding schema information can be found, and constructs information elements exposed through the standard interface. Data consumers can utilize the outputs of these as if they were custom-created data sources for the type of information described in the schemas.
[0085] In a related aspect, implementation of the invention as described herein for both XML and relational databases is provided. In the XML implementation, a built-in data type hierarchy for XML schemas is used to provide types to attributes, and the element-subelement-attribute structural hierarchy in XML schemas is used to determine relationships between information elements. All documents and schema references to other documents are followed up to their sources in order to specify further attribute or relationship information. A user can optionally specify an XSLT (XML Stylesheet Transformations) document that maps the typed data fields found from the instance-schema combination into attributes with richer metadata and/or references to specific domain policies. In the database implementation, the table column heading types from the relational database (date, integer, text, etc.) are used to provide default type metadata to the attributes of information elements derived from table rows of the database. A user can optionally specify a mapping between columns or sets of columns into attributes with specific metadata. Furthermore, a user can define a sequence of queries for which the results are to result in a hierarchy of information elements. For example, for each information element retrieved from, for example, Query 1, a parameterized instantiation of Query 2 may be applied to retrieve elements which will be exposed as the children of the first information element. For each of these elements, a parameterized instantiation of Query 3 may be instantiated, and so forth.
[0086] Framework Block Diagram
[0087] FIG. 1 shows a basic block diagram of a framework that is implemented in accordance with the present invention. The framework 100
of FIG. 1 can be used to develop, for example, an information-handling system or application wherein data source components 102 and data consumer components 122 are separate and independent from each other but can communicate and share data. The framework 100 described herein shall be called the extensible information system (XIS) framework.
[0088] From a developer's perspective, a modular piece of software that handles part or all of the data intake or retrieval function is a data source component 102. A modular piece of software that handles part or all of either data computation, transformation, presentation, or display of information is a data consumer component 122. A conventional information-handling application such as a graphing program comprises two major components: one side handles the intake of information from storage devices, the network, or user input, and the other side handles the display or presentation of the information. There may also be parts of the application that perform computations or transformations on the information before it is displayed.
[0089] XIS Framework
[0090] In the XIS framework 100 constructed in accordance with the invention, there may be more than one data source component 102 (also referred to as a source, data source, source component, and source object) and there may be more than one data consumer component 122 (also referred to as a consumer, consumer object, consumer component, and data consumer). The data source components 102 provide information to other components within the XIS framework 100 via a mediation layer 112, while the data consumer components 122 use the provided information.
[0091] The source components 102 and consumer components 122 that comprise the XIS framework 100 are configured such that they communicate with each other in a manner that is supported by the programming environment in which the framework exists, typically by making function calls, via the mediation layer 112. In one embodiment, the mediation layer 112 consists of a group of application programming interfaces (APIs) or class libraries that define a common format for data exchange, establishing an information exchange standard. Thus, data source components 102
configured for a different system, application, or framework may still be used within the XIS framework if they are "wrapped" in a predetermined way or are suitably modified, as will be known to those skilled in the art, such that they conform to the requirements of the data exchange interface of the mediation layer 112.
[0092] A relatively simple block of programming code may be produced to translate the output of a data source component 102 into the common format as defined by the mediation layer or API 112. In this way, any consumer component 122 may work with any data source component 102
regardless of the specific nature or type of information involved and regardless of whether the data source component was known or anticipated during the design of the data consumer component. Because of the XIS framework described herein, the data consumer 122 may also extract whatever features or sets of information that it needs or can process from one or more data source, thereby enabling the data consumer to utilize features and information in a generic unspecialized fashion.
[0093] The mediation layer 112, which is between the data source components 102 and the consumer components 122, exposes the data structure of the data source components 102 in a manner that is common for the framework, preferably through an API interface. Data consumer components 122 are constructed to use this common API, including utilizing the exposed data structure. The data consumer components 122
are suitable for expressing an extremely wide variety of information types. In addition, the data consumers may be constructed to deliver the information received from the mediation layer to another data consumer component, or to output the information received for display.
[0094] Data consumer objects 122 are application or software objects or components that use data, or may be said to consume it. Examples of data consumers include display programs that display data in tabular format, in graphical mode, in organizational chart mode, spreadsheet mode, timeline mode (similar to files in the format of the "PROJECT" application from Microsoft Corporation), and the like. Data consumers may be desktop based, web-based (Internet-based), distributed architecture, interpreted programs, and the like. Data consumer components within the XIS framework may provide display, computational, or interactive facilities. In the present description, such specially configured data consumer components are referred to as "INFOBEAN" objects, as available from the assignee of the present invention, Polexis, Inc. of San Diego, Calif., USA. Those skilled in the art will understand how to extend the framework 100 to produce desired applications, in view of the description herein.
[0095] FIG. 2 shows additional details of the mediation layer 112 in the framework 100. In the framework 100, four special types of interfaces may be exposed to the data consumer components 122. These four interfaces include Domain Definition or Domain Policy 202, Relationship 210, Attributes/Metadata 214, and Change Event 216. In one embodiment, change events are registered within the XIS framework 100. These interfaces may be exposed, for example, through class and object libraries that may be developed for the XIS framework. With these pre-defined class and object libraries and APIs, developers of data source components 102 and data consumer components 122 may independently develop their own source and consumer components, thus facilitating development of information-handling applications or systems. An example of a class that may be implemented or written in the mediation layer to facilitate development of source and consumer components is illustrated in FIGS. 33A to 33P, which show details of a sample class called ContentInfoBean.
[0096] Domain definitions or policies 202 (also referred to as domain objects or simply domains) are optional within the XIS framework 100. If defined, the corresponding Domain methods 212 for such policies are exposed to the data consumers 122. Other information about the domain policy may also be exposed, such as Attributes/metadata 214 and Relationships 210 for that particular Domain Policy. Attributes/Metadata 214, Change Events 216, and Relationships 210 may also be exposed within the XIS framework 100, even if domain policies are not defined.
[0097] Relationships show the relationship between data source components. Containment, hierarchies, and ad-hoc relationships, for example, may be shown. They may be expressed as "members of" and references. Relationships are thus recognized and may be obtained accordingly, as shown in FIG. 14 described further below.
[0098] Change events may be used to ensure that all consumer or source components that have an interest in another source component's data are notified when changes occur. Changes may be notified when attributes, members (or containers), or references (or referrers) are added, updated, or removed and when values are changed.
[0099] Once a data consumer component 122 obtains a reference to a data source 102, the data consumer component may obtain access to these interfaces 202, 210, 212, 214, 216 through method calls in accordance with the programming environment of the host computer system. The data consumer 122 obtains such a reference typically in preparation to consume or use information from at least a particular data source 102. Examples of such consumer component method calls include:
[0100] get attributes;
[0101] get member and container information elements;
[0102] get referred and referring information elements;
[0103] get unique ID and selection state;
[0104] add and remove instance specific attributes;
[0105] register to be informed of changes to attributes or relationships; and
[0106] invoke method calls of a semantically annotated type, described below.
[0107] These types of method calls will be familiar to those skilled in the art and familiar with the programming environment of the host computer system.
[0108] FIG. 3A is a schematic diagram showing the information about data source objects that is exposed by the mediation layer 112 in FIGS. 1 and 2, as well as the services available within the XIS framework 100. In accordance with the invention, data source components are wrapped with an object that exposes the interface information for the data source to data consumers through the mediation layer.
[0109] In the preferred embodiment, the wrapper around each data source is an object provided by a class called InfoModel. As shown in FIG. 3A, a data source comprising a raw data item 351, via the APIs 112 as described above, offers a variety of information, as shown in the blocks 354, 356, 358, 360, 362, through which data consumers may gain access to the data source. The information represented by the blocks 354, 356, 358, 360, 362
is exposed or may be contained within an InfoModel 350, which provides an information space for all information available in the XIS framework 100
for the wrapped data source component. In one embodiment of the invention, the data needed by data consumers are accessed via such InfoModels (such as further illustrated in FIG. 28). The wrapper provided by the InfoModel is called a LeifDataItem object 352. Thus, the InfoModel is an interface that permits data sources and data consumers of the XIS framework to independently share their data. In this way, the methods 360, domains 358, metadata 354, relationships 356, and other information of a data source object are thus exposed using the InfoModel object, which may be said to exist in the mediation layer 112, which sets up contexts for data consumption. The XIS framework also provides additional data services through the mediation layer, such as the Plug-In Service 264 and BeanContext Service 266 indicated in FIG. 3A. These services provide the functionality listed in their respective boxes 364, 366. Other data services may be provided, as desired.
[0110] The InfoModel object provides a context for information access, i.e., context is instantiated through the InfoModel concept. In this way, security may be enforced, considering that the conceptual or real "end-user" accessing the information is known and thus the underlying data source may be forwarded correctly. Furthermore, through this InfoModel concept, an embodiment of the framework may be implemented such that attributes and methods may be added or removed by the framework user. Original attributes and methods in one context may also be overridden.
[0111] An attribute is any property of an object. In one embodiment of the invention, an attribute may be coded with an "AttributeDescriptor". An AttributeDescriptor is provided by the object or its Translator to describe a property of the object using TypeMetaData, e.g., how to display it, how to edit it, its permitted ranges, and the like. Translators map data source-specific structures and types to an XIS-generic representation. Translators are further discussed below. Attributes may also be defined using Java introspection or reflection, as discussed further below.
[0112] Dynamic attributes may also be exposed within the XIS framework 100. These attributes are attributes that are exposed during run time, such as, for example, a database query wherein each column is an attribute revealed at run time. The mediation layer has a mechanism that captures such information. In the preferred embodiment, the XIS framework operates in conjunction with a database management application, so that the mediation layer utilizes run time database query mechanisms that generate-metadata of the data object, such as data table column headings, data types, and the like. Such mechanisms may be provided, for example, by SQL queries and the like. In one embodiment, data consumer applications using the XIS APIs are unaware of whether an attribute for a data item is obtained dynamically or statically, so that the process is transparent to the application user.
[0113] A domain is a collection of semantically meaningful attributes and method signatures grouped by their common domain of interest. Examples of domains include a Display Domain (a domain that describes how to display information) or a Geo Domain (a domain that specifies how to handle geographic information). Domains are further discussed below.
[0114] The contextualization provided by the XIS framework system is accomplished by delegating the final responsibility for data exposure to an object termed an "InfoModel", which is able to choose which of the available attributes and methods of an object should be exposed or hidden, and is able to add additional attributes or methods. Preferably, the system and/or framework further provides facilities supporting the transfer of data items between data consumers, either by user manipulation (cut/paste or drag/drop) or by internal method calls. This supports data sharing among data consumers. When a transfer is initiated, the data item is passed without its contextual characteristics (which are supplied by an InfoModel object) to the receiver, i.e., only non-contextual information is transferred. In this way, the source data may remain unchanged.
[0115] As illustrated in FIG. 3A, a FieldMetaData file 354, a type of metadata, is used to represent sorting, subset, and visibility criteria for an attribute. This is further explained below in conjunction with Examples 1 to 5, wherein subsets of data are shown depending on whether "All Attributes" or "Preferred Attributes" are shown. In one embodiment of the invention, default behavior method of domain policy attributes may also be overridden. Within this framework, context-specific special attributes for flagging whether a data item should be visible or not (e.g., can be used for display filtering, including the XIS value slider, tree checkboxes in the map view, etc.) may be defined. This may be achieved through the mediation layer by utilizing a user interface to modify display processing for the data item. Furthermore, a selection attribute that is a context-specific special attribute for flagging whether an object is "selected" (and typically should be highlighted) may also be defined. Selected pieces of information are often shared among views (context-specific, though), and certain operations may be performed on the set of selected objects in a given context The InfoModel objects as described above know how to return a data item (a LeifDataItem) given a corresponding raw data source identifier. The InfoModel also manages these data items. As indicated in FIG. 3A, an InfoModel may contain one or more LeifDataItem objects, each of which provides an interface to a raw data item. An application developer may use an InfoModel object 350
to get a LeifDataItem object 352 in order to use the XIS APIs for accessing the underlying data source in a generic fashion. If two different data consumer components ask for a data item (e.g., a LeifDataItem) from the same InfoModel for the same raw data source, then both data consumers will get the same instance of the LeifDataItem object. InfoModel objects may also be nested as indicated in FIG. 3B.
[0116] Information becomes normalized in the XIS framework so that any application can use an object's information by getting attributes and relationships dynamically at runtime. Therefore, instead of hard-coding a visualization program to a specific type of object, the visualization looks for the attributes it needs to perform its function. Thus, the developer of the data consuming module may obtain the information needed from the XIS LeifDataItem class, which wraps raw data item objects and exposes them to the data consumer through uniform APIs. The visualization can access all the information exposed, through the XIS APIs and techniques, as needed. If the data source provides AttributeDescriptor objects or translates the properties to domain attributes, then the information can be interpreted more intelligently in domain-specific ways. In one embodiment of the invention, the XIS framework also offers APIs and a programming model (or design pattern) that extends Sun's JavaBean pattern with XIS information awareness. These extended JavaBeans comprise "smarter JavaBeans" that are provided in the XIS framework as the specially configured INFOBEAN objects and, like JavaBeans, INFOBEANs can be visual or nonvisual components, and can be graphically combined in any standard Java development environment.
[0117] InfoModel Class Objects
[0118] In one embodiment, there are four types of InfoModels in the XIS framework:
[0119] BaseInfoModel:
[0120] A single BaseInfoModel is required because it is responsible for creating and caching every BaseDataItem (data item) wrapping a Java object (the raw data item object). The BaseInfoModel object holds any object used as a LeifDataItem until the data item is no longer needed (i.e., until it is no longer strongly referenced).
[0121] SelectableInfoModel:
[0122] A super class of BaseInfoModel, this InfoModel delegates to any other InfoModel (typically the BaseInfoModel), and creates SelectableDataItems (data items that are selectable). The SelectableInfoModel objects add a selected Boolean attribute and delegate to the LeifDataItems from the prior InfoModel. Since the BaseInfoModel is a SelectableInfoModel, all LeifDataItems have a selected attribute. This is true because any LeifDataItem is either in the BaseInfoModel itself, or is in an InfoModel that is nested in the BaseInfoModel and, therefore, inherits the selected attribute from the BaseDataItem. Additional SelectableInfoModels can be instantiated to create independent contexts for selection state, independent of other InfoModels.
[0123] AttributeFactoryInfoModel:
[0124] This InfoModel allows AttributeFactory classes to be registered so that every time a LeifDataItem is created, it enables attribute factories to add additional attributes to each LeifDataItem.
[0125] InfoModelSubset:
[0126] A super class of SelectableInfoModel and AttributeFactoryInfoModel, this is the simplest InfoModel. It delegates to its parent InfoModel and creates LeifDataItems that wrap those XIS data items from the other InfoModel. This InfoModel does not automatically add any attributes to the LeifDataItems it creates and manages, but simply provides a context in which data items can be managed. Each InfoModel "layer" provides a context in which additional attributes can be defined, or existing ones can be overridden. FIGS. 34A to 34D list an exemplary Java package that lists various classes. FIGS. 35A to 35D list the InfoModel interface. An interface is a contract in the form of a collection of method and constant declarations. When a class implements an interface, it promises to implement all of the methods declared in that interface.
[0127] Exposing Data
[0128] FIG. 4 is a diagram showing how information from source components may be exposed to data consumers using the mediation layer 112. The Attribute/Metadata interface 214 of FIG. 2 exposes a data item 440, 442
as a set of attributes, each of which carry a value and a set of metadata that describes the value. A data consumer component 420, 422, 424 may obtain information from one or more data items. Similarly, a data item 342 may be used by more than one data consumer 422, 424 via the mediation layer or API 112. The information blocks 460, 461 show the information available to data consumers.
[0129] A data source component 102 may comprise a data source interface (DSI) object 412, 414. A DSI object 412, 414 provides a conceptual way to encapsulate objects that provide data to the XIS framework 100. A class of a DSI object does not have to extend or implement any interface. Data is created (instantiated) in DSI objects to thereby encapsulate the data and make it available to other objects. The DSI itself may also be a data item that simply contains other data items (members). The data may be generated internally or extracted from an external source such as a database or across a LAN. In addition to creating the data, DSI objects are also responsible for maintaining and controlling data, such as removing and updating the data themselves if such changes are observed in the underlying data used by the DSI to create the data. Property change events (216 of FIG. 2) may be used by DSIs to communicate changes observed in the original source data items to the listening data consumers.
[0130] Any Java object may be a data source component. The Swing JButton, for example, is usually a transient object, and not typically retrieved in an information system. The Swing JButton, however, may still be a data source, if so desired.
[0131] INFOBEANs as stated above are data consumer components 420, 422, 424. They are specially configured objects that behave like JavaBeans that process and manipulate data in a generic fashion. They are also capable of interpreting and optionally displaying XIS data items. INFOBEANs use the XIS framework API's to gain access to information about data items.
[0132] As previously stated, any Java object may become a data item 440, 442 within the XIS framework 100. To make a data item out of JSlider javax.swing.JSlider), it simply must be added to an INFOBEAN (data consumer component). Table II below provides programming code that makes a data item out of javax.swing.JSlider, thus exposing the information blocks 460, 461 shown in FIG. 4.
2 TABLE II Jslider slider = new Jslider(0, 100, 50); tableInfoBean.addRawDataItem(slider);
[0133] The first line of code creates a data item out of JSlider. The second line of code adds the JSlider created in line 1 to the TableInfoBean object (an INFOBEAN). In this framework, JSlider knows nothing about the XIS framework, however, all its attributes are exposed, to be used and modified.
[0134] There are basic steps that must be performed when creating a DSI. First, before any code is actually written, a determination must be made as to how the original data or data source is to be obtained (e.g., will it come from a database, a flat file, an EJB (Enterprise JavaBean), read from a socket, etc.). This step is performed prior to and independent of coding the DSI. Once the data source has been determined, it must be decided what attributes of the data source should be exposed within the XIS framework.
[0135] The DSI component within the mediation layer of the XIS framework has the capability of exposing the attributes of a data source. In one embodiment, assuming that the data source is a Java object, the attributes to be exposed are determined through Java introspection. Introspection is a way to determine a bean's properties, methods, and events. Those skilled in the art will understand that a bean is a reusable software component, which may be combined to build applications. In this scenario, no additional code in the consumer component needs to be written. Although convenient, this approach is limiting, as it does not allow control over which attributes are exposed, and does not allow the user to define custom visualization components or express semantics. Furthermore, it requires the Java object to conform to the JavaBean design pattern.
[0136] Another approach to determining which attributes of a data source should be exposed involves writing new code. This approach embeds XIS-aware code directly into the Java object. This allows the component developer to directly specify details such as the attributes (e.g., via AttributeDescriptor) to be exposed along with their metadata, the Domains to which the DSI subscribes, which Domain methods are exposed with what implementations, and more. Writing new code enables greater control over the data item (as opposed to the introspection-only case) and provides more flexibility in dealing with any Java object rather than just JavaBean objects. One limitation of this approach is that the relationships between data items may not be directly specified.
[0137] Another approach for exposing attributes is to create a Translator class. An application developer may place any of the XIS-aware code for exposing attributes, Domains, and the like in this class, as specifying relationships to other data as members or as references. This is described further below, in conjunction with the description of FIGS. 21
to 23.
[0138] Referring back to FIG. 4, a data consumer 420, 422, 424 may access a data source via a data source interface (DSI) object defined in the mediation layer 112. Communication between the DSI objects 412, 414 and data consumers 420, 422, 424 in the framework 100 is mediated through a set of application programming interfaces (APIs) 112 that remain independent of the actual contents and types of the data sources. Such APIs are contained in class libraries.
[0139] Using the framework 100, a data consumer 420, 422, 424 (for example, an INFOBEAN as shown in FIG. 6B) may be able to use heterogeneous data sources and, thus, eliminate the need to write a particular display software object for each particular data source. Within this framework, any data consumer object or application may use the data source object's information by getting attributes and relationships dynamically at run time. Instead of hard coding a visualization to a specific type of data source component, the visualization object or data consumer looks for the attributes it needs to perform its function. Thus, in this framework, developers for source and consumer objects may work independently of each other.
[0140] The DSI object may create any data structure containing members and references, and may expose any part of that data structure to the framework or system 100 if it is desired. Since there are no requirements involved to be a data source, a visualization bean can also be a data source. The data source can consume data from other data sources, and can create new data based on what it has learned. For example, DSI objects may be coded to use data source from an RDBMS, e.g., systems such as provided by Oracle Corporation of Redwood Shores, Calif., USA and as provided by Microsoft Corporation of Redmond, Wash., USA through their "ACCESS" application or SQL Server. DSI objects also may use data sources such as XML format data, tabular data (e.g., spreadsheet data such as spreadsheet files in the format of the "Excel" application from Microsoft Corporation), email, schedules (e.g. schedule data in the format of the "PROJECT" application from Microsoft Corporation), data following the SNMP (simple network management protocol), and the like.
[0141] Objects created by DSIs are considered to be raw objects in the XIS platform. These raw objects become normalized objects within the XIS framework when they conform to the mediation layer or the API 112. In one embodiment, when these raw objects are added to an XIS-enabled environment, the XIS framework wraps them with a normalized object called a LeifDataItem (see FIG. 3A) and holds the data item in one or more InfoModels. The raw data item could be a simple Java object (that does not know anything about XIS) or it can support XIS with direct references to AttributeDescriptors and other metadata that are recognized by XIS. The mediation layer is implemented in software and runs in-process. It is also exportable to serve as a distributed middleware if required by a given application.
[0142] An attribute is any property of an object. An attribute 474, 475
typically includes identity (ID number) 476, 477, name of the attribute 478, 479, value 480, 481, and the metadata type or Type Metadata 482, 484, and a description 484, 485. Attribute names 478, 479 may be the table column header or field name in an RDBMS. The description of the attribute 484, 485 may be plain text that explains the attribute. The value 480, 481 may be expressed as a number, string, or other basic data type, or may be expressed as a complex, structured object in itself.
[0143] Referring back to FIG. 2, the Attribute/Metadata interface 214
provides for fine-grained exposure of an information element or data item 440 442 (FIG. 4); by "fine-grained" is meant that the data item is broken down into a number of aspects or characteristics (the "attributes") which are simpler data elements. These might be numerical values, strings, arrays, or anything else that can be represented by a software object (but is simpler than the original element). If a data consumer 412, 414
is not able to handle the entire data element, it may be able to handle some of its attributes and therefore may be able to do something useful with it, unlike most systems providing interfaces for data integration, which require the entire interface to be implemented to enable any data usage.
[0144] The Attribute/Metadata interface 214 also makes each attribute self-describing, to a limited extent. In accordance with the invention, a data consumer designed without regard to a particular type of attribute is still able to display and perform limited operations with those attributes by using the metadata types. For example, a data consumer object or INFOBEAN, which displays an X and Y chart of cost of living (expressed as a numerical value) versus geographical location (expressed as a territory or state character string, e.g., "California"), may be used to display a different set of data contained in another data source component or data item, so long as the metadata types of the different sets of data are compatible with the X and Y chart. In particular, a data consumer component that renders and edits information may still be executed, the default value substituted in cases of absence, and statistical summarization performed, even if the data consumer component is processing a different data source component. Other operations are possible and additional metadata may be provided by developers for any identified classes of information elements (such as number, array, geographic entity, etc.) desired. Because of this, data consumer developers may identify the type of auxiliary information or procedures provided by the consumer component and then define the interface according to which other developers creating data sources should provide or expose their metadata.
[0145] In one embodiment, any property or attribute of an object may be defined with an AttributeDescriptor programming code. When a data source object is enabled within the XIS framework, the computing system automatically creates AttributeDescriptors for JavaBean properties and for some public properties. A JSlider object, for example, is a JavaBean. JavaBeans have properties that are defined by the get<property> and set<property> methods. If the object is a JavaBean and provides a BeanInfo, then it will be honored and treated according to the JavaBean's specification for BeanInfo classes. Only properties listed in the BeanInfo appear as attributes. If metadata types, further discussed below, support the property's type, then they appear as attributes for that data item. Any properties that do not have TypeMetaData support become data items themselves (using the same reflection and introspection rules) and are listed in the data item's reference array, retrieved by the LeifDataItem getReferences( ) method (i.e., a method to obtain the references). Translators translate various data item classes, thereby enabling seamless integration of various data items without code modification. Translators may also be added to augment object reflection and introspection, i.e., by developers directly specifying the properties of an object.
[0146] Table III below lists exemplary programming code to define attributes. Table III shows how to define a SIZE attribute.
3TABLE III public static AttributeDescriptor SIZE; static { AttributeDescriptorFactory factory = AttributeDescriptorFactory.getAttributeDescriptorFactory(); SIZE = factory.createAttributeDescriptor( "size", Your.class, new NumericTypeMetaData("Size", long.class, UnitsOfMeasure.BYTES, 6)); }
[0147] Metadata are data or information regarding data, for example, data type, field name, length, value restriction, color, and the like. In practice, metadata are used to define the structure and meaning of data objects in tools, databases, applications, and other information processes. The data type metadata 482, 483 encompasses both procedural and declarative information, including (as appropriate for the value) but not limited to the following:
[0148] unit of measure (from the provided unit of measure software object, converters to/from other units are accessible);
[0149] content length;
[0150] default or maximum character length or precision of numbers;
[0151] data quality (a rating given by the provider of the data);
[0152] default value (given by the provider of the data type);
[0153] constraints (e.g., numeric range or list of acceptable values);
[0154] formatting;
[0155] comparator function (a procedure which takes two items of the data type in question and returns whether one is to be ordered before, after, or the same as the other);
[0156] validation function (returns `true` or `false` depending on whether the value for the attribute passes a certain test or set of tests, tests are developer-definable based on an interface which takes a software object providing a value and returns a Boolean value, but several reference implementations are provided, such as one to determine whether a number is within a specified range;
[0157] list of applicable summary (statistical) functions, summary functions are developer-definable based on an interface which takes a collection or array of software objects providing values and returns a single value (usually, but not necessarily of the same type) based on those values, several reference implementations are provided, including mean, standard deviation, count, max, min, median; and
[0158] renderer and editor procedures for different output modalities (examples of modalities include local graphical window, HTML, plain text, and WML).
[0159] A renderer displays a value, while an editor allows the user to enter or edit one; renderers and editors are both developer definable for any modality desired. In the preferred embodiment, renderers and editors for graphical windows, HTML, and plain text are provided.
[0160] In a simple example, a data item may have an attribute called "Manager" (attribute name) 478, 479 that has a value of "John Doe," 480, 481 with metadata type 482, 484 of content length (e.g. "30"), data type ("string"), and default value (""). In another example, a data item may have an attribute called "Cost" 478, 479 that has a value of "5.00" 480, 481 with metadata type of data type ("float"), default value ("0.0"), summary statistics ("true"), validation function ("can never be less than zero"), and the like.
[0161] The Attribute/Metadata interface specifies generic type accessors for object comparing, editing, formatting, rendering, and validation. This displaces the burden from the consumer of the data (INFOBEANs) to the developer of the TypeMetaData. It enables developers to use existing TypeMetaData to create content that is viewable in many forms such as a Swing Component, HTML table, and WML text.
[0162] In one embodiment of the invention, the data consumer components are very generic, requiring little or no Domain-specific knowledge. For example, a data consumer object, for example, which resembles a spreadsheet, displays all available attributes of any data item, regardless of the Domain Policies represented. If useful to this consumer object, the metadata types may provide graphical control components for rendering attribute values. They also may supply editor components that give the end-user a standard way to modify an attribute, e.g., a color chooser GUI for selecting a new color value.
[0163] An input/out metadata class, TypeIO, defines the end content format. The TypeIO class offers flexibility in both the input (editing) and output (rendering) of attributes according to their type. In one embodiment, a TypeIO object is registered for a specific TypeMetaData using a registry, for example, the TypeIORegistry. The registration is performed on the following interface types: HTMLTypeIO, SwingTypeIO, TextTypeIO and WMLTypeIO. Examples of TypeIO are "Swing TypeIO" (for Java standard user interface library called "Swing"), HTML (hypertext markup language), WML (wireless markup language), XML (extensible markup language), and text. Swing is a graphical user interface (GUI) component kit, part of the Java Foundation Classes (JFC) that are integrated into the Java programming language. Swing simplifies deployment of applications by providing a complete set of user-interface elements written entirely in the Java programming language. Swing components permit a customizable look and feel without relying on any specific windowing system.
[0164] Table IV below is exemplary code to register two different TypeIOs for the BooleanTypeMetaData.
4TABLE IV static { TypeIORegistry.registerT- ypeIO(BooleanTypeMetaData.class, SwingTypeIO.class, BooleanSwingTypeIO.class); TypeIORegistry.registerTypeIO(BooleanT- ypeMetaData.class, TextTypeIO.class, BooleanTextTypeIO.class); }
[0165] In one embodiment, the metadata type may be overridden. For example, it is possible to override the editing/rendering capabilities of a TypeMetaData. In one embodiment, a new TypeIO implementation is registered that provides the desired editing and rendering. If a developer only wants to affect the TypeMetaData instance that the developer is using, a subclass must be created and the TypeIO registered with that subclass. Thereafter, any instances of the new subclass will use the specified TypeIO.
[0166] Other features may also be added to the TypeMetaData, such as summary function, min function, max function, and the like. For example, BooleanTypeMetaData adds summary methods for obtaining the total of false and true counts. Exemplary code to perform this modification is listed in Table V below.
5TABLE V static { TypeIORegistry.registerTy- peIO(BooleanTypeMetaData.class, SwingTypeIO.class, BooleanSwingTypeIO.class); TypeIORegistry.registerTypeIO(BooleanT- ypeMetaData.class, TextTypeIO.class, BooleanTextTypeIO.class); } . . . /** * Constructs a <b>BooleanTypeMetaData</b> with <i>name</I> * @param name the type name, returned by getName( ). */ public BooleanTypeMetaData(String name) { super(name); addSummaryFunction(new FalseBooleanSummaryFuncti- on(this)); addSummaryFunction(new TrueBooleanSummaryFunction(this)- ); } . . .
[0167] Methods may also be added to the TypeMetaData interface to provide standard behavior. Constraints may also be specified. Table VI below lists exemplary code to define a StringTypeMetaData called "Threat" with only three valid values ("HOSTILE," "FRIEND," and "NEUTRAL").
6 TABLE VI new StringTypeMetaData("Threat", 3) { { set ValidTest( new DiscreteRange( ) { { add("HOS"); add("FRI"); add("NEU"); } } ); } }
[0168] In one embodiment, an INFOBEAN data consumer is given a data item. The consumer examines the data item and its attributes, and may also access certain Domain attributes or execute Domain methods. If the consumer finds something it can use, the data item is further processed according to that consumer's function. For example, a user might drag a group of data items to an INFOBEAN that displays time relationships. The INFOBEAN would ignore those data items that did not have any appropriate time-related attributes. For those data items that have time-related attributes, the values can be obtained and used to populate a user interface.
[0169] Referring back to FIG. 2, the Domain Definition/Policy interface 202 provides a means for the intended use of an attribute in a data item to be conveyed along with the attribute itself. A domain policy typically comprises a list of attribute types with metadata and a list of function calls applicable to data possessing some or all of the attributes with parameter specifications, annotated with English text expressing the intent (i.e., description of the attribute). It is a group of related attributes (or properties), along with their semantics to usefully deal with data processing those attributes, particularly to define the specific intent of the attribute or method. The semantics are specified in the attribute TypeMetaData and in natural language. Software developers of both sources 102 and consumers of data 122 may refer to a domain policy in making design decisions, thereby ensuring that an attribute is handled in a more sensible manner than the limited self describing capabilities provided by metadata alone would allow. Domain policies indicating intended use of a set of information that are well understood, for example, by experts now may be mapped and aligned so that common features of different sources of data may be combined along common lines.
[0170] A domain policy typically has no knowledge of the data items that use the attributes from those domains or the data consumer components that use them. Domains are just a related collection of Attributes and methods from which the various data item classes are free to choose.
[0171] In one embodiment of the invention, every data item in the framework provides a list of domain policies it "subscribes to" when requested by a standard method call. For example, a geographical domain policy is defined within the framework 100 to handle a set of three numerical values (longitude, latitude, and altitude) to define the position of, for example, an airplane. This domain policy or domain interface is defined in the mediation layer 112 so that the data source component 102 and the data consumer component 122 may interface with each properly. In this scenario, data source component 102 exposes the three numerical values properly (i.e., as latitude, longitude, and latitude). The data consumer component 122, on the other hand, understands this pre-defined domain policy and thus is able to properly handle these three attributes or values, such that, the location of this airplane may be plotted on a map (like the one shown in FIG. 1A), distances between positions calculated, and the like.
[0172] Two or more modules (consumer and source) may subscribe to the same Domain. This, however, does not preclude the modules to be developed independently. A Domain Policy in one embodiment is defined by Java classes that declare a set of attributes and methods that might be supported by a given data item. For example, a temporal domain defines start time and duration as attributes. A timeline may only be properly plotted if such software object understands which attribute represents the start time and which attribute represents the duration or the end time. For this to work in XIS, two classes would need to exist: TemporalDomain and TemporalDomainWrapper. The TemporalDomain class defines the AttributeDescriptors (i.e., attributes) for each domain attribute; and the TemporalDomainWrapper class provides accessor and mutator (get and set) methods for these attributes. The wrapper also may declare one or more domain methods, which can have any signature to be invoked with the data item as the target object. The wrapper is a convenience class for accessing domain attributes, providing optional default values, and invoking domain methods through Java reflection.
[0173] Analyzing any domain yields a list of attributes and methods. Though much like a class definition in form, Domain Policies are supposed to convey and define logically independent characteristics related only by their domain context. It is very important not to fall into the trap of accidentally creating a domain that reflects a particular class or interface, or to add implementation-specific details that have nothing to do with conceptual domains into a given Domain Policy. An application can obtain and manipulate attributes of an object via a domain wrapper instead of accessing the object directly. This eliminates the dependency on the class of the object. An application can now be written with only the knowledge of domains. No prior knowledge of a particular data source is required at development time, only domains.
[0174] In one embodiment, attribute aliases may be used. This enables one attribute to be substituted for another. This is typically used when two domains are defined that have similar attributes. This enables a consumer to ask for the Attribute from the domain that it knows about, and have the value translated from the Attribute of the DSI from the second domain. In one embodiment, the mediation layer implements this in a seamless operation, i.e., either the consumer or provider of the Attributes knows that it was an aliased Attribute, for example, "speed in knots" and "velocity in meters/sec".
[0175] In another embodiment, methods of Domains may be registered with domain method descriptor factories similar to AttributeDescriptors. In this implementation, it enables developers to reference domain methods via these static singletons, determine if domain methods of interest are defined, and to determine all information about the argument types and interpretation of the domain method. Furthermore, like the attribute descriptor factory (AttributeDescriptorFactory), developers pass the necessary ingredients or information to this factory, and the factory handles the internal registration of the method parameter types, return type, exceptions, and interpretation. It ensures that one and only one object in the Java runtime exists for each distinct domain method definition (each unique method signature), similar to attributes and attributes factory.
[0176] FIG. 4 shows a schematic diagram of information that may be exposed by a data item 510 (440 and 452 in FIG. 4). In an embodiment of the present invention, a data item 510 is defined as any unit of information that can be represented by a single object (perhaps containing subobjects) in an object oriented programming (OOP) language and is a coherent unit in terms of the semantics of the content domain that it relates to. Thus, data items are defined within a common semantic representation. Each information element is defined in terms of entities (data source or data consumer component), identity, relationships, attributes (name/value), services (not just data), and change events (dynamic nature).
[0177] For example, a single row in a relational database containing information on a person's name and address constitutes an information element, but so would the table from which it comes, and even the entire database itself. Different levels or granularity of information is useful in the context of different applications, but any one of them can be considered an information element for purposes of our exposition. An example of a noncoherent unit would be a random collection of name/address rows from a database, unless there was some comprehensible unifying characteristic to them (e.g., all rows for addresses in the state of Utah).
[0178] Data items use Domain Policy attributes and methods to express the data item characteristics in a "normalized" manner. That is, a data item may expose Domain Policy methods 512, which are the functions or methods 516, 518, 520 of a particular Domain Policy to characterize the data item's behavior and attributes to characterize the data item's information content. A data item may also expose Domain attributes and metadata. A data item may also be part of more than one Domain Policy, thus a number of Domain methods 512 may be exposed with such data item 510. The Domain methods define the method name, possible input parameters, which may be mutable objects, i.e., input/output parameters, and optional return value. This shows the expected behavior of the method, expectations of the inputs, and return value constraints. The data item may also expose one or more attributes 530 and 538. Each attribute 530, 538 may have an attribute value 534, 542, an attribute descriptor 532, 540 (containing, among other information, an English text description of the attribute), and type metadata 536, 543. The type metadata may include the class type 544 (the class type of the attribute's value) and type input/output 546 (TypeIO, for IO facilities). Examples of class type are LatLonAlt (for latitude, longitude, altitude data), String (string data), Integer (integer data), Date (calendar date), Color, and the like. TypeIO, as discussed above, may indicate the input and output format.
[0179] The Relationships 522, e.g., containment, hierarchies, and ad-hoc relationships, of a particular data item 510 may also be exposed as shown by the data items 524, 526, 528. A data item may have zero (none at all) or may have many data relationships to the other data items via Domain methods and attributes.
[0180] Additional information exposed by a data element is a metadata override, which may be used to override a default behavior of a Domain Policy attribute. For example, default formatting of a date for some Domain Policy may be overridden, from MM-DD format (two digits for month and two digits for date) to "month text string" and DD format. In one embodiment, this may be implemented by assigning different metadata to an attribute using FieldMetaData within the XIS framework.
[0181] User Interface
[0182] FIGS. 6A to 6F are exemplary representations of computer display windows produced by data consumer components 122, which may be developed within the XIS framework 100. These data consumer components may use any data source component 102 for data and may also be run without an associated data source component.
[0183] FIG. 6A shows a computer display window called "Map View 1" produced by a mapping program for an INFOBEAN object that contains vector shoreline data from a data source component to produce the world shoreline depiction in the drawing figure. If an appropriate data source is loaded into this INFOBEAN, then appropriate additional pieces of information will be displayed, e.g., as geographic points on the depicted world map. Appropriate pieces of information for this INFOBEAN may include numeric data, which may, for example, be mapped to a set of latitude, longitude, and altitude coordinates on the map display of FIG. 6A.
[0184] FIGS. 6B to 6D show window displays of a file manager or information exploring component, much like a file system explorer, called "XIS Explorer" with a vertically oriented directory frame on the left side of the window display and two stacked information detail frames on the right side. The directory frame on the left may provide a tree diagram of available DSI components and their relationships to other components. FIG. 6B shows that the Explorer View display does not contain any data (the "Explorer Contents" menu is empty). FIG. 6C shows the XIS Explorer program after it is loaded with data called "Orders", "Computer", and "People Source" data sources, with "People Source" selected. Detail information about the People Source data is shown in the two stacked right frames. The upper right frame shows a listing of data objects or entries in the People Source data source, and the lower right frame shows attributes of a particular data object in People Source. A different set of data objects or records is shown in FIG. 6D, this time for the "Orders" data file. That is, FIG. 6D corresponds to the FIG. 6B di