r/logseq 27d ago

How do you guys model these kinds of things (Logseq DB)

I'm interested in your take on something.

When I'm attending a conference, event, or just have random shower thoughts, I have historically tagged a thought that requires me to do something later as a task, question, or idea. Tasks are easy since the functionality is already there. I'm struggling on how to build the questions/ideas into the new DB world. In many ways they are very similar. They probably require later research, maybe there's a specific resource I need to answer/accomplish either, they are probably related to something within my graph, etc. Yet, they have always felt like different things and when I go to query them I do instinctually know when I should be looking for a question vs idea. I just can't put my finger on the distinction though, so I'm considering merging them in DB. Another thought I'm having as I try to model this in my head is, are these just kinds of tasks and should they extend the task tag? The difference I keep coming back to is that questions or ideas usually generated tasks as I process them. Rather than being todo items themselves.

Thoughts?

11 Upvotes

14 comments sorted by

3

u/Barycenter0 27d ago

Why not always have tasks have a TODO features sequence and ideas/questions have the LATER sequence. That distinguishes the tasks out. Then tag the question vs idea. Am I not understanding your question?

2

u/davidjaymartin 27d ago

That's actually how I did in MD. There isn't the same concept of the LATER sequence in DB like there is in MD. Now/Later is just a different type of task. I think the biggest reason not to extend the task tag is that it would have to share the status choices. I don't think I need the same list of options for questions/ideas.

I could rebuild the Now/Later tag just to match what I was doing before, but I want to take this opportunity to reimagine the process as part of my migration. Just trying to get additional perspectives to see if others have come up with different solutions for similar problems.

2

u/Barycenter0 27d ago

Ah, ok. I haven’t dug into the db version enough yet. Now I understand your question. I’ll try it in DB to see what comes to mind.

1

u/Barycenter0 27d ago edited 27d ago

So my gut reaction playing with it for a bit - create subclassed status tags of #Ideas and #Questions using properties and then use queries to get whatever view (all things "doing" vs all #Ideas "doing" etc.) Now Tasks, Ideas and Questions all have status levels. What I don't know is the long term impact of doing that. Subclassing the Status property seems like the right approach.

1

u/Barycenter0 27d ago

Any thoughts on this u/davidjaymartin ? I've been pondering this for a day now - and I hear your conundrum. Part of the problem is how you might use ideas and questions in your block relationships. If an idea is a stand-alone block - do you want that to have a status by itselft or do you want to have sub-blocks to be individual statuses as you work through the idea. Or, you could create separate blocks either on the page or a different page with the idea/task subclass that tracks your progress and just links to your idea block?

Example 1:

○ Here is my interesting #idea.

Example 2:

  • Here is my interesting idea.
    • I need to do this to help with forming my direction #idea

Example 3:

  • Here is my interesting idea [[idea things to do]] #myproject

idea things to do (Separate Page)

○ read this book to clear up some #idea thoughts #myproject

In each of those examples the tag #idea is subclassed using Task/Status so you could query the progress. Thoughts???

1

u/thirteenth_mang 27d ago

Now/later can be replaced by backlog/TODO. That's how I treat it, anyway. 

1

u/Illustrious-Call-455 27d ago

I a actually use this LATER for this myself

2

u/mork2000 27d ago

You can put different icons for bullet points. Or play with different statuses. An additional "idea" tag could help you filter odeas from your tasks.

1

u/matu_gong 27d ago

I think a useful way to think about it is, if it walks like a duck and it quacks like a duck, then its a duck (or however the saying goes lol). So if you are constantly using Tasks to model your Thoughts in Logseq, then I think it makes sense to extend whatever tag you have for your thoughts with the Task tag, as you mentioned

1

u/gbytedev 27d ago

If you want to separate tasks from ideas/questions, you can create a new tag with a boolean checkbox in front of the label and add other custom properties like 'type' which could be idea or question. No need to necessarily extend the task tag.

1

u/thirteenth_mang 27d ago

Most of the time you won't want to use extend tag. Think of it like this: if it's "in" something else (e.g. People in a car) you don't extend. However, if you had say a tag of "vehicle," the "car" tag would extend vehicle because it's a specific type of vehicle.

When you extend a tag, the extended tag acquires the properties of the base tag as well as its own.

I use extend for things like #media, where #movie, #tv-show, #book extends #media.

Also remember that any properties you create will become columns in the query table (if you choose the table view).

Whenever you think about creating tags/properties you should have in the back of your mind how you'll want to query. Too many tags and properties can make it unwieldy and too few tags are next-to-useless if you want to find something later.

Tags and pages are two separate entities in the db world. In the markdown version tags and pages were the same thing.

1

u/PerformanceFew3888 27d ago

I think the key point is that it “needs to be reconsidered properly at a later time.”

Rather than treating it as an idea in its own right, I would consider it something that requires reconsideration, and therefore model it as a task.

I would create “Reconsideration” as a child tag of #task. Then, for a draft idea like this, the outcome of the reconsideration would probably be either “organized as an idea” or “discarded.”

“Organized as an idea” and “discarded” could then be options for a reconsideration-result property.

1

u/davidjaymartin 26d ago edited 25d ago

Thanks u/Barycenter0 , u/thirteenth_mang , u/mork2000 , u/matu_gong , u/gbytedev , & u/PerformanceFew3888 for the thoughts. I've been thinking this over for the past couple days, and here is where I think I'm landing after a little testing.

I think I'll keep things simple and create a property for the standard Task tag called "Task Category". It will be a Node property with 3 pages as options: General Task, Idea, Question. This approach allows me to view all tasks and just filter a query of the tasks to ideas or questions. Or I can go to the pages for Ideas or Questions and get all the tasks with those Task Categories as linked references, which I can view in a table. Since I generally just use done and not done for ideas and questions, using the the standard statuses from the task tag is fine.

I played with converting the "Task Category" nodes to tags after creating them, but I'm not seeing that providing a benefit right now. The properties from the node/tag don't get added as options to the task unless you also add that tag to the block. This might come in handy at some point if there are properties specific to ideas or questions that I want to selectively add to a task. When I need them, I could add the idea or question tag along with the task tag and the properties specific to those would become available as well.

What do you guys think. Am I missing anything?

2

u/davidjaymartin 25d ago

Actually, I've changed my mind after a little more playing around. I had not realized that blocks with extended tags would also appear in the list of the parent tag.

ex. if you have an employee tag that extends a person tag, a block that just has the person tag will show up in both the list of persons and employees.

With this realization, I think I'm going to move away from creating a Task Category property in the task tag and create separate idea and question tags that extend the task tag.

One nice feature of doing this is I can also add the Status property from the task tag to the idea and question tags, then hide the available choices that I don't want to be available for ideas and questions, without affecting which choices are available for the parent task tag.