- Rules and data representation are essential components of expert systems.
- They determine how the system stores and processes knowledge.
Rules
Rules
Statements that define the relationships between facts and actions.
- They are typically written in the form of IF-THEN statements.
- Rules are used to draw conclusions based on the facts in the knowledge base.
Rule: IF a patient has a fever AND a cough, THEN the patient may have the flu.
Data Representation
- Data representation refers to how facts and rules are stored in the system.
- Common methods include:
- Production rules: IF-THEN statements.
- Semantic networks: Graphs that represent relationships between concepts.
- Frames: Data structures that represent objects and their attributes.
A semantic network might represent the relationship between a dog and its owner.
Critically commenting on rules and data representation
- When evaluating rules and data representation, consider the following:
- Clarity: Are the rules easy to understand?
- Completeness: Do the rules cover all possible scenarios?
- Efficiency: Is the data representation efficient in terms of storage and retrieval?
A rule that is too general may lead to incorrect conclusions, while a rule that is too specific may miss important scenarios.
Sample Questions
A timetable is coded as a 2-D array timetable[day][period]. Evaluate this organisation and state a rule the system should enforce.
Solution
- The fixed array collapses when the school adds half-periods or alternating A/B weeks, so the structure is not future-proof.
- A relational table (teacherID, day, period) is more flexible.
- Declaring (teacherID, day, period) as UNIQUE enforces the rule that a teacher cannot be double-booked.
All student data are kept in a single CSV file with repeated address columns (address1, address2, address3). Critique the organisation and mention a rule that would improve data quality.
Solution
- Repeating address columns signal a non-normalised design: changes to one field risk inconsistency in the others.
- Splitting addresses into a separate Address table eliminates redundancy and update anomalies.
- A foreign-key rule from Student.addressID to Address.id preserves referential integrity.
Sensor packets are stored as raw JSON: {"temp":31.2, "hum":"high"}. Discuss the representation and propose a useful validation rule.
Solution
- JSON is human-readable but large and type-unsafe; strings like "high" can slip into numeric fields.
- A binary, schema-driven format (e.g., Protocol Buffers) enforces data types and cuts bandwidth.
- A rule that temperature must be between –50 °C and 60 °C filters obvious sensor errors.
Usernames are stored as case-sensitive strings. The system lets both “Ali” and “ali” register. Make a critical comment on this rule and representation.
Solution
- Treating "Ali" and "ali" as different users confuses login and mentions; the rule lacks clarity.
- Converting all usernames to lowercase before storage simplifies look-ups and avoids duplicates.
- A UNIQUE constraint on the lowercase column enforces the rule consistently.
Seat numbers are stored in a CHAR(4) field but the database accepts “00A3”. Provide a critical comment and a corrective rule.
Solution
- Allowing letters defeats the numeric seat-ordering logic; the representation is fine but the rule is missing.
- A CHECK (seatID ~ '^[0-9]{4}$') regex restricts inputs to four digits only.
- This ensures seats sort naturally and prevents allocation errors.
