Require? No. Here are two notes with with no title or text atop a map adornment with no title:
But wait, how can the app track items like these? It is done via an internal unique ID. Initially hidden, in v5.6.0 (Sep 2010) it was made accessible to the user as $ID.
So, ‘required’ no, but in terms of design intent, notes would have a title ($Name) and may have body text ($Text). In some PKM or outlining systems, the note might be one piece of text (with out without discrete paragraphs), in others the same but with all or part (if long) of the text used as a title.
For instance OPML, if one reads the actual spec, it is apparent it has no notion of ‘text’. But, don’t lots of apps use OPML and exchange text? Yes, Tinderbox (here) amongst them (v2.5.0, Jun 2005). As best I can trace it, the divergence is Omnigroup’s OmniOutliner that added a custom extension
_note to the format which many now think is part of the text. Because in OPML what we might consider the title goes in the
text attribute, while the text goes in
_note (at least for use with apps that know about that custom convention). Even that may enrage some as it only supports plain UTF-8 text, so no highlighting supported.
Linkage is another battleground. A recent crop of PKMs, drawing on wiki-mark-up notation, use
[[…]] notation. Add an un-styled note space using inline mark-up (currently Markdown is the poster-child) add soon we have many people whose only concept of making/marking a link is
[[…]], oblivious to what’s really happening. Again, Tinderbox is accommodating—see ‘Text link creation via the Ziplinks method’.
Thus it is that the PKM/note-taking/outlining domain is bedevilled by:
- WYSIWII (What You See Is What It Is), i.e. it is what it looks like.
- HIWIWII (How It Works Is What It Is), i.e. things must work in a certain way (q.v.
- TAWDFMA (ThisApp Works Differently From MyApp), a variation on HIWIWII.
WYSIWII address the tendency of many (most?) of us to work backwards from an idealised ill-defined but sharp-edged mental view of how things should be. IOW, getting to re-paint the room countless times until it ‘looks right’; easy, no understanding/thought involved! HIWIWII speaks to the constant issue of paradigm mismatch: “ThisApp doesn’t do task X in the same way as OtherApp. Everything should work like OtherApp (unstated part—I use OtherApp a lot and know it far better”. IOW don’t make me think.
I googled ‘Block Reference’. If using ‘normal’ Web behaviour, there is no answer as page #1 of results is all about CAD apps. If we roll our eyes and go to page #2 there is a link to " How to Use the Block Reference Menu in Roam Research" which starts “Everything is a block in Roam Research” before failing to explain what an addressable block is and rapidly dumping the reader into easy-to-understand constructs like:
I’m sure it works (I don’t use Roam) but sadly I’m none the wiser other than that it appears to mainly work of literal string matches. Probably (hopefully) there is something like an aTbRef for Roam (and other PKM) that explains all the assumed-self-evident detail. The example above explains why such resources are of value. Now I come to think of it Tinderbox does have block referencing, it’s just not much used or particularly easy to do. Tinderbox does have transclusion, and very richly so, in its export code. Recall, the app’s debut was in 2001 and back then personal web-based apps weren’t really a thing for the ordinary person. Originally such rich views were exported. The march of time and the “don’t make me think” approach of many has pushed the evolution of the Tinderbox preview (originally added in v6.0.0 (Apr 2015) to ‘test’ HTML pages without exporting) in a zero-config Markdown-based preview.
Here, I feel for the app developers. The behaviours above in many (most?) cases rest on real thought and research going back decades. We as users tend to over-emphasise in the User Expereince (UX) part before looking deeper. Many users jump around serially between apps, berating the UX of the last—often for not being ‘new’ or ‘intuitive’ enough in some unexplained way—before rushing to the newest shiniest entrant to the field. There’s a paper for someone looking at the underlying design of PKMs & note-taking apps rather than the visual froth of the UI. I suspect there are fewer ‘new’ ideas around than we are led to believe
In closing I think this sums it up rather well, in relation to non-trivial use of PKMs:
“Do not try and bend the spoon, that’s impossible. Instead, only try to realize the truth… there is no spoon. Then you’ll see that it is not the spoon that bends, it is only yourself.”