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.
A piece of policy could be something like,
All books should have properties for
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.
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?”
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.
Specifically noting that this one has a comment with some great candidates for developing and investigating structure when you’re auditing your graph.