Transfer of agent-resource-relationship

fosterlynn commented 8 years ago

From yesterday's walk'n'talk, this idea introduced by @bhaugen , who should feel free to add to or clarify anything here.

The idea is to encapsulate the rights and responsibilities concept in the agent-resource relationship. For some cases, this is instead of a resource in its own right with an underlying resource. Could reference any amount of formal definition, like a lease agreement or deed or whatever. But the vocabulary would only model that relationship, not all the complex possibilities of the rights and responsibilities. (Which we were never going to do anyway.)

Part of this is to try to make this flexible enough to get into a coordination focus over an ownership focus. Like what can happen with this resource on different relationships. An example in the current system is maybe I can sublet the apartment but not sell it.

So a vf:Transfer could transfer an agent-resource-relationship from one agent to another. We would need the ability to define agent-resource-relationship types. I think there will be a lot of variations there, and users will want to be able to define their own.

Remaining issues I can think of right now:

I don't think this addresses Services very well, which our old definition of "transfer of rights" didn't either. We'll need to look at that more.
Not only does the agent change, the resource might change. This gets entangled with the ongoing discussion of what defines vf:Resource and what can identify a resource in different situations. Teasing out the model for vf:Resource will affect the agent-resource-relationship, I think.
I don't think this necessarily gets completely rid of the underlying resource idea, unless we can make this work for virtual accounts, which I don't think we can. I think all relationships to a resource are of the same amount, which is the amount on the resource itself. Or maybe not, I start to see some possibilities....

gcassel commented 8 years ago

I don't have anything substantial to add now but I love this train of thought.

I suppose there's continuing doubt over whether this can apply to rights and responsibilities regarding currencies and services. I don't perceive any fundamental obstacles, but I guess there will be more focused discussions on terms like money/currency and service.

elf-pavlik commented 8 years ago

I don't think this necessarily gets completely rid of the underlying resource idea, unless we can make this work for virtual accounts, which I don't think we can. I think all relationships to a resource are of the same amount, which is the amount on the resource itself. Or maybe not, I start to see some possibilities....

What about shares, if you consider 50kg of apples in a bin as as 'stock resource', person owning all 50kg of apples could transfer ownership to 10kg of apples to 3 different people (3kg each). This way that person will still own 20kg of apples in that bin.

We could see it as 3 different 'stock resources' 20kg, 10kg, 10kg, 10kg
We could see it as 1 'stock resource' with 4 shares 20kg, 10kg, 10kg, 10kg

So a share would act as relationship between an agent and a resource.

I would consider those shares as currency as I try to explain in https://github.com/valueflows/valueflows/issues/128

one can vf:Transfer currency (eg. 10kg of apples share)
one needs to vf:Transport the actual apples or split them into multiple 'stock resources' through other vf:Process

elf-pavlik commented 8 years ago

Not only does the agent change, the resource might change. This gets entangled with the ongoing discussion of what defines vf:Resource and what can identify a resource in different situations. Teasing out the model for vf:Resource will affect the agent-resource-relationship, I think.

I don't think resource can change 'during transfer', if it does we end up with something very blurry. If we describe transfer of ownership, we should clearly specify a resource - serial one, actual stock or virtual share of it. It doesn't increment or decrement that resource. I think only processes should affect actual resources and stocks - including splitting and merging stock operations (often creating virtual stocks) and transportation events related to transfers . vf:Transfer should reference a single resource and express change of relationship between that resource and involved agents.

fosterlynn commented 8 years ago

I understand you in principle and agree on some conceptual level. As to how transfers fits resources into flows of value, and how we want to define vf:Resource, I am much less clear. In practice, the coordinating agent or context agent, or some agent, needs to be part of the equation. I am working on getting my head into a community economy situation to see if that changes how we think about it now, which is very much in a context (whether organization, group, household, person or whatever). Resources that move in and out of a context due to a transfer have changed in their relationship to agents, although nothing physical has changed. Is that a change of the vf:Resource or not? Let's figure out where the blur is and if where it should live..... or something like that.... :)

