obsidian bases nante

intro

today, when the power got cut at my workplace and obsidian reloaded, i learned that version 1.9 came out and it introduces bases! it totally makes sense for them to do this, considering how dataview is both one of the program’s killer apps and one of the most imposing things for new users to learn.

it also helps to contextualize the properties view that they implemented however many years ago: while it seemingly didn’t make much sense at the time (unless you were already invested in dataview), it suddenly has a much clearer purpose.

unfortunately, with how i have like 5,000 media notes which rely on inline fields, bases isn’t especially useful to me at this current juncture. maybe datacore would be more up my alley once it reaches a stable release, particularly because it preserves inline metadata and holy shit it finally supports querying by section!!

(now if only it supported querying tables… but maybe i would’ve had to have stuck with org-roam if i considered that to be essential)

rendering within-note data through bases

guinea pigs: [blololies – Summer’s Dai (1996)], [Ellen Straighton – Creativity (1985)] (both are fictional albums)

• file.name == this.file.name Just Works as a “select this file,” and i’m happy to have nailed that just through intuition alone. it still feels a bit weird conceptually though – as if i need to survey the world to figure out where i am right now
• the way of rendering stars that i’ve been using with dataview Just Works too, which surprises me a little more
  • (that is, by using ["", "★", "⭐", "🌟", "🌠"][stars] )
  • though now i’m wondering how much of what’s in these views can be treated as imported components? so that if i want to change the way that they’re presented i wouldn’t have to do so within every card?
• i could see the gui being the primary way that people write queries unless necessary, because wow that query language is verbose
  • wait. it’s just yaml. the query language is entirely yaml! except for pieces like the formula language, which taste like some strange combination of js and excel
    • like why would my array select work but if-thens are written as if(cond, true, false)?!
    • i was gonna make a joke where i compared the yaml query language to like coldfusion but now i’m just confused…
  • thankfully, the gui formula editor is very helpful
• table view would’ve worked for what i’m trying to do here if rows and columns could be flipped, so card view it is
• omg so you can just create a .base file, embed it into a note, and it’ll pull information from the note that it’s embedded in! that’s pretty based, and it’s something that i wish dataview would let you do without having to resort to the js api
  • (actually wait does the js api let you? i think the most i’ve tried is sending arguments through dv.await()…)
• it’d be nice to have a way to, once you’re happy with it, put a flag in the base code to make it read-only from the gui
  • or at least make it read-only in reading view?
  • (then again, properties are also always editable, and i both dislike that and find it very useful)
• is there a way to, if a property is blank, just not have it show up in the card? i could work around this with different views, but…
• still, it suffers from the same issue (?) that dataview does, where links presented in the rendering don’t count as “true” links. i still can’t decide how big of an issue this is…
  • these connections are no longer visible in the local / global graph, which thus leads to more supposed orphans and less impressive local and global graphs. the first isn’t really an issue so long as these notes are discoverable through other means – as for the latter, my thick and dense bush of a global graph hasn’t gotten me laid yet
  • yet how useful are these connections, really? if anything they reflect a relation of kinship – such as a shared link to a moc – than of actual substance. so if there are useful insights to be found through the graph connections, they’re going to have a hard time poking their way out of the lush, virile bush
    • (counterpoint: if two artists appear on the same album, that won’t be apparent unless that connection is made explicit in the note text, but that would require recognizing it and making it explicit in the first place)
  • likewise, it means these connections don’t show up in backlinks / outgoing either, but wouldn’t that just clutter things up further? i’m already running into this issue with prayerlocket, after all, since i’m forced to bake the queries into the file…

table views for me and you

guinea pig:

Transclude of socopo-table-testbed.base

• it feels weird to have a format where all you see is the table, but maybe that’s all some people need
• my feelings about being able to set a read-only flag apply here too, if even moreso because this just lets you edit properties just from clicking around in the table, and i’m a bit of a klutz…

inline fields nante

https://github.com/blacksmithgu/datacore/blob/master/ROADMAP.md

Obsidian has some native support for editing metadata at the page level, and has recommended that Datacore move away from inline fields (since they are much more bespoke).

i guess, uhm, this ideologically feels weird to me, in part because, uhm…

so, one of the arguments i’ve seen people leverage against dataview (and community plugins in general) is that it’s unlikely to be future-proof in the same way that markdown is, as the markdown progressively becomes more and more consumed by a layer of other code that determines how the file itself will be rendered. the notes become less something that any normal person can open and read and more something that’s only intelligible when opened within this specific program using these specific plugins configured in this specific way.

i see inline fields as an effective compromise in this direction, since to the average person they don’t look much different from normal text, but they’ll still be useful within more data-oriented notes (such as automatically-generated MOCs). that said, i can also see the argument that this compromise requires relying on particularities that only this specific community plugin has, whereas yaml frontmatter seems to have more support overall – such as within SilverBullet, where i had this internal debate before apparently.

or essentially…

• inline: more intelligible in plaintext, harder to port
• frontmatter: less intelligible in plaintext, easier to port

so should i switch over to frontmatter?

i mean, like, i’m already trying to switch over all my album notes from using hyphens to separate artist and album to using en-dashes, and i expect that to take way too long…

however, all but the label and catalog information are already duplicated in there as frontmatter, so for the most part only those two would need to be added (and right now there are plenty of stubs where those aren’t there already).

perhaps i’ll revisit all this once datacore comes around, because as it stands i don’t think bases can replace everything i currently do with dataview.