search

valueflows / exchange

exchange has moved to https://lab.allmende.io/valueflows/exchange
3 stars 4 forks source link

Data structure for Transfer #16

Closed fosterlynn closed 4 years ago

fosterlynn commented 8 years ago

What should our data structure look like?

Here is more or less where I ended up in NRP recently, simplified to be able to start a discussion. Understanding of course that is one input. I'll just put it out there with the data as is, understanding we need to make it LOD friendly, discuss subclassing, etc.

Transfer

Give flow

Receive flow

It could be normalized to something like the following. Although I think we want Value Flow (aka Economic Event) to be able to be used in Transfers and Processes, so that may push it back towards the above.

Transfer

Give flow

Receive flow

[removed context agent]

fosterlynn commented 8 years ago

One simple example to look at: The transfer of funds from one "virtual account" to another, within one legal bank account. @elf-pavlik I know you consider all currency accounts to be "virtual", but this is the terminology used by more than one actual group, so I'm going with it here, hope it is OK. :blush:

Transfer:

One thing I think is helpful to think about is that the resource is not in this case the $10 as it flows between accounts. The resources are the accounts themselves, and this is about the effect on the from- and the to- resources.

Another note: You might not have both flows within your context. Like if the context is Sensorica and the network purchases a component from a supplier, in only has the Transfer and the Receive Flow.

[removed context agent]

elf-pavlik commented 8 years ago

Another note: You might not have both flows within your context. Like if the context is Sensorica and the network purchases a component from a supplier, in only has the Transfer and the Receive Flow.

This seems like a consequence of integration with a legacy system.

I would see our current approach to Transfer more as a Contract. As you see your Give flow and Receive flow duplicate exactly the same data. It seems to me that we talk about the same Transfer/Contract and just look at it from different perspective.

Let's introduce digital signatures so that we can verify ownership claims. In you example of 'internal' transfer of ownership over 10 US Dollars between you and Bob. Who needs to sign which data record so that 3rd party can verify you ownersip claims over that 10 US Dollars deposited on your shared banking account?

elf-pavlik commented 8 years ago

Give flow:

  • event date: 2016-04-10
  • from agent: Lynn
  • to agent: Bob
  • resource type: Virtual Account
  • resource: Virtual account for Lynn
  • quantity: 10 [Give flow will then decrement the resource]
  • unit of quantity: US Dollar

I would also see 'resource type' as an attribute of the resource not the flow, so: Give flow:

Introducing ownership instead of 'nested virtual accounts', and making transfer a single flow: Transfer flow:

Above contract IMO gives better foundation to verify your ownership claims over US State Currency shares, deposited on your shared banking account (a virtual resource of course) and counted in its major units (Dollars)

bhaugen commented 8 years ago

Yes, resource type is an attribute of a resource. I think that is a hangover from our current software, where we often need to deal with resources that are not tracked, and so do not "exist", so in those cases, the event needs the resource type. Value Flows might want to handle that differently.

elf-pavlik commented 8 years ago

I just 'nested' my last version of transfer further to add some types and names/labels. I guess some of you data modelling practices might have influences of relational databases and trying to fit things into tables. In RDF we have graph model which has different flexibility.

id = IRI/URI/URL

Let's draw some colourful bubbles!

fosterlynn commented 8 years ago

Need to study more later, but briefly:

I guess some of you data modelling practices might have influences of relational databases and trying to fit things into tables.

For sure! I tried to say I know that we need to free the data into LOD! Just takes me too long to think in LOD right now and wanted to get the discussion moving...

As you see your Give flow and Receive flow duplicate exactly the same data.

No they don't. The resource is often different. Think of the resource not as what is flowing, but as what is decremented or incremented on either side of the transfer.

Date might be different too, although technically it should be the same, as there is a moment where rights are transferred. But in practice, maybe we want to record dates relevant to each agent??? (Not sure.)

Let's draw some colourful bubbles!

:+1:

bhaugen commented 8 years ago

No they don't. The resource is often different. Think of the resource not as what is flowing, but as what is decremented or incremented on either side of the transfer.

I think this is mixed up in the discussion between Lynn and Pavlik trying to separate the transfers of rights from the movements of resources. I think we need to nail down what Rights are in relation to Resources. Let's work through some example resources:

The other aspect that may be different between a Give and Receive is the context, but see some ambiguity in the recent discussion about that concept, too.

bhaugen commented 8 years ago

Lynn says I misunderstood. The examples might still be useful, and add the virtual account example.

fosterlynn commented 8 years ago

