Inheriting attribute using Ziplinks

If I have a note full of text and I want to ziplink several phrases in that text so they are extracted as separate notes, what OnAdd, Rule, or Edict should I write so that the resulting ziplinked notes inherit certain attributes from the original note (full of text) they were created from?

I can ziplink these notes to a container that would call the action/rule/edict, indeed I would prefer to do that because the logic of where ziplinks land on a map once they are created is still a mystery to me.

Much thanks for any guidance!

Well, the newly-created zip link will have one inbound link — the link to the source from which it was created. So, the source of that link would give you the path to the originating note, and you could copy (not inherit!) whatever attributes you like.

CAVEAT: the natural way to do this would be the container’s OnAdd action. That might work. I don’t remember, though, whether the OnAdd action runs before or after the zip link is made! So, try that, but it might not work. I’m going to assume that the OnAdd runs before the link is made, so we’ll need some fancy footwork.

Now: I assume we want to perform this action once, after the note and its link are created, to set some initial values. If you want to constrain the values permanently, use an rule or and edict. Otherwise, we need to leave ourselves a note to say, “I need to perform an action, but I can’t perform it yet!”

To do that, we define a boolean user attribute $NeedsUpdate. The OnAdd action becomes:

$NeedsUpdate=true; $Rule=$Rule(/config/DelayedZiplinkUpdate)

In other words, I set $NeedsUpdate, and I copy a rule from an exemplary note I’ve made at some known place. That note’s rule, in turn, figures out the source of the zip link, does the work, and sets $NeedsUpdate to false.

This could be made easier if we added an attribute the held the path to the note from which this note was created. But what would we call the attribute? $CreatedBy? $CreatedFrom? $PathToCreator? $ZiplinkSource?

$Zapped? :slight_smile:

$ZiplinkSource is most intuitive to me.

So if the attribute is $PID, would the OnAdd (if it works) syntax look like $PID = $PID(source)?

@mwra You’re the expert!

I think

$MyList=links.inbound.“*”.Path;

will give you a list of the sources of inbound links.

$MyString=$MyList.at(0);

gives you the first source, which in this case is the only one.

$PID=$PID($MyString)

does the assignment you want.

Something I’ve always wondered in times like this where I need to do a bit of sandboxing… is there some sort of best practice for doing this? I see there are a series of $My___ attributes, but what does your screen look like when you’re toying with them? What windows/inspectors/browsers/tabs are showing?

Thanks,
Beck

I do all of this in the Action Inspector

This is definitely something to sandbox, not least as it has the smell of a workflow kludge where the workaround is prone to confusion from un-considered edge cases.

One of the first things I do in this situation, is to ask in what places I’m assuming a single match to queries and whether that is a reliable assumption for the long term. Optimism is not sufficient. So, a first task may be to add extra scope identifiers.

So we’re all on the same page, ziplinks are not a form of link: all ziplinks are just text links. Their difference lies on the keyboard-centric method of their creation, so the fingers don’t have to leave the keyboard.

The sensible thing to me is to set a specific link type on the created link so it helps narrow the number of links we need to consider to get our result. The link type can be changed later. Unfortunately, the ziplink method can’t set a link type until the next release (after 8.7.1).

I’ve a submission deadline this evening and have long writing jag ahead but I’ll return to this tomorrow if I may.

Hi all, following back on this now that I’ve created a final workflow. I’m wondering if I articulate them, a clearer (to me at least) solution might emerge for automating at least one part. Here’s my workflow in image, I’ll describe it in narrative as well, below.

  1. I have a “Data” container. In that container are 400-some data items that have a $DID (data item ID) from 1 to 5 and $PID (participant ID) from 1-86. I execute a keyboard maestro shortcut that creates a ziplink and puts that data extract into a container called “Coded.”
  2. When I’m done coding all the data items for a single participant, I go to “Coded” and have to manually assign the DID and PID for all the data extracts in that container. After this, I stamp the notes so they move to a container “Codes.” (Copying and pasting removes the link for some reason.)
  3. Once the notes are in “Codes,” I drag them to all manner of smart adornments (multiple tags and flags per note).
  4. Last, I stamp them to move to the container “Done” (again because copy/paste removes the link back to the original data item).

I would like to know if there is a way to automate the assigning/copying of PID and DID so that I can eliminate step 2 entirely. It would save me ~8 hours of work to do so.

I would also like to know if the stripping of links when an item is copied and pasted is a bug.

And last, if there are better ways you see to achieve the following workflow or ideas you have about it, please let me know!

Thanks!

I’m a bit lost at step #1. You have a note that gets linked to what? The use of the ‘ziplink’ link creation method. Perhaps if you broke the task out into sub-tasks it might help. If you are using zip links that does tell use the note has $Text (as the ziplinks method only creates text links). So what links to what, using what criteria and which note (source or target) is moved?

What is this data and what logic do you use to (manually) choose the right ones?

Assuming the process is the source note (with the DID/PID) creates a sibling that is then moved. I’d get the new (moved) note to find the note linked from it in the ‘Data’ container (possibly filtered by link type used?). Then the note sets its $DID and $PID to the values of the note at the source of the link.

It’s not a bug. Copy copies the selected note(s), and any links among the selected notes. Duplicate might be closer to what you need.

Here’s one approach.

  1. Make a note /config
  2. When you begin work on Data Item 137, copy its $DID and $PID to /config. You could do that with a stamp.
  3. Let the OnAdd action for Coded extract assign the $DID and $PID: $DID=$DID(/config)
1 Like

Hi Mark,

I’ve made a video showing what happens when I copy/paste a note. Is this the expected behavior?

It is the intended behavior.

Copy* copies the selected note(s), and any links among the selected notes. Duplicate duplicates the note and its links.

I’ve played around with this a bit and I am going to ask the question differently.

Take Note 1 and Note 2:

Copying (or duplicating) Note 1 copies the link to Note 2.

Copying (or duplicating) Note 2, does not copy the link from Note 1.

I would expect copy and paste to go both ways, but perhaps it’s not intended to.

Does this explanation help?

1 Like

The inbound links not being replicated by either duplicate or copy paste, I think by design. The issue is that there are two valid but conflicting behaviours here.

As to the video, try applying this stamp to your newly zip-created notes:

$MyString=links.inbound..$Path;
$DID = $DID($MyString);
$PID=$PID($MyString);
$MyString=;

Could be an edict not a stamp. Late so no worked demo but hopefully this shows the way. :slight_smile:

1 Like

That worked!

WHAT IS IT DOING? (I’ll hunt and peck to find the answer on my own, of course, so no need to actually answer.)

Great! Basic links() syntax has 4 parts:

$MyString=links.inbound..$Path;
  1. Locus/scope. As used here we are testing ‘this’, the current context, but with an offset we could specify an other note , e.g. links("some note") or a group, e.g. links(children)
  2. Direction of links to test: inbound or outbound - must be one or the other. To test both directions use two separate actions and merge the result.
  3. Optional filter by link type(s), otherwise leave blank .. as above.
  4. Attribute value to to return from notes at the other end of matched notes. Use attribute’s name with a $-prefix.

You can think of the actions as a link-filtered collect.

More at links[(item|group)].kind.[linkType].attribute.

2 Likes