Okay since I don't seem to have enough energy for the serious things I have to do, time to start this thread on "Hawkeish Names", and how they could help extensions to ActivityStreams (the vocab used by ActivityPub) and other projects, allowing decentralized terminology with some collaboration without requiring a central authority to "ok" a term or requiring being able to maintain a namespace.

Thread below, I'll eventually turn it into a blogpost or ActivityPub issue.

First, let's lay out how things work now. A lot of people wonder why json-ld has a context. Well, english is imprecise, and in an open world system we need to be careful about what terms we mean. For example, imagine two ActivityPub implementors adding "run" a program and "run" a mile extensions, and how to know which term is used?

The json-ld context maps shorter human-readable terms to more precise URIs. Eg "Follow" becomes "w3.org/ns/activitystreams#Foll which is a more precise URI.

Okay now we can easily understand, we can map new terms to new vocabularies etc. Except vocabularies are hard to maintain, they spread out, and are generally a pain in the ass.

And what about adding extensions to existing vocabularies? The SocialCG has spent about 9 months hemming and hawing about how or if to extend ActivityStreams. That sucks. Can we do something better?

@sandro made a suggestion earlier which I'll call "Hawke Names", from which "Hawkeish Names" are derived. Sandro's suggestions is: the actual important definition of a term isn't the short version of the term, but the paragraph long definition of your term from the specification and use that as your key. So in this case, name would be "A simple, human-readable, plain-text name for the object. HTML markup MUST NOT be included. The name MAY be expressed using multiple
language-tagged values."

Except *nobody's* going to want to have every key in their json document bloat 20x so that's not going to happen. So here's where I diverge from @sandro who thinks this is an "optimization", but I think is pretty key: you hash the document and use that as a hash-based URN (a kind of content-addressed URI). Just to show sha1 (yeah I know) the key would look like: urn:sha1:fa53084596e3e1c04b37441b70ad0e6d90907163

@cwebber @sandro but hashes, unlike URIs accessible over the Web, aren't dereferenceable: a dev can't see the new vocabulary term and easily look up what it means.


@cwebber @npd You somewhat mischaracterized my proposal. I wasn't suggesting one use the definition text every place in the data you need to refer to the definition. Instead, you use a URI like now, but you connect it rigidly to the definition, so that different URIs can clearly refer to the same thing.

Fairly concrete proposal at sandhawke.github.io/mov/

The schemove implementation isn't quite done.

· · Web · 1 · 1 · 0

@cwebber @npd And I REALLY HATE using microblogging for technical discussion, so maybe move it to gh issues? Issues on mov are welcome.

@sandro @cwebber happy to move conversation elsewhere, like if there's a mailing list discussing this topic. I don't know if issues on your GitHub repository are appropriate, since I don't know if the discussion is specific to your particular proposal, or if you want issues on why we should look at alternatives to your proposal.

@npd @cwebber Certainly if there's anything imperfect :-) about movable-schemas it'd be nice to document/discuss in issues there. Then if there's an alternative, we could start talking about it there, sure.

The problem is Chris proposed an alternative to strawman, so I don't know where to begin.

Also, Chris, if you want feedback on your proposal, maybe make a repo for it?

@sandro @npd Sorry my response to yours was a strawman because I thought your idea was good as I misunderstood it aside from one thing!

I'll have to re-read what you wrote, I'm happy for feedback on what I wrote even if it's not the same thing

I'll write up my proposal on the AP issue tracker anyway when I get some time to breathe

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!