Well, this example was 2 "virtual accounts", each of which is a right to a certain amount of a bank account. Ownership, although possibly not legal ownership, I don't know.

So one virtual account is decremented, the other is incremented. Both are rights. But they are different resources.

elf-pavlik commented 8 years ago

@fosterlynn IMO movement of virtual resources between virtual accounts/stocks (nested or not) might require a virtual process and also could require departure - transit - transit -transit - arrival

In this case I see that we try to deal with ownership, IMO something always legal even if not based on some mainstream legal system. I guess term Contract might suggest more purely conceptual (legal) change and not suggest some kind of physical or virtual movement.

Date might be different too, although technically it should be the same, as there is a moment where rights are transferred. But in practice, maybe we want to record dates relevant to each agent??? (Not sure.)

Can we please consider aspect of verifying ownership claims? How do you plan to do it in quoted scenario?

No they don't. The resource is often different. Think of the resource not as what is flowing, but as what is decremented or incremented on either side of the transfer.

When we transfer ownership, we always increment or decrement purely conceptual (legal) pool of 'an agent owning some physical or virtual resource (possibly identifiable only as unambiguously defined share of particular physical or virtual stock of that resource type)'.

Again, if you can't clearly identify a single resource as an object of transfer, how do you verify claims of ownership over that resource? If we don't want to support verification of ownership claims, why even bother to introduce concept of ownership?

bhaugen commented 8 years ago

See also https://github.com/valueflows/valueflows/issues/113

fosterlynn commented 8 years ago

I understand that every value flow you've created so far has had a designated context agent, but I don't see how that can be the case for the generic interoperable vocabulary.

@gcassel thanks, I think you are right in the case of the value flows, they should not need a context agent as we look at the vocabulary from the "independent view". The flows happened no matter what the context. I'll edit the data examples. I think in the case of relationships between agents, we do still need the context because the relationship occurs in a context, and possibly doesn't exist outside of that context.

@gcassel I'm rethinking.... sorry about that! I was thinking about transfers between groups and seeing that context was not so important then, and probably even a duplicate of the from or to agent. But thinking about our herbal network here, they have lots of transfers internal to the network. (That is basically how they operate, the herbs get sold to the agent at the next step all along the chain.) In this case, I think it might be useful to know that say Emily sold the fresh nettles she harvested to Namaste Drying Site, in the context of Driftless Herbal Exchange Network (DHEN). Otherwise it sort of dangles in space without its context. And maybe some day Emily wants to gather all her economic events, and to see what work she has done in DHEN, compared to other contexts she is involved in.... etc.

What do you think?

gcassel commented 8 years ago

I think it might be useful to know that say Emily sold the fresh nettles she harvested to Namaste Drying Site, in the context of Driftless Herbal Exchange Network (DHEN)

