Abstract: Displaying a visualization of ranked elements over a selected dimension. The method includes determining a user selection of a ranking function for a plurality of elements. The ranking function defines a core value to be ranked. The method further includes determining a dimension over which the core value of the ranking function output can change. The method further includes animating a relevant number of the elements over time. A time value of the animation correspond to values of the dimension. Animating includes displaying elements in prominence corresponding to the result of the output of the ranking function.

Abstract: Suggesting replacements for search sub-strings to a user. A method includes receiving a query string from a user including a plurality of search sub-strings in the query string. The method further includes determining semantically valid replacements of one or more search sub-strings in the query string. The method further includes suggesting to the user semantically valid replacements of one or more of the search sub-strings to allow the user to modify the original query string.

Abstract: Smart defaults are provided for data visualization by creating a default layout of rows, columns, filters, and comparable elements that improve a user's experience in finding relevant answers within the data. Usage history of the ways that users look at data in various data sources, user specific information, and inferred relationships between a current user and similar users are used to determine elements relevant to visualization of data for a particular user such that the visualization process may be automatically started, and a relevance model is formed/adjusted based on these factors. Queries may also be executed in a preemptive fashion based on the relevance model and results provided to a requesting user more rapidly enhancing user experience with networked data visualization.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: An interface for designing a report is provided, with elements of the report being disposed at intersections of report positions and configured to present information derived from data in a database. A formula is associated with one or more selected elements in the report to generate a result for the one or more selected elements. A tuple identifying the report positions of the one or more selected elements is associated and stored with the formula in a formula list associated with the report. The report is configured so that, when the report is generated, it is determined whether identifying report positions corresponding to an identified element in the report correspond with the tuple in the formula list. Upon determining the tuple corresponds with the identifying report positions for the identified element, the formula associated with the tuple is applied to generate the result.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Smart defaults are provided for data visualization by creating a default layout of rows, columns, filters, and comparable elements that improve a user's experience in finding relevant answers within the data. Usage history of the ways that users look at data in various data sources, user specific information, and inferred relationships between a current user and similar users are used to determine elements relevant to visualization of data for a particular user such that the visualization process may be automatically started, and a relevance model is formed/adjusted based on these factors. Queries may also be executed in a preemptive fashion based on the relevance model and results provided to a requesting user more rapidly enhancing user experience with networked data visualization.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Architecture that employs a journal assignment that can be created on demand when journal is created, and operates outside the business cycle. The assignment is routed to reviewers and approvers based on predefined company policy that users define. The assignment encloses a changelist of data changes created by the journal. The changelist is used for rendition and calculation for reviewers and approvers (in addition to the journal contributor) to view/verify and modify the data as if the data is already written into the model. At the time that other users access this model, the data is not present. At the end of the successful workflow chain the changelist is written into the model. If failed, the changelist will be used as that basis for correction or the user can discard the changelist.

Abstract: A user interface displays a group of related documents such that bulk operations may be performed on them without requiring the user to individually access each document to perform an action. Properties, such as a status, contributor information, submission date and submission deadline and the like are also displayed with the documents. From this information, a user may decide to open a specific document and/or version of the document for review while bulk approving the other displayed documents. A user may perform an action on all or part of the displayed documents and their versions from the user interface. In this way, the efficiency of the workflow may be increased since the user doesn't have to individually access each document to perform the action.

Abstract: An interface for designing a report is provided, with elements of the report being disposed at intersections of report positions and configured to present information derived from data in a database. A formula is associated with one or more selected elements in the report to generate a result for the one or more selected elements. A tuple identifying the report positions of the one or more selected elements is associated and stored with the formula in a formula list associated with the report. The report is configured so that, when the report is generated, it is determined whether identifying report positions corresponding to an identified element in the report correspond with the tuple in the formula list. Upon determining the tuple corresponds with the identifying report positions for the identified element, the formula associated with the tuple is applied to generate the result.

Abstract: A scalable workflow management system is provided that includes queues for storing work items to be processed. Work items may be placed into the queues by front-end services executing within the workflow management system. When a work item is placed on a queue, it remains on the queue until an appropriate back-end service is available to de-queue the work item, validate the de-queued work item, and process the de-queued work item. Separate queues are provided for storing normal work items, work items generated according to a time schedule, and work items generated by job launching services. The state of operation of the workflow management system may be controlled by an administrative console application.