RFC for hashtags

[gordonbrander]

18 introduces /slashlinks. We might consider uses for #hashtags and @mentions as well.

Really, either of these usecases could be accomplished via slashlinks, so these amount to a separate namespaces. There may be value in them anyhow.

Notes and questions:

• Hashtags could conceptually link to collections, or queries, rather than documents. The distinction is fuzzy in Subconscious, but there are ways we could leverage this.
• One could use hashtags to tag blocks. This could be used to e.g. grab all blocks with a specific tag
• Slashlinks have an obvious mapping to URLs, where adding an origin to namespace them makes them valid URLs. It's less clear how #hashtags and @mentions should unambiguously map to URLs.
• Subconscious does not have a concept of identity or person right now. Should it? I'm not so sure. I think the key-management paradigm is a better one, with any username style abstraction being layered on top. However, other uses for Subtext may

Observations:

• Tags are semantic triples without predicates (the subject is the document)
• Tags are backlinks to pages that don't exist

[tixel]

Just a loose idea: @mentions and #hashtags could be short hand for a specific header. This way the subtext note conveys, in a clear and compact way, that it is talking about a specific identity and a specific topic.

The header could disambiguate and make explicit that this @mentions is a Twitter handler or a github user. And the same for #hashtag. It could point to a RDF ontology thing or to a Twitter topic.

Of course it comes with new problems: What if you want to add 2 identical @mentions that point to different identities.

[bburns]

Just digging up another file - https://github.com/subconsciousnetwork/subtext/blob/main/explorations/hashtags.md -

---

Hashtags

We could explore expanding Subtext to include support for hashtags in text blocks:

There’s no such thing as advantageous in a general sense. It’s advantageous in the circumstances you’re living in. #evolution #ecology

Hashtags could be collected into a "tags" field of text blocks, and perhaps stripped from the text as well.

OTOH: Tags are just a backlinks to pages that don't exist. To use an OODA lens, tagging is O without ODA. Collecting into tagged buckets is not sense-making, only a coarse-grained first approximation. Sense-making should fold into Orientation, and make it possible to expand your repertoire of Actions. That means synthesizing collected information into new knowledge. This is something linking supports, and tags do not. So if we have to choose one primitive, Wikilinks are the better primitive.

[bburns]

I like the equivalence of /foo-bar, and [[Foo bar]] that you've mentioned.

One question is - when would a client render a transclusion? I guess when it's on a line by itself?

e.g.

# Some heading /evolution

Here is a pic of a turtle - 
/turtle.jpg

Hashtags might be useful because they seem to have a slightly different meaning than a slashlink. A hashtag is like "file this item under evolution", or "this item is a book", while a link is like "see also this article", or "include this image below"?

It goes back to the issue of anchor links in html - what do they mean exactly? ie what kind of relationship is it?

There is the 'rel' attribute for 'a' elements - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#attr-rel

The relationship of the linked URL as space-separated link types.

https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types

• alternate
• external
• help
• search Indicates that the hyperlink references a document whose interface is specially designed for searching in this document, or site, and its resources.
• tag Indicates that the hyperlink refers to a document describing a tag that applies to this document.
• up Indicates that the page is part of a hierarchical structure and that the hyperlink leads to the higher level resource of that structure.

So having a hashtag available would give some more meaning to a link.

Same for @ signs.

And editors could also use them in restricting the namespace for autocomplete, eg in github # starts autocomplete for issues, @ for people.

So I guess they're kind of semantic sugar - adding a bit of meaning to a regular slashlink.

[bburns]

Or, what if could assign an optional link type to slashlinks? eg

/person:gibson /tag:evolution

so @gibson and #evolution would be shorthand for those.

And maybe link types could be user-defined? eg

/author:gibson /type:fish

So they would make different namespaces, useful for autocomplete.

And those could have corresepondence with links in the header? eg

author: /gibson type: /fish

[bburns]

Another issue would be assigning properties to links, to be able to make complete property graphs - maybe assign key:values like

# love and the pilgrim /artist:burne-jones /date:1896-7 /location:tate{since:1942}

[macedotavares]

I think that hashtags (in the context of KM) are best employed when they have a clear "is-a" meaning. In my experience, using them for other purposes leads to ambiguity and cognitive overhead.

"Gödel, Escher, Bach" is a #book about /computer-science and /consciousness written by /douglas-hofstadter. (How that other info could be structured is another matter).

I don't know how opinionated Subconscious should be on this, but I've seen other apps incentivizing this practice by rewarding it with extra functionality.

[polyrainbow]

It should also be considered that with the current spec, hashtags at the beginning of a line are not possible, as it would turn the block into a heading.

Note that the space after the sigil characters is NOT part of the sigil and is optional, but recommended.

# This is a heading
#This is also a heading