Misc. event-resource thoughts from holo-rea discussions
Pulling a few random thoughts from earlier discussions, mostly around event and resource mutations, mostly from https://github.com/holo-rea/holo-rea/issues/65#. (Note some of the discussion in that issue itself has been superceded.)
unitOfEffort: similarly, must this be explicitly provided or does it come from the associated ResourceSpecification?
If explicitly provided, use that; else if in RS use that; else null.
Something else- I'm just going to remove classifiedAs from the creation parameters for EconomicResource. Reason being it creates ambiguity and unnecessary complexity in handling EconomicEvent.resourceClassifiedAs- I would prefer to just be able to use that field as-is with the new resource, rather than having to concatenate and de-duplicate it.
So I guess make location non-editable?
a move event would affect currentLocation, as could other events.
We added atLocation to event based on your suggestion, which I understood was for the event location, not the resource location. I don't think we can assume those are the same right now, haven't had a real use case for it.
Perhaps it could depend on the action? For me that would make sense
New note: We didn't add a new location field to event, so let's try using event.atLocation to update resource.currentLocation for move events.
On validations, should all the transfer-* events require a toResourceInventoriedAs if resourceInventoriedAs is provided?
No, let's leave it flexible.
Actual inventoried resources are never required. Even if agents do inventory those resources, in transfers often the VF independent view will include only the ResourceSpecification, not the identifiers of the agents' inventoried resources. These are there mostly for when we do actually need them in the independent view, such as many currency transfers.
@bhaugen and I had a brief conversation at supper. Which was that we should not allow changes to event quantities, also not allow deletion of events. All changes to quantities would have to be a further event, even to correct them. That would keep us more in line with generally accepted accounting principles, which is probably a good thing for this implementation. And we wouldn't have to worry at all about the effect of accounting period reporting and such. There are probably other properties that this would apply to also, will give that a think later - provider and receiver agents would also affect accounting reports for example.
We had also discussed the possibility of splitting the records into one for can't-change and one for can-change. (Noting that everything is actually immutable, just a question of is it a new EconomicEvent or is it a Change Activity (in ActivityStreams speak, however that works in holochain).) To me this feels like too big a change for right now, and for our state of knowledge too. But it has possibilities.
I would think there are Commitments that also affect standard accounting reports, like feeding Accounts Receivable and Accounts Payable.
Suggest the fields that can be changed on event:
note: String atLocation: ID agreedIn: URI realizationOf: ID # Agreement triggeredBy: ID # EconomicEvent
Fields updateable directly on a resource:
classifiedAs: [URI!] unitOfEffort: ID # Unit (would affect events going forward) image: URI # URI containedIn: ID # EconomicResource note: String
So, here's a list of what resource fields can be updated by an event:
accountingQuantity: IMeasure onhandQuantity: IMeasure currentLocation: ID # SpatialThing stage: ID # Processspecification
It's possible we need to add state to that list, not currently on event since we changed it to a string.
conforms_to, tracking_identifier, lot - we were thinking safest if those require new events to zero the old resource, and create a new one - we should get some feedback if that is excessive for people