elf-pavlik commented 8 years ago

Resources that move in and out of a context due to a transfer have changed in their relationship to agents, although nothing physical has changed. Is that a change of the vf:Resource or not?

Looking at resources tracked as 'serial', with distinct serial or tracking numbers. Let's say a device model Fairphone2. The serial number stays the same, no matter who owns the device and where it stays located. We do need to address topic of using IRIs in namespace of domains in control of different agents. I'll try to add to https://github.com/valueflows/resource/issues/13 some thoughts about that. Including potential in using constructs like Inverse Functional Properties

elf-pavlik commented 8 years ago

I thought how this could work with vf:ServiceResource. I see two main relationships between vf:ServiceResource and foaf:Agent: provider and recipient. Let's stay we start with planned service:

'@context': https://w3id.org/valueflows/v1
'@id': https://tidycoop.example/0e006f65-b153-4837-9949-4ccf13f805bf#service
'@type': vf:ServiceResource
'vf:model': https://tidycoop.example/cleaning-spaces-by-m2#model
'vf:provider': https://tidycoop.example/#agent
'vf:location': https://fablab.example/lab-1#place
'vf:quantity':
  '@type': qudt:QuantityValue
   'qudt:unit': unit:SquareMeter
   'qudt:numericValue': 0
'vf:expectedQuantity':
  '@type': qudt:QuantityValue
   'qudt:unit': unit:SquareMeter
   'qudt:numericValue': 200

Now we can transfer agent <-> resource vf:recipient relationship to fablab. Until process creating that resource will execute the quantity will stay 0. Which doesn't affect whatever accounting people may want to run. After the process executes, we have event which sets the final quantity of that resource. Now this vf:ServiceResource with positive quantity would affect various accounting schemes which people may choose to use.

In economic environments where various service providers 'load balance' instead of competing, I could imagine that provider relationship could also change on planned services, as long as providers have compatible service 'models'. In similar way as performer relation can change on planned vf:WorkResource https://github.com/valueflows/valueflows/issues/148#issuecomment-241000913

Similar note for vf:UsageResource https://github.com/valueflows/resource/issues/29#issuecomment-241165362

elf-pavlik commented 8 years ago

Thinking about vf:Transfer of vf:ServiceResource, vf:UsageResource and vf:WorkResource captured in previous comment. I seems that vf:Transfer just creates a commitment #21

Just as agent can transfer 'ownership' relation over material resource to someone else, while still having it in one's own possession. One can transfer 'recipient' (or 'beneficiary') relation to planned 'service', 'usage', or 'work'. Thinking about Gift Cards and Tickets @bhaugen might actually consider them a claim #22 since the service/usage/work should come as exchange for something already given (eg. popular nowadays $$$).

Main difference relates to the temporal dimension, while material goods already exist and one can observe them, service/usage/work we can only plan until they actually happen. Usage seems more predictable when the underlyingResource already exists but in commitment to work the person also already stays alive and very likely has needed skillset. Comparing to transfer of ownership relation to a material resource without changing it's possession. We may also imagine situation where the storage gets flooded or burns down and the owner never gets possession of the resource.

In transportation FOB (origin or destination) the load / unload events seem to fulfill a commitment to change of 'possession'. Since people can have owner (all rights) relationship with resources in possession of various other agents. The ownership pretty much only allows to make commitments and future IPO events may fulfill them or not. I will also add a case of fractional ownership over non divisible resources. Eg. 10 agents co-own "1 Each of a car".

All above reminds me about the vf:controls issue in valueflows/agent - which seems key aspect of having agency and basis for making commitments. Agents do not consume or create resources, only processes do. But I don't know of any living (or even digital) agent which can exist without a process aspect. I will give more focus from now on to distinction between IPO chains which involve resources and processes. And the agency overlay which involves agreements and control. Let's 'cross those streams' carefully 😉

crossstreams

fosterlynn commented 8 years ago

I seems that vf:Transfer just creates a commitment

