Anyone here experimented with / implemented "object types" in DT? – constructive experiences to share?

DEVONthink Tips
1

Hey community,

With the Markdown editing being improved in DT, I am currently contemplating whether DEVONthink as a system would allow for something like a workable (not-too-complicated) way to implement (emulate) something like ‘object types’ within it?

As many here are surely aware, there are some PKM apps that now base their whole logic on it (like Capacities, Anytype, formerly TriliumNotes(†) et al.). And for me, this really makes sense (cognitively) and works (practically).

Thus my inquiry: has anyone tried something likewise? And gotten this to work in a ‘sensible’ way, i.e., without too much friction for his/her sentiment?

I am contemplating that a combination of tags and templates could bring one near to such a thing.

Also, from my knowledge of DT, I guess that labels and smart collections could play a role… :thinking:

But in all this, I already sense too much friction in direct interaction, problems of detectability, and easy-at-hand structuring of such a system. And I am looking for ‘object types’ especially for the reason that in many cases (mine) they make interaction with (semi-)structured data (and documents) much more intuitive.

So, I wondered whether anyone here has – successfully – gone down that road?

And while I am also interested in elucidation of relevant aspects, technicalities, problematics, the focus of this inquiry is experience in real constructions and implementations, and the ways things were achieved, or at least tested/experimented by others. :blush:

As for me, sensible ‘implementation/emulation of object types’ means:

• giving individual objects in the DB a recurring/stable/unique profile (– both in terms of a) metadata profiles (even specific metadata fields, at best), i.e., ‘meaning’; and b) in terms of visuality/layout/appearance of an object type, i.e., ‘look’ or ‘design’.

• having these ‘object types’ be easily discernible in everyday interaction – visually (see above) as in terms of interaction

• … and generally having ‘object types’ taking a first-class and foundational role in the whole system (here for a start: within one database)

So, the ‘challenge’ of having a workable ‘object type’ structure is to have a fundamental and very easily ‘affordable’ unit of interaction, which is deeper and more structured than tags, labels, or folder sorting – but also easy to interact with cognitively and practically when using one’s DB in DT.

It also is defined by being more customizable and more on the ‘semantics’ side of things vis-à-vis file- and document-types (which are handled extremely well in DT of course, as it is a ‘document manager’; … and ‘file types’, I guess, might also play a part in any emulation of such an ‘object type’ system…)

If anyone doesn’t know what I mean by ‘object type’ here and in the context of PKMs, then this post is probably not for you, in the first place :blush:

– still, people interested can look up these references/links (and find more by search on the internet):

https://docs.oracle.com/cd/A58617*01/server.804/a58236/09*objs.htm

https://www.reddit.com/r/PKMS/search/?q=objects+types (for discussions of it in the context(s) of different apps + database-like ‘systems’)

TIA for any constructive experiences and approaches shared! :folded_hands: :seedling:

2

Object types have its place in very large systems, and systems where accuracy is critical. In personal knowledge management, however, types are no more than bloated tags.

Maintaining typed objects requires considerable time and mental energy, in return for nothing but a couple of fancy tables, kanbans or timelines. It’s the opposite of productivity, for both the user and the dev. Unfortunately that’s exactly what the new generation of note-taking apps is advertising.

Now that you’re already using markdown, you can simply write whatever metadata in the frontmatter. Find a way to bulk retrieve the data only when you need to. Utilize DT’s custom metadata fields if you prefer, though these fields are invisible to other software. Or, if you are like me, just don’t care about complex metadata at all.

3 Likes
3

thx @meowky for your take.

all this is something to consider, of course.

for me, its clear that the concept of ‘object types’ successfully crossed over into PKMS, also ‘personal’ – as this can also be quite extensive (depending on scenario), striving for precision, and leveraging some kind of custom ‘type’-ontologies. also, it just ‘clicks’ for some people (including me).
(plus, it might have been misleading to link to the Oracle text, as this firmly leads into large DB-systems; … but up to now I couldn´t find a real convincing paper on general systematics of ‘object types’ in PKMS, and why they seem to work so well for so many people. One only finds a lot of app-specific discussions on this… :face_without_mouth:)