--Briefly (I'm fading here, sorry) that's one key type of context I would like for transfers to document in some way or other.

Right now, though, I'd say that the only reason I always care about the context of [the communications medium/ network in which the transfer occurs] is with respect to whether or not its a secure network, and a valid transaction. I mean, I figure that any of the involved parties could simply be visitors to that network, logging in with an external account (such as a Google, fb, or someday Personator account.)

I care lots about the context of each person's identity/ account/ key, because that could be directly associated with mutual credit, complementary currency, or any other community resources which they claim to have use-rights for. But I've already expressed that, sort of, and I'll try later to see if it relates to any current Agent vocab issues. ;)

elf-pavlik commented 8 years ago

I think it might be useful to know that say Emily sold the fresh nettles she harvested to Namaste Drying Site, in the context of Driftless Herbal Exchange Network (DHEN). Otherwise it sort of dangles in space without its context. And maybe some day Emily wants to gather all her economic events, and to see what work she has done in DHEN, compared to other contexts she is involved in.... etc.

Do you take into account here that each agent needs to have freedom to host its data in fully independent data space? While in your current implementation Emily might need to have and account on DHEN instance. I believe that we move away from such approach and Emily just needs to have her account on The Web and use VF aware applications to connect with any other party in the ecosystem that wants to connect with her.

Short observation: this very focused issue driven by example seems to start getting blurred away by more abstract conversations. While I see need and places for that, I would propose that we also cultivate threads where each response directly refers to included example and preferably proposes clear modification or asks others to propose alternative approach for the given example.

Can we try as much as possible to keep our comments here focused on iterating over proposed concrete example?

fosterlynn commented 8 years ago

Do you take into account here that each agent needs to have freedom to host its data in fully independent data space? While in your current implementation Emily might need to have and account on DHEN instance.

@elf-pavlik I don't think I was tied up in implementations. Just what people might want to know. Emily might especially want to know what work she did as part of the DHEN network if she is keeping all her own data. Just because it is an organized real-life network with a social and economic life of its own which Emily is part of. Sometimes people want to connect to others in a context, not as an island. (IMO) The context agent data element should be optional of course.

I believe that we move away from such approach and Emily just needs to have her account on The Web and use VF aware applications to connect with any other party in the ecosystem that wants to connect with her.

I agree with this! It is a good reminder, but I see it as a separate issue.

Short observation: this very focused issue driven by example seems to start getting blurred away by more abstract conversations.

Well, in this case @gcassel was saying I didn't need a data element, and I was responding to that. The topic is the transfer data structure. Seems OK, basically?

elf-pavlik commented 8 years ago

I understand that in case of provided example of Transfer, you would use context to in a way label/tag in case you would like to filter by it in a future? Since we talk about easily extensible model, we can always add tags/labels or any extra information we care about. I think we should mostly focus on necessary minimum needed to express something.

Does anyone see in this example more required information for the transfer other than: from: (agent), to: (agent), what: (rights)

So far I understand that @fosterlynn and I take different approach to how to express the what. Maybe we could focus on that since we all seem to agree on from & to (agents).

fosterlynn commented 8 years ago

you would use context to in a way label/tag in case you would like to filter by it in a future?

Not a label, it is a defined piece of info. But I'm fine letting it simmer in the background. It can be easily added or subtracted.

how to express the what. Maybe we could focus on that

Sounds good, this is the hard part!

gcassel commented 8 years ago

Does anyone see in this example more required information for the transfer other than: from: (agent), to: (agent), what: (rights)

As long as the agents are clearly identified as unique individuals or groups, and the transfer occurs as a secure and mutually recognized/ verified transmission of information, I guess that's all the information which is mandatory to create a valid transfer.

bhaugen commented 8 years ago

Might be a valid transfer, but a context agent might also valid reasons for know which events occurred within their context. For example, for income distributions.

bhaugen commented 8 years ago

Likewise we're in this transitional stage and context agents with legal identities need to report to the tax man.

Edit: This is a big issue in Enspiral, for example, where they have several different context agents with legal identities flowing money around through virtual accounts in their internal pseudo-bank.

elf-pavlik commented 8 years ago

Might be a valid transfer, but a context agent might also valid reasons for know which events occurred within their context. For example, for income distributions.

Why from and to agents don't provide enough information for income distribution? Let's maybe keep 'context agent' on distinct issue(s) and only add it here once we clearly document use cases which show requirement for it.

bhaugen commented 8 years ago

Why from and to agents don't provide enough information for income distribution?

Because I work in a lot of contexts. Likewise Lynn, likewise you, and I think likewise everybody who participates in VF.

bhaugen commented 8 years ago

P.S. if we have a clear value flow through a network of processes and transfers, we don't need the context agent for income distributions. But for example housekeeping and administration maintain the context and are seldom clearly associated with a single value flow.

And the taxman is still knocking at the door...

fosterlynn commented 8 years ago

if we have a clear value flow through a network of processes and transfers, we don't need to the context agent for income distributions

We do need it because if we cross to a different context when traveling backwards in the value flow, we dump the income onto the different context's virtual account and stop traveling the chain. Because each context agent can have a different value equation.

bhaugen commented 8 years ago

As usual, Lynn is right.

ahdinosaur commented 8 years ago

Let's maybe keep 'context agent' on distinct issue(s) and only add it here once we clearly document use cases which show requirement for it.

um, we've already clearly documented use cases which show requirements for context agent:

as @bhaugen says:

This is a big issue in Enspiral, for example, where they have several different context agents with legal identities flowing money around through virtual accounts in their internal pseudo-bank.

for example if i'm part of both Enspiral Services and Enspiral Academy, and i want to transfer monies to someone who is also part of both, i need to know which context i'm performing the transfer, which will correspond to which underlying bank account i'm transferring the rights to.

yet for a better example (since one could say the above is solved by two different underlying resources), if i'm part of Enspiral Academy and a small pod within EA called Root Systems, then if i'm transferring monies to someone using the Enspiral Academy underlying bank account, it's important to know whether i'm doing so with my Enspiral Academy hat on or specifically with my Root Systems hat on, since it means something different for how we account for finances.

elf-pavlik commented 8 years ago

um, we've already clearly documented use cases which show requirements for context agent:

  • for example in Enspiral Craftworks, to be a member you must be stewarding at least one other member or contributor. in this relationship, we need to describe not only the "steward" and the "stewardee", but also the "context" in which this relationship is happening. (see here and here for previous examples)

I don't see a clear Transfer here

yet for a better example (since one could say the above is solved by two different underlying resources), if i'm part of Enspiral Academy and a small pod within EA called Root Systems, then if i'm transferring monies to someone using the Enspiral Academy underlying bank account, it's important to know whether i'm doing so with my Enspiral Academy hat on or specifically with my Root Systems hat on, since it means something different for how we account for finances.

could you please write an example data as @fosterlynn did for that use case? do you transfer monetary currency between accounts or between agents? do you see in your transfer besides from, to and what also the need to include why ? so far we focused just on the fact to describe the Transfer but not the motivation for that transfer.

fosterlynn commented 8 years ago

@ahdinosaur I don't think @elf-pavlik was saying we don't need a context agent for the agent relationship.

do you transfer monetary currency between accounts or between agents?

From an agent, to an agent; from a resource, to a resource when the resources are accounts.

ahdinosaur commented 8 years ago

@elf-pavlik says: I don't see a clear Transfer here

@fosterlynn says: @ahdinosaur I don't think @elf-pavlik was saying we don't need a context agent for the agent relationship.

yep, i was using that as an example to start me thinking because the principle is more or less the same.

elf-pavlik commented 8 years ago

do you transfer monetary currency between accounts or between agents?

From an agent, to an agent; from a resource, to a resource when the resources are accounts.

How about cash payments? frome resource: The green wallet in Lynn's left pocket | to resource: puce wallet in Bob's murse :wink:

In case where you transfer monetary currency within a single bank account, you may need include information about this particular bank account, but as a part of definition which describes the resource, one that rights over get transferred. Otherwise I really don't understand why you see such a strong need for from stock: & to stock: to define a Transfer.

fosterlynn commented 8 years ago

Otherwise I really don't understand why you see such a strong need for from stock: & to stock: to define a Transfer

Just when you actually need it.

If you're doing a transfer from my wallet in my pocket to Bob's wallet in his murse :) then you probably aren't recording the resources. Although some organizations will record money out of and into "petty cash", which is cash sitting around for small local expenses, and is a resource they need to keep track of. But there are lots of times when only the resource type gets recorded, not the resource itself.

