Knowing and Enforcing Policy Within Your PKM

General
1

I imagine that everyone has a set of soft rules that they like to abide by, that may be incomplete and also contradicting - I’ll call this weak policy. It’s fine if the policy is broken as you create content or as you specify policy, but you as a user may wish to know about it, so that it’s done intentionally. I don’t think the contradiction and incompleteness (weakness) is an issue as there’s probably have some contradiction within our mental models. So I’d like to look at how others might answer the question,

How might we express policies and verify where they are and aren’t holding?

  • Recognizing that a policy fails often may require reassessment of that policy.
  • Testing different policies can be a sort of “property check” to see to what degree you’ve done to what things
  • If assessment is in real-time, then it may be possible to see what policies would be in effect as you edit/create a block to more easily adhere to or question your policies
  • I don’t have the background to justify this claim, but I suspect that there are cases in which a statement of policy A and a statement of policy B could specify how to transform items under policy A into items under policy B, which could really help the change process.
  • A colored graph view, “all blocks on this page abide by policy”, may indicate some otherwise unnoticed structure.

Example 1

A piece of policy could be something like,

All books should have properties for type:: book, title:: , author:: , and isbn::

And an easy way to know some of the details of that policy are to use a template, perhaps you have more fields, but those three can have an initial value of “unspecified” and maybe the others are empty. Implementation is up to the user.

One could ask, “What books don’t have all of these?” and one way to answer this would be checking that all blocks with property type=book that don’t have values for or don’t have the other properties.

Example 2

Another example, to encourage brevity for things that you have a lot of and query on often - like tasks

Tasks cannot have children that are not tasks
Tasks cannot have over 120 runes

Expressing a task as a composition of tasks makes sense, but maybe you don’t want your notes about the task to appear in queries.
Your query results could be collapsed so that finding tasks will only have tasks, but diagnosing the second policy would really be a case of, “gosh this query has some really long individual results, maybe should I rephrase these?”

Example 3

A block cannot have more than 10 different tags in the properties

This may be a way to indicate to yourself that this block could be expressed with more resolution. This could also be done as a query.

Seems like some of this can be treated with queries, but they’d not be adjacent to where the policy is relevant, but instead on a list of chores.

My only idea on implementing this is to have a “PKM chores” page where I have queries that find where I have failure of policy, however, I don’t want to put in the work to create and maintain that if someone has a perspective I would agree with that argues that reviewing weak policy is not worth the squeeze.

Other discussion that may be similar

Specifically noting that this one has a comment with some great candidates for developing and investigating structure when you’re auditing your graph.

2 Likes
2
  • Quick: As a soft rule, weak policies are not worthy.
    • Because they miss the value of consistency.
  • Slow: But if you want a calculation that is:
    • short: The weaker a policy, the less worthy the squeeze of reviewing it.
    • long: The value from reviewing a policy generally is:
      • inversely proportional to:
        • the needed squeeze
      • proportional to:
        • the strength of the policy, which generally is:
          • proportional to:
            • the gains from enforcing it, multiplied by their probability
          • inversely proportional to:
            • the losses from not enforcing it, multiplied by their probability
3

Thanks for you answer.

It makes sense to me that given some time I should be able to construct policy that

  • provides value when implemented on an expected portion of the graph…
  • where implementation cost/friction regulates how much of the graph I’d expect it to be on

But this is what I find difficult - I feel that I either lack the experience or the patience to choose policies that I am willing to enforce for long enough to learn from. Would you be able to offer,

  • General bits of policy that are very often a good idea?
  • Approaches and advice on how to decide whether or not I should impose some structure via policy?
  • Methods to assess existing patterns to find where I may be practicing some policy unintentionally so that it appears in much of the graph, but it applicable to all of it?
4
  • Offerings
    • General questions cannot get specific answers.
    • The field is both wide and diverse.
      • I don’t know anyone experienced enough in this field to provide statistics on whether something is “very often a good idea”.
      • Neither am I.
  • Structure
    • It matters.
    • But structure is considerably unknown in the beginning.
      • If structure was already well known, the need for a knowledge graph would be limited.
        • Structure has to gradually emerge and be discovered with the help of the graph.
        • This is characteristic to PKM.
          • Most other tools only consume knowledge, but PKM produces as well.
      • It is impossible to impose unknown structure (that is in the beginning).
        • Imposing the wrong structure is counter-productive.
  • Methods
    • Review (manually) the graph from multiple different perspectives.
      • The more, the better.
    • Repeat.
      • It is natural in each iteration to notice things earlier missed.
    • Don’t spend more time in managing knowledge than in knowledge itself.
      • The system should serve you, not you the system.
    • Any artificially imposed limitations should be easy to lift when needed.
      • You cannot fully assess something if you don’t know how it is without it.
