roles
in my opinion, one major selling point of holodex is a system to describe and delegate roles within a network. a great example of an existing system with similar aims is GlassFrog.
the concept of a role is overloaded, so in order to architect a beautiful system we need to break it down into its constituent pieces. i'll approach this with a simple example of an actual role: as the "Desk Collector" in Enspiral Craftworks, i have the responsibilities of "every month, collect intention to contribute money to collective desk account, then check people have actually put money into desk account (friendly nags if necessary)". this role organically grew into being last month as we needed to collectively pay-what-we-want for our desks at Enspiral Space and i volunteered to be the touch point, which in the process lead me to define the role into something beyond me than can be passed on from person to person within Enspiral Craftworks.
we have our first piece to describe roles already which we are calling relationships, namely a connection between multiple agents optionally under the context of other agents. examples of these relationships so far include group <-> member, parent <-> child, steward <-> stewardee, friendships, mentor <-> mentee, followers, customer <-> supplier, etc. as of now, it fails to denote a mechanism for including better information concerning the role played by a given relationship, namely the purpose, domains, responsibilities, etc. we could add this to our RelationshipType
definition, but i wonder if maybe we are using an inadaquate term, or maybe i'm conflating relationships (aka associations) with another concept.
another piece of the puzzle is combining multiple "roles" into a single "post" that exists independently of the person filing the "roles". the "Desk Collector" in Enspiral Craftworks is one such "post", where we pass it along from person to person while the core "role" stays the same. it's not enough to pass along a single relationship because it's entirely possible that one "post" may contain multiple "roles". the solution for this i've considered is to follow the practice of other concepts in the Value Network vocabulary and create a virtual entity that parallels the actual entity, namely a virtual agent entity that parallels actual agent entities. in this way, actual agents (me) can assume many virtual agents ("Desk Collector"), much in the same way that i can put on many hats, masks, coats, etc depending on the situation and context. i'm partial to this virtual parallel because then in many ways we can treat these virtual agents the same as actual agents, which feels right.
i'm gonna think more about this, in particular i think there may be something to virtual agents in combination with capacities instead of relationships, e.g. "the Desk Collector has these capacities (responsibilities described) and depends on these capacities (being an Enspiral Craftworks member)", but i need to iron out some more examples in data format.
/cc @bhaugen @fosterlynn