From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 8N3tLxtg6mPL6wAAbAwnHQ (envelope-from ) for ; Mon, 13 Feb 2023 17:06:51 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id APGdLxtg6mP3VgEAauVa8A (envelope-from ) for ; Mon, 13 Feb 2023 17:06:51 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F25596481 for ; Mon, 13 Feb 2023 17:06:50 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=T+yW30+J; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1676304411; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=u6Yp7S1+kgGhwiskS2jFQ8W+nz/dLR7RUmbZenXfGUQ=; b=crdebC2H3URlT0YDXmY2+GlQdBVqBMtbWbx7FBhhHT1G4j1bKgVMZ9EqNYipquOjj7FR+S rg+rLrz5xfE5Ke8rpt7Lou+h7pZjlaxYzsZbbxGQAtl5HDeNxLVdmrQDSxJfdotojkQytH zHU0PpxWxGuHYpNTB/TnDuAAKT5eQBWGeJMstmqw4W1CEVQ6MWWz+yhz7gU9rIBsS9Vss1 TQUTQc4WyqYvZrUJZtcDDw1VizCvUIpDqpPia4jE9lsAfeG3tPNNoyPY35RA96SQaa/ct3 1/QJzPHsLJC/9eL2VMTV22v9kd1H0JmAEhC8Li0mFX3boXXSpYGGkf2+9adA/A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=T+yW30+J; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676304411; a=rsa-sha256; cv=none; b=EQOxC7hpvi3pXjQeUA3K8nDRLjaXeHwdipBa5DI1CDvv0T1l7cyjaQO86REvdoEW137ajE FRnKEJ0fi3GrP6q22S47/ponCPciC/sjTRHxa7FOLNCCroJ4/z1Qm3+LaYuT72Tbgj/AWM T9vnOyT/IyhkvFRyeSILYBbpbAUQWJApXYU95PSax//+qsdZRInPrb3Jcx39jY44wwMASh q8139CbLypROmG0v97s2TE2YbMb/icdZlPc9BWjujl0N2JRgAQwlRemIIFvvaLYv6B69Ci F+LcO+4MrO/hGK6gYBbi2JEVovuDHWhGf62Hu+Lx4Gt3GhB6BH0kGsxxqDjziA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRbL8-0003Jt-1S; Mon, 13 Feb 2023 11:06:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRbL2-0003I3-OS for emacs-orgmode@gnu.org; Mon, 13 Feb 2023 11:05:56 -0500 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pRbKz-0004AF-US for emacs-orgmode@gnu.org; Mon, 13 Feb 2023 11:05:56 -0500 Received: by mail-ej1-x629.google.com with SMTP id qw12so33135435ejc.2 for ; Mon, 13 Feb 2023 08:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=u6Yp7S1+kgGhwiskS2jFQ8W+nz/dLR7RUmbZenXfGUQ=; b=T+yW30+Jdb1HzaT9krrecPa3g5S18QUKb03oLufkW70R2t3z+dkRXRfam5In+h7W7Z 88jatue3Idf3jMTvoXN9FQrlif6NhJDi8feCsr0VqCNY+9NirWB85SCZ3YATPc0vLM5h rolhtZEWEP0W83jfLIiokXfb+Synt5mPelR+a3C/Xrn6nxE2/lcKHRaKRcT5v5Hv7t2B noH97L7P7z8BDHhOPB9KfmozYo+9KsM8zNRXZAeK+ODpthkX+kImZUmFoSKRZzLmRq6E dCYmBnlE+Fzp9eKpFDUy9SX0Epfe+DBQnXw9ExBBIgPDjbPNCAeTi7KvwNefkkMVA6Jo Ur2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=u6Yp7S1+kgGhwiskS2jFQ8W+nz/dLR7RUmbZenXfGUQ=; b=70JJDTMt9gKcwmY+5eKSBOfWrSVTAK9JjwI6MVmDXf3AetMc4gJMWAtyckBF4bcMDK HPy9DhyNoUwctD2/4BNBlmgDy2QtOsh+pOOnYbKKdrTW4OwJFYB2Ka+CHhoyU8wGJ8+A M87W9UJQR/CsvMK/KiTztHmHPvtcgnS2Be1oBAb3DxswjfXADf/5fe3tGhvXhsDu+wGX /3ZWzqaqMKTUQLoMHPK/BwJ6KXiC056p8HHFPewIKq16sFv/msAMyLzXgstfeT/AkIDP 3FcFZWiMt+5JX4soDYPFIFicyys8PpcQzbONhdNS2WW6oZiZg+XrP4iZy3Pr1qhPHB6q 37kQ== X-Gm-Message-State: AO0yUKWjPiKL232w94AGfWgZJdVglsr3b47yQnRlkvW2RBmZbLNLGx1I WtVWAxBbeSL3l2BqQxXuHxKmt/6IOvq+AnqVhMY3wCWBo7hOO3+C X-Google-Smtp-Source: AK7set/ijWMWsvwgfifIh5drg+bbKH5c+U3cTPSjX/25HSjqAJy8VIcZOlPzO/PKzD/SHh3/227jLKtbXvmNMWKJmOk= X-Received: by 2002:a17:906:3a8c:b0:8a6:5c06:dedf with SMTP id y12-20020a1709063a8c00b008a65c06dedfmr4637197ejd.12.1676304350413; Mon, 13 Feb 2023 08:05:50 -0800 (PST) MIME-Version: 1.0 From: Cletip Cletip Date: Mon, 13 Feb 2023 17:05:39 +0100 Message-ID: Subject: Link type in org-mode, but with org-roam ? To: Org Mode List Content-Type: multipart/alternative; boundary="00000000000057853b05f49705b3" Received-SPF: pass client-ip=2a00:1450:4864:20::629; envelope-from=clement020302@gmail.com; helo=mail-ej1-x629.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: X-Migadu-Queue-Id: F25596481 X-Spam-Score: -7.12 X-Migadu-Spam-Score: -7.12 X-Migadu-Scanner: scn0.migadu.com List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-TUID: NSKj76e/1G6t --00000000000057853b05f49705b3 Content-Type: text/plain; charset="UTF-8" Hello everyone. I apologize in advance for : - my org-mode philosophy (my ideas may be totally stupid, meaningless, or even contrary to the original org-mode philosophy) - my knowledge of the mailing-list (my mail may be badly organised, badly indented, the code unclear etc) - any other point that might irritate you because of my lack of knowledge of certain things - the length of this mail - for my bad bad bad english I'm going to get straight to the point and try to be as concise as possible, just for context: I've been using org-mode every day for at least 2 years. I want to make it my personal knowledge/information manager. I understand code relatively quickly, I understand less when it comes to writing it. I've done a lot of research on note-taking methods... well, you can see my profile I think. So, my goal: to make a concise system with org-mode, org-roam, org-attach, org-agenda etc... a "classic" goal for some of us :). I won't describe any of the tools mentioned here, it would make the mail much too long. The problem: need to make "queryable" notes to do more or less complex operations. For example, run the code of all headings/notes that have the tag "ubuntu", to allow me to reinstall my computer for example. This problem is trivial to solve with tags (a simple "dolist" is enough), but tags will not always be enough... So you need to be able to store "value-key" data, in order to make "select me all the people with a phone number starting with 06" queries. This works perfectly well with this: https://github.com/d12frosted/vulpea#metadata. This gives things of the following conceptual form: note1(where the metadata is stored) -> relationship -> note2/OrValue. What is stored in the database must be only the IDs (not the titles of the note for example), but the description is there for the user. This allows not to have a controlled vocabulary: when searching, we look for a note id, and not a string. On the other hand, what is displayed to the user in the notes is the description, which is very practical. note1 is therefore the id of a note (in the org-roam sense). Relation is the id of the "metadata"/type of the desired relation. And note2/Value is the value of the relationship, which may be an id of another note or just a value. In practice, it is therefore in this form: - [[id:20230112135328669948][Name you want, but respect the idea of the concept behind the id]] :: [[id:20220617105453042719][Another note]] - [[id:20230112135328669948][a metadata only with a value]] :: just a value The concept is close to the "In-Buffer Settings", with a "#+": it's a key-value. Except that In-Buffer Settings, org-mode can't understand that there is a link or something else, org-mode understands just a string, which will be parsed to modify org-mode's behaviour on that file, or for a export, etc. Concrete example: if I want to store all my music (eache music = a note with an attached file), I have two choices: - I put the tag "music", in the org-roam sense (i.e. "#+filetag: #music") for each note. - But, this amounts to writing: aMusic relation(here, "tagged with" for example) note2 or in practice: - [[idOfTaggedwith][tag]]: [[idOfTheConceptOfMusic][music]]. So we can make the following request: give me the notes with the metadata "idOfTaggedwith" with the value "idOfTheConceptOfMusic" (because, I remind you, only ids are stored. Just make a convenient interface for the user, and he won't even need to think about ids). Conceptually and omitting the other usefulness of In-Buffer Settings, it's exactly the same thing. Furthermore, I think this problem is part of a more global problem: they are "typed links". They can be called by many names: link tags https://org-roam.discourse.group/t/add-link-tags-feature/171, link types, relational links, etc. If someone has the "right" name to describe this... And therein lies my real problem: I haven't found a single good solution to achieve this. This problem is mostly related to org-roam, but org-roam is based on org-mode, that's why I'm writing here. I thought of the following solution, so I'd like to have some opinions. Main idea: make a link type that would be recognized not by "X:path" with X = link type, but by a regular expression, where if X respects a certain format, it is recognized as a relationship. As you know, external links can be of the form "X:path", where X equals id, file, gnus etc. Note: Org-roam stores all types of links. So we can make the following type of links: [[A:B][description]] where - A is the id of a note known by org-roam - B is the id of a note, or string, or numeric value, etc - description is a description (what a precision) This allows org-roam to store the type of the relationship, A, and the value of the relationship, B. So we can make queries like: "all notes where idOfTaggedwith = idOfTheConceptOfMusic". Implementation (functional on my side. It took me a lot of time, because I didn't know the org-mode code. But it's done without too much difficulty I think, as it's a link addition). : - modification of org-element-link-parser (yes, I dare to modify this. Tell me if I'm doing it right or not), origin of the link type detection. Put a condition before the "fuzzy" type, which would detect with a regular expression if the type matches an id. This could be : ((string-match regex-of-an-id raw-link) (let ((type-path (split-string raw-link ":"))) (setq type (car type-path)) (setq path (cadr type-path)))) - modification of "usual" functions (export, follow, open etc) - org-link-open searches last for dedicated "fuzzy" function in custom links. So we can add a condition before with the following idea: ;; check if the type is an id for relation-id ((pred ((lambda (type) (string-match regex-of-an-id type)))) ;; ask for the link of the relation or the destination (if (yes-or-no-p "Open the relation ?") (org-id-open type nil) (org-id-open path nil)) ;; here case of fuzzy link The other cases should be taken into account, if the "path" is not an id, but just a value, or a value + a string - Other functions I didn't do, but not unfeasible. Some problems arise like : - org-mode "fits" org-roam, and not the other way around. On the other hand, if there is a real use for this kind of link, then org-roam would be the one to adapt. (Because a relationship is defined here by a note... which is an org-roam note. But that could be a simple id generated by org-mode... I don't know. Relationship are perhaps not so necessarily id...) - My implementation requires a modification of org-mode, which I think is not normal. I think it's better add a layer of code with another package. In summary, I have several questions: - is my idea bad? If yes, why ? - I'm sure some people have already thought about what I've done. Is there an implementation already done ? - How to make this implementation without modifying org-mode, but only org-roam? Overwritten functions with modified functions? Like with this example: (org-link-set-parameters "id" :follow #'org-roam-id-open), where org-roam-id-open is defined in org-roam. - is there another solution to my main problem: making my notes queryable ? - Some people often have subjects related to this type of question (I think in particular of a certain "Jean Louis"): have you found better solutions? I thank you in advance for reading me, and thank you very much in advance for your answers. --00000000000057853b05f49705b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone.

