IPT home IPT A Virtual Approach by Peter Whitehouse
Quick Links:
ORM home
Information and Intelligent Systems Social and Ethical Implications Human Computer Interaction Software and Systems Engineering eXercise Files Course Outline and Assessment A-Z of Geeky Acronyms Terrace Work Program 2004 Sillybus FAQ = Frequently Asked Questions Help


Atomic Propositions

Communicating Facts

Facts (data/information) may be expressed in many ways - speech, writing, diagrams etc.

'Facts' may be true or false, but are simple propositions, or information in (preferably) basic or ATOMIC form.

To avoid ambiguity (due to poor expression or nuances within the language), a more formalised natural language has been devised.

eg. Carol studies IPT

This fact may be True or False (she may or may not study this subject, we could, however store the information regardless of it's correctness). The fact is comprised of two objects (a person called 'Carol' and a subject with the acronym 'IPT') and a relationship ( studies). The above fact is in INFIX form (the role is embedded amongst the objects.

We could re-stated the above fact without loss of information in PREFIX form as

studies ('Carol','IPT')

Although the prefix form of the fact looks a little strange (unless you are Yoda "... mmm Studies IPT Carol does") it still says the same thing. PROLOG stores facts in prefix form, and usually calls them clauses.

The connecting term/phrase is called the predicate (or role) and provides the lexical or linguistic link between the connected objects (ie. the 'meaning')

Both formulations above are examples of a binary fact - ie. there are two entities involved in some relationship.

General binary fact form : entity predicate entity
prefix alternative: predicate (entity, entity)

Entity are OBJECTs and can be either physical objects-things you can touch (eg. persons) or abstract objects (like a rating in a subject).

Fact types (sometimes called elementary sentences) come in pre-packaged shapes - that is they are constructed with particular types of objects in mind.

desk studies grossPay

The above attempt to use the fact type is obviously NONSENSE - clearly, certain FACTS rely heavily on CONTEXT and ENTITY TYPE.

FACT TYPES (or Sentence types) are only defined for ENTITIES they were designed for. The following deep sentence structure analysis begins to explore the objects and the nature of their relationship:

   Entity of       studies        Entity of
   type Person                    type Subject         is clearer

   Entity of       studies        Entity of
   type Person                    type Subject    entity category
   named                          with acronym     label category
   'Carol'                        'IPT'.        instance category

When using a 4GL or 5GL, we need to define the type of each label category (eg. integer, char(8)...)

Facts may be UNARY (involving only 1 entity and a predicate)

   eg:     'Fred' is_male      or    is_male('Fred')
           'Julie' is_female   or    is_female('Julie')
           'Olivia' is_male

where "Fred", "Julie" and "Olivia" are all examples of entity label instances

Facts may also be Ternary (involving 3 entities and 2 predicates)

 eg:   'Phil' has_height 175 at_age 17
         or   has_height_at_age('Phil',175,17)

This fact is also ATOMIC as it cannot be split into separate facts without the loss of information...

           'Phil' has_height 175
           'Phil' has_age 17
           17 is_age_of_someone_with_height 175

the 're-expression' of facts as simpler facts can often lose the relationships between specific entity instances

   name = reference         cm = reference      yrs = reference
   person = entity          length = entity     age = entity
   "Phil" = instance        175 = instance      17 = instance

sometimes, a fact involving 3 or more entities may be split into simpler facts without the loss of information:

        'Olivia' enjoys_eating 'Broccoli' and 'Tripe'

     same as:   'Olivia' enjoys_eating 'Broccoli'
                'Olivia' enjoys_eating 'Tripe'

notice the statement of two simpler facts represents the same information, and uses the general fact type:

entity of type person likes_eating entity of type food_type

Fifth Generation Architecture

If 2 humans are discussing a UoD, it should be possible to replace one of the humans with a 5GIS (with appropriately specified UoD), without significant change in the language used for communication.

     CONCEPTUAL SCHEMA = description of UoD including
     facts and rules.
     INFORMATION BASE - stored somewhere, somehow, but
     whose 'state' is understood.

CIB - The Information Base is initially empty, and with each update request, the STATE is changes. For argument sake, imagine the IB is designed to contain facts about war, and only has the following fact:

America is_ally

By the inclusion of a country in an is_ally relationship, we explicitly state who is our friend. Does the omission indicate the converse? Clearly we need to be careful what inferences we draw from data that is not included.

If we add the fact: Japan is_enemy, we have fundamentally altered the state of the information base - a STATE TRANSITION has occurred.

A CONCEPTUAL SCHEMA contains a formalised description of the UoD, contains

  1. Stored Fact Types = kinds of facts which can be stored = types of entities + reference + roles
  2. Constraints = restrictions applying to fact types = static constraints that apply to all DB states + dynamic constraints that forbid certain changes. Also known as VALIDATION RULES
  3. Derivation Rules = list of functions, operations + rules used to derive info not explicitly stored in the DB (inc. calculations (eg. +,-,*, sum, avg....). Derived fact types also listed as rules (rather than stored as fact types to avoid update anomalies)
  4. Transition Rules = allowable state transitions for facts already stored (eg. married --> divorced, single --> married, married --> widowed, widowed --> married)

To transact with the database, we use a CONCEPTUAL INFORMATION PROCESSOR, which has three main functions:

  1. Design Filter - humans describe UoD, with CIP approval, a conceptual schema is formed. Changes to UoD also overseen by the CIP
  2. Data Filter - user updates facts stored in IB, theCIP checks for consistency, if OK then changes committed.
  3. Info Supplier - user queries about the UoD, the CIP replies by first drawing the answers from the IB

CIP Problem 1

Stored Fact Types:

     F1   Person  IsBrotherOf  Person
     F2   Person  IsParentOf   Person
     F3   Person  Has          Height


     C1   Each Person's Height must be recorded
     C2   Each Person has at most one Height
     C3   Nobody is his/her own Brother
     C4   Nobody is his/her own Parent

Derivation Rules:

     D1   avg(Height) returns the average of the recorded heights
     D2   X IsUncleOf Y if X IsBrotherOf Z and Z IsParentOf Y

The conceptual schema above can be represented diagramatically using a Conceptual Schema Diagram as follows:

CIP Problem 1 CSD

Determine the CIP responses to the following requests (assuming the Database is EMPTY initially, and each request is processed before the next is issued):

+ Person "Alan" Has Height 178
+ Person "Alan" IsBrotherOf Cat "Felix"
+ Person "Alan" IsBrotherOf Person "Sue"
+ Person "Sue" Has Height 170
+ Person "Alan" IsBrotherOf Person "Sue"
+ Person "Alan" IsBrotherOf Person "Alan"
+ Person "Alan" Has Height 180
- Person "Alan" Has Height 178
+ [ - Person "Alan" Has Height 178 + Person "Alan" Has Height 180 ]
+ Person "Mary" Has Height 175
+ Person "Sue" IsParentOf Person "Mary"
+ avg(Height) = 174

Suppose the following queries were legally expressed, and the database was complete with facts from the previous section:

avg(height) ?
Who IsUncleOf "Mary" ?
Who IsAuntOf "Mary"

Suppose this additional information was added to the UoD:

F4 Person Eats Food
C5 Each Person Must be recorded to Eat a Food

If the database started out EMPTY again, what would the CIP respond with in each of the following cases:

+ Person "Bob" IsBrotherOf Person "Anne"
+ Person "Anne" Has Height 170
+ [ + Person "Anne" Has Height 170 + Person "Anne" Eats Food "Spinach" ]
+ [ + Person "Bob" HasHeight 175 + Person "Bob" Eats Food "Apple" + Person "Bob" Eats Food "Spinach" ]
+ Person "Bob" IsBrotherOf Person "Anne"

CIP Problem 2

Stored Fact Types:

     F1    Person Has FitnessRating
     F2    Person Plays Sport
     F3    Person IsExpertAt Sport


     C1    Each Person has at least one FitnessRating
     C2    Each Person has at most one FitnessRating
     C3    FitnessRatings are denoted by integers 1..10
     C4    Each Person IsExpertAt at most one sport
     C5    X IsExpertAt Y is stored only if X Plays Y is stored

Derivation Rules:

     D1    count(Plays Y) returns the number of players of Y
     D2    X IsFootballer IF X Plays League OR X Plays Union OR
           X Plays AustralianRules

The conceptual schema above can be represented diagramatically using a Conceptual Schema Diagram as follows:


If the Database is initially Empty, what would the CIP response be to the following update requests:

+ Person "Gladys" Has FitnessRating 9
+ Person "Fred" Plays Sport Soccer
+ Person "Bob" Has FitnessRating 7
+ Person "Gladys" Has FitnessRating 8
+ Person "Olivia" Has FitnessRating 7
+ Person "Freda" Has FitnessRating 15
+ Person "Gladys" Plays Sport League
+ Person "Bob" IsExpertAt Sport BonsaiTreeClimbing
+ Person "Gladys" IsExpertAt Sport League
+ Person "Olivia" ProgramsIn Language Cobol
+ Person "Gladys" Plays Sport Badminton
+ Person "Freda" Plays Sport Judo
- Person "Freda" Has FitnessRating 7
+ [ + Person "Bob" Has FitnessRating 8 - Person "Bob" Has FitnessRating 7 ]
+ Person "Gladys" IsExpertAt Badminton
+ Person "Bob" Plays Sport Soccer
+ Person "Freda" Plays Sport Judo

Assuming the following queries are legally expressed, and the database is loaded with the facts from the previous section:

Person "Gladys" Plays Sport League ?
Who Plays Sport Judo ?
count (plays soccer) ?
Who is Footballer ?
What FitnessRatings are permitted ?
What is the meaning of life, the universe and everything ?

©Copyright t 1992..2018+. Edition 26.150117
Creative Commons License
This work is licensed under a
Creative Commons Attribution-NonCommercial-ShareAlike 2.1 Australia License