* Julien Dallot <[email protected]> [2026-06-06 10:37]: > > Hello everyone in the org-mode community! > > I'm Julien and, for the past year, I started to add rich metadata inside my > org links. > I'm writing this email to ask for feedback about the best way to do > it, and whether it's desirable to add it into org-mode. Also, I'm > not sure if there already is a functionality that does this (could > not find it).
Hello Julien, You are asking exactly the right question. And your intuition about rich metadata in links is correct—this is not just a feature request, it is a fundamental architectural decision. I can fully agree with your motion. In fact, I have been operating with this exact model for years. I have 92 static properties for each elementary object (what you call a "link"), managed outside of Org mode and then exported into Org mode. The schema includes: - Core identity: UUID, ID, revision number, creation/modification timestamps - Typing: Elementary object type and subtype (with executable behavior) - People context: Author, assigned contact, related people list, curator, introducer, report-to - Temporal dimensions: Start/end dates, duration, intervals - Classification: Tags, WRS categories/areas, keywords, properties array, related URIs - Lifecycle: Active flag, action status, search status, sharing type, kill type - Rich media: File hash, GPG signature, dimensions, page count, duration - Financial: SKU, value/price, currency - Location: Physical location, geographic coordinates - Workflow: Priority, global rank, admin scale, sales flow stage - Content: Name, description, text, internal information, markup type - Emacs integration: Override major mode, minor modes, Emacs Lisp hash And this is before we even get to external properties—an unlimited key-value store attached to every object. A "link" is elementary object. It can also be text, description, image, video, PDF page, you name it. Org has that notion to manage links, yet as it is text based, and not database based, it is not suitable for such structured management. It requires a database. One way to achieve that in Org mode would be to treat Org sections as elementary objects which can get unlimited number of properties. Then to make some Elisp to treat those section as actual links. Such section would look like: * (7) Penn & Teller Fool Us season 7 // Ali Cook and the Snake Goddess - YouTube :PROPERTIES: :ID: 127190 :UUID: e5a6656e-ce9d-4849-b910-553f7e9af484 :CREATED: [2026-06-21 Sun 18:00] :MODIFIED: [2026-06-21 Sun 18:01] :USER_CREATED: maddox :USER_MODIFIED:maddox :TIMEZONE: Africa/Nairobi :TYPE: WWW :SUBTYPE: Magic :LINK: https://www.youtube.com/watch?v=iEijfoqn2Fk :PARENT: Ali Cook :GLOBAL_RANK: 2 :STATUS: ACTIVE :PRIORITY: 10 :CURATOR: Jean Louis :TASK: Nice appearance of coins from fire. :SHARING: Description, link, text, report :LAYOUT: Basic Layout :OUTPUT: HTML :END: #+DESCRIPTION: #+TEXT: ** Properties :PROPERTIES: :UNLIMITED: true :END: - Property 1 :: Value 1 - Property 2 :: Value 2 ** Relations :PROPERTIES: :RELATED: hyperdocument-id-1, hyperdocument-id-2 :TAGS: magic, penn-and-teller, youtube :END: and the link would look like: [[id:127190][(7) Penn & Teller Fool Us season 7 // Ali Cook and the Snake Goddess - YouTube]] [[uuid:e5a6656e-ce9d-4849-b910-553f7e9af484][(7) Penn & Teller Fool Us season 7 // Ali Cook and the Snake Goddess - YouTube]] > For the past year, I've been integrating org links in my daily > workflow to a great extent (the cornerstone is the linkin-org > package [1] that makes links reliable). I wanted to do more than > just opening my files with it, so I added metadata for a smoother > workflow. That is how it should be. > The current syntax I'm using uses a plist instead of the usual placeholder > for page number or regexp to search. > Here is an example of the pdf link that I use on a daily basis: > [[pdf:<path>::(:page 12 :edges (0.240196 0.478535 0.331699 0.494949))]] > When I open that link, the pdf opens on page 12 and highlights a particular > region defined by its edges. > I can create such a link by selecting the region I want to keep a > trace of and hit a keystroke, this is so useful I now only use this > to take notes of any reading-related task I'm doing. While that is good, it becomes tiresome. Managing link properties outside of Org—in a database—and then referencing them inside the Org file is far more sustainable. Instead of embedding coordinates, page numbers, and plists directly in every link, you store them once as properties of the elementary object. The Org link becomes a simple reference: [[id:127190][Ali Cook - Snake Goddess]] Everything else—the path, the page number, the coordinates, the highlights, the annotations, the relationships—lives in the database or in the Org file for that object. The link is just a pointe and the object holds the substance. This approach scales. When you have hundreds of PDF annotations, the plist-in-link approach creates enormous, unmaintainable Org files filled with coordinate data that belongs in structured storage, not in your text documents. The database approach keeps your Org files clean, your data queryable, and your annotations versioned. The full context—page 12, edges, highlights, creation date, author, tags, relationships—is always available through the link, but never clutters your documents. > The use cases are numerous. I also use links as playlists to start > music through mpd (then the metadata is the time stamp at which to > start the music), or to retrieve a particular id in a file (need > metadata here, otherwise the search may take me to the link since > the id is also inside it). [[mpd:album::track=12&start=45][Song Title]] Database approach: [[id:192837][Song Title]] > I was wondering what you think about this: is there a preferred way > to add metadata in links? does such a feature already exist? Can > this be somehow added to the core? No need to add it to core. It can be an extra package to manage those elementary objects. Here are link types I use: -------------------------- 1 📁 File 209 2 🌐 WWW 20924 3 📺 Video (exact time) 38 4 🆔 ID List 4 5 Set ➡️ 4253 6 📺 YouTube Video (exact time) 58 7 🔗 YouTube 3148 8 📎 Emacs Lisp Hyperlink 94 9 📝 Note 8189 10 📁 Directory 793 11 🚀 Launch Program 6 12 🎥 Media 19 13 ℹ️ Info Node 1 14 📑 PDF 6128 15 🔬 HyperScope ID 966 16 🔍 PDF Query 0 17 🌱 Tuberling 1 18 📅 Org 89 19 📄 PDF by Page Nr. 14872 20 📖 DJVU 32 21 📹 Video 759 22 📧 Message-ID 17 23 ⚙️ Admin Scale 0 24 📂 Directory Action ➜ 0 25 💻 Shell Command 8 26 🔍 Case 1 27 🔀 Action 0 28 📄 LaTeX 3 29 🔁 FOLLOW-UP 94 30 🦙 aMule 0 31 ✅ Task 1031 32 🔒 Password 1 33 🐘 PostgreSQL 65 34 📦 SQLite 0 35 🗂️ Paraset 0 36 ✉️ Enriched 3 37 📆 Plan 1 38 📚 EPUB 206 39 📃 HTML File 72 40 💬 SMS 1 41 🖼️ Image 27756 42 🔖 Emacs Bookmark 2 43 💬 Quote 6 44 🌐 URL for Image 25 45 ✅ SUCCESS 2 46 📦 Maff 2 47 📝 Xournalpp 11 48 👥 Meeting 15 49 🩺 DISEASE 14 50 📎 Emacs Lisp 14 51 📄 ODT 18 52 📜 Text with images 0 53 ✍️ Emacs Region 1 54 🌱 Kotl (Hyperbole Outline) 1 55 🎧 Audio 272 56 🔀 Track 0 57 📍 Location 0 58 🔗 Backlink 259 59 🆔 DB-ID 29 60 💬 QUOTATION 4 61 📖 Instruction 43 62 🔧 Shell Script 1 63 🦄 Scheme 1 64 📨 Mbox 1 65 🧮 Common Lisp 1 66 📚 Mobi 10 67 📁 Mount Point 1 68 ⏰ Time Reminder 19 69 📖 Page in physical book 1 70 📄 Text 5910 71 🌟 Opportunity 60 72 📄 WRS Unprocessed Page 1 73 🅰️ Priority 9 74 🌐 Web Server Query 11 75 📊 ODS 5 76 📚 CBR 1 77 🧮 Gnumeric 18 78 🔬 Hyperscope ExLaTeX 3 79 📊 CSV 26 80 💰 GnuCash 3 81 🎨 XCF 9 82 📑 DOCX 1 83 📄 Document 876 84 🏗️ Project 10 85 💌 Letter 15 86 💔 Break-up 0 87 🖼️ SVG 39 88 💰 Invoice 30 89 🛠️ Service 37 90 📬 Inquiry 1 91 💸 Schedule of Fees 202 92 🎉 Good News 1 93 🔖 Reference 0 94 📞 Call 12 95 📈 Marketing Campaign 0 96 📄 Statement 1 97 📊 Report 16 98 🗺️ GPX 191 99 🗺️ GeoJSON 1 100 📝 LyX 0 101 💻 Executable Snippet 2 102 🏹 Reach person 2 103 🤖 ChatGPT 1 104 📄 HTML (entry) 4 105 📄 HTML Snippet 7 106 🏙 ZIP 2 107 🔵 DOT 8 108 🔍 ISO 2 109 🐍 Python (one-click) 1 110 📍 KMZ 1 111 Site Plan 0 112 📄 KML 2 113 🤖🌐 LLM -> HTML 3 115 📖 FictionBook 2 and each link can also have subtype: 1 🏢 Default 2 📰 Article 3 💼📝 Business Quotation 4 📝 Request for quotation 5 🤝 Partnership Offer 6 📚 Book 7 📊 Progress 8 📊 Report 9 📎 Attachment 10 📞 Call 11 💰 Pay 12 🎉 Event 13 🏢 Business Profile 14 ⚠️ Warning 15 💼 Offer 16 📄 PDF 17 📜 Agreement 18 📝 Contract 19 📝 Poem 20 🎵 Song 21 💲 Pricing 22 📝 Request For Proposal 23 ❓ Question 24 🛠️ Practical Skill 25 🍳 Recipe 26 💡 Proposal 28 👥 Meeting 29 💊 Drug Information 30 🍔 Food 31 ✅ Task 32 ✈️ Travel 33 🎓 Training 34 📺 Video 35 🧠 Cognition 36 ✉️ E-mail Snippet 37 ✉️ E-mail Signature 39 📄 WRS Page 40 🔁 Follow-up 41 👤 Online Account 42 📄 Template 43 📊 Spreadsheet 44 💭 Dream 45 👨💻 Dev-T 46 🗣️ Voice 47 📋 Signature 48 🛡️ Patent 49 📇 Contact Information 50 📞 Phone 51 📝 Instructions 52 🗺️ Georgraphic Map 53 💰 Financial Subject 54 🔍 Ethics Report 55 📜 Flyer 56 📰 Press Release 57 🎵 Music 58 📋 Questionnaire 59 📜 Certificate 60 💲 Demand 61 🔗 Letterhead 62 📜 Corporate Resolution 64 💰 Payslip 65 🌍 Place 66 📋 Clipboard (Primary) 67 📜 Loan Request 68 🔑 Power of Attorney 69 🎵 Media Play List 70 🆔 ID Document 71 💰 Expenses Report 72 💰 Wealth Generation Plan 73 💊 Health Remedy 74 🖼️ Header Image for Letterhead 75 🌆 City 76 🔍 Case 77 🌟 Opportunity 78 🛒 Public Bidding 79 🔮 Magic 80 📝 Business Plan 81 💰 Debt 82 💌 Letter 84 🔒 Lock-down 85 🧾 Receipt 86 ✉️ Acknowledgment 87 👤 Profile Picture 88 🔱 Heraldry 89 💼 Job 90 ⚔️ Battle Plan 91 🚫 Theft 92 📄 Form 93 💬 Opinion 94 👀 Site Monitoring 95 ⚖️ Administrative Scale 96 📔 Cover Page 97 📊 Executive Summary 98 ⚠️ Reprimand 99 🗄️ Archive 100 🔄 Deja-Vu 101 📋 Minutes 102 🔧 Technical 103 👮 Police 104 ⏰ Daily Routine 105 📊 Presentation 107 🏗️ Project 108 📈 Sales Flow 109 📈 Sales stage 110 📜 Recommendation 111 📑 Policy 112 💰 Financial Planning Program No. 1 114 💰 Projected Budget 115 🏦 Gold Deal 116 💰 Income Plan 117 🔨 DIY 118 📝 CIS 119 📐 CAD Drawing 120 🏢 Corporate Document 121 ⚖️ Law 122 🔢 TIN Number 123 🔒 Password 124 📣 Marketing 125 📍 Location 126 📜 Chat Log 127 ✔️ Checklist 128 🏦 Bank Statement 129 ✍️ Technical Drawing 130 📅 Org File 131 🔍 Leads 132 📚 Lesson 133 💬 Comment 136 🔍 Research 137 🏦 Bank Instructions 138 💰 Payment 139 🏷️ Label 140 🔔 Order 141 ✍️ Draft 142 💰 Invoice 143 📜 License 144 📜 Quote 145 🏗️ Construction 146 ☕ Coffee 147 🖼️ image 148 🔢 Count 149 📅 Diary 150 📸 Screenshot 151 🧠 AI Memory 152 ⛏️ Prospecting Method 153 🔖 Bookmark 154 📄 Snippet 155 📝 Plan 156 💰 Money 157 🛩️ Shipping 158 ✨ Story 159 🎥 Movie 160 📝 Definition 161 📝 Quick Note 162 📊 Dataset (LLM) 163 🤖 AI Command 165 🔍 Micrograph 166 🖥️ OCR 167 🌐 HTML Product 168 📚 Embeddings Class 169 💡 Advice 170 🏠 Floor plan 171 🔲 Site plan 172 📋 Organizing Board 173 📋 List 174 📁 Evidence 175 😂 Joke 176 📘 Notes 177 🔬 PSDA 180 💡 Idea 181 🤖 LLM Prompt 182 📚 Just Indexed 183 🌟 Spotlight 184 WRS Game 185 🗺️ Flowchart 186 Prediction 187 📜 Transcript > There are also some technical questions that I had while writing the > linkin-org package: should I add another entry in the org-element > object of a link (a :metadata one), or should I just access metadata > from the raw-path entry. The type, the subtype, the behavior, the metadata, the relationships—all stored in the database. The Org file contains only the pointer. An extra package—let's call it org-dkr—could provide: - Functions to create and manage these typed objects from within Emacs - Link resolution—when you click [[id:127190]], it knows how to open it based on its type - Property display—show the object's metadata in the Org buffer - Query interface—find objects by type, subtype, property, or relationship - Export—generate Org files from database queries - Capture templates—create new objects with a keystroke This keeps Org mode clean and generic while providing the full power of the DKR. The core remains simple. The package provides the richness. The database provides the structure. According to Doug Engelbart, a Dynamic Knowledge Repository (DKR) is not a static archive of finished documents. Instead, it is a living, breathing, rapidly evolving collection. It is designed to capture the complete, moment-to-moment record of a project or pursuit. The concept of a DKR is central to Engelbart's goal of raising our Collective IQ—a measure of how effectively a group can tackle complex challenges. Engelbart coined the term CoDIAK (Concurrent Development, Integration, and Application of Knowledge) to describe the core processes a group uses to create knowledge. A successful DKR is more than just a database; it is the collaborative record of CoDIAK, captured "on the fly," representing the collective memory and vision. About Dynamic Knowledge Repositories (DKR) https://www.dougengelbart.org/content/view/190/163/ A Dynamic Knowledge Repository (DKR) is a living, evolving collection of all artifacts generated throughout a project or pursuit—ranging from successive drafts and brainstorming notes to source code, bug reports, and meeting records—captured in real time to form a "group brain" that connects the dots between concurrent contributions. CoDIAK (Concurrent Development, Integration, and Application of Knowledge) describes the core processes of effectively developing, integrating, and applying this knowledge to enhance a group’s Collective IQ. An exemplary DKR emerges through best practices, specialized roles (like collaboration facilitators and knowledge specialists), and enabling tools that optimize capture, organization, and navigation, allowing teams to instantly access historical context, design rationale, and dialogues to solve problems or make course corrections. While the term can also refer to static archives like Wikipedia or the Human Genome Project, its highest potential is realized as a dynamic, searchable, and highly navigable resource that significantly boosts collective intelligence. The Open Hyperdocument System (OHS): A Living Knowledge Base Framework Introduced in 1998 by Douglas Engelbart and His Colleagues https://gnu.support/dynamic-knowledge-repository-dkr/The-Open-Hyperdocument-System-OHS-A-Living-Knowledge-Base-Framework-Introduced-in-1998-by-Douglas-Engelbart-and-His-Colleagues-124375.html The Open Hyperdocument System (OHS) is a framework for building a living knowledge base, introduced in 1998 by Douglas Engelbart and his colleagues, which emphasizes four key principles: Store with integrity, Relate with precision, Trust with provenance, and Retrieve with speed and precision. These principles guide the creation of flexible, interconnected, and secure knowledge systems, ensuring that stored information is verifiable, links are bidirectional, access is controlled, and retrieval is efficient and deterministic. The author, having developed a Dynamic Knowledge Repository over 23 years, highlights that Engelbart's blueprint remains relevant and ahead of many current systems, urging readers to adopt the framework for effective knowledge management. Anyway, I hope these ideas give you some food for thought. Your plist-based link syntax is clever and clearly works for you—I'm not knocking it. But if you ever find yourself drowning in metadata, or wishing you could query all your PDF annotations from last month, or wondering why your Org files are becoming unmanageable, consider this: the link is just a pointer. The object is everything else. Put the object in a database. Keep the link clean. Let Emacs be the interface. You already have the intuition and are using rich metadata just it becomes unmanageable when stored in the wrong place (text). The true benefit of the database system is not the link syntax or even the metadata itself. It is being able to intersect, search, and manage by intersection using PostgreSQL. -- Jean Louis
