Feature Request: Tagging

[pramjan]

Hi,

If possible, implementing the below features would serve as a great benefit to the user:

• Folders for hierarchical note organisation.
• Zettelkasten ID prefixing for the note name (to create unique notes). This can be based on a unique timestamp prefixed in the filename, like other apps do.

[arkie]

• Folders for hierarchical note organisation.

While you can organize your files in folders within iCloud Drive, the UI is currently based around graph-based navigation to avoid required a fixed hierarchy. Can you go more into the use cases you're considering here?

• Zettelkasten ID prefixing for the note name (to create unique notes). This can be based on a unique timestamp prefixed in the filename, like other apps do.

The filename currently is a Unix timestamp, and can be seen as the linked local URL. Is the issue you're running into from naming multiple notes with the same title or something else?

[pramjan]

Can you go more into the use cases you're considering here?

I understand what you mean. Structures help humans categorise notes. This is usually done with folders or tags or both.

The filename currently is a Unix timestamp, and can be seen as the linked local URL.

Great! I didn't know this since I missed the fact that Markology simply stores files in .md format in the iCloud Drive. Is there a way then, to suffix the file's title (maybe the Header 1) into the filename? Then we'd have a way to identify the file based on name and when it was created, right away. Helps with organisation, and tracing the path for zettels on the same topic.

[arkie]

I understand what you mean. Structures help humans categorise notes. This is usually done with folders or tags or both.

Given the abstract context, I definitely agree that structure can help retrieval and comprehension - a core part of the design of Markology is to use a minimal number of such concepts to achieve maximal capability. As an example, instead of having a separate tagging system, we surface reverse links by default to allow using any note as a functional tag.

So far (per personal and user reports), this has avoided a multi-pass approach to categorization (either figuring out relevant tags or hierarchy) as well as increasing the flexibility in usage, and simplicity in interface. Something that may be useful is trying to do without the explicit directory structure for a trial period, and then reporting what doesn't work?

Great! I didn't know this since I missed the fact that Markology simply stores files in .md format in the iCloud Drive. Is there a way then, to suffix the file's title (maybe the Header 1) into the filename? Then we'd have a way to identify the file based on name and when it was created, right away. Helps with organisation, and tracing the path for zettels on the same topic.

Unfortunately, relying on the underlying files is something of a double-edged sword; while we can allow trivial import/export, we generally expect the filenames being immutable IDs already (which precludes using the first header within it). As an example of the issue, consider the following:

# Go ([Board Game](/1613291580.md))

<https://en.wikipedia.org/wiki/Go_(game)>

# Board [Games](/1608879824.md)

In this instance, if 1608879824.md was updated with a new header, then it would cause a cascade for not just the links in the notes pointing at it, but also the notes pointing at those notes, which would in turn potentially cause files not yet synced to point at non-existent locations, or otherwise cause conflicts on otherwise unchanged notes.

Similar to the previous note, I'd ask you to try using the built-in UI / linking for awhile, and see what the largest gaps are in the existing system. Part of the overarching philosophy behind our development is to have a simple enough modality to preclude some of the bespoke complexity implicit in more convoluted systems (as well as, of course, avoiding recurring subscriptions, advertisements, data collection, et cetera).

[pramjan]

Something that may be useful is trying to do without the explicit directory structure for a trial period, and then reporting what doesn't work?

Directories are a secondary concern, so its fine to drop this. I use tags much more often, simply because my note repository has hundreds of notes, from diverse topics (programming, health, gardening - you name it). That tag, helps me look at notes related to a certain topic. Without explicit tag management, I won't know what are all the tags I have, but if I know the topic - the search can look for the tags just as well, and its super fast at that! So can we have a sidebar area showing us the tags in the repository?

Unfortunately, relying on the underlying files is something of a double-edged sword; while we can allow trivial import/export, we generally expect the filenames being immutable IDs already (which precludes using the first header within it).

I understand what you mean, its fine to drop this feature. I will get back to you on this in case I find reasons to think its essential. Thanks!

[arkie]

