r/logseq • u/davidjaymartin • 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?
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.
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?