GRAPHICAL USER INTERFACE TOOL
BACKGROUND OF THE INVENTION
1. Field of the Invention
The field of the invention is graphical user interface tools, especially graphical user interface tools which retrieve data that defines the relationship between entities in a network, which analyse that data to generate data that defines the network relationships (i.e. generates a "data relationship network") and which then graphically depict or display that data relationship network to form a graph or a "data relationship map".
The invention can be applied to any network that connects physical entities, such as servers and switches on a computer network, as well as logical entities, such as customers, accounts, transactions, and business process workflows, so long as there is some form of relationship between those entities.
2. Technical Background
Analysing the relationships in data, without the use of a graphical interface which can display data in the form of a graph, is difficult to achieve. Analysing the data as a list of rows and columns, as in spreadsheet programs such as Microsoft (RTM) Excel (RTM) requires focused concentration on the part of the analyst and is tiring and time consuming. To overcome this, graphs are used to provide a graphical representation of a data relationship network. However, at present the market place does not offer a graphical user interface tool to bring together system integration for retrieving required data relationship network data and for the graphical viewing of the data relationship network.
There are two common techniques for rendering a network of relationships in a graph, in which a thick desktop client communicates with a remote server or using web browser technology communicating with the server. These are as follows. A thick client application operates on a desktop personal computer (PC) provides the technology to visualise in a graph the data that has been developed in a specific manner for a specific business domain. This means that the data structure and how the graph can be interacted with cannot be utilised outside of the specific business domain. Desktop PC clients introduce the issue of needing to be deployed and maintained on each client machine, and in a large corporation with many users the deployment and maintenance can be an expensive approach. Deployment and maintenance can also be expensive on a per user basis in smaller corporations.
Using a browser-based technology overcomes the issue of deployment. This involves users connecting to a Universal Resource Locator (URL) and the graph being displayed in the browser window using technologies such as Scalable Vector Graphics (SVG) or Macromedia Flash (RTM). The drawback of SVG is that it does not perform well in terms of user interaction. Macromedia Flash (RTM) provides the user interaction but does not provide a simple solution to introducing new features. While both of these technologies overcome some of the visualisation issue they do not address how to retrieve the data from a disparate set of source repositories. Typically, restricting data shown to the user will be performed through the use of database queries with roundtrips to the database taking place to retrieve new, filtered data. This provides a usability issue to the end users while they wait for retrieval of data leading to frustration and a lack of desire to use the system, especially where users wish to change the filters applied.
3. Discussion of Related Art
It is known to graphically present relationships between data items to an end user. There are a number of applications available that will show these relationships. For example, in the telecommunications industry users view telecommunication hardware network topologies and the users possess software to do this. SUMMARY OF THE INVENTION
A graphical user interface tool is provided that is operable (i) to use meta-data associated with entities in a network by analysing that meta-data to extract relationships between some or all of the entities in the network and then (ii) to graphically depict or display the relationships.
The graphical user interface tool may be operable with a hardware system including a database server, a presentation server and a user work station, the graphical user interface tool combining data processing at the presentation server and at the user work station when extracting relationships in the analysis of meta-data retrieved from the database server and stored in a data cache, the extracted relationships forming a data relationship network.
The graphical user interface tool may be one in which the tool uses meta-data to describe attributes of the extracted relationships.
The graphical user interface tool may be one in which the extracted relationships are rendered as a data relationship network map.
The graphical user interface tool may be one in which the data stored in the data cache is filtered without further interrogation of the database server.
The graphical user interface tool may be one in which push technology is used to provide real time updates to the data cache.
The graphical user interface tool may be one in which the relationship extraction is metadata driven such that the meta-data allows a data relationship network to be described in terms of Node Types, Link Types, Link Styles, Subset Effects and Filters.
The graphical user interface tool may be one in which Link Styles may be configured.
The graphical user interface tool may be one in which Subset Effects may be configured. The graphical user interface tool may be one in which relationship extraction analysis is performed using meta-data driven queries.
The graphical user interface tool may be one in which configurable and flexible user interface components are provided for mapping a network of relationships.
The graphical user interface tool may be one in which the tool operates in a web browser environment.
The graphical user interface tool may be one in which new database server queries can be quickly added to an existing set of database server queries.
The graphical user interface tool of may be one in which all sources of information can be merged together either in a single set of data passed to the presentation server and to the user work station, or as multiple data sets which can be merged on the presentation server and the user work station.
The graphical user interface tool may be one in which a Network Analyser is used to retrieve data from the database server.
The graphical user interface tool may be one in which the Network Analyser uses hardware network topology meta data to provide high performance and targeted analysis of the data stored within the database server.
The graphical user interface tool may be one in which the data retrieved from the database server is any data in XML format that exposes a relation between entities.
The graphical user interface tool may be one in which the data can expose explicit relationships through the data itself.
The graphical user interface tool of may be one in which some or all the data can have implied relationships where the relationships in data are exposed as a consequence of the data structure. The graphical user interface tool may be one in which the approach is to use a query language such as SQL, XPath or XQuery to provide the definitions of the data relationships.
The graphical user interface tool may be one in which a configuration file of the graphical user interface tool can be edited either through an integrated development environment (IDE) or direct using a text editor.
The graphical user interface tool may be one in which Node Types are configured at design time through a designer interface.
The graphical user interface tool of may be one in which a Node Type is configured by editing a meta-data description of the Node Type directly.
The graphical user interface tool may be one in which a Link Type is that of an implied relationship.
The graphical user interface tool may be one in which a Link Type is that of an explicit relationship.
The graphical user interface tool may be one in which the Link Styles have implied attributes for handling values for two ends of a Link.
The graphical user interface tool may be one in which extracted relationships are defined in terms of Edges, Nodes and Relations.
The graphical user interface tool may be one in which the tool provides filtering for Edges, Links, and Activity.
The graphical user interface tool may be one in which a user may interact with the data relationship network map data by deleting nodes or by moving nodes.
The graphical user interface tool may be one in which a user may open new windows, popup windows providing summary information. The graphical user interface tool may be one in which a user may enable or disable the display of node and link labels.
The graphical user interface tool may be one in which a user may zoom in and out on regions of the data relationship network map.
The graphical user interface tool may be one in which a client database stores the data in an XML structure and queries are performed using the XPath query language.
The graphical user interface tool may be one in which an initial request to the database server populates the data cache with all data required by the user.
The graphical user interface tool may be one in which an initial request to the database server is followed by a response, followed by the detailed data pushed to the data cache by the database server when the data is available.
The graphical user interface tool may be one in which the data analysis approach is to use Predictive analysis of data within a framework that allows additional queries and requests to multiple disparate data sources to be provided through configuration of the tool.
The graphical user interface tool may be one in which sources of data and the configuration of accessing the sources of data are stored as meta-data in configuration files.
The graphical user interface tool may be one in which meta-data can be maintained statically by editing a configuration file.
The graphical user interface tool may be one in which meta-data can be maintained dynamically at runtime by inserting new meta-data.
The graphical user interface tool may be one in which the Network Analyser is implemented using a key to identify Node Types and from these Node Types a set of queries or service requests are assigned to determine the sources of data to be queried. The graphical user interface tool may be one in which Relation Query Groups provide a mechanism to group a set of logic that uses a seed node to find related nodes or links to other nodes.
The graphical user interface tool may be one in which the data source is one or more of Web Service, Database, flat file, or HTTP.
A graphical user interface tool is provided which is operable with a hardware system including a database server, a presentation server and a user work station, the graphical user interface tool combining data processing at the presentation server and at the user work station to analyse relationships in data retrieved from the database server and stored in a data cache, thereby generating a data relationship network.
A computer program product is provided, the computer program product running as a graphical user interface tool that is operable (i) to use meta-data associated with entities in a network by analysing that meta-data to extract relationships between some or all of the entities in the network and then (ii) to graphically depict or display the relationships.
The computer program product may be one in which the computer program product runs as a graphical user interface tool which is operable with a hardware system including a database server, a presentation server and a user work station, the graphical user interface tool combining data processing at the presentation server and at the user work station when extracting relationships in the analysis of meta-data retrieved from the database server and stored in a data cache, the extracted relationships forming a data relationship network.
The computer program product may be one in which the program uses meta-data to describe attributes of the extracted relationships.
The computer program product may be one in which the extracted relationships are rendered as a data relationship network map.
The computer program product may be contained on a data carrier. A method of presenting information is provided, the method including the step of using a graphical user interface tool as described in this document.
A method of presenting information is provided, the method including the step of using a computer program product as described in this document.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 shows the use of a graphical user interface tool which is an example of the invention. Figure 2 shows the concepts of Nodes, Edges and Relationships for a set of customers in a financial environment
Figure 3 shows example data exposing explicit relations for a link between two nodes.
Figure 4 shows an example of where implied relationships occur, where the structure of the data provides the definition of the links between nodes. Figure 5 shows a user interface for configuring the attributes of an Altio (RTM) Graph node.
Figure 6 shows a meta-data description which may be edited for configuring the attributes of an Altio (RTM) Graph node.
Figure 7 shows an example of where a customer node is linked to two purchase nodes. Figure 8 shows a graph resulting from the explicit data relationship network using XML data and the definitions from Figures 31, 32 and 33. This graph has two nodes and a link between them.
Figure 9 shows the attributes in the designer, associated with Figure 8.
Figure 10 shows the configuration meta data, associated with Figures 8 and 9. Figure 11 shows an example of Link Types attributes as used in Altio (RTM) Graph.
Figure 12 shows the meta-data that is saved to the configuration file in the case of Figure
11.
Figure 13 shows an example of grouping by Link Style which provides the addition of totalling all values for links of different Link Types. Figure 14 shows an example of how Subset Effects can be modified at run time through a user interface to provide dynamic visual effects on the displayed graph.
Figure 15 shows an example of how a Subset Effects configuration can be saved as XML meta-data.
Figure 16 shows an example in which Node A has four Edges and thus four relations to related Nodes. The values from the Edges accumulate on the node, and the Edge totals are an accumulation of the link values in the edge.
Figure 17 shows an example of how a Filter Type can be configured through the user interface. Figure 18 shows an example of how a Filter Type can be configured through the metadata.
Figure 19 shows an example of how the Value of a filter can be changed at runtime and be applied immediately to the graph. Figure 20 shows an example of a case in which for a data relationship network graph, the data has been retrieved and then transmitted to the user where it is displayed. Once data is available, typically the user will want to interact with that data by applying filters that affect what will be shown in the graph.
Figure 21 shows how in a typical web based system, data is retrieved on request. This will mean that details about a Node or Link will need to be retrieved each time a user interacts with the data. This imposes further latency due to the server roundtrip time.
Figure 22 shows, in contrast to Figure 21, an approach which involves an initial request to the server that populates the client database cache with all data required by the user.
Figure 23 shows, in contrast to Figures 21 and 22, an approach which enables users to interact with the initial set of data while the details are cached as a background process.
Figure 24 shows a data relationship network for which the common practice is to use
Nodes, Links and Edges.
Figure 25 shows an example of the logical relationship of a Query Group to Relation
Query objects. Figure 26 shows a configuration for a class AdhocRelationQueryGroup.
Figure 27 shows the concrete class implementation of the configuration of Figure 26.
Figure 28 shows the configuration of a Relation Query object for a database query, where two configurations of the same class take place.
Figure 29 shows an example of XML and the XPath statement that can be used to identify a data source for a node.
Figure 30 shows an example of where there is an implied relation from PURCHASE to
CUSTOMER because PURCHASE is a child element. This is an example of an implied data relationship network definition using XPath.
Figure 31 shows example XML in which explicit relations are defined between node elements and link elements. This continues in Figure 32.
Figure 32 shows example XMT, in which explicit relations are defined between node elements and link elements, continued from Figure 31. This continues in Figure 33.
Figure 33 shows example XML in which explicit relations are defined between node elements and link elements, continued from Figure 32. Figure 34 shows in Java an example of an interface declaration for a Query Group.
Figure 35 shows a Java declaration for a query group which is the same as for the
Relation Query interface shown in Figure 25.
Figure 36 shows an example of a concrete class implementing a database query. The text continues in Figure 37.
Figure 37 shows an example of a concrete class implementing a database query, where the text continues from Figure 36.
DETAILED DESCRIPTION
The Altio (RTM) Graph graphical user interface tool which is used to represent a data relationship network visually to a user is described. Contained in the description is a high level architectural description of significant components.
This document describes the architecture of Altio (RTM) Graph and the data integration layer Altio (RTM) Graph Network Analyser. Significance lies in the provision of configurable and flexible user interface components for mapping a network of relationships.
Overview
The Altio (RTM) Graph tool is designed to provide a graphical representation of data. However, at present the market place does not offer a generic tool to bring together system integration for retrieving required data and for the graphical viewing of this data. One feature of the Altio (RTM) Graph tool is that it overcomes this limitation.
The Altio (RTM) Graph control provides a means to graphically present relationships between data items to an end user.
Altio (RTM) Graph is not specific to a particular business domain (eg. inside one particular firm) and provides the following features in a generic framework:
• Operates in a web browser environment • Zero latency filtering and user interaction with underlying data.
• Real time updates to the data visualised
• Meta-data driven data relationship network analysis
Altio (RTM) Graph provides a flexible user interface and once the initial data has been loaded from source locations the data can be filtered using zero latency techniques that do not require further roundtrips to the data source location. Zero latency data analysis allows users to apply filters to the information displayed in the graph and has the effect of the filter being applied instantly, or after a very short time period. It also allows the filter to be removed without the need to perform a request to the server. Retrieval of the initial network data is provided through a framework that enables new database queries to be quickly added to enhance the network data without the need for a large development cycle or for modification to existing code. It is also possible to use standard Altiolive integration features to connect to web services, message queues etc. All sources of information can be merged together either in a single set of data passed to the client or as multiple data sets which can be merged on the client. Data can also be pushed to the client from the server when updates occur. This provides real-time feedback to the user of a system that changes to the original data are occurring.
Altio (RTM) Graph Architecture
The architecture of the Altio (RTM) Graph conforms to a typical web based application. The web browser provides access to the application on the client desktop, laptop or other computer, but does not install software on the computer. Altio (RTM) Graph is provided to the client platform through Altiolive which in turn is hosted within the web browser. Communication is handled through HTTP or HTTPS polling or streaming.
The server can be configured to retrieve the required network data using standard Altiolive integration components such as Java Database Connectivity (JDBC), Web Services or by using the Network Analyser; the Altio (RTM) Graph Network Analyser uses network topology meta data to provide high performance and targeted analysis of the data stored within a database or other data source.
The hierarchy of the components is shown in Figure 1 with the start of the process taking place at the workstation when a user makes a request to open the Altio (RTM)
Graph client application. The user will do this by selecting on an existing web page a hyperlink to a URL, or by entering a new URL into the web browser. A seed point is required to enable a graph to be initiated, this seed providing the focus for all searches for related data. In a telecommunications environment this seed point may be the identifier of a router; in a fraud investigation this may be a customer or account identifier.
The Network Analyser is used to retrieve data from the database. It is designed to take the seed data and execute a sequence of queries on the database based upon the seed data type. Discovered entities related to the seed data become new layers to the data relationship network and these entities are used as the next seed point for a further iteration of queries. This allows for a complex data relationship network to be formed based upon meta-data that determines the order and types of queries to be executed. To control the length of time the data is analysed a number of constraints will be applied to the analysed data to ensure the data relationship network does not grow out of control.
A typical social graph is shown in Figure 2 which shows the concept of Nodes, Edges and Relationships for a set of customers in a financial environment. Nodes are the entities, such as a Customer, Account and each Node may join to none, one or many other nodes via a Relationship. An Edge is the connection point with a Node and a Node may have many edges.
An Edge and Relation can contain one or more links. This will occur where there are multiple links between the entities, for example two bank accounts can have many transactions between them.
Network Relation Graph Meta Data
An important aspect of the Altio (RTM) Graph control is its ability to work with any data in XML format that exposes a relation between entities. This means data can expose explicit relationships through the data itself or can have implied relationships where the relations in data are exposed as a consequence of the data structure.
Explicit relationships will use the same principles as seen in relational databases, where primary keys provide unique identification of an entity. The primary key is duplicated as a foreign key to a related entity.
Example data exposing explicit relations can be seen in Figure 3 which shows a link between two nodes. The primary key is the type and id (identification) attributes of the node elements; the link element that contains nodeRef elements contains the foreign keys. Implied relationships occur where the structure of the data provides the definition of the links between nodes. This is shown in Figure 4 where the CUSTOMER element contains sub-elements called PURCHASE. This tree hierarchy provides the implied relationship with the purchase being related to a customer by the fact of the purchase being a child element. This structure is typically represented in user interfaces as a tree of data.
Data relationships need to be identified and then a method of defining the relationship is required. The relationship definition can be explicitly built into the software code, but the issue with this is that it is a very inflexible approach which restricts the maintainability and customis ability of the system. An alternative approach is to use a query language such as SQL, XPath or XQuery to provide the definition of the relationship. Injection of the definition through configuration files and provision of a generic framework to handle the processing of the network definition is achieved by Altio (RTM) Graph, freeing the constraints upon how network relations are designed.
The configuration file can be edited either through an integrated development environment (IDE) or direct using a text editor, ensuring low maintenance costs and the ability to make quick modifications when new data sources are required. This overcomes the issues of cost associated with having to re-engineer software every time changes to a system using Altio (RTM) Graph are required.
An essential part of defining relationships between data is identifying the key attributes within the data. Once identified, being able to describe the attribute relationships in meta-data provides the foundation of Altio (RTM) Graph. The Altio (RTM) Graph meta-data allows a graph to be described in terms of Node Types, Link Types, Link Styles, Subset Effects and Filters.
Node Type
A node is the focal point of relationships in the data relationship network graph. It can represent a physical object or it can represent an intangible item of interest such as an electronic transaction.
The attributes of an Altio (RTM) Graph node are:
• Name - provides a unique identification of the node
• Data Source - defines data source of the node being displayed in the graph • Label - provides a description of the node, or the label can be generated using XPath expressions.
• Tooltip Parameter — provides the definition of how to render a tooltip. The tooltip appears in the graph when a user pauses their mouse pointer at an object. • Shape - if no image is available a shape provides the visual identification of the node.
• Image - an image can be used to provide the visual identification of the node.
• Size — how large the image should be in relation to other nodes in the graph.
• Light Colour, Dark Colour — this provides the Shape with the colours to use for rendering the shape
• Font Style - each node can have its own font style
• Label Orientation - positioning of the label in relation to the node image.
These attributes form the basis of where the data comes from and how a node is to be shown to a user. These are configured at design time through the designer (Figure 5) or by editing the meta-data description directly (Figure 6).
It is possible to define many Nodes each with a different data source, ensuring flexibility in types of nodes that can be displayed. The important factor in determining a Node is the data source — Figure 29 shows an example of XML and the XPath statement that can be used to identify a data source for a node.
Link Type
Defining links through the use of meta-data is more complicated than the definition for a node. The attributes required and how they are exposed affect the flexibility of a solution for providing data relationship network visualisation in a graph.
Where the data representing a network offers implied relations, only two attributes are required: that of the parent XMT, element and that of the data source. This can be seen in Figure 30 where there is an implied relation from PURCHASE to CUSTOMER because PURCHASE is a child element.
Attributes of an implied relationship are • Data Source - the data that infers the relation between node and its parent
• Link to Parent - the identifier for the parent element.
An implied data relationship network definition using the XPath as described in Figure 30 results in a graph being displayed with three nodes being drawn - two purchase nodes and a customer node. The customer node is linked to both purchase nodes, as shown in Figure 7.
Attributes for an explicit relationship definition require identification of the foreign and primary keys of the A and B ends of the data relationship network. This is now explained.
The attributes of an explicit relationship definition are:
• Name — an identifier that provides a unique reference for the link between two nodes
• Data Source - defines an actual element in the XML that forms the data for the link.
• Node A Type - the type of node that forms the A end of the link, this will need to have been defined a Node Type. • Node A Foreign Key - an XML attribute or element of the Data Source XML element that provides a reference to the primary key of the A end Node.
• Node A Primary Key - the XML attribute or element of the Node A Type element that provides the identification of the Node A Foreign Key. Both Node A Foreign Key and Node A Primary Key will need to have the same value returned for a link to be identified.
• Node B Type, Node B Foreign Key, Node B Primary Key operate the same except that they refer to the B end of the link.
• Value - if a link has a value associated with it this attribute is used to define the XPath to the value within the XML. • Direction — where a link has direction this defines whether it is from A to B or B to A. The direction will be presented using an arrow head. A Link Type also has an appearance attribute "Link Style", which controls the appearance of the link when shown to the user. Link Styles are described later in this document.
In the example XML in Figures 31, 32 and 33 (the text running from Figure 31 into Figure 32 and then into Figure 33) explicit relations are defined between node elements and link elements. The link elements in the example contain sub-elements nodeRef which provide explicit reference to the A and B ends of the link.
The explicit data relationship network using XML data and the definition from Figures 31, 32 and 33 results in a graph shown in Figure 8. This graph has two nodes and a link between them.
The attributes in the designer are shown in Figure 9, with the associated configuration meta data shown in Figure 10.
There can be many Link Types defined between two nodes, and a Link Type can have many data elements found between two nodes. An example of this is two bank accounts where multiple transactions take place between the accounts.
Link Styles
Link Types provide the ability to define the links between nodes using the data within XML. A Link Type has a visual representation which is provided by the Link Style. Link Styles provide the means to define multiple different attributes to be associated with a link:
• Colour - the initial colour of the link
• Maximum Colour - the colour to use if the link reaches a maximum size and there is a requirement to highlight this to the user. • Line Style — the type of line used to represent the link
• Font Style — The font to be used for labels shown on the link
• Line Width - minimum size of a line
• Maximum Width - maximum size a line should grow to. This is only relevant where a link has a value. • Popup Renderer - allows a class to be written which will handle displaying a customised tooltip. The tooltip is displayed when a user hovers the mouse cursor over a link.
These attributes as used in Altio (RTM) Graph can be seen in Figure 11 and the meta data that is saved to the configuration file is shown in Figure 12.
Link Styles have implied attributes for handling values for the A and B ends as well as a value for links that have no direction. As a Link Type represents a single type of link between nodes multiple links of the same type will have an accumulative effect on values. Visually users are presented with the total value of all links between the related nodes.
A Link Style can be used by multiple Link Types. This means different Link Types can be visually grouped together. This grouping by Link Style provides the addition of totalling all values for links of different Link Types (Figure 13).
This is a powerful feature of Altio (RTM) Graph which allows different types of data to be grouped visually in different combinations without the need to make changes to the underlying logic needed to retrieve the data.
Multi Match Line Style
By introducing the concept of a Link Style and having the ability to have multiple Link Types and thus Link Styles between nodes necessitates the need to handle multiple types of links between nodes. This is achieved by being able to configure a Multi Match Link Style for the graph as a whole.
A Multi Match Style is an attribute of the Altio (RTM) Graph itself and provides a reference to a defined Link Style which is used when more than one Link Style is associated with two nodes. Visually the links between the nodes provide a different appearance to indicate the complexity of the relationship.
Subset Effects In some scenarios it may be necessary to visually identify specific Nodes or Links within the graph. This is achieved through the use of Subset Effects. Subset effects can be modified at run time through a user interface to provide dynamic visual effects on the displayed graph. This provides a unique ability for users to interact with the graph and change the Nodes or Links affected by the Subset Effect (Figure 14).
The attributes available to Subset Effects are:
• Node/Link Type — the object in the graph that the Subset Effect is applied to (NODE or LINK). • Exclude From Filters — prevents Nodes or Links from being considered for filters and so they will never be removed from the graph, filters in Altio (RTM) Graph are discussed later in this document.
• Data Source — the data in the cache that should be affected by the settings of the Subset Effect. • Highlight Colour — provides a means to place a highlight around the affected object
• Transparency % - causes the identified objects for the Data Source to become transparent to the % specified.
• Grey Out — causes the identified object for the Data Source to become grey.
As with all features of the Altio (RTM) Graph, the configuration is saved as XML metadata (Figure 15).
Filtering Nodes
Altio (RTM) Graph provides filtering for Edges, Links, and Activity - total, in, out and middle.
An Edge filter applies to the number of Edges (unique relations) on a node, the filter works by counting the unique Edges on a node. A Link filter is applied to a relation between two nodes, and works by counting the number of individual links in that relationship and applying a filter to it. Activity filters apply to Nodes and the total value of a Node based upon the values provided by Links. Links can have inbound and outbound values and a value with no direction. A Node value is the total of all the Links contained in an Edge associated with the node — there will be a total value for in, out and middle values in a relationship.
In Figure 16, Node A has four Edges and thus four relations to related Nodes. The values from the Edges accumulate on the node, and the Edge totals are an accumulation of the link values in the edge.
The Filter Types that can be applied to Nodes on a graph are:
• EDGETHRESHOLD - the number of unique edges (relations) that exist on a node.
• LINKTHRESHOLD - this filter applies to the number of links contained in a Edge (relation). • ACTIVITYTOTAL - this applies to a node and is the total amount of activity on the node. Total activity on a node is the sum of inbound and outbound values, of all the edges associated with a Node.
• ACTIVITYIN - this filter applies to an Edge and is the sum of total inbound link values. • ACTIVITYOUT - this filter applies to an Edge and is the sum of the total outbound link values.
• ACTIVITYMIDDLE - this applies to the non-directional total value on a relation between two nodes.
For filters to be effective they require an operator, an order of execution and a value. The configurability of Altio (RTM) Graph allows multiple filters to be applied to the graph for the same Filter Type, so it is possible to have a minimum and maximum value or combinations of values applied to a single focus item.
A Filter Type can be configured through the user interface (Figure 17) or through the meta-data (Figure 18). To provide effective usability the Value of a filter can be changed at runtime and be applied immediately to the graph (Figure 19). The immediacy of applying filters provides one feature of the zero latency interaction provided by Altio (RTM) Graph.
Zero Latency Interaction
The effectiveness of a graph is gauged through the usability of the overall system as well as the accuracy of the data. A web application imposes numerous issues that need to be overcome. Common issues are associated with • keeping the application small to reduce the time it takes to download
• responsiveness to user interaction
• rich user interface required for complex interaction
The speed of internet connections provided by the high bandwidth available today mitigates the majority of issues associated with application size. User expectation does mean that they expect instant availability and will become impatient if the system is not available quickly and once available is not responsive - this is a challenge overcome by Altio (RTM) Graph.
A key to providing a user responsive environment allowing the user to interact with the graph lies in zero latency. Latency is the time it takes of the application to respond to an action. If a user performs an action in a typical web application then the logic is performed on the server and the result returned to the user. In the case of a data relationship network graph the data needs to be retrieved and then transmitted to the user where it is displayed. Once data is available, typically the user will want to interact with that data by applying filters that affect what will be shown in the graph (Figure 20).
Typical features expected in a rich user interface for a data relationship network graph are: • ability to interact with data, opening new windows, popup windows providing summary information
• applying filters to the data held in memory without the need to re-query the database and wait for the results.
• Interact with the graph data, deleting nodes or moving them. • Enable or disable the display of node and link labels.
• Zoom in and out on regions of the graph
In the case of filters, users may wish to then remove the effects of the applied filter. While this could be achieved using client server roundtrips this will be affected by hardware network latency. The solution is to provide all the functionality on the client machine, in a lightweight container.
Client Side Data Caching
To produce a data relationship network graph in a traditional web application environment will require the server to generate the data relationship network data and supply it back to the client. All filtering of the data will be applied on the server side and so any change to filter values requires a further roundtrip request to the server to re- generate the data relationship network data using the new filter parameters. The latency in execution caused by hardware network roundtrips reduces the overall usability of the system and impacts user satisfactions.
In a typical web based system data is retrieved on request. This will mean that details about a Node or Link will need to be retrieved each time a user interacts with the data. This imposes further latency due to the server roundtrip time (Figure 21).
Zero latency user interaction requires the data to be cached within the client environment. To achieve maximum flexibility it is important to be able to dynamically manipulate the data within the cache. The manipulation of the data occurs either through user interaction or server changes being propagated to the client, and feedback to the user is instantaneous, or it occurs in a very short period of time.
The client data cache is only a subset of the data available on the server and will be specific to the graph being displayed but this will provide the user with all the information required to perform their duties. The graph control interacts with the client data cache by applying filters or to display further details not already displayed. Filters affect the data made available for visualisation and displaying details makes use of data which exists in the client cache - all achieved without further requests to the server. The Altio (RTM) Graph client database stores the data in an XML structure and queries are performed using the XPath query language.
Several approaches to retrieving data and caching it in the client are available and are discussed in this section.
The simplest approach involves an initial request to the server that populates the client database cache with all data required by the user (Figure 22). This initial request returns the data relationship network data required to draw the data relationship network graph and this will be the one and only hardware network request to the server unless a different set of data relationship network data is required.
An alternative approach involves separating the data into parts and delivering the data to the client in multiple parts. Each individual part of the overall data set can be delivered either in the background with no further user interaction or on an as-required basis. The choice of approach is dependent upon the volumes of data being handled. In a high data volume environment it may be necessary to deliver in the first request/ response a summary of the data and then using server push technology supply details in smaller chunks. This approach enables users to interact with the initial set of data while the details are cached as a background process. This process is shown in Figure 23 which shows the initial request and response, followed by the details data pushed to the client by the server when the data is available.
The approach of improving user satisfaction by delivering the data in multiple packets pushed from the server. This provides the means by which the user will be able to access details without the need to initiate a new request to the server. The same push technology is used to provide real time updates to the data cache ensuring clients have the latest data available.
Network Analysis using meta-data driven queries
Analysis of data to provide a network of data relationships can be achieved through Predictive or Exploratory Data Analysis, each approach having strengths and weaknesses - these approaches are often found in data mining. Predictive analysis involves making use of predefined queries and requests to other systems for the required data. The locations of the data and the structure of the queries as well as parameters required to execute are all pre-determined. This provides a predictive approach to analysing the data and will result in a pre-determined set of relationship types and node types, and a consistent data set based upon the same seed point. This approach to analysing the data is efficient and provides the fastest response time to the user. The major risk to performance is the source of the data not being optimised to return data as quickly as possible.
Exploratory Data Analysis is more complex and involves identifying potential relationships in data based upon matching values regardless of context within which the data is found. The technique involves analysing individual data items contained in a starting entity and then locating matches in data within other sources. An example for this would be taking a person's name and looking for the text in other data fields in a database. In a pure form this would allow free analysis of all data, but this requires huge amounts of processing power much like that provided in grid computing. This can be refined by constraining the data to be used for analysis but response times to users would make usability difficult and only valid for critical issues and where response time is not a factor. This approach may also impact the systems supplying the data if searches take place on un-structured data sources that the source system was not designed to handle.
The Altio (RTM) Graph solution is to use Predictive analysis of data but within a framework that allows additional queries and requests to multiple disparate data sources to be simply provided through configuration.
Altio (RTM) Graph makes use of server side components to integrate with databases, web services and message queues. The support for this is primarily provided through Altiolive but a specific component for querying databases for relationships is provided in a component called the Network Analyser. In both AltioLive and the Network Analyser the sources of data and the configuration of accessing the systems are stored as meta-data in configuration files. This meta-data can be maintained statically by editing the configuration file or dynamically at runtime by inserting new meta-data into the running system. Static edits of the configuration means the changes are only available on system restart.
A significant feature is in how the Network Analyser is implemented. A key is used to identify Node Types and from these Node Types a set of queries or service requests are assigned to determine the sources of data to be queried. A service request may be a Web Service or REST service or any other Web 2.0 data feed which support XML data. Each service request will use the seed data provided to execute requests or queries.
A wrapper object around service requests and queries provides a consistent means to execute an individual item of work without the need for the calling system to know what is being executed. The wrapper objects, known as a Relation Query, and their contained logic are grouped into Query Groups and these query groups are executed based upon the type of data used to seed the execution.
A generic framework in which to perform data relationship network analysis requires an underlying infrastructure that represents a data relationship network. This infrastructure is provided through a class object model containing interfaces that provide the template for the methods /events that a concrete class should implement. For a data relationship network the common practice is to use Nodes, Links and Edges as shown in Figure 24.
This structure is used by the Query Group to generate the data relationship network. Using the concept of an interface as defined by Java, Smalltalk, C++, C# etc. a specific method is used to provide the means to generate the data relationship network is declared.
The declaration of the method contains two parameters. The first provides the seed point for performing the execution of queries or service requests: the Node. The second parameter to the method/event is a name value pair of additional parameters that can be used during execution of queries.
These parameters provide a declaration as shown below:
NetworkGroup.execute(Node, Params) N etworkQuery. execute (N ode, Params)
The name value pair parameter provides means to pass loosely coupled parameters, ensuring flexibility in the use of the method/event when implemented by a concrete class. This concrete class is an actual implementation of the interface the concrete class performs, for example, the task of querying a database or executing a request to a web service but is not limited to these execution types.
Relation Query Group and Relation Query
Relation Query Groups provide the mechanism to group a set of logic that uses a seed node to find related nodes or links to other nodes.
In Java the interface declaration for a Query Group will be similar to as is shown in Figure 34.
In the simplest form the concrete class will simply loop through the Relation Query objects executing them in sequence or as a controlled parallel group. The control over if a query executes in parallel with the other queries or sequentially is controlled through configuration and is managed by the query group.
Shown in Figure 25 is the logical relationship of a Query Group to Relation Query objects. The diagram has a sequence of three queries followed by a parallel group of queries. In using a configuration framework the combinations of queries and how they are executed provides a very flexible means of executing Predictive data relationship network analysis.
The Relation Query interface has the same declaration as the query group as shown in the Java declaration shown in Figure 35.
And an example of a concrete class implementing a database query could be as shown in Figures 36 and 37, where the text runs from Figure 36 into Figure 37. The important factor is the configuration that provides the means to combine Relation Query objects into groups. Altio (RTM) Graph uses SpringFramework (www.springframework.com) to provide the configuration by means of dependency injection. A configuration for a class AdhocRelationQueryGroup is shown in Figure 26 with the concrete class implementation shown in Figure 27. The example Java code shown in Figure 27 demonstrates the execution of Query Objects in a loop as a sequence of executable steps.
The configuration of a Relation Query object for a database query is shown in Figure 28 where two configurations of the same class take place. In both configurations a query string attribute is populated with the executable SQL statement. As the system exposes a generic framework it is necessary to describe to the system the relationship type
"HnkTypeCode" and the node type that forms the end of the link "returnNodeType". AU link and node types use codes rather than descriptions so that language independence can be provided.
SUMMARY
To summarize, a graphical user interface tool has been described. The tool uses meta- data to describe the attributes of a data relationship network as well as having the ability to combine server side and client side processing to analyse relationships in data to produce a data relationship network. This data relationship network is then rendered as a graph. Regarding the graphical user interface tool, its features may include:
• Zero latency filtering and user interaction with underlying data
• Real time updates to the data visualised
• Meta-data driven data relationship network analysis
• Configuring Link Styles
• Subset Effects • Data relationship Network Analysis using meta-data driven queries
NOTES It will be appreciated by those skilled in the art that where above a "database server" is referred to, this could be a single database server or a set of database servers. The "database server" can be one or more of a broad set of data sources e.g. Web Service, Database, flat file, HTTP.
Various modifications and alterations of this invention will become apparent to those skilled in the art without departing from the scope of this invention, and it should be understood that this invention is not to be unduly limited to the illustrative embodiments and implementations set forth herein.
Appendix I
The following definitions may be useful.
AltioLive
Altiolive is a platform for building and deploying rich internet, thin client applications that offer real-time bi-directional interactivity with enterprise data. Further reference may be made to US 2004-0117439 and US 2004-0148375, the contents of which are incorporated by reference.
Altiolive is a best fit for the presentation of, and interaction with, data-intensive information where immediacy is critical. Based on proprietary technology and industry standards such as Java and XML, AltioLive uses a small yet highly efficient client to communicate with the server and render XML screen layouts as Swing windows within the web browser. As a result, the user can enjoy features such as secure live data delivery, drag and drop, filtering and sorting - all in the browser.
The AltioLive platform integrates easily with existing application environments. It is both easy to connect to sources of information and simple to deploy over a hardware network via a URL. The Altiolive client is designed to run in as many different browsers on as many different operating systems as required, meaning the user's applications can be deployed as widely as possible. Further information is given at http://www.altio.com/AltioLive.aspx.
Extensible Markup Language (XML)
The Extensible Markup Language (XML) is a general-purpose specification for creating custom markup languages. It is classified as an extensible language because it allows its users to define their own elements. XML's primary purpose is to facilitate the sharing of structured data across different information systems, particularly via the Internet, and it is used both to encode documents and to serialize data.
Hypertext Transfer Protocol (HTTP)
Hypertext Transfer Protocol (HTTP) is a communications protocol for the transfer of information on the internet and the World Wide Web. Its original purpose was to provide a way to publish and retrieve hypertext pages over the Internet.
Hypertext Transfer Protocol over Secure Socket Layer (HTTPS)
Hypertext Transfer Protocol over Secure Socket Layer, or HTTPS, is a Uniform Resource Identifier (URI) scheme used to indicate a secure HTTP connection. It is syntactically identical to the http:// scheme normally used for accessing resources using HTTP. Using an https: URL indicates that HTTP is to be used, but with a different default Transmission Control Protocol (TCP) port and an additional encryption/ authentication layer between the HTTP and TCP. This system was designed by Netscape Communications Corporation to provide authentication and encrypted communication and is widely used on the World Wide Web for security-sensitive communication such as payment transactions and corporate logons.
Integrated Development Environment (IDE)
In computing, an integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of a source code editor, a compiler and/or interpreter, build automation tools, and (usually) a debugger. Sometimes a version control system and various tools are integrated to simplify the construction of a graphical user interface (GUI). Many modern IDEs also have a class browser, an object inspector, and a class hierarchy diagram, for use with object oriented software development. IDEs are designed to maximise programmer productivity by providing tightly-knit components with similar user interfaces. This should mean that the programmer has much less mode switching to do than when using discrete development programs.
Java Database Connectivity (JDBC)
Java Database Connectivity (JDBC) is an application programming interface (API) for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.
Representational state transfer (REST)
Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. REST strictly refers to a collection of hardware network architecture principles which outline how resources are defined and addressed. The term is often used in a looser sense to describe any simple interface which transmits domain- specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies.
RTM
This means Registered Trade Mark. This abbreviation has been incorporated because some patent offices require registered trade marks to be identified in the specification. In this document, the designation "RTM" merely indicates that a trade mark is registered in the United Kingdom; the mark may or may not be registered elsewhere.
Structured Query Language (SQL) Structured Query Language (SQL) is a database computer language designed for the retrieval and management of data in relational database management systems (RDBMS), database schema creation and modification, and database object access control management. SQL is a standard interactive and programming language for querying and modifying data and managing databases. The core of SQL is formed by a command language that allows the retrieval, insertion, updating, and deletion of data, and performing management and administrative functions. SQL also includes a Call Level Interface (SQL/CLI) for accessing and managing data and databases remotely.
Web Service
A Web Service is defined by the World Wide Web Consortium as "a software system designed to support interoperable Machine to Machine interaction over a network." Web services are frequently just Web APIs that can be accessed over a hardware network, such as the Internet, and executed on a remote system hosting the requested services.
XML Path Language (XPath)
XML Path Language (XPath) is a language for selecting nodes from an XML document. In addition, XPath may be used to compute values (strings, numbers, or boolean values) from the content of an XML document. The XPath language is based on a tree representation of the XML document, and provides the ability to navigate around the tree, selecting nodes by a variety of criteria. In popular use, an XPath expression is often referred to simply as an "XPath".
XQuery
XQuery is a query language (with some programming language features) that is designed to query collections of XML data. It is semantically similar to SQL. XQuery provides the means to extract and manipulate data from XMT, documents or any data source that can be viewed as XML, such as relational databases or office documents. XQuery uses XPath expression syntax to address specific parts of an XML document.