I think there are two aspects to attribute choice: the data type of attribute to use, and use of built-in vs. user attributes. Then there is use of prototypes.

Data Types. IF you want to be able to do date arithmetic ("How long was X in office?", "Did X serve longer than Y?", "Who was last to leave office - X, Y or Z?", etc.) on the characters you are tracking, use Date type attributes. Note that under the hood TB Dates are actually times (actually microseconds before or since a set reference time) and thus even if not shown a date includes a time; you're free to ignore the latter and in some contexts can hide it. TB also provides tools for working with dates at day scope, i.e. ignoring time.

Conversely, if you just want to note a date as a bit of reference text you should be OK to store info in a String type attribute, e.g. "Dec 2016". I won't explain here but if you do mess up and realises you've started with the wrong data type, it's not impossible to change latter (we can discuss that separately if the need arises).

Built-in or Custom attributes. If you do go down the route of Date-type attributes, it likely you will benefit from creating your own attributes. Tinderbox has $StartDate, $DueDate and $EndDate pre-defined. However, you may need to note (as a Date) someone's nomination, approval, taking office, etc. Each of those could be a discrete user-created Date-type attribute ($NominationDate, etc.). If going this route, I find it useful to put something in the attribute name to indicate the data type (e.g. 'Date' suffix for Dates, 'Str' suffix for strings, etc.).

Just because you record data in attributes doesn't mean you can't still have it in note text ($Text). The boon of attributes is the data can be viewed/manipulated/exported discretely from the note's $Text.

If you make custom attributes, then definitely think of using prototypes. There's no one right way. You might have separate prototypes for each type of office you are tracking or you might just use one or two prototypes and alter the prototype's Key Attributes to show a different set of attributes depending on the task you are doing at the time.

If you use custom dates, consider leaving $StartDate/$EndDate unused. This leaves them free to be populated by other attribute's data if you want to use a timeline. By default, timeline view plots $StartDate/$EndDate but you can set a different Date-type alternative for either/both of the defaults though you can't plot data from more than a single start and single end Date attribute.

Does that help?

Broadly, yes to most of the confirmatory questions. However, my approach to prototype is to experiment in a test file, or a copy of a real work doc to see what I need, so I can then build/configure a prototype from a new note. this avoids taking a note that may have detritus from lots of abandoned trials (in terms of now non-inheriting attributes). so, I'd figure out the extra attributes I need, than make a new prototype note and add the necessary key attributes. You don't have to do it this way but experience suggests it helps if you can can on with such an approach.

Quote:

Not quite. You can do as above, but if I understand your project right, I'd make custom Date attributes per each discrete type of date event you're tracking. This enables each event to be stored/accessed discretely.  Leaving $StartDate/$EndDate unused at this stage leaves them free to use for timeline visualisation where you might want (event) dates drawn from more than one source. In other words you want to plot the nomination date of Person A but the approval date of Person B, etc., noting that those events live in discrete attributes (e.g. $NominationDate vs. $ApprovalDate). By setting A's $StartDate to equal A's $NominationDate and B's $StartDate to equal B's $ApprovalDate the two are more easily visualised. It all depends on what you want to do.

Quote:

I think the above already answers this. If you make sufficient Date-type attributes for the start and/or end of each discrete date event relevant to the holder of an office, then each date is discretely recorded as a date and is available for display (as a note KA) and/or for calculations.

Does that help?

Quote:

Yes. Of course, we readers here don't know your data - only you can know how many attributes you need and what best to name them.  

Q1. You can suppress display of the time element of attributes displayed as KA - see more. If insisting on neat times, I'd fill in the dates and then make a stamp that works with Date.hour, etc. to set a common time in h/m/s for each of your custom Date attributes in each of the notes using them.

Q2. I don't understand the data. Are you saying you've put the job title as part of the not'e title (i.e. its $Name), or is it added via a $DisplayExpression, or is the job title in an attribute of its own.  If the latter don't overwork which attribute. If you can't find a suitable built-in one, make your own; more important the latter case is considering the data type for that attribute.

The nature of your questions makes me think your trying to conceptualise everything before actually touching the doc.  I think that's not the best way to leverage Tinderbox which bis very supporting of experimentation. The only caveat I'd make to that is experiment in new to-be-discarded docs intended just for exploration/test, as opposed to messing up your 'real' file with all the data you've carefully  added.  If you need specimen data for a test, make a copy of your real file, give it a name significantly different from the original so your know it's a test, then experiment.  Once you've understood an issue you can apply the desired solution to your main work folder.

