hard vs soft allocations #355
Comments
I understand you would consider that 20kg of apples as on instance of vf:Resource, and those 5kg and 15kg NOT instances of vf:Resource How do you model that 5kg of Apples which you commit to me? I assume that you need instances of vf:Commitment available to know how much of that stock resource you commit to who. Maybe you could write a snippet of how such instance of vf:Commitment look? Can you please also add definitions for onhand quantity and available quantity to vf:Resource!
I understand that in this case you would consider those 5kg of Apples an instance of vf:Resource. We could even capture the split as vf:Process which has instance of vf:Resource (one with 20kg of Apples) on vf:consume input and yields that instance new of 5kg of Apples on create output. What if we find useful to do such split of stock resource just in the software (not reflecting it on physical stock resource). Maybe instead of defining some kind of vf-x:VirtualProcess we could have simpler way for split stock resources into multiple stocks, or extract a stock resource from existing stock resource of the same type. |
I think I was at least semi-clear that I think context agents should figure out which properties of a resource should be used for identification. If I was putting 5kg of apples in a bin for you to pick up, I would probably identify it as a separate resource. Soft allocations, I would not. But up to the context. [Edit] that will happen anyway. |
|
I'm too tired to think much on this, but when peeking at gitter chat earlier, I was thinking that soft allocation would normally correspond directly to a commitment... and hard allocation seems to me to be an act of transportation, even if something is moving only a few feet. |
|
split & merged complementing YAML in https://github.com/valueflows/process/issues/9#issuecomment-221965499 Just a rough draft which needs several improvements! Most likely making the stock distinct from resource it contains.
'@context': https://w3id.org/valueflows/v1-dev
'@graph':
- '@id': coop:stock-of-ataulfo
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 500
after split before merge, doesn't care about elf's stock at home, just allocation for him '@context': https://w3id.org/valueflows/v1-dev
'@graph':
- '@id': coop:split-ataulfo-for-order-32424223
'@type': vf:Process
'vf:flow':
- '@id': coop:input-1001
'vf:verb': vf:consume
'vf:resource': coop:stock-of-ataulfo
- '@id': coop:output-1001
'vf:verb': vf:create
'vf:resource': coop:stock-of-ataulfo
- '@id': coop:output-1002
'vf:verb': vf:create
'vf:resource': coop:ataulfo-allocated-by-order-32424223
- '@id': coop:stock-of-ataulfo
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 497
- '@id': coop:ataulfo-allocated-by-order-32424223
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 3before merge, doesn't care about coop's stock, just my alocation - '@id': coop:ataulfo-allocated-by-order-32424223
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 3
- '@id': elf:stock-of-mangos
'@type':
- vf:Resource
- prodont:Mango
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 1.2after merge '@context': https://w3id.org/valueflows/v1-dev
'@graph':
- '@id': elf:merge-mangos-on-may-21-2016
'@type': vf:Process
'vf:flow':
- '@id': elf:input-1
'vf:verb': vf:consume
'vf:resource': elf-stock-of-mangos
- '@id': elf:input-2
'vf:verb': vf:consume
'vf:resource': coop:ataulfo-allocated-by-order-32424223
- '@id': elf:output-1
'vf:verb': vf:create
'vf:resource': elf:stock-of-mangos
- '@id': elf:stock-of-mangos
'@type':
- vf:Resource
- prodont:Mango
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 4.2 |
|
I like it. I might think about it as vf:accepting the elf-stock-of-mangos and vf:improving it as the output.. But that is not the business of the vocabulary, it will support either.
No, this is good! :) |
|
So, what is a vf:Resource and what is a rea:EconomicEvent (a vf:hard-to-name)? What is |
|
Now, how about a similar but different use case, where Pavlik, Sally, and Bob (replacing the Coop in the other use case) are all part of a buying club, they contribute their time and their basements and their bikes to the work of the buying club, all the data is open. They do soft allocation or no planning at all, and there is no different resource type issue because the buying club defines the resource types. They want to move 3kg of mangos from Bob's basement to Pavlik's basement, because another member is picking up there. Sally volunteers to move it. State before the shipment: - '@id': buyclub:bob-stock-of-ataulfo
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 500
- '@id': buyclub:elf-stock-of-ataulfo
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 1.2Now the shipment happens. - '@id': sally:delivering-3kg-of-mango-to-elf-on-may-21-2006
'@type': vf:Transportation
'vf:context': buyclub:Great-Buying-Club
'vf:flow':
- '@id': input-1
'vf:action': vf:work
note: Sally riding doing all the work
- '@id': input-2
'vf:action': vf:use
'vf:resource':
'@id': sally:blue-cargo-bike
'@type': vf:Resoruce
note: Sally's favorite cargo bike
- '@id': input-3
'vf:action': vf:pickup
'vf:resource': buyclub:bob-stock-of-ataulfo
'vf:amount':
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 3
- '@id': output-1
'vf:action': vf:dropoff
'vf:resource': buyclub:elf-stock-of-ataulfo
'vf:amount':
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 3State of the resources after shipment: - '@id': buyclub:bob-stock-of-ataulfo
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 497
- '@id': buyclub:elf-stock-of-ataulfo
'@type':
- vf:Resource
- prodont:Ataulfo_(mango)
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 4.2Apologies for technical badness in identifiers. |
|
@fosterlynn could you please clarify with YAML snippet how do you express 'soft allocation'? If possible both:
|
|
See pegging Soft allocations are just information about the relationships between existing and planned resources and requirements. |
|
@elf-pavlik here is a "soft allocation", which is nothing more than a plan/commitment. Could do all the events, but for the one you are probably thinking about: - '@id': sally:delivering-3kg-of-mango-to-elf-on-may-21-2006
'@type': vf:Transportation
'vf:context': buyclub:Great-Buying-Club
'vf:plan':
- '@id': input-plan-3
'vf:action': vf:pickup
'vf:resource': buyclub:bob-stock-of-ataulfo
'vf:amount':
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 3
Then when the process happens (vf names need some work): - '@id': sally:delivering-3kg-of-mango-to-elf-on-may-21-2006
'@type': vf:Transportation
'vf:context': buyclub:Great-Buying-Club
'vf:flow':
- '@id': input-3
'vf:action': vf:pickup
'vf:plan': input-plan-3
'vf:resource': buyclub:bob-stock-of-ataulfo
..... |
|
Might be interesting to consider one of the missing features in NRP and all MRP systems I know about. If I schedule a process next week that requires some ataulfo, and finds enuf in stock, my process will stop planning that branch right there. But if you plan a similar process in between, yours will soft-allocate the ataulfo, and my process will not know anything about it. Two previous projects that I worked on had a troubleshooting framework similar to If This Then That, which would notify people about such problems and give them options to deal with them (click on "replan" that branch, for example). [edit] MRP systems do give you a report highlighting such problems, but it's usually a big report, and is not actionable (as in, click-to-do). |
|
now the buyclub for managing its @fosterlynn you didn't even prefix the commitments and events to show which dataset publishes the canonical data. i'll also stop using urn:example and from now let's always use distinct prefixes to show which dataset originally published the data. [EDIT] https://gitter.im/valueflows?at=5749b5dbf44fde236e513bcb
|
Why the first process didn't soft-allocate? I see place for before allocation step where we just collect matches from which we can choose to allocate - https://github.com/valueflows/intent/issues/7 This way we can subscribe to the matching resources and stay up to date with their availability |
|
Subscribing to the matching resources is a great idea! |
I wasn't thinking at all about the datasets (although I now realize this is why you prefixed elf: etc. earlier). And I don't really want to make any assumptions about the datasets. Shouldn't we be able to get all the data we need in a context, such as the buying club or the coop? Or related to an economic activity that people are all involved in? That is what vf should facilitate, no? Assuming people can get the data they need, then they can report or publish the quantityAvailable based on the resource's quantity + or - commitments' quantities. Just to make sure, you do see the buying club as a vf:Agent, true? And the coop? What are the considerations for the vocab? |
In many cases we may not have a single context which shares all the data. In my examples we had 3 datasets |
|
It would be very interesting to see a diagram of those sets of relationships, what would be private information, and what would be in a collaboration or coordination space that all the agents might share. I agree that I don't want to force anybody to publish their data, but I am also interested in how a mutual coordination economy would work, and what information would be required for mutual coordination. |
|
@elf-pavlik in my buying club example, it was people all working together in a buying club (the context agent), and all the data is served by the buying club, none of it is personal data, none of it is decentralized. I was trying to focus on the aspect of clarifying how the vf:Resources work in soft or no allocation. In your example, now that I understand what you are expressing with the prefix, I think that when the context changes, there has to be a vf:Transfer. (This is not so much about physical decentralization of the data, more about what data occurs in what context. Maybe the same thing?) Something like this: - '@id': transfer-mangos-on-may-21-2016 (this is both elf: and coop:)
'@type': vf:Transfer
'vf:flow':
- '@id': coop:give-10
'vf:verb': vf:give
'vf:resource': coop: ataulfo-allocated-by-order-32424223
- '@id': elf:receive-10
'vf:verb': vf:receive
'vf:resource': elf: ataulfo-allocated-by-order-32424223
- '@id': elf:merge-mangos-on-may-21-2016
'@type': vf:Process
'vf:context': elf:identity
'vf:flow':
- '@id': elf:input-1
'vf:verb': vf:consume
'vf:resource': elf-stock-of-mangos
- '@id': elf:input-2
'vf:verb': vf:consume
'vf:resource': elf:ataulfo-allocated-by-order-32424223
- '@id': elf:output-1
'vf:verb': vf:create
'vf:resource': elf:stock-of-mangos
- '@id': elf:stock-of-mangos
'@type':
- vf:Resource
- prodont:Mango
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 4.2 |
|
I don't think we need to relabel the transferred resource before merging it, I see this sufficient: - '@id': coop:transfer-mangos-on-may-21-2016
'@type': vf:Transfer
'vf:from': coop:identity
'vf:to': elf:identity
'vf:rightsFor': coop:ataulfo-allocated-by-order-32424223
- '@id': elf:merge-mangos-on-may-21-2016
'@type': vf:Process
'vf:context': elf:identity
'vf:flow':
- '@id': elf:input-1
'vf:verb': vf:consume
'vf:resource': elf-stock-of-mangos
- '@id': elf:input-2
'vf:verb': vf:consume
'vf:resource': coop:ataulfo-allocated-by-order-32424223
- '@id': elf:output-1
'vf:verb': vf:create
'vf:resource': elf:stock-of-mangos
- '@id': elf:stock-of-mangos
'@type':
- vf:Resource
- prodont:Mango
vf:amount:
'@type': qudt:QuantityValue
'qudt:unit': unit:Kilogram
'qudt:numericValue': 4.2In
You do need to publish it somewhere, both agents could publish a copy and also digitally sign each other copy. In this case most people would see it important that at least coop signs the transfer. This way I can prove I have rights to those manogos and didn't for example steal them while asked to transport them to someone else. In case of let's say hard to recycle material (eg. batteries), people would find it important that to agent signs it, this way confirming that it accepts responsibility and if those batteries will end up in the forest people may expect cleaning it up. |
|
I'm hesitant to put signatures into the category of vocabulary. That's security stuff, which in some cases will be necessary, but aren't at the same level of data, imo. It is an implementation detail that will change with technology, not functional definitions which will not change with technology. Seems like to support coordination, and this is a good example, you need to get the resource where it can be used in the next process if it is a different context. In your example, does the coop need to find the vf:consume in your data to decrement its inventory (coop:ataulfo-allocated-by-order-32424223)? |
|
Signatures are part of conversations for agreement/action. The best pattern is for all participants to keep a record of all of the signed messages in conversation in a tamper-proof sequence. SSB can do this. Maybe Solid can, too. But it's deep implementation detail, and I don't think it belongs in either the vocab or the protocol, because the protocol should be implemented in any capable way. |
I think we need to keep in mind that people will need a way to sign the data. Of course some other vocab should take that responsibility (eg. https://web-payments.org/specs/source/ld-signatures/ ). For example, rea:Claim (as discussed in valueflows/exchange#22 ) in many cases may need a way to verify them. Let's leave it in this issue and discuss it elsewhere. I just wanted to point out that we have to stay more clear how to do:
|
|
I'm fine with people signing whatever they need to sign for their processes (little p). I thought you were including that somehow in the requirements to publish. I also didn't see your vf:Transfer before - '@id': coop:transfer-mangos-on-may-21-2016
'@type': vf:Transfer
'vf:from': coop:identity
'vf:to': elf:identity
'vf:rightsFor': coop:ataulfo-allocated-by-order-32424223As long as there is a vf:Transfer between contexts, I'm good. I don't really understand all the implications of labeling, I thought you were saying who publishes the data. But if both parties publish the same information so it can be queried and merged, that should be enough I would think? |
In case above it doesn't matter that I publish the data about transfer, I can publish a record that the cosmos transferred to me rights for the moon. Once again, I don't think we should discuss trust and verifying claims (not only rea:Claim) here. We should only keep in mind that we don't have a centralized system run by administrators who everyone using that systems trust as fair arbiters, and who will ensure that no one deletes records about commitments and agreements. |
|
VF set out to describe both vocabs and protocols. The vocabs have gotten most of our attention so far, but the protocols are important, too. The protocol in this case is some variety of conversation for action, or maybe renamed conversation for agreement. The one on the exchange readme is maybe too elaborate for borrowing a bike, but the idea is that each participant keeps a full set of the messages in the conversation in a tamper-proof sequence. It's not enuf for Agent Smith to publish a record, Smith and Pavlik need to exchange messages saying they both agree (level of formality depending on the level of trust between them, which is their judgment call). What @elf-pavlik described is called repudiation: see Wikipedia on non-repudiation. A variety of methods exist for non-repudiation. I think our job in VF is to describe the protocols in enough detail that they can be implemented, without specifying the implementations. I think for a 2-agent conversation for a reciprocal exchange, the state diagram on the exchange repo does a pretty good job, with some additional text about non-repudiation and other requirements for implementation. I also think we can get some help from the SSB and Solid gangs on this, as two possible paths for implementation, so we are not specifying something that cannot be implemented. |
|
Besides considering this issue together with #39 I think we should look at difference between allocating resource for a process and allocating resource for a transfer or just transferring a resource which will not move to another physical stock and just software will know who owns how much of it. |
These are used both in resource sales as well as issues to manufacturing processes.
A soft allocation is a type of rea:Commitment which allocates a quantity of an rea:ResourceType but does not allocate any particular rea:Resources.
For example, in a stock of apples, Pavlik may have a commitment with Bob for 5k of Apples. That is, any apples, not any particular apples.
Bob may have 20kg of Apples. A soft allocation would subtract 5kg from the available quantity, but not the onhand quantity. So Bob would only have 15kg left available for other requests.
A hard allocation would put 5kg of Apples in a container for Pavlik to pick up.
The purpose of a hard allocation is to avoid somebody else coming along and taking more than 15kg of Apples, because the 5kg allocated to Pavlik was only known to the inventory system, not obvious in the bin of Apples.
The text was updated successfully, but these errors were encountered: