Compilation of transformation in recalculation user interface.

(54) Title: COMPILATION OF TRANSFORMATION IN A RECALCULATION USER INTERFACE.

(54) Title: COMPILATION OF TRANSFORMATION IN RECALCULATION USER INTERFACE.

(57) Summary

The complication of a transform chain of a recalculation user interface that displays an electronic banner containing one or more displayed results of a transform chain. The transformation chain includes transformations between a respective data source and a data collector. The user edit of the recalculation user interface can cause one or more of the transformations to be rerun, thus causing the recalculation. Compilation involves analyzing the transformation chain of the recalculation user interface for dependencies to create a dependency graph of dependencies between entities. For example, some dependencies may be between entities in order to indicate that if one entity is evaluated, then the other must also be evaluated. The dependency graph is then used to create a lower level of execution steps. The dependency graph is also provided at a run time for the program, so that the dependency graph may be available during the operation of the recalculation user interface.

(57) Abstract

The compilation a transformation Chain of a recalculation user interface that displays an electronic canvas that contains one or more displayed result of a transformation Chain. The transformation Chain includes transforms between a respective data source and data sink. User editing of the recalculation user interface could cause one or more of the transforms to be re-executed, thereby causing recalculation. The compilation involves analyzing the transformation Chain of the recalculation user interface for dependencies to create a dependency graph of dependencies between entities. For instance, some dependencies might be between entities so as to indicate that if one entity is evaluated, then the other should be also. The dependency graph is then used to create a lower level of execution steps. The dependency graph is further provided to a runtime for the program, so that the dependency graph may be available during operation of the recalculation user interface.

I Μ Ρ I ' ^{; !} '«Μ · * PATENT TITLE No. 348639

Owner (s): MICROSOFT TECHNOLOGY LICENSING, LLC

Address: One Microsoft Way, Redmond, Washington, 98052, USA

Name: COMPILATION OF TRANSFORMATION INTO A RECALCULATION USER INTERFACE.

Classification: CIP: G06F9 / 45; G06F9 / 44; G06F17 / 24

CPC: G06F9 / 4443; G06F8 / 433; G06F17 / 246

Inventor (s): ANDREW DOUGLAS REDDISH; OLIVIER COLLE; RADU B. GRUIAN; NIZAM

ANUAR; JAIDEEP SARKAR; VIJAY MITAL

REQUEST

Number: International Presentation Date:

MX / a / 2015/014301 April 11, 2014

PRIORITY

Country: Date: Number:

US April 12, 2013 13 / 862,277

Validity: Twenty years

Expiration Date: April 11, 2034

Issue Date: June 22, 2017

The reference patent is granted based on the articles 1^or. 2 'fraction V, 6^or fraction IW, and 59 of the Industrial Property Law.

In accordance with article 23, of the Industrial Property Law, this patent has a validity of twenty non-extendable highs, counted from the date of presentation of the “international legality and the rate to keep the rights in force will be subject to the pagbtfe

Whoever signs this title does so based on the provisions of »Articles 6 ° taEones III and 7“ bis 2 of the Industrial Property Law (Official Gazette of the Federation (D.OF) 06/27/1991, amended on 08/02/1994, 10/25/1986 12/26/1997, 05/17/1999, 01/26/2004, 06/16/2005, 01/25/2006, 05/06/2009, 06/01 / 2010, 06/18 / 2010,28 / 06 / 2010,27 / 01/2012 and 04/09/2012); items 1^or, 3 »fraction Vinciso a), 4» and 12 ° fractions I and III of the Regulations of the Mexican Institute of Industrial Property (DOF 12/14/1999, amended on 07/01/2002, 07/15/2004, 28 / 07/2004 and 7/09/2007), articles 1^or, 3^or. 4^or. 5^or fraction V subsection a), 16 sections I and III and JO of the Organic Statute of the Mexican Institute of Industrial Property (DOF 12/27/1999. amended on 10/10/2002, 07/29/2004, 08/04/2004 and 09/13/2007); 1·. 3rd and 5 * inc «o '^;a) of the Agreement that delegates powers to the Deputy General Directors, Coordinator, Divisional Directors, Titulare »of the · Regional · Office, Divisional Deputy Directors, Departmental Coordinators and other subordinates of the Mexican Institute of Industrial Property (DOF 12/15/1999, amended 02/04/2000, 07/29/2004, 08/04/2004 and 09/13/2007).

This official letter is signed with an advanced electronic signature (FIEL), based on articles 7 BIS 2 of the Industrial Property Law; 3 of its Regulations, and 1 section III, 2 section V, 26 BIS and 26 TER of the Agreement establishing the guidelines for the use of the Payment and Electronic Services Portal (PASE) of the Mexican Institute of Industrial Property, in the procedures indicated.

THE DIVISIONAL PATENT DIRECTOR NAHANNY CANAL REYES .Θ Original Chain:

NAHANNY MARISOL CANAL REYES | 00001000000403252793 | Administration Service

Tax | 1695 || MX / 2017/49518 | MX / a / 2015/014301 | PCT patent title | 1223 | GAGV | Page (s) 1 | ekVTziBeifsUU8xOfelfFSenchU =

<img file="MX348639B_D0001.tif" />

Digital stamp:

R / cw + jlSNUs7yNnSma3YVn3Qju6RULnRa3LSzS42cOyZopDDb6CIXOtmnXmuJBrLnWu5sydtKCaHlc96Qcec6831Xx HB4 / RXoCwxmzRgtK7eEE4XmszcCu1DA / jFQHA6wJUMEfbAh5L1POmCf68qfLGZXj3147YhVqDQSSvBG0bSAZZwpue