I don't think so. And I'd like to have a much more in depth discussion on how we record commitments, I would do it different than the suggestions above. (Don't want to get into that so much now, because it is out of scope for our first release, no? And requires too much thought in that case. :blush: )

But for now, I see that a vf:Transfer can create conditions that some other input to a process is allowed to occur, based on the rules the people are working with. That is not the same as vf:Transfer == commitment. The agent transferred to can have many options of what to do next, not implied by the transfer, which only changes an agent resource role. There may be conditions placed on what the agent can do after the transfer, which would be governed by some agreement. And a person could check if the plans and actuals support the agreement. Still not vf:Transfer == commitment.

In fact, you can create a commitment to do a vf:Transfer, just as you can create a commitment to do any other event. But that is before the transfer and has nothing to do with anything happening after the transfer.

Agents do not consume or create resources, only processes do. But I don't know of any living (or even digital) agent which can exist without a process aspect.

Maybe at some point we need to carefully define "agent" so as to separate their economic agency from metabolic processes that are happening in the living person? I don't personally have a need to go there for VF, at least for some releases - eventually when we need to address ecosystems in that way, we may need to go there. The definition of foaf:Agent is too general to make that distinction, but the name does imply something of the intention - agents can do stuff, decide stuff, etc.

elf-pavlik commented 8 years ago

agents can do stuff, decide stuff

I would say that agents can only communicate, negotiate and decide stuff. To do something, something that actually affects resources we need a process. So agents can not consume and create stuff, only the processes they control/govern can consume and create (or accept and improve) resources.

At the same time I stay open that a single entity can have aspect of agent and aspect of process, so: "@type": [ "foaf:Agent", "vf:Process" ]

I think for now we can just stay try to make sure that only process can affect the observable state of a resource.

fosterlynn commented 8 years ago

I think for now we can just stay try to make sure that only process can affect the observable state of a resource.

OK, that sounds good as a bottom line, as long as you mean process events. (The finer points of agency are probably a different discussion.)

fosterlynn commented 7 years ago

I would like to re-think this and move away from agent-resource relationships as relates to transfers. In the #32 issue, I haven't yet used any transfers in the examples, just issue-receive processes, which are almost a transfer, but have some aspect of a process. I was toying with getting rid of transfer all together.

But I do think there is a valuable conceptual difference between a process and a transfer. Although we have gone around and around on this a few times. Here goes again. :)

I think for now we can just stay try to make sure that only process can affect the observable state of a resource.

I think we have basically agreed on this. And this is the observable state of the resource itself, aside from any properties that might give it a different "identifier" to its human administrators. So the resource in the world, not the vf:Resource's @id or other properties not observable in the real world.

So there will be cases where things really are a transfer. The resource will have no observable change. However, there is always a "process" of recording a transfer, and I would like to not count that as a process. For example when I did some work at a gas utility right after deregulation in the US, companies would buy and sell quantities of gas at a meter, and nobody ever touched the gas in any way. The transfers were recorded, which took time and bits. But the gas was noticeably not affected. (Not saying this is a good way to run an economy! :frowning_face: )

There will be cases where it is not crystal clear, like transferring $ between bank accounts for example. Is that just recording a transfer, or is that bits of $ changing location? I think we can afford to not worry too much on these things and leave them up to users to decide. Since a issue-receive process and a give-take transfer would be structured in basically the same way, it should be fine. (This is assuming we do not use agent-resource relationship for transfers.)

Speaking of which: I have used give and receive for events of a transfer. I'd like to change that back to give and take, so that "receive" is left for processes.

I still need to do some examples on this to prove or disprove it.... so this is a bit preliminary yet.

gcassel commented 7 years ago

I'm not sure what's happened in your recent discussions, @fosterlynn , but I continue to think that transfer is the most obvious and proper term to indicate the movement of exclusive resource rights (of any sort; use, control, ownership) from one agent to another. Am I missing something?

elf-pavlik commented 7 years ago

