Attributes or links - or both?
I would like to get some opinions/advice on this - when to use attributes, and when to use links.
I build a Tinderbox document to trace the recent history of Scandinavian traditional (and not quite traditional) music, from the 70ties up to today. Art the moment, I try to get an overview of Musicians, Bands they have participated in, Albums they have released. There are many-to-many relations between all those entities. I want to trace many connections: All the bands a certain musicians has taken part in; all albums (that may span different bands) s/he has contributed to; all albums for each band etc. I have started with prototypes for Musician, Album and Band, and wonder if I should use links or attributes to document the connections. There is also the obvious, (but I believe not practical), option to use levels, with all albums from a certain Band on the level below each Band.
At the moment, the only attributes for each entity are start and end dates, to be able to get a timeline overview. All inputs are welcome!
Firstly, there is no general right/wrong choice. I suspect that, certainly in large/long-lived documents that people use a blend of both. Partly this reflects personal style and partly the differing nature of the subject on which people are working.
We come to links quickly in maps and from there link types as visual labels for those links. Of course, once notes are in different containers (i.e. different maps) we only see those links as link stubs. But, they still link notes and can be queried: the linksâ link types, rather than merely being line-labels on a map, can indicate the purpose of a link. A link can only have one link type but two notes can be linked by multiple discrete links, each of a differentâ link type. Once you have differently-typed links there are plenty of Link type honouring operators with which you can investigate your document.
User attributes are easily made when needed⥠and are best used when it is useful to know if notes have a certain property. Everything-bucket lists of tags are an easy start, but the more experienced user learns to store separate strands of info in discrete attributes. Whether for display internally (âpreviewââ mode) or for export, data in attributes makes it much easier to get the right information in the right place when needed.
Indeed, you might blend both. So, if band D became band B and inspired band C, we might link D â B with a ârenamedâ type link and D â C with an 'inspired type link. Letâs also assume B later got renamed A. That makes for a nice display if all on one map. But when exporting, you might D to know all its ancestors, so a $PreviousNames attribute for A might hold a list§ of its previous names (i.e. B and A). You could get that by using an agent (or action code) to query typed links, but it might be helpful to store the âresultâ of such a query in an attribute.
If starting out, there is one approach that is rarely a good choice, that of trying to plan every detail at outset when you only know a few of the features. Far better, take a subset of your subject matterâespecially some of those with odd aspectsâand experiment. At this stage the point is not to progress generating stored data but to understand how best to save it in a way that aids later use and understanding.
Also experiment with importing data (i.e. different methods) if you are going to be doing that: what/where are the inconsistencies, whatâs best triaged before Tinderbox vs once in Tinderbox.
Donât guess - try out your ideas in tests. Even once youâve got a main document figured out and are now adding data, if you have a new process or code solution in mind, test that in a small, separate, TBX and only add the code once you are confident it works as expected.
Doing tests like above can seem like extra work. However, as your project progresses, youâll find it is actually a time-saver as you are less likely to make messes in your main document which, whilst fixable, still take time to resolve. As your familiarity with Tinderbox grows youâll gain a feel for what needs testing first vs just implementing straight into your main document.
â . Tinderbox will happily let you make multiple links between the same notes using the same link type (or using no type at all) but there is little point in doing so.
âĄ. Donât forget to fill out the Description box (and press Return to save the added text) when making an attribute. Whilst the name, if chosen with care can indicate the purpose and/or data type, it is still easy to forget over time why we chose to make a particular attribute. Thus, annotate not only what it does but its purpose.
§. Here is a good example of where attribute data type can matter. A Set-type allows no duplicates (so fixing user input error). But Set-type also auto sorts on A-Z order. List type allows duplicates and doesnât sort. So, if it makes sense for $PreviousNames to hold value(s) in a particular order. As D became B became A, if you want to save the names in order âB;Aâ, use a List, if you donât mind the data listing as âA;Bâ is a List. But, donât worry about getting this right first time. Tinderbox is very forgiving about re-working data if you find a better solution later on.
I had similar questions when I started a project related to a large body of films a few years ago and I agree with @mwraâs final point wholeheartedly:
One additional idea: redundancy isnât a problem and so thereâs no reason early on to choose between links or attributes. In my case I used link actions to populate attributes by making links. These actions can seem fiddly early on because you need to specify the source and destination attributes (so test actions!), but once you wrap your head around them, they make it easy to capture info as a link AND as an attribute simultaneously. Which gives you the space to work without making choices until later when you know better what you are doing.
I donât have examples of my early actions anymore (I deleted and revised them as I went) but I remember starting with simple action that would add a directorâs name to one of their films when I linked from the directorâs note to the film note:
$Director(destination)=$Director(source);
Pretty quickly I built this into a longer, chained conditional actions that would let me link from any filmmakerâs note to any film note and to add the relevant info to the film note. I did this by testing the filmmakerâs noteâs prototype to determine which attributes to assign:
if($Prototype(source)="p_cinematographer"){$Cinematographer(destination)=$Cinematographer(source)}else{$Director...
When these chains became too long and complicated, I started dividing simpler actions across different link types of the sort @mwra suggests: types like âdirected,â âphotographed,â etc. (And let me have some types like â*untitledâ that didnât have actions associated with themâŚsomething I hadnât realized I needed early on.) This evolution from the simple actions to the conditional actions to actions associated with link types happened over the course of weeks and weeks as I figured out what I needed.
Eventually, I settled into a combination of links, attributes and outline hierarchy that worked for me. But what I settled into wasnât what I would have predicted initially. So not making choices between links and attributes early on was good for me: once I knew what I needed, I didnât have to go back and rebuild. There was also no downside: the info I added to attributes that I donât need isnât in the way (or even visible) and the link types I didnât need and were in the way were easy to make invisible in the inspector (or to delete if they werenât typed).
Hi @Tellefk - embarking upon this cool project, you will likely discover that you must make a few attempts to scale the mountain. Youâll certainly discover new connections and possibilities within your data set through Tinderboxâs generous visualization/connection/organization solutions.
Your initial ambition might morph to new heights, fuelled by glimpses into the appâs capabilities. Even if it feels like meandering, stick with it! The most rewarding way to build your toolkit in Tinderbox is via experimentation - and scrolling through or posting on this forum 
Of course, it may take a few false starts to get your data entered, linked, and $Attributed optimally in order to tease what you want out of it. Fortunately, Tinderbox is powerfully malleable. I for one enjoy leveraging this flexibility to re-hoist my Tbx data, itâs an essential aspect of my process. It also comes by virtue of my evolving Tbx chops, and strides in the softwareâs development!
For example on your project, I can visualize the dataset coming to life in the new Gaudi View
I would preface by breaking the project down into discrete steps if possible, by way of a rough roadmap with an achievable objective. Of course you will change course, but it helps en route if overwhelmed by feature-shock. Also, you will no doubt pick up valuable workflows along the (Tinderbox) way.
Shout out to great breadcrumbing/safe practices (and any, really!) advice offered above by @mwra - that suggestion above has saved weeks of my life!
Good luck 
Thanks for the detailed answers and valuable suggestions! Iâll cdrtainly do some more experimenting before I try to add as much relevant data as I think I need. And I find that I need to actually (re)listen to some of the ralbums just to get some new ideas of what kind of project I like to do.
One (personal) obstacle I discover is that I have perhaps too much experience with relational databases, so redundancy of data is something I instinctively try to avoid. Obviously that is not a good idea at this stage in the design.
I find Tinderbox a good tool to develope my understanding of what I actually want to get from the data. Starting out with just a list of Artists, Bands and Albums, I now have added record Labels to the list of prototypes, and I also will have to consider adding info on single tracks/tunes, (with no ambition of competeness) - to track how some tunes become sign of coolness, and how artists tends to tell us that their source is an old performer or and even older archive recording, when they in reality got from an album release last year. Two attributes may be called forâŚ
Again, thanks for the input! Iâll make a list of relevant albums on a later occasion if any of you would like to hear some of my data!
Great! Depending on your timezone, I encourage attending the Meetups, theyâre a great place to learn how other people are doing things, and to lob your sample files to for feedback and ideation
The next oneâs this Sunday.
Thereâs a lifetime of good advice in the thread, above. Iâll add one more suggestion. Experiment with the variety of views that Tinderbox offers. A couple of view were mentioned already. Todayâs Tinderbox offers 10 views. They are all useful tools in their own respect. Hyperbolic view, for example, offers interesting insights into linkage among notes, while Attribute Browser and Cross Tabs are indispensable for exploring attributes and their values. Timeline has been mentioned, of course, and the Chart, and in some cases the Treemap, are useful for exploring relationships among notes. I think we all sometimes get stuck in Outlines and Maps, and forget to explore the other view and their benefits.
Honestly, I use both attributes and links, with value in attributes being the fallback. Moreover, I have Tindebox create the links based on the value in attributes. Why? 1) It helps with creating atomic notes and writing, 2) I can easily copy and paste notes across Tinderbox files without fear of losing data (as long as the attributes are in both files), and based on my action code, the links will automatically re-create themselves. There are several videos and examples of this workflow in our meetup video library.
Much good advice! At the moment I go for both links and attributes, and data consistency is kept with the link action feature. However, they work just is one direction, - or is there a trick to make them work both ways? If not, I believe it would be possible to use an edict: Now, I make a link from artist to album, so that an album eventually will have a full list of artists that take part. But then I want a set attribute for each artist with the album(s) the artist contributes to. Could I use an edict to (periodically) search through all albums, and pick up those where the artist contributes, and then add that album to the albums set attribute for the artist?
Link actions can access both the source and the destination of the link.
Could I use an edict to (periodically) search through all albums, and pick up those where the artist contributes, and then add that album to the albums set attribute for the artist?
You could! But this sounds like a classic task for an agent.