P Lm5Xf6PbtdJqaJbzQvmUxEJ7wllzMpk6iYTgza2BP2ceucgJ3XDJI8ruvh + WJVI6Rwbh7m348uNqXcBqZqw7grcRuTs lt + SY0xg / 9jhZFDUZWQWemzr9IRzWFDUZWQWemCr 9IRzFZFUJWC5WCZQRZFZBUZWQWC5

Arenal No 550. ,_F · T zt, í, * u, ni Xochimilco, 16020. 0 hi ii Mt i «i I &lt;ib I I. I | UI

<img file="MX348639B_D0002.tif" />

IMPI

<img file="MX348639B_D0003.tif" />

TRANSFORMATION COMPILATION IN ----------------------------------------^------------------- * --------- INUUMUAL

RECALCULATION USER

BACKGROUND

A "recalculation document" is a document that lists multiple data sources and data collectors, and enables a declarative transformation between a data source and a data collector. For a given group of multiple data sources and data collectors interconnect transformations, the output of the data source can be consumed by the data collector, or the output of the data source can be subjected to transformations before being consumed by the data collector. These various transformations are evaluated resulting in one or more outputs represented through the recalculation document.

User can add and edit declarative transformations without having deep coding knowledge. This editing automatically causes the transformations to be recalculated, causing a change in one of more outputs.

A specific example of a recalculation document is a spreadsheet document, which includes a grid of cells. Any given cell can include an expression that is evaluated to produce a particular value that is displayed in the cell. The expression can refer to a data source, such as one or more other cells or values.

WICKED

BRIEF DESCRIPTION OF THE IN VIEWMGAL ^ ·

INDUSTRIAL ¿a—

At least some of the modalities described here refer to compiling a transformation chain from a recalculation user interface. The transformation chain includes a declarative transformation between respective data sources and data collectors. For example, in the context of a worksheet, the data collector can be a particular worksheet cell, the transformation can be the expression associated with the particular cell, and the data source can be one or more other cells. or particular values ​​named within the expression. The user edit of the recalculation interface can cause one or more of the transformations to be rerun, thus causing the recalculation.

Compilation involves analyzing the transformation chain of the recalculation user interface for dependencies to create a dependency graph of dependencies between entities. For example, some dependencies may be between entities in order to indicate that if one entity is evaluated, then the other must also. Other dependencies can specify user events on which the evaluation of an entity depends. The dependency graph is then used to create a lower level of execution steps. Additionally, the dependency graph is provided at a run time for the program, so that the dependency graph may be available during the run.

<img file="MX348639B_D0004.tif" />

user interface operation of

This Brief Description is not intended to provide the key or essential characteristics of the claimed subject matter, it is not intended to be used as an auxiliary to determine the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the aforementioned and other advantages and characteristics can be obtained, a more particular description of various embodiments will be presented with reference to the accompanying drawings. Understanding that these drawings illustrate only sample modalities and, therefore, are not considered as limiting the scope of the invention, the modalities will be described and explained with additional specificity and detail through the use of the attached drawings in which:

Figure 1 in an abstract way shows a computing system where some modalities described here can be used;

Figure 2 abstractly shows an illustrative recalculation user interface, which shows various data sources and data collectors with intervention transformations, and is used as a specific example provided to explain the broader principles described herein;

Figure 3 shows an illustrative compilation environment that includes a compiler that enters the transform chain and _

IMPL produces compiled code as well as cad ^ W ^^^^^ e

INDUSTUIAL and ________________

Figure 4 shows a flow chart of a method for compiling a transform string of a recalculation user interface;

Figure 5 shows an environment where the principles of the present invention can be employed, including a data-driven layout structure that builds a view layout that is dependent on input data;

Figure 6 shows a pipeline environment representing an example of the environment of Figure 5;

Figure 7 schematically shows an embodiment of the data portion of the pipeline of Figure 6;

Figure 8 schematically shows an embodiment of the analytical portion of the pipeline of Figure 6; and

Figure 9 schematically shows an embodiment of the view portion of the pipeline of Figure 6.

DETAILED DESCRIPTION

At least some of the modalities described here refer to compiling a transformation chain from a recalculation user interface. The recalculation user interface may be, for example, a recalculation document, such as a spreadsheet. However, the recalculation interface can be any

<img file="MX348639B_D0005.tif" />

IMPIAS electronic canvas presented that includes one or transformation chain. The transformation chain includes a plurality of transformations between a respective data source and a data collector. The user edit of the recalculation user interface can cause one or more of the transformations to be rerun, thus causing the recalculation.

The compilation involves analyzing the transformation chain of the recalculation user interface for dependencies to create a dependency graph of dependencies between entities. For example, some dependencies may be between entities in order to indicate that if one entity is evaluated, then the other must also be. The dependency graph is then used to create a lower level of execution steps. The dependency graph is further provided at a run time for the program, so that the dependency graph may be available during the operation of the recalculation user interface.

With respect to Figure 1, some introductory discussion of a computer system will be presented. Then, the compilation of the recalculation user interface transform chain will be described with respect to the subsequent figures.

Computer systems have now greatly taken on a wide variety of forms. Computer systems can be, for example, portable devices, appliances, laptop computers,⁶ IMPI

