Formatting Export Layout

Making progress… many thanks for the prompt help.

The next thing is to contain the map. The core to each “map” is a Model, from each model, many pink sheets; for each pink sheet, many studies and stories. So I’m thinking that a Note called Model 1 could contain the map for the model and that I can paste the actual model (as an image) into the root map and arrange these manually.

Does the “Dance” command work with a map view inside a container?

I need to get this set up more or less correctly because I will have in excess of 1500 pink sheets, perhaps 2-3 times that of studies and stories and a good hundred models. Currently the map has one model, 14 pink sheets and associated studies and stories and it is getting a bit congested - I’m working on a 13" inch screen…

Does that all make sense?

Thanks again.

I’ve tried really large maps (000s of notes plus links) and you do need to consider performance; I’ve never tried to ‘dance’ a really big map but I suspect it might load Tinderbox quite heavily. There are no hard limits

Putting different model(s) in different containers might lessen that loading of the map. Notes can link between containers/maps - you just can’t see the line drawn from source to destination a you can in one map. The new hyperbolic view aims to work around that, though in that view you don’t get to arrange the layout (which is dynamic).

Pat, Paul,

Sorry about the delay, different time zones, too much going on…

I hope I’ve copy/pasted enough to give you a flavour.

Many thanks.

Output table example.xls.zip (9.7 KB)
Pink Sheet example.tbx (121.3 KB)

1 Like

Thank you for posting these files @Stephen.

Had a thought. It’s not crucial that all Stories or Studies are exported to the same cell in the spreadsheet. They can have a row each as long as the PSID and other material is duplicated. Updated example output attached.
Output table example.xls 2.zip (9.9 KB)

Interesting. some observations from export-challenge-in-process:

Don’t make big maps at root. Always (IMO!) start inside a container. That way:

  • doc-level containers like /Prototypes, /Templates, etc. don’t get in the way of the ‘real’ map content
  • there is no problem having multiple map containers at root level (e.g. /map1, map2, etc., with the exact container naming of your choice).
  • having a deliberate map container makes it easy to scope queries to a single maps’ contents
  • if your prototypes use calculated Display Expressions use the Text Inspector/Title to disable the DE in that context. Using queries/action/export code you’ll likely reference prototypes a lot, so its easier if the prototype render at source (in the /Prototypes container) with their $Name rather than $DisplayName.
  • use link types for all your structural links as it makes them easier to filter in the abstract environment of action code. The human eye may easily see in the map that only one ground green note links to each square red note. Action code has to query/compare those facets (i.e. attribute values reflecting visual style).

Here’s work in progress

(forgot to label above that agent sorts on $PSID, as not necessarily the default agent sort, well just because…)

I suspect, that as we’re dealing with links to the originals of the queries alias and then doing further link based queries, it will be easier to use an Edict to make pink notes store the relevant data from linked notes rather than compute on the fly at export.

Anyway, making progress.

2 Likes

Merging now. I concur on storing the linkage info. If this doc grows you don’t want to be polling all notes all the time just to find which one [sic] represents a predictable 1-to-1 relationship. Even if 1-to-N, I think that is something worth testing/storing via edict so it can be further worked on quickly in action/export code.

However, I will move rules to edicts. Why? We don’t need to run these 24/7 and edicts can be run (once) on demand by using the file menu’s ‘Update Agents Now’ option.

If the later seems odd - i.e. if we know we’ll do this sort of thing, why doesn’t the app ‘just’ do this task better. That falls into the regular lazy assumptions that Tinderbox only does one type of task and all users do only one type of task. If this were a ‘Pink Guide’ app, the network logic would be baked in. But in an open-ended toolbox designed for emergent formalisation like Tinderbox, the latter would be premature optimisation (plus expensive to fully engineer for a few users). I think the latter point is a useful counter-point to the process at hand. Tinderbox can often explore all sorts of process, but deliberate optimisation for them is a whole different question. For instance were I a coder thinking of making a Pink Sheet app, exploring the process in Tinderbox would be really useful for seeing where optimisations would be helpful and conversely where scope for ambiguity would also be a plus.

I agree that edicts are better than rules, in the long run, for this thing.

I also encourage the OP to investigate typed links (not depend on *untitled links) which can (a) help to add a level of formalization on the map and (b) help with the reporting duty – which is where this whole thread started.

I don’t know how many Pink Sheets the map (or additional Models) that the map would eventually be be expected to represent. The way the map is currently designed, I think it could easily get out of hand and be very difficult to understand.

As we’re using an agent, we also need to use links(original)... rather than links()... in the rule/edict otherwise the action evaluates differently in the original note vs the alias (inside the export agent).

OK, the actions don’t help. On export, we need to identify for 4 different cases the one (or in some cases more) notes linked either to or from this note and which have a particular prototype. Then we want the $Name of this note.

Aside - fixed assumed typo in attribute MyMethapor to MyMetaphor and updated actions, KA lists, etc., accordingly.

