Questions regarding transport-with-transfer.yaml #613
Comments
|
@fkleedorfer wow, you have done some serious study!! If you don't understand or don't agree with any answers, feel free to continue the discussion. You certainly got me to look at that example again! :)
In some cases, the quantity in an event and the current quantity on the resource are not the same. Events can always decrement or increment a partial amount of a stock resource (one that basically stays where it is with the same identifier, but has items added or subtracted). Another use case: even in transportation, an agent could pick up 10 cases, and drop off 1 case here, 2 there, etc. And the other way around. In terms of resource classifications, I see one confusing thing in that example, which is that the resource classification of haralson apples probably should be a resource specification, we have moved towards always having a resource specification if there is no inventoried resource, not a classification to identify what the resource is. I think I will change that. But in any case, most often for intents and commitments, an inventoried resource won't be in the data, it will just be a resource specification (like when you order something from an ecommerce site, that is what you are ordering, not a specific resource). An exception would be for a used item for example, where you are offering a specific resource. Even on the observation layer (economic events), there will be non-inventoried resources for various reasons, including services and even material items that aren't worth inventorying because you know when to replenish by looking at them maybe. To summarize, you need a
No, this is because Alice is responsible for the transportation, not Bob. Bob is purchasing the apples delivered, sometimes called "FOB destination". So the agreement is between Alice (the supplier) and Claudia (the shipper). It is true that somewhere the address and probably the name would appear in the specifics of what the shipper will do, but that level of detail is not really in VF. There is all kinds of possible detail in contracts, which we are leaving to some other vocabulary.
That would make some sense, and possibly speak to your previous question too, although Bob won't probably even know Claudia and doesn't have any agreement with her. But if you included it and it makes sense for your application, VF wouldn't object. And sometimes transportation isn't complete until explicit receipt of the goods, yes. Sometimes things are just dropped off with the assumption that someone will find them, like consumer goods at a house. So I think you could do this how it makes sense to you and it would be fine. I'll also say that we don't have much experience with transportation using REA models, none of our users of previous REA based software did much of that. So if you do it, that would be great and we'd love to see what works best for you! And would fix the vocabulary and examples as needed, with appreciation. :)
Actually, there are not really any assumptions. And our use of ids is a bit arbitrary in the examples. I think it will depend on what people want to do. Sensorica for example has complete openness for all data in the whole network; while FreedomCoop wants privacy per project. But yes, to do a trace, you would need access to other agents' data. In the real (private data) world now, I think that agents would be required to provide minimal data needed, say in case of a food poisoning trace. In the case of VF data in a distributed system like Holochain, specific data could be specified as public in some way, while other data would be private (if I understand it properly) - as specified by users.
You might be right, again we don't have much transportation experience, but did want to show 2 "hops" of transportation managed by Claudia internally. Location might be needed by Claudia. Or maybe the apples went from one truck directly onto another truck? Don't know. [edit] Or Claudia might be able to tell by an identifier (like an internally generated tracking number). But I also want to note that in general, processes are linked through resources (little-r), at whatever level of identification people use. So sometimes it can be unclear which exact resource went out one process then in to another process, say if they are using only resource specification. Hopefully in these cases, it doesn't matter, and that is why the resources can be defined slightly loosely. |
|
Thanks, @fosterlynn, for your explanations! I'll have to let all of that sink in, it seems... |
Again thanks for digging so deeply, I expect we can use your questions to improve the doc. Also, I'm happy to work directly with you to map VF to the Web of Needs model if you like. Hopefully that would save you time, and any new use cases always contribute to the VF vocabulary too. |
|
Picking this up again... I am trying to map the VF entities to the WoN data model for the transport example. It's not finished, but I would like to share an intermediate state and welcome comments. I simplified the transport (only one process instead of two hops), otherwise I think all the entities are there. Alice, Bob, and Claudia each control two atoms. For simplicity, they have atoms representing the agents themselves, and they are directly connected via "Connection Agent1/Agent2" objects. Connections are private, which means that only the users owning the connected atoms can see what's in a connection. In a connection, users can make agreements, which means that they agree on a set of RDF triples. In the diagram, the agreements are numbered in the order they are made. Atoms are public, but can only be changed by their owner; their content is also RDF. The VF from the transport example entities are mostly generated within connections, only the agents themselves and the EconomicResources (the apples) are represented as atoms.
Does this look plausible, especially regarding data visibility? Eg., is there something that one of the users needs to have access to but in this model does not? One thing I would like to add is that Alice and Claudia's first agreement encompasses a plan for the transport process (transfer-custody, pickup, dropoff). Then, the execution of the process cannot be arbitrary (as it seems here) but must follow the plan - each process must be an instance of the planned process. Ideally, this works in such a way that there is no room for interpretation as to which Events need to occur in order for the vf agreement to succeed. Any hints as to how to get there would be helpful. Also, it is unclear to me how exactly to determine the outcome of an EconomicEvent. Is there some kind of ruleset that can be applied to calculate the effect of an EconomicEvent on the world (i.e., resources/processes/etc.)? I am quite confused by Alices Apples Resource that changes its quantity over time but is never referenced by any of the EconomicEvents: could it be that 'the application' is responsible for all these updates (i.e., the outcome is somewhat arbitrary)? |
|
@fkleedorfer will study and get back here.... |
|
@fosterlynn thanks!! Here is the same diagram with a couple of comments and questions (messes up the layout - sorry for that, but it may help to understand where I am at) |
|
@fkleedorfer this will take me longer to review, but I thought I could start some answers/thoughts and see if that helps in the meantime. If not, don't worry, I will get through your models!
One thing is that the process is the same instance in the plan and in the actuals (observations). Commitments can be hooked to a process in planning phase. Then events are also hooked to the same process, and to the commitments if applicable (through Fulfillment because it can be M:M at least in exchanges, although probably not process events). So yes the execution of the process will follow the plan, and record relationships to the planning objects - until it doesn't some times because not everything goes according to plan.
Economic events affect resources, not really anything else. The action on the event defines what the event does to the resource. Like Then there are little-r resources that can't be represented by an actual EconomicResource, like someone's work skills. In those cases, the event will usually refer to the resource specification and not to an economic resource. And nothing is affected, unless the app is keeping track of the work schedule on a calendar or something. (And we haven't actually done that, so we're not totally sure what that would look like.) |
|
@fkleedorfer looking at the questions on your diagram: Q1. A change in qty or location can only be caused by an economic event. Looking at the example, I see Alice's apples missing from the first transfer event, aargh. Very sorry, this has obviously caused you extra time and confusion, will fix! Q2. The fulfillment has a quantity and not any resource information because the resource is assumed to be the same as in the event. The quantity is because an event could partially fulfill a commitment, or an event could fulfill more than one commitment. (The latter not as often, but an example is an agent paying by statement or for whatever reason paying for more than one receipt.) Q3. Yes, if I understand you correctly. Other examples, there could be several pickups of the same type of resource for one dropoff, and vice versa. Also, the quantity is needed in the event so it can directly increment or decrement a stock resource. Q4. Not completely sure of the question. Yes, Alice and Claudia each have an "inventory" item that is a different bank account. The transfer takes $10 from Alice's and adds $10 to Claudia's. They should be only "connected" because the transfer references both, but there isn't any real connection between the bank accounts. And the transfer can be thought of kind of like 2 events (and we have modeled it that way sometimes, gone back and forth more than once - there are trade offs - hopefully this is our final thought on that). Q5. That is a good question. Another one we have had a lot of discussion on, and not much experience with transportation in actual apps. I think the answer is yes. There actually might be a lot of situations where agents abbreviate this kind of thing, and record only what is important to them. The pickup and dropoff are meant to be more process related events, which shows more if you look at the two hops. But Alice probably doesn't care much at all about Claudia's process(es), except to maybe look up online the progress of the shipment. Claudia cares because she is executing the process(es) - but she may or may not need/want to record that level of detail. Right now we have defined that transfers cannot be input or output of processes, but maybe experience will show that to be a better idea than we think. Or, we have not defined it that way, but the pickup and dropoff events could be thought to cover transfer of custody, since we now have both resourceInventoriedAs and toResourceInventoriedAs allowed on events. Hope it doesn't add more confusion to give some of the thought process on this stuff. I feel like we are waiting for more experience in this area. Florian, thanks again for your detailed inquiry. I will take some time and look again at WoN now that you have made some mapping, and see if I understand better! |
|
Thanks @fosterlynn for your continued efforts! ad Q3: looking at the table you mentioned (on the Flows page), When carefully stepping through the example (imagining a program interpreting each If, on the other hand, the Either way, the example is a bit unclear to me. In a nutshell:
|
|
Pickup is more like a status update, knowing that a resource has been loaded onto a truck or whatever and is now "inside" the process of transportation. Claudia already has updated her onhand inventory from the transfer-custody event, and she never takes ownership of the apples, so it is purely an internal operational event. She can know the status and location of the resource based on pickup and dropoff events and other process info. But also, Claudia should be able to pickup 20 in one truck and 10 in another truck after she has custody of all 30. I see your point that she might want to now identify 2 resources (with different tracking numbers, say). The way we have it defined, I suppose she would have to record a move event to split up the original resource before loading. But she might be looser in her resource management, and just pickup 20, transport them, drop them off. Then go back and pickup 10, transport them, drop them off. Seems OK, they have the same resource identifier, and know what their quantity is, and they are all the same kind? Just split up into different locations, which may not be an important part of the identifier to Claudia (in a different real world use case). Also, in terms of the quantity property, it is just useful and simpler to have it on all events, even if it could in some situations be derived by looking backwards in the value flow. So, what do you think? Too convoluted? Are you connected to any transportation use cases in your work with user groups that would shed light on the questions? (We did at one point have pickup and dropoff affecting resource quantities. But when we were defining transfers, it was clear that sometimes it would and sometimes it wouldn't. So in the interest of having event actions have clean definitions of effect on resources, we settled on this solution. And as I mentioned, we don't have a lot of experience with user groups doing transportation.) |
|
Ok, I think I got it, moving on.
Oh no, I am just trying to wrap my head around the whole thing. The But I have another problem. I first stumbled on that in my first comment here ('handovers are not committed to'), but it either is something that I don't understand or that should be added to VF: So if I understand correctly, the EconomicEvent is the only entity that grounds the whole model "in reality" - anything that actually happens, happens in the form of EconomicEvents. Everything else is just planning or interpretation or accounting. That is brilliant, because we can use the recipes and plans for calculating an anticipation of what is going to happen (in terms of a set of expected events) and then we compare the actual events to the expectation and calculate fulfillments and claims automatically. Looking at the 'Planning' example Fulfillment and satisfaction, we can easily see how such a program would work. There is an intent for receiving the 8 hours of work and Bob's commitment to do it. At this point, we could conclude what kinds of EconomicEvents to expect from Bob now (and, for example, show him a GUI component with everything already filled out for him except for the time.) Now as soon as we see such an EconomicEvent (4 hrs of work), we can automatically calculate the first Fulfillment of the commitment, conclude we need 4 more hours, and wait (or tell Bob to work some more). Upon the second EconomicEvent (4 hrs of work), we can generate the second Fulfillment object automatically and conclude that Bob's commitment is fulfilled completely. Nice! Now for my problem: sometimes, as I see it, an EconomicEvent implies another, meaning that if event A happened, so did event B. There is no way it did not. Now if we could automatically conclude that B happened upon seeing A, I believe it would help a lot - but I don't think VF allows that because there is no way to specify such an implication (ie. 'from A follows B'). Based on my crude initial understanding, I touched upon this point in my remark 'handovers are not committed to' and have now re-read your explanation. I am basically making the same point again, but with better understanding of the VF model and of what I may want to do with it: There is a Commitment to a My problem here is that the What might work is that a process can have an EconomicEvent as its result, such that the process can be understood like a logical rule: if the left hand side happens, the right hand side happens, too. For the sake of the argument, let's call that property 'vf:resultOf" and define: when all commitments to all inputs and outputs of a process are fulfilled, the events linked to the process via If that's doable, I would try to model the transport such that its A Planner/Matcher could find these intents, and match them with recipes (just checking against the Now, when the four EconomicEvents (our old buddies, the Here's a diagram that illustrates this idea: In realistic cases, the automatically triggered Is that a solution you could imagine? |
Exactly.
That is true if the commitment really means just work for 8 hours, no matter what you get done. But often it means complete a certain task, and the committed hours are an estimate for planning purposes. In those cases, you'll want to allow for different hours on the event and the commitment (which can be compared to make better estimates in the future). There is a property on the commitment called finished, which can be used instead of exactly matching the hours, of course depending on your use case.
True. Perhaps we should add that to the recipe structure, and the plan structure. I will start an issue or a PR.
This is another case where I don't think we can always be sure that something is done without a user saying so. Some services include many more not-so-abstract outputs, not just one, for example. And some services have no concrete outputs, and just will have a deliver-service output, for example a haircut. So we leave it open for a user to say that a complete service was delivered, and also so that one event can then be used in an exchange agreement, if there is one. Or much less often, as an input to another process. I would think that wouldn't stop you from automating it to greater extent of course. And as always, complete recording of events (or anything) is optional and dependent on user requirements. Many things can be (and are in practice) omitted if for the specific user there is enough information recorded for them to account for what they need to know.
Yes, the main use case we know of for triggeredBy is to trigger transfers from more concrete events. Of course there may be more.... [Got to break for some homestead work.... so I'll just post how far I am, I will continue later, including your proposed resultOf, unless you respond in the meantime... ] |
|
[continued @fkleedorfer ]
My question is how is resultOf different from outputOf? And that makes me wonder if actually the dropoff should be an input to the transportation process. And if generally an application could imply completion of an output event if all input commitments are marked complete. I don't it would always work. For example, sometimes events are needed even though they weren't planned. But I could see that for some situations it could work, and there wouldn't be anything stopping apps from implementing something like that if it makes sense for their users.
Would this work for the sender to have a ProposedIntent to request a transportation service (with when-where-what details), and the transporter to have a ProposedIntent to offer a transportation service (with fewer details probably)? Seems cleaner? Wouldn't need recipes, which not everyone will use. In terms of your diagram (thanks, always like a picture!), here is why I think of it more as it is in the example. With a note that these things are sometimes an art more than a science, and different people will think of things differently. But here are some ways the model needs to work:
In terms of the roles, that is interesting in general, but not sure they are really needed. Processes in this and many examples would occur in inScopeOf an agent - basically managed operationally by one agent. Like the transportation is inScopeOf Claudia, probably only she cares about those gory operational details. Alice only needs to know that apples got transported (she received a transportation service). So processes don't make as much sense if they cross scoping agents. If processes are thought of in this way, do you still find a need for the roles? So.... I've been looking at WoN documentation a bit, very interesting, and I'm appreciating the clean distributed architecture. I need to continue studying it. But since here we are, if I understand correctly, other ontologies (like GoodRelations or ValueFlows) would be expected to define the details of an atom or connection (or maybe other things?), which will be an offer or request for goods or services or other contributions or collaborations. If I understand correctly, it seems like the part of VF that would be needed would be Proposal - ProposedIntent - Intent, and their direct core relationships (resource definitions at some level, and agents)? I understand WoN sets up potential conversations based on the matching algorithms. Does it go farther to commitments/agreements or economic events? I possibly haven't gotten that far in my study. Or are most of your questions targeted towards what might be needed by a matching engine? |
|
Ok, a lot to unpack here...
Also a sidenote: In the examples, the property |
|
.. and here is how I see this recipe in the context of Alice's need and Claudia's offer: |
|
In pieces:
transfer is basically the combination of transfer-custody and transfer-all-rights. And even though we are trying to be careful with our definitions, I actually don't think it is horrible to change location at the same time, like I said there are many shortcuts that can be taken and don't cause any harm. If you look at a bank transfer or crypto transfer, the resource kind of ends up in a new location, and I see no need to complicate those. So, if the move of a resource that happens at the same time as a transfer seems like too much trouble to record separately, and you have no need to record the operational details of it, then my opinion is go for it. The value flow is still easy to follow. @elf-pavlik might disagree. |
Yeah, they can be powerful. And yes, recipes are intended to be data that is machine interpretable, so an application that can process my recipe can also process your recipe. Some clarification in the details: Recipes are intended to be not agent-specific, they are more like (hopefully open and shared), guides that anyone can use. Recipes can be used by an application to generate a plan for a specific agent or agents. (We do this in NRP, and there are a few decades of history in manufacturing for this kind of software, which @bhaugen can explain better than I can if you're interested. Or look up MRP and ERP for some of that history.) Anyhow, once a recipe has generated a plan (in the image of the recipe but with helpful details like knowing if you already have something in stock or need to make or get it, etc), the plan can do exactly what you are talking about for matching for needs, and for coordinating complex workflows. Big events are a good example, yes. Anyhow, I don't think you need to contrast recipes with one person coordinating it all, plans can do that job. And have the advantage of you being able to tweak them yourself if they don't exactly follow the recipe, like a big wedding for example. Because they become decoupled from the recipe once generated. |
|
I've looked more at your diagrams now, and think I understand why you are wanting to match proposals/intents with recipes, because recipes are what "could be done"? And what I said about plans may not make sense in this context. But still you don't want to use recipes. People who are offering something often haven't planned to make it yet, and will only create a plan if someone wants it, "make to order". In that case they still will have created a proposal/intents to publish what they know they can either make or obtain another way because they are an aggregator or retailer or whatever and can source it. And whether there is a plan or not, most offers and requests would refer to a ResourceSpecification (that may or may not have a public recipe behind it, and may not have any recipe). Or they could refer to an actual EconomicResource if it is something used like my old bike or one-of-a-kind like a painting or house. Also a note about "The Apples Transfer": Both intents and commitments can be part of the same plan, intents being what you need to find a match for, and commitments being what you don't because both agents have committed already (provider and receiver). I have figured that WoN would not include commitments, just intents? |
|
The idea was that a planning agent would detect that claudia's standing offer and Alice's need match the results of the recipe, and suggest to Claudia to make an offer:
Not sure if I understand this remark. "The Apples Transfer" is meant as a transfer that someone else is supposed to do, ie Alice is publishing the demand for a specific transport (transfer from Alice's Apples to Bob's Apples, which are locatedAt different locations). Is that not how that would be done? |
Oh, I get what you are doing. No, an intent will have either a provider or a receiver, whichever is known. Bob is actually irrelevant in this piece of the puzzle. So Alice could post an intent looking for someone to provide transportation services. Alice would be the receiver. |
|
To me, on your diagram, Claudia's general transport offer looks pretty perfect for matching. (Although since we don't have the roles, that provider/receiver would be just null or not there. What would be the purpose?) Claudia's offer to Alice is interesting, and probably part of the negotiation happening after Claudia and Alice find each other as potential matches, before a commitment is made. We haven't defined that "conversation for action" in VF, and weren't actually thinking about this kind of specific proposal, after an initial match is made. Seems like a gap. Does WoN have the negotiation process included, and specific offers like this? I need to complete my study to be able to meet you half way better. :) Actually, we do have a way to direct a Proposal to one or more specific agents, but we weren't really thinking of it in the way you are (at least I wasn't). So I guess the data structure is there, sort of, but not connected to a conversation yet. Hmmm. |
Ok, got it: an intent never has both provider and receiver. Quite exactly what it says in the docs, actually. I'll have to update my models and see what the consequences are. Thanks for now! |
|
Sorry for the long post again. TL; DR: first, I explain what I was thinking, for context, then I show a refactored version that does not have invalid Intents (look for Refactored below): So in my scenario, actually, Alice has a standing offer: After seeing Bob's demand, she makes an offer and they agree. Now she generates a demand for the transport - and my idea was that she shows the Commitment as something she needs done by someone else. But as you cannot propose Commitments, I used an Intent, again "The Apples Transfer", leaving everything else identical: ... but that is an invalid Intent because it hats provider and receiver set. However, the idea would be that the recipe's Refactored:
then, same story, Alice and Bob agree:
But now, Alice can generate a demand for a ... which matches the adapted
And so, Claudia ends up with the specific transport offer, generated from the recipe:
I agree that the Thanks again. |
In a way, yes: Atoms receive Hint messages from matchers whenever a matcher thinks there is a match for it. Claudia could receive a hint to her general offer and then create an atom (let's call it |
|
Next attempt for the transport recipe. No more roles, but variables - also needed for location/quantity:
It seems I cannot get rid of Intents with It also seems to make sense to be able to express: "can someone please hand this thing to that third person?" - which in VF would be an Intent with |
|
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. |
As I am trying to wrap my head around modelling in VF, I have a few questions regarding
/valueflows/examples/transport-with-transfer.yaml:redundant data: there seem to be more
vf:resourceQuantityandvf:resourceClassifiedAsstatements than necessary, repeating '30 kg of apples' many times in events. For example the pickup/dropoff events (eg claudia:856c43b1-0a63-445f-a56f-707b257f086e), could they not just reference claudia's economic resource representing the apples? Doesn't this invite inconsistencies?Bob is not mentioned in the agreement: In the agreement, there is no mention of Bob or his address. I would expect that in
urn:uuid:c7897c39-7f05-4a5d-a487-80e130a2414a(the service commitment). The actual EconomicEvent that fulfills the Commitment,urn:uuid:68cabaf3-deb8-4bd5-a439-798263abe35adoesn't mention Bob, either. This is just for brevity, I assume?handovers are not committed to: I'm surprised that the transfer-custody from Claudia to Bob is not somehow required in the agreement or necessary for fulfillment of the 'service' Commitment. When the transfer-custody to Bob takes place (urn:uuid:7a63ea10-b1c3-441a-9a08-fb8630c02614), it seems that the transport Agreement is already fulfilled. However, I'd argue that, even with FOB transport, the transport isn't finished until the intended recipient has custody of the object, so the transfer-custody should be required for Fulfillment. No?
data visibility: the modelling seems to account for different agents having only a partial view of the data: each agent has their own URI space that is used for EconomicResources; events are identified by UUIDs so they are independent of agent URI spaces. However, when you try to trace the Fulfillment of the Agreement from Alice's point of view, I think she needs access to both Claudia's and Bob's data in order to verify that bob has actually received the apples. Are there any assumptions in VF as to data visibility/ownership etc?
two processes: there is no connection between the two consecutive processes claudia uses to transport the apples, apart from the resource being the same. I would expect some storage location where she drops off the apples and picks them up later - which would also make sense tracking-wise; moreover I had expected the processes to cause an update to claudia's resource location. Is it correct to assume that data has been left out for brevity that would normally be there?
Thanks!
The text was updated successfully, but these errors were encountered: