Semantically meaningful links, e.g. [[providesEvidenceFor>Climate Change]]

Feedback Feature Requests
1

Not all links are the same. Sometimes one note supports another note, other times it refutes it. It should be possible to intuitively add semantics to links in Logseq. This would raise the expressiveness of the app to a new level. For example:

A page describing the relation supports:

# providesEvidenceFor

type:: relation
inverse:: corroboratedBy

Its use in another page:

# Some New Research Paper

Blah blah blah [[providesEvidenceFor>Climate Change]]

When typing inside the [[ ]], auto-complete in the pre-> section would be limited to pages with a type:: relation property. In the post-> section, auto-complete would behave like normal.

Then, in the Climate Change page, there should be a new section of references at the bottom of the page:

# Climate Change

blah blah
blah blah

---

Linked References

Unlinked References

Corroborated By
  Some New Research Paper
        * Blah blah blah [[providesEvidenceFor>Climate Change]]

Hope this makes sense.

Rory

2

The concept of course has value in the context of knowledge graphs but I don’t see why adding more syntax i.e. this could be implemented using existing block properties:

# Appleseed Theorem

implications:: [[Appleseed Lemma]]

# Cold Fusion

evidences:: [[Coherent Quantum Electrodynamics]]

and so on.

Though defining a relation as the inverse of another one is interesting and somehow covered.

1 Like
3

Still, defining a way to embed semantics, as in RDF, could be useful Semantic Markdown - Annotate your markdown content

4

There is a structured way to define and enhance relationships between blocks/knowledge items, its called a discourse graph. Leveraging such a graph can make knowledge synthesis a lot more efficient and can help represent complex knowledge ecosystems such as scientific literature or debate on a given topic. Knowledge synthesis: A conceptual model and practical guide · Open and Sustainable Innovation Systems (OASIS) Lab

here is a feature request to bring this functionality to logseq Improve Graph View: Relationship Types, Link Styling and Graph Parameters like in Cosma

1 Like
5

Ooh, I think I might have duplicated this over here: Attributes/properties for links/relationships . Will close that one and copy my comment here.

It would be cool to be able to have attributes on links between pages, in a way that could later be used for mapping the data in the graph (e.g. via export into Gephi, or perhaps via improvements to the graph view page)

Links could have two basic attribute types:

  • A “type” that defines the type of relationship the link represents
  • Arbitrary key=value pairs that define relationship attributes

Using some special character to delimit the sections, perhaps something like:

[[Target|Relationship-type|param1=value1]]

So for example, on the Person A page, you might have a link like:

[[Company Z|works for|start-date=2024-11-13]], which would say that "Person A started working for Company Z on 2024-11-13`.

This format is perhaps not ideal in that it doesn’t read super clearly, because the predicate is after the object/target, but it has the benefit that you can leave components implicit, e.g. leave off the parameters section, or leave off the relationship-type (implying a “normal” link).

This would be very useful for e.g.:

  • Filtering the graph view by relationship types
  • Using relationship parameters as edge-properties in graph view.

Both of which can potentially allow much more informative visualisation.

These types of relationship-properties can sometimes be stored as properties on the subject/object page, but not in the general case of many-to-many relationship graphs, see e.g. Attributes to Relationships in ER Model - GeeksforGeeks

Obviously the proposal above is A solution, not necessarily the best solution. I guess take it as a partial attempt at problem definition.

6

IMO this would be a an immediately useful implementation, but not ideal. There is something valuable about having the relationships embedded in text that adds context. I think it can provide a trust backstop (i.e. by providing info on the logic or the source of the relationship). A method that allows attributes on the link/relationship itself might make that even easier, while also allowing for more nuanced information (e.g. giving the relationships weights or dates).

However, your suggestion does seem to be possible right now, which is interesting because it means that it could potentially already be used for visualization. I guess a simple way to do this might be something like:

  • Create some arbitrary block properties
  • Find all block properties
  • Perhaps associate child block properties with the parent page?
  • Filter out built-in properties (or perhaps write a black- or whitelist of properties you don’t/do want)
  • Export relationships to e.g. CSV for visualisation in Gephi or some other graph viewer.
7

YES +1!! I have worked on something very similar professionally, and would love to see this in Logseq since it would deepen much more relationships and knowledge stored. But wanted to chime in, definitely a topic of high interest for me!

It would be so useful to qualify links with, for example:

  • numbers (example a recipe is 40% protein, another is just 2% but high in glucids).
  • an article is 70% technology, 20% business and 10% others
  • a new toy is great for kids from 5-8 but dangerous for those under 3. But not for those with allergies.

just bogus examples to illustrate. It’s be great to be able to query & filter blocks with qualitative or quantitative. Yes this is a BIG thing, but could be done somehow with attributes in links & tags. It could be, for example, a simple set of user defined properties “baked-into” links: say a system of properties could be a user defined list:

  • ®T = Topic
  • ®Tt = Technology
  • ®Tb = Business
  • ®Tm = Misc
  • ®N = Nutrition
  • ®Np = Protein
  • ®Nl = Lipids
  • ®Ng = Glucids
  • ®Nv = Vitamins

Then a link to the post I mentioned earlier could be
[[Post]®.7Tt®.2Tb®.1M

Furthermore, links could (and should!) be hierarchical, meaning it should be possible to organize things in parent - child manners, such as with folders. I think this is the missing link (ha) in logseq, which would help transition more easily from file+folder ecosystems of notes towards a freer form which allows to (but does not forces to) structure things in hierarchies.

Blocks of knowledge could express much more if it were possible to bake in this kind of anchors.

8

Hmm wanted to edit a few errors but didn’t find how, sorry.

These ®.7Tt®.2Tb®.1M attributes would rather be in the block. So in turn, I could the query-filter blocks with say at least 50% technology, or recipes high in protein but not allergy prone, for example.

This would also open up to “dynamic” attributes. A prime example I’d like is the number of clicks to a link or block happened. I could use this to spot useless information, or that was forgotten. Or to get a word cloud of my “top tags or links”, which would be helpful to spot what I focused on lately.