Patent ID: 12248486

DETAILED DESCRIPTION

The following provides a platform for creating a shared network of data nodes. Each data node is self-describing, self-connecting, and self-securing. The data network taught herein can reduce the time and effort required to build large-scale (e.g., enterprise-level) data management solutions. Some advantages include: prevention of data silo environments; flexible enterprise alignment through an adaptable application programming interface (API) integration layer; and simplified data integration based on reuse of data across applications with minimal effort, effectively reducing or eliminating the need to develop “applications” in the traditional sense. Each node has: a dataset containing version-controlled data; an access controls layer limiting user access to the dataset; a metadata layer defining characteristics of the dataset and connecting to the another node. One or more links are created to associate the node with the subsequent node to create the network of data nodes such that a change in the dataset affects a change in the network of data nodes; and the network of data nodes comprises a query layer to interact with the dataset and the subsequent dataset.

As discussed below, this system effectively eliminates the need for application development in the traditional sense, such that the data collaboration network and the individual data nodes in that network eliminate the need for applications by allowing entities with access to the data to utilize the same data without requiring the significant efforts associated with traditional application development and the creation of data silos. Therefore, the system enables faster delivery of solutions by decoupling data from the UI and allowing for the configuration of security and control layers around the data, rather than having to write one off code for each solution or application. Moreover, the data collaboration networks within separate organizations can be linked to each other to create networks of networks, creating a super network of linked data, rather than isolated data silos.

FIG.2shows the traditional creation of each new custom application involving the creation of a new database24and the duplication of data26. Each of the traditionally developed applications10would require their own databases24with linked or related data26in the database24being created, imported, updated, maintained, etc. Each of the databases24stores a copy of the data26to be accessed by the application10. Traditional applications have datasets embedded within. Traditionally, data is stored as copies of data in data silos24behind individual applications10. This can cause a data-silo like environment, which can be disadvantageous.

FIG.3shows a schematic diagram of the network of data nodes. The data network34is created by connecting individual nodes36to form a network of data nodes34. The raw data or record of data35is accessible via the query interface33, which connects to the network of data nodes34. For instance,FIG.3shows four different application experiences32a,32b,32c, and32dall using data from the same data network. This not only eliminates the need to create, import, update, and maintain separate databases, but also eliminates the need to manage each application's security and controls16, data integration18, data persistence20, and data publishing22systems.

As such, adding a new application experience32is relatively easy.FIG.4shows a new application experience32ebeing added to the existing architecture shown inFIG.3. The addition of a new application experience32edoes not require additional security and controls16, data integration18, data persistence20, and data publishing22capabilities. The application experience32acts as a custom user interface to interact with the data.

Therefore, it can be appreciated that any number of nodes36, as well as application experiences32can be added to the network34. As newer application experiences32are added, the network of datasets34grows, and newer links are formed between the new datasets26.

Dataset Nodes, Networks of Data Nodes, and Platform Implementation

Turning now toFIGS.5and6, the platform described herein is configured to manage data35as a network of data nodes34.FIG.5illustrates an example of a dataset node36, andFIG.6illustrates an example of a network34of nodes36. Each dataset26comprises data35. The dataset is version controlled38and contains versions of data such as a first version35a, a second version35b, and a third version35c. It can be appreciated that any number of versions are possible. An access-controls layer39is built atop the dataset26. A metadata layer37is built atop the access-controls layer39. As seen with the single node36shown inFIG.5, at a node's core are records of data35. The records of data35cannot be accessed without first going through the metadata layer37and the access-controls layer39. The node36comprises metadata layer that makes the node37self-describing and self-connecting. Therefore, each dataset26comprises its own metadata layer37that contains information about the dataset such as properties and information regarding its relationships with other nodes (i.e., links), along with the data that relates any record in the current node with one or more records in other nodes.

The node36can be self-controlling by having a built-in control layer39to ensure the integrity of data, and to offer governance controls such as data versioning38and change approval. Data versioning38is shown inFIG.11, and described in more detail discussed below. The node36can be self-securing meaning that it has a built-in security layer to manage entitlements. The node is also accessible both through the platform's metadata driven user interface or API.