I apologize in advance for :
- m= y org-mode philosophy (my ideas may be totally stupid, meaningless, or even= contrary to the original org-mode philosophy)
- my knowledge of the mai= ling-list (my mail may be badly organised, badly indented, the code unclear= etc)
- any other point that might irritate you because of my lack of kn= owledge of certain things
- the length of this mail
- for my bad bad= bad english

=C2=A0I'm going to get straight to the point and tr= y to be as concise as possible, just for context: I've been using org-m= ode every day for at least 2 years. I want to make it my personal knowledge= /information manager. I understand code relatively quickly, I understand le= ss when it comes to writing it. I've done a lot of research on note-tak= ing methods... well, you can see my profile I think.
So, my goal: to mak= e a concise system with org-mode, org-roam, org-attach, org-agenda etc... a= "classic" goal for some of us :).
I won't describe any of= the tools mentioned here, it would make the mail much too long.

The= problem: need to make "queryable" notes to do more or less compl= ex operations. For example, run the code of all headings/notes that have th= e tag "ubuntu", to allow me to reinstall my computer for example.= This problem is trivial to solve with tags (a simple "dolist" is= enough), but tags will not always be enough... So you need to be able to s= tore "value-key" data, in order to make "select me all the p= eople with a phone number starting with 06" queries. This works perfec= tly well with this: https://github.com/d12frosted/vulpea#metadata.


