AI Zone Admin Forum Add your forum

NEWS: Chatbots.org survey on 3000 US and UK consumers shows it is time for chatbot integration in customer service!read more..

recognize matched concept, from inside choice brackets + concept words changed to all caps
 
 

Hello,

I have a responder with a bracket which contains ~concepts. That works perfect. After some processing, which concept matched will determine which responder to reuse. That’s the issue. I can’t do this:
u: ( [ _~concept1 _~concept2 ] )

Neither this

If ( _0 == ~concept1)

And this gives me false positives

If ( _0?~concept1)

Could you please suggest a solution?

——

I have a concept with a list of words defined as NOUN and all words are written with the first letter capitalized. The system converts some of the words into all caps. This can be seen by tracing or query responses or the keywords1.txt file. I’ve found no pattern into why specific entries are changed to all caps. I searched all files in ChatScript to find these words defined as something else, but that’s not the case. Example changed words include Circuits, Analytical Methods, Digital Design. Other words with no issue include Elements, Digital Logic, E Circuits. I haven’t had a major issue with this, except for the query returns looking weird in all caps, and the word Circuits. That word is the only one which when queried does not match unless the user enters it as all caps. On the other hand the word Circuits is the only one that does not appear all caps inside the keywords1.txt file.

Thanks

 

 
  [ # 1 ]

First, how to find which concept matched…  The system has determined a word is a member (direct or indirect) of some concept.  Am I to assume the concepts are non-overlapping, that it cannot match multiple of these concepts at a time.
Not that that’s essential.

A solution is the same as one I use to handle Loebner qualifier questions like “which is bigger, an elephant or a termite.”
I have a master concept (~sizes) that lists concepts of varying size.
I break the world into various size concepts from ~microscopic to ~handsized to ~humansized to ~elephantsized to ~cityblocksized etc thru to ~astronomicalsized.  These all contain collections of objects.  So if I write a pattern
u: ( [big small large heavy light] * _~sizes or * _~sizes) 
then I know someone is trying to compare two objects whose sizes I know approximately. Then I do two things, where you only have to do one.  I determine what concept a word is “as it enter the ~sizes” concept. And then what position in the ~size concept set that is, comparing it to some other concepts position. But you don’t care about position. You are not comparing. You just want to know what set the item was in as inherited precursor to your top level list.  That’s a query.

Its this query:
^query(up2set _0 ? ‘~sizes 1 )
The set ~sizes is characterized by facts like (~city-sizes member ~sizes)  (~microscopic-sizes member ~sizes).
This query returns the fact that is one of these top level facts of ~sizes.  Eg:  (~human-sized member ~sizes)
which means @0subject is the name of the concept that it matched before becoming ~sizes.

I’ll answer your other question shortly.

 

 
  [ # 2 ]

as for the capitalization question…. I’m not sure… here’s what I do know or can ask.

1. if you :prepare the sentence, does the word show up in caps as the final tokenized result?

2. The system can only store one form a word in upper case. So if you create LifeBoat and LIFEBOAT, only the first one goes in the dictionary and any other capitalized form of it is considered that one.  So IF (which we presume is not the case), in the dictionary we had “CIRCUIT”, then any spelling Circuit would be converted to the first one.  But you suggest this is not the case and there is no reason for me to believe that the all caps version would ever be in the dictionary.

3. The system does sometimes convert case an input for testing purposes. It is supposed to do this only on copies of things and not damage the actual world. But if I had a code mistake, one could imagine what you describe. Except that I generally LOWERcase everything, not upper case it. So that seems unlikely. 

So let say first, tell me the results of :prepare, and email me your trace file you have the example in.

bruce

 

 
  [ # 3 ]

I appreciate the solution. I does seem a bit involved…
Yes, the concepts are non-overlapping.

Would this solution require me to define a master concept?
Is up2set a system definition?

In my case (which involves 3 concepts), would that solution involve more computation than having 3 identical responders?

From 2nd answer:
With :prepare, the word does not show up in caps. The issue seems to be when matching in the query.

Last edit:
When I wrote the email I saw the issue. That word is the only one which canonization played a part. So yeah, no issue there shut eye

 

 
  [ # 4 ]

It would require a master concept. Up2Set is a predefined Query type.
if YOu only have 3 concepts, you could just write rules for matching each concept and thus know what concept was involved. already.  So you don’t write union of 2 concepts, you write separate responders. They can use REUSE and set a global variable before doing so, but the pattern match is just completely separate.

 

 
  [ # 5 ]

surprised

Ed UF - Jul 23, 2012:

And this gives me false positives

If ( _0?~concept1)

 

But this doesn’t:

refine()
  a: (_0?~concept1) ^reuse()

 

 
  [ # 6 ]

Not sure what you are trying to do here…

your ORIGINAL pattern was:
u: (_[~concept1 ~concept2])
And I’m saying when you do that, you have lost which concept it came from without more work to get it back, and
u: (_~concept1)
u: (_~concept2)
would allow YOU to know which concept was matched.

Patterns and concepts ALWAYS work perfectly.  Use of the script operator ? is subject to potential flaws. First, is it the original word or the canonical that is a member. the pattern code always uses BOTH.  a script request like if (_0 ? ~set) is asking for only a specific one (the canonical in this case).  Second, there might be a bug in the within code since it is separate from the pattern match code.

As always, this is a general discussion. If you have actual code for me to test, with an example to try, I’m happy to receive an email and find the fault. Right now I don’t know how to recreate your specific problems.

 

 
  [ # 7 ]

I have no clue why a query call would force upper case on anything. I’d have to run the example.

 

 
  [ # 8 ]

What I originally wanted to avoid was having redundant code, so separate responders was my last choice. While doing that I came up with my last post, which so far is giving good results. In summary I have (but with 3 concepts):

u: (word _[ ~concept1 ~concept2 ] * otherwords)
Some processing ...
refine()
  a: (_0?~concept1) ^reuse(call1)
  a: (_0?~concept2) ^reuse(call2)


The issue with the query was mostly not using the apostrophe to keep the original input and not due to the all caps issue. The all caps issue, i.e. “Why would the system upload some words in a concept as all caps?”, you did answer with point #2, which made me realize the words (or phrases) which are converted to all caps exist in a table in all caps form. And then i saw in my files.txt that I import the table before the concepts.
And that’s that smile

 

 
  [ # 9 ]

unnecessary post, sorry.

 

 
  [ # 10 ]

good. so caps was not a bug on my side…

you can also write this:
u: (word _[ ~concept1 ~concept2 ] * otherwords)
Some processing ...
refine()
  a: (~concept1) ^reuse(call1)
  a: (~concept2) ^reuse(call2)

which is even faster and simpler.

 

 
  [ # 11 ]

So…. are we all good now?

 

 
  [ # 12 ]

yep. Thanks!

 

 
  login or register to react