Using Types like Anytype or Tana

I really like apps like Craft and Anytype, Craft is awesome for creating docs thas I want to share or publish, a lot like how I use Google Docs. Anytype is also very UI-friendly but far better for knowledge management. I think being able to make everything some kind of Type is very beneficial to the way my mind works. Medium post on how I think about types in KM

But I really like outliners, and even though I am on the waitlist for Tana (which seems to combine the best of both) the unencrypted online-only is a big concern for me. I have been using Logseq on and off but never managed to make is my home. I was drawn to Anytype as it is privacy oriented and has those Types, but there is so much less friction in outliners and I would love to make it work.

Any of you got any thought on how to replicate Tanas supertags or Anytypes object types in Logseq?


Exactly the same state I’m in. I’m waiting for a Tana invite because of how I think Supertags are exactly the function I’ve been searching for.

Using tags with inherited attributes/properties would make my pkm a lot more convenient.

It would be even more awesome to have this in locally stored files. :slight_smile:

I’m thinking about the systems types/props/attribs would allow us to build. I know there are ways to add this to pages and blocks today, but I don’t really know how to go about replicating the behaviour of Anytype, Tana or other apps using this approach.

Days ago there were commits like this one so there is hope:


Yes, this may be in relation to Tienson’s tweet where he showed his Logseq, and showed some notes talking about a “Properties 2.0” and schemas. I think we can achieve supertags fairly easily with Logseq, and adopting different views should also be easy. I’ve already built a prototype for the table view Tana has. I need to finish completing the plugin so I can publish to the marketplace, but I have high hopes.

Also just noticed something, from tienson’s tweet (which is looking very promising) you can see how he’s showing off this new schema type of look:


Very cool! @tienson

I hope we will not be forced to switch to .edn to store notes to get this feature. I’ve always thought that since property keys already have their own page, they could be enriched with page-properties:

- Oscar Wilde
  birthday:: [[Oct 16, 1854]]

property-type:: date

That’s amazing. I’m actually in the Tana trial, but the online-first nature of it is already cumbersome and probably won’t change in the foreseeable future. Whenever this schema aspect is live, I’ll probably do the switcht.


I didn’t know about Tana and its supertags, but I started testing Anytype even before Logseq and I liked the concept of “types”. Turns out, it’s also usable in Logseq.

You just have to use templates with properties. It’s easy, convenient enough and very flexible.

For example, let’s say I want to keep track of songs I want to learn.

1. Creating a template = defining a type

Here I’m creating a template for a type called “canción” (song). The key is the “type::” property, but at the same time I’m defining any other property I intend to use for that type. For example, I want to record the “state” (pending to learn), a relevant URL, author(s), etc.


I could add not only properties, but also any sub-blocks in here, like a section for lyrics and tabs, a notes section… just anything I wanted.

2. Invoking a template = creating an object of a certain type

Here I’m creating a new song, which is a block using the “canción” template. Some properties are already filled (like the “type” property") and others can be filled in that moment and will be specific to that object.


As you can see, I’m referencing an existing block/object (El Viaje de Chihiro = Spirited Away) which has a different type (película = film).

3. Creating a query = creating a set with all objects of a certain type

Here I’m creating the equivalent of Anytypes’ sets, and more speciffically a set of songs filtered by “pending” to learn.

I’m also switching the query to table format, making this effectively an “inline set” anywhere I want, a feature that hasn’t even been added to Anytype yet.


Here you can see a much more detailed explanation on how to use templates as “types”.

Big caveat: You can edit a template at any point and new objects will be created with the updated template, but the existing objects or instances won’t update. When I edit a template, I make sure to look into the “set” (query) and quickly update previous objects (blocks or pages) of that type. Not ideal if you have many of them, but good enough for now.

Big advantage: As you can see, you can assign several “types” to an object, which is much more flexible than Tana’s and Anytype’s implementations. For example, something can be a “website”, a “reference”, a “resource” and a “tool”, or a “meeting” and an “assembly”. It just comes down to what #tags you use in the type:: property.

This is nowhere near the UI and functionality of Tana’s supertags, but it’s close enough for me and VERY flexible. And it’s working in a more powerful way than Anytype does right now (allowing for inline sets, for example).


This is the big caveat. I tried for a while to implement this in Obsidian, but the fact that you can’t update past instances of a template gets horrible real fast. If you actually use your notes a lot, you’re going to want to update the format a lot.

As someone who’s in both betas, this is possible in Tana already (just add as many tags as you fancy, you can even have a structured hierarchy of tags with shared properties). It is a scheduled feature for Anytype.

1 Like

This is really a drawback - for me, templates aren’t really usable because of this.

I certainly would wish for stronger semantics and structure support in LogSeq. This is issue is an example of that.

It could probably be described as a design decision, choosing some point on the “parsing markdown files”<->“note taking as structured data/graph database” axis. Where LogSeq currently is quite far to the former, whereas my preference would be the latter.

As noted elsewhere, there’s signs LogSeq is moving towards the structured data approach, so there might be hope!


Aren’t Logseq Markdown files already a structured data format? Lists of key:: value records organized hierarchically, it’s basically what formats like JSON, XML etc are.

The only advantage I see in using EDN instead of Markdown is that value in key:: value can be a block, while now value would have to be a reference to a block stored somewhere else:

key:: ((block-id))

as opposed to:

key:: - Foo
        - Bar
         - Foobar

what you define as “flexibility” can also be seen as a lack of proper structure. In some cases, I need only specific types to ensure that my metadata follow a controlled set of possible values, for example say I want my property ‘status::’ to only accept 3 possible string values, eg : wip/not started/archives or I want my ‘duration::’ values to be exclusively numbers, whereas ‘start-date::’ must be a date in yyyyMMdd and nothing else because I need to make calculations.
types are useful when you expect a specific type of value (strings, numbers, dates, urls, page-refs, blocks ids, checkboxes, etc) or a specific subset of possible values (by using a drop-down, a checklist, à user-defined list of possible options).
flexibility is great but sometimes, we also need options to eliminate user errors on input, so I really hope the devs introduce advanced templating and types with a nice ui/ux: a forms builder or a template builder… in this regard, I think both Tana and Capacities are ahead of logseq.