Structured Metadata/Attributes Input

Archive Feature Requests
#1

I want to be able to input metadata in a structured way.

Update Feb 2021:

This is a prerequisite for Table / spreadsheet functionality (when interpreted like modeling notion database features) and Ability to use logical operators for searching (Queries).

Roam seems to do it with :: as well. (I don’t know for sure, I never used it.)

Current State: RemNote Templates

Maybe this can be done with the current features already, but the obvious way using templates and :: is not satisfactory for me because it overlaps with the flashcard functionality.

Here is how it currently works (how I understand it):

  • A rem has 2 parts: the key|name (front side, before ::) and a value|content (back side, after ::) (named differently internally|in API).
  • Tagging a rem R with a tag T makes R an instance of type T.
  • All slots of T are suggested to be inserted for R.
  • If you insert a slot in R it is referenced automatically to the slot definition in T.
  • You are supposed to (I think) use this as the front of the flashcard, write :: after and add a value, turning this slot instance to a descriptor.
    • This always turns the rem into a flashcard which might not be useful. I don’t want to learn the release year of books or in which related keywords I have assigned which are useful for certain queries.
  • If this reference (or any reference unrelated to a template slot) is the last element of a rem, it is implicitly tagged with that reference.

The problem with this approach is that you can either chose to use :: to split the rem key/value and have a potentially unnecessary flashcard which clutters remnote.io/cards or not use :: but then you have to manually extract the value from the key later.

Is there already a best practice for this which I don’t know?

The semantically best thing for querying I can come up with be to use plain tags because they are not part of the rem text. But Sönke Ahrens #author is harder to read than Author: Sönke Ahrens.

image
image1176×565 38.7 KB

I have not used Roam queries so I don’t know if there are methods/conventions to comfortable query without a metadata/attribute format and do more powerful stuff than “show me all rem which contain those references”.

QoL: Multiplicity of slots

You can have a slot multiple times, e.g. for multiple authors or keywords. It would be nice if there was a for format to still have everything on one line. On the other hand you could just search like value.includes("search term") instead of value == "search term" if future queries support string matching. Not sure yet.

Sidenote on Querying with Templates

I have not yet made up my mind how to input data regarding how I want to query my knowledge base in the future. Using templates locks you into a hierarchical structure. For example if I would have two templates for #Book and #Article, both having an author then Book > author is different from Article > author and when I want to search for all author I’d have to create a union to find all authors. But then I’d have to know all types having an author (oops I forgot #Paper).

  • I could use tag inheritance and create a superclass #Publication with a author slot and tag/inherit like Book #Publication. Or go full overboard and have traits/mixins like #authorable.

    image
    image1261×513 37.8 KB

  • Or I don’t use the template mechanism at all and just paste literal templates (using a third party tool). Which reference a top specific rems of my choice (e.g. a top-level rem Author). But built-in templates are more portable when switching devices.

Any suggestions on how to use templates/references/tags to best prepare for queries?

#2

I like the directions you’re taking this. I have some ideas from my own use that might interest you.

  • I turn off practicing slots on the Rem as I encounter them in the queue or as I work with a document. It would be a quality-of-life improvement if slots on a type could be specified as practice, no-practice, practice-forward, or practice-backward, so that Rems tagged with that type inherit the default practice behavior. The default practice behavior could then be overriden.
  • I use multiline descriptors rather than multiples of the same descriptor. I would find a single-line variant of the multiline Rem useful. It would be semantically similar–maybe identical?–to the multiline Rem, but it would be displayed more densely.
  • I use universal descriptors where you are contemplating the use of mix-ins or traits. I even use universal descriptors as slots on types.
  • I hope to be able to query on the basis of slots with something like a drastically simplified SQL.
2 Likes
#3

+1 (no votes left to give)

PS I do have votes in both Tables and Logical Operators requests

2 Likes
#4

This video has a nice example of query usage in Roam (starting at 36:23). I would argue that RemNote has a few key differences, main one being the intended atomisation: if you ::, the part before serves as the name of the note when it is referenced and if you apply tags to the same block they will pile in the order applied and start to get hidden into an overflow thingie (+n tags) after 2(?..). This is nice for having a lot of weak links for zettelkastening stuff that can’t be fit neatly into a keynote, but awful for creating a lot of properties via tag. In my opinion, until full tables, or templates with selectors as in Notion, or possible source field overhaul, the only viable option really is to create separate simple templates, only with the stuff that you feel must be referenced or aggregated (so author ok, genre redundant) , apply the template via tag and apply tags about the content to the same block as the template tag (or place the block via reference into multiple keynotes). That way you will at least preserve the weak links and can reapply or reformat the metadata later.

2 Likes
#5

@Martin, I understand you guys are still working on an implementation for structured data (and tables/spreadsheets). Meanwhile, could you let us know how this is more likely to be implemented? That way we can already input our data in a way that is the most compatible with your planned system.

For example, I’d like to transfer my entire reading list (currently in an excel spreadsheet) into RemNote. How should I structure this so that I can later view this data in a table view? Using slots, tags, some other way?

Thanks!

#6

The graph view uses :: now as well to record named edges as disabled descriptors. So I suppose this mechanic is the semantic way/best practice to record data.

So I’d rephrase this request:

I want a feature to distinguish those “data cards”/key-value pairs which are permanently disabled and proper flashcards that are sometimes just temporarily disabled. I don’t want data cards to show up in both the queue and the cards table.

Suppose for example I have a folder about a topic containing both data cards and normal flashcards that is not relevant to me at the moment. I disable the flashcards for now. Later I want to revisit those concepts. I can not just enable all flashcards again because this also enables data only cards.

Workarounds/possible solutions:

  • Use only clozes for flashcards and reserve the CD-Framework for semantic data.
    • Requires a feature to set default practice direction, in this case to disabled.
    • Or being able to filter the Queue to practice only clozes.
  • Have another mechanic to disable flashcards temporarily instead of selecting everything and selecting disable from the toolbar. E.g. a power up tag to exclude a whole subtree.
  • Have an additional is_flashcard boolean property per rem indicating if it is a flashcard or or a data_card.

I think at some point flashcards also remembered their previous practice direction. This seems no longer be the case?

2 Likes