actions: transfer, transport, transform, ... #47
Comments
|
I like the alliteration, but would also like to see more details. For example,
Are all of those called Transfer?
Are those all Transform? (P.S. I posted this comment first in a very different form, so you might have gotten a notification of the very different first form before I edited it.) |
|
@ahdinosaur thanks for getting this discussion going! 😄 Just to make sure I understand your proposal in terms of the model itself: You are proposing to eliminate Exchange and Process, and substitute the T's to be on that level, all subclasses of Transaction? Or is this only about repos? In terms of the repos, I think I like your 1) best. Seems to complicate things more to add a layer of repo, since we are accumulating various doc, context, etc. from the repos into central places. I think of VF as a cohesive vocabulary in the end. And a person does need to think about these things together on some level. Although it worked well to handle Agent separately I thought. Possible nit-pick: I'm not sure I like the term Transaction to cover both processes (creation or maintenance or transport) and exchanges, or the three T's. I think people usually use Transaction for an exchange. Do you not like "economic interaction"? Or I'm totally open to a better general one. |
|
I'm not sure how to handle this, but a lot of our economic actions aren't transactions, and this covers a lot of transformations and some of our transportations. Example: I've gathered a tree branch for myself, but I'd rather have a spear-- so I sharpen the point of the branch; or I tie a sharpened stone onto the tip of the branch. So, I've performed an economic action to add value to my resource(s) 'purely for myself'. (Pretend I live alone in the wilderness, for the simplest example here. Maybe someday in the distance future I'll trade the spear or hunt for another person; maybe I won't.) I guess the main reason I point this out now is to illustrate that transform does not seem to have any particular relation to transaction or exchange to me. In most cases, it probably does have at least an indirect relationship with social events or social possibilities; however, this is not inevitable. Certainly, a transformation is an action, regardless of whether or not it directly or indirectly involves our expectations of other people. Also, gathering any resource type (like sticks) is an action. So, I currently don't think that either transform or transport should be defined as sub-types of transaction. Transfers certainly are transactions. Certainly, many transaction-types involve a transfer of a resource (often money) from Person A to Person B in exchange for a service from Person B-- and, that service may be a case of Person B performing a specific transformation on one or more resources which Person A has ownership rights to. I like 'Process' as the generic description of all economically valuable/significant actions, whether those actions are performed by human agents or otherwise. With that in mind, I think that all transformations, transportations and transactions are types of process. I hope I'm not just confusing things? @ahdinosaur |
@gcassel @ahdinosaur Yeah, that is what I was trying to get at too (if I understand Greg correctly). I think Transaction implies Exchange, not Process. But my quibble is with the term itself, not with having something that is a super-class of exchange and process (or the 3 T's). I like the spear example, because hopefully more and more in the future we can just deal with use value, not exchange value. Although I see that if you make a spear for yourself, Economic Interaction isn't really what is happening, so maybe an even broader term is needed. Hey, maybe Economic Action? I also still like the term Process, because so many people think in terms of input-process-output. I don't know about breaking out transportation, maybe that is useful because it seems grey because the resource itself has not changed form in any way. But if you think of it another way, from the transporter's perspective, the output is more like a transportation service, not so much the resource that got transported. And if someone is paying for shipping, they are paying for the transportation service. And for a transporter, it behaves exactly like a process, with very concrete inputs, some used, some consumed, etc. Greg, for the same reason (concept of I-P-O), I don't really see exchanges (transactions) as types of processes.... but this is still about the words, so let's continue to discuss. We do seem to agree that there is a basic difference, but also a similarity, between creating something and trading something. We could delineate all the concepts out, and then work on terms maybe.... All good discussion, thanks! :) |
i give you a coffee.
i give you a coffee and in exchange receive 3 dollars from you.
i deliver a coffee to your house.
the change in rights are called Transfer (giving and receiving the coffee or money), the change in location (delivery) is called Transport.
probably lots of overlap, i'd start with saying they are the same and tease out the differences if any. but not a Transform.
i'm defining Transform as when the resources changes composition, so this isn't a Transform then?
yep, this is a definite Transform.
yes the former.
yep, well aware transaction is a term more used to describe what elf calls "conceptual flows". i picked it because the alliteration, also could use Interaction or EconomicInteraction, but then Transaction kinda grew on me as this is the "Action" in "Conversations for Action".
👍
hmm...
my proposal is to redefine transaction to be economic action, so words and stuff. |
|
hmm |
ahdinosaur
changed the title
|
Like diagram. One possible miscommunication:
I mean, the input resource has the same identity, but is changed in some way. Examples:
Vs. steel was melted and then molded and then milled into a bicycle gear. Or dough was baked into bread or rolls or cookies. |
Sorry, full credit to @gcassel for the term! |
|
riffing on @ahdinosaur .... (not sure what to do with transformation at the moment)
|
ah good point. transition? but also happy to keep most within process so we don't fall prey to overusing the inflexible concept of classical inheritance. |
|
How the online meeting example fits into Transform/Transport? During our next call we can observe it as a process and make sure we can express it. We have various inputs - agenda, proposals, our participation (with different roles), internet connections, online venue etc. and outputs minutes, resolutions, often new issues/todos. For IRL meeting it will have dependency on other processes, including transport for all participants and maybe cooking if meeting includes lunch 🍴 |
|
I really like the left half of @fosterlynn 's diagram above and the right half of @ahdinosaur 's. I think maybe all processes can be defined as transform and/or transport? |
|
@gcassel like so? Although I used nouns instead of verbs, as I think Process, Transfer, Exchange are nouns, from a discussion with @pmackay earlier, starting here https://github.com/valueflows/valueflows/issues/96#issuecomment-163934965. Others may disagree?
|
|
... although I'm personally also good with just Process with no subclasses, and explaining the possibilities in a definition in the doc, including clarifying that transportation is a process. It's a little sad to not have the Tr's, which are cool, but simplicity is also a big plus, to @ahdinosaur 's point above. Note Process will be one of those things with lots of types, as process type is part of recipe, which can get very specific, think like gr:ProductOrService except it will also include things that are created or maintained or done but are not products or services. I would be surprised if these can be handled as subclasses. |
|
I think that Process Types, like many types (e.g. Resource Types), will be a taxonomy. See recent links about types of manufacturing processes. |
That's a great idea! We discussed it in our morning walk-and-talk and are thinking about how we can model the whole value flows project as interconnected value flows. We are an economic network, we are creating value (or at least that's the goal), and so we should get good at it. I don't mean this as something we should do in a big hurry. But let's do it! |
Actually to selfdogfood I would like to focus my work on it during next weeks. Later food networks and other things I directly engage in. Many years ago I used to help a bit with CAD drawings for programming CNC machines but I don't think I can really relate to various nuances of metal manufacturing. On Sunday I hope we can present prototype of an app for tracking our time where we work on tasks/goals/issues, also with adapter to github to expose all the repos and issues as LOD with URLs on domains of our choice. Since I see all the physical resources as derived from common natural resources. The actual work we (people) perform, seems to me the most relevant aspect for someone to recognize actual contributions of other people. |
|
@elf-pavlik I didn't mean to bring metal manufacturing into this discussion as something we should work on, just as examples of process types to tease out whether Transform was general enough for what we mean. We prefer to focus on processes that people who might use the vocab are engaged in. |
This would be great. I will also be happy to focus on some selfdogfood with y'all. |
|
Yes to that new diagram hybrid @fosterlynn . At the same time, I agree with @bhaugen on this:
|
|
You wrote: I think in our current society's way of seeing reality this tree branch is your property and it's yours do do with as you please since you own it. No other human is involved so where is the transaction? I agree wholeheartedly with Mikey's OP. There is a transaction. There is always a transaction; in this case the tree gave you the branch. The tree (being a producer) created the branch by transacting with the atmosphere (breathing in CO2 and exhaling oxygen) and transacting with the ground (water + minerals) to create itself. To grow. If you take one branch for yourself it's pretty insignificant. If every person on the planet takes a branch from the same forest it is significant. At what rate does the forest reproduce itself? I don't know how to account for the human transacting with the tree because it seems to be a one way street. What does the tree get out of the deal? Maybe the tree is owed a debt by the human? Maybe the human owes a debt to a wider ecology because that branch had leaves that exchanged CO2 so all of us animals could breathe oxygen? Maybe the action of taking from the tree was done with respect and such a small amount was taken that it was not harmful to the tree or the forest? Maybe in that case it was a gift from the tree? I don't know, but there is definitely a transaction. |
|
@av8ta you are clearly indicating that all actions are actually what I would call interactions between two or more agents. All actions involve mutually influential forces/agents/actors. However, I think we want to distinguish a concept which indicates consent-based transfers of resources between autonomous human agents. I currently call this concept 'transfer'. Does this make sense? |
|
@av8ta some time in the future we would like to merge in Odum's Emergy Accounting to map total ecosystem flows. We've had some discussions with people in the UK who are working on it. But they've been dormant for awhile, and getting good data is difficult. |
|
@fosterlynn @ahdinosaur this diagram looks pretty good to me I would just change arrow Transfer - partOf -> Exchange into Transfer <- involvesMany - Exchange. Just to emphasise that Transfer can exist without Exchange but not the other way. I really like the clear distinction between Transportation and Transformation
👍 adding it to README |
|
@elf-pavlik awesome, thanks for making those pull requests. :) temperature check, how do we feel about the separation between "process" and "transfer"? how would we feel about merging in the past i remember you mentioning how these separate physical and virtual transactions, however with comments like this i wonder if you're implying "transport" (a subclass of "process") could be virtual. further, our new definition of "transfer" seems linked to the definitions of "transport" and "transform". so i'm not sure if our layers of separation is valuable or just unnecessary taxonomy. |
I like having a single superclass, but I personally don't like Transaction as the name. I don't think it will communicate well. While transaction is a very overloaded word (database transactions etc), in the economic sphere, I see most people using it to mean the same thing as transfer. Processes have a very different structure, and work very differently, from transfers. (For example, many inputs and possibly more than one output, and the inputs are usually, but not always, different resources of different resource types than the outputs.) Lynn is starting to work more with processes now, so the differences should become more apparent. |
i'm so over what color we paint the bikeshed. 🔴 💚 🔷 unless someone comes up with a better word, i think the fact that transactions are already used in the economic sphere is a benefit as we can show how to do economic transactions beyond just transfers, such as transformations (aka processes) or transportations. |
|
Hey, @ahdinosaur you were the one that was concerned about communicating to people... 😉 Lynn and I toyed around with Interaction as the superclass name. Might need to be Economic Interaction to differentiate from just bumping into something. But agents interact with each other in both transfers and processes and also with resources. So it seemed to fit. Whatcha think? |
haha yep, i've been using transaction thus far and it works. :) personally, i prefer transaction to interaction, but we've all had this conversation before in this thread and i'd like to move beyond another discussion about names (we can always change the name later!). |
|
A coupla responses:
@fosterlynn and I talked about this the other day and if I understood correctly, she didn't like it. I figure it will happen, we should think about how to handle it. |
|
@ahdinosaur ha, I do understand your feelings about the continuing language discussions. I got used to them in the part of my career spent in enterprise modeling. Sort of. Even worse when you have to deal with corporate politics, OMG. :) Yes, @bhaugen is correct, I would rather agree to something I don't like than see a fork. Way too complex, and defeats the whole purpose of a vocabulary. As @elf-pavlik continues to point out, people can mix and match vocabularies, add things that aren't included in one, etc., as they actually use them. But to me, that doesn't mean you want more than one version of one vocabulary. And it is true, I don't like Transaction to include Process. Takes the emphasis of Process off of making something into the realm of relations and deals. If you don't like Economic Action, then I'll try to think of something better. And if everyone wants Transaction, then I'll happily back down. :) Hmmm, how about something leaning towards coordination? Economic Coordination? Doesn't fit as well with people's current conception of exchange, but does move into the less-property-driven future better.... ? I'm fine with whatever you want to do with the repos. I think this needs to end up as one vocabulary. We can provide pieces in documentation if that seems helpful. So repos are tactical for us to manage our work, the way I understand it.
Oops, looks like the word "moving" is no good. Maybe "changing"? Trying as hard as possible to separate them clearly, but understanding they have the overlapping concept of participating in value flows. |
|
And overall, getting the definitions right for this kind of exercise are always tedious. I could tell you stories about standards committees when it was my paid job to work on them. At least we don't have big corporations banging their metaphorical fists on the table. |
|
ah right, this is a marathon after all, we can take our time. 😺 so how do we feel about vf:Action or vf:Interaction as the superclass name, where the vf: namespace implies economic? then as the subclasses (?):
my intuition says vf:Action <= { vf: Transfer, vf:Process, vf:Transport } but i don't know. and then do we merge this all into a single repo named by the superclass? |
|
I really don't understand a need for common superclass for vf:Transfer and vf:Process I would prefer to keep them for now as separate repositories, as we have it now and keep drawing distinction between those two concepts. Rather than merging those repositories, I hope we can pick up the conversation on renaming valueflows/exchange valueflows/exchange#10 I also see Transportation as subclass of Process, I marked them this way in my PR in valueflows/process |
I think we need to continue to work on clear distinction in terminology. I tend to use virtual and conceptual as very distinct terms. Transfering rights I see as purely conceptual, I prefer to keep them in separate repo (currently named exchange). When it comes to virtual transport, I will add two use cases.
In both cases we don't have Transfer but only virtual Transport |
|
I like
Action, however, is yet another horribly overloaded word, so I'm open to alternatives. I do think we need Transport. It's already accumulated a few use cases, and it helps to differentiate transport from transfer.
I don't want to merge the repos, but one reason might be to define a value flow as going from one of those things to another of those things. That was why I was tempted by calling everything Process, then everything could be I->P->O->I->P->O etc. But nah. It would confuse the IPO tables and PROHOW gangs and all the old-school IPO modelers from the 1970's, which included me. But I'm more interested in @ahdinosaur 's reasons... |
👎 I find very important distinction between a resource (physical or virtual) which takes part in a Process, and rights to a resource which takes part in a Transfer. For most use cases, I will provide a variant which shows that Process and Transfer can work independent from each other. I would like to see a use case which requires use of common super class. Also I->P->O->I->P->O seems to work more as [O|I]->P->[O|I]->P->[O|I] and if we have transport (process) involved where output of one process becomes input of other process, than we still have. [O|I]->P->[O|I]->P->[O|I]. Since output of Transportation becomes input of Transformation. Actually for short notation like [O|I]->TP->[O|I]->MP->[O|I]->TP->[O|I] Moving might work better than Transportation. One can also move digital currency between bank accounts and digital documents between digital storages, while transport seems bit unfit here. |
👍 Although I'm also fine with getting rid of Transportation. Or fine with it staying as an emphasis that it is not the same as Transfer. As long as it is a subclass, because to people doing transportation work, it is a process just like any other, with equipment, time, gas, etc. as inputs, and the transportation service as an output.
I'm good with not having one for now, and waiting to see how the models shake out. The one case offhand where I think it might be eventually useful is in stringing together value flows, like: |
|
I'm having trouble following the flow of this thread. My brain is melting today, lol. Transportation doesn't bother me much. It's a type of process and IMO it can be pretty easily modeled, as long as that process is viably factored. I think we all agree that transportation has nothing inherently to do with rights or transfers-- correct? Transfer is also IMO a process: a verb, not a noun. However, it's debatable which process the term "transfer" should refer to: the whole process, or the final sub-process (in my roughly suggestive description below): Ultimately, I'd like to describe Transfer via a vocabulary for Information/Communication/Conversation/Conversation for Agreement/Commitment . (Sorry I'm not modelling that properly here!) An output of Commitment becomes an input into Information via formal accounting, which transforms the data which is attached to resources and to agents. (And the changed data may also be indicated in a physical "receipt".) We could describe that entire sequential process as Transfer. However, practically speaking, maybe most people would prefer to identify Transfer with the [transformation of data which is attached to each involved agent]? Regardless of terms, I think the whole process needs to be articulated. On a related note, I think that "Conversation for Agreement" currently seems a crucially important process-type which will probably need a major emphasis. It's something I think about every day, and I deeply desire extra hours every day to focus on it. Hope I'm not disturbing flow/process significantly. |
I see Transformation and Transportation both as process but with very different purpose. In most cases we do process for it's outputs. In Transformation we produce a new different resource which has different composition than any of its inputs. In Transportation we just change location of the same resource, and possibly transported resource doesn't qualify as neither input or output of Transportation process. I created a dedicated issue to define Transportation - https://github.com/valueflows/process/issues/9
In this diagram I would see need for two separate layers
IMO using single layers doesn't make much sense and just can result in confusing physical/virtual (analogue/digital) operations on resources with conceptual (mental) operations on rights to resources. |
TODO for myself
|
Of course contribution economy is but one experiment of many going on now, but we "string together" processes and transfers in resource flows (value flows) when we figure out who all contributed to making something. Could be for distributing income, which is what we do. But could also be for lot tracing, and probably other things. Side note: "string together" is not actually an explicit data reference, it is just following the resources' outflows and inflows. Which is a many to many. Loosely coupled. So there isn't any vocabulary that strings processes and transfers together that I think we need. I understand your philosophical or ideological interest in keeping transfers separate, but per valueflows/exchange#17 I personally am understanding the need for transfers beyond property rights. They just free up resources to go on their way down a value flow. They facilitate coordination. Here's a Sensorica simplified (but real) example with mixed transfers and processes.
|
|
@fosterlynn would you like to add those diagrams to https://github.com/valueflows/valueflows/blob/master/use-cases/make-3d-printed-part.md and than link to that use case from Use Cases section of each relevant repository (probably all). I would happily include it among main use cases which drive our work! |
|
@elf-pavlik done. (Note the cartoons include transfers as well as processes, where the use case is only processes.) |
|
I see many processes and many transfers in this cartoon. Let's give it a proper treatment in various relevant issues! |
|
To be really nitty gritty about it, transformation doesn't always create "new" resources. Sometimes IMO it just modifies the attributes of a resource. For instance, we could describe teeth-cleaning as not only a service, but a transformation of someone's teeth. We wouldn't necessarily need to, but, I think that that's the rational way to be more detailed about a teeth-cleaning process. (Otherwise, I currently think that it's hard to formally associate some types of service with specific enduring resources...) Looking deeper, technically, transformation is often an act of fusion or fission of previously identified resources. As an example, hopefully not insulting anyone's excellent intelligence: Sodium and chlorine are agents, as atoms or as molecules, but can be combined to form the "new" agent of sodium chloride / table salt. The previous agents are still there, but bound in an unusually stable dependency. The previous agents have acquired new attributes/ relationships. I guess this is my roundabout way of suggesting that ultimately, transportation is fundamentally a subclass of transformation from my personal perspective. IMO it's all ultimately a matter of the properties and attributes of each agent. Simple agents have few properties, but may have many attributes. Complex agents may have many properties, including the relationships of simpler agents which create the complex agent. Complex agents may also have many attributes. Anyway, IMO "location" is simply an attribute of an agent; and that attribute can be changed/ transformed. |
@gcassel yes makes sense. The Guerrilla Translators use case is like that. https://github.com/valueflows/valueflows/blob/master/use-cases/guerrilla-translation.md |
|
We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows. This issue has been closed here, and all further discussion on this issue can be done at
If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there. |
and others
from https://github.com/valueflows/valueflows/issues/21#issuecomment-167378450, i propose we formalize the concept of an economic interaction as a
Transaction, then rename and split out the sub-types of interactionsExchangeandProcessinto:with this, i recommend we either
transactionrepotransactionrepo to be an overview and index for all the types of transactions (renameexchangerepo totransfer, renameprocessrepo totransform, createtransportrepo)The text was updated successfully, but these errors were encountered: