isn’t this graph a good insight for you to review the things that you read and note?
maybe it shows that you read too many unrelated random things.
too much noise maybe?
I don’t think a graph is bad per se. If a graph has an additional structure for navigation, it can be very useful.
The problem I see is with Logseq’s graph display only. This is a display issue, Logseq’s internal data model can already do what is suggested here, but the presentation is just not suitable to browse any larger number of tags without any structure.
If you look at the Zotero example on top (very first picture in this thread), the graph presentation is pretty but useless. If users need to get rid of information just to make the Logseq graph presentation usable, then something is wrong with the presentation.
A big part of knowledgemanagement is curating the information. Your example of a lot of random things could be handled by putting them in a suitable (poly)hierarchy to make the information findable.
1 Like
I haven’t read the entire thread yet, excuse me if I’m commenting on a trifle or something that has already been commented on, but for the sake of simplicity, in my opinion, and without going into the issue of visualizations or user interfaces, regarding the hierarchy of categories, I think that:
- Tag links should point to special pages where there is a template that references not only pages with the same tag, but also special category pages, like the page in question, that have been tagged with that category.
That would provide a taxonomic structure of categories and could perhaps be a good starting point.
Yes, exactly. In principle, Logseq’s data model already supports all of this. All we need is to give every tag page a couple properties (related, narrower, broader etc.) and this is all there is to it.
What is missing is a way to traverse the properties and display the results as a browsable tree.
@alex0 wrote a proposal to do so.
Ultimately some other UI/UX features would be nice, e.g. a way to easily access broader/narrower/related items, a tree view in the sidebar, a way to efficiently manage tags etc.
2 Likes
Great, then. Something that I would like to find, regarding, say, special pages, is something that visually differentiate them from, say, regular pages, in order to minimize the possible eventual confusion. However, I really like the concept that in Logseq everything is a block. In that sense, I would not treat special pages in a special way, beyond that it could include a predefined template, but easily readable and editable by anyone.
That is why I think that solving the issue of dynamic templates is a priority (allowing the templates to work as the macros work, by transclusion), and that the templates only make a substitution when it is expressly indicated at the time of being called. This is imperative to develop a modular model of structured knowledge, both for taxonomic structures of blocks, categories or properties, and to define concepts through semantic queries. Or simply to allow users to edit their templates without that meaning having to fix all the pages in which it was used before.
I will take a look at it, but right now that layer worries me less.
Of course, and once the base is solid and flexible at the same time, as well as scalable, the possibilities shoot and can be very creative and innovative, in this regard. Sure. And it is a very motivating field, I imagine. I myself, without going any further, can have many colorful and extravagant ideas about it, for being a simple jazz musician, but the important thing here, IMHO, is that these two aspects must be independent layers, that its architecture allows all those possibilities, but its not chained to any of them.
1 Like
After writing my last message in this thread, I have been thinking for a while and it has occurred to me that, since the meaning of categories is to determine the classes to which certain entities can belong, in relation to a given ontology, and that the classes allude to the fulfillment of certain properties or attributes; the act of categorizing an entity should entail the assignment of presumed properties to that class.
That is, tagging would, in effect, apply a template that will assign the relevant properties to the entity in question.
In this way, the structure is implicit and consistent with the ontology with which you are working on.
1 Like
@Didac I think the question that needs to be addressed is whether LogSeq is primarily an application for managing linked, unstructured text items that can be optionally annotated with loosely defined structured data (tags, attributes) or primarily a database of structured data, any record within which can be annotated with text. Your suggestion of tags constituting well formed classes is essentially proposing the latter.
The issue of classification ontologies has been discussed at length elsewhere, eg Knowledge Management for Tags / Tag Hierarchies - #16 by GaiusScotius. I still subscribe to the position that synonym sets and the relations beetten them should underpin any classification system that is intended to be both long lived and extensible.
On the issue of associating structured data with concepts (tags), my view is that LogSeq would do well to look at prototypical/ differential inheritance. This is the tack taken by applications like Tinderbox.
The concept is that a note may have a prototype from which it inherits attributes, including tags. It may then add new attributes and/or override inherited values and may itself act as the prototype for further notes.
In this model, tags provide the semantics of notes independent from the structure of any data that a user may wish to associate with notes related to that concept. “Root notes” — call them classes if you wish — define names attributes and default values. These act as prototypes for other notes that “inherit” their attributes and classifications.
Prototypical inheritance — sometimes also called slot based inheritance — is well understood and is seen in several programming languages including JavaScript, Self and Io. In these implementations, however, creating a high level object called, say, Person does not explicitly define what being a Person means. Adding a reference to a separate note that defines the meaning of Person would I suggest, be a very powerful extension.
3 Likes
I think the question that needs to be addressed is whether LogSeq is primarily an application for managing linked, unstructured text items that can be optionally annotated with loosely defined structured data (tags, attributes) or primarily a database of structured data, any record within which can be annotated with text.
@GaiusScotius At the moment, I find it difficult to rule out that this dilemma of “to be or not to be structured” is not a false dilemma, here.
I understand that, in any case, we are talking about a feature request that would make use of the Logseq Core Hooks and that would be located in one of the Plugin layers.
Because I don’t think it is on the table to change the architecture of Logseq Core or its Outliner Module, which already works with structured data and establishes the relationships between the blocks by determining their position in the graph
So, this point seems to be overcome, from what I understand, since the proposal assumes the infrastructure on which it is based. And both options can coexist, being not mutually exclusive, so I don’t see that resolving this issue is a prerequisite for moving forward.
Do you think that so far we could agree on this in general terms? Or, why do you think we should first opt for one or the other option? Because one seems to be an evolution of the other…
2 Likes
@brsma, just wanted to thank you for the clarification. This has been quite revealing to me. I’ll be thinking and reading about it for a while, for sure.
1 Like
Previous to Logseq, I’ve been able to manage close to 1000 bookmarks/things and 400 tags using a modified schema.org ontology. I wrote about it some at knowledge graph experiment · GitHub. I’m now taking a similar approach with Logseq graphs and can report back once I start getting close to those numbers in a graph. In the meantime, I’m happy to share that generating rdf from logseq graphs is doable with nbb-logseq/examples/linked-data at main · logseq/nbb-logseq · GitHub. With the example, a small portion of Logseq’s docs are able to generate rdf
4 Likes
This script converts a subset of a Logseq graph to an rdf file using
GitHub - rdfjs/N3.js: Lightning fast, spec-compatible, streaming RDF for JavaScript. This script is configurable viagraph-config
and by default will print a turtle file (.ttl) to the console. By default,
the subset of a graph that is exported to rdf are:
• class pages with properties ‘type:: [[Class]]’
• property pages with properties ‘type:: [[Property]]’
• class instance pages with properties ‘type:: [[X]]’ where X are pages with ‘type:: [[Property]]’
Could you please make an example of what you mean with the third point class instance pages with...?
1 Like
I made a mistake in that last line. It should be:
class instance pages with properties ‘type:: [[X]]’ where X are pages with ‘type:: [[Class]]’
For examples, see the backlinks at https://docs.logseq.com/#/page/feature and https://docs.logseq.com/#/page/ui%20element
I’ll also mention I’m a linked data beginner so there are probably more correct ways to model some of the relations e.g. more use of sameAs instead of url. For now I’m trying to strike a pragmatic balance with rdf output without sacrificing usability in Logseq
4 Likes