INSTITUTO MEXICANO and desktop computers, central computers for distributed computing, or even devices that conventionally have not been considered as a computer system. In this description and in the claims, the term "computer system" is broadly defined as including any device or system (or a combination thereof) that includes at least one tangible physical processor, and tangible physical memory capable of having there computer-executable instructions that can be executed by the processor. Memory can take any form and can depend on the nature and shape of the computer system. A computer system can be distributed across a network environment and can include multiple constituent computer systems.

As shown in Figure 1, in its most basic configuration, a computer system 100 typically includes at least one processing unit 102 and memory 104. Memory 104 can be physical system memory, which can be volatile, not volatile. volatile, or some combination of the two. The term "memory" can also be used herein to refer to non-volatile mass storage such as physical storage media. If the computer system is distributed, the processing, memory and / or storage capacity can also be distributed. As used herein, the term "executable module" or "executable component" can refer to software objects, routings, or methods that can be executed on the computer system. The . IMPI different components, modules, motors, and sei «nxjio_pei ^^ í

INDUSTRIAL can be implemented as objects or procedures that are executed in the computer system (for example, as separate sequences).

In the description that follows, modalities are described with reference to acts that are performed by one or more computer systems. If such acts are implemented in software, one or more processors of the associated computer system that performs the act direct the operation of the computer system in response to having computer-executable instructions. For example, such computer-executable instructions can be modeled on one or more computer-readable media that form a computer program product. An example of such an operation involves data manipulation. Computer-executable instructions (and manipulated data) can be stored in memory 104 of computer system 100. The computer system 100 may also contain communication channels 108 that allow the computer system 100 to communicate with other message processors through, for example, the network 110. The computer system 100 also includes a presentation 112, the which can be used to present visual representations to a user.

The modalities described herein may comprise or utilize a general-purpose or special-purpose computer that includes computer hardware, such as, for example, one or more

ΙΜΡΙ ^ γ processors and system memory, as detailed later. The modalities described herein also include physical and other computer-readable means for making or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available medium that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that stores computer-executable instructions are physical storage media. Computer-readable media that can perform computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention may comprise at least two very different types of computer-readable media: computer storage media and transmission media.

Computer storage media includes RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible medium, which can be used to store storage media. Desired program code in the form of computer-executable instructions or data structures that can be accessed by a general-purpose or special-purpose computer.

A "network" is defined as one or more data links that allow the transport of electronic data between communication systems.

IMPIAS computer and / or modules and / or other devices and I C-trandcr, / the information is transferred or provided through a network or other communication connection (either wired, wireless, or a combination of wired or wireless ) to a computer, the computer appropriately views the connection as a transmission medium. The transmission media may include a network and / or data links that can be used to carry or desire program code media in the form of computer-executable instructions or data structures that can be accessed by the general-purpose computer or special purpose. Combinations of the above should also be included within the scope of computer-readable media.

Furthermore, after reaching various computer system components, program code means in the form of computer executable instructions or data structures can be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data collector can be buffered in RAM within a network interface module (eg, "NIC"), and then finally transferred to system RAM and / or less volatile computer storage media in a computer system. In this way, it should be understood that computer storage media can be included in computer system components that

M THE PROPERTY K- * ·· $ 2

INDUSTRIAL mainly) use transmission media.

Computer-executable instructions comprise, for example, instructions and data that, when executed by a processor, cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. . Computer-executable instructions can be, for example, binaries, intermediate-format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features described or acts described above. Rather, the features and acts described are described as illustrative ways to implement the claims.

Those skilled in the art will appreciate that the invention can be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, portable devices, processor systems. multiple, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, mobile phones, PDAs, locators, routers, switches, and the like. The inve

<img file="MX348639B_D0006.tif" />

be practiced in distributed system environments, where ____i ii w -। f irtwrrm— local and remote computer systems that are linked (either through wired data links, wireless data links, or through a combination of wired or wireless data links) over a network, both perform tasks. In a distributed system environment, the program modules can be located on both local and remote memory storage devices.

In this description and in the claims, a "recalculation user interface" is an interface with which a user can interact and that occurs in an environment where there are one or more data sources and one or more data collectors. Furthermore, there is a group of transformations that each can be declaratively defined between one or more data sources and a data collector. For example, the output of a data source is fed to the transformation, and the result of the transformation is then provided to the data collector, potentially resulting in some type of display change to the user.

Transformations are "declarative" in the sense that a user, without specific coding knowledge, can write the declarations that define the transformation. Since the transformation is declaratively defined, a user can change the declarative transformation. In response, recalculation is performed, resulting in perhaps different data that is provided to the data collectors. J] V1 1 1

MtXlCANl INSTITUTE

FROM THE FkOHtUAU ¿-4.pl *

A classic example of a user interface^NW'TbcaTburtT is a spreadsheet document. An hpja document includes a grid of cells. The cells are initially empty, and thus any cell in the spreadsheet program has the potential to be a data source or a data collector, depending on the meaning and context of declarative expressions entered by a user. For example, a user can select a given cell, and type an expression in that cell. The expression can be as simple as an expressed scalar value that will be assigned to that cell. That cell can then be used as a data source. Alternatively, the expression for a given cell can be in the form of an equation where the input values ​​are taken from one or more other cells. In that case, the given cell is a data collector that presents the result of the transformation. However, during continuous authoring, that cell can be used as a data collector for other transformations declaratively done by the author.

The author of a spreadsheet document does not need to be an expert in imperative code. The author simply makes statements that define a transformation, and selects corresponding data collectors and data sources. Figures 5 through 9 described below provide a more generalized declarative authoring environment in which an interface of

IMPIOS most widespread recalculation user. In¹*^^^^