I notice that $MyModel and $MyMetaphor are set-type but $MyStories and $MyStudies are list-type. We don’t desire dupes here so set-type would be more useful. So, changed.

For export, $MyModel’s data doesn’t help. What we really need is the $ID of the model/story/etc linked note.

As the existing $MyModel may be useful working in the actual TBX, I’ll make 4 more set-type attributes with a $MyModelID, etc. to hold the ID of those linked notes and amend the edict accordingly.

Thanks to you both for all this work. I don’t understand much of it but will get there…
I think the links could be typed (if by that you mean to name them) as:
Model-PS
Metaphor-PS
PS-Study
PS-Story
That would certainly be enough to get started. It may be worth adding a Model-Metaphor link as well but not crucial.

In terms of maps, it is the Model that anchors the map. So there would be as many maps as models. Generally speaking, there would be a maximum of 15-20 pink sheets per model and 2-3 studies and stories per pink sheet. Each map would then have a maximum of 140 notes, more likely about 80.

The extraction you are working on would be by map which reinforces the wisdom of not building maps at root, per your comment earlier. If I need to use Pink Sheets from different models, I can do that in the spreadsheet then group them in Tinderbox later, if necessary.

Hope this helps to give a little more context.
Thanks again!

The edict is now:

$MyModel=links(original).inbound..$MODID;
$MyModelID=links(original).inbound..$ID;
$MyMetaphor=links(original).inbound..$METID;
$MyMetaphorID=links(original).inbound..$ID;
$MyStories=links(original).outbound..$STOID;
$MyStoriesID=links(original).outbound..$ID;
$MyStudies=links(original).outbound..$STUID;
$MyStudiesID=links(original).outbound..$ID;

I’ve also disabled the edict in prototype $Pink Sheet Prototype as it has no purpose running there.

You’ll get there @Stephen

Since @mwra is taking the lead, I’ll step back and delete the misleading posts, above, so as not to sow confusion with a different point of view. It’s always best to let @mwra handle how-to questions here.

Most useful. Even more reason to put each map in a sibling container - moving the existing map from root into a container off the root (e.g. just as prototypes live in a root-level container /Prototypes). I’d avoid nesting Models so in ‘looking’ via query at model X, you don’t inadvertently have unconnected model Y in-scope in a nested container beneath.

Fixed typo up-thread, kindly reported by @PaulWalters, where I repeated the same scope of a links() call , the point actually being that we needed to change the original.

I should add, that just because I’m changing things in @PaulWalters’ TBX, that these are in any corrections to errors. Far from it, even the PE1 document is a big time saver. I’m documenting the ‘changes’ to try and surface the incremental formalisation of emergent structure.

Sorry for slow progress, this is interleaved into a busy work day.

No, models will never be nested, they are standalone which is what makes them so useful in the use of Tinderbox for this work. Sometimes the metaphor may apply to the model universally (the Model-Metaphor link I mentioned in my edit above) but more often the metaphor is pink sheet specific.

The stories and studies will always be pink sheet specific, they provide the substance to the point being made (which is why there are always 2-3 of each per pink sheet. But there may be situation when the same study supported several pink sheets, I guess I can use aliases in different maps in that case.

1 Like

And don’t worry about speed of progress. This is something I could never have worked out myself and would be nice to have (not must have) in the next month or so… :slight_smile:

…and yes we will need typed links (though suppress link labels for a clearer map). Why? Consider this current code:

$MyModel=links(original).inbound..$MODID;
$MyModelID=links(original).inbound..$ID;
$MyMetaphor=links(original).inbound..$METID;
$MyMetaphorID=links(original).inbound..$ID;

But whilst the original code finds one item, the ‘ID’ variants find two:

attributes%3A%20PS02%3A%20Intellectual%20knowledge%20creates%20a%20virtual%20reality%202019-05-31%2017-00-16

Duh, of course as both Metaphor and Model notes are a single untyped link therefore links(original).inbound..$ID will find 2 IDs whereas the model note doesn’t have a metaphor code and vice versa.

Also, have now re-ordered KAs and code so the order runs model/metaphor/study/story so as to align with the column order on export. From experience, doing otherwise causes false negatives when debugging export as input/output list are in different orders. This is protection against human rather than machine fallibility - something tech system configurations overlook when writing for others (as here - this is for @Stephen’s eventual use). Been burned by this in (non-Tinderbox) past work.

Links in Tinderbox are always one way, so I’d name thus:

Model
Metaphor
Study
Story

None of this is in tablets of stone, just trying to show my thinking in terms of adding formalisation.

BTW, I’ll probably turn on link type labels (actually) on by default until all pertinent links are typed, then turn off. Note link type visibility is scope to all links of that type in the doc. For links type ‘x’, turning label vis off means all type ‘x’ notes in the doc lose their label in Map view (and Timeline view FWIW) but type is still shown in things like Browse Links. IOW, link type visibility setting doesn’t alter link type assignment.

Got to stop for a bit. more in c.3-4 hours.