Potential problems with Scopes as Shared Ledgers
I am thinking and writing in this blog post and elsewhere about Valueflows Scopes as shared ledgers for accounting and analytical purposes, as well as validations of distributed agreements and transactions.
This would be implemented differently in the two projects mentioned in that blog post, Holo-REA and Bonfire.
Holo-REA would provide a distributed ledger and validation service pretty much built into the architecture as a Distributed Hash Table (DHT) (but the DHT needs to be scoped programmatically).
But Bonfire would need to build it as a separate Actor with an account and its own REA data.
The potential problem arises because Scope in Valueflows is designated by an object property named inScopeOf
inScopeOf is used in vf:AgentRelationship or vf:Claim or vf:Commitment or vf:EconomicEvent or vf:Intent or vf:Process or vf:Proposal or vf:Scenario
The reference can be anything. And the problem arises because every single inScopeOf property can reference a different object!
So I think that groups that want to use Scopes as DLTs will need to agree about inScopeOf references.
Doesn't always need to be the same thing. For example, Sensorica is a network of networks, where (for example) Sensorica is the logical Scope for some activities and Breathing Games is the Scope for others.
But random inScopeOf references will create a mess rather than a shared ledger.
Groups that care about shared ledgers will need to come to some agreements about what to reference when. And it would be good to have some programmatic constraints enforcing the agreed-upon references.
Comments? Ideas? @lynnfoster @pospi @mayel @ivan @yova @jvanbockryck @yala who else?