Feature Request: Support parsing link types from [[Note|Alias&Relation]] syntax

[Hobeom]

Thanks for your great work on this plugin! This feature would make Graph Link Types even more expressive and user-friendly in a graph knowledge workflow.

I’d like to request support for parsing edge types directly from the alias portion of Obsidian wiki links using a & delimiter syntax.

This allows users to semantically describe relationships inline, without requiring frontmatter or dataview fields.

✅ Supported Formats

Syntax	Display Text	Relation Type	Note File Target
[[Plato|Socrates&teacher_of]]	Socrates	teacher_of	Plato
[[Plato|&teacher_of]]	Plato	teacher_of	Plato
[[Plato|Socrates]]	Socrates	(none)	Plato
[[Plato]]	Plato	(none)	Plato

⚠️ [[Plato&teacher_of]] should not be parsed this way because & is valid in note titles.

Reference Implementation (Experimental)

I’ve extended the getMetadataKeyForLink() function to support this logic. Here’s the relevant snippet:

private getMetadataKeyForLink(sourceId: string, targetId: string): string | null {
...
for (const l of sourcePage.file?.outlinks ?? []) {
    if (l.path !== targetId) continue;
    const disp = (l.display ?? "").trim();
    if (!disp) return null;

    const ampPos = disp.indexOf("&");
    if (ampPos === -1) return null;

    const aliasPart = disp.substring(0, ampPos).trim();
    const propPart  = disp.substring(ampPos + 1).trim();
    if (!aliasPart || !propPart) return null;

    return propPart;
}
return null;}

This checks for outlinks with a display string of the form Alias&Relation, splits them, and uses the right-hand portion (Relation) as the edge label.

Additionally, I would like to have a function (or CSS snippet) that hides after the & delimiter in a link’s display text, so that only the part before & is visible in the rendered note. This would ensure a clean and intuitive display while preserving the semantic edge information for the graph.

Thanks!

[dial481]

@Hobeom just took a stab at this as a standalone plugin using @ syntax. Writes standard YAML frontmatter that Graph Link Types can read natively.

I'd be happy to hear your feedback and contributions are welcome: https://github.com/penfieldlabs/obsidian-wikilink-types

[Hobeom]

@dial481 Thanks for sharing this! I went through the obsidian-wikilink-types source code — really clean implementation.

A few observations and questions after reading through it:

1. @ vs & delimiter — Using @ with a lookbehind for whitespace/start-of-string (/(?<=\s|^)@([\w-]+)/) is a smart choice. It naturally avoids the ambiguity I flagged in my original request (where & could appear in note titles), and it also sidesteps false positives like email addresses (john@causes.com). Nice touch.

2. YAML sync as the compatibility layer — I see that syncFrontmatter() in sync.ts uses app.fileManager.processFrontMatter() with a diff check (frontmatterMatchesDesired) to avoid infinite re-triggers on the vault modify event. That's exactly the right approach for co-existing with Graph Link Types and Dataview without any upstream changes.

3. Multiple @types per link — The ability to write [[Note|text @supersedes and @contradicts]] and have each type generate its own frontmatter entry is more expressive than what I originally proposed with my single Alias&Relation syntax. This is a meaningful improvement.

4. Display text in reading view — I notice the current styles.css only covers the autocomplete popup styling. Does the @type text remain visible as-is in reading/preview mode? In my original request I mentioned wanting to hide the relation portion from the rendered display. Is this something you're planning to address (e.g., with a post-processor that wraps @type tokens in a hidden/dimmed <span>)?

5. Graceful degradation — The fact that YAML frontmatter persists even after uninstalling is a great design decision for data safety.

Overall this feels like a more robust and ergonomic take on the idea I was going for. I'll install it via BRAT and test it in my vault. Happy to contribute if there are areas where I can help!

[dial481]

@Hobeom, thanks for the detailed review.

On point 4, you're right, the @type text renders as-is in reading view right now. A post-processor to hide or dim it in reading mode is a good idea but not implemented yet. If you have thoughts on the UX or want to take a crack at it, contributions are welcome.