Oddly, Google search of aTbref appears to be working again. I mention that in case it helps anyone.
Is there somewhere to contribute (minor) corrections to your excellent aTBref resource?
I noticed for example a page titled ‘Neuro-linguistic programming’ describing what I think are actually ‘natural language processing’ features which populate various $NLx attributes.
Thanks again for your tremendous work supporting the use community.
The two terms seems to be used interchangably, ther in the was ask two peolle for a definition of AI and you get three answers! Thus, I’m not sure which should be used, or if both which apply where. I’m very happy to take guidance.
Just send me a list of changes, i.e. URL of the page and the bit of text to find and replace. If I’ve got to go look stuff up, it won’t get fixed as quickly. In context, I’ve been making changes to aTbRef all day, tracking issues being raised now the new release is out.
Find me. By all means post here, message me in the forum (so everyone can’t doesn’t have to fead it) or email me. I’m not bothered by corrections in public - I want the resource to be as useful as it can be so all corrections/clarifications are gratefully received.
Have to say that the most common method I use for searching aTbRef is going to the Site Map and doing a good old Cmd-F. Obviously that doesn’t snag everything in the way a text search does, but it very often gets me where I need to go.
I am wondering if one method might not be use $Tags in the source TBX for keyword/search terms and just write them into the foot of the text. It would also allow for rapid improvement, especially when dealing with vocab misalignment between user and resource. IOW, when I search for term ‘A’ but the resource actually uses term ‘B’ to describe the same think. Plus such mapping also opens a feed for a page(s) of cross-app terminology or process difference.
I mention the latter as an unfortunate number of threads tend to start “A use app A a lot, Tinderbox doesn’t work like app A, as everyone knows … rant, etc.”. Such frustrated souls could be pointed to a form of look-up table. It isn’t Tinderbox’s task to be like app A but it doesn’t mean working with both need be hard.
Going back to a $tags based index approach, it would make it easier to crow-source some tags as I’d just need to know the URL9S) and tag suggestions. In such a scenario I’d probably make a ‘tag’ list as a page. Static html pages don’t lend themselves to the tags linking to use instances (I’d need 120s or 100s of such index pages and the TBX load would be heavier as each page would represent a query of some kind in the TBX. But, even a static list might give an idea of things that ought to return
some results for a web-based search.