Typically, security and controls16for data existed in individual applications10shown in the prior art example ofFIG.1. This can be dangerous as the security and controls are linked to the individual applications, and therefore would not follow the data when the data is copied. Therefore, the data would be vulnerable or unsecure when copied.

In the system shown by this invention, the security and controls are built-into each dataset26. It can be appreciated that this is far more efficient and secure because it ensures universal enforcement agnostic of how the data is used. InFIG.1, if the data is copied across applications as a part of performing data integration, the security and controls do not follow the data, and must be re-implemented by each application. This is avoided as the access controls layer39is built as a layer atop the dataset26.

Turning now toFIG.6, it can be seen that a first node36acan be connected to a second node36band a third node36c. This forms the network of data nodes34. The nodes36are connected via links40, which are relationships between the nodes36. Links40are defined within a node's metadata layer37, which forms the basis for the network of data nodes34. Links40relate data records35within the data nodes, and an individual link40has the ability to relate a data record in a first node36ato one or more data records in another node36b,36c.

Since each node36is self-describing, self-connecting, and self-securing, the datasets26in the network34are not limited by an application's boundaries. The data is no longer siloed, as it is in the prior art illustration shown inFIG.1. This eliminates the need for the application managed databases shown inFIG.1, creating a simpler and more effective way to use the datasets.

For any individual, their network is shaped by the datasets they have access to interact with. Even the links connecting nodes are only exposed/accessible where the individual has access to the target of a link. It is possible that any user only has access to a small slice of the overall network, as shown inFIG.10.

By enabling data nodes to be connected to other data nodes, yet remain self-describing, self-connecting, and self-securing, we eliminate the need for data publishing and data integration components shown inFIG.1when interacting within the data network. Copies of data do not need to be distributed. Instead, access is granted, and links are established to enable the use of data that may be managed by a different owner.

The platform that is configured to create, modify, and interact with the network of data nodes34is illustrated inFIG.7A. The system has a query interface33where the API41or the application interface32can query the data through. The user12interacts with the user interface42or the application interface32to manage both the configuration of the node as well as the data in the node. The API41and the UI42can be provided dynamically by the platform itself.

The query interface33provides a query engine to interact with the network34including all the datasets26within the network. This enables interactions that go beyond the scope of a single node36, i.e. beyond what is possible using the APIs available for each node36. Queries can be written in a platform scripting language, which in one example builds upon SQL and is designed to take advantage of the links available in the network, enabling a user to traverse relationships between nodes when executing queries.FIG.9provides an example of a query that leverages a dot notation in the scripting language to traverse relationships when querying a node. The platform's scripting language enables users to read/create/modify/delete data, as well as manage the nodes on the network. Queries written in the platform's scripting language may support ACID transactions.

In an embodiment, legacy data28may be imported into the network34. Connectors can be used to bridge the gap between the legacy data28and the data network34. Connectors can enable the synchronization of data from outside of the platform into self-describing, self-connecting, and self-securing datasets, as well as the reverse flow to push data out to legacy applications or the enterprise data lake shown inFIG.1.

FIG.7Bshows an embodiment where multiple networks34are connected to one another. For example, networks34within separate organizations can be linked to each other to create networks of networks of linked data, rather than isolated data silos. The network of networks of data is referred to as a super network.

Turning now toFIGS.8athrough8e, example screen shots are provided to illustrate the user experience component shown inFIG.7. The user experience42can use web forms for creating and managing nodes.

InFIG.8there is shown a sample of screens for an example of a node.FIG.8ais a UI to manage the data in the node. It may be noted that the Primary Client column is a link, andFIG.8cshows the definition. This experience enables a user to click through to traverse the link to the related record in the linked dataset.

InFIG.8bthere is shown a sample screen for designing the dataset, including the definition of the metadata in the rightmost screen shot.

FIG.8cprovides a sample screen for defining a link between the current dataset and another dataset. As shown inFIG.8d, all data changes in a node are automatically version controlled.FIG.8dis a sample screen of a Collaboration Log that displays the versions of data.

FIG.8eprovides a sample screenshot of the Controls that can be configured on an individual node.

The platform therefore provides a native metadata driven user interface for users to interact with the data network. This, coupled with the ability to create custom application experiences, provides a replacement for the need for Applications in the sense illustrated in FIG.

