Currently if I define
---
url: https://someurl.com
---
it will be interpreted as a URL (it will be shown as a link, not just a string). Same could be applied to [[]] notation, and we still have the benefit of autocomplete, something that won’t be available with alternative notations.
Is the :: in sources:: using some sort of syntax for something or is that just your personal choice.
@SamAdams seems to think it’s “inline meta data” but I personally haven’t seen that syntax before and I don’t see it adding anything when I put it in my vault.
@DandyLyons - the key:: value syntax is used for the “Dataview” Obsidian community plugin: GitHub - blacksmithgu/obsidian-dataview: A high-performance data index and query language over Markdown files, for https://obsidian.md/.
Apologies if I’ve missed mention of this somewhere above, but why isn’t "[[…]]" the least bad option for syntax?
---
Link: "[[Note with \"Double Quotation Marks\" in Title#Heading|Display Text]]"
---
is valid YAML. Ideally Obsidian’s wikilink autocomplete function would detect that the context is a YAML header and escape the necessary characters.
Wikilinks in YAML headers simply being Command-clickable in edit mode would go a long way for me.
See also: Can [[wikilink]] in YAML ever be “done right”? NO. But there could be a “route of least pain”.
Hello, @WhiteNoise
Toying with this issue in my own notes. What is the advantage of having both a YAML block and a personal block?
Why not just use the personal-block double-colon format throughout and dispense with the separate YAML block?
Thanks
Angel
I believe this issue boils down to what the YAML block is for, the YAML block was intended to store per file settings/data of plugins. Some people have hijacked for the purpose of storing their content and are 1) unhappy because linked/unlinked mention don’t work there or 2) complain because their text doesn’t flow since they have to adhere to the YAML syntax.
I understand the needs of the users and perhaps we will revisit this other FR at some point in the future: https://forum.obsidian.md/t/native-support-for-inline-intext-attributes-yaml-fields-key-value-a-la-dataview/17092
Very grateful for the reply. Wasn’t adding to this thread as a means of asking for any change to be made. Was just trying to understand the rationale of keeping both YAML and personal blocks.
Thanks to your explanation, I now have a clearer grasp of how I can best structure my notes and make more use of the data I have.
Many thanks for sharing your time and knowledge.
Angel
Correct me if I’m wrong, but one reason I can’t completely dispense with YAML is aliases. I don’t think it’s possible to create these with double colons and then have Obsidian recognise them when creating links. I’d love to be wrong about this.
Good point. I think you are right.
Thanks for sharing.
Angel
This is a great thread. It is about one standard that is constrained, but a suggestion is to add to that constrained standard an area dedicated to whatever a user would like to stuff in there.
Historically there have been two similar standards - for Information Managers there is the ‘Topic Map Data Model Standard’ standard (see https://www.isotopicmaps.org) and for older programmers there is Java Serialization (Serialization and Deserialization in Java with Example - GeeksforGeeks). Both of these are reducible to YAML if you beat yourself on the head until you figure out some way to put into yaml every conceivable object property type (serialization) and if you force every kind of identifier (in the Topic Standard, an Identifier can appear many times in the same record, each unambiguously identifying the subject of the Topic Object) into YAML - and that is before the user gets the power to write a non-YAML or a personalized user area.
To state this with less cleverness, the need being discussed is on the one hand some form of object structuring (by properties for now) where naming is standardized up to a point, and on the other hand the need for writing stuff with an understandable markup language. The markup language issue could be due to starting from nothing and getting some distance quickly as the most realistic dev approach (NOT because that is the way it was started, but because it was a realistic approach). The YAML markup language approach still works because it is easier to convey and requires less development of tools.
But there are stresses that will rise higher and higher on this. Add pointers / links —— oh, wait, how about pointers into this or that database for indirection / cross-referencing, or how about highly tuned references (Bluebook standards: 3 or four different standards each a ‘uniform system of citation for legal texts’), or some easy mobility standard where there might be 20 directories on a machine that are various versions of the same database so there has to be some ‘root’ for the object and for the database. This will go on and on while the object structure is developed. In some ways that is fun.
There are ways around it. For instance a simple tool and a simple base object structure could be developed for reading/writing a major part of the settled structure out into YAML (or some other newly accepted standard for the auto read/write portion). The tool could be improved over time to translate whatever is in the base area to the new standard (as it gets released), and accept other YAML that is being added to the released standard and writing it out in the new standard. This is the realistic method for moving properties with new data types into the object structure. It is used in versioning mechanisms for data and programs.
The real reason behind the need for these versioning / upgrading scenarios is complexity, and complexity grows. Notice the Topic Standard’s allowance of multiple unambiguous identities and thus identifier field values. With complexity, that structure falls apart. Consider that in the early 1970’s there were so many people with the same exact social security number that on a campus of 30,000 students it was anticipated that there would be 25 students with an overlapping SSN. At Penn State there were 3 students with the same SSN, and two had the last name of Murphy. That was all fixed with versioning and a lot of hassle. Main point is that there has to be this kind of mechanism.
Consider what it will be like if the mindmap gets more structured and solidified. Pointers will be used. Nice diagrams. BUT, what happens when the same topic appears with good reason in two different maps. Or, how about at two places in the same map. Or, how about if it is in different places in 50 maps, and where it appears is dependent upon outside variables. How about where it is a root in one map that allows only trees, but is also a root in a map that allows forests, and thus has to be moved down one layer. How about if the location of the topic in a map is dependent upon the ‘fuzzy set’ of relationships into it as compared to other children of a parent. That is a head scratcher but it is what happens when positions of topics depend upon variables on relationships.
There are other methods for handling this kind of issue. First rule - don’t get locked in (and handle the griping / misunderstanding / over-broad explanations). Second rule - don’t under spec - there will be almost obvious situations that can be handled early to save a lot of later pain. Third rule - listen a lot and listen early by outing opinions.
(Aside: I think Obsidian is going to good places, and I think I can help, so I will. Thanks for being there.)
D
Hi! I know you started this thread a long time ago. And I really wanted that same thing you did.
But after a million videos I found a solution that seems to be enough for me and it’s so simple that I’m baffled.
It seems that when you use :: in the body of the note it is picked up by dataview and you can use tags and links and they are all clickable in the tables.
So, other than not being “invisible”, which is nothing incredible because you can just create a header and hide the contents, and not being able to be read by some kind of other app, which is probably only important for specific purposes of which I am not aware, then it seems that everything else works.
Am I missing something?
See the attachment: and sorry for the weird names that’s just a test vault and I just write weird names instead of thinking of things hahaha
The main issue I have with this approach is that it only works for the most simplest use case. Outside of Frontmatter, Dataview doesn’t have inline object support. If you want to built a list of objects where each has a property that links to a page you have to use hacks and it gets messy.
For example, I have a People folder and each page represents a person. I also have a Teams folder. I intended the team pages to have a frontmatter list of “members”, where each member was an object that linked to a person and described their role. I wanted the links to join up in the graph, but that doesn’t happen.
I tried to then represent this through a markdown table, but don’t like the look of them in live preview (and can’t be styled as a table) and the data isn’t accessible through dataview.
I ended up using tasks, where each property of a member is a subtask, then have dataview roll up those properties via a map function.
I mean, it works, but none of this would be needed if I could use a frontmatter property to opt-in to frontmatter links displaying in the graph, or a second data block somewhere in the page to represent my data. Frontmatter is meant for plugins, but I don’t know if any plug-in that can import those links into the graph.
My understanding is that dataview will eventually have some kind of object support, and when that happens I’ll likely have to go back and redo my setup to support it. (None of this is a big deal, I just wish there were an easier way to do it)
Very well stated. Beautifully even. Thank you @dvd1, sincerely.
Tribalism–the selfsame fuel and flame of innovation and limitation–is a universal artifact of the survival instinct.
Dialogue (a la Bohm) with an eye towards optimization allows both the “us’s” and the “them’s” to benefit from the potential “better” way of the “ours.”
Debate = Stagnate
Tribalism is alive and well today: Mac v. Windows || folder v. tags || frontmatter v. inline || functional v. OOP || fuzzy v. standardized…
It’s all much ado, about some thing.
Unfortunately, it’s rarely about the important things, and usually about defending the tribes’ things…
To the OP’s point, and to what seems to be the important “feature” being requested:
At the risk of additional sanctimony (though truly none is intended, sincerest apologies for any offense), the thread has focused on this topic’s message and not its meaning.
That is, instead of “YAML ain’t markup…” or “RTFM” or the like, perhaps it would help to dialogue on the potential benefits and then means of implementing the feature of “[linking] anything to anything…”?
The desideratum yet missing from our beloved Obsidian is a simple, standard, universal, and realtime/in vivo means of data disambiguation. All of the dataz, regardless of its type: link, object, string, meta, frontmatter, et al.
It would seem that addressing the absence, potential merits, and means of attaining this capability is most productive?
Instead of “let me count the ways this can’t work” because, reasons: YAML, Dataview, or other meta-califragilisticexpialidocious-ness…
Are there any updates on the status of this request? I’m relatively new to Obsidian and I’ve found that the metadata limitations, particularly the absence of link support, have been the main hindrance for me in the process of transitioning from other applications. I’d love to see this feature added.
Why don’t using Dataview for links ?
To be honest such important feature should be in the design of the core product, so every single view (graph, search…) will exploit it, and every plugin can use and enrich on it. As long as a feature only lives in a plugin, it will always be limited to that plugin, never participate in any standard obsidian view, never be usable to other plugins. That’s why i feel it’s important to get informations about where and if the product is heading in term of design and if such notion-like features will one day become native or if they will be delegated in plugins.
Tbh i don’t understand the point
First, Yaml doesn’t support link, it will be break every attempt to read frontmatter without Obsidian (from mkdocs to Jekill).
Also, you will always saw the link if you put in in a dataview so I don’t really doesn’t understand it.
Also, Notion use a native format that prevent the export outside Notion, and that’s not the point of Obsidian.
And so does obsidian flavor of markdown, which will also “break” here and there because markdown is one of the most poorely standardized language. What’s more important between limiting the functionalities because of a tool or changing the tool for having the functionalities? You get to a point where the chosen language becomes the excuse as to why necessary things can’t be implemented, and the tool becomes the hinderance instead of being the enabler. I can’t care less if it’s YAML, JSON… I can’t care less if a better thing than markdown is necessary, those are just tools, a mean to an end, it’s the end that matters, not the tool. I’m not doing markdown or YAML because they are super nice things, i’m doing them for the mean of structured, human readable knowledge management. If those tools stop being useful to express what I need, then they are no longer a tool but something to get rid of or evolved.
The need for a feature and how it can be implemented should never be mixed in the same discussion, the “but the current language doesn’t support” should never be an excuse to not do something if the feature is necessary. Even the most simple graph database (links as a first citizen promise, remember?) has attributes on both nodes and links. Not only links in obsidian are just barely hyperlinks, but if their most important concepts can’t even be used as attributes then they should just remove the sentence from the product advertisement.
Obsidian is knowledge management tool, not a markdown and YAML editor. The important thing is knowledge management, not how closely they stick to markdown and YAML. One is the aim of the program, the other is just ONE tool among thousands. If it doesn’t fit, change it.
Obsidian is used as a knowledge management tool, but that is not its only use.
Obsidian IS a PLAIN TEXT note taking app that uses Markdown to make notes
more readable, is multi platform (iOS Android OS, Linux (most flavors), Windows OS
and Mac OS), and is extensible. The programmers have no control over the YAML
Spec, nor the Markdown Spec. And remember, this program is basically on the line
between an Alpha and a Beta program.
Well, I disagree here. Part of the mission is to be compliant with standards so you can take your notes somewhere else. If underling format didn’t matter, Obsidian could just save all your files in json format and handle everything internally.
Back to this specific topic. As I said in one of my previous posts:
It is likely that a single YAML attribute will be chosen for linking to other notes in the frontmatter (still following the YAML syntax). Something like
---
links: ["Note 1", "Note 2"]
---
---
links:
- Note 1
- Note 2
---
It is very unlikely that arbitrary YAML fields will be parsed for linked or unlinked mentions.
It is more likely that Obsidian Core implements something like this