Relationship types (predicates) - Colored graph

[gww]

When on page e.g. [[Alice]] we make likes [[Apple]] and someone else e.g. [[Bob]] hates [[Apple]] on graph we see edges between [[Apple]] and those people but we can not distinguish relationship type, or filter out in graph view.

That’s why in RDF/Semantic web, things are stored not as binary but triples, that reflect structure of most human languages: “subject predicate object”.

We have already some notion of this in Logseq e.g. with alias::, which is like owl:sameAs ( sameAs - Wikipedia ).

I was wondering :

• what’s the easiest way to export all graph relationships from logseq as it is today into triples (with default predicate logseq:relationship) ? => somehow graph module needs to get it’s vertices and edges? How can I export them into text file, preferably from command line, programatically?
• second: wondering if would community be kind to accept extension to logseq semantics, to be able to express predicate beyond default logseq:relationship ? I dont know what would be best design choice of it (on page [[Alice]] ##likes#Apple , #likes=>Apple #[[likes][Apple]] or something else?), but some way to “color edges” , both, for mentioned earlier export (what would make it trivial to convert into RDF triples ), and potential future “edge filtering” in graph view - as currently we can filter by nodes, while I see a lot of value in potentially filtering by edges.
• another brainstorming idea - maybe fetching properties from text block would be helpful in coloring graph?

RDF: Resource Description Framework - Wikipedia

(bot requested me to edit this content)

[andrewzhurov]

Hi, I have come from a related post.

First off, I think that a great idea to have data alongside human-readable text of blocks.

Attending your wonders

what’s the easiest way to export all graph relationships from logseq as it is today into triples (with default predicate logseq:relationship) ? => somehow graph module needs to get it’s vertices and edges? How can I export them into text file, preferably from command line, programatically?

It seems you are aware already, there is an ongoing effort from Tienson to export Logseq graph in EDN.
EDN can be convert to JSON-LD and used with Semantic Web tools.

Also, there is an ongoing effort towards deriving immutable RDF graph out of Logseq graph, discussed in the same thread, but you are well aware of that too.=)

second: wondering if would community be kind to accept extension to logseq semantics, to be able to express predicate beyond default logseq:relationship ? I dont know what would be best design choice of it (on page [[Alice]] ##likes#Apple , #likes=>Apple #[[likes][Apple]] or something else?), but some way to “color edges” , both, for mentioned earlier export (what would make it trivial to convert into RDF triples ), and potential future “edge filtering” in graph view - as currently we can filter by nodes, while I see a lot of value in potentially filtering by edges.

It already possible to express triple semantics in Logseq, via properties. example
Refs to other blocks in text do not assigned ‘predicate’ to it, that’s a fair mention.
If we do want to have it, we could formally describe that relationship in properties.

another brainstorming idea - maybe fetching properties from text block would be helpful in coloring graph?

I like this idea. Coloring is one way to represent some semantics.
E.g., coloring edges of ‘loves’ in green and of ‘hates’ in red.
More generically speaking, we could create even more specialized views for semantics.
This is akin to moldable development and concept of Semantic Web where we can build custom views of some data.
And custom views are way more handy than a generic representation. (see the above link to get a glimpse)
Graph view that we have now is generic, enriching it with more custom views sounds appealing.

---

Thank you for thinking in this direction, takes us one step closer to having it.=)

[andrewzhurov]

A quick remark about similarity of aliases and owl:sameAs.

They are somewhat alike if from a glance.
However, there is an important distinction.
owl:sameAs represents semantics of “some content 1 is the same as some content 2”,
and these content could be blocks about “Logseq” in english and spanish, for example.
Aliases represent semantics “content1 can be referenced by name1 name2 etc.”. Such names can be many, they are user-level dictionaries. Some prefer to ref to a block about “Logseq” as “Logseq”, some may call it “logseq”, “lq” etc.
So aliases are not part of ‘content’, names we give to a thing does not affect that thing, e.g., it won’t matter for the Sun if we call it the Moon. There is an ongoing effort towards having it so in Logseq. Here is a glimpse of rationale for a curious mind.

[gww]

coloring graph

Clarification: Coloring edges in semantic sense.

I meant in Graph (discrete mathematics) - Wikipedia send of edge_coloring ( Graph coloring - Wikipedia ).

Therefore, not colors , but entities. In logseq sense to color edges with artibrary pages, like in rdf. Therefore, my examples.

Rendering-wise , I like neo4j approach, by putting text on edges:

Eventually this library on MIT license maybe helpful:

GitHub - eisman/neo4jd3: Neo4j graph visualization using D3.js

[gww]

@andrewzhurov

via properties. example

I’ve tried following:

$ cat p%2FJohn.md 
title:: p/John
likes:: [[o/Apple]], [[o/Orange]]
hates:: [[o/Spinach]]

In graph view is obviously not reflected:

We clearly see on picture that we can not distinguish between “likes” and “hates” relationships.

but maybe I don’t know sth. Is there a query that for pages like this I can generate:

| page_name | likes |
| p/John | o/Apple |
| p/John | o/Orange |
| p/Alice | o/Apple |
| p/Bob | o/Organ |

?

[gww]

cross linking, I see here @gax made a very good points:

A meta-graph as a set of linked graphs

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 …

[naught101]

Relevant and/or duplicate:

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

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-compl…