Rule frame

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

Please note that no action has been defined for the VALID rules. The below proposed actions are tentative.

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")
tuple	chkVMSInterval	timestamp, PortName		New		Check that delay between two VMS reporting <= 2h	(If return = "FALSE") Raise Alert ("No VMS reporting for the last 2 hours contact (calls getVesselsDetails("RadioCode",VMSVesselRadioCode))
tuple	chkVMSInterval	timestamp, PortName		New		Check that delay between two VMS reporting <= 12h	(If return = "FALSE") Raise Alert ("No VMS reporting for the last 12 hours contact port authorities for thorough check on vessel (calls managePort(PortName))