And often it is the same resource, like the computer (or rights to the computer).

I was emphasizing it to try to get across a way of thinking about an economic event as having an effect on a resource. Sorry, I probably over-emphasized it. But it is also true that sometimes you do need to record a different resource on either end of a transfer, so I think it needs to be in the vocabulary.

elf-pavlik commented 8 years ago

It seems to me that for purpose other than identifying the resource, for which rights we transfer, information about stock from agent keeps it in and to agent plans to keep it in stay separate concerns. Once again, we transfer only rights to particular resource, the delivery of that particular resource (physical or virtual) and storing it in particular stock, seem to me independent from the rights transfer event.

But it is also true that sometimes you do need to record a different resource on either end of a transfer, so I think it needs to be in the vocabulary.

I disagree with it, or at least with what I currently understand it. If we (from agent, to agent and 'neutral' agent) can not identify a resource in unambiguous way, how we can event talk about rights to it or transferring those rights?

fosterlynn commented 8 years ago

I disagree with it, or at least with what I currently understand it. If we (from agent, to agent and 'neutral' agent) can not identify a resource in unambiguous way, how we can event talk about rights to it or transferring those rights?

The current model from which we are working (not to say it can't be changed!) has what you are thinking of as the resource recorded as the quantity and unit of the economic event. So $10 is transferred from say one virtual account resource to another virtual account resource. In this particular example $10 is not the resource. In the case of the serialized custom built computer resource, say this exact computer serial number 345345, the quantity and unit are then 1 each, and the resource given is the same as the resource received (rights or computer either one).

It is kind of weird that different kinds of resources are treated differently - I see that as part of radically simplifying the model. So money, and serialized resources, and resources that have lot tracking (like food in case there is e-coli), and uninventoried resources, and probably lots of other situations in both the old and new economies, behave a bit differently yet have been unified into this simple model. @bhaugen can probably help with this train of thought, he has more experience. Probably a good idea to create a set of examples that cover what we can think of and see how it nets out.

almereyda commented 4 years ago

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

https://lab.allmende.io/valueflows/exchange/-/issues/16.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.