News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

Hi - I haven't posted here for years as haven't been using T'box much. Recently been asked to manage volunteers for a local church. The key task is to keep and maintain a list of volunteers, their roles and whether or not they have necessary criminal records checks, training courses etc on file. There will be a need to generate a simple report on an annual basis with Surname, Forename, role and whether training course, CR checks etc done. The number of volunteers would be around 50. Certainly no more than 100

My first thought was a relational database and I tried to design the tables. It got complex very quickly as there are many:many relationships everywhere (volunteer:role:role requirements). I'm also not confident that I fully understand the problem domain yet (I strongly suspect nobody in the parish does which is a problem) so I don't want to spend ages designing a database that would have to be scrapped. I still need a workflow to get me started however.

I then remembered Mark (Bernstein's) point that T'box was a good fit for problems with dozens or hundreds of entities and when your understanding of the problem is evolving as you work on it

I've made a start today with notes for volunteers and adornments for roles. Once I'm satisfied all the requirements are met I will drag volunteer to adornment. Currently, the volunteers are all sitting on an adornment named "in progress" I plan to use alias's to cope with volunteers having multiple roles. The volunteer notes have custom attributes (inherited from a prototype) to record the existence and date of mandatory courses etc. There will also be list attribute to record roles. I appreciate this is recording the role information twice but the attribute can be searched by agents and the adornment allows a quick visual scan which is nice.

I plan to use agents to generate the necessary reports, maybe exporting to a table with a bit of markdown maybe?

Being very rusty wanted to see if folks here felt that this was sensible approach or had better ideas or thought that T'box not the tool for the job

Hi (I recall meeting at a TB w//e - London 2010?). I think you've two parallel problems. The first is capturing the multiple relationships. The second is visualising/reporting them.

For the first you could have an attribute per relationship type, or a Set-type attribute to capture them all (or several if discrete sets). There's no 'right' way - the choice boils down to your dat and your style. Generally, if there are a *lot* of relationships having one attribute per relation may not scale well. But the joy of TB's easy incremental formalisation is if you start down a path that's wrong it's not the complete do-over to fix as it would be with a normal database.

A different axis of this is the number of folk involved. Let's say you've 50 people and 10 possible roles (attributes), by the time you've got 30 people added some with up to 9 aliases the map will get very busy. Thought: if only 4-5 different roles consider map aspects like badge/colour/shape/pattern to capture all roles without the need for aliases.

I did indeed meet you all but it was in Cambridge, I think around 2006/7?

Thanks for the reminder about set attributes. It looks like these have been enhanced since I last used T'box to become list attributes? Plan to use these as a flexible way of recording roles.

After my first post I had a small epiphany (small ones are all I ever get!) about the "dual representation" of roles in list attribute and also by means of positioning on role adornment. They don't necessarily duplicate if we take one as meaning "qualifys for role" and the latter as meaning "is assigned to role". It might also be an opportunity to put in place a check so that, for roles that require it, the adornment could check that the necessary CJ check has been done or otherwise it would change the badge to a warning sign

Not sure how I could use badge/colour/shape to capture roles as you suggest Mark (A) however if we are sticking with a simple 1 note = 1 volunteer model. The cognitive burden on me to remember that "blue border plus red stripes plus stave symbol means choir member, driver and Eucharistic minister" and so on for every role combination would be heavy

I see what you mean about multiple roles per volunteer leading to a busy map but I am somewhat drawn to the conceptual directness of plonking a volunteer on one or more jobs. Makes drag and drop quite concrete! I can already get a real sense for the size and shape of the work from this

I'll play around and see how it goes. At the very least it will be a useful way of managing the transitional workflow without committing too heavily to a design until we get our backlog cleared and routine operations established. Then a relational database might work

[Aside: well remembered. Yes it was Cambridge TB w/e in Apr 2007 (the first TB w/e I attended).]

I agree about visual complexity of lots of border/pattern/etc., colouring making for a busy interface but some folk do like it - thus the suggestion. As ever with TB, there's no one right way. I see how dragging a person/note onto an adornment might ($OnAdd) apply a role to that's person's attribute data. However, I don't see how you get round the problem of Person A being in 4 roles (i.e. on 4 adornments at once) without the use of lots of aliases in which case I wonder how well things scale.

Still, with Tinderbox's good support for formalising as you go along you needed be too fearful of following the odd blind ally in finding you own most comfortable/intuitive set-up. The less tidy the problem, the more I think it suits a TB-based solution.

As you do about your map, keep a side thought for how you might stratify that 'flat' structure for exporting data (e.f. reports of whose on which role/stages of qualification/etc. I suspect agents may cope file but it's worth not-entriely ignoring export needs unless you 100% certain all data will only ever live in your TBX (as can be the case).

Volunteer application is working nicely in tracking people through the stages of the process and the volunteers are beginning to trickle out the other end. I find I have forgotten stuff I used to be able to do with Tinderbox.

I was hoping to start to develop a simple reporting feature by first collating a list of volunteers in regulated roles.

An agent with a query

$IsRegulated==true;

Works OK but trips up by including the prototype I use to record regulated volunteers which obviously has the attribute "IsRegulated" default to "true"

I next tried the following code in a query;

$IsRegulated==true;$IsPrototype==false;

The second constraint doesn't seem to be tested for. I'm sure it's a syntactical issue rather than a conceptual one. Should there be some form of AND boolean operator to indicate that I want to see notes that satisfy both requirements? Looked in the cookbook but didn't see any applicable examples and the help file was similarly silent.

I hope to eventually export the report as plain text with a table defined in Emacs org-mode. I note however that the option to use a plain text export format seems to have disappeared. Any thoughts?

Further to Alex's answer - with which I concur - semi-colons aren't used in queries at all. If your query has more than one test, then each successive test must be 'joined' to the preceding one.

All joins are one of two types: an 'and' where all test must be met, or an 'or' where at least one test must be met. In TB queries, an ampersand '&' signifies an 'and' join and a pipe '|' is used for an 'or'.

I had been mightily buffaloed by exports, but here is what I think is the simplest possible way to get something started:

Step 1: Go to File/Built-in Templates and click HTML. This installs some HTML templates in your file and avoids getting the "No Template Found" error message when you try an export.

Step 2: When you open a note or, better, its prototype, go over to the text pane -- the right-hand window. Click the HTML tab, and where it says "Template / None," then choose from the dropdown list the HTML-item template you installed in step 1.

There are a million refinements you can apply, but this at least gets you past the "why on earth can't I export anything" hurdle.

Thought experiment for Eastgate: by default, install those built-in templates when someone creates a new file, or maybe the first time someone clicks on the HTML tab. That might complicate things for veterans who want control over their templates, but it would avoid the startup barriers to using this feature.

The application, such as it is, works very well. Tinderbox is a good tool for looser bodies of information and workflows which are as yet not fully understood and defined.

Still stumped by export but haven't had time to study the information on this topic and in the tinderbox way, in sufficient detail. What I'm struggling with is the recursive nature of template(s) needed to export a container and certain fields from the children of the container. In the interim, in just typing the information from screen. This works OK with the small numbers I have so far but won't scale well

Happy to send you anonymised version of my document if you like though it's so simple it's hardly worth it. Email me on