How it Works

How GaterWare^® works

GaterWare uses two components

A data repository (“GaterBase”) that is integrated into the app and controls access to its data fields. It can reside anywhere: on the client, an intranet, the internet or the cloud.
A web service (“DataGater” ), managed by DataGater, LLC which handles all vendor registration, payment transactions, key-creation, and vendor payments.

Data values can exist in one of 2 states in the repository:

RAW (“ReadAndWrite” ) where they can be created, saved, read and edited – one record at a time.
PAID (“PurchasedAndIndexerData” ) which have the one-record at a time restriction removed.

When a data field for a case has no value stored in it, it is referred to as “Undefined”

“Gating” which converts RAW values to PAID, is done by the GaterBase repository object and requires a custom set of keys provided through the DataGater service – after the user makes payment. The keys are specific to the particular GaterBase making the request and to the records and fields that the user has selected for gating.

The GaterBase repository works like any other data repository structured with records and fields. Fields are strongly typed … as string, integer, floating-point or join fields.

PAID data fields can be exported at any time into other data formats. One method call to the GaterBase repository object exports all the fields to an MS Access database file – with separate tables for each join.

The GaterBase allows you to specify up to 3 fields as indexers. Indexer fields do not require payment but are treated as PAID. They are always available for sorting and aggregation. Typical fields for indexer status are “record number”, “case name” and some categorization attribute like product ID or treatment condition. They let you sort quickly through the data you have on file, list them out, or filter the records you want to purchase gate-keys for.

Why it works

Customer value comes from what customers learn from their data, not from the software have installed or from the individual bits of data themselves. And nearly all learning from data requires aggregation. Sorting, ranking, and statistical analysis are all aggregation functions. They all require that more than one record be regarded at once.

The GaterBase has been engineered to allow only one record to be readable at a time. It imposes a “gate” that prevents the values in one record from being aggregated with those in other records until a gate fee has been paid. The fee gets a digital, encrypted gate key that converts the status of the value field from RAW to PAID.. .

Before gating, users can put data into a record, read it and edit it. But they can’t do analysis or other kinds of batch processing.

After gating they can do any kind of processing they choose. They can sort, rank, compare, convert and statistically analyze PAID fields without limit. They can also export them to other data-file formats for processing by third-party apps, if the app developer so chooses.

PAID status is permanent. Payment is done only once. The only thing that will change a value’s status is having it overwritten with a new value.

GaterWare^®, is thus not exactly a pay-per-use system, it is a “pay-per-data-analzability” system. Users pay a fee to enhance the usability of their data.

DataGater’s free data repository starts with a “gate” on data usability. Payment opens that gate to unlimited, permanent data functionality.

GaterWare^® System Requirements

App-Developer systems:
            Windows XP or higher
            A development environment for any .NET language or VB6
            The DataGater object library
            The .NET framework, version 2.0 or higher

App-User systems
            Windows XP or higher
            .NET Framework 2.0 or higher
            An internet connection – for payment transactions

GaterBase Data Structures

Cases are the term by which GaterBases refer to records. There is no limit to the number of Cases that can be held by a GaterBase

The CaseDefinition. The data structure of a GaterBase is contained in the CaseDefinition

The CaseDefinition defines all the variables under which data values can be stored. It consists of a collection of FieldDefinitions, which in turn contain the defining properties of each data field:

FieldDefinitions contain the following properties

- Name (must be unique)
- Type (integer, floating point, string or join)
- Indexer status (true/false – limited to 3)

There is a FieldDefinition for each variable in the study (Answers to all questions, all field notes, all codes, treatment groups, etc)

Indexer fields are fields used for rapid access and sorting of cases. They behave like PAID fields and never require payment. There can be no more than 3.

There are typically indexer fields for each Case’s record number, name and one other sorting variable.

FieldGroups. Fields are grouped within the CaseDefinition into FieldGroup collections

A GaterBase’s FieldGroupsCollection can contain one or more FieldGroups, and each FieldGroup can contain one or more fields

The FieldGroup structure was created to make it easier for users to select and operate upon sets of fields at a time. This can be a help when selecting data to be gated.

Case Definition Structure Graphic

GaterBase Data

Data “Values” are stored in “Cases” by “Fields” according to the field structures defined by the CaseDefinition, and each FieldValue has a FieldState which describes the value’s gating status

Cases

Each stored Case has a unique identifying index, CaseID by which the GaterBase keeps track of its location. This may or not coincide with the number you assign to the case for project management purposes.
Each Case has a FieldValueCollection for storing FieldValues
There is also a CaseInfo packet associated with each case that contains information about the gating status of data stored in the case.

Each Case has a FieldValueCollection for storing FieldValues

There is also a CaseInfo packet associated with each case that contains information about the gating status of data stored in the case.

FieldValues
“FieldValues” are the data stored in each record under each field

JoinFieldValues

There can be any number of entries in a JoinFieldEntry collection, which is stored as a Field of “Join” type. Each entry will contain JoinFieldValues for each of its constituent JoinFields: “NoteTime” and “NoteText” in the example in Figure 3. JoinFieldValues are limited to being typed as Strings.

Join Field example

FieldStates

The packet of meta-information about the status of each Case’s FieldValues is contained in the Case’s CaseInfo object, which in turn holds a FieldState object Regular values can be

Missing (the “.Undefined” property)
RAW (stored but unpaid – “.Unpurchased”), or
PAID (stored and paid for – “.Purchased”)

Indexer fields are either missing or not

In the following example, Case 2 has no answer stored for “WantToSeeAgain.” The FieldValues for the “PostRating” and “Why” Fields are RAW (Unpurchased)

CaseInfo - FieldState Properties

Case Access Modes

Cases can be read from a GaterBase in one of two modes, governed and ungoverned.

Governed Mode

If you retrieve a Case from the GaterBase as a governed case, it will contain all the stored field values, whether Indexer, RAW or PAID. But you can only access one governed case at a time. (or, more precisely, you can only access a very small number of cases within a short period of time.)

If the user tries to access more than 5 governed cases in a ten-second period, the GaterBase will not release the next case’s values, and it will post a warning that you have hit a speed bump. The values will be released after a set period of time has passed.

Governed cases are what you use for collecting, reviewing and editing data – all of which only require access to one record at a time.

Ungoverned Mode

Ungoverned cases contain only PAID Data Values (Purchased and Indexers). They have no speed or frequency limits.

Ungoverned cases are what you use for analysis, exporting or other batch processing.

In this example, Case 2 in Ungoverned mode only contains Field values for the Indexer fields, and the PAID field. The RAW (Unpurchased) fields are read as missing values (Undefined)

Governed and Ungoverned Records

During data collection, editing and review, you would use Governed Cases. For analysis, processing, reporting or export you would use UnGoverned Cases (which have purchased FieldValues and thereby permit rapid access and aggregation)

How GaterWare® works