INDUSTRIAL subsequently described, the displayed controls can serve as both data sources and data collectors. Additionally, declarative transformations can be more intuitively authored by simple manipulations of those controls.

Figure 2 abstractly shows an illustrative recalculation user interface 200, which is a specific example provided to explain the broader principles described herein. The recalculation user interface 200 is just one example of how the principles described herein can be applied to any recalculation user interface to create a countless variety of recalculation user interfaces for a countless variety of applications.

The recalculation user interface 200 includes several declarative transformations 211 to 215. The dotted circle around each of the arrows representing the transformations 211 to 216 symbolizes that the transformations are each in declarative form.

In this specific example of Figure 2, the transformation 211 includes a data source 201 and a respective data collector 202. Note that a data collector for one transformation can also be a data source for another transformation. For example, data collector 202 for transformation 211 also serves as a data source for transformation 212. In addition, a transformation may have

IMPI multiple data sources. In this way, - ^^, ^^^^J Say LA PKudtlIAL · VXj, go INDUSTRIAL transformation can be hierarchical, and thus quite complex. For example, transformation 212 includes data source 202 and data collector 203. Data collector 203 includes two data sources; mainly data source 202 for transformation 212, and data source 205 for transformation 214. That is, perhaps a single transformation leads the two data sources 202 and 205 to data collector 203. The transformation 213 includes a data source 204 and a data collector 205.

If the recalculation user interface were a spreadsheet document, for example, the various data sources / collectors 201 to 205 can be spreadsheet cells, in which case the transformations represent the expression that can be associated with each cell collector. The output of each expression is presented within the cell. In this way, in the case of a spreadsheet, the data sources / collectors can be complex visualized controls that both include input parameters to and output parameters of the transformation chain. For example, in Figure 2, there is an additional declarative transformation 215 that goes from data source 205 to data collector 201. Thus, data source / collector 201 can display information representing an output from transformation 215, as well as provide additional data to other data collectors.

Recalculation user interfaces do not need to have display controls. An example of this e »^b GIVE INDUSTRIAL PROPERTY recalculation user made to perform transformation-based computation, consume source data and update collector data, without any information presented to the user about the computation in the normal case. For example, the recalculation user interface can support background computing. A second example is a recalculation user interface that has output controls that operate external actuators, such as the valves in the illustrative procedural control. These controls are like presentation controls in that their states are controlled by results of the transformation computation and signal inputs. However, here, the output is a control signal to a device rather than a display to a presentation. Consider, for example, a recalculation user interface to control a robot. This recalculation user interface can have rules for robot actions and behavior that depend on input robot sensors such as servo-positions and speeds, ultrasonic scale finding measurements, and so on. Or consider a procedural control application based on a recalculation user interface that takes signals from equipment sensors such as valve positions, fluid flow rates, etc.

Figure 3 shows an illustrative build environment 300 that includes a compiler 310 that has access to transform chain 301. An example of transform chain 301

<img file="MX348639B_D0007.tif" />

is the transformation chain 200 of the sample a flow chart of a method transformation chain of an interface of — usual ¡u of leuáluirfu "The method 400 can be performed by the compiler 310 of Figure 3. In one embodiment, method 400 may be performed by computer system 100 in response to processor (s) 102 executing modalized computer-executable instructions on one or more computer-readable storage media.

Method 400 includes parsing a transformation chain of the recalculation user interface for dependencies (act 401). For example, referring to Figure 2, compiler 300 can analyze each of the transformations 211 to 215. The transformations are declarative and in this way the dependencies can be extracted more easily than it could be if the transformations were expressed using an imperative computer language.

Based on the analysis, a dependency graph (act 402) is created between named entities in the transformations. Essentially, dependencies have a source entity that represents an event, and a target entity that represents that the evaluation of that target entity depends on the event. An example of the event could be a user event where the user interacts, in a certain way, with the recalculation user interface. As another example, the event can be an inter-entity event where if the source entity is evaluated, then the entity

IMPI target of the dependency should also be evaluatedSV'IP ™ * ^^ * ^{1 l}- * · LA rnVf! TL'AL · V ** · «

INDUSTRIAL

The compiler then creates lower level execution steps based on the dependency graph (act 403). Lower level execution steps, for example, can be imperative language code. Imperative language code is adapted to respond to detection events, reference an event box to determine a function to execute, and execute that function. Therefore, each of the dependencies on the dependency graph can be reduced to a function. The dependency graph itself can be provided at runtime (act 404). The imperative language code can be, for example, a script or script language, such as JAVASCRIPT. However, the principles described here are not limited to the imperative language code being of any particular language.

As an example, Figure 3 shows that compiler 310 also generates lower-level code 311. Said lower-level code 311 includes a compilation of each of the transforms in the transform chain. For example, the lower-level code 311 is shown as including an element 321 that represents the compilation of each of the transforms in the transform chain. In the context of Figure 2, element 321 could include a compilation of each of the transformations 211 to 215. The lower-level code 311 also includes a variety of functions 322. A function is generated for each dependency on the graph of dependence. The_.................. , _sdelena . . IMPI functions can be imperairiKO * MtXiCANt 'language functions

OF THE INDUSTRIAL RXOPIEDAL

<img file="MX348639B_D0008.tif" />

When an imperative language runtime detects an event that is listed in the dependency graph, the corresponding function within compiled functions 322 also executes. Therefore, with all the properly compiled transformations, and with each of the dependencies on particular events imposed by the dedicated functions, the declarative recalculation user interface is appropriately represented as an imperative language code.

Thus, an effective mechanism for compiling a declarative recalculation user interface has been described. Also, the runtime is provided with a dependency graph, instead of a more extensive interpreter.

