A meta-graph as a set of linked graphs

I found an interesting paper that takes this to the extreme.
A Type-Theoretical Approach for Ontologies:
the Case of Roles.

Honestly, I have no idea if such theory contributes anything useful, my guess is not. The Olog
I find the different types in Def. 4 interesting. They also implement relations.
Overall, the Olog paper by Spivak seems to be much more useful. I remember reading a paper on CQL, a categorical query language for databases, they had some categorical constructions that go beyond relational databases, but I don’t remember the details.

Wikipedia puts categories into their own namespace, so that is one fundamental difference to the Logseq model.

You are right about the blocks, of course!

A Type-Theoretical Approach for Ontologies:
the Case of Roles.

exploding-head_1f92f

Well, meanwhile (I have a lot of material to digest), perhaps it would be convenient to make a disquisition of what we already have implemented in Logseq. A more or less rigorous examination, considering each of its parts regarding this topic.

I hope you can help me to solve some doubts that I have and that this can also help others.

One issue that I think creates confusion is related to terminology. That’s why I think we could specify (or agree) what exactly we mean when we use certain words.

my thoughts exactly! I wish we had an information architect as part of the discussion (for real IA, not academic paperwriting). Many of these issues have been worked out a long long time ago, but there is a reluctance in the community to accept the solutions instead of reinventing an inferior solution.

1 Like

It has occurred to me that, for the discussion of terminology, we could start by defining what we could call ‘local variables’, to understand each other here, without having to worry about whether or not that definition would be convenient at a ‘global’ level.

@Didac How about this diagram from the other thread as a starting point?

93e7391a5c8768734ecda4ecf667d5e3473bff21_2_690x4111

1 Like

Yes, the concept is that, to build taxonomic structures from categories and properties. And then draw other maps with the relationships between those concepts and operate in that abstraction layer defining a data model.

However, as a starting point I would propose going deeper.

Personally, I mostly have questions, I am learning as I go. And the questions I ask myself, right now, have to do with Logseq’s architecture, whether or not it would be convenient to adopt a Three-schema approach [0] model, or to differentiate each external/conceptual/internal schema, also in the terminology.

[0]:Three-schema approach - Three-schema approach - Wikipedia

I didn’t want to talk about the taxonomy, I just wanted to use this sketch to illustrate the kinds of relationships that Logseq can encode and give names to the the concepts.

  • Should ⊂ the same as ∈ even though it violates our common understanding of categories, sub-categories and elements? Even though both point at page blocks, they are different mechanisms and could be made to point to different things.
  • Do we have separate namespaces for different concepts? Do we need them (as Wikipedia does for categories)
  • What is missing? Attributes for ⊂ or ∈ (something like [[isSon::QueenMary]])? Relations?
  • How to integrate with Namespaces? It might make sense to have categories and or tags with the same name in different namespaces, but is the complexity worth it?
1 Like

I wonder the same thing. I don’t know, because I’m still not clear about what parallels are convenient between the conceptual model and the physical model.

1 Like

From what I see, we have here an apparent dilemma between two types of approach. One from the perspective of relational databases vs. the graph database approach. And it turns out that both approaches make sense if you think about each from the perspective of their results. However, it is a fact that the logseq database is a graph, so doing a relational approach would require a middle layer. Same happens at the file level, where possible solutions are tied to the file storage model.

Without going into assessing which model would be preferable at the user interface level, if such a dichotomy really existed in that layer, I think that perhaps it would be convenient to separate three types of schemas in the Logseq architecture:

  • External schema for user views
  • Conceptual schema which integrates external schemata
  • Internal schema that defines physical storage structures

If I’m not mistaken, this model is not implemented, so it would be part of a hypothetical next Logseq refactoring and this debate would be part of the discussion regarding its suitability and the possible feasibility of its development.

People have brought this argument up in the past, but I don’t agree.
A relational database has tables that store relations. Data is often stored in fairly small chunks and is typed. Logseq doesn’t store tabular data, and doesn’t even support textual tables well.

A good example of a relational approach is Zotero, which allows pdf annotations just like Logseq, but stores the annotations in its SQLite database instead of in a text file. If you look at a note in Zotero, it is split into hundreds of little relations. This is not even remotely similar to Logseq.

Logseq’s isn’t that great of a “graph-database”, though, because it still lacks many of the features that graph databases (such as Neo4j or TypeDB) have:

Adding any of these features doesn’t make Logseq a relational database, if anything, it would make it a better graph storage.

Here is an example that shows that hierarchies are no stranger to graph databases:

So it should be pretty clear by now that HIERARCHIES ARE GRAPHS right? I think so :slight_smile:
Bruggen Blog: Hierarchies and the Google Product Taxonomy in Neo4j


Another example for semantic search using SKOS, which would be an amazing and natural addition to Logseq:

Here is a Neo4j example of with an edge, DRIVES, which itself has an attribute. Unfortunately these kinds of relationships can’t be represented cleanly in Logseq.


Now some of the features offered in graph DBs don’t make sense for Logseq, but it would be good to have a close look what could be useful.

The first things that come to mind are search functions for graph traversal to represent hierarchies, and the ability to give attributes to tags and properties, which would already let us express the DRIVES example above in a reasonable manner.

6 Likes

My intention was not to enter into the debate about whether such a dichotomy really exists or about which approach is better at the UX level, although these are topics that interest me and for which I really appreciate your comments about it and I learn a lot from them.

