List vs. Set Attributes

Q & A - getting started with Tinderbox
1

Can somone please provide a practical example where list attributes would be used against set attributes and vice versa? I’ve looked at all the dog, pear, peach, zebra…examples and doesn’t really ring.

Here’s how I see a use of list & set attributes: ( I need a little nudge to see how I can use them in this context)

LEt’s say I want to arrange all my software applications by name so I create a List attribute for all the applications by name (that being the raw “deposit in my database”; then I would use set attributes to categorize all the applications by, e.g.: platform, operating system, manufacturer, type ,device, etc. Am I on the right track here? I can’t discern how these two attributes are used and what the benefit would be of one over the other…

2

Nope. Both are a list, i.e multi-value attributes than can hold zero, one, or more values. By comparison, changing a String value changes the only value stored by that attribute.

A List-type stores all the values applied, in the order applied. A List can have duplicate values , and in some cases that’s a valid and useful thing.

A Set-type is also a list but de-dupes values, so if you add the same value again unlike a List-type that value is stored once, i.e the list is de-duped. Also, a Set may alter it’s stored value order - but generally doesn’t. A practical example is $KeyAttributes - a Set. It’s most unlikely you’d want the same attribute as a KA more than once, so a Set is a boon. But if you need to make a list of the order of people posting if a thread in a forum (where some post more than once), de-duping would make that impossible.

OK, that sounds confusing, but way back (circa .v4.5) in Tinderbox’s life the only list-type attribute was a Set. Now that both Set and List have dot-operators like .unique (de-dupes list) and .sort the difference between the two has lessened.

aTbRef is probably your best reference for a) system attribute data-types and b) the data-type returned by action code functions. Note that over time some action functions that used to return Sets, may now return Lists.

3

A set either contains a value, or it doesn’t. Sets can’t have more than one copy of a value. Checking whether a set already has a value is very fast. The order in which items appear in a set is arbitrary and subject to change — that’s how Tinderbox makes find things faster.

A list is more general. Lists can be ordered however you like. Lists might the same item several times. If you arrange a list one way, it will stay that we until you change it.

4

Context, context, context…the reason I’ve asked for a practical example. I don’t have a technical background, I know nothing about programming and I can’t create context based on your information-based description. I posted this question in the getting-started forum section and I’ve received a reference guide type technical answer. I need a learning/goal oriented description that’s less focused on theoretical knwoledge and more on practical steps so I can actually comprehend how this feature can be applied in all types of situations.

I believe I understand how set data-type attributes are used however, list data-types are beyond me. I seem to find no practical example in any of the resources I have (manual, getting strarted, Tbx way, tutorials…)

Pic 1 shows how a note can live in multiple themes or how author set-type attributes can be used for showing multiple references by the same author as in Pic 2.

pic%201

pic%202

How can I apply these list type attributes ? Thank you

5

Let’s say a restaurant manager has three servers

Mary, Ed, Kim

that’s a set, obviously. Now, perhaps the manager wants to keep track of which of the three is going to be crew lead over the next 10 days, in order:

Mary, Ed, Mary, Kim, Kim, Ed, Mary, Ed, Kim, Kim

that’s a list.

So if the manager was using Tinderbox for her notes, she might create a set attribute, $Servers like this

$Servers = "Mary; Ed; Kim";

and a list of the on-lead servers ($LeadServer) like this – organized in sequence of who’s on lead:

$LeadServer = "Mary; Ed; Mary; Kim; Kim; Ed; Mary; Ed; Kim; Kim";

In the $Servers set attribute, each of Mary, Ed, and Kim can appear only once. Tinderbox makes sure that’s the case. In the $LeadServer list attribute, Mary, Ed, or Kim can appear as often as needed – depending on whatever the manager thinks the list should look like.

3 Likes
6

I commend the above answer.

Don’t worry unduly about getting the ‘right’ type. With user created attributes, Tinderbox will let you change the attribute Type, e.g. from Set to List or vice-versa. I say this to help breakdown the natural inclination to want to be right first time. Happily, unlike many apps, Tinderbox is quite forgiving in this regard.

Having decided you need an attribute allowing multiple values, i.e. a List or Set, you simply need to decide if any given list value can appear many times (a List) or is de-duped so each discrete value is stored once (a Set). A good worked example is above.

Now, following the above example, the general manager of several restaurants my have notes for different venues. So for the note on the Krusty Krab, the info might be set as

$Servers = "Mary;Ed;Kim";
$LeadServer = "Mary;Ed;Mary;Kim;Kim;Ed;Mary;Ed;Kim;Kim";

But in the note for the Chum Bucket, the same attributes might set:

$Servers = "Fred;Esther;Luis;Mina";
$LeadServer = "Mina;Esther;Mina;Fred;Fred;Esther;Mina;Esther;Luis;Fred";

In each case, the same attribute, in different notes, has a completely different set of values. Assuming only those 2 notes uses these attributes. If we ask for values("Servers") we get a list of 9 values:

"Mary;Ed;Kim;Fred;Esther;Luis;Mina"

We can sort that list if we want but the key point is we know that we have a total of 9 servers working for us across all outlets. values("LeadServer") also returns 9 items as the operation de-dupes the output. However, if we get a count of a note’s lead server per shift (LeadServers.count) we get the figure 10 telling us there are 10 shifts.

So practically, the difference in use reflects what you want to do with the data, and which is why your opening question is less simple than you might suppose.