@fosterlynn while we looked at possibility of creating 'logical partitions' on resources so that each resource (actually each logical partition) has always one and only one owner. We noticed that it most likely will not work for many kinds of agent <-> resource relationships which change independently.

How do we model case where resource with ownership relation to Alice, changes stewardship relation to Bob and then possession relation to Sandy?

gcassel commented 7 years ago

Exclusive rights to any kind of resource is an artifice, a convention; a social construction. Transfer is a term which can indicate formal agreements of when those constructs have moved between agents.

"Give" and "receive" may apply to physical possession (and responsibility for safekeeping) without having anything to do with exclusive rights to use, modify, or sell etcetera.

fosterlynn commented 7 years ago

@gcassel @elf-pavlik thanks for the quick push-back. :)

I continue to think that transfer is the most obvious and proper term to indicate the movement of exclusive resource rights (of any sort; use, control, ownership) from one agent to another.

Yes I agree. The question is how to model it. Right now I am liking rights as a resource itself, often with underlying resource. And some reference to more detailed agreements, as in your "formal agreements", which can cover more than agent-resource relationships can.

How do we model case where resource with ownership relation to Alice, changes stewardship relation to Bob and then possession relation to Sandy?

Good question. Today I will try out some scenarios to see what devils in the details I can find. But I'm curious, do you see a change of possession as a transfer? I'm thinking that is more of an issue-receive....?

fosterlynn commented 7 years ago

exclusive resource rights (of any sort; use, control, ownership)

Just read this again.... @gcassel interesting you include "use". Do you see necessity for a transfer when someone uses someone else's resource? I can see it in rental, where there is a specific transfer of rights, but in say Sensorica, where tools are lying around for people to use based on a larger ongoing agreement, they record the use event but not anything else. There might be an implied transfer there, but I am not in favor of requiring it.

@elf-pavlik maybe in your "possession" you were thinking of something like an apartment rental? Seems like "rights to possess" is a transfer; handing something over to someone maybe more an issue-receive?

We will need to document this all clearly when we get it all figured out.... :)

elf-pavlik commented 7 years ago

How do we model case where resource with ownership relation to Alice, changes stewardship relation to Bob and then possession relation to Sandy? Good question. Today I will try out some scenarios to see what devils in the details I can find. But I'm curious, do you see a change of possession as a transfer? I'm thinking that is more of an issue-receive....?

Let's use an example of bicycle:

Alice owns a particular bicycle (it has QR code on it with IRI that identifies it)
She leaves for a year to another continent and asks Bob to act as steward of this bicycle and let people requests its use via portals like http://www.cycle.land , http://www.bikesurf.org/ etc.
During one of following weeks, Sandy visits the town and Bob gives him Alice's bike to use it for this one week.

If take snapshot of description of that bike, we would have something like

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8
'@type': 'vf:MaterialResource'
'skos:note': Alice-s bike with QR code on it
'vf-x:ownership': https://alice.example/
'vf-x:stewardship': https://bob.example/
'vf-x:possesion': https://sandy.example/

If we rely on events to change 'state' of resource at different times. We could also follow the same approach to change agent <-> resource relationships. e.g. Reusing terms after vf:Relationship (subject, relationship, object) https://github.com/valueflows/agent#vfagent

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8
'@type': 'vf:MaterialResource'
'skos:note': Alice-s bike with QR code on it
'vf-x:ownership': https://alice.example/
'vf-x:stewardship': https://alice.example/
'vf-x:possesion': https://alice.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/7d756cb1-1391-454e-aef5-9682dd64311f
'@type': 'vf:Transfer'
'vf-x:subject': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
'vf-x:relationship': 'vf-x:stewardship'
'vf-x:fromObject': https://alice.example/
'vf-x:toObject': https://bob.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/b07203fc-6472-498b-926f-b74f08f1aa9f
'@type': 'vf:Transfer'
'vf-x:subject': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
'vf-x:relationship': 'vf-x:possesion'
'vf-x:fromObject': https://alice.example/
'vf-x:toObject': https://bob.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8
'@type': 'vf:MaterialResource'
'skos:note': Alice-s bike with QR code on it
'vf-x:ownership': https://alice.example/
'vf-x:stewardship': https://bob.example/
'vf-x:possesion': https://bob.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://bob.example/c06e7311-2a34-4e6a-b4ef-a33f764695ce
'@type': 'vf:Transfer'
'vf-x:subject': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
'vf-x:relationship': 'vf-x:possesion'
'vf-x:fromObject': https://bob.example/
'vf-x:toObject': https://sandy.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8
'@type': 'vf:MaterialResource'
'skos:note': Alice-s bike with QR code on it
'vf-x:ownership': https://alice.example/
'vf-x:stewardship': https://bob.example/
'vf-x:possesion': https://sandy.example/

