There isnât a status on Agreement. The thinking is you can derive the nuances of that by looking at the Commitments and fulfilling EconomicEvents, plus finished flags.
Are you thinking that will be useful while the Agreement is being negotiated, or while it is being fulfilled, or both?
And are you thinking free-form text?
Anyhow, if you would like a status, we can add it to the FEP, and see how it goes for people. Or even just add it to any app that wants it. We wouldnât add it to VF without some actual use to test it out.
P.S. The rules link certainly is not working, thanks!
Letâs think about what statuses might be useful.
What there is right now in VF:
While people are creating the Agreement, there isnât really anything. In my experience, people create them basically all at once, so the Agreement and all Commitments. (like Alice transfer 1 used bike to Bob, Bob transfer $20 to Alice) You wouldnât see just one of those commitments out there during this process (itâs a unit of work) - but thereâs nothing saying it has to happen that way.
Once an EconomicEvent has been recorded as fulfilling a Commitment, then the Agreement is in progress.
When a Commitment is marked finished then nothing more is expected on that Commitment (although it doesnât mean that the Commitment was completely fulfilled).
When all Commitments are marked finished then the Agreement is complete (again doesnât mean everything was fulfilled as expected, but you can see what was fulfilled).
Sounds like you are thinking a user-defined status? I donât have experience with preview but it sounds different. Would that persist as a status, or be more for an immediate display on a message? Or I could see where you might be going with something like a note update that you want to communicate, like âAlmost ready to send, should be in the next couple daysâ. But maybe that is just the already proposed blend of social (AS) and economic (VF) communications?
Should we also think about more defined states that might be needed?
An exchange is rarely atomic, payments and deliveries often take time and may consist of multiple steps. These steps vary depending on the use case.
For now I just need a progress indication mechanism for my application (not for the FEP). preview is different but itâs close enough and I donât want to introduce a new property.
The âImplementationsâ section now includes Mitra (itâs not a new one, I implemented federated payments there at the same time this proposal was published).
One thing that I donât like about FEP-0837 is how resources are described. Currently we describe them using the resourceConformsTo property, which value is an URI.
I agree. Here are some other options for Intent resource-related properties: name, image, imageList, note (sort of a duplicate of the as:content above but could have a detailed discription of the resource), resourceClassifiedAs. Offers/requests are the loosest and least understood as regards identifying resources. Some mutual aid kinds of apps just have a description and thatâs it. I also do think an image would be good.
To at least partially clarify resourceConformsTo and resourceClassifiedAs, the first refers to the lowest level resource type needed to completely identify the resource in the use case, which might be more like âSchwinn bicycle model xyz123 blueâ (or not). Using wikidata is misleading, which is our fault, as we use that as shorthand in VF examples. resourceConformsTo points to ResourceSpecification, which is actually defined within VF, so might not even be a uri. Wikidata could be more appropriate for resourceClassifiedAs, which for offers/requests could use an agreed upon taxonomy or set of categories for matching/search, or just tags, pretty loose depending on the app, and can be multiple. But still, it depends on the use case, and we donât have a good understanding yet of the formality that people will want to coordinate their resource specifications (resourceConformsTo) across networks or the public, even just limited to marketplace type apps.
i think i was describing my simple interpretation of my VF. (i didnât know what VF was, and iâm still trying to catch up on the whole economicEvent of VF atm)
Iâd like to update the recommendations related to representation of amounts. Currently we have this:
hasUnit (REQUIRED): name of the unit, according to Ontology of units of Measure classification. The RECOMMENDED unit for countable items is one.
hasNumericalValue (OPTIONAL): the amount of the resource. If not specified, arbitrary amounts can be used when responding to the proposal.
The one unit is not a good fit for currency amounts. @lynnfoster, what are the alternatives? I found âamount of moneyâ, is it supposed to be a unit label, e.g. "hasUnit": "amount of money"?
hasNumericalValue is a string in all FEP-0837 examples, but this is not a requirement. I want to make serialization into decimal string mandatory, because JSON numbers should not be used for currency amounts.
Agree, itâs not great. Apologies for the following lengthy kludge, if that is too much, Iâll try again.
The âamount of moneyâ looks like it sits in a different part of their model than the units, i.e. it is a quantity, not a unit. OM2 has defined a bunch of fiat currencies as units, as have some other unit of measure vocabs. Quite awhile back, VF decided not to do that, after some long discussion. Partly this is general semantics, but specifically also (IIRC) because units have basically defined permanently in relation to each other, vs currencies which have fast moving conversion rates, and also units tend to be pretty fixed and long-lived, gathered into vocabularies, while people invent alt and local currencies all the time. Different behaviors, although one as a currency requires some different behaviors too, on the UI. So we ended up with currencies as ResourceSpecifications. Anyhow, Iâm pretty sure it is not worth asking OM2 for a new unit, since they have the individual currencies defined already. Maybe we just make up one that we recommend people use when using VF? Maybe we could add a subproperty (or whatever is correct) of one to VF, amountOfMoney isnât bad. Do you not like one because it feels like an integer? (QUDT, the other vocab we had under consideration, calls it number. Both are the âone dimensional unitâ.) Side note: In fact, one doesnât work cleanly for other business uses very well either, like âeachâ, âcountâ, etc. I have asked for those in OM2, and got turned down, very politely, didnât pursue.
Related note: We have label and symbol on vf:Unit, which override those properties coming from OM2. Lots of the unit labels need to be clarified and simplified for user groups, beyond currencies.
I wish this werenât so complex, a downside of using another very thorough vocab for something simple to us.
I think whatever is best for the technology is good. Will decimal string also work for other hasNumericalValue situations? It is used on all quantities, whether currency or weight or volumes or time or whatever needed for material things, energy, work, etc. Seems OK to me, but thought I better ask that.
Related, Iâm wondering if we should have hasNumericalValue as an optional field when part of a quantity? We do have a couple default units on ResourceSpecification, defaultUnitOfResource and defaultUntiOfEffort. Iâd need to look more carefully at your examples before doing more than wondering.
That seems good. I donât want to formally define that in VF until weâve tried it out, but we can just define it in the FEP, and include in the examples. And Iâll start an issue in VF.
Sorry, I meant maybe it shouldnât be optional, and we use another way to define the suggested or defined unit. But Iâm OK leaving it as is too, and we see how it goes, that was off topic anyhow.
Also, I realized that the minimal example of a Proposal is not useful because it doesnât contain enough information. I made resourceConformsTo property required to address that.
On a related note,
Can we use resource? It could point to a Product object (FEP-c07e).
@silverpill I happened to run into a unit of measure vocab from the UN, which has a lot of the âbusinessâ units that the scientific unit vocabs donât have. Still investigating, and thinking about how to possibly incorporate it at this point.
>Currently we describe them using the resourceConformsTo property, which value is an URI. Can we use resource? It could point to a Product object (FEP-c07e).
I think resource is confusing because you donât know it is a resource type.
But, actually the VF spec says resourceConformsTo points to a ResourceSpecification. I donât remember how we got the URI in there, maybe our examples are confusing things. Or maybe we have some unclarity in VF because sometimes these definitions will be at some point in some workflows found out on the web. Formatted Specification - Valueflows