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).

I work a lot with the Bible. My work is in many disparate containers and often this means I miss stuff. I've been thinking of setting up a TBX to contain all my info. Here's what I'm looking to do:

1. Create all my notes on the Bible in one TBX2. Use attributes to assign each note to specific Bible reference3. Use the notes to develop sermons/lessons/blogposts

Workflow1. Create notes in an inbox making sure each note is tagged with a Bible reference and subject tag, perhaps add a theme if it's clear. Maybe add a TableExpression that would sort note in various ways such a Bible reference or subject or theme.2. Notes that form a specific message get placed into their own container. The Container title will be the message title and it will have attributes showing whether it's a sermon, lesson or blog post. These will also be numbered in case the same or similar name is used in the future.3. Use agents to collect notes of interest. Create agents that collect all notes for example, that are from the Bible book "Matthew", or are to do with the subject "money" and so on.

A few questions:1. This would require a lot of agents. For example. Having an agent that collects notes for each book of the Bible alone would give me 66 agents. If I then create other agents based on subject or themes there'll be plenty more. Would this work or slow down my TBX to be unusable? Is there a better way to do it? I know I could split this into many TBX's but that would sacrifice having all the notes together.2. Over time I would want to see what the most used subjects are and link notes and messages together. How feasible is this? I know it's possible in terms of technology and functionality, but I use a macair and am concerned about the processing power required. The TBX will purely be text based, not images or video.

Please feel free to pick this apart if I'm going in the wrong direction! Looking forward to your comments.

There are a load of issues nested in this topic, but I'll pick out one for now. Do consider if you really need to have a agent searching for everything all the time just incase you want it. For instance, the new v6 attribute browser view is really good for investigating String, List/Set and Number type data. The view controls let you switch target attribute easily. It's quick to open a new (Attribute Browser) tab set an attribute of choice, look for top listing and then closing the tab. Info's quickly gained without adding any persistent structure to the doc. Being able to do this has made me start to think about (re-)structuring projects so attributes/agent/code easily feed things like Attribute Browser so I've fewer always on (or present but turned off agents). for instance, if an 100 notes use an prototype with a rule, that's 101 rules in the rule cycles. add an agent matching all 10 notes and that's 201 rules potentially running.

My advice therefore is rather than think of "what's the easiest 'always on' approach so I don't have to think about stuff?" to "what's doI need to compute store so info's easily available if/when I want it.

For 100 notes, constantly re-running the same configuration rule just so any later edits are noticed is fine. For 1,000 or 10,000 notes, I think that strategy's wasteful. It's not an issue over how 'fast' TB is, but rather how tasks scale. Every time you want to speak to a neighbour you could know every door until one is answered by the person you want; but as the neighbourhood grows it pays off to figure a quicker way to remember/find the one person you actually want.

Thanks Mark, that's a really great help. I never thought about the Attribute browser, but that would really meet my needs. It also means I need to take a really close look at attributes.

Does the Attribute browser allow compound display? What I mean is can I build views? If I have an attribute that holds a value such as a book of the Bible "Matthew". Can I then select a second attribute such as $BookChapter and perhaps a third, $BookVerse? If not how would I solve that problem? I may end up with hundreds of notes on the book of Matthew, how do I then select on chapter 7 and perhaps a specific verse?

The best thing is to experiment, as only you will know exactly how you want to view the data. The Attribute Browser works on a single attribute, but you can also set a scope, e.g. only notes in a particular container - which might be an agent.

The view shows each discrete value for Strings/lists. For list (Set/List) attributes a note shows in every category for which it has that discrete value. Numbers are shown split across 10 equally sized groups between zero and maximum (in fact just above the maximum).

Each category (discrete value (or number value range) can show a total based on the main selected attribute or another. Thus for a trip the main attribute might be $City and the summary be based on $Price, showing expenses per city. within the categories notes can be sorted using an attribute in normal or reverse order.

An optional agent can be used to filter the view further, i.e. everything with a value for the chosen attribute, within the scope set, but which also meet the agent's criteria. The agent can also apply a action to those notes too.

As I say, the best thing at this point is to try an Attribute Browser in your doc - or make a new one with some test data and see how the view looks. A small test doc may make it easier to try deliberate edge cases and see you the view performs for you. As with other views, now everyone will need it and not everyone will use all the features. However, I think will likely assist in you project.