fosterlynn commented 7 years ago

Here is snippets of how it could look without requiring agent-resource relationship.

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/7d756cb1-1391-454e-aef5-9682dd64311f
'@type': 'vf:Transfer'
'vf-x:agreement': https://alice.example/stewardship-agreement-2016
'vf:io':
  - 'vf:action': vf:give 
    'vf-x:resource': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://alice.example/
  - 'vf:action': vf:take
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the same bike but bob is keeping track
    'vf-x:agent': https://bob.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/b07203fc-6472-498b-926f-b74f08f1aa9f
'@type': 'vf:Transfer'
'vf-x:agreement': https://alice.example/possession-agreement-20161210
  - 'vf:action': vf:lend
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://bob.example/
  - 'vf:action': vf:borrow
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://sandy.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/b07203fc-6472-498b-926f-b74f08f1aa9f
'@type': 'vf:Transfer'
'vf-x:agreement': https://alice.example/possession-agreement-20161210
  - '@id': https://sandy.example/events/fjskdjl
    'vf:action': vf:return
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://sandy.example/
    'vf-x:eventDate': 2016-12-07
  - '@id': https://bob.example/events/57154724
    'vf:action': vf:repossess
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://bob.example/
    'vf-x:eventDate': 2016-12-08

fosterlynn commented 7 years ago

Here is a yaml example for transferring a piece of a "logical partition" of a material resource.

resources before

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer
'@type': 'vf:MaterialResource'
'skos:note': Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 1

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-41444ss#Lynn
'@type': 'vf:ShareResource'
'skos:note': Lynn ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 100
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Daniel
'@type': 'vf:ShareResource'
'skos:note': Daniel ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 1000
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-ghhk676#Maria
'@type': 'vf:ShareResource'
'skos:note': Maria ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 900
'vf:underlyingResource': https://sens.example/FDM-printer

Transfer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/7d756cb1-1391-454e-aef5-9682dd64311f
'@type': 'vf:Transfer'
'vf:io':
  - 'vf:action': vf:give 
    'vf-x:resource': https://sens.example/FDM-printer-shares-4574564#Daniel
    'vf-x:agent': https://daniel.example/
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:CAD
      'qudt:numericValue': 200
  - 'vf:action': vf:take
    'vf-x:resource': https://sens.example/FDM-printer-shares-hjk43j3#Ahmed
    'vf-x:agent': https://ahmed.example/
    'vf:affectedQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:CAD
      'qudt:numericValue': 200

changed resources

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Daniel
'@type': 'vf:ShareResource'
'skos:note': Daniel ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 800
'vf:underlyingResource': https://sens.example/FDM-printer

'@context': https://w3id.org/valueflows/v1
'@id': https://sens.example/FDM-printer-shares-4574564#Ahmed
'@type': 'vf:ShareResource'
'skos:note': Ahmed ownership share of Sensorica 3d printer
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:CAD
  'qudt:numericValue': 200
'vf:underlyingResource': https://sens.example/FDM-printer

elf-pavlik commented 7 years ago

Here is snippets of how it could look without requiring agent-resource relationship

It seems that in your examples, for each kind of relationship one need to have two distinct actions. If you use give and take for stewardship, how does the system recognize it as different from changing ownership?

gcassel commented 7 years ago

