I want to do something very specific. I’m writing the docs for a game that I’m working on, and have 30-some pages for characters. They all have various metadata and what-not, but recently it’s become cumbersome and confusing to edit, as they might change over the course of the game. (e.g. become friends with another character mid-way through the game, or change rank, etc) I thought about splitting the game into “chapters”, and having each attribute be an array of values for each chapter, but that would definitely be error-prone and easy to break.
I’d really like to use a (arbitrary, since it’s fictional) date-based approach. I already have birthdays and death dates, so it would fit nicely. I could probably get some results using YAML objects, but I’d rather use inline fields, and YAML probably wouldn’t be any easier to parse.
Something I think might be better is having headers for “events”, and the new metadata underneath. The header itself is the date that the event happens. As it is right now it isn’t really any different than the lists, since reassigning properties just appends the new value and ignores the headers. But it is significantly more readable for me, and when Dataview adds section-specific metadata, I should be able to query it properly (with some additional parsing, of course).
I might try something with YAML objects in the meantime, so I can still have my nice table view.
If anyone has any better ideas, please let me know!
Sorry, I forgot to mention the whole reason I want to do all this. Basically, I have a big table that lists all the characters and a bunch of their metadata. I want to be able to supply it with a date (or a chapter, if I was doing that) and have it only show the values relevant to that date.
Also, there are two types of these metadata: cumulative and immediate. The former works very similar to the current behaviour of inline fields, where each subsequent assignment adds it to the list. The latter would treat each assignment as the new single value.
@OreoThePony Very cool! One way would be to write everything out using the heading structure like you mentioned, but without the metadata. Then you could create individual notes to embed the different sections within. In these atomic notes you could add the metadata. Next, you could duplicate your original note, keeping only the headings, removing the content within. Then inside the headings you could embed the atomic note corresponding to that section. It might be the best of both worlds if you don’t mind clicking in in order to edit. Obviously you’d be building the queries separately. But I definitely think there are some benefits to protecting your content by encapsulating it like this.
You could also use a method similar to what I just described, but using block embeds within the atomic notes. Check out the new insider build and how it allows you to embed all sub list items by simply embedding the parent bullet.
Anyways, I am interested in where you are going with this. I have been exploring all kinds of different ways to organize ideas and designs for an animated short. It sounds like you are already onto something with the sectional metadata. I hadn’t heard that that was on the roadmap for Dataview. Thanks for sharing.
hmm, that’s an interesting idea. I thought about splitting up the data in various ways, but I don’t think it would make it easier to handle with dataview, only more complicated. Not to mention how cluttered my file system would be. For now, I’m going to use YAML for functionality and the heading/ inline field thing I mentioned for readability.
Not quite sure what you mean about the block embeds. I’m also not an insider, so I don’t have access to those builds unfortunately. Thanks, though!
That’s sort of the inverse of what I’m doing right now.
I often have a lot of things happening on the same date (and are often describing the same or related event), so I would have lot of copies of it floating around. If I wanted to change that date, I would then have to around and change for every occurrence. I already have to do this a little bit between the characters, but it would be considerably worse if i did this.
If I wanted to try that structure in a more readable in-page format, I would have to use nested headers. Which, from my experience makes it harder to tell what’s actually going on in the page, especially if you start mixing fields and values between them. It would be nice to have all the values for a field in one place in a list, though. (if I really wanted that, I could have a query in the page itself with my current solution)
I just started making actual event notes for the events, so I can display them on a nice timeline. But now the event headings (or at least the YAML) feel redundant, because I’m basically putting the same information in 2 (actually 3) different places. So I might actually try something like you suggested and have the event pages be dual-purpose. If that goes well, I’ll see what I can do about displaying it on the character’s page.
Main issue I can foresee with this is that the events are global, not per-character. So I’ll have to figure out a way to annotate whose property is being “modified”.
I was thinking it would be automatic - like to find all the metadata it would just search through all the event pages and report back what it finds. That approach might be a bit slow for a single character, but it would scale nicely.
I’ll have to figure out a way to annotate whose property is being “modified”.
I’ve been looking around for different ways to do this, and it seems my options are very limited. I can do all kinds of things to it on the page, but dataview simplifies it completely, down to only alphanumeric (lowercase) characters and hyphens/underscores. So it seems links are out of the question, unfortunately.
With that in mind, I could use a format like so: {note name}_{property key}:: {value}. Underscores because dataview automatically converts spaces to hyphens, but underscores you have to put in manually.
Alternatively, I could define characters (with links) to plain numbered fields, and then for any of those character’s modified properties, you prefix it with their assigned number. I actually really like this option the more I think about it, because it would enable backlinks and whatnot.
I’ll prototype both and see which I like better. I think I’ll probably go with the second one, but we’ll see.
After some testing on the number system, it produces unexpected results when I skip a number or even define them out of order. However, it’s actually significantly more intuitive if I just have a characters:: field with an array.
Ok, so an update. The parsing system is all done (or at least functional, might still do some more polishing). I’ve started annotating the event pages, about 1/3 of the way through. (I have a checklist of them, which is 56 items long!) I really like the way both the event pages and the character pages look. An example of each:
It is a hassle if you want to rearrange an event page since you have to change the numbers accordingly, but I think it looks really nice! Plus, I shouldn’t need the numbers or the “character” field once section metadata comes out.
I have had a couple of issues along the way, like not being able to directly embed something using Dataview, or page.file.day not consistently getting indexed correctly.
Note that they use customJS as well as Dataview. Included is a utilities script (customJS), a “cats” view, used for my big table of characters, and a “cat-individual” view, used on a character’s page.
