Q&A about Design of Ontology and Formal Representation 

1) Property/3 and Instance_att/3 

The predicate property/3 does not give a default value for the class
that it describes. The predicate property describes the properties of
a class that is true for all instances in the class. It does not
describes the attrubites for the instances - this is describes in the
instance_att/3.     


 2)      I can see that you have instances of "slot" (e.g. slot1...)
         Do you expect to have instances of processor, etc., too?

          Yes, when that becomes necessary in the application that we
          are working on, which is not the issue for our current 
          problem. 

          At the moment, we are producing the best spec according to 
          customer requirements, that is, not having to compromising 
          the spec with what device is currently available in stock.  
          
          If one wants to confirm with what is currently available, or 
          even available for next week, next month, etc., then this  
          consideration can also be added to the representation. The 
          ontology is flexible in that sense because it can accommodate 
          both different kinds of problems and can deal with the time 
          factor to deal with the more complicated problems. 

3) The two arguments, List1 and List2, that are used in
   static_constratin/2 and dynamic_constraint/2 can be formally
   represented as: 

    List1 --> List2 

    It reads "if List1 is true then List2 is also true", and the
    IF-THEN constraint itself has also to be true for the final
    solution. Notice that terms used in List1 and List2 are written in
    conjunction normal form. 

    For instance, the first static_constraint/2 in the formal
    representation for the PC configuration domain can be
    interpretated as:  

          IF
          disk_controller has been allocated to slot1 and 
          process         has been allocated to slot2, 

          THEN it must be the case that slot1 is next_to slot2. 

    When the "IF" part of the constraint is not present, i.e. [],
    it means that, under all circumstances the "THEN" part of the
    constrain should always be true. This can be formally represented
    as: 
 
          true --> List2.

     The difference between static and dynamic constraints is that 
     dynamic constraints is negociatable. So that, if the dynamic  
     constraint is not satisfied in the current solution, one can ask   
     the customer to change the requirements - so eventually the 
     system can find a satisfying solution or a "nearest best"
     solution for customer requirements. This leaves doors open for
     other types of manipulation, e.g. the interactive type of
     systems. The formal representation of a dynamic constraint is: 

          List1 ~~> List2