Currently I am storing it then statements as facts of the following form:
ifA:sun_shine_today ifAthenB thenB:grass_grow_today

I have a process that reviews known facts and creates new facts if the condition in the subject is a known fact.  It then removes the condition from further consideration since the resulting fact already exists.

I am interested in how to store if then else conditions in a triple store.  Also I am trying to figure out how to store an “AND” condition or an “OR” condition.  An Example might be “if sun shine today and grass have water then grass grow today”.

See the folowing output for an example of current functionality.  The sentence parsing and mapping to the fact condition needs to be greatly expanded and the think process will be automatic in the future and “hidden”.  It currently shows the processing for debugging purposes:

alaric:_> if sun shine today then grass grow today
HARRY:_ Ok. If sun shine today then grass grow today.
alaric:_> if grass grow today then grass need mowing
HARRY:_ Ok. If grass grow today then grass need mowing.
alaric:_> if grass need mowing then alaric has chore
HARRY:_ Ok. If grass need mowing then Alaric has chore.
alaric:_> Does Alaric have chores?
HARRY:_ I don’t know if Alaric has chores.
alaric:_> think
HARRY:_ I think that if sun shine today then grass grow today.
I have reasoned that grass grow today.
I forgot fact: If sun shine today then grass grow today.
I think that if grass grow today then grass need mowing.
I have reasoned that grass need mowing.
I forgot fact: If grass grow today then grass need mowing.
I think that if grass need mowing then Alaric has chore.
I have reasoned that Alaric has chore.
I forgot fact: If grass need mowing then Alaric has chore.
Ok. I have thought awhile.
alaric:_> Does Alaric have chores?
HARRY:_ Yes,  Alaric has chores.

How can I link two or more facts together as a set of facts and then erase those facts without affected other personal user stored facts that I want to keep permanently such as “Alaric has son”?

(FACT1 IfThenElse (Fact2 Else Fact3))

You can walk the list of all IfThenElse facts. You can test if fact1 is true.  If it is, then you can assert FACT2 otherwise you can assert FACT3. Is that what you want?  When you say if a fact is true, you remove the condition from further consideration, what do you mean? How do you do that?

And conditions

FACT1 could be replaced by a fact that looks like this:

(FACT1 AND FACT4) —a simple dual and
(FACT1 AND ( FACT4 AND FACT5)) —a triple and
(FACT1 AND ( FACT4 AND ( FACT5 AND FACT6))) —a quad and

Mixing ands and ors…

The above has an implied order of evaluation for all those composite facts. So you could mix ands with ors in it. When you want complexity like   A   or (B AND C) or (D AND (F OR G)) 
then you might want to create a base fact and stack other facts off it, using a unique id.  E.g.,

(  (27 baseid x )  IFTHENELSE (FACT2 ELSE FACT3)) 
the first fact is just a holding place (the x is meaningless)

Then you can have facts like
(  (27 baseid x) CONDITION A)
(  (27 baseid x) CONDITION (B AND C))
( (27 baseid x) CONDITION (D AND (F OR G)))
where conditions are top level independent “or” choices for deciding that baseid 27 is in fact true.

I’m not sure what you mean by how can I delete some facts and not others. I would presume that all of these grass growing facts are not referenced by Aleric has a son fact.  So deleting any of them has no impact on other personal facts.
All you have to do is arrange for the facts you want to delete (FROM YOUR PERSONAL FACTS, NOT SYSTEM FACTS) to be in factset, and request delete of the contents of the factset.

Your explanation answers exactly what I was asking.  By setting the baseid to the same value for a number of facts then I can assign the fact to assert as well to the same baseid and then remove them once the fact has been asserted.  The use case is for math word problems where the chabot needs to process and store facts temporarily but once the conditions are evaluated the rules can be removed (by using ^delete(fact)). I do not want the history of temporary hypothetical math problems cluttering up the user fact history and I do not want to remove other facts the chatbot may have learned.  Using a baseid, I can assign facts to a category, sessionID, mathproblemid, etc.  Then instead of evaluating all “CONDITIONS” I can process just those conditions for a category, sessionID, or mathproblemID.

In order to get the “next available baseid #” I suppose I can maintain a fact for it:  (27 lastbaseid x) and increment it each time I create a new fact.

Using nested facts for AND and OR seems straight forward.  I thought I would have to create linking ids and worry about order and parenthesis, etc.  I will need to try creating a procedure to parse the nested facts out and test and apply the logic to assert the fact.  By using a baseid I can also have multiple asserted facts as a result.
( (27 baseid x) ASSERT (H AND I) )
( (27 baseid x) ASSERT J)

or something like

( (27 baseid x) IfTrueCreateFact (FACT7 AND FACT8])
( (27 baseid x) IfTrueCreateFact FACT9)

Well you COULD make a fact of the baseid but then you have to delete the old fact and create the incremented new one. Simpler is merely to dedicate a variable to it like $baseid, which you initialize to 0 in the basic bot macro that defines the bot, and then increment as you generate fact bases.

I should point out, that I was being overly general creating a baseid fact.  You don’t actually NEED a fact, just the baseid.
(1 ASSERT ..)
(1 CONDITION ...)
(1 CONDITION ...)

Having given you time to think over the slight red herring, let me be a little clearer and simpler.
Once you realize a unique id can be used in place of a fact,  then you will realize that unique id’s can be used at any level in a fact tangle…. eg.

(1 RECIPE “pot pie”)
(1 STEP 2)
(1 STEP 3)

(2 ACTION “open container”)
(2 ACTION “place in oven”)
(2 ACTION “heat for 10 minutes”)

(3 ACTION “eat”)

From the above you can query to find all recipes. You can get all steps of a specific recipe in order. For each
step you can get the sequential list of actions.  You can get ALL recipes that call for heating for 10 minutes, etc.

Obviously in the above example, there was no need to separate a step 2 from a step 3. Nor was there any need for STEPS as opposed to actions. What you NEED depends on what you are trying to do with the data and how you intend to retrieve it.  Facts in order can represent AND behavior or SEQUENTIAL behavior or OR behavior. It’s all in how you interpret your chosen verb.