A data rule is a statement that provides the opportunity to validate compliance to expected conditions or to identify and review exceptions. It always resolves to either true or false. Data Rules are intended to ensure that a program operates on accurate and useful data providing higher user confidence in the quality of the data. Data rules apply to data and information, not workflows and processes. They provide a method to define specific tests, validations or constraints associated with data items. Data rules are atomic; they each check one thing.
A Business rule is a statement that defines or constrains some aspect of the business. Business rules describe the operations, definitions and constraints that apply to an organization and are put in place to help the organization achieve its goals. Business rules can apply to workflow, policies, procedures, regulatory compliance, computing systems, individual behavior or corporate behavior in an organization.
Conformance to a business rule must be measured by determining whether the necessary processes have been applied to data and information. Business rules is a grouping of data rules by describing how to assert business structure or control or influence the behavior of the business. A business rule will contain one or more data rules, and data rules will be contained in more than one business rule.
A metadata rule is a statement that provides the opportunity to validate the information about a data record in terms of compliance to expected conditions or to identify and review exceptions.
A metadata rule has the same purpose and design as a data rule, but is aimed at the data record rather than at the real-world object.
Metadata is “data about data”. Metadata rules apply to the database row (record). For example, row created date must not be null; published date is greater than created date.
The metadata for each rule includes the following dates related to status.
Anyone may add a comment about a rule the Discussion tab on the Rule Viewer page. We welcome comments about the wording of a rule Statement, the business value of the rule, or any of the Description items that support the understanding and application of the rule.
An editor or administrator must add a comment to explain a change to a Published rule.
A comment is also required if the rule Statement is changed during In Review status.
Quality can be assessed in several ways based on certain expectations about how the information describes a real thing (object or event). In the information management world, there is no standard or consensus on what quality dimensions are necessary or how the terms are defined. The PPDM Rules use the following defined terms.
ACCURACY The record must conform to the real world object or event. E.g. top depth less than base depth. The opposite is meaningless or garbled: the thing reconstructed from the data is ridiculous.
COMPLETENESS The data is part of the minimum set of information that is necessary to describe the real thing. E.g. if top depth is missing, an interval cannot be described. The rule is usually a "not null" check.
CONSISTENCY There is no conflict in how two records describe the same object or event. E.g. well record says ABD but production record says it's producing. This comparison may be within one record or between two data sets. The opposite is ambiguous: you can construct the real thing in 2 different ways and you don't know which one is right.
UNIQUENESS There is no duplication. E.g. one well cannot have two locations; one location cannot have two wells. The rule should make allowance for different sources, versions, etc. of course.
VALIDITY The record value is in the accepted format and range. The range could be numeric or a text list (e.g. status codes). The set of values may be adjusted to suit local conditions, e.g. a location in the State of Colorado (USA) must have a latitude of 37 to 41 degrees.
Note: Timeliness is another important quality dimension. However, it is not used for PPDM rules because the measure of timeliness is highly dependent on the business requirements of the data. For example, UPDATE_DATE must be less than 1 month after SPUD_DATE might satisfy most business units but the drilling department might require timeliness of 1 day or 1 hour for some wells. Timeliness may be evaluated with a business rule (not a data rule).
Subject areas (categories) are a high-level classification of E&P information. They are based on the published roadmaps for the PPDM 3.9 data model.
Subjects available for filtering are limited to those used in published rules. As new rules are contributed, more Subject choices will be added. With additional subjects, some existing rules may be re-classified.
Wells General information, depths, dates, directional surveys, logs, tests, cores, interpretations, drilling and completion operations, etc.
Land Rights General information, authorizations, status, acquisition, interests
Seismic Acquisition, processing, licenses, transactions, interpretations
Production Fields, pools, units, production strings, reporting
Spatial Information about areas, parcels, fields, units, coordinate systems, etc.