Also be mindful of the fact that many simple/free apps limit user metadata (data about your data) to a single tagging (keywording) feature - a single bucket into which numerous strands of data must be poured. By contrast, the TBX I am working on uses 34 user attributes all holding important discrete strands of analytical data for my research.

If still unsure, try adding a Set and a List to your document and add the same data to each; as separate attributes there’s no bleed-over of data. However it will allow you to experiment with the differences described above and illustrate how Lists and Sets best fit your work.

HTH :grinning:

1 Like
7

Brilliant! Your example provided background and context…Concept understood.

Ty Paul.

8

“ a difference in use” might be the following numbers : {3,4,4,3,7}; I could add these up and get a total or I could divide the numbers and get an average value. This would reflect your “what you want to do with the data” scenarios?! Will definitely need more experimentation but at least now I have some context. Ty Mark

9

Absolutely - in this context a sum of only the unique values would not help!

Reflecting on my own experience, I’d say I use Sets more than Lists but:

  • Thats reflect deliberate choices based on the project at hand - i.e. it my simply reflect my work as opposed to use in general. (Indeed, this is why there often is no ‘correct’ answer to ‘which?’).
  • The .unique functions will always give you the unique values in any List-type list data.
  • The .sort, .nsort and .isort functions will (re-)sort any Set or List type list data to your criteria if the default list order is not to taste.

All this reminds me that whilst Sets were around in 2003 when I first dabbled with Tinderbox, Lists didn’t arrive until v5 in late 2009. It’s confusing that one of the two list (i.e. multi-value) attribute types is called List and that it wasn’t the original such type. But that was almost a decade ago. In the light of that perhaps need to revisit how aTbRef approaches the List-vs-Set divide and forget the latter came first. A Set is effectively a normal list (List) with 2 special characteristics: firstly it automatically de-dupes added values and (b) more obscurely you can’t always rely on the sort order of values read directly from a set attribute. In other words, though historically a set came first, it is really a ‘modified Lis’ and perhaps we should new describe it from that perspective.

HTH.

1 Like
10

Lists And Sets In Use: a different approach

A good way to think about the difference between lists and sets is to consider what you want to happen when you add a member.

$MySet = $MySet + “frog”

will add a frog to $MySet. If $MySet already has a frog, it is unchanged; if it doesn’t have a frog, it now has all the members it had before and it also has a frog.

$MyList = $MyList + “frog”

will add a frog at the end of $MyList. If $MyList already has a frog, it now has another frog. The newly-added frog will be at the end of the list.

If we have a club of animals, then its membership roll is a set: the frog is either a member or not. We don’t really care about the order in which animals joined; typically, we just need to know if a particular animal is a member or not.

If the animal club has a plaque of former club presidents, that’s a list. Perhaps the frog was the first president, and did such a good job that she was reelected. Then the elephant won the job and did such a terrible job that everyone asked the frog to come back.

$Presidents: frog; frog; elephant; frog; sea otter

We do care about the order of club presidents. We might sometimes ask, “has the kitten ever been president?” but that’s not a a very common question. We’re more likely to ask things like “who was the first president?” and “who is the current president?”

2 Likes
11

So if I had initially set up a user attribute as a list, but I really wanted it to be a set, is there a way to change this (automatically)?

12

For User(-created) attributes, yes. Open the User attribute Inspector and select the attribute you wish to change from the pop-up list of user attributes defined in the document. Now change the Type pop-up to the desired listing type (Set or List). System attribute types may not be changed.
[Edit: see my follow-up on this, two posts down]

Note that in testing, I was able to change a List to a Set and vice versa. On possible gotcha, although a List can be made into a Set, notes with _existing _ values with duplicate values (that a List allows: e.g. “dog;cat:dog”) are not de-duped, unless the existing value happens to be re-edited. I’m not sure if that is by design, but it’s something of which to beware. If it is an issue, just ask, I’ve a solution for that but don’t want to over-burden this answer i the extra info is not needed.

Tip: if you are a user who tends to include the data type in the name, e.g. $MyAwesomeList, I strongly suggest you also rename the attribute (using the same Inspector - above). So, if $MyAwesomeList changes from a List to Set type, then I’d rename i $MyAwesomeSet. This does mean you will need to change the name used in any queries/agent actions/rules/edicts/onAdds/stamps, etc. Additional tip - using prototypes makes finding fixing things much easier/quicker as you only need to edit the prototype and not every note using the affected code.

1 Like
13

Just to reinforce @mwra 's useful-as-always advice:

  • It’s extremely easy to change the Set/List typology of attributes you create yourself (“User Attributes”). You just go to the inspector and switch – I’ve done it many times. You can’t change the built-in attributes, but you wouldn’t expect to. And if there is a built-in attribute that is of a different type from what you’d want, you can just create a new User attribute that has all the properties you want. You’d just have to give it a slightly different name than the built-in one.
  • As Mark A says, there are some edge cases involving de-duplicating values. But you can handle those manually if they arise.
  • Agree entirely with Mark’s emphasis on relying on prototypes, so that you can make fine-tuning and tweaks in the prototype itself, and have them ripple through the countless other notes based on the prototype.

Good luck!

2 Likes
14

It transpires that a simple close/re-open of the document purges ‘old’ dupred values if any. From @eastgate

When the file is saved, closed, and then reopened, any duplicates will have been removed from the set attribute that formerly was a list attributed.

1 Like