With reference to Figures 5 to 9, a specific example of an authoring pipeline to allow non-programmers to write programs with complex behaviors using a recalculation user interface will now be described.

Figure 5 shows a visual composition environment 500 that can be used to construct an interactive visual composition in the form of a recalculation user interface. Construction of the recalculation user interface is performed using data-driven analytics and visualization of analytical results. The environment 500 includes a composition structure 510 that performs logic that is made independent of the problem domain of view composition 530. For example,

<img file="MX348639B_D0009.tif" />

same composition structure 510 can be

HEAR THE OWN INDUSTMA interactive view compositions for city plans, molecular models, food shelf layouts, machine performance or assembly analysis, or other domain-specific presentations.

The composition structure 510 uses domain-specific data 520, however, to construct the current visual composition 530 that is domain-specific. Accordingly, the same composition structure 510 can be used for recalculation user interfaces for any number of different domains by changing domain-specific data 520, rather than having to re-encode the same composition structure 510. In this way, the composition structure 510 of pipeline 500 can be applied to a potentially unlimited number of problem domains, or at least a wide variety of problem domains, by altering data, rather than re-encoding and re-encoding. compile. View composition 530 may then be supplied as instructions to an appropriate 2-D or 3-D display module. The architecture described here also allows for the convenient incorporation of pre-existing view composition models as building blocks for new view composition models. In one embodiment, multiple view comps can be included in an integrated view comp to allow easy comparison between two possible solutions to a model.

Figure 6 shows an illustrative architecture of composition structure 510 in the form:

Pipeline 600. Pipeline environment 600 includes, among other things, pipeline 601 itself. Pipeline 601 includes a data portion 610, an analytical portion 620, and a view portion 630, each of which will be described in detail with with respect to subsequent Figures 7 through 9, respectively, and the accompanying description. Now, at a general level, the data portion 610 of the pipeline 610 can accept a variety of different types of data and presents that data in a canonical form to the analytical portion 620 of the pipeline 601. The analytical portion 620 ties the various model parameters, and solves the unknown in the model parameters use model analytics. The various parameter values ​​are then provided to the view portion 630, which constructs the composite view using those model parameter values.

Pipeline environment 600 also includes an authoring component 640 that allows an author or other user of pipeline 601 to formulate and / or select data to provide to pipeline 601. For example, authoring component 640 can be used to supply data to each of the data portion 610 (represented by input data 611), analytical portion 620 (represented by analytical data 621), and view portion 630 (represented by view data 631). The various data 611, 621, and 631 represent an example of the domain-specific data 520 of Figure 5, and will be described in greater detail later. The authoring component 640 supports

<img file="MX348639B_D0010.tif" />

wide variety of data including, for example, data schemas, actual data to be used by the model, the location or scale of possible locations of data to be fetched from external sources, visual objects (graphics or animation), interactions user interface that can be performed in visual statements, modeling (for example, views, equations, constraints), unions, etc. In one embodiment, the authoring component is just a portion of the functionality provided by a full manager component (not shown in Figure 6, but represented by the composition structure 510 of Figure

5). The manager is a total manager who controls and sequences the operation of all other components (such as data connectors, solvers, viewers, etc.), in response to events (such as user interaction events, data events external, and events from any of the other components such as solvers, operating system, etc.).

In the pipeline environment 600 of Figure 6, the authoring component 640 is used to provide data to an existing pipeline 601, where is the data that drives the entire procedure from defining the input data, defining the analytical model (called above as the “transform chain”), to define how the results of the transform chain are displayed in the view composition. Therefore, no encoding is required in order ²² IMPI # ^

INSTITUTO MEXICANO to adapt pipeline 601 to any of one of domains and problems. Only the data provided to pipeline 601 is what will change in order to apply pipeline 601 to display a different view composition of either a different problem domain, or perhaps adjust the problem that an existing domain solves. Also, since data can be changed in a usage time (ie runtime) as well as author time, the model can be modified and / or extended at runtime. In this way, there is less distinction, if any, between creating a model and running the model. Since authorship involves editing data articles and since the software runs through all of your data behavior, each change to the data immediately affects the behavior without the need for recording and recompiling.

The pipeline environment 600 also includes a user interaction response module 650 that detects when a user has interacted with the presented visa composition, and then determines what to do in response. For example, some types of interactions may require no change to the data provided to pipeline 601 and thus no change to view composition is required. Other types of interactions can change one or more of the 611, 621, or 631 data. In that case, these new or modified data may cause new data to be provided to the data portion 610, may require a re-analysis of the input data by the analytical portion 620, and / or may require re-visualization. of the iNousTwAi by view portion 630.

Consequently, pipeline 601 can be used to extend data-driven analytical views to perhaps an unlimited number of problem domains, or at least to a wide variety of problem domains. Also, you don't need to be a programmer to alter view composition to address a wide variety of problems. Each of the data portion 610, the analytical portion 620, and the view portion 630 of the pipeline 601 will now be described with respect to the respective data portion 700 of Figure 7, the analytical portion 800 of the

Figure 8, and the view portion 900 of Figure 9, in that order. As will be apparent from Figures 7 through 9, pipeline 601 can be constructed as a series of transform components, each 1) receiving some appropriate input data, 2) performing some action in response to that input data. input (such as performing a transformation on the input data), and 3) output data that then serves as input data to the next transformation component.