Just read this again.... @gcassel interesting you include "use". Do you see necessity for a transfer when someone uses someone else's resource?

Short answer: no, certainly not in many or most cases. (Although, tangentially, 'rental' is often used as a derogatory term in 'commons' culture.)

@fosterlynn I think that "rights" (or a synonym) is the most broadly useful term in this area of social relationships. As I wrote earlier, all exclusive resource rights (and restrictions) are artificial. This includes the idea of ownership, and the idea that someone needs permission to use someone else's "property". -- For instance, a tenant needing a permission or formal right to dwell in someone else's building. That never requires a transfer. It does typically require a lease.

Of course, some of our artificial ideas about usage and rights may seem practically commonsense or universal. For instance, nonhuman animals sometimes seem possessive about items they've found or used a lot. I suppose this may be doubly true for nonhuman tool-making (some primates, cetaceans, corvids etcetera): individuals can feel possessive of their own labor and physical investments. However, we're well aware (perhaps especially in VF) that rights to "found" or "claimed" physical resources are: (1) socially complicated (2) further complicated by "improvements" created by labor (3) further complicated by relationships between labor, 'owners' and managers.

bhaugen commented 7 years ago

Elinor Ostrom found that successful commons always had a community behind them with some clear governance. So common resources will require some people to be responsible for them, although "the community" "owns" them. And you might need to get permission from a responsible person to use a common resource.

In other words, I think responsibility and usage rights will survive into a non-capitalist economy.

elf-pavlik commented 7 years ago

@fosterlynn: Here is a yaml example for transferring a piece of a "logical partition" of a material resource.

@bhaugen: In other words, I think responsibility and usage rights will survive into a non-capitalist economy.

We could try to write YAML exmample for transferable quotas for usage (time based resource). Actually we can do it for the very same 3d printer which you wrote ownership shares for (as proposed in https://github.com/valueflows/resource/issues/51#issuecomment-239972811 )

fosterlynn commented 7 years ago

If you use give and take for stewardship, how does the system recognize it as different from changing ownership?

Well, could be through different event templates. Or could be be referencing the agreement, which would have those details. @elf-pavlik do you like either of those options?

elf-pavlik commented 7 years ago

In snippets that I wrote, we can see clearly 1) rights to which resource 2) which kind of rights 3) from who to who

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/7d756cb1-1391-454e-aef5-9682dd64311f
'@type': 'vf:Transfer'
'vf-x:subject': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
'vf-x:relationship': 'vf-x:stewardship'
'vf-x:fromObject': https://alice.example/
'vf-x:toObject': https://bob.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/b07203fc-6472-498b-926f-b74f08f1aa9f
'@type': 'vf:Transfer'
'vf-x:subject': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
'vf-x:relationship': 'vf-x:possesion'
'vf-x:fromObject': https://alice.example/
'vf-x:toObject': https://bob.example/

In your version: 1) We can see action but it doesn't make clear if it affects ownership, stewardship 2) We don't know what it means if transfer has give referencing resource A and take referencing resource B - if they can't differ why do we need two references? 3) We don't know what it means if transfer has two events: one with give and one with reposses 4) We don't know what it means if transfer has only one event - if transfer represents agreement between agents about rights to some resource, having just one event with one agent doesn't do it.

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/7d756cb1-1391-454e-aef5-9682dd64311f
'@type': 'vf:Transfer'
'vf-x:agreement': https://alice.example/stewardship-agreement-2016
'vf:io':
  - 'vf:action': vf:give 
    'vf-x:resource': https://alice.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://alice.example/
  - 'vf:action': vf:take
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the same bike but bob is keeping track
    'vf-x:agent': https://bob.example/

'@context': https://w3id.org/valueflows/v1
'@id': https://alice.example/b07203fc-6472-498b-926f-b74f08f1aa9f
'@type': 'vf:Transfer'
'vf-x:agreement': https://alice.example/possession-agreement-20161210
  - 'vf:action': vf:lend
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://bob.example/
  - 'vf:action': vf:borrow
    'vf-x:resource': https://bob.example/f5661764-c6ba-48c1-8be3-511ac673e1f8 # the bike
    'vf-x:agent': https://sandy.example/

