As described, Weals represent processes that coordinate actions of groups. The action cycle will start with some initiating action, for example the declaration of an intention or making a promise or request. These initiatives can be negotiated and agreed to and then carried out, or not, and get a final disposition according to outcomes (completed, cancelled, completed with reservations, etc.). Further, these chains may be part of larger chains or have sub-chains constituting a dependency hierarchy of related weals.
We want to be able to code the state transitions as XPFL patterns, XPFL+example+Action_Chains, and by having the Wagn Weal modules use these patterns to decide when actions are allowed and present the appropriate options to each user, wagneers can now become action flow engineers as well by evolving the XPFL cardsets available for the community.
Years ago, I (Gerry)used a program called The Coordinator, which was basically email, but with a twist. A sequence of emails related to the same coordinated action would be actions that are tracked state changes from a request or offer through the completion of a promised action.
Here are some of the language actions extracted from the link above:
Request Action, Decline Promise
Offer Action, Declare complete
Cancel, Ask for progress report
Report completion, Revoke promise
Using this software and learning from the designer, Fernando Flores, I understood the power in understanding language a s a technology for coordinating actions as well as the personal power in handling our commitments. Even when we don't have a piece of software telling us, we know to be clear in making or declining promises and canceling or revoking them as well.
You can look at language actions through these categories:
Interrogation -- ask a question expecting a response
Stream actions in this class don't affect the state of any objects, just compute a result to view or reference.
Assertion -- assert a fact with reference to evidence
Stream actions in this class assert correspondence between logical forms on the statement and facts in the system or world. Can be true or false.
Assessment -- summarize qualities based on systemic knowledge
This is probably where the trust map most comes in. Good assessments are grounded in both facts and observations evaluated by someone with skills and experience in the field of judgement.
Declaration -- a statement constituting an action with authority
Stream actions in this class create all of the primary data objects of the system. Declarations are meaningful to the extent that they are authoritative. In the sense that a judge has the authority to make declarations in court, or more simply in our personal authority to declare our intentions.
My purpose of introducing the above is not to propose any particular ontology for the action languages we are in the process of designing, but to draw attention to this way of thinking about language as a technology of action. I see this as also key to what we are doing at FlowSpace. Where I do want to start getting specific is in around the ontology of connecting projects "intentionally", that is in action networks.
More background: See also.
I really like the idea of building an instance of something like The Coordinator on the Metacurrency platform.
It can be much more powerful than email (for moving intentions forward). It is easy to define the set of breaths/statements/speech-acts available. I think it would be a powerful example of a simple yet powerful Metacurrency application.
--Arthur Brock.....Sun Mar 14 04:03:36 +0100 2010
Notes and examples towards a language for declaring action chain patters so that actions can be authenticated and validated when they are posted to a weal card.
Arrows (->) indicate the next state of the weal
Action: new: Create an -> intention weal
new :generative : Create a new intention with the ":generative" property which means that the intention is recreated for each request or offer as needed. This way the same intention can be the parent of many weal cycles.
destroy <weal> (only possible if it has no links) -> null
Actions for Weal Type: Intention:
is_aligned: Declare as co-holder of this intention
is_interested: Declare that another intention or weal supports this intension, that it is wealth for us in the context of this intension.
is_offered: Declare value offered, requests that you are open to
make_request: Enter negotiation -> <interested weal (self)> requests <contract> from <offered weal>
make_proposal: Enter negotiation: -> <offering weal (self)> proposes <contract> to <interested weal>
satisfied: Declare the intention -> completed
cancel: Reverses a declaration of alignment
# self is the counter-party of the offer, the from side who has offered something that is requested now.
Actions for Weal Type: Request:
promise <contractor> agrees to <contract> (Contract includes interested weal and details, must be able to contract to the terms, have capacity to perform and be authorized as <contractor> (user or circle)
counter-offer (counter request with offer at different terms)
# self is the counter-party to the request. Counter-offer and counter request will ping pong between
Actions for Weal Type: Offer:
accept <contract> -> promise
counter-request: (counter an offer with a request at different terms)
Actions for Weal Type: Promise:
satisfied: Declare that <contract> terms are met, the weal action is complete -> satisfied
modify_promise <new contract>: enter negotiation for new terms (change delivery date, costs, etc.)
cancel: Declare that the promise will not be completed. -> default
Actions for Weal Type: Satisfied/Default:
acknowledge <value>: Declares the wealth created or destroyed -> complete
nack: <why> Negative acknowledgement, declares non-acceptance of the completion declaration (satisfied vs. default) back to -> promise
I think the main differences from current FP work is they way intentions are handled. Eric says they already have the idea of :generative for intentions to stay around, so that isn't a real difference.
The way the idea of interested and offers that can link intentions into chains and as decompositions of smaller tasks and goals within overarching global intentions help by many.
The request/offer and promised actions following is from my experience with the Coordinator and I am confident in this design because of that experience. I don't think it is that different than FP weal transitions, but there are some details to work out.
--Gerry.....Thu Oct 22 19:49:21 +0200 2009