Figure 7 shows only one of many possible embodiments of the data portion 700 of pipeline 601 of Figure 6. One of the functions of the data portion 700 is to provide data in a canonical format that is consistent with schemas understood by the analytical portion 800 of the pipeline discussed with respect to Figure 8. The data portion includes an access component

IMPI ^ of data 710 accessing heterogenic data input 701 may be "heterogenic" in the sense that the data can (but need not) be presented to the data access component 710 in a canonical form. Actually, the data portion 700 is structured such that the heterogenic data can be of a wide variety of formats. Examples of different types of domain data that can be accessed and operated by models include text documents, and XML, tables, lists, hierarchies (trees), SQL database query results, intelligence cube query results from business (Bl), graphical information such as 2D drawings and 3D visual models in various formats, and their combinations (ie, a composite). In addition, the type of data that can be accessed can be declaratively extended, by providing a definition (eg, a schema) for the data that will be accessed. Accordingly, the data portion 700 allows a wide variety of heterogenic input into the model. And it also supports runtime, declarative extension of accessible data types.

In one embodiment, the data access portion 700 includes a number of connectors for obtaining data from a number of different data sources. Since one of the main functions of the connector is to place corresponding data in canonical form, such connectors will generally be referred to hereinafter and in the drawings as "canonicalizers". Each canonicalizer may have an understanding of the corresponding industry-specific Application Program Interfaces (APIs) d * grt.cs. The canonicalizer can also include logic

O — MM — Μ —— 1Μ · 1 fW «WWWW · corresponding to interface with that corresponding API to read and / or write data from and to the data source. In this way, canonicalizers link external data sources and the memory image of the data.

The data access component 710 evaluates the input data 701. If the input data is already canonical and thus processable by the analytical portion 800, then the input data can be directly provided as canonical data 740 to be input to the analytical portion 800.

However, if the input data 701 is non-canonical, then the appropriate data canonicalization component 730 is capable of converting the input data 701 to canonical format. The data canonicalization components 730 are actually a collection of canonicalization components 730, each capable of converting input data that has particular characteristics into canonical form. The collection of canonicalization components 730 is illustrated as including four canonicalization components 731, 732, 733, and 734. However, the ellipses 735 represent that there may be any other number of canonicalization components as well, perhaps even fewer than the four illustrated. .

701 input data can still include the same canonicalizer as well as a data feature identifier

IMPI correlated. The data portion 700 entoncg ^^^ cle

INDUSTRIAL the correlated data characteristics, and provide the canonicalization component to the 730 data canonicalization component collection, where it can be added to the available canonicalization components. If the input data is received later than those correlated features, the data portion 710 may then assign the input data to the correlated canonicalization component. Canonicalization components can also be found dynamically from external sources, such as from component libraries defined on the web. For example, if the schema of a given data source is known but the canonicalizer is not present, the canonicalizer can be located from an external component library, as long as a library can be found and contains the necessary components. The pipeline can also analyze data for which no schema is yet known and compare the analysis results against schema information in known component libraries to attempt a dynamic determination of the data type to locate the necessary canonicalizer components.

Alternatively, rather than the input data including everything from the canonicalization component, the input data rather provides a transformation definition that defines canonicalization transformations. The 730 collection can then be configured to convert that definition to

IMPI transformations in a component of l¹^^ corresponding transforms that enforce the transforms along with zero or more standard default canonicalization transforms. This represents an example of a case where the data portion 700 consumes the input data and does not provide corresponding canonicalized data downstream of the pipeline. However, perhaps in most cases, the 701 input data results in the generation of corresponding 740 canonicalized data.

In one embodiment, the data portion 710 may be configured to assign input data to the data canonicalization component based on a file type and / or format type of the input data. Other characteristics may include, for example, a source of the input data. A default canonicalization component can be assigned to input data that does not have a corresponding designated canonicalization component. The default canonicalization component can apply a set of rules to try to canonicalize the input data. If the default canonicalization component is unable to canonicalize the data, the default canonicalization component can trigger the authoring component 540 in Figure 5 to prompt the user to provide a schema definition for the input data. If a schema definition does not yet exist, the authoring component 540 may present a schema definition wizard to help the author generate

<img file="MX348639B_D0011.tif" />

a corresponding schema definition that £ to transform the input data into canonical form. Once the data is in canonical form, the schema that accompanies the data provides a sufficient description of the data that the remainder of pipe 601 does not need new code to interpret the data. Rather, pipeline 601 includes code that is capable of interpreting data in light of any schema that can be expressed in an accessible schema declaration language.

Regardless, the canonical data 740 is provided as the output data of the data portion 700 and as the input data to the analytical portion 800. The canonical data can include fields that include a variety of data types. For example, fields can include simple data types such as integers, floating point numbers, sequences, vectors, layouts, collections, hierarchical structures, text, XML documents, tables, lists, SQL database query results, results business intelligence (Bl) cube query tools, graphical information such as 2D drawings and 3D visual models in various formats, or even complex combinations of these various types of data. As a further advantage, the canonicalization procedure is capable of canonicalizing a wide variety of input data. Furthermore, the variety of input data that the data portion 700 is capable of accepting is expansive. This is helpful in the case where multiple models are combined, as shown

IMPI will discuss later in this descripcftyft ^ * ^ industrial

Figure 8 shows analytical portion 800 which represents an example of analytical portion 620 of pipeline 601 of the

Figure 6. The data portion 700 provides the canonicalized data 801 to the data model union component

810. Although the canonicalized data 801 can have any canonicalized shape, and any number of parameters, where the shape and number of parameters may still differ from one piece of input data to another. For purposes of discussion, however, canonical data 801 has fields 802A through 802H, which collectively may be referred to herein as "802 fields".