1 Like
5

Thanks for your thoughts. I plan to regularly reflect to find what is or isn’t appearing because I don’t think I’ve yet approached the scale to expect emergent structure and over time I expect I’ll figure out if I’m spending more time in knowledge management than I need to

my direction forward will be to

  • a general emphasis to let structure emerge from judicious usage of links before imposing additional structure
  • create queries to view link structure (histogram of forward and backlinks) as part of review
    • link density can justify need for greater/lesser resolution, like you mentioned in post #7 in 21147.
    • potential appearance of repeated structure
      • what tooling or practices do you have for programmatic or software supported motif detection in logseq graphs? I recognize this is a difficult question.
  • increasing ease to remove / change / lift
    • use references for property values in lieu of strings to improve
      • aliasing (as deduplication)
      • renaming
      • backlink counting
    • any policy should be detectable via programmatic search
  • implement a monthly review
    • keep log for notable instances of high friction. Logging low-friction may not be worth the squeeze since logging is already friction.
      • will likely implement as a tag and query on the review page.
    • review link structure
    • review usage of properties
    • attempt a temporary removal of newest practices
      • I’m unsure of low-friction approach, my thoughts
        • copying markdown files
        • automated text search/replace tool
        • index this copy as new graph
        • go over review process
      • do you remove data (even temporarily) in the process to “lift” limitations?
        • if so, how do you go about it?
  • don’t change existing policies yet
    • likely to wait until I’ve completed three reviews
6

No limitation should end-up blocking the way. With all its protective measures, the way should be free.

  • I move data out of the way. That includes:
    • repositioning
      • change lane, until finding the natural place
    • collapsing
      • even useful pieces need to park at the side-lane for a while
    • hiding
      • special form of collapsing, that doesn’t modify the file
    • deleting
      • quality is more important than quantity
  • I don’t use a special tool for that.
    • The graph is a tool in itself.
    • I could imagine an AI-based special tool, mostly for graphs built by someone else.
  • I don’t passively link what simply feels to be link-worhty.
    • I trust my reason more than my feelings (I hope so).
    • A link should have a good-enough explanation in my mind. I spend some time to find one.
      • If I find one soon-enough, I link accordingly.
      • If I don’t find one soon-enough, I don’t link.
        • I prefer losing some potentially useful connections
          • if they are that good, they will be discovered later
        • in order to gain better clarity (less noise) in the remaining ones
          • cleaning-up useless connections is harder
  • In that active approach, the motif is detected in the thinking process before it is clearly formed in the graph.
    • I treat my PKM graphs:
      • as magnifying mirrors of my mind
        • They are small subsets of the real thing.
        • They are for focused introspection.
      • not as parallel versions of my mind
        • They are weak reflections of the real thing.
    • I don’t use my mind to help the graph, but the graph to help my mind.
  • There are other approaches, as well as other variations.
    • You should form your own variation.
      • If you can automate it, that’s:
        • great achievement
        • of secondary importance
1 Like
7

This seems obvious in retrospect, but your stating it makes me realize I’ve made decisions that serve the graph’s completeness or correctness instead of increasing my capacity for introspecting on my thoughts. Thanks again.

1 Like
8

Really enjoyable conversation to read :heart:
I use some sanity check queries based on how I like things to be.
Though the other day I came across an unlinked note through those checks. As I try to link/tag all my notes.
This note was just a whimsical thought I had. It wasn’t relevant in any sense.
This was a moment to let it go. To just be, well it doesn’t need to be found, I don’t need to tag it.
Such notes will live on journal pages and my sanity checks are limited in how far back they look. So I will not need to continually deal with this outlier.
That’s how I recently dealt with my own personal policies.
I don’t currently have many. I have let go of the idea that everything has to be grouped a certain way. It has really helped me get more value and less hindrance. Natural links work much better for me.