I use tags much more often, simply because my note repository has hundreds of notes, from diverse topics (programming, health, gardening - you name it). That tag, helps me look at notes related to a certain topic. Without explicit tag management, I won't know what are all the tags I have, but if I know the topic - the search can look for the tags just as well, and its super fast at that! So can we have a sidebar area showing us the tags in the repository?

I can relate to having hundreds of notes across a broad set of concepts, but I think I'm a little confused on the suggestion. It sounds like you're describing tags as separate from linked notes, which isn't a distinction that exists in Markology today.

As an example, consider:

# Slaughterhouse-Five

[Kurt Vonnegut](/1632487894.md) [Books](/1609883123.md)

This functionally uses the links to the notes on the author / topic for all books as tags (via the reverse links) which in turn allows seeing either all books or other works directly (and other related concepts radially out from the related overlay). Whereas tags offer a more flat space, and generally don't allow expanding the concept used as a tag definition, notes-as-tags supports multi-level tagging hierarchies without needing additional primitives (one of the main reason for the prominence of reverse links in the UI).

In short, I'm hopeful to figure out if adding more functionality to link insertion / search to see if it can obviate tagging, which is why I'm trying to get at whether the issue is tag selection for filtering or adding or otherwise 😊

[pramjan]

but I think I'm a little confused on the suggestion. It sounds like you're describing tags as separate from linked notes, which isn't a distinction that exists in Markology today.

I will try give an example. Consider that I might have a couple of notes related to medicinal herbs and their benefits:

# Benefits of Ashwagandha

#ayurveda, #herb

<Content goes here....>

and another note for the benefits of consuming Moringa:

# Benefits of Moringa

#herb, #superfood

<Content goes here....>

Now, I might not directly link these two notes - they're independent of each other. Any similarities between these two herbs can be explored in another note, where there could be a reference to them both (and probably others). The tag "herb" is common between them, and hence tag search will list them both. Tags help cut down on the search results to find relevant topics more easily

I could search for "superfood" and Markology brings up the tag pretty quickly in the search result. But I can only know I have that tag if there's a tag browser of some sort. Search implemented along with tags is a great feature to have. My existing repo of zettels all have tags already, so this feature can harness what's already there.

If you think it's a valuable addition to Markology, please consider its implementation.

By the way, I'm yet to completely understand the "Notes as tags" feature you have described above. Will test this out to figure it out. Thanks for the suggestion!

[arkie]

By the way, I'm yet to completely understand the "Notes as tags" feature you have described above. Will test this out to figure it out. Thanks for the suggestion!

To update your example, it would essentially just be:

# Benefits of Moringa

[#herb](/herb.md), [#superfood](/superfood.md)

<Content goes here....>

(Note that the # in the name is just decorative in this case, and the body of the links would be timestamps if created in app. This is just using the tag names as placeholder filenames, although it should be fairly easy to extract and generate files with those names from your existing tags if you wanted to automate the conversion)

In this case, instead of having a separate namespace for tags, searching superfood would just return the note in question, and then all things tagged by it would be visible as reverse links (Linked From).

If you think it's a valuable addition to Markology, please consider its implementation.

Will do, and will update this issue to be a tracking issue for said same - and feel free to comment further if you try out using notes-as-tags!

[pramjan]

I've understood the method to use notes as tags. While its a bit more cumbersome to type out the note-as-tag syntax, I see that its easier to create the tag-note first, then link it in. And to get a list of all the existing tags in the library, simply need to type '#' in the search bar. It works as intended, so this is cool. Thanks for the quick support! I feel it is good to consider having the standard tags as a feature (it could be a sidebar section below "New" - something for "recent tags", and then on toggle, it could list all tags, similar to most recent notes/all) - first, it reduces the number of steps to insert the tag (either by creating the tag note, or not having to type the lengthier syntax), and second, there won't be any need to create actual, empty files.

[arkie]

it reduces the number of steps to insert the tag (either by creating the tag note, or not having to type the lengthier syntax)

Are you manually typing out [#example](/example)? If you use the Add Link, it should allow you to just type #example and then tap the entry under New to auto-create instead if so - otherwise I do agree it's not as fast as just typing without bringing up modal link insertion. I wonder if in-line link completion may be something to explore here.

It works as intended, so this is cool. Thanks for the quick support!

Thanks!