On the other hand, the analytical portion 800 includes a number of model parameters 811. The type and number of model parameters may differ according to the model. However, for purposes of discussion of a particular example, the 811 model parameters will be discussed as including 811A, 811B, 811C and 811D model parameters. In one embodiment, the identity of the model parameters, and the analytical relationships between the model parameters can be declaratively defined without using imperative coding.

A data model join component 810 interfaces between the canonicalized data fields 802 and the model parameters 811 to thereby provide joins between the fields. In this case, data field 802B is linked to pattern parameter 811A as represented by arrow 803A. In other words, the value of the 802B data field is used for Model 811A II. Also, in this example, data field 802E is linked to pattern parameter 811B (as represented by arrow 803B), and data field 802H is linked to pattern parameter 811C (as represented by arrow 803C).

The 802A, 802C, 802D, 802F, and 802G data fields are not shown tied to any of the model parameters. This is to emphasize that not all data fields of the input data are always required to be used as model parameters. In one embodiment, one or more of these data fields can be used to provide instructions to the data model union component 810 where the fields of the canonicalized data (for this canonicalized data or perhaps any future canonicalized data) go to bind to that model parameter. This represents an example of the type of analytical data 621 that can be provided to the analytical portion 620 of Figure 6. The definition of which data fields from the canonicalized data are attached to the model parameters can be formulated in a number of ways. For example, bindings can be 1) explicitly set by the author at an authoring time, 2) explicitly set by the user as airtime (subject to any restriction imposed by the author), 3) automatically joined by the component of 640 authorship based on algorithmic heuristics, and / or 4) prompted by the authorship component of the author and / or user to specify a union when it is determined that a union does not give the INDUSTRIAL property algorithmically. In this way, unions can also be resolved as part of the same model logic.

The ability of an author to define which of the data fields is mapped to which model parameters provides the author with great flexibility of being able to use symbols of which the author is comfortable to define model parameters. For example, if one of the model parameters represents pressure, the author can name that model parameter "Pressure" or "P" or any other symbol that makes sense to the author. The author can still rename the model parameter which, in one mode, can have the model join component 810 automatically update to allow joins that were previously for the old name's model parameter instead of joining the model parameter of the new name, thus preserving the desired unions. This join mechanism can also allow the join to be changed declaratively at run time.

The 811 D model parameter is illustrated with an asterisk to emphasize that in this example, the 811D model parameter was not assigned a value by the 810 data model join component. Therefore, the 811D model parameter remains unknown. . In other words, the 811D model parameter is not assigned a value.

The modeling component 820 performs a number of functions. First, the modeling component 820 defines. . ........... ΙΜ.ΡΠ? Β ^ 821 analytical relationships between parameters

OF THE MONITY

INDUSTRIAL 821 analytical relationships are categorized into three general categories including 831 equations, 832 rules, and 833 constraints. However, the list of solvers is extensible. In one embodiment, for example, one or more simulations may be incorporated as part of the provided analytical relationships, a corresponding simulation engine provided, and logged as a solver.

The term "equation", as used here, aligns with the term that is used in the field of mathematics.

The term "rules", as used here, means a conditional statement where if one or more conditions are satisfied (the conditional or "if" portion of the conditional statement), then one or more actions will be taken (the consequence or portion "Then" of the conditional statement). A rule is applied to model parameters if one or more model parameters are expressed in the conditional statement, or one or more model parameters are expressed in the consequence statement.

The term "constraint", as used herein, means that a constraint is applied to one or more model parameters. For example, in a city planning model, a private house element can be restricted to being placed in a map location that has a subset of the total possible area designations. A bridge element can be constrained below

IMPI »3 ^ a certain maximum length, or a certain number of lanes,

An author who is familiar with the model can provide expressions for these equations, rules, and restrictions that apply to that model. In the field of simulations, the author can provide an appropriate simulation engine that provides the appropriate simulation relationships between the model parameters. The modeling component 820 can provide a mechanism for the author to provide a natural symbolic expression for equations, rules, and constraints. For example, a model author related to thermodynamics can simply copy and paste equations from a thermodynamics textbook. The ability to bind model parameters to data fields allows the author to use any symbols the author is familiar with (such as the exact symbols used in author-based textbooks) or the exact symbols the author likes to use. .

Prior to resolution, the modeling component 820 also identifies which of the model parameters is to be resolved (ie, hereinafter, the "output model variable" if singular, or "output model variables "If the plural, or" output model variable (s) "if it is a single output model variable or plural output model variables). The output model variables can be unknown parameters, or they can be known model parameters, where the value of the known model parameter is subject to change in the solve operation. In the example in Figure 8, after the data model join operation. The parameters of INDUSTRIAL PROPERTY and 811C are known, the parameter of model 811D is unknown. Therefore, the unknown 811D model parameter can be one of the output model variables. Alternatively or in addition, one or more of the known model parameters 811A, 811B and 811C may also be output model variables. The solver 840 then solves for the output model variable (s), if possible. In an embodiment described below, solver 840 is capable of solving a variety of output model variables, still within a single model as long as enough input model variables are provided to allow the solve operation to be performed. The input model variables, for example, can be known model parameters whose values ​​are not changed during the solve operation. For example, in Figure 8, if the model parameters 811A and 811D are input model variables, the solver may rather solve the output model variables 811B and 811C. In one embodiment, the solver can output any of a number of different data types for an individual model parameter. For example, some equation operations (such as addition, subtraction, and the like) are applied regardless of whether the operands are integers, floating point, vectors thereof, or matrices thereof.

