2023/03/17 →
#
>

19:45

→
#
>

Now that I’ve separated out the public and private repos and I’m a bit more committed to moving forward with Logseq for my public notes for a while, I’m thinking about how to use properties and indicate relationships.

→
#
>

I would kind of like to figure this out earlier so I don’t have to do too much retroactive editing down the line, especially if I’m going to pull notes over to this new system slowly.

→
#
>

It’s essentially a debate between the convenience of using properties and the “pureness” of using the ->

→
#
>

The default would probably be to use the properties for “basic” things like indicating the date and location of a note, but then any “contextual” linking between notes would be done with the ->

→
#
>

The argument for going all in on the -> would be to put to the test the idea of building relationships through “natural semantics” supplemented by this one -> character

→
#
>

This would look like this:

→
#
>

Many restaurants in NYC are small

→
#
>

example ->

→
#
>

Mura is small

→
#
>

Authentic Szechuan is small

→
#
>

supports ->

→
#
>

Big cities have small restaurants

→
#
>

<- informs

→
#
>

I’ve been to a lot of restaurants in NYC

→
#
>

part of ->

→
#
>

claims

→
#
>

But this doesn’t give an example of a situation where I would be tempted to use properties. I think time, location, and general tags are the only things I would be tempted to use properties for.

→
#
>

Time and location are interesting, because they are data about the writing itself, not about the idea I’m writing about.

→
#
>

A “general tag” would essentially be saying: when I think about x it would also be useful to keep in mind y (in both directions).

→
#
>

This could be done with the following system

→
#
>

The real reason to use properties is to make it easier to process something so Hugo sees it out of the box…

→
#
>

Let me think about this…

→
#
>

Do I need tags to be visible to Hugo?

→
#
>

I don’t think I need tags to be visible to Hugo right now

→
#
>

Worth noting that Logseq is saving the created and updated time for each block, and those are visible to Hugo from my script.

→
#
>

So it’s mainly a question of tags and location, and whether I want the time to be visible at the top level.

→
#
>

Currently I like the idea of continuing the time as the text in a block that identifies a certain “session”. Then that session can be in -> a location.

→
#
>

Pretty happy with using the tag -> formulation as well.

→
#
>

At Wild East Brewing right now in Gowanus and they have a non-alcoholic beer on draft (<0.5%). Amazing! And it’s given a normal spot on the menu, and no hullabaloo when ordering.

→
#
>

They also have a 3.8% light pilsner.

→
#
>

Happy to see low alcoholic beverages gaining prominence like this. Can’t wait for 2% beers and the opportunity to just have “one” beer but sit in a bar environment enjoying 3-4 drinks.

→
#
>

Just noticed they also have a 3% smoked, Polish-style ale (Grodziskie). Great!

→
#
>

A couple remaining questions

→
#
>

Should I allow creating new relationships via reference (rather than on the page itself)?

→
#
>

Should I create a prefix for all the relationships?

→
#
>

[[example]] -> vs [[relationship/example]] ->

→
#
>

The reason I really like the -> is because it takes full advantage of the hierarchical nature of blocked writing. You can create a relationship in either direction (<- or ->), and you can create the relationship inline without having to navigate away from where you are.

→
#
>

In this sense, creating relationships like this is the most like writing natural language that I’ve seen.

→
#
>

Downside: it’s a bit verbose.

→
#
>

from 2022/11/21

→
#
>

Venue Idea ->

→
#
>

All the signs look like they’ve been repurposed from other things

→
#
>

Stop sign with “stop” crossed out and says “next customer”.

→
#
>

“Find your life partner here” with “Find your life partner” crossed out and replaced with “order”.

→
#
>

Came up with this idea at a Panera Bread, this is the photo I took.

→
#
>

Using Tana to model the core relationships…

→
#
>

Main relationships from Tana

→
#
>

is part of

→
#
>

this is equivalent to is a, but I think the part of framing should be the default

→
#
>

thinking about locations here

→
#
>

so I’m going to change the is a to part of above (except locations where I already used part of)

→
#
>

is connected to

→
#
>

instead of using this, I’m just free-handing all the relationships as I like, I guess

→
#
>

If part of is the core semantic relationship, then I can worry about extracting that in the script first. This part of semantic relationship can be surfaced in more places (maybe in the header), and the other relationship types would remain different sections of backlinks (for now).

→
#
>

This is my initial thought. More to flesh out here.

→
#
>

Been doing a fair amount of work thinking about what My Principles are over the last week.

→
#
>

A possible Methodology for choosing your principles

→
#
>

What types of people do you care about?

→
#
>

Contains “should”

→
#
>

Divides the world into right and wrong

→
#
>

Should be opinionated enough that not everyone agrees.

→
#
>

One thing I want to do is fine-tune an Open AI chat model using all my notes and then enable a chat bot that can have a conversation with a user like it’s me (or at least, my public notes).

→
#
>

This might require me writing the “question that each note is an answer to”, i.e. the prompt for each note

→