Tinderbox Forum

Agents as user attribute values

Can I create a user attribute whose value is an agent?

I’m designing a Tinderbox as backup for Andy van Dam’s upcoming Hypertext 30 Keynote on Sept. 17. The foundational structure is related to what I created in the Memex and Beyond website (http://cs.brown.edu/memex/), only this is a 2D space and will cover all the ACM Hypertext conferences since 1987 plus a few other things such as references to Doug Engelbart’s papers, including his 1962 SRI report “Augmenting Human Intellect: A Conceptual Framework”. In my HT '01 demo of ConceptLab I tried to create a searchable, reconfigurable 2D framework for the structure, but it was pretty ugly and not really extensible. The categories are People, Projects, Institutions, Publications, Conferences, Concepts/Keywords, and these categories are all interlinked as you can see in the Memex and Beyond website. There will be hundreds of documents referenced and the Tinderbox will dynamically grow over time. To build this network, with links to PDFs of the specific documents, I need to automatically populate the appropriate category individuals for each document registered in the Tinderbox. After the Tinderbox is populated with this network of information, I then want to use agents to gather all related information in a 2D manner for a specific person or institution or project or concept or conference or publication.

The reason why I wanted to use an agent as an attribute value is that this Tinderbox will be rapidly growing and Attributes such as Publications for a person such as Catherine Marshall will have many values, the number of which grows over time. Plus, these values are actually “links” to another part of the Tinderbox.

In general, this is an academic research resource base that I’m creating in response to this very important Keynote.

1 Like

@SkylarkMichelle - I have a TBX mapping all papers in the ACM Hypertext '97-'18 including ECHT '92 and '94 and am currently adding info for ECHT '90 (I know it’s not formally adopted as part of the ACM conference but is is HT and covers papers on Microcosm so seems pertinent.

Here’s just something I output from it: https://www.shoantel.com/proj/acm-ht/2018/index.html

This all grew from playing around with Les Carr’s 2004 Tinderbox experiments (on the old wiki).

Notes for papers have a fair amount of metadata:


I’ve also extracted all authors and normalised for spelling, accents, alternat forename, change of surname etc. All authors link to their papers.

Happy to send you a copy if you want. It’s a lot of my effort but the data is ultimately all derived from dl.acm - though their records have goodly amount of typos that i’ve corrected along the way.

Last point. don’t try and do a project at this size in a single map - it’s simply too much data, even though map performance has improved significantly in recent versions. The doc pre-dates hyperbolic view so I’ve not tried that but it too may chug a bit with a doc with this many notes and links.

Note: if wondering why I’m just not posting a copy, I’m still working on the doc and I’m also uncertain about the copyright issue re the dl.acm source. Normally, anyone you can find to ask about such things gives a default ‘no’ - albeit because they don’t understand or simply don’t care.]


Note for later readers: the control concepts described here really are only pertinent at scale - with thousands of notes. For more normal documents with a few hundred notes or fewer, such precautions are overkill.

Further to my last, re agents. My experience is making an agent for every [thing] doesn’t scale up nicely. You end up with a lot of agents and have to tweak their $AgentPriority or turn updates off.

More flexible I’ve found are edicts, although they too need use with care. The find() action essentially allows a note to run a query like an agent, without needing and agent:

 ... action code stuff;

Now rather than a thousand notes each needing an agent, the note can use a find to populate attributes and make/break links. In the case of links, you are now working from the context of the original, rather than an alias, it is easier to ensure links are between originals at both ends (though recent action code changes have made the task easier in agents, too).

An edict runs once only the following events (and assuming $EdictDisabled is not set true locally):

  • On first creation
  • On editing the edict code;
  • At document start.
  • Approximately once per hour during the current document session.
  • If File -> Update Agents Now is run (i.e. a one-off manual agent update also updates all edicts once as well and works even if there are no agents in the document).

So a quite flexible system, where you can run the edicts you need, when you need and not clog your editing with lots of unneeded always-on behaviours.

At scale, prototype are your friend. I use them a lot. They are also a good way to maintain rules and edicts across lots of notes. Be aware that $EdictDisabled (and $RuleDisabled) are intrinsic so are not inherited. To make an edict switchable via the prototype, use this sort of edict wrapper (amend the code and you can do the same with rules):

... edict code;

The $IsPrototype test is there because in this sort of scenario you generally don’t want the edict to run in the prototype. $EdictDisabled normally does this, but we’re now using it as a proxy switch for all notes using the prototype, so we simply ensure that the note executing the edict isn’t itself a prototype.

If this doesn’t make sense do ask