Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
http://www.eastgate.com/Tinderbox/forum//YaBB.cgi
Tinderbox Users >> Agent, Actions, Rules & Automation >> Using #linkedTo & #linkedFrom
http://www.eastgate.com/Tinderbox/forum//YaBB.cgi?num=1220548346

Message started by Rafter T. Sass on Sep 4th, 2008, 1:12pm

Title: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 4th, 2008, 1:12pm

I'm interested in using an agent to collect, or filter out, notes that are linked to, or from, any other note.

Is this doable? What would the syntax be?

Thanks!

Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 4th, 2008, 1:28pm

You might also consider the links(). It works as an action to create a set of (attribute) values - default being $Name - of each matching note.

The #linkedTo/#linkedFrom special queries have an optional second parameter, 'Type', allowing you to tighten the match to a single link type.

When testing/researching links for the above don't forget that you can turn each link type off individually via the LinkTypes palette (Cmd+2). Also, the Path view (Cmd+Shift+P) allows you to see all notes linked by a given link type (albeit both source & sink without polarity). Raodmap (Cmd+Opt+R) allows links to be navigated and all inbound outbound links are shown (withuot link types). Browse links shows all outbound links. Lots of slightly overlapping tools.

Not time to build tests now but the above should help give some start points.

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 4th, 2008, 1:48pm

Thanks! That's helpful.

If I want to exclude notes that are linked to, would the query be:
!#linkedTo(*)
or
#linkedTo(*) = ""

or something else?

I'm workin' on it.

Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 4th, 2008, 1:55pm

Re-read the notes on #linkedTo/#linkedFrom and you'll see the target is a single note. I assume you're not trying to link to a note called "*"? Usage:

#linkedTo("some note",agree)
#linkedFrom("another note")

A note's name can be substituted for by any item object.

#linkedTo("some note","custom type")

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 4th, 2008, 1:55pm

I'm getting sidetracked by very weird glitches.

Created a new TBX to test (before mucking with my GTD).

Created and linked some sample notes.

Created Agent#1: works great! Collects every note with a link running to it!

Subsequent Agents: do not work for anything - even if I cut-n-paste the exact query from Agent #1, they collect nothing

Duplicate Agent #1 - works great!

I'm stumped hard.



Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 4th, 2008, 1:58pm

If you delete agent #1 do the others work? What is the query for agent #1?

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 4th, 2008, 2:00pm

Maybe I should clarify my task.

I'm dealing with the hoary old problem of ordinality in GTD/TBX tasks.

It's of particular note when a project combines sequential and non-sequential tasks.

So, in order that my Context agents only pick up the relevant Next Action, I'm hoping that I can link sequential tasks, in order, and *add a filter layer* to the agent queries that ignores tasks that have uncompleted precedents.

Does that make sense?

So, unless I'm missing some important point here, I will want to use a wildcard in my #linked query...

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 4th, 2008, 2:57pm

Well, that weird agent behavior seems to have resolved itself.

Thanks much for your help, Mark!

I'm getting encouraging results from using the links() operator.

My little testing ground TBX has three User attributes:
Action (boolean)
OpenPrecedent(boolean)
MyPrecedent(set)

- the Rules for my Task prototype are looking like this:

OpenPrecedent=links.inbound.antecedent.Action;
if($OpenPrecedent) {Action=False};
MyPrecedent=links.inbound.antecedent.Name;

I'm still tinkering to figure out if I want to query from Action or OpenPrecedent, or both, or what, when I collect tasks.


Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 4th, 2008, 5:17pm

Re your previous, wildcard searches aren't possible in the way you used an asterisk search.  It's worth taking a read through the objects & concepts section of aTbRef so you understand what your options are when a query, code, etc., asks for a 'note' as an argument. It saves guessing, not least as due to under-the-hood coercion can produce false positives making you think your code works when it doesn't where Boolean tests are being made.

Most link type filters in codes/operators are a single link type. If necessary you may need to re-visit your link types & use  - perhaps consolidating - to allow you to locate sets links by a single link type.  I'm not saying that's ideal but rather it's an achievable solution for today.

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 4th, 2008, 5:51pm

No doubt. Thanks for the pointer - I'll check out that section.

The way I'm working at it now, there are no attempted wildcard searches.

The Tbref that Mark A. referred me to on the #linkedTo syntax does seem to indicate that w*ldcards are ok in queries using #linkedTo and From.



Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 4th, 2008, 6:24pm

I've corrected my earlier post as #linkedto/#linkedFrom are two exceptions to the general rule that TB does not use a '*' wildcard ( I should remember what I wrote!). Expressions & regexp allow the use of a wildcard via regexp syntax so with careful naming you might be able to use a regexp to match a sub-set of named link types.

IIRC Prototypes are found by these queries.  Not sure why your *-based scope of search wasn't working earlier.

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 5th, 2008, 12:23am

What are IIRC prototpes? What's an 8-based scope of search?

Thanks!

Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 5th, 2008, 3:09am

IIRC is an abbreviation for 'if I recall correctly'; sorry I was up late late and on a deadline so trying to be brief. '8' was a typo for '*' - I've corrected the original post.

I'm not 100% sure but certainly quick tests last night indicated 'Prototype'-labelled links are found when using #linkedTo/#linkedFrom. This may be an issue when querying link types as depending on what you're doing, queries including links from a prototype to notes using that prototype may not be appropriate.  If I recall not all functions treat prototype links the same but the fact isn't documented in any detail - this was the point I was making last night

