Before people ask, there was no formal meet-up Sunday 5 Nov, But a few showed up and there was some discussion (unrecorded)—some of it directly about Tinderbox.
One Tinderbox related point was having, or growing, a Tinderbox that contains lots of different projects. The question was how do you plan for such growth in terms of being able to find things. The Ideas discussed were (in no deliberate order)
- If the content allows, place discrete subjects under separate top level containers; this doesn’t necessarily mean all content, but that which allows for clean segregation. Thus research into Athenian plays might best be stored separately (within the TBX) from a list of tasks needed for submitting your tax return. In this case there is no overlap and notes clearly belong to one or the other. This worn’t apply to everything, but where possible to compartmentalise, it helps. Why?
- Because if all your tax-related notes live under a root container ‘Tax’ ($Path
/Tax) then it is easy to query fordescendedFrom(/Tax)and know only tax-related notes are returned.
- Because if all your tax-related notes live under a root container ‘Tax’ ($Path
- Just because subjects may be separated in terms of the Outline view (the underlying structure of the notes as stored in the TBX), it does not mean you can then only such content in outline view.
- Prototypes. Whether specific to a specific strand of notes or used more generally, prototypes are useful for identifying notes of a particular type or role. Whilst many think most readily of visual styling of notes using prototypes, they also help with easy addressing for querying or other action code tasks. The query
$Prototype=="pReadingNote"(N.B. the == operator in the query, rather than a single=) will find all notes whose prototype is ‘pReadingNote’ across the whole document. So, in the above scenario in might find notes in both the tax and plays sections of notes. Obviously, having located such notes you can then work on them or run action code. - Tagging/Keywords. Whether you use $Tags or add one or more user attributes for this purpose, adding metadata in the form of attribute values can be useful if wanting to locate (or simply annotate) notes of a particular type of purpose. By using set-type attributes for tagging, a note can be tagged as having more than one purpose/task/relevance. In comparison, if there is a stand of tagging where the possible values are singular and discrete, it can help to use a String-type attribute to hold a discrete value. In a single-value attribute like a String, setting a new value replaces the previous one.
- This doesn’t mean to can’t both use a String for a particular stand on information and also put the term (or a variant of it) in your note’s $Tags. Your choice reflects you own method of annotation and searching.
Certainly, even if you don’t use separate sections within your TBX for discrete issues, the tagging described above will, if started while the document is still small, help later if you need to restructure your document.