Populating/Updating a new UserAttribute variable with values from linkType?

Agents, Actions and Automation
1

My research is telling me that linkTypes are not exposed like many other attributes, however I thought I would ask.

Lets say I have 3 link types: untitled; note; note+ and now I add a fourth: RelatesTo
In addition, I have created a new User Attribute: xLinkType
What I want to do is to autoUpdate my set values in xLinkType with the values from the inherent linkTypes found in the Links tab. Is this possible?

I do not see a system attribute called linkType yet it seems to be an attribute for Links.

Currently, I am manually updating xLinkType with the linkType values but feel, somehow I can better automate this step.

I have created a very basic and simple file…with the above in place.

Thanks in advance for your thoughts.
Tom

xLinkTypeDemo.tbx (58.9 KB)

2

Late here, catching this as I turn in, but the above is easily answered. Attributes, in the Tinderbox sense, are an aspect of notes. But, links are not notes, some don’t have attributes. Links do have have properties; ‘attributes’ of the underlying XML if you prefer, but regardless—they aren’t Tinderbox-type attributes.

I don’t think there is an action code operator that lists all the link types in use, whatever the scope chosen, though such an affordance has been raised in a different forum, IIRC.

3

FWIW, there are speculative experiments underway in Tinderbox 9.1 to address this.

1 Like
4

Is this feature out, still under development, or just abandoned? Being able to read and modify links ‘attributes’ via action code would make sharing pre-set tbx files with others much easier, especially with new users or those without coding (action code) experience.

5

At present, as far as it has got at v9.2.0 is the document() dictionary object has a link-types key.

A related lower-level issue still being resolved is how the Dictionary type gets/sets multi-term values (i.e. lists), such as the the list of currently defined link types.

Also since v9.1.0 eachLink() allows action code access to all the current objects links. I thin one is essentially looking at each link and a sub-set of the underlying XML <link> data object. The value of the type key is that link’s link type. I’m not sure (i.e. not explicitly tested if any of the key values are read/write or read-only). Why not give it a try.

However, there is no action code to directly address link types, either as a doc-level per-link-type set of defaults or as customised at per link level. I can see that’s a lot of code for a niche use so it might help assess the ROI (cost/value) if you could unpack your use case a bit more.

Also, I’ve checked the current (v9.2.0) AppleScript app dictionary (i.e. allowed terms/usage) and link types are not exposed beyond the name of a link’s current link type.

To ‘just’ set up a doc for another user, it is still easier to make a new doc and customise it. Or another approach to the same end, take a customised doc, and strip out all the data (the ‘content’ as it were) leaving all the prototypes, stamps, templates, composites, custom link types, etc.

Note although user attributes have a ‘Description’ that is saved as part of the attribute’s data, link types don’t. I suspect is that is because most users employ link type names as screen labels of box-and-line type visualisation. As one moves to using links less for their visual element but as a means to compute across the graph of connected notes, it might be useful if link types also allowed for a description of the types purpose. Indeed, a link might not want or need a map-visible label, but we still might want to know what type ‘X’ is for and how it is different from type ‘X2’.

Of all this issues here, the one offering most traction towards the aim seems to be getting dictionary type objects to be able to get/set list values as well as single values, which also implies being able to address discrete values in a list value without laboriously (for the user’s code at least) literally iterating every value in case it is a list vale to then identify and work on the one intended. I believe this is work in progress at present. That’s good as fixing that action code aspect also fixes/enhances a lot of other action code use.

HTH :slight_smile:

6

Thank you for your detailed answer! Sorry for my late reply, but I was busy preparing tinderbox project to share with rest of community, that will explain better what I have in my mind! I will share it in the next couple of days, just need to write a README note first.

Arek

2 Likes
7

Maybe now when I shared Literature Review with Tinderbox document, it should be easier for me to explain what I had in my mind.

In that project, there are three prototypes (nodes) and three kinds of link types (relationships when we add direction) that are fundamental for the synthesis process and create the grammar of my discourse graph. But that’s a grammar that is useful to me, but for somebody else it should contain more/fewer nodes and different kind of relationships. To make it easier for others to switch between different grammar patterns, I would like to create a container note (‘Nodes’) with nodes inside it and let them set relationships between those nodes by simple linking between them. $Edict inside ‘Nodes’ would watch children notes and, based on created nodes and relationships, automatically add action code to individual link types. I hope it makes sense, and you can understand what I mean.
I have to agree that’s a pretty niche use, and I’m uncertain if it is worth from a ROI perspective - I’m not a software developer myself, nor I have much knowledge of other TBX user use cases.

The other thing I think would be useful, but maybe easier to implement, is to let the user be able to get information about link details from Browse Links pop-over.

1680×1024 115 KB

Sometimes short description (Link Type name) is not enough to describe why I linked one note with the other, that’s why I put some description in Browse Links pop-over. What’s problematic is to get back this information, especially when you have dozens or hundreds of notes linked to each other. What I propose is action code scheme like this:
linkDetail(sourceDesignator,destinationDesignator[,linkType])
With this action code, one could still use Browse Links pop-over to write down some detailed information about the link, and easily get this information back when exporting notes.

Arek

8

Although eachLink() may have a glitch at present (as at v9.2.1), I think it—when fully working— does what you ask, as you’d loop the desired note’s links and test for the desired link source/destination/type. If you know the latter, then I’d agree your suggested linkDetail() operator would be slightly quicker access to an individual link’s dictionary of metadata (as is exposed via eachLink()). In you suggested operator don’t overlook that for text links you might have >1 outbound link of the same type and destination so you might also need to specify which link be also supplying the link anchor value. It’s not safe to assume you’ll ‘never’ have 2 such same-type notes that have differing comments.

However, and with the proviso that this code may not work in v9.2.1. Let’s assume we’ve populated 3 variables with source/destination/type, e.g.:

var:number vSrc = 1234567890;
var:number vDest = 1234567891;
var:string vType = "Agrees";
var:string vCmnt;
eachLink(aLink){
  if(aLink["source']==vSrc & aLink["destination"]==vDest & aLink["type"]==vSrc){
    vCmnt = aLink["comment"];
};
// the link's comment string is now stored in vCmnt to use as you see fit

One other limitation I see is eachLink is bound to the current note. I don’t think you can use it to iterate info for a different note. It’s a shame eachLink() is not a dot operator as it could then chain to any note, e.g. via an offset reference:

// THIS *NOT* VALID CODE
$Name(vSrc).eachLink(aLink){
  ...etc.

Looking further ahead, I can see that you might have a ‘utility’ note with 3 user attributes as Displayed Attributes: $SourceID, $DestID, $TypeName. A rule or edict could then use those to take the place of vSrc, vDest and vType in the above example and the link comment could be written as the $Text of the note. Thus by altering the Displayed Attributes values, the note could function as an ad hoc viewer for link comments whilst being non-modal unlike Browse Links.

1 Like
9

OMG, how have I missed this one…

Many thanks for your detailed explanation! You’re right, I shouldn’t make this kind of assumptions. I will use eachLink() operator, as it seems to be the best option right now (or post-9.2.1) :wink:

That could work! Thanks again, you’re the best!

10

No error there, we all do this with innocent intent, no there’s no censure implied. Indeed, the issue of link anchor as a parameter only occurred to me as I was thinking through the implications of your suggested operator. :slight_smile: Even if it is only implemented as a wrapper for the sort of eachLink() example I gave above it could be useful.

I’d certainly agree that making link comments more accessible may enhance their use.