of course, as often is discussed here, there are different kinds of ‘use cultures’, user preferences and styles of different folk vary – as do the architectures of their ‘PKMS’ (which is quite a formal catch-all label anyways, it seems).
But certainly, for those using and developing Capacities, Anytype, Trilium etc it obviously ‘works’, and makes life easier. But of course that’s not everyone, and in that light I understand your cautioning remarks.
– I am quite convinced the many people using these are rather the ‘non-coder’ types (though, I also know a lot of coders and developers jump onto these systems as well).

This is also why I adressed people sharing the interest/preference for that style (‘object typed PKMS’)

The whole line of implementing it via frontmatter (I guess you mean mainly YAML, right) which you bring up seems an interesting pointer! Thx! Haven´t really considered that.

While using MD extensively for some time now, I never entered that extended practice’ (– i.e. using YAML; aside from some escapades w/ Omnivore and Obsidian) also, because I am more on the GUI side of things, generally and as long as possible :smiling_face:).
Then, I am aware that is just what people are doing, or rather have been doing, in Obsidian, whenever they wanted to work with more structured data objects (I think this changed when people discovered first Dataview, and then Datacore).
Plus, I was thinking this might be the way to grapple the question of implementing different layout-types, as YAML is needed anyways to use different CSS ‘presets’, AFAIK… :thinking:

But it seems an interesting idea for my case/research, so thx!
I will maybe revisit the Obsidian forums for hints and clues.

Still, if anyone already uses YAML in such a way to systematically emulate and work with ‘object type’-kind of things in DT, I´d be happy to hear about ways and experiences! :grinning_face:

4

Just to clarify: YAML is not a requirement for Markdown metadata unless you’re using Obsidian. We have long supported MultiMarkdown metadata.

5

thx for pointing that out, @BLUEFROG. appreciated.

In this context it would mostly be interesting to learn, which kind of metadata practices people can report about when experimenting w/ something akin to ‘object type’ implementation/emulation.

but it is of course always good to have the basics straight and laid out, when moving through such territories… – esp. as any affordance can be linked to other ways of building/constructing a ‘solution’ :bus_stop: :world_map:

6

Following on from @meowky, an option to have different object type templates could be achieved using:

  • DT markdown templates
  • MacOS Text replacement to auto populate the markdown metadata
  • Alfred/keyboard Maestro/Textexpander/DT’s XMenu to insert a ‘snippet’

I personally use MacOS text replacement to insert a block of text from a keyword (like @address to insert my full address). The advantage of this is the replacement becomes available on my IPhone and iPad as well.

2 Likes
7

I see. thx, @saltlane !

sounds like another good building block / option in a grander scheme / strategy.

I certainly have experience working w/ text replacement and snippets, including the tools you mention.

I have used such strategies in some other contexts. at some point it can become a problem that everything is very ‘backstage’, and there are very few visual cues etc.
– but certainly a worthwhile idea to take into account here!

… and mave I find good ways ro attach such sytematic text replacement inside of DT (via smart rules, folder attachments etc. this might make things more relatable to the visible structure… :thinking:… hmm…)

appreciate the idea!

8

Funny addition:

I just asked Perplexity for a ‘Deep Research Report’ on a more systematical evaluation of where object type methodology intersects w/ current PKMS field.

… and it spew out an answer placing DT at #3 of relevant contexts of applications within apps – right behind Capacities and Affine :laughing::

[ … ]

Implementation in Modern PKM Systems

The theoretical concepts of object types have been operationalized in several contemporary PKM tools:

Capacities implements object types as the foundational organizational unit, where:

  • “Inside of a space, all of your content is stored in databases, one database for each type of content”[15]

  • Basic object types are built-in, covering common use cases (pages, images, web links)[15]

  • Custom object types can be created for specific domains and workflows[15][17]

  1. AFFiNE approaches object note-taking through:

  • Property fields within each note representing object attributes[19]

  • Tagging mechanisms to group notes corresponding to the same object type[19]

  • Template support for different object types[19]

  1. DEVONthink users have explored implementing object types through:

  • Combinations of tags and templates[5]

  • Smart collections to organize similar objects[5]

  • Metadata profiles for different object categories[5]

[…]

It´s also interesting to read the whole context of this Perplexity ‘Research Report’ as it is quite informative and elucidates this ‘non-standard’ topic quite a bit already. (also, one finds a lot of references in it…)