gcassel commented 7 years ago

In other words, I think responsibility and usage rights will survive into a non-capitalist economy.

I entirely agree @bhaugen . I'm concerned with making implicit understandings about rights and responsibilities as clear and fair as possible, especially whenever persistent conflicts emerge.

bhaugen commented 7 years ago

What I'd like to do with that set of ideas is explore whether responsibility is the replacement for ownership in a commons-based economy. See https://github.com/valueflows/valueflows/issues/121 @ChristianSi does that seem wrong in any way?

gcassel commented 7 years ago

What I'd like to do with that set of ideas is explore whether responsibility is the replacement for ownership in a commons-based economy.

I think we're mostly in sync here, including your holistic (may I use that term?) conception of a 'bus service'. Each participant role, including something as simple as 'using a service', has different responsibilities.

What I'm currently wondering, @bhaugen , is if you're thinking that the term "responsibilities" could work as an umbrella which implicitly includes the concept of "rights"?

I've mentioned that exclusive/restrictive rights to use resources are artificial. The same could be said, of course, if exclusion or restriction are fundamentally considered to be roles (or relationships) of shared responsibility.

gcassel commented 7 years ago

^ also, it seems entirely possible right now that the term responsibility could replace the term role in Agreement-Based Organization.

bhaugen commented 7 years ago

I think rights and responsibilities go together. If you have the right to use something, you have a responsibility to maintain it in good condition.

elf-pavlik commented 7 years ago

What I'd like to do with that set of ideas is explore whether responsibility is the replacement for ownership in a commons-based economy.

I know that you did some work with Faircoin so let's take it as example. IMO in currencies like faircoin it all pretty much boils down to owning them. One can't do anything else with Faircoins than own it and change ownership (by moving them to another address). I also find it bit awkward to talk about 'responsibility' for some faircoins.

I think many people relate ownership with potential to benefit in some way from that. While responsibility often relates to making some effort. Ownership seems to relate more to control than responsiblity, while I agree that I would like that people who take the responsibility also have the control!

bhaugen commented 7 years ago

I also find it bit awkward to talk about 'responsibility' for some faircoins.

Sure, and mostly I don't, except for collective wallets. Somebody needs to be responsible for those. Faircoin has a lot of them. One of them just went a little crazy and needed to be rebuilt. Good thing somebody was responsible. By the way, that person did not own the coins.

When I talk about responsibility as a replacement for ownership in a commons-based economy, though, I am usually thinking about material resources. And it remains to be seen if a commons-based economy will use any kind of money. We don't know yet. I can't think of a fully working example. I just know that's what a lot of people are talking about these days.

gcassel commented 7 years ago

I also find it bit awkward to talk about 'responsibility' for some faircoins.

Sure, and mostly I don't, except for collective wallets.

Collective wallets are IMO like any shared 'ownership', in that they create (at least a few) rights and responsibilities. Like many expectations, those rights and responsibilities are probably implied more often than they're formally stated.

Anyway... there's a sort of responsibility which the issuer of a currency has to people which hold substantial amounts of that currency. It's mutually expected (between the issuer and holders) that the currency won't unpredictably and explosively depreciate, potentially to the point of worthlessness-- which can happen via a chain reaction of divestiture by many or most holders of that currency. That risk can be minimized by having a healthy community/ network of currency users.

One big currency risk factor is an excessive amount (positive sum) of circulated currency in relation to the size of the economy which uses it. Mutual credit/debt relationships are more sustainable, in an important sense, because they distribute and localize risk. However, all kinds of awful things can happen if currency is created as loans (debt) by for-profit organizations such as US banks. People are becoming more aware of that.

Of course, this is all tangential to this Issue. However, I'm really glad that you guys are thinking lots of currency transfers and related issues. I think that complementary currencies are going to become extremely important.

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/29.

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

valueflows / exchange