Hi Folks, if one creates a search agent I saw a Michael Bekker video that explained how one can get it to convert an attribute into a text string so that a case insensitive query can be run for a partial match - eg $NLTags.format(";").icontains(“Ma”), when you are looking for a note that has, say, the first half of the acronym for Mobility-as-a-Service (ie MaaS) assigned to it in the NLTags set. I’m looking for help please on what to add to this query in order to further refine the search. If I wanted to obtain only the subset of notes that also had, say, a particular text string in the text of the note, what would one add to the agent query please? ie it would be “$NLTags.format(”;").icontains(“Ma”)" plus “x” (where x is further syntax to refine the search results). What agent query code could be added in place of x please? A few particular search refinements I’d like to be able to add would be for a text string in the note name or the note text. I’m assuming this would be helpful if one knew, say, the broad topic one had assigned to a note through its attribute tag, and wanted to find the note within that topic area that also mentioned a particular term or terms by name, in either the note title or note text.
So, if you want to match all but only those notes that have the case-insensitive substring ‘Ma’ you need to test the $Text of each note, which is done thus:
$Text.icontains("Ma")
If you need both conditions to be true, then you need to use an ‘AND’ join, thus:
$NLTags.format(";").icontains("Ma") & $Text.icontains("Ma")
If only one, i.e. either, condition needs to be true, use an ‘OR’ join:
$NLTags.format(";").icontains("Ma") | $Text.icontains("Ma")
If you want to do this in an agent and configure the search string (i.e. the ‘Ma’ above), then instead of using a literal string we would but that search string in the agent’s $MyString and use this query (with a & or | join as needed):
$NLTags.format(";").icontains($MyString(agent)) | $Text.icontains($MyString(agent))
The ‘agent’ term is a designator - see more here. If you wanted to use an attribute that didn’t get used for other purposes, you could make a new string-type user attribute $SearchString and use that instead on $MyString in the code above.
To search note titles (name), you would test $Name. The same and (&) / or (|) join syntax is used.
It could be, or, by using such short terms you’ll get too many matches. You need to experiment. As thus aspect of the app is still fresh to you, I’d proceed thus.
- Put you main document aside for now.
- Make a small document to test the above with at least one note you think match. As you’re testing any/all of $NLTags, $Text and $Name, you want a note match only one of each of those and perhaps one matching all 3 possible locations.
- Add a note that definitely shouldn’t be matched.
- As you experiment you may add a few note with edge cases that you think might match but shouldn’t of vice versa.
- working is a deliberate test allows you to try and fail without the noise of unexpected other interactions within your actual work document
- once you’ve experimented and are happy how the process works and the different effects of AND vs. OR joins in queries then move the query code into your main document.
Noting you are working with the Set-type attribute $NLTags, do looking into using Attribute Browser view. It can list all discrete values within the set and under the banner for each such value, all the notes using that set. See the link for additional controls in AB view.
Takeaway lesson: learn query techniques using a trest docu,ment so you aren’t introducing extra ‘noise’ into the test. Once happy, copy over the code and delete the test. Deleting test docs is good aas it:
- avoids a kitty-litter of abandoned tests
- makes one consider whether the task is understood and it is time to migrate the code to other document(s).
It may be that you want to kepp the doc as an ongoing test rig. In which case I’d adopt a habit of storing the latter separately from one-off disposable test docs, again to avoid a build-up of abandoned docs.
If you find yourself constantly building out the same test data, consider using ‘favorites’ to have a stationery-pad type blank documents with data in place ready to add test code.
This is absolutely fantastic advice Mark - thank you. Crystal clear, relevant, comprehensive. Tinderbox is so splendidly vast it is possible to forget how to do things in between uses of them. It is marvellous to be able to return home to this forum and tap your expertise on such matters.