As indicated above,FIG.9provides a sample of a platform scripting language query that is taking advantage of the links that exist between nodes to traverse the data network34and retrieve data. Specifically, a dot notation can be used to obtain a query result, by using the query interface33provided by the platform.

Data Versioning

Data versioning38in the platform can be performed on the data.FIG.11shows data versioning of a single record. A first version may represent the initial creation. Subsequently, new versions may be created each time the dataset is changed or altered. For example, Version18approved the changes performed by a user named Dan Demers on Nov. 13, 2020. Each version captures the details of the user that made the change along with the timestamp of the change.

For example, in one version a user can delete a record of data, this will show as grayed because it is a deletion. In another instance, a user may restore the record of data from the recycle bin, this will show as a restore performed by the user. In another instance, a revert operation can be performed by a user, to restore a first version of the dataset. This will create a new version, and it does not impact the version history.

Data Level Access Control

FIG.10provides an illustration of how two different users (User12aand User12b) see the same network of data nodes. Here there are two different users12aand12b, who are interacting with the data network34via the query interface33. The black links40and nodes36represent datasets26that the user has access to. For either individual, the gray nodes and dashed links are unavailable, it is as if they do not exist at all. This means that each user has their own perspective when looking at the data network34, and it may look very different for each.

The partially filled nodes represent the fact that a user may only have access to a subset of the data within a node36, subject to rules that have been configured. The access controls layer39built-on a node36can be very granular and define rules that enable a user12to view/edit/approve data under certain conditions.FIG.12, discussed below provides an example of data driven access entitlement.

Turning now toFIG.12, datasets can support very granular access controls. InFIG.12is an example, which is showing two independent grants defining what a user is able to edit. One of these grants has conditions based upon the data in the current node. These conditions can span nodes as well, leveraging the links to traverse related datasets to determine whether a user has access. Similar granular controls are available for what a user can view or approve. In this example, the grayed out cells would not be editable by the user.

The networks of nodes are linkable via any application that is configured to utilize and interact with the platform. The network is an interaction of the relationships between the data and does not necessarily affect the location of, or exact device used, to store the data in the underlying persistence. In this way, existing technology within an enterprise can be used while running the platform over top of this technology, without requiring with adopting one or more new databases.

The network34can be built from a series of data nodes36. The datasets26can link to other datasets and queries can be built by applying the scripting language as explained herein. This allows users, such as developers, to build application experiences using existing datasets and by creating new datasets and thus leverages the existing network of nodes and builds upon that network for future application development.

It may be noted that a newly created node can have data added and manipulated by the user, and/or can import existing data, e.g., legacy data. In this way, new nodes can be added to the network using an enterprise's existing data, e.g., from a legacy application or data storage component. Nodes can be user managed, synchronized, and/or application managed and any particular node can have individual attributes or sets of attributes that are user managed, or synchronized, or application managed. That is, a node can be controlled and managed on a per attribute basis. More specifically, records in one node can be linked to one or more records in another node.

An enterprise environment may not only build solutions quickly by reusing existing queries and nodes, but also continues to enhance and add to the data network as new data is created or imported for the newly built solutions.

The configuration and various components of the platform enable several unique features that improve upon the way enterprises and other users of data build solutions. By providing a network of data nodes34as shown inFIG.6and providing data-layer controls and interfaces to that data network, solutions can be built with less effort and at greater speed than traditional approaches that replicate these capabilities in data silos.

In prior approaches, each solution is implemented as a separate application10that requires a separate database24for persistence (seeFIG.1). In contrast, the system described herein provides a single platform to manage data for multiple solutions. Using the platform, persistence can be provided to solutions over APIs. Because of this structure, data can be reused across solutions without data integration required for each solution individually. This reduces the infrastructure burden, particularly when creating many solutions.

It is recognized that traditional databases are designed for use by a code which is written by a development team. This code generally runs under an account for the application10, not separate accounts for individual users12. That is, access controls in traditional application development environments are typically not robust enough to allow a single database to be used by multiple teams for multiple applications10, each with multiple users12. To overcome this limitation, the system described herein provides data access controls that limit what all users (including developers) are able to see and edit. The security layer of the platform applies these controls so that each user12sees a slice of the data network according to what they have access to.