Re asterisks, I was referring to the use of the asterisk (*) character as a placeholder for any character, i.e. as a wildcard. As already stated, the usage of an asterisk for any code's  required parameters is not generally expected so that is why their use in these particular queries is unusual. For more detail on that you'd need to ask Eastgate directly.

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 6th, 2008, 12:36am

OK, I've continued tinkering for a while now. I'm learning a lot!

And making progress...

But right now I can't figure out from the available reference material if I'm using terms correctly or not, or if it's something else that's stopping me. So it seems like a good time to post.

Here's the idea:
(1) Sequential Tasks are connected, in their required order of doing, by links of a type called "antecedent".
(I.e. each task has a link that points to the task that comes after it, if there is one.)
(2) Through rules, task-notes will know if there is an undone task "upstream" from them. I'm calling an undone upstream task an "open precedent."
(3) Tasks-notes automatically set their Action attribute to false when they have an open precedent, so they won't get swept up by Context agents. Thus, the GTD maxim to focus only on the very next action is achieved. Or at least supported...

Here is the chunk of rules that I'm using, with **annotations**.

Code:
PrecedentValues= links.inbound.antecedent.Action;
**This populates a set attribute with the Action status of any preceding tasks**
if(PrecedentValues(true)){OpenPrecedent=true};
**This is meant to translate the set to a Boolean attribute - it doesn't seem to work.**
PrePrecedentValues=links.inbound.antecedent.OpenPrecedent;
If(PrePrecedentValues(true)){OpenPrecedent=true};
**These two lines are meant to ensure that the existence of an OpenPrecedent in the task sequence cascades downstream.**
if((PrePrecedentValues!(true)&PrecedentValues!(true))){OpenPrecedent=false};
**This last line is meant to reset OpenPrecedent to false when upstream tasks are completed.**
MyPrecedents= links.inbound.antecedent.Name;
**And this rule, which works great, fills a set attribute with the names of the immediate upstream tasks.**


Here is a copy of the little tester TBX I've been tinkering on:
Sequence]Working.tbx (39.14 KB)

If anyone is able to help, I'll be eternally grateful.

I think this sequential task stuff is important for the TBX/GTD community, as well.

Thanks!



Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 6th, 2008, 8:07am

Thanks for the TBX, that helps. I like your use of DisplayExpression. OK:

I think I found one code error and I needed to add one thing:


Code:
PrecedentValues= links.inbound.antecedent.Action;
if(PrecedentValues(true)){OpenPrecedent=true};
PrePrecedentValues=links.inbound.antecedent.OpenPrecedent;
if(PrePrecedentValues(true)){OpenPrecedent=true};
if((PrePrecedentValues(true))|(PrecedentValues(true))){OpenPrecedent=true}else{OpenPrecedent=false};
if(OpenPrecedent=true){Action=false};
MyPrecedents= links.inbound.antecedent.Name;


The problem was the clause testing for 'true' precedents.  It had unequal balance of opening/closing () for the if part. Also the test was an and '&' when it should be an or '|' as a 'true' in either attribute should trigger and action here. To make thinks clearer I reversed the not (!) tests and explicitly set OpenPrecedent for both true/false branches. You could simply leave the true branch as empty {} if you want.

To try the fix, take your example TBX an in 'Task Prototype' and open the rename dialog. Replace the Rule code with the code above (removing the line breaks after each code line).

I've not attempted to change to improve the code or simplify it so as not to introduce ambiguity. I figured it better to get it working before trying improvements - if any (I've not looked at that aspect).

I'm not GTd-er but I think the now does what you want.

Title: Re: Using #linkedTo & #linkedFrom
Post by Rafter T. Sass on Sep 6th, 2008, 11:45am

Thanks so much - that is incredibly helpful.

It doesn't quite get me there, but it gets me closer. (I'm mildly embarrassed you had to correct a opening/closing ()'s mistake.))

Your response highlighted some unnecessary redundancy in my code, which I've streamlined now.

This tinkering brings up a question (which might be more suited to a new topic):

Is there anyway to (re)set the Rules in a number of notes at once?
*(re)Setting in the prototype seems not to work.
*Setting by agent action seems only able to insert about 15 characters.

Any ideas?


Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 6th, 2008, 5:24pm

Don't apologise, my knowledge is build upon the experience of such mistakes. FWIW, I tracked down the  error by pasting the rule into a text editor (a TB note will do!) and putting a line break after each opening bracket and before each ). Low tech, but it does quickly point up nesting errors if complex nesting.

I'd like to say thanks for your test file - it's a good example of how to offer up a good test rig - everything was there and as importantly, well visualised on opening. The only change I made was to add a depended task to 'Fill out Rebate' when I noticed its PrePrecedentValues had both 'true' and 'false' values.

Glad to see the fix has helped flag up simplification.  When you're done and if you feel like sharing, I'm sure Mark B would be very happy with an addition to the TB File Exchange page, GTD-ers seen a committed subset of TB users.

Title: Re: Using #linkedTo & #linkedFrom
Post by Mark Anderson on Sep 6th, 2008, 7:26pm

Re re-setting. Once *any* attribute - system or user - has been altered from the prototype's value inheritance is broken.  To reset the inherited value, set the attribute value to ; (semi-colon). See also this article.

To reset a Rule, set 'Rule=' or $Rule= as appropriate.

To set at rule only if it is empty, use |=. This won't work if a rule is not set but inherits a value as it does have a value - the inherited one.


Quote:
Setting by agent action seems only able to insert about 15 characters.

Please give a sample TBX or step-by-step instructions for v4.5.1 to reproduce.

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.