Actually, I was still thinking about the question of defining a terminology. And I found the three-schema approach software engineering model convenient, if only to conceptually separate a term depending on the view we’re referring to.

For example, when we are talking about the graph, there does not have to be a direct correlation between the graph as a representation at the UI level and the graph as a database in the view of the internal schema that defines the physical storage structures (in our case, in the RAM memory, in the browser, not in our file system that is an other interface).

Another example would be the concept of page. In the application, a view in which to consult and enter information does not necessarily have to correspond to the concept of a page from the point of view of the database, or to a file in our storage.

Although a file appears to correspond to a page in the DB and is viewed from the application as a page; a page in the application does not necessarily have to correspond to a page as it is defined from the point of view of the database, nor to a concrete file in our file system.

Although the use of the extrapolation of concepts based on homological parallelisms can be a useful resource as a cognitive tool or metaphor.

Now some of the features offered in graph DBs don’t make sense for Logseq, but it would be good to have a close look what could be useful.

Of course! I have yet to take a closer look at the Datascript library 0 and at the Datomic Data Model 1

The first things that come to mind are search functions for graph traversal to represent hierarchies, and the ability to give attributes to tags and properties, which would already let us express the DRIVES example above in a reasonable manner.

That would be a great advance.

In fact, my original proposal in this thread deals precisely with representing relationships in a metagraph (a dedicated branch within the graph or a namespace, i.e. a hierarchy), where the correlation is that each type of relationship is a node of the metagraph in which to define the concept and in which to list the nodes of the graph (pages or blocks) that must be linked with said relationship.

And having a visualization in the application as if it were an independent graph, I suppose it would help to see it more clearly, separating the concept of page from relation.

Absolutely agree!

I am looking for features that you listed!

I realised that properties does not solve issue of naming/coloring relationships! It has to be inline like normal links. Also directions of relation and other things! It would make life so much easier to navigate vaults for users being intense knowledge worksers :crossed_fingers:

1 Like

Named relationships are there through properties:: and with them you can have a storage model for everything you have listed, it’s just that there is no UI for that.

For example “edge properties” and “nested relations”[¹]:

Page.md
key:: value 1
subkey:: value 2

key.md
nested-keys:: subkey

Then with Datalog queries you can perform whatever you want including graph traversing. Everything is already in place in my opinion, what’s missing is just UI/UX so that it isn’t a pain to maintain for the user.

[1]: why do you mix so many synonyms instead of sticking to {graph, vertex, edge} or {network, node, link}?

See my previous comment above and here there is my proposal for inline properties:

Basically just [[key:: value]].

For me [[key::val]] seems good !

Even better if on backend we could extract it into triples!

Page [[person/John]], has link [[verb/likes::noun/fruit/Apple]] .

and then we have tripe: “[[person/John]] ----([[verb/likes]])—> [[noun/fruit/Apple]]”
ideal for further conversion e.g. for RDF triples!

2 Likes

Also it looks like @alex0 in

  • your proposal you suggest for support in [[key::val]] syntax without separating space after ::.

The more I think about it, the more I like it.
(i.e. to ideally support both - with space [[key:: val]] and without space [[key::val]].) . I recently even started tagging directories and files in my filesystem using #tag or [[tag..]] notation (still have to figure out how to use tag hierarchies, as / is prohibited on filesystems, but probably single : would be a work around !
That way

  • I could translate document [[verb/describes:: person::Alice]].md
  • into document [[verb:describes::person:Alice]].md ,

what has following advantages

  • I could use single : instead of / where / is prohibited
  • I could distinguish : from :: easily!
  • and removing space would allow me in scripting to utilize tags usually by just splitting by space !

Otherwise, even if without space syntax would be rejected, still I consider inline [[key:: val]] a huge improvement! (especially if triples (page, key, val) could be programmatically retrived => but if not logseq, then I guess doing external parser could do the job)

To be honest I didn’t pay attention to this detail, I guess it wouldn’t make much a difference.

/ is how you actually use namespace functionality in Logseq. Check my post with tips on when and how use this:

Logseq will save [[Parent/Child]] as Parent__Child.md on the file system, so no need to worry about it.

At the moment you can’t use : inside a key, but you can use namespaces, numbers and underscores as keys, like:

verb/describe_1:: value

In general keys must start with a non-numeric character and can contain alphanumeric characters and . * + ! - _ ? $ % & = < >.

If -, + or . are the first character, the second character (if any) must be non-numeric.

You can decide that one of those special character stands for “verb” and use something like:

>/describe:: value

This way when you visit the page [[>]] you will see the list of verbs like “describe” at the bottom.

1 Like

Thank you ! Yes, I already use ir extensively in my logseq graphs and it’s awesome!

My point is that I started using Logseq notation in my filesystem , so use same everywhere, e.g.

#2023/#bills/mobile provider [[Great Telecom]] [[bill:amount::12345]].pdf

So my point is that in filename I can not use “/” so using single “:” is very convenient and easy to convert later into “/” if importing into Logseq"tags"/“links” from filesystem with scripting. No change required, just sharing my trick how to handle this when “/” character is not allower (e.g. Linux filesystems) and that it will work with your proposal ! Sorry for bringing it up here, I should have put this side topic in another thread.

All the rest: looking forward !

And if skipping “space” after “::” in inline notation would be allowed (but not required) for me even better!

2 Likes