Add sigil for keyvalue pairs

[bburns]

Just adding this as a possible alternative to header keyvalue pairs, as discussed in #19.

That link mentions @ as a possible sigil, ie

@ foo: bar

Some alternatives -

.foo bar
.foo=bar
.foo: bar

I like this syntax as it's like property assignment in oo, and @ seems more appropriate for other uses.

For my project Neomem, I had been planning to just parse out any plain 'key: value' lines and treat them as metadata. Each item has a text representation similar to markdown, corresponding to a record in a database.

There's also 'key:: value' as in obsidian - I don't like that syntax though.

[cdata]

I'm going to throw in some of our chat transcript for additional context:

At this time, there is really only one kind of data in Noosphere: subtext. Adding a new kind of data is technically easy, but it carries the trade-off that your new content type may not be well supported by other clients (much like serving arbitrary content types over the web doesn't guarantee that a web browser can view that content). That said, it is reasonable to assume that Subconscious (our Noosphere client) will support first-class rendering for common structured data formats such as JSON, CSV etc. And, we hope to explore ways to make new data types automatically legible for clients using some WASM magic (but this is a speculative and only partially formed idea, so I don't want to leave you with the impression that we have a great feature ready for you to use).

@gordon has been working on a key-value header syntax that may be suitable for what you are trying to do with Neomem. The idea is to offer a feature similar to markdown's front matter, or HTML's tag so that an author may configure header metadata from content.

Yet another way to think about it would be as a subtext "block." Block is sadly going to be a very overloaded term in our technical domain, but in the subtext context you can think of a block as being made up of the contents of a line in the subtext file. Now, subtext does not have a block type for key/value data (maybe it should). But, that doesn't necessarily stop you from interpreting any give block type that way. After all, block content is really just text that we are tagging with some inferred semantics as we parse it.

[bmann]

LogSeq also does key:: value

Jekyll front matter is yaml, mostly seen as key: value.

For TiddkyWiki, I can create arbitrary custom fields name -> value on any item.

But I would say there is a lot of complexity down this path that might better be tied to the programmability of geists? EG can we include a Geist (with whatever that syntax is) and the simplest Geist might encapsulate both custom fields AND know what to do with them?

Anti-pattern example: for Jekyll or TiddlyWiki, without extensive template / display layer programming and custom theme, these custom untyped data types don’t survive past a single user.

(I’d love an example where this is not the case — because I’d love more lightly structured entities floating about)

+1 for not using @ — it has become a public good UI element that mostly means social entities (users or organizations).

[gordonbrander]

Moving this conversation to #19.