So, for instance, make a new file and add the built-in 'Event' prototype. Now add a few new notes and set there prototype as Event, thus showing $StartDate/$EndDate/$DueDate as KAs allowing you easy experimentation with how the time elements is displayed and possible stamp or quickstamp approaches to altering time in Date attributes. Then, once confident in the choices you prefer (they will differ person to person), apply them to your main work doc(s). Actually trying things early is a faster route to understanding the depth of the app.

Q3. DEVONThink has its own pseudo-protocol (something like devonthink://etc...) which you generate within the DT app and which work within the context of a single Mac - i.e. opening the URL opens DT at that note. Such DT URLs can be placed in $URL or in custom URL-type user attributes which can be exposed as KA.  I've not tried but if you make a 'web link' in $Text and use a DT URL as opposed to a web (http://...) one I guess it would also work, as in all cases TB hands passes to URL to Finder to resolve and it opens DT or your web browser or whatever. For other apps you could use a $File or a custom File-type attribute to store a path to the data file of some other app for as with URLs, TB just passes the path to finder and asks the latter to open it. DT is somewhat distinct in allowing external (local) access direct to specific notes; for other apps likely the best you can do is open a given data file in the target app.

Q1. That makes sense - it seems the primary link I added 'see more' didn't generate a link in the actual post. I've now fixed that in the post but I also now add it here as well. The display options for date/time fields set via the doc settings are here; note that 2 of the 3 display only the date. The second option is like the default but date only. The 'by the way' comment in the your answer is aimed at the wrong person - I'm just a user of Tinderbox. I document how the app works, I don't design its features.

Q2. You still haven't answered the question. I suggest you give be actual examples of the discrete bits of info you want. The picture in your mind may be clear but it's difficult to guess without some exposition.

Q3. As I understand it you want to have a link from a Tinderbox note to a DEVONThink note. For that, you need a way to address the DT note. DT offers a way to do this as a URL (OK, a pseudo-URL but the difference is moot to most folk). Once you have this you use it as a URL. What TB doesn't have is a way to 'just' guess which DT note in which DT database you want to access. Instead you get the data in DT and use it in TB. It's really no different from copying a URL in your web browser's location bar and then using it in TB. If finding the data in DT isn't easy, that's best taken up on DT's forums as it's something over which TB has no control.

Ah, I'd assumed you were using the current version (v6.6.5). The doc setting to alter display of Date attributes as KAs was added in v6.3.1. In earlier versions such attributes use the default with is the date in your OS' locale's short date format.

As to #2, You additional info helps. I'd guess a mapping like:

-Name => $Name (i.e. the title of the note)
-Title => user string attribute $JobTitle
-Gov. Agency / Department => user string attributes $GovAgency, $Department
-Various dates ranges (e.g., nominated, approved, stated working, stopped working) => user date attributes e.g. $NomDate, $ApprovalDate, $JobStartDate, $JobEndDate, etc.

Those are just suggested attributes names. Using these or similar doesn't stop you also having the info such as job title in the $Text as well if it makes sense to do so. Having a discrete attribute mainly aids clarity of display (e.g. as KAs etc.), addressability (e.g. agent queries, actions code) and export (e.g. a list of job start dates in ascending date order). In naming attributes, I normally append 'Date', 'List' or 'Set' to the end of attributes of those types to indicate type (and thus behaviour) and use prefixes like 'Has', 'Is' or 'Not' for Booleans (e.g. $IsApproved).

However, looking at the above, the job data is tied to one person note. You might need to allow for the fact that in the study period a person might transition jobs or hold several concurrently, plus different people might hold the same titular post consecutively during the study. If so, you'd likely want to de-couple person and post. Thus you might want each post to be a note and use links to person notes. Or have each person have a note per job held. Having a single note per job has the same problem as above if there is more than one holder of the job in the period.

As you can see there's no one 'right' choice. How many attributes are sensible and how the data is split into notes is a balance of the data and the sort of information you want to pull from it.  

Tinderbox is very flexible in letting you alter structure if you find you've gone down a wrong path. Sure, it means some work but importantly it is possible without a complete do-over (as might be the case with a standard database). Ergo, avoid analysis paralysis by diving in. My experience is it's not until I try to use the data I've added to the errors or strengths of my structural choices shine through. Short of finding someone who has both a similar personal work style and has worked on a very similar project/dataset, I don't think you'll get more precise pointers.

To my knowledge, DT tags are not addressable as a discrete piece of data. You can call (open in DT) a DT record from TB. You can drag import at DT note with the DT tags mapping to Tinderbox $Tags (needs Tinderbox V6.4.0+ and DEVONThink v2.8.8+)