Computer implemented virtual sensor object and tangible medium utilizing same6697879Abstract A computer implemented Virtual Sensor Object includes an abstract class of Objects, and an actual software instantiation of which performs an abstract observation, evaluation, and expression method in either a static, a synchronous, or an asynchronous Form. The evaluation method of the Virtual Sensor Object allows the substantive meaning of the observations to be expressed in a Form which clarifies the Substance of the observations, so that the substantive meaning of the observations may be perceived directly, with little or no cognitive interpretation being required. The methods of expression and evaluation are dependent on the observation, whereas they are independent as to how they use and express meaning. Claims We claim: Description TECHNICAL FIELD
Abstract Class Substantive Extension
ObservationMethod.class om_.class
ExpressionMethod.class xm_.class
EvaluationMethod.class em_.class
RenderingMethod.class rm_.class
With this logical architecture of Form for the Sensor.class Objects, we now address the issues of the Substance of the internal mechanics, as Object-oriented programming language specifications, and the Form of the external interface in a tangible medium, as the Form of a canonical Window GUI. The following sections detail the Form and Substance of the Objects which are created as components of, and interact with, the Sensor.class of Objects. The Internal Substance--ObservationMethod.class Objects In FIG. 2, we see a Sensor.class Object 2-1, which contains Object Instance Variables 2-2 and Object Instance Methods 2-3, and a typical om_.class extension Object 2-4 for the substantive creation of an ObservationMethod.class Object, which, of course, likewise contains distinct Object Instance Variables 2-5 and Object Instance Methods 2-6. In the Object Instance Variables 2-2 in FIG. 2, we note that a declaration of a reference name, for an instance of the abstract Object class, ObservationMethod.class, is declared along with a reference name for an Object instance of the ObservationReadings.class. The actual Object instances will be created as an om_.class Object 2-4 and as an or_.class Object 3-9 or 3-12, respectively. As specific instances relate to specific problems being addressed, the om_.class is in a unique position and situation to know and implement exactly the standard variable and algorithms required to observe variable digital information as if it emanated from a sensor device. Several such om_.class Objects have been implemented for ASCII file access and support various timestamp, numeric, graphic, Decimal Value, and other MIME formats, with a standard algorithm for merging and reconciling the various TimeLines with respect to other Virtual Sensors at a client Site. Specific DataBase access om_.class Objects must be specifically programmed on a case by case basis. Standard Software interfaces may be supplied by sensor manufactures to serve as the Substance of such Objects. As such, the om_.class Object 2-4 in FIG. 2, allocates and specifies the format and content of the digital information, whether it represents textual, numeric, graphic, caloric, auditory, etc. information. Thus, the or_.class, Object 3-9 or 3-12 of the Sensor.class Object 2411 is in fact created by the om class Object 2-4 during the construction. In other words, when a Sensor.class Object 2-1 is being constructed, it is only necessary to create an om_.class Object 2-4, as depicted by the line from the omObject declaration 2-2 to the Object instance thereof 2-4, whereas an appropriate or_.class Object will be automatically created, based on the requirements of the om_.class Object, as depicted by the line from the om_( ) Constructor Method 2-6 to the Readings declaration 2-2. The Internal Substance--ObservationReadings.class Objects In FIG. 3, two examples of specific or_.class extension Objects are depicted 3-9, 3-12, along with their relationship to the GetReading( ) Method 3-3 of a Sensor.class Object 3-1. Each of the Sensor.class Object 3-1, the ObservationReadings.class Object 3-4, the first example or_.class Object 3-9, and the second or_.class Object 3-12, have their own, distinct Object Instance Variables 3-2, 3-5, 3-10, 3-13 and Object Instance Methods 3-3, 3-6, 3-11, 3-14, respectively. The relationship of substantive extension between the ObservationReadings.class Object 3-4 and the example or_.class extension Objects is represented by the pairs of connecting lines indicated as 3-7 and 3-8. In general only the storage type and number of elements will vary from one specific or_.class 3-9, 3-12 to another: the reference names and indexing requirements will be independent of the storage type and number of elements considerations. Further, the ObservationMethod.class Object 3-4 in FIG. 3 must support the acquisition of digital information in either a Static Mode, whereby all digital information is received from an archive or DataBase system in an orderly manner, or in an Dynamic Mode, whereby an observation is periodically obtained in real-time by an independent Sensor device. The GetReading( ) Method 3-3 presents the;,two possibilities for having a specific observation reading returned by the Method. In FIG. 3, for digital information which is to interpreted as numeric, the or_.class Object 3-9 is merely an abstract formalization of a dynamically a allocated array of integers into a Class which stores information in an arbitrary structure, such as a minimally allocated array of integers. This is suggested by the declaration of an array of integers which is referenced by the name Moments 3-10. The Moments 3-10 array is two dimensional to allow indexing by a moment index and a reading value index, for cases in which a sensor probe may return multiple values for a single reading moment. The reading value index will also serve as a parameter which is referenced from within the ExpressionMethod.class Object 6-4, in order to specify the origin of the reading value which is being evaluated. By formal analogy, the or_.class Object 3-12 for a series of graphic images, which are continuously refreshed by a Device Driver, require only a single instance declaration of an image.class Object 3-13. Additional declarations may be made, as needed, to implement standard techniques such as "double buffering" to eliminate any "flicker effects" that may occur during animation on certain platforms and expression devices. In the first example or_.class Object 3-9 in FIG. 3, the digital information of the observed readings is represented by an array of ItemCount integer values 3-10. Further, the first example 3-9, deals with the Static Mode of observation and further declares the storage to contain a TimeLineCount number of such arrays of readings 3-10. Accordingly these storage elements may be referenced by the variable name of Moments 3-10. Note well that the ItemCount and TimeLineCount variables may be dynamically assigned their values by the om_( ) Constructor Method 2-6. In the second example or_.class Object 3-12 in FIG. 3, the digital information of the observed readings is represented by a bitmap graphic image 3-13. Further, the second example 3-12, deals with the Dynamic Mode of observation and requires only the current reading to be available at any time. Accordingly this storage element may be referenced by the variable name of Current 3-13. The Internal Substance--Static Mode ObservationMethod.class Objects FIG. 4 provides the example of an ObservationMethod.class Object 4-1 which is extended by the Substance of a Static Mode om_.class extension Object 4-5. Each of the ObservationMethod.class Object 1 and the om_.class Object 4-5 have their own, distinct Object Instance Variables 4-2, 4-6 and Object Instance Methods 4-3, 4-7 respectively. The relationship of substantive extension between the ObservationMethod.class Object 4-1 and the example om_.class extension Object 4-5 is represented by a connecting line 4-4. In FIG. 4, the parameter list of the Initialize( ) Method 4-3 specifies a unique Virtual Sensor identification index, sInx, an abstract ListBox Object, sLog, and an abstract Label Object, lTag. The formal abstract Window Objects may be instantiated by any standard Abstract Windows Toolkit (AWT) platform implementation, and thus, allow display of the activity of the Initialize( ) Method 4-3 on said platform via actual abstract Window Objects. Note that for a Static Mode om_.class extension Object 4-5, a conformal or_.class Object 3-9 acts as a table structure of all readings for the period of moments which are downloaded in bulk, or may be possibly staged for refresh. For a Static Mode ObservationMethod.class Object, the Initialize( ) Method 4-3 in FIG. 4, of the Virtual Sensor performs certain housekeeping chores concerned with accessing the digital information which is available via the specification of a Universal Resource Locator (URL) and appended parameter information. There are two general "bulk access" programming approaches for obtaining the digital, information associated with an observation: ASCII file access and generic Data Base access. The resource indicated by a URL may represent either content or intent, in conformity with the Form of said Boolean Arithmetic. In the case of content, the ASCII information is provided directly as a data stream to be parsed and interpreted. In the case of intent, the URL indicates a resource to be executed with the intent that the execution will produce a data stream to be parsed and interpreted. The execution of the intent may involve any data base capabilities which are inherent in the host system of the URL. In the case of data base access, it will be useful to specify an observation period and qualifier to specify the period of readings of interest, see FIG. 13. Generally, the observation period and qualifier will be used to construct the URL and data selection specifications with respect to the client Site. Once communication with the URL has been established, the Initialize( ) Method 413 will invoke the execution of the GetBulkReadings( ) Method of the om_.class extension Object, and then terminate. In FIG. 4, the GetBulkReadings( ) Method 4-7 performs read-store logic on a per record basis to implement a "bulk-download" Method to observe a complete period set of readings as a single, complete event. The "bulk download" process loops repeated to read, and store, the observed digital information into the ObservationReadings.class Object 3-9, until all the digital information has been read and stored. The URL communication is then terminated. While the present invention utilizes certain specific access methods, it should be noted that any standard access method for accessing data from a data base or file may be utilized for retrieving the data to perform the data observation. However, the specific access methods which are utilized in the present invention are organized with respect to particular timestamp, numeric, graphic, and other Multi-purpose Internet Mail Extension (MIME) format characteristics which facilitate the retrieval and transmission of this data for receipt by the ObservationMethod.class Object. Note that the Initialize( ) Method 4-3 may be invoked either once the User has specified an observation period and qualifier, either via the Site Control Window Menubar, see FIG. 13, or may be invoked via an "AutoLoad" run-time parameter (HTML <Applet> Tag, etc), when a SensiView.class Site Control Window is created. The Internal Substance--Dynamic Mode ObservationMethod.class Objects FIG. 5 provides the example of an ObservationMethod.class Object 5-1 which is extended by the Substance of a Dynamic Mode om_.class extension Object 5-5. Each of the ObservationMethod.class Object 5-1 and the om_.class Object 5-5 have their own, distinct Object Instance Variables 5-2, 5-6 and Object Instance Methods 5-3, 5-7 respectively. The relationship of substantive extension between the ObservationMethod.class Object 5-1 and the example om_.class extension Object 5-5 is represented by a connecting line 5-4. In FIG. 5, the parameter list of the Initialize( ) Method 5-3 specifies a unique Virtual Sensor identification index, sinx, an abstract ListBox Object, sLog, and an abstract Label Object, lTag. The formal abstract Window Objects may be instantiated by any standard Abstract Windows Toolkit (AWT) platform implementation, and thus, allow display of the activity of the Initialize( ) Method 5-3 on said platform via actual abstract Window Objects. Note that for a Static Mode om_.class extension Object 5-5, a conformal or_.class Object 5-3, 5-12 acts as a holding area for the Current ("now" ) reading moment. A real-time access om_.class Object 5-5 must be specifically programmed on a case by case basis and address either an "immediate return" Synchronous Sensor Device Driver or an "interrupt generating" Asynchronous Sensor Device Driver. Software interfaces may be supplied by sensor manufacturers to serve as the foundations for such om_.class extension Objects 5-5. Whereas a Sensor Device Driver may operate in a Synchronous or an Asynchronous manner, the om_.class extensionObject 5-5 will be implemented tot either poll, in a synchronous manner, a "ready" flag which indicates the presence of a new reading, or respond to, in an asynchronous manner, an interrupt event when it is detected on the I/O port which is utilized by the Device Driver. For a Dynamic Mode ObservationMethod.class Object, the Initialize( ) Method 5-3 in FIG. 5, of the Virtual Sensor performs certain housekeeping chores with respect to the client Site and activating the Sensor Device Driver. The Initialize( ) Method 5-3 will perform standard tasks that are required to establish communication with the physical observation Device Driver.software, as provided by the manufactures of the physical observation sensor probes and devices. Once the Sensor Device Driver is ready to respond to requests for readings, the Initialize( ) Method 5-3 will create a omTimeThread.class Object, and then terminate. In turn, the TimeThread.class Object will periodically invoke the TimeThreadCallback( ) Method 5-7 of the om_.class extension Object. For an Asynchronous Dynamic Mode ObservationMethod.class Object, the creation of such a omTimeThread.class object is unnecessary since the TimeThreadCallback( ) Method 5-7 will be invoked asynchronously via the HandleEvent( ) Method of the ObservationMethod.class Object 5-1, when an asynchronous event generated by the Device Driver is received. The asynchronous sensor Device Driver reading event must be immediately handled via the HandleEvent( ) Method of the ObservationMethod.class Object, in order to dignify the Current nature of the reading and to refresh the reading of the current moment, "now". In either case, the Dynamic Mode operation will occasionally invoke the execution of the TimeThreadCallback( ) Method 5-7 of the om_.class extension Object. The TimeThreadCallback( ) Method 5-7, in turn, will perform any necessary Device Driver housekeeping chores, then parse and store the digital information of the reading. Note that the Initialize( ) Method 5-3 may be invoked either via the Site Control Window Menubar, see FIG. 13, or may be invoked via an "AutoLoad" run-time parameter (HTML <Applet> Tag, etc), when a SensiView.class Site Control Window is created. The Internal Substance--ExpressionMethod.class Objects The design intently of the ExpressionMethod.class Object is to allow multiple sensory expressions to combine as a single expression of normalcy, or deviation therefrom. Towards this end, we have determined that an ExpressionMethod.class Object must support a list of pairs of: EvaluationMethod.class RenderingMethod.class Objects, where each such pair of evaluation-rendering methods results in an expression for rendition on the target expression device. FIG. 6 provides the example of a Sensor.class Object 6-1 and the associated ExpressionMethod.class Object 6-4 which is extended by the Substance of a xm_.class extension Object 6-8. Each of the Sensor.class Object 61, the ExpressionMethod.class Object 6-4 and the xm_.class Object 6-8 have their own, distinct Object Instance Variables 6-2, 6-5, 6-9 and Object Instance Methods; 6-3, 6-6, 6-10, respectively. The relationship of substantive extension between the ExpressionMethod.class Object 6-4 and the example xm_.class extension Object 6-8 is represented by a connecting line 6-7. The Figure depicts the creation of the component EvaluationMethod.class Objects, RenderingMethod.class Objects, and other Objects which constitute the ExpressionMethod.class Object. The ExpressionMethod.class Object 6-4 is one of the abstract component Object Classes of the Virtual Sensor, and is always instantiated by an "xm_.class" Object. In FIG. 6, the declaration of a reference name 6-2, xmObject, is made and instantiated for an ExpressionMethod.class Object 6-4 by the creation of an "xm_.class" Object 6-8. The creation of the xm_.class Object 6-8, is achieved by invocation of the xm_( ) Constructor Method 6-10 of the xm_.class Object 6-8. As such, the xm_.class Object 6-8, is in a unique position and situation to specifically define and configure the components and parameters of the expression to be rendered. Specifically, the xm_( ) Constructor Method 6-will specify the number of symbols 6-5 which comprise the complete expressions, and will also create the arrays for the EvaluationMethod.class Object and RenderingMethod.class Object pairs which generate each such expression symbol 6-5. In addition, the xm_( ) Constructor Method 6-10 will also create a formal abstract CheckboxMenuItem Object, which may be instantiated by any standard Abstract Windows Toolkit (AWT) platform implementation, to allow GUI control of the Virtual Sensor expression. Finally, an ExpressionParams.class Object, MediaContext 6-2, is created and assigned any particular Expression Device parameters which may be necessary for the effective utilization of the l Expression Device by the RenderingMethod.class Objects 6-5 involved. FIG. 7 provides the example of a Sensor.class Object 7-1 and the associated ExpressionMethod.class Object 7-4. Each of the Sensor.class Object 7-1 and the ExpressionMethod.class Object 7-4 have their own, distinct Object Instance Variables 7-2, 7-5 and Object Instance Methods 7-3, 7-6, respectively. The Figure depicts a conventional logic flowchart and Object-oriented programming code of the RenderSensorExpression( ) Method 7-6, and its relationship to the Express( ) Method 7-3 of the Sensor.class Object 7-1. The intent of the RenderSensorExpression( ) Method 7-6 is to express the normality, or lack thereof, of the readings obtained from the GetReading( ) Method 3-3 of the parent Sensor.class Object 7-1. It should be noted that for each RenderingMethod.class Object, it is always possible to construct a so-called "Identity" ExpressionMethod.class Object for the RenderingMethod.class Object, by pairing the RenderingMethod.class Object with the "Null" EvaluationMethod.class Object, so as to form a single pair rendering expression. For all such "Identity" ExpressionMethod.class Objects, the rendering will be directly, immediately, and exactly determined by the observation readings. In FIG. 7, it is assumed that whatever GUI, or other CyberSpace Object, which invokes the execution of the Express( ) Method 7-3 of a Sensor.class Object, will also provide a Device Object 7-3, as a parameter to the Method, which may serve as the target Expression Device on which to render the Expression of the Virtual Sensor Object 7-1. In turn, the Express( ) Method 7-3 invokes the execution of the RenderSensorExpression( ) Method 7-6, likewise passing the Device Object 7-3, as a parameter. The execution of the RenderSensorExpression( ) Method 7-6 in FIG. 7 begins by counting against the number of symbol renderings which comprise the complete expression and exiting when all the symbols have been rendered. When a symbol remains to be expressed, a check is made against the DisplayControl CheckboxMenuItem Object and determines if the symbol should be rendered or ignored. If it is to be ignored, then the counting is advanced to the next possible symbol and the looping continued until exit, is achieved. Otherwise, the EvaluationMethod.class Object and the RenderingMethod.class Object for the current symbol count are obtained as the Evaluator and Renderer Objects, respectively. Other such temporary storage variables, ObservationReadings orObject; Reading Observed; and DeviationStatistic Deviations; are likewise declared for processing convenience and clarity. Then the GetReading( ) Method 3-3 of the Sensor.class Object 7-1 is invoked to obtain then currently specified moment of digital information reading and the ReadingsIndex element 7-6 of the ObservationReadings Object is taken as the observed digital information which contains a substantive meaning to be expressed. The specific Reading is then passed to emDeviation( ) Method of the Evaluator Object to obtain the Deviations associated with the Reading. Finally, the Deviations are passed as parameters, along with the target Expression Device, to the RenderSensorExpression( ) Method which then expresses an appropriate symbol on the Expression Device. Then the counting is advanced to the next possible symbol and the looping continued until exit is achieved. The Internal Substance--EvaluationMethod.class Objects FIG. 8 provides the example of an EvaluationMethod.class Object 8-1 which is extended by the Substance of a em_.class extension Object 8-5. Each of the EvaluationMethod.class Object 8-1 and the em_.class Object 8-5 have their own, distinct Object Instance Variables 8-2, 8-6 and Object Instance Methods 8-3, 8-7 respectively. The relationship of substantive extension between the EvaluationMethod.class Object 8-4 and the em_.class extension Object 8-5 is represented by a connecting line 8-4. It is the function of the EvaluationMethod.class Object 8-1 to support an emDeviation( ) Method 8-7a which will evaluate an Observed Reading, as a parameter, against a range of normal values and the degrees of deviation from the normal range. The deviation information is typically returned from the Method via a DeviationStatistic.class Object 8-7b. Likewise, an emAverage( ) Method 8-7c will yield the average, expected value for said range of normal values. There are two specific em_.class extension Classes 8-5 of interest: emIdentity.class the "Null" EvaluationMethod.class, and emRangeDialog.class the "Dynamic Range" EvaluationMethod.class. The emIdentity.class provides no transformative activity on the Observed Reading parameter 8-7a which is passed to the emDeviation( ) Method 8-7a of the said Class, whereas the DeviationStatistic 8-7b will be constructed to return exactly the Observed Reading parameter 8-7a which was passed in for evaluation. This is a recrossing of the distinction between a dimensional and a statistical entity and conforms to the Form of the said Boolean Arithmetic. The emRangeDialog.class provides a dynamically configurable range of deviation values via a "Deviation Range Specification Dialog" Object that supports a dynamically configurable range of deviation values against a quantified dimensional scale. The Internal Substance--RenderingMethod.class Objects FIG. 9 provides the example of a RenderingMethod.class Object 9-1 which is extended by the Substance of a rm_.class extension Object 9-5. Each of the RenderingMethod.class Object 9-1 and the rm_.class Object 9-5 have their own, distinct Object Instance Variables 9-2, 9-6 and Object Instance Methods 9-3, 9-7 respectively The relationship of substantive extension between the RenderingMethod.class Object 9-4 and the rm_.class extension Object 9-5 is represented by a connecting line 9-4. It is the function of the RenderingMethod.class Object 9-1 to support a RenderSensorSymbol( ) Method 9-7 which will render an appropriate symbol on an Expression Device, Device, for a DeviationStatistic.class Object. A Graphics Device is always available in the context of a GUI and this leads to a discussion of the features available in any standard Abstract Windows ToolKit (AWT) for the construction of geometric shapes and graphic images. We have determined several natural symbols for expressing abnormalities and deviations, which have been implemented as rm_.class extension Objects 9-5. The typical rm_.Class extension may also support a RenderingParms.class Object for each invocation of the effective Method, which are controlled at the parent ExpressionMethod.class Object 6-4. The Internal Substance--Conclusion This completes the construction of the Virtual Sensor Object as an instance of the Sensor.class. Aside from the Log ListBox and Status Label pair of Abstract Window Toolkit Control Objects, passed as parameters to the ObservationMethod.class Methods, there are no Graphic User Interface elements used within the Virtual Sensor Object. Thus, we begin the construction of a fully parameterized Graphic User Interface to provide an End-User friendly form of interaction with the features and benefits of a Virtual Sensor. At each stage of the following constructional, standard conventions and practices concerning the Forms of rendering and design of GUI layouts and elements will be observed as canons for the construction for the GUI, and thus it will exist as a canonical GUI Window. The External Form--A Site of Virtual Sensors It is a natural extension of the Virtual Sensor Object to also provide a Graphic User Interface (GUI) which supports a fully parameterized implementation of all possible functional invocations of the Class Methods. Further, such a Graphic User Interface will necessarily and immediately provide a Graphic Device for the expression of visual renderings, and will serve as a default Expression Device for the Sensor.class of Objects. If we consider a set of Virtual Sensor Objects with respect to some reference system, or client Site, within CyberSpace, two distinct levels of management must be addressed. Firstly, there is a level of management which deals with how the Virtual Sensor Objects are individually configured. Each Virtual Sensor Object, as a CyberSpace Object instance of the Sensor.class, may exist in a persistent Form, which may be loaded and executed directly; or, may exist in the potential Form of a ASCII text file, which provides the construction specifications for a Sensor.class Object. As such, a SiteProfile.class Object declares and instantiates the Virtual Sensor Objects that exist with respect to the Graphic Images of the client Site, along with various Instance Variables for processing control, definition, and expression. However, it is pointless to further discuss the configuration of an individual Virtual Sensor Object until a frame of reference, i.e., a SiteProfile.class Object has been established, which is the next logical topic of discussion. Thus, the configuration of an individual Virtual Sensor Object will be addressed in the later discussion of the Edit Mode Menu Item of the Click Menu (FIG. 19). For the current discussion, it is therefore assumed that each Virtual Sensor Object is well defined and configured with respect to the client Site. Secondly, there is a level of management which deals with a well defined collection of Virtual Sensor Objects with respect to a specific client Site. In addition to the Virtual Sensor Objects, there are Graphic Images and other means 6f expression which may require specification by the client and, hence, must be specified by the SiteProfile.class Object for the client Site. As a CyberSpace Object, each SiteProfile.class Object may exist in a persistent Form, which may be loaded and executed directly; or, may exist in the potential Form of a ASCII text file, which provides the construction specifications for a SiteProfile.class Object. As such, this is analogous to their, management of a collection of documents, and a standard solution is provided by a conventional series of New . . . Open . . . Save . . . Save As . . . Close Menu Items within a File Menu, which in this context, is more appropriately called a Site Menu. Each of the SiteProfile.class Objects and Sensor.class Objects may be managed with such a Site Menu or Sensor Menu solution of Menu Items. An extension of this solution is the implementation of Persistence for the Virtual Sensor, SiteProfile.class and ObservationReadings.class Objects, which may then be referenced by their respective URLs. Such persistent Objects may be loaded for immediate execution, as needed, by either the host platform of the CyberSpace Objects, or, programmatically from within the Sensor.class Object via an invocation of a ClassLoad( ) Method. A ClassLoad( ) Method implements the recrossing of the distinction between the content and intent of a series of distinctions, and conforms to the Form of the said Boolean Arithmetic. FIG. 10 provides an example of a SiteProfile.class Object 10-1 which has its own, distinct Object Instance Variables 10-2 and Object Instance Methods 10-3, respectively. A standard ASCII text file may serve as a Site Definition Parameters File 10-4. Note that the SiteProfile.class Object 10-1 declares a reference array, SensorDevice[ ] 10-21 of Virtual Sensor Objects, as instances of the Sensor.class of Objects. This is the collection of Virtual Sensor Objects which will later be referenced, by a svTimeThread.class Object of the parent SensiView.class Object, to drive their observation-expression cycle sequence over time (FIG. 14). In FIG. 10, the PrepareSiteProfile( ) Method 10-3 illustrates the ability of a Persistent Object to indicate that it was previously loaded, and is not being created as a new instance, so exit is achieved. However, if a new instance is being created, then the Substance of the Object must be obtained from an ASCII text file 10-4, of construction specifications, as the content of the file. In such a case, the construction specifications are read in from the URL data stream of the Site Definition Parameters File 10-4 and stored into standard private memory, for subsequent reference by other Methods of the Class, as the Sensor Definition Parameter Variables 10-2, and exit is achieved. Once the Sensor Definition Parameter Variables 10-2 in FIG. 10, have been instantiated, the PrepareSiteSensors( ) Method 10-3 may be invoked to complete the instantiation of the Sensor.class Objects for the Site. It is assumed that a parent SensiView.class Object maintains a current and previous copy of the most recently used SiteProfile.class Objects 10-1. The previous SiteProfile.class Object 10-1 is passed as the LastSite parameter to the PrepareSiteSensors( ) Method 10-3. This allows any previously instantiated Sensor.class Objects to be reused from the previous SiteProfile.class Objects 10-1. Otherwise, the SensorDevice[ ] array 10-2 element instance of a Sensor.class Object is explicitly constructed according to the Sensor Definition Parameter Variables 10-2. This looping continues until all SensorDevice [ ] array 10-2 elements have been instantiated for the current Site. The External Form--Viewing Client Sites Once the Form and Substance of a client Site of Virtual Sensor Objects has been expressed and defined, we have determined that the Graphic User Interface should have a Form of interaction, operation, and control that is analogous to that of a conventional media player, such as an Audio Tape, Compact Disk, or Video Cassette Player, with a like set of controls for the sequential, chronological rendition of recorded information. In this role, a SensiView.class Object provides a Site Control Window as a means for managing and expressing a set of Virtual Sensor Objects, in the Form of a SiteProfile.class Object, with respect to a client Site, where the Virtual Sensor Objects are conceptually or actually located. The SensiView.class Object is a management shell Window Object for a graphics device and any other expression devices which may be used to render the expression of the Virtual Sensor Objects. This Object is intended to support audio, thermal, motion, general device control renderings, and other sensory expressions. Access of a SiteProfile.class Object by the SensiView.class Object is always indicated by the presence of a SensorsCanvas.class Object which implements a general graphics Device that responds to mouse clicks which occur over an assigned Virtual Sensor location, relative to the graphic canvas and is complete. The SensorsCanvas.class Object displays the Graphic Image for the client Site and the expression of the Virtual Sensors indicated by the currently accessed SiteProfile.class Object. FIG. 11 depicts User interaction with the Site Control Window 11-1 of a SensiView.class Object to create an entirely new SiteProfile.class Object without Substance, and the associated SensorCanvas.class Object which acts as the Site Window Object 11-4. Note how a, SiteProfile.class Object without Substance is manifest as a Site Window Object 11-4 with a blank image and no Virtual Sensor Objects indicated. The Site Control Window 11-1 is a graphic rendering of the external visual manifestation of a SensiView.class Object as a standard CyberSpace Window, and its implemented MenuBar and assorted ScrollBar, Button, TextField, and other Abstract Windows ToolKit Control Objects. Specifically, the New Menu Item 11-2 of the Site Menu is selected to initiate a Site specification dialog 11-3 of User interaction, for creating an entirely new instance of a SiteProfile.class Object. Once a client Site Title, Graphic Image URLs, and ClassLoad( ) Method Directory Paths have been typed in to the respective fields, and the OK button is clicked, an entirely new SiteProfile.class Object without Substance, and the associated Site Window Object 11-4 are created. FIG. 12 depicts User interaction with the Site Control Window 12-1 of a SensiView.class Object to open an existing SiteProfile.class Object, and the associated SensorCanvas.class Object which acts as the Site Window Object 12-4. The Site Control Window 12-1 is a graphic rendering of the external visual manifestation of a SensiView.class Object as a standard CyberSpace Window, and its implemented MenuBar and assorted ScrollBar, Button, TextField, and other Abstract Windows ToolKit Control Objects. Specifically, the Open Menu Item 12-2 of the Site Menu is selected to initiate a Site open dialog 12-3 of User interaction to specify an instance of a SiteProfile.class Object. Once a URL has been typed in to the respective field, and the OK button is clicked, the specified SiteProfile.class Object is instantiated and the associated Site Window Object 12-4 will display the Graphic Image for the client Site, as specified by the current SiteProfile.class Object. In this case, the SiteProfile.class indicates a Graphic Image which depicts the architectural schematic of a pair of gateway towers. The External Form--Static Mode Observation Periods In a practical sense, all observations are made during a specific moment of time, with respect to an arbitrary qualifier. Thus, for a Static Mode ObservationMethod.class Object, it is appropriate and useful to allow the User to specify a generalized ObservationPeriod.class Object. FIG. 13 is a graphic rendering of a SensiView.class Object 13-1, with the Specific Menu Item 13-2 of the Readings Menu selected to define an ObservationPeriod.class Object 13-5 via a PeriodDialog.class Object, which enjoys the external Form of an Observation Period Specification Window Object 13-3. The ObservationPeriod.class Object 13-5 of a Sensor.class Object 13-4 governs what digital information may be referenced by a URL either at a remote host or on the local platform environment. The SetObservationPeriod( ) Method 13-6 of a Sensor.class Object 13-4 is used to assign the individual ObservationPeriod.class Interval Object 13-5 for the Sensor.class Object 13-4. The digital information may represent any actual or virtual observation, and may exist in any format which may be expressed. In as much as the digital information represents a sequence in time, it is always appropriate to specify a period of time with a specific "From" starting instant, and a specific "Thru", meaning "to and including", ending instant, as provided in the Observation Period Specification Window Object 13-3. Further in FIG. 13, the Observation Period Specification Window Object 13-3 allows the entry of a so-called "Observation Qualifier" which is used to indicate a particular subset of a complete set of digital information which may exist at the client Site. Such an Observation Qualifier may appear, to a User at a client Site, as merely a "Set Id", or, alternatively, it may embody the complexity of a DataBase selection criteria. SensiView cannot anticipate all the possible client data base and file structures which a client may employ to organize and archive their digital information. However, in all cases, SensiView,can provide an Observation Period Specification Window Object 13-3 to allow the User to specify a period of time and an Observation Qualifier, for reference by any ObservationMethod.class Object which loads selected readings. The fact, that ObservationPeriod.class Objects 13-5, in FIG. 13, exist on a per Sensor.class Object 13-4 basis, indicates that a distinct TimeLine, consisting of the ordered TimeStamps indicating the respective moments of the readings selected for a qualified observation period, exists for each given Virtual Sensor. As such, the period of time "From" the starting instant "Thru" the ending instant may be arbitrarily subdivided into mutually exclusive "Moments" within the period. Standard interpolation and morphing techniques may be applied to achieve a uniform distribution of data readings within an observation period, with respect to the other observation periods within a client Site. Of course, for a Dynamic Mode ObservationMethod.class Object, it is unnecessary to specify a qualified observation period of time because the current moment of the current period of time, in a Dynamic Mode of observation and conscious experience, is always "now" and "here". The External Form--The SensiView Time Thread Object FIG. 14 include's a graphic rendering of the external Form of a SensiView.class Object as a Site Control Window 14-1, with the Play Button 14-7 indicated to signify the animation feature of the SensiView.class Object. The svTimeThread.class Object 14-16 is informally represented to clarify the cyclical and chronological nature of the Object. A Site collection of Virtual Sensor Objects 14-17, 14-18, 14-19, 14-20 are seen as autonomous Objects, whose expression 14-21, 14-22 is driven by the svTimeThread.class Object 14-16. Items 14-2 thru 14-15 constitute the AWT Control Objects which serve as the GUI. Specifically, the Stop button control Object 14-9, causes any active animation activity to cease by resetting a control variable in the svTimeThread.class Object 14-16. The Rewind button 14-5, causes the current moment of animation activity to be reset to the beginning of the current qualified observation period, when animation is ceased. Likewise, the -1 button 14-6 and the +1 button 14-8, causes the current moment of animation activity to be advanced or retreated one moment, when animation is ceased. At any time, the Lower 14-11 and Upper 14-13 buttons may be clicked to record the index of the current moment immediately above the respective button as 14-10 and 14-12. The svTimeThread.class Object 14-16 is constructed so as to indefinitely repeat and cycle through the observation period as restricted by the Lower and Upper values 14-10, 14-12 so indicated. The Scrollbar 14-4 provides a convenient mechanism for quickly moving to an arbitrary moment among the moments of the current qualified observation period. A click on either of the step arrows of the Scrollbar 14-4 will cause an advance or retreat of "Scroll Step" moments 14-15, when animation is ceased. The animation frame rate 14-14 is specified as moments per second. The text label areas 14-2, 14-3 are used to display current moment information and various status information. In FIG. 14, the substantive logic of the svTimeThread.class Object 14-16 is informally presented as a flowchart of the Callback Method that is driven by the TimeThread. Repeatedly, after pausing a fixed period of time corresponding to the animation frame rate 14-14, the Callback Method will invoke the GetReading( ) and Express( ) Methods of each Virtual Sensor 14-17, 14-18, 14-19, 14-20, with respect to a Graphic Image of the Site location of the Virtual Sensors. Prior to the expression of the Virtual Sensor 14-17, 14-18, 14-19, 14-20, the CallBack Method 14-16 will perform any required initialization or buffering of the Expression Device 14-22 via the Expression Device Driver Interface 14-21. Once the expression is completed, the moment index is incremented, with respect to the Upper 14-12 and Lower 14-10 limits, and animation continues indefinitely. While the animation of the svTimeThread.class Object 14-16 and the Site Window 12-4 present a wealth of visual insight over time, it is occasionally desirable to focus on the readings of a specific moment. In such case, the User clicks on the Stop button 14-9 of the Site Control Window 14-1 and then clicks on the location of the Virtual Sensor of interest within the Site Window 12-4. The selection of the Click Menu Item (FIGS. 15, 16, 17, 18, 19) determines the subsequent action. The External Form--The Click Current Menu Item FIG. 15 depicts User interaction, via a standard Mouse Device 15-5, with the Site Window 15-6 of the SensorCanvas.class Object of the Site Control Window 15-1 of a SensiView.class Object, when the Current Menu Item of the Click Menu 15-4 is selected to enable the display of the current moment 15-2 of reading values 15-3 for the Virtual Sensor whose location is clicked 15-5 within the Site Window 15-6. The implementation of this feature is achieved via the HandleEvent( ) Method of the SensorCanvas.class Object processing Mouse Device events, so as to display the numeric values 15-3 associated with the current moment 15-3 of ObservationReadings Readings 2-2, when a click event is detected over the location of the respective Virtual Sensor with respect to the Site Graphic Image. The External Form--The Click Digital Menu Item FIG. 16 depicts User interaction, via a standard Mouse Device 16-5, with the Site Window 16-6 of the SensorCanvas.class Object of the Site Control Window 16-1 of a SensiView.class Object, when the Digital Menu Item of the Click Menu 16-4 is selected to enable the digital display 16-3 of all moments 16-7 of reading values 2-2 for the Virtual Sensor whose location is clicked 16-5 within the Site Window 16-6. The implementation of this feature is achieved via the HandleEvent( ) Method of the SensorCanvas.class Object processing Mouse Device events, so as to display all moments 16-7 of the reading values of the ObservationReadings Readings 2-2, when a click event is detected over the location of the respective Virtual Sensor with respect to the Site Graphic Image. The External Form--The Click Graph Menu Item FIG. 17 depicts User interaction, via a standard Mouse Device 17-5, with the Site Window 17-6 of the SensorCanvas.class Object of the Site Control Window 17-1 of a SensiView.class Object, when the Graph Menu Item of the Click Menu 17-4 is selected to enable the graphic charting 17-3 of all moments 17-7 of reading values 2-2 for the Virtual Sensor whose location is clicked 17-5 within the Site Window 17-6. The implementation of this feature is achieved via the HandleEvent( ) Method of the SensorCanvas.class Object processing Mouse Device events, so as to graphical chart all moments 17-7 off the reading values of the ObservationReadings Readings 2-2, when a click event is detected over the location of the respective Virtual Sensor with respect to the Site Graphic Image. The External Form--The Click Properties Menu Item FIG. 18 depicts User interaction, via a standard Mouse Device 18-5, width the Site Window 18-6 of the SensorCanvas.class Object of the Site Control Window 18-1 of a SensiView.class Object, when the Properties Menu Item of the Click Menu 18-4 is selected to enable the identification 18-7 of the component Objects of the Virtual Sensor whose location is clicked 18-5 within the Site Window 18-6. The component Objects of the indicated Virtual Sensor are displayed 18-7 as: the Sensor Field (Identification) Tag 18-8, the Class name of the ObservationMethod.class Object 18-9, and the Class name of the ExpressionMethod.class Object 18-10, and the AWT ListBox Object 18-11 list of pairs of EvaluationMethod.class Objects and RenderingMethod.class Objects which define the individual symbols of expression for the Virtual Sensor. When the User has completed their viewing of the Properties, the OK 18-12 button may be clicked to close the display window 18-7. The implementation of this feature is achieved via the Handle Event( ) Method of the SensorCanvas.class Object processing Mouse Device events, so as to display the component Objects 6-2 and 6-5 of the Virtual Sensor, when a click event is detected over the location of the respective Virtual Sensor with respect to the Site Graphic Image. The External Form--The Click Edit Mode Menu Item FIG. 19 depicts User interaction, via a standard Mouse Device 19-4, with the Site Window 19-5 of the SensorCanvas.class Object of the Site Control Window 19-1 of a SensiView.class Object, when the Edit Mode Menu Item of the Click Menu 194-2 is selected to enable the identification 19-6 of the component Objects of the Virtual Sensor whose location is clicked 19-4 within the Site Window 19-5. The component Objects of the indicated Virtual Sensor are displayed 19-6 as: the Sensor Field (Identification) Tag 19-7, the Class name of the ObservationMethod.class Object 19-8, and the Class name of the ExpressionMethod.class Object 19-9, and the AWT ListBox Object 19-10 list of pairs of EvaluationMethod.class Objects and RenderingMethod.class Objects which define the individual symbols of expression for the Virtual Sensor. Note that an Edit Menu 19-3 is included on the MenuBar for Edit Mode of operation which allows to Cut, Copy, Paste, and Delete complete Virtual, Sensor Objects, with respect to the client Site Window Object. The component Objects may be edited by using the Mouse Device 19-4 to place the input focus on the component information of interest and then clicking the Edit button 19-11. When the User has completed their editing of the components, the OK button 19-12 may be clicked to close the display window 19-6. Alternatively, the Cancel button 19-13 may be clicked at any time to revert the Virtual Sensor to its prior configuration. The implementation of this feature is achieved via the HandleEvent( ) Method of the SensorCanvas.class Object processing Mouse Device events, so as to display the component Objects 6-2 and 6-4 of the Virtual Sensor, when a click event is detected over the location of the respective Virtual Sensor with respect to the Site Graphic Image. The External Form--The Observation Method Editor Window FIG. 20 is a graphic rendering of a Sensor Methods Window Object 20-1, with the name field of the ObservationMethod.class Object 20-3 clicked to enable specification and modification, of the om_.class Object used by a Virtual Sensor, via a Observation Method editor Window Object 20-10. The component Objects of the Virtual Sensor are displayed as: the Sensor Field (Identification) Tag 20-2, the Class name of the ObservationMethod.class Object 20-3, the Class name of the ExpressionMethod.class Object 20-4, and the AWT ListBox Object 20-5 list of pairs of EvaluationMethod.class Objects and RenderingMethod.class Objects which define the individual symbols of expression for the Virtual Sensor. The ObservationMethod.class Object 20-3, is selected for editing by use of the Mouse Device 20-9 and then by clicking the Edit button 20-6. When the User has completed their editing of the components, the OK button 20-7 may be clicked to close the Sensor Methods Window Object 20-1. Alternatively, the Cancel button 20-8 may be clicked at any time to revert the Virtual Sensor to its prior configuration. Beyond the Sensor Methods Window Object 20-1, in FIG. 20, the Observation Method editor Window Object 20-10 provides an interface which allows selection 20-11 from the list of all the om_.classes 20-12 which are available for the client Site. The specifications and options for the selected om_.class 20-11 are detailed as the operational Mode 20-16, a URL target Object extension 20-17, TimeLine Continuity options 20-18, the number of distinct values observed per reading 20-19, the format of the digital information observed by the URL target Object 20-20, a description 20-21 of the currently selected Method, and the precision and dimensionality of the observed reading 20-22. Note that some concepts, such as dimensionality, may be inappropriate to graphic, audio, etc. formats. When the User has completed their editing of the Observation Method, the OK button 20-13 may be clicked to close the editor window 20-10. Alternatively, the Cancel button 20-14 may be clicked at any time to revert to previously defined Observation Method, or, the Help button 20-15 may be clicked at any time to obtain additional information regarding the options available. Each_Method.class-type Class of Object supports a Description( ) Method to describe the properties that an Object of the Class enjoys. Note that certain properties may impact the selection process or otherwise constrain the selection of other candidate_Method.class-type Objects within a given Virtual Sensor. Examples of such constraints are the number of digits precision carried by a numeric value, the dimensionality of the measured quantity and the number of values observed per Reading Moment. The External Form--The ExpressionMethod Editor Window FIG. 21 is a graphic rendering of a Sensor Methods Window Object 21-1, with the name field of the ExpressionMethod.class Object 21-3 clicked to enable specification and modification, of the xm_.class Object used by a Virtual Sensor, via an Expression Method editor Window Object 21-10. The component Objects of the Virtual Sensor are displayed as: the Sensor Field (Identification) Tag, 21-2, the Class name of the ObservationMethod.class Object 21-3, the Class name of the ExpressionMethod.class Object 21-4, and, a ListBox Object 21-5 list of the defined pairs of EvaluationMethod.class Objects and RenderingMethod.class Objects which produce the individual symbols of expression for the Virtual Sensor. The ExpressionMethod.class Object 21-4, is selected for editing by use of the Mouse Device 21-9 and then by clicking the Edit button 21-6. When the User has completed their editing of the components, the OK button 21-7 may be clicked to close the Sensor Methods Window Object 21-1. Alternatively, the Cancel button 21-8 may be clicked at any time to revert the Virtual Sensor to its prior configuration. Beyond the Sensor Methods Window Object 21-1, in FIG. 21, the Expression Method editor Window Object 21-10 provides an interface which allows selection 21-11 from the list of all the xm_.classes 21-12 which are available for the client Site. The specifications and options for the selected xm_.class 21-11 are detailed by a description 21-16 of the currently selected Method and a Listbox of the EvaluationMethod.class and RenderingMethod.class Object pairs 21-17 which produce the symbols which will constitute an expression. This specific example depicts a Virtual Sensor whose Observation Method was just replaced with an omTS_V.class ObservationMethod.class Object 21-3, whereas a new, compatible Expression Method must be specified. When the User has completed their editing of the Expression Method, the OK button 21-13 may be clicked to close the editor window 21-10. Alternatively, the Cancel button 21-14 may be clicked at any time to revert to previously defined Expression Method, or, the Help button 21-15 may be clicked at any time to obtain additional information regarding the options available. The User may add, modify, or delete a symbol from the Expression Method by selecting a Symbol Pair from the list of all the xm_.classes 21-12 which are available, and clicking the New button 21-18, the Edit button 21-19, or, the Delete button 21-20, respectively. When the New button 21-18 or the Edit button 21-19 is then clicked, a Symbol Pair editor Window Object 22-9 will be displayed for the target Symbol Pair. The External Form--The Symbol Pair Editor Window FIG. 22 is a graphic rendering of an Expression Method editor Window Object 22-1 provides an interface which allows selection 22-2 from the list of all the xm_.classes 22-3 which are available for the client Site. The specifications and options for the selected xm_.class 22-2 are detailed by a description 22-7 of the currently selected Method and a Listbox of the EvaluationMethod.class and RenderingMethod.class Object pairs 22-8 which produce the symbols which will constitute an expression. The User may add, modify, or delete a symbol from the Expression Method by selecting a Symbol Pair from the Listbox of all the xm_.classes 22-3 which are available, and clicking the New button 22-9, the Edit button 22-10, or, the Delete button 22-11, respectively. This specific example depicts a Virtual Sensor whose Expression Method is specified as an xmM_S ExpressionMethod.class Object 22-3, which has been selected by a click of the Mouse Device 22-12 for modification, via a Symbol Pair editor Window Object 22-13. When the User has completed their editing of the Expression Method, the OK button 22-4 may be clicked to close the editor window 22-1. Alternatively, the Cancel button 22-5 may be clicked at any time to revert to previously defined Expression Method, or, the Help button 22-6 may be clicked at any time to obtain additional information regarding the options available. For the Symbol Pair 22-8 thusly selected 22-12 in FIG. 22, a Symbol Pair editor Window Object 22-13 is opened and the constituent Evaluation 22-14 and Rendering 22-16 Methods are displayed. Along with the name 22-14 of the constituent Evaluation Method, a Listbox Control of all available em_.classes 22-15 is displayed, and likewise, along with the name 22-16 of the constituent Rendering Method, a Listbox of all available rm_.classes 22-17 is displayed. For the Evaluation Method 22-14, an Observation Readings Index 22-18 is specified to indicate which specific value, within a reading for a moment, is to be used as the Substance to be passed to the Evaluation Method 22-14 of the Virtual Sensor. Necessarily, the thusly selected specific value within a reading 22-18 then determines the Form of the interface requirements for the classes of em_.class Objects 22-15 which may accept such Substance, typically in the Form of an ObservationReadings.class Object 1-13. The number of Decimal Places 22-19 and Units 22-20 allow a normalization of precision and conversion of dimensional units to be performed, respectively, by the em_.class Objects 22-15. The options available via the Units Edit Control 22-20 include an extensive list of conventional physical dimensional units, and an extension of the concept into the CyberSpace virtual reality of internal Forms and formats as a dimension, with units of measure such as GIF, JPG, MPEG, AVI, and other various MIME formats. Appropriate conversion, transformation, and other management functions options are provided as per the requirements of the specific format, in accordance with a fully parameterized canonical GUI. A description 22-21 of the Evaluation Method 22-14 is also provided. For the Rendering Method 22-16, a Display Control Edit Control 22-22 allows the client User to specify a Display Control name which will be used to create an AWT CheckboxMenuItem Object that may be integrated into a GUI, such as a SensiView.class Object client Site Control Window 11-1. The menu of all such Display Control Objects is presented on the Site Control Window 11-1 as the Display Menu. The Always Render Pushbutton Control 22-23 allows the client User to specify that the Rendering Method 22-16 should be invoked even when the Evaluation Method 22!-14 indicates a `null` or `normal` evaluation. The Overlay Edit Control 22-24 indicates the nature of Device masking to be performed during the expression process. For graphic Devices, such as a CRT, kit various levels of transparency and styles of masking filters are available. A description 22-25 of the Evaluation Method is also provided. When the client User has completed their editing of the Symbol Pair 22-13, the OK button 22-26 may be clicked to close the Symbol. Pair editor Window Object 22-13. Alternatively, the Cancel button 22-27 may be clicked at any time to revert to previously defined Expression Method, or, the Help button 22-28 may be clicked at any time to obtain additional information regarding the options available. Network Platforms Whereas all SensiView components are formulated as Objects in CyberSpace, in FIG. 23, the InterNet 23-7 may be regarded as a transport mechanism for communication of content messages and intent instructions among and between the Objects. As such, the SensiView Control Window 23-1, displays the external form of the SensiView.class Object on the client user's local computer 23-2 display terminal 23-3. Also connected to the client user's logical computer 23-2 is a mouse device 23-4, a series of sensor probes 23-5 for actively acquiring data for observation and expression in real-time, and a local disk storage device 23-6 for archive storage of the observed readings as digitized information. In turn, a comparable computer 23-8 configuration may likewise be connected to the InterNet 23-7 and be accessible via standard InterNet 23-7 protocols for communications, such as TCP/IP, SLIP, PPP, etc. The comparable remote computer 23-8 configuration, likewise, has a display terminal 23-9, a mouse device 23-10, a series of sensor probes 23-11 for actively acquiring data for observation and expression in real-time, and a local disk storage device 23-12 for storing the observed readings as digitized information. The Universal Resource Locator (URL) provides a means of access to any digitized information which may exist on any such disk storage devices 23-6, 23-12 which are thusly connected to the InterNet. The specific device drivers for the sensor probes 23-5, 23-11 will determine the remote control capabilities of the specific sensor probes in a real-time mode of operation. However, such a remote configuration can always record the acquired observation reading to the local disk storage device 23-12 for later access. Further, because all SensiView components are formulated as Objects in CyberSpace, in FIG. 24, the InterNet 24-6 may be regarded as a transport mechanism for communication of content messages and intent instructions among and between the Objects. As such, the SensiView Control Window 24-3, displays the external form of the SensiView.class Object on the client user's local computer 24-1 display terminal 24-2. Also connected to the client user's local computer 24-1 is a mouse device 24-5. The Site Window 24-4 for the graphic image associated with a specific SiteProfile object provides a medium for the visual expression of the Virtual Sensors configured for the client site. In turn, a comparable computer 24-8 configuration 24-7 may likewise be connected to the InterNet 24-6 and be accessible via standard InterNet 24-6 protocols for communications, such: as TCP/IP, SLIP, PPP, etc. The comparable remote computer 24-8 configuration 24-7, likewise, has a display terminal 24-9, a mouse device 24-10, a series of sensor probes 24-11 for actively acquiring data for observation and expression in real-time, and a local disk storage device 24-12 for storing the observed readings as digitized information. The Universal Resource Locator (URL) provides a means of access to any digitized information which may exist on any such disk storage device 24-12 which is thusly connected to the InterNet 24-6. The specific device drivers for the sensor probes 24-11 will determine the remote control capabilities of the specific sensor probes in a real-time mode of operation. However, such a remote configuration can always record the acquired observation reading to the local disk storage device 24-12 for later access. Objective Formalities Finally, it should be noted that while the above process was described with reference to the various flow charts of the present application, in essence, the various steps of the present invention were implemented by hardware computer components. Accordingly, each step of the present invention typically generates an electrical signal which represents a result of the specific step in the illustrated flow charts. Accordingly, the flow charts represent the electrical signals which are generated and used in subsequent steps of the Virtual Sensor process of the present invention. The many features and advantages of the invention are apparent from the detailed specification, and thus, it is intended by the appended claims to cover all such features and advantages of the invention which fall within the true spirit and scope of the invention. Further, since numerous modifications and variations will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction illustrated and described, and accordingly, all suitable modifications and equivalence may be resorted to, falling within the scope of the invention.
Standard Methods Classes
Observation
omDialog A client User dialog value specification, per reading.
omNewStat A sample Object for custom Static Mode
Observation Methods.
omNewDyAs A sample Object for custom Dynamic Mode,
Asynchronous Observation Methods.
omNewDySy A sample Object for custom Dynamic Mode,
Synchronous Observation Methods.
omRecord { Unit record text format }
omTime Null observation for timestamp generation.
omTH_A { TimeStamp, xx.xx, xx.xx } format
omTS_IW { TimeStamp, Int, xx.xx } format.
omTS_V { TimeStamp, xx } format.
omTS_W { TimeStamp, xx.xx } format.
omTTH_A { HourStamp, xx.xx, xx.xx, xx.xx } format
omTTH_M { TimeStamp, xx.xx, xx.xx, xx.xx } format
Evaluation
emAir Air Flow, Circulation Deviations.
emDynamic An Evaluation Method which is dynamically
configured by a client User dialog.
emH_M Humidity, Museum Deviations.
emIdentity Null Evaluation Method.
emM_G Moisture, Ground Deviations.
emNew Null Evaluation Method.
emT_M Temperature, Museum Deviations.
Expression
Symbol Pair
xmAir_S emAir, rmAir
xmAir emIdentity, rmAir
xmBoxes emIdentity, rmBoxC
xmCrack emIdentity, rmCrack
xmDay emIdentity, rmSun
xmDensity emIdentity, rmDensity
xmHatch emIdentity, rmHatch
xmJiggle emIdentity, rmJiggle
xmM_S emM_S, rmRings
xmOilPan emIdentity, rmOilPan
xmPeople emIdentity, rmPeopB
xmRandom emIdentity, rmRandom
xmRings emIdentity, rmRings
xmTH_S emT_M, rmBoxC
emH_M, rmRings
xmTTH_S emT_M, rmBoxL
emT_M, rmBoxR
emH_M, rmRings
xmTube emIdentity, rmTube
xmT_S emT_M, rmBoxC
xmWeather emIdentity, rmRainB
Rendering
rmAir 0 to 4 deviations for up arrows.
rmBoxC 0 to 4 deviations for imploding, centered boxes.
rmBoxL 0 to 4 deviations for imploding, left shifted boxes.
rmBoxR 0 to 4 deviations for imploding, right shifted boxes.
rmCrack 0 to 4 deviations for vertically extending triangle.
rmDensity 0 to 4 deviations for grid filled rectangle.
rmHatch 0 to 4 deviations for cross hatched filled rectangle.
rmJiggle 0 to 4 deviations for vertically extending, jiggling
mesh.
rmNew A sample Object for development of custom Rendering
Methods.
rmOilPan 0 to 4 deviations for sparse red to dense white filled
trapezoid.
rmPeopB Text display of a numeric value.
rmRainB 0 or 1 toggle for clear sky or jiggling raindrops.
rmRandom 0 to 100 percentage randomly filled rectangle.
rmRings 0 to 4 deviations for imploding concentric rings.
rmSun Sun and Moon rise and set of a TimeStamp.
rmTube 0 to 100 percentage filled rectangle.
GLOSSARY OF TERMS abstract Class of Objects: An abstract Class of Objects is a Class in which methods are defined, but are not actually implemented by that Class. Such method definitions only provide formal place-holders such that subsequent Classes, which are derived from the abstract Class, must override such methods and supply their actual implementation. actual software instantiation: An actual instance of an executable program module. analog: The quality of a continuous flow, in contrast to the discrete quantification, of information. array structure: A convenient form for referencing a specific element within a well defined collection of Objects which are all of the same Class. ASCII: American Standard Codes for Information Interchange. asynchronous access: A method of access which indicates, via a interruption of normal processing, that a target Object has entered a particular state or completed a specific task. The interruption of normal processing is handled by the EventHandler method of the Object which initiated the access. binary: The digital representation of quantity, using the number 2 as the positional power base. binary information: Quantative data represented in binary form. Class: A Class is a software construct that defines the instance variables and methods of an Object. A Class in and of itself is not an O | ||||||