In one embodiment, even though the 840 solver cannot ³⁵ IMPI ^ solve a particular output model variable,

800 you can still present a partial solution for that output model variable, even if a full resolution to the actual numeric result (or anything solved for the data type) is not possible. This allows the pipeline to facilitate incremental development by prompting the author what information is needed to arrive at a complete solution. This also helps eliminate the distinction between authoring time and airtime, as at least a partial solution is available through the various stages of authoring. For an abstract example, suppose that the analytical model includes an equation a = b + c + d. Now suppose that a, c and d are output model variables, and b is an input model variable having a known value of 5 (an integer in this case). In the solution procedure, solver 840 is only capable of solving one of the output model variables "d", and assigns a value of 6 (an integer) to the model parameter named "d", but solver 840 cannot. is able to solve for "c". Since "a" depends on "c", the model parameter named "a" also remains unknown and unresolved. In this case, instead of assigning an integer value to "a", the solver can do a partial solution and produce the sequence value of "c + 11" to the model parameter "a". As mentioned previously, this can be especially useful when an analytical model is being created by a domain expert, and will essentially serve to provide partial information regarding the content of the model parameter "a" and will also serve for '· INDUSTRIAL ^ *. 3 ^ -3 some additional model analytics needs to be provided to allow the model parameter "c" to be resolved. This partial resolution result can perhaps somehow come out in the view composition to allow the domain expert to see the partial result.

The solver 840 is shown in simplified form in Figure 8. However, the solver 840 may direct the operation of multiple constituent solvers as will be described with respect to Figure 9. In Figure 8, the modeling component 820 then does to the model parameters (including the model variables now known and resolved for output) available as the output to be provided to the view portion 900 of Figure 9.

Figure 9 shows a view portion 900, which represents an example of the view portion 630 of Figure 6, and represents an example of controls displayed on the recalculation user interface 200. The view portion 900 receives the parameters Model No. 811 of the analytical portion 800 of Figure 8. The view portion also includes a view component repository 920 containing a collection of view components. For example, view component pool 920, in this example, is illustrated as including view components 921 through 924, although view component pool 920 can contain any number of components. The view components each include zero to more parameters of e

<img file="MX348639B_D0012.tif" />

view component 921 does not include any input parameters.

However, the view component 922 includes two input parameters 942A and 942B. The view component 923 includes an input parameter 943, and the vision component 924 includes an input parameter 944. That is, this is just an example. The input parameters may, but not necessarily, affect how the visual article is presented. The fact that view component 921 does not include any input parameters emphasizes that views can be generated without reference to any model parameters. Consider a view that comprises only fixed (embedded) data that does not change. Such a view, for example, may constitute reference information for the user. Alternatively, consider a view that only provides one way to navigate in a catalog, so that items from the catalog can be selected for import into a model.

Each view component 921 through 924 includes or is associated with corresponding logic that, when executed by view composition component 940 using the corresponding view component input parameter (s), if any, causes a view article corresponding to be placed in virtual space 950. That virtual article can be a static image or object, or it can be an animated, dynamic article or virtual object. For example, each view component 921 to 924 is associated with corresponding logic 931 to 934 which, when executed, makes the article virtual

951 to 954 corresponding, respectively, industrial virtual space 950. Virtual items are illustrated as simple shapes. However, virtual articles can be quite complex in form perhaps even including animation. In this description, when a view article is presented in virtual space, this means that the view composition component has created enough instructions that, when provided to the presentation engine, the presentation engine is capable of presenting the article of viewed at the presentation at the designated location and in the designated manner.

View components 921 through 924 may still be provided as view data to view portion 900 using, for example, authoring component 640 of Figure 6. For example, authoring component 640 may provide a selector that allows the author to select from various geometric shapes, or perhaps compose other geometric shapes. The author can also specify the types of input parameters for each view component, while some of the input parameters can be default input parameters imposed by view portion 900. The logic that is associated with each view component 921 to 924 may also provide view data, and / or may also include some default functionality provided by the same view portion 900.

The view portion 900 includes a model view attachment component 910 that is configured to attach at least some

IMPI ^

INSTITUTO MÍXICANO Λ parameters⁶ By is attached to the parameter of the corresponding model parameters a of the example components, the model parameter 811A input 942A of the view component 922 as represented by arrow 911A. Model parameter 811B is linked to input parameter 942B of view component 922 as represented by arrow 911B. Also, model parameter 811D is linked to input parameters 943 and 944 of vision components 923 and 924, respectively, as represented by arrow 911C. The 811C model parameter is not shown attached to any corresponding view component parameters, emphasizing that not all model parameters need to be used by the view portion of the pipeline, even if those model parameters were essential in the analytical portion. . Also, the 811D model parameter is shown linked to two different view component input parameters representing that the model parameters can be linked to multiple view component parameters. In one embodiment, the definition of the unions between the model parameters and the view component parameters can be formulated by 1) explicitly set by the author at authoring time, 2) explicitly set by the user at usage time (subject to any restriction imposed by the author), 3) automatically join by the authoring component 640 based on algorithmic heuristics, and / or 4) prompting, by the author and / or user authorship component, to specify a union

IMPIí

INSTITUTO MEXICANO \ cua ^ ee a union cannot be made aijnrítm¡r₃m_tont_to

The present invention will be embodied in other specific ways without departing from its spirit or essential characteristics. The modalities described are to be considered in all respects only as illustrative and not restrictive. The scope of the invention, therefore, is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and equivalence scale of the claims will be encompassed within their scope.