This gives= things of the following conceptual form:
note1(where the metadata is st= ored) -> relationship -> note2/OrValue.

What is stored in the = database must be only the IDs (not the titles of the note for example), but= the description is there for the user. This allows not to have a controlle= d vocabulary: when searching, we look for a note id, and not a string. On t= he other hand, what is displayed to the user in the notes is the descriptio= n, which is very practical.

note1 is therefore the id of a note (in= the org-roam sense).
Relation is the id of the "metadata"/typ= e of the desired relation.
And note2/Value is the value of the relations= hip, which may be an id of another note or just a value.
In practice, it= is therefore in this form:=E2=80=AF
- [[id:20230112135328669948][Name y= ou want, but respect the idea of the concept behind the id]] :: [[id:202206= 17105453042719][Another note]]
- [[id:20230112135328669948][a metadata o= nly with a value]] :: just a value

The concept is close to the "= ;In-Buffer Settings", with a "#+": it's a key-value. Exc= ept that In-Buffer Settings, org-mode can't understand that there is a = link or something else, org-mode understands just a string, which will be p= arsed to modify org-mode's behaviour on that file, or for a export, etc= .

Concrete=C2=A0example: if I want to store all my music (eache musi= c =3D a note with an attached file), I have two choices:
- I put the ta= g "music", in the org-roam sense (i.e. "#+filetag: #music&qu= ot;) for each note.=C2=A0
- But, this amounts to writing: aMusic relatio= n(here, "tagged with" for example) note2 or in practice: - [[idOf= Taggedwith][tag]]: [[idOfTheConceptOfMusic][music]]. So we can make the fol= lowing request: give me the notes with the metadata "idOfTaggedwith&qu= ot; with the value "idOfTheConceptOfMusic" (because, I remind you= , only ids are stored. Just make a convenient interface for the user, and h= e won't even need to think about ids).

Conceptually and omitting= the other usefulness of In-Buffer Settings, it's exactly the same thin= g.

Furthermore, I think this problem is part of a more global proble= m: they are "typed links". They can be called by many names: link= tags https://org-roam.discourse.group/t/add-link-tags-feature/171, link = types, relational links, etc. If someone has the "right" name to = describe this...

And therein lies my real problem: I haven't fou= nd a single good solution to achieve this. This problem is mostly related t= o org-roam, but org-roam is based on org-mode, that's why I'm writi= ng here.
I thought of the following solution, so I'd like to have so= me opinions.
Main idea: make a link type that would be recognized not by= "X:path" with X =3D link type, but by a regular expression, wher= e if X respects a certain format, it is recognized as a relationship.
As you know, external links can be of the form "X:path", where = X equals id, file, gnus etc. Note: Org-roam stores all types of links.
S= o we can make the following type of links:
[[A:B][description]]
where=
- A is the id of a note known by org-roam
- B is the id of a note, o= r string, or numeric value, etc
- description is a description (what a p= recision)

This allows org-roam to store the type of the relationship= , A, and the value of the relationship, B. So we can make queries like: &qu= ot;all notes where idOfTaggedwith =3D idOfTheConceptOfMusic".

I= mplementation (functional on my side. It took me a lot of time, because I d= idn't know the org-mode code. But it's done without too much diffic= ulty I think, as it's a link addition). :
- modification of org-elem= ent-link-parser (yes, I dare to modify this. Tell me if I'm doing it ri= ght or not), origin of the link type detection. Put a condition before the = "fuzzy" type, which would detect with a regular expression if the= type matches an id. This could be :
=C2=A0 ((string-match regex-of-an-i= d raw-link)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((type-path (= split-string raw-link ":")))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (setq type (car type-path))
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 (setq path (cadr type-path))))
- modification o= f "usual" functions (export, follow, open etc)
=C2=A0 - org-li= nk-open searches last for dedicated "fuzzy" function in custom li= nks. So we can add a condition before with the following idea:
=C2=A0 = =C2=A0 ;; check if the type is an id for relation-id
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 ((pred ((lambda (type) (string-match regex-of-an-id type))))
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; ask for the link of the relation or th= e destination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (yes-or-no-p "O= pen the relation ?")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(org-id-open type nil)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(org-= id-open path nil))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; here case= of fuzzy link
=C2=A0 =C2=A0 =C2=A0The other cases should be taken into = account, if the "path" is not an id, but just a value, or a value= + a string
=C2=A0 - Other functions I didn't do, but not unfeasible= .

Some problems arise like :
- org-mode "fits" org-roam= , and not the other way around. On the other hand, if there is a real use f= or this kind of link, then org-roam would be the one to adapt. (Because a r= elationship is defined here by a note... which is an org-roam note. But tha= t could be a simple id generated by org-mode... I don't know. Relations= hip are perhaps not so necessarily id...)
- My implementation requires a= modification of org-mode, which I think is not normal. I think it's be= tter add a layer of code with another package.

In summary, I have se= veral questions:
- is my idea bad? If yes, why ?
- I'm sure some = people have already thought about what I've done. Is there an implement= ation already done ?
- How to make this implementation without modifying= org-mode, but only org-roam? Overwritten functions with modified functions= ? Like with this example: (org-link-set-parameters "id" :follow #= 'org-roam-id-open), where org-roam-id-open is defined in org-roam.
-= is there another solution to my main problem: making my notes queryable ?<= br>- Some people often have subjects related to this type of question (I th= ink in particular of a certain "Jean Louis"): have you found bett= er solutions?

I thank you in advance for reading me, and thank you v= ery much in advance for your answers.
--00000000000057853b05f49705b3--