In prior approaches, while data change auditing could, in theory, be implemented in application code as a generic capability for all data within the application, in practice it rarely if ever is. Typically, developers of applications10build a separate “audit log” table to store changes for specific datasets of interest. However, changes are not universally captured for all datasets, and is often not recoverable through a systematic approach when an audit log is available. In the presently described system, the platform is configured to perform automatic data versioning of each individual record, with the ability to roll-back to previous versions. This reduces application development efforts and is guaranteed to apply to all data as opposed to having to compromise because of an effort cost/impact. Automatic data versioning also simplifies the data model by avoiding user-defined control attributes (e.g., creation time, created by, etc.).

The automatic data versioning applied by a data versioning module of the platform can be performed by storing all data changes in a way that allows both viewing of prior versions, differences from version to version, and the ability to revert back to a specific version, by reapplying the change back, even in scenarios where the schema of the table has changed.

In prior approaches, the ability to restrict who can see and edit data is implemented by each application10in application-specific code (seeFIG.1). This application-specific code is written at the application/function/feature level, not the data layer. As mentioned above and shown inFIGS.5and6, the platform has data access controls defined at the data node level, and solutions are forced to automatically respect those controls. As shown inFIG.9, execution of a scripting language query used by the platform utilizes access controls metadata to execute the query engine such that the query results pulled from the data network are limited to what that particular user has access to.

This data layer access control reduces application development efforts by eliminating the need to create access controls for each and every application. Moreover, there is a consistent enforcement of controls (e.g., a single user accessing the same data through multiple applications) across all access channels (e.g., API, UI, etc.).

In prior approaches, links between records in databases24used by applications10are implemented by copying the column values and/or using surrogate keys. In the presently described system, the platform provides the ability to link a record in one node to one or more records in another node, agnostic to the attributes and attribute values. Also, the platform provides the ability to use the links in queries. This simplifies the data model by unifying physical and logical models and avoids a dependency on manually defined surrogate keys. The linking performed using the platform also simplifies queries by avoiding what would normally require complex joins.

The linking can be performed by the platform storing the links between records separately from user-defined columns. A separate table can be used, which includes a mapping of these relationships, in a way that is agnostic to user defined columns. It can be appreciated that this linking mechanism is only for illustrative purposes, and the exact implementation would vary depending on the type of underlying persistence.

The query engine can execute the platform's scripting language by generating the underlying persistence language, e.g., SQL, and if applicable explodes the “dot” notation (shown inFIG.9) and converts from model to logical. The data may then be converted from logical to physical and access controls applied such that only approved data is pulled from the underlying persistence. The underlying persistence native query may then be performed and returned.

Traditional approaches to filter data access per user privileges rely on an application-specific insulation layer of security and controls over the data integration, persistence, and publishing interfaces upon the physical database layer. As such, the ability to restrict who can see and edit data is implemented within each application in application-specific code, which is written at the application function/feature level. Such a traditional approach is not application agnostic and requires extensive and time-consuming application development effort.

To address this traditional approach, the platform described herein defines the data access controls at the data layer so that application development time can be significantly reduced while providing consistent enforcement of controls (e.g. a single user accessing the same data through multiple applications) across all access channels (e.g. API and UI) and eliminating the risk of inappropriate access.

It has been found that injecting caching of metadata and entitlements data and incorporating dedicated processing modules and tables to capture entitlements in separate tables within the interaction layer can accelerate performance. The caching protocol described below incrementally can execute a cached transformed query or regenerate the query depending on the changes associated with the access privileges or the query itself, with the changes being reflected in a rapid or near-instantaneous manner. Thus, possibility of undue data access, while new use privileges are being applied, can be eliminated.

The following describes processes for data level access control by managing the entitlements within the interaction layer and then applying them through a query engine to rewrite the queries “on-the-fly” that incorporates access privileges into consideration. This can be done while caching metadata and entitlements data and incorporating dedicated processing modules and tables to capture entitlements in separate tables within the interaction layer.

Change Approval

