- 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.