Difference between revisions of "Rule frame"
From D4Science Wiki
(→Action rules) |
(→ICIS Rule Frame) |
||
| Line 4: | Line 4: | ||
The rule frame described in this example related to the validation of a imaginary dataset that is collected from a Regional Fisheries Organization, and has been loaded as a CSV in ICIS. It now needs to be reconciled with previous datasets from the same reporting stream, and be published in various locations. | The rule frame described in this example related to the validation of a imaginary dataset that is collected from a Regional Fisheries Organization, and has been loaded as a CSV in ICIS. It now needs to be reconciled with previous datasets from the same reporting stream, and be published in various locations. | ||
| + | |||
| + | There are 2 basic types of rules: | ||
| + | * Contraints check if a condition is violated (return a boolean), and this triggers some action (from an alert, to stopping the transaction) that is not related to a modification of data. | ||
| + | * Action rules trigger an event that can be a transaction, a form navigation, or something similar. | ||
| + | |||
| + | There are also several types of rules: | ||
| + | * Attribute rules operate on one input value, and usually check only it's validity according to a predefined range. | ||
| + | * Tuple rules check if two values in a row that have a defined relationship do not violate the relationship. | ||
| + | * Entity rules check if the values in a tuple 'fit' within the data-table (or structured dataset) they belong to. Exaples are time-series of VMS positions where two consecutive records may have temporal and spatial distances that should be observed. | ||
| + | * Inter-entity rules check if the values in one table-row are consistent with the values in another (set of) tables. Examples are if the given lat-long are within an EEZ, if the given genus / species name is valid, if the portname is open for vassels of the reporting category, and much, much more. | ||
| + | * OTA are Other Triggered Actions, and basically cover all actions that are not modeled with the data. These can e.g. be import and export actions, logging, alerting, backing-up, or sharing. | ||
| + | |||
| + | Rules have to fired by an event, that can be user-triggered (mouse-events, click events), data manipulation (CRUD), or by a clock. In order to perform the operation correctly, they must fire at the right time, and in the correct sequence. The timing is usually related to maintaining data integrity, thus before the manipulation is persisted. The sequence is a topic for another page. This page is to collect user level requirements only, more developer oriented pages will have to describe the implementation and fire-sequence. | ||
==== Check rules ==== | ==== Check rules ==== | ||
Revision as of 16:19, 9 July 2013
ICIS Rule Frame
One approach to capturing requirements and potentially define on the implementation facilities, is to use a rule frame. This classifies and describes the expected types of rules to apply to data once an action has been triggered.
The rule frame described in this example related to the validation of a imaginary dataset that is collected from a Regional Fisheries Organization, and has been loaded as a CSV in ICIS. It now needs to be reconciled with previous datasets from the same reporting stream, and be published in various locations.
There are 2 basic types of rules:
- Contraints check if a condition is violated (return a boolean), and this triggers some action (from an alert, to stopping the transaction) that is not related to a modification of data.
- Action rules trigger an event that can be a transaction, a form navigation, or something similar.
There are also several types of rules:
- Attribute rules operate on one input value, and usually check only it's validity according to a predefined range.
- Tuple rules check if two values in a row that have a defined relationship do not violate the relationship.
- Entity rules check if the values in a tuple 'fit' within the data-table (or structured dataset) they belong to. Exaples are time-series of VMS positions where two consecutive records may have temporal and spatial distances that should be observed.
- Inter-entity rules check if the values in one table-row are consistent with the values in another (set of) tables. Examples are if the given lat-long are within an EEZ, if the given genus / species name is valid, if the portname is open for vassels of the reporting category, and much, much more.
- OTA are Other Triggered Actions, and basically cover all actions that are not modeled with the data. These can e.g. be import and export actions, logging, alerting, backing-up, or sharing.
Rules have to fired by an event, that can be user-triggered (mouse-events, click events), data manipulation (CRUD), or by a clock. In order to perform the operation correctly, they must fire at the right time, and in the correct sequence. The timing is usually related to maintaining data integrity, thus before the manipulation is persisted. The sequence is a topic for another page. This page is to collect user level requirements only, more developer oriented pages will have to describe the implementation and fire-sequence.
Check rules
| Type | Trigger | When | Status | Implemented by | Comment | Action |
|---|---|---|---|---|---|---|
| Attr | 0 <= temp <= 30 | AI / AU | New | Check that Seawater is warmer then 0, and cooler than 30 | Raise Alert ("Your water temp is out of range") | |
| Tuple | dtStart <= dtEnd | BI / BU | New | A check to ensure start dates are before end-dates | Raise Alert ("A start date must be before the end-date") | |
| Entity | Unique key on genus, species, subspecies | BI / BU | New | Check that species are unique | Raise Error ("This species already exists") | |
| Inter Entity | Valid Lat/Long | App logic | New | Find if Lat/Long fits within BBox of distributions | Raise Alert ("This position seems unvalid") |
Action rules
| Type | Trigger | Params | Returns | Status | Implemented by | Comment | Action |
|---|---|---|---|---|---|---|---|
| tuple | getGeoName | Lat / Long | geoName | New | Retrieve the nearest geoName, of any kind | (If return = "") Raise Alert ("No name found") | |
| tuple | getGeoNameCityOrPort | Lat / Long | geoName | New | Retrieve the nearest geoName, of type "City" / "Port" | (If return = "") Raise Alert ("No name found") |
VALID project Action rules
| Type | Trigger | Params | Returns | Status | Implemented by | Comment | Action |
|---|---|---|---|---|---|---|---|
| tuple | chkPort | PortName, timestamp | New | Check if the reported port is valid | (If return = "") Raise Alert ("No port found, want to check the name Y/N (calls managePort(PortName)") | ||
| entity | chkPortMooring | [[PortName], [timestamp]] | New | Check if the reported stay in a port is valid; no other location can be reported in between reported location | (If return = "FALSE") Raise Alert ("No valid port mooring reported") | ||
| inter-entity | chkSteaming | [[Lat], [long], [timestamp]] | New | Check if the reported positions are valid steaming according to chkSea, chkSpeed, chkLicense, chkFishArea | (If return = "FALSE") Raise Alert ("No valid port mooring reported") | ||
| OTA | managePort | [PortName, timestamp opt] | New | Check if the PortName does exist given the timestamp, and gives Create Update options | (If return = "TRUE") Raise Alert ("Your changes have been sent for review") |
