Support for entity/page types

[agentydragon]

Describe the problem

Roam works basically like a knowledge graph, where a page is an entity.

Knowledge graphs like WikiData or Freebase have types attached to entities.

Types are useful, because you can describe what attributes an entity of a given type should have. For example (from how I use Roam):

• "Person" should have a "Birthday" (possibly unknown), or a free-text "Where we met" field (possibly unknown).
• "Task" should have "Priority" (possibly unset), and "Task/Status", which is free text, but will often be something like "#DONE @ [[date]]".
• "Task to learn" is a sub-type of the "Task" type, so it has mostly the same requirements.

I already have a "type system" like this, but I maintain it manually. It would be really nice to have first-class support for it, and it would nicely overlap with another feature that lots of people would probably use a lot - templates.

Having a "type system" which has good UX would enable people to standardize and make faster lots of workflows that I suspect are common, like:

• People (where we met, birthday, interests, family, friends)
• Media (articles, their URLs, who recommended them, their topics, books, movies, IMDB/Goodreads links)
• Tasks (task status, who is working on it, when started, what priority, what project is it under)
• Problems that need solving (status, priority, problem area)

You can already e.g. store people you know in Roam, but if you want to have a consistent way the pages look (so you can, say, query them and they're not a huge mess), you basically have to Ctrl+C/V a template. It's also easy to make a mistake - e.g., on Joe's page, use We met at:: #[[GLC 2020]] instead of We know each other from:: #[[GLC 2020]].

Feature implementation

I think you could implement this by supporting some special attributes. I'll give a user story that I'd really like to have.

In my system, I currently use the tag Type:: to point to an entity's type (or multiple types - e.g., I work at Google and my page Google is a mix of "the Google office I work at and stuff I need to do when physically there" and "stuff related to my Google work").

• Type:: #Type would declare "this page is a type".
• Attributes:: would contain a list of links to well-known attributes this type has, and maybe validation conditions.

For example:

# Task

* Type:: [[Type]]
* Attributes::
  * [[Task/Status]]
  * [[Task/Project]]
  * [[Tags]]

# Task/Status

* Type:: [[Attribute]]
* Default:: [[TODO]]
* Suggest::
  * [[DONE]]
  * [[TODO]]
  * [[Blocked]]
  * [[Waiting]]
  * [[Cancelled]]

# Task/Project

* Type:: [[Attribute]]
* Default:: [[No project]]
* Validate::
  * Type:: [[Project]]

If a page has a Type:: attribute, it is interpreted as an entity with a type. In this mock-up, the types Type and Attribute would be built-ins. In the context of pages with the type Type, the attribute Attributes would be special, and in pages with type Attribute, the attributes Default, Suggest and Validate would be special (i.e., have a special effect on Roam).

With a task type specified like this, when creating a page (e.g., by using [ [ to link to a new page), Roam could suggest adding types, and based on the types, also attributes to the new page.

For example, say I have a daily note saying I need to hire a band for Joe's birthday party soon, I can select hire a band for Joe's birthday party and press [ [.

Roam could pop up an autocomplete box to select types for that new page. I could use Ctrl+J/K (or Up/DownArrow) and Enter to select that this is a Task.

Roam would then understand that as a Task, the page has a Task/Status, which is TODO by default, and a Task/Project, which is #[[No project]] by default. It could add those elements into the autocompletion pop-up. I could leave the Task/Status in TODO, and if I already have a Project for Joe's birthday party, I could ideally quickly assign the task to the project. If I assign it to something that's not a Project, Roam could warn me.

I could also add freeform text into the Tags:: attribute, and confirm.

Let's say I called the band but they are busy and can't get back to me until the weekend. I open the hire band for Joe's birthday party page and open the Task/Status attribute. An autocomplete box suggests #[[DONE]], #[[TODO]], etc. I select #[[Waiting]], and add more text:

#[[Waiting]] until #[[May 16th, 2020]], band is busy @ [[May 13th, 2020]]

Maybe I could even have a custom /-command to add a new pre-populated entity, like /newtask hire band for Joe's birthday party.

Subtypes could work like this:

# Task to buy

* Type:: #Type
* Supertype:: #[[Task]]
* Attributes::
  * E-shop link::

Types should be possible to change once created. For example, I might decide I want to fold the #[[Blocked]] task status into #[[Waiting]]. I could update the #[[Task]] type like this:

* Attributes::
  * Task/Status::
    * Default:: #[[TODO]]
    * Suggest::
      * #[[DONE]]
      * #[[TODO]]
      * #[[Waiting]]
      * #[[Cancelled]]
    * Validate::
      * Not:: #[[Waiting]]

I could then find a list of Tasks which violate the validation condition - i.e., which still hold #[[Waiting]].

Compound values

Some knowledge graphs use compound values, which are attribute values that hold a more complex relationship than a single integer. For example, the three-way relationship between "[[John]] married [[Jane]] on [[June 1, 2020]]".

This might be useful for attributes. My task status might look like this:

Bug status:: #Open @ [[May 13th, 2020]]

This means that on May 13th, 2020, this bug was open (as in, not solved). It would be nice to be able to encode this into the type system, too.

Other examples:

• # Share Joe's PCR report with investors
  * Type:: #[[Task]]
  * Task status: #[[Waiting until]] #[[Joe finishes his PCR report]] @ [[May 13th, 2020]]

  # Buy equipment based on Joe's PCR report
  * Type:: #[[Task]]
  * Task status: #[[Waiting until]] #[[Joe finishes his PCR report]] @ [[May 15th, 2020]]

  # Joe finishes his PCR report
  * Type:: #[[Blocker]]
  * Blocker status:: #[[Open]] @ [[May 10th, 2020]]

• Task status: #[[Waiting]], looks like I need more time to wait for the visa @ [[May 13th, 2020]]

Additional context

Example how a task looks in my database:

# Get a luxmeter

* Type:: #[[Task to obtain]]
* Task status:: #[[Not a priority]] @ [[May 13th, 2020]]
* Tags:: #[[Sleep]]
* For measuring my sleep conditions

Links to how other knowledge databases do it:

• https://developers.google.com/freebase/guide/basic_concepts
• https://www.wikidata.org/wiki/Help:Data_type

WikiData allows editing entities online, and maybe some of the UX of it (or of other such databases) could serve as an inspiration for how to get the UX on this right.

Having a strong enough API (https://github.com/Roam-Research/issues/issues/145) would enable people to implement this themselves.

[Stvad]

a kind of related discussion from metaroam: https://roamresearch.com/#/app/metaroam2/page/kbNts7gyA

[monaddle]

This also seems crucially important for using multiplayer roam to build a unified knowledge graph. I have a long standing amateur interest in scientometrics, and In my own graph I'm building out a map of scientific articles relevant to my interests, and including stuff like authors, publication date, and associated institutions.

If people were using a unified schema to describe people/publications/institutions, then joining authors and doing computation within and across graphs becomes feasible and interesting. Indeed, you imagine that authors themselves would have some incentive to publish their CV/publications in Roam, so that others could more easily cite and use their work, and in that way incentivize people doing research to more effectively document their work and make it accessible.

No doubt things like this have occurred to the Roam team, but it seems particularly important to me, for people doing both research as well as "power users" who want to do BI-type work.