1 Like
9

Can you share some sanity check query examples?

10

Sure! Here’s some I’ve been using.

Tasks without a tag

#+BEGIN_QUERY
{:title [:b "Tasks without tag"]
 :query [:find (pull ?b [*])
  :where
   [?b :block/marker ?mark]
   [(contains? #{"TODO" "LATER"} ?mark)]
   [?b :block/parent ?parent]
   (not [?parent :block/marker]) ;taak wordt niet getoond als de parent taak buiten beschouwing valt
   [?m :block/original-name ?mark]
   (not 
     [?b :block/refs ?r]
     [(!= ?m ?r)]
   )
   [?b :block/page ?p]
   [?p :block/journal? true]
 ]
 :breadcrumb-show? false
}
#+END_QUERY

Completed projects (status:: afgerond) without end date (datum-eind:: )

#+BEGIN_QUERY
{:title [:b "Afgerond zonder datum"]
 :query [:find (pull ?p [*])
  :where
   [?p :block/properties ?prop]
   [(get ?prop :status) ?s]
   [(= ?s "afgerond")]
   [(get ?prop :datum-eind) ?a]
   [(= ?a "")]
 ]
}
#+END_QUERY

Floating pages (non-journal pages, with a file. That don’t have one of a list of characteristics)

#+BEGIN_QUERY
{:title [:b "Losse pagina's"]
 :query [:find (pull ?p [*])
  :where
   [?p :block/journal? false]
   [?p :block/file _]
   [?p :block/name ?nm]
   (not [?b :block/refs ?p])
   (not [(contains? #{"startpagina"} ?nm)])
   (not [(clojure.string/starts-with? ?nm "hls_")])
   (not [?p :block/namespace])
   (not (has-page-property ?p :exclude-from-graph-view))
   (not (has-page-property ?p :type))
   (not (has-page-property ?p :cluster))
   (not (has-page-property ?p :hobby))
 ]
 :result-transform (fn [result] (sort-by (fn [r] (get r :block/name)) result))
 :view (fn [result] (for [r result] [:a.tag.mr-1 {:href (str "#/page/" (get r :block/name) )} (get r :block/original-name) ] ) )
}
#+END_QUERY

Broken references, probably mentioned in some earlier post

#+BEGIN_QUERY 
{:title [:b "Broken References"]
 :inputs [ "\\([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\\)"]
 :query [:find (pull ?b [*])
  :in $ ?matcher
  :where
   [(re-pattern ?matcher) ?regex]
   [?b :block/content ?c]
   [(re-find ?regex ?c)]
   [?b :block/refs ?br]
   [(missing? $ ?br :block/content)]
   [(missing? $ ?br :block/name)]
 ]
}
#+END_QUERY

Empty files

#+BEGIN_QUERY
{:title [:b "Empty files"]
 :query [:find (pull ?p [*])
  :where
   [?p :block/journal? false]
   [?p :block/file _]
   (not 
     [?b :block/page ?p]
     (not [?b :block/content ""] )
   )
 ]
}
#+END_QUERY

Blocks without a reference. This one is on a specific page with a scheduled block that has the day to look at. Hence it is slightly more complex than expected.

#+BEGIN_QUERY
{:title [:b "🔥 Blocks zonder referentie"]
 :inputs [:query-page]
 :query [:find (pull ?b [*])
  :in $ ?page
  :where
   [?p :block/name ?page]
   [?t :block/page ?p]
   [?t :block/content ?tc]
   [(clojure.string/includes? ?tc "Avond")]
   [?t :block/scheduled ?dag]
   [?j :block/journal-day ?dag]
   [?r :block/name ?name]
   [(contains? #{"notitie" "activiteit"} ?name)]
   [?h :block/page ?j]
   [?h :block/refs ?r]
   [?b :block/parent ?h]
   (not [?b :block/refs])
   [?b :block/content ?bc]
   (not [(clojure.string/includes? ?bc "Trots op /")])
   (not [(clojure.string/includes? ?bc "✅ Herhaal taakjes")])
 ]
}
#+END_QUERY

If you have any questions, or want help editing these for your needs. Let me know!

3 Likes
11

Wow, these are great! Thanks!

1 Like