Another problem addressed by the platform is in designing effective underlying data structures that allow the platform to implement a change approval process in a seamless manner without impacting performance. It was recognized that application queries should calculate results based on approved database changes only, while tracking and versioning pending changes for approval. Existing change approval techniques in prior approaches have been found to not be designed to address the highly unpredictable usage patterns faced by the platform and were therefore determined to be either overly complex or underperforming for the operation of the platform described herein. In addition, such existing techniques were found to be more suitable for a fixed database schema design whereas the platform and its data collaboration network(s) undergo continuous evolution.

It was found that maintaining two separate tables, one dedicated to tracking unapproved changes and another one being the approved master table itself could be used for change approval. Processes within this two-table architecture were run to compare and identify the specific fields that have undergone changes between a master and unapproved changes table, including calculating changes on-the-fly and outside the interaction layer in the application layer. This led to a process based on persisting flags to identify changes for each master data column, which delivered acceptable performance and storage requirement characteristics, and was incorporated as part of the overall architecture of the platform.

As such, there is provided herein a two-table data structure design that maintains two separate tables, one dedicated to tracking unapproved changes and another one being the approved master table itself, to effectively version and track unapproved database changes. This can include the aforementioned persisting flags that identifies changes for each master data column without negatively impacting performance and storage requirement characteristics.

Data-Driven Entitlements

In addition to user/group based column level entitlements that can be enforced by the database consistently across all methods of access (e.g. API or UI), the platform described herein, can also be configured to allow data-driven entitlements. It has been appreciated that without conditions, data would still need to be fragmented and duplicated. For example, if one wants to see the title and name of everyone in the company, but can only see his/her own phone number and address, and only him/her and his/her manager(s) is/are able to see his/her salary. For this information to exist in the same table, the platform applies separate conditions that would allow one to control access based on data within the table.

Column level entitlements can be applied by creating an interaction layer and rewriting queries before being sent to the backend. This combined the user's permissions with the query they are running. While a user's query's “where clause” can be enriched to include any additional conditions, it has been found that in some cases this means restructuring the query completely to include a where clause, e.g. when performing updates. This can however be insufficient for doing data-driven entitlements because a user's entitlements can be based on data that they do not have access to. The platform can run the entire query under the context of that user. For example, if a user only has access to Name and Title in a table with Name, Title, Phone Number, and Address, the platform can apply that user's permissions and limit the data the user gets back to Name and Title. With data-driven entitlements, the platform can allow the user to view all employees where their address is in a particular state or province, when the user does not have access to the address field.

That platform can also be configured to be able to layer together multiple entitlements that impact different columns (e.g., you can see your own name, title, phone number, and address but you can only see the name and title of other employees). By dynamically rewriting the where clause, the platform may be unable to isolate conditions to individual columns. The rewrite logic of the platform can therefore be enhanced to adapt the positioning of the conditions when they fall into this category.

It was also recognized that where there is a link between tables, the controls of the linked table should apply in addition to the controls of the current dataset. This can become quite complex because links could point to other links and thus not only include one additional set of conditions but potentially multiple. Moreover, links support multi-select inside of the platform to allow a one-to-many relationship. In an environment where a user has access to a subset of the data, the platform can be configured to ensure that where there are multiple selections the user only see the ones they are allowed to see. This can further complicate the rewrite logic to dynamically account for these conditions.

To enable data driven scenarios, the platform can also be configured to allow a user inside of the entitlement conditions to access information about the current user and which groups they are a member of. This can be done by extending a query language to support such functions.

To address potential performance issues (because of the complexity that these controls added to the parsing of each request and the final query that is fired against the underlying database), the platform may also implement a custom caching layer that can reduce the number of times a statement is processed by the platform's query engine.

As such, the platform provides a process for data level access control to allow data-driven entitlements by running a re-written query through a system user rather than the current user's credentials, and can layer multiple entitlements together.

Data Sync/Connector Architecture

Extract Transform Load (ETL) tools generally provide components to insert new data or execute a script to clear existing data, whereas the platform described herein intends on creating a data sync which leaves existing data intact and applies deltas to preserve version history. It is intended that the platform do this in a way wherein the data sync architecture was agnostic of the source or target. In this way, simple connectors can be built against an interface to enable the creation of new connectors in a shorter amount of time, e.g., over the span of 1-2 days, regardless of the platform, and have consistency in how the sync operates and the features it exposes.

The first step in implementing a sync is to establish the reconciliation logic. The platform can be configured to implement partitioning, which was found to be relatively more effective by creating a custom algorithm that relies on a custom indexing and sorting strategy. It was found that a bottleneck then shifted to the serialization and deserialization of data when transferring between the sync utility and the web application for the platform. Various serialization protocols can be used, for example Protocol Buffers provided by Google. It is recognized that Protocol Buffers is typically aligned to a fixed payload structure, whereas with the platform, the data moving back and forth may not adhere to a fixed schema. As such, the platform was configured to fit a dynamic structure into that type of a model.

Accordingly, the platform can abstract the source and target out of the sync engine, meaning that when the platform adds a new connector it only needs to have code written for it to transform its data to a standard intermediate format, rather than implementing solutions for each combination of source and target.

Network Growth

FIGS.13a-13cshow the development of the dataset network34through time. Specifically,FIG.13ashows an34dataset network in an early stage, as the data is still being developed. In the early stages, a smaller number of nodes36are present as well as a smaller number of links40between nodes36. As the dataset is developed, a user adds more data to the dataset network34, growing the network.FIG.13bshows the dataset network34in a stage later than the early stage. In this stage, the dataset network has more nodes36and more links40between the nodes.FIG.13cshows the dataset network in an even later stage than the stage shown inFIG.13b. In this stage, the dataset network has a large number of number of nodes36and a large number of links40between the nodes36.

FIG.14andFIG.15provide a schematic view of a traditional application versus a dataset network34.FIG.14andFIG.15show a traditional application (or “app”) comprising a UI14, API15, Logic, controls16, persistence20and is then integrated with the operating system of a computing device18. On the other hand, the dataset network34comprises the nodes36that are self-describing, self-connecting, and self-securing. As such, there is no need fora UI14, API, or integration with the Operating System18. The API41or application experience32obtains data25directly from the data network34via the query interface33. This eliminates the need to create, import, update, and maintain separate databases. This also eliminates the need to manage each application's security and controls16, data integration18, data persistence20, and data publishing systems22.

The dataset network34does not require additional security and controls16, data integration18, data persistence20, and data publishing22capabilities. It is also optional to create a custom user interface to interact with the data, as the query interface33is available.

Therefore, it can be appreciated that any number of dataset nodes36, as well as application experiences can be added to the network34. As newer applications are added, the network of data grows, and newer links are formed between the new datasets.

FIG.16Ais a schematic view showing security and controls16for traditional application development using siloed databases.FIG.16Bis a schematic view showing security and controls via an access layer39for application development using a data network34. InFIG.16B, data26is accessed through a users credentials, rather than an application's service account, as shown inFIG.16A. The security and controls39of the data network34are defined per dataset26, rather than at each application10, as done traditionally. This enables real, cross-application security and controls on data and eliminates data duplication. A user12can also optionally interact with the data directly via the data network user interface42, instead of always through an application.

For simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth in order to provide a thorough understanding of the examples described herein. However, it will be understood by those of ordinary skill in the art that the examples described herein may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the examples described herein. Also, the description is not to be considered as limiting the scope of the examples described herein.

It will be appreciated that the examples and corresponding diagrams used herein are for illustrative purposes only. Different configurations and terminology can be used without departing from the principles expressed herein. For instance, components and modules can be added, deleted, modified, or arranged with differing connections without departing from these principles.

It will also be appreciated that any module or component exemplified herein that executes instructions may include or otherwise have access to computer readable media such as storage media, computer storage media, or data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by an application, module, or both. Any such computer storage media may be part of the platform, any component of or related thereto, etc., or accessible or connectable thereto. Any application or module herein described may be implemented using computer readable/executable instructions that may be stored or otherwise held by such computer readable media.

The steps or operations in the flow charts and diagrams described herein are just for example. There may be many variations to these steps or operations without departing from the principles discussed above. For instance, the steps may be performed in a differing order, or steps may be added, deleted, or modified.

Although the above principles have been described with reference to certain specific examples, various modifications thereof will be apparent to those skilled in the art as outlined in the appended claims.