Discussion: Unify pages and blocks

[venture-comp]

@jeroen_ophetweb

I thought the goal was to simplify and make everything work as much the same as can be … lose the tags vs page-tags and properties vs page-properties

Yes, intention is to just have blocks as atomic thought unit in the user interface.

It starts with the terminology: Instead of tag (which is only optical nature), page, page reference, block, block reference etc, I really would like to just simplify terms to “block” and “block reference” aka link to a block.

^{Btw: wouldn’t it be a great idea to call this app “Blocks”? Nice and simple to remember. Drifting off here…}

Main points in this request are to remove page-tags, page-property ambiguity and fix the link reference filter (bug reports). It also would be cool to use it as umbrella post for further discussion about general page-block-unification ideas.

@alex0 Option to treat specific blocks as pages reads like you are only proposing changes to the GUI graph widget by displaying blocks with their title:: property. Having read ongoing discussion, I think, you also mean to have block references as first-class citizens in the app in general, don’t you? So querying block references similar to pages now, displaying blocks by ::title as node in the UI graph, etc.

That indeed would be nice - and probably more far-reaching long-term - request. In a first step we could keep status quo, and consider only “root blocks” (former pages) to be queryable and displayable in the UI graph widget.

Also: As logical consequence, wouldn’t that imply, that we could have one syntax [[]] (or (())) instead of two for block references? If everything in UI becomes a block, we don’t need to differentiate between page references [[]] and block references (()) anymore - would appreciate that!

@alex0

@jonor

Why not reference pages with ID in the same way as blocks, and use aliases as labels, like in Wikidata?

Sorry but this doesn’t make any sense to me. [[wikilinks]] are much better than ((1234-5678-9012-3456-7890)).

IMO this is an internal implementation detail of how to provide technical IDs for blocks in the storage. I.e. it shouldn’t matter too much from UX point?

Without going into too much detail I would prefer:
All relevant blocks get technical IDs in form of UUIDs (including root blocks aka todays page, which currently have their title as ID). Hence no worries about duplicate titles when referencing blocks.
The first line of a block is its default title, with reference to following comment:

@tienson

1. Each block in logseq can have an optional title, for example:

Title (which is optional)
property-A:: value
property-B:: value (properties are optional too)
Body content (which is optional too)

::title could be a replacement for default block title. But I wouldn’t see it as flag for whether to display the block in the UI graph widget. What about a block property display-in-graph: true?