The currency of a PKM system

As we’ve reminisced about the importance of building out a personal knowledge management system, we’ve seen that we are Creatives, Synthesizers and draw satisfaction from generating, not recalling. We’ve become aware therefore, that the information entering our sphere needs to be addressed, organised, filed for recall, and made a part of a “living” system of notes. We’ve seen that the modules (into which information is packaged for ease of teaching primarily) should not be the frame into which it is filed for recall. And, the structure and solution that we use as the back bone of our personal knowledge management (PKM) system will need to be robust enough to handle a high volume of intricate information at a fast pace, and to contain, safely, information of various forms: graphs, data points, paragraphs, equations, methods/strategies, etc..

On that note, let’s get stuck into the information that we will be handling in the PKM system. It is so vitally important that we don’t just create the system before we know the currency of the system.

We’re in the sphere of STEM (Science, Technology, Engineering, Mathematics). The information that we will be managing will in its essence not be simple. There will definitely be cross-referencing requirements. Let’s take an example, because thought without a concrete locator is difficult.

The example that I will use will be something that I have had to think about recently: pumps. A pump is a thing. And the information that we will be managing around pumps will have a certain structure. If we have the structure, we can check whether the structure will be robust enough to replace “pumps” with something like “gearbox”, or “beam”, or “heat exchanger”.

Now, a pump has:

• a shape (including the size, and working principle of the pump (centrifugal, axial, mixed flow)) and parts to it - impeller (with a blade angle, blade shape, diameter), shaft, volute casing. We could even have CAD models referenced here.

• some performance metrics: power, head, flow rate, efficiency - linking back to working principle.

• a graphic depiction of the performance metrics - a single pump has a single performance curve.

• a mathematical definition of the governing equations in a rigorous form, meaning that every little perturbation of loss or fluctuation is captured explicitly. Or a general form, meaning that some assumptions and approximations are made concerning losses, fluctuations, etc. - think Euler Turbomachine equations.

• Assumptions simplifying the mathematical depiction of the system - One-dimensional flow, Flow entering normal to the impeller.

• a method of evaluation - a strategy for selection, a strategy for design

• a manufacturer

• maintenance options

• a list of pro’s and con’s, which you can actually calculate or mathematically prove

• a list of limitations (also possible to mathematically express)

• Reference to the physics and applied mathematics behind the system:

  • Fluid properties (density, viscosity, etc.) that play a role in the design & performance

  • Orientation, specifically in relation to gravity - if, for instance, the pump has the fluid flowing downward into the impeller, meaning the fluid falls onto the impeller, then the weight of the fluid along with the pressure and velocity will play a role in wear and performance.

  • Calculus rules applied to operate with the governing equations

  • Differential Equation rules applied to operate the governing equations

  • Linear Algebra to generate systems of equations when optimising for simulation

  • Numerical Methods used when simulating to approximate answers

• Simulation templates, including inlet, outlet, operating conditions, assumptions and numerical solvers pre-selected. (If your project calls for these kinds of things).

As we delve into all the different “things” that engineers come accross in their projects, we could build out the information landscape further. For now, this suffices to make you aware of the intricacy that exists in mechanical engineering information landscape. The landscape is vast, and it is so so easy to get lost in the details of each and every one of these points. In writing down this list, I only eluded to many things, but the perturbations and variations that are possible in each of these points are vast, and our PKM system will need to be “vaster” to contain this intricacy.

The PKM system will therefore need to be a database. A database is an efficient way of saving and recovering information that relates to other information. What we are busy with at the moment is the design of a database. We have successfully done the first iteration of creating the “zeroth normal form” (0NF) for the information that will be contained in our database. Each of the emboldened words is the name of a column for our database. But, as software engineers and developers know, the 0NF is not efficient, nor robust, nor really real. It’s just a list of what we will capture. This is the level at which class notes and lectures exist. Everything on a page in a book, and you flick through the pages scanning, hoping that your eye might land on what you need.

For the PKM system to be robust enough for our knowledge landscape, we will need to venture to the third normal form (3NF). There are rules governing the creation and refinement of each of the intermediate Normal Form steps:

• The first normal form requires that:

  • there is no repeating data - data should be atomic.

  • A single value should be associated with a single column: there should only be one entry for “shape” for each entry of “pump”.

  • Each entry of “pump” should be identifiable with a primary key (this could be a nonsense phrase like “8juk10dvysn8930d”, which does not repeat anywhere in the database)

This is the nature in which a notecard might exist in the Zettlekasten method: it has an identifying number, there is a topic: pump, and there is some information about pump, maybe a little description on the shape of the pump.

• The second normal form requires that:

  • 1NF is met, plus

  • Partial dependencies are removed: additional relational tables are used to facilitate this.

An example of this can be found when looking at the attribute “Manufacturer”. The Manufacturer of a pump might not be the only manufacturer that manufactures this pump. But each manufacturer has their own location, contact number, catalogue, price. So instead of having multiple entries possible for “Manufacturer” and the associated attributes, we will have another table, relating pumps to manufacturers.

• The third normal form requires that:

  • 2NF is met, plus

  • Attributes should only depend on the primary key.

  • If there is some dependency of one entry upon the nature of another, a table is designed for this dependency to be optimised.

We optimise entries where if you have made a decision that exclude other options, additional tables are introduced and relations are made through intermediary tables. You have a pump. It can be centrifugal, or axial, or mixed flow. It can not be multiple at a time. Each of these have their own associated governing equation, assumptions, shape, performance. And without this distinction of type, any further allocation of attributes to our pump will be impossible. A table is created to optimise this.

When designing a database, we need to know what information is captured, how the information can be best optimised, and how the information relates to each other. The descriptions that I have made thus far have been wordy, difficult to understand and in need of further clarification. Enter ERD (thanks Peter Chen, 1970).

Each table is represented by a block. Each table is unique and contains explicitly the keys for referencing records. Each attribute is a line item in the block - the key is the first attribute in the block. Each attribute (column name) exists once and only once. Each relation is initiated with a line from a table entry to another table entry. I.e. for each attribute, there may be a relation to another attribute. This relation can be one to one, one to many, many to one, many to many. There are many more relations that I have not mentioned now. The nature of the relation is presented by the symbol at the head and foot of the line.

We’ve done a gruesome activity today. We’ve discussed pumps with so much depth of understanding, yet only referencing at a high level. We’ve played around with the different information pieces that we have on our table. We’ve generated the very first glimpses into a possible database, looking, again with a high level view, at a deep technical methodology.

I would like to challenge you, reader, Mechanical Engineer. Take a topic you are thinking about now. Write down the 0NF of the information contained in the topic (off the top of your head is a sufficient starting point). Then see where you can split off 1NF, 2NF and even, if you’re gutsy 3NF tables. Draw a line between linking attributes and see if you can generate an ERD from which to build out your PKM.

We’ll stop there for now.

Have a great week, genius!

Hannalie