Recording a vf:Transfer vs vf:Transportation

[fosterlynn]

once again I want to emphasise that we should treat vf:Transfer differently from vf:Process!

I want to dig into this some more. (Sorry!) I have been bothered by where this line is drawn, but haven't been able to put my finger on it. Now it is starting to sort itself out in my mind. :)

How about this way of looking at it? There is a distinction between Transportation of a resource where it changes Location, and Recording of a Transfer. It doesn't seem right to me that the recording of a decrease in one virtual account and an increase in another virtual account, to take an example with very little material change, is Transportation or is a change of Location of a resource.

Taking it one step out, a bank transfer is like this except the decrease and increase of different accounts probably occur on different servers controlled by different banks. But still, I don't think this is Transportation. Where the servers or banks are located is irrelevant. It is recording a Transfer, which does not need any data or vocabulary other than what we already have in the Transfer itself.

There are other examples that may involve more work or more electrons, like say printing and signing a lease agreement, where I still think this is not useful as a Process. It is recording a Transfer. In that case, the landlord may have a process there and want to record his work leasing property, including printing off lease agreements. But that is not the same as the actual recording of the transfer, which just marks that the Transfer has occurred.

Sometimes there actually is both Transportation and a Transfer, I think when moving more material goods in addition to transferring rights to them.

Does this direction make sense to anyone?

[elf-pavlik]

1. How do you describe vf:Transfer of rights to currency deposited on particular bank account, which happens within that one bank account - use case Currency exchange (ISO4217)
2. How do you describe a bank transfer (not vf:Transfer) where agent moves currency credits between two bank accounts, both of those accounts owned by the same agent. Does it even need vf:Transfer if ownership rights to that currency don't change at all (same agent keeps them all the time, just stores the digital coins on different account)

[fosterlynn]

Good use cases!

How do you describe vf:Transfer of rights to currency deposited on particular bank account, which happens within that one bank account - use case Currency exchange (ISO4217)

I think in this case, there would be 2 virtual accounts as part of each bank account (the underlying resource). So there would be a vf:Transfer from Lynn to Sam for 100 USD, decreasing Lynn's virtual USD resource and increasing Sam's USD virtual resource. And a vf:Transfer from Sam to Lynn decreasing Sam's virtual EUR resource and increasing Lynn's virtual EUR resource.

How do you describe a bank transfer (not vf:Transfer) where agent moves currency credits between two bank accounts, both of those accounts owned by the same agent. Does it even need vf:Transfer if ownership rights to that currency don't change at all (same agent keeps them all the time, just stores the digital coins on different account)

Even though there is only one agent involved, that agent would still need to know what is in it's accounts, so I think the agent will want to record a vf:Transfer from the agent to the agent, decreasing the first bank account resource and increasing the second bank account resource. (Good to use this one to revisit the definitions.)

I am proposing that there is no vf:Transportation needed in either of these cases. All that is needed is the recording of the vf:Transfer(s).

[bhaugen]

I am proposing that there is no vf:Transportation needed in either of these cases. All that is needed is the recording of the vf:Transfer(s).

I am rethinking this since my digital currency experience, and also thinking about wire transfers. A fee is charged in both cases, which is for handling the electronic transfer. It is more-or-less a transportation service, just with bits instead of vehicles.

[elf-pavlik]

I am rethinking this since my digital currency experience, and also thinking about wire transfers. A fee is charged in both cases, which is for handling the electronic transfer. It is more-or-less a transportation service, just with bits instead of vehicles.

Currently I see it in similar way. Sometimes you also have additional shipping service involved eg. https://transferwise.com/ I wouldn't say that at any point in time they vf:own the money which they move through their worldwide accounts. Even that it stays deposited in between on bank accounts they 'legally' own.

I think in this case, there would be 2 virtual accounts as part of each bank account (the underlying resource). So there would be a vf:Transfer from Lynn to Sam for 100 USD, decreasing Lynn's virtual USD resource and increasing Sam's USD virtual resource. And a vf:Transfer from Sam to Lynn decreasing Sam's virtual EUR resource and increasing Lynn's virtual EUR resource.

In case of vf:Transfer of currency which doesn't change an account we can fully handle it in VF environment. I wouldn't expect mainstream banks to adopt VF any soon so in near future we will need to define a bridge which will use something like https://openbankproject.com/ (which banks also adopt very slowly and also just few banks) and reflect movement of currencies to VF environment (a bridge or adapter to non VF environment).

Yesterday we discussed considering that vf:Transfer deals with changing agent in particular relationship to particular resource. Transfer of currency seems to deal more with moving currency between virtual stock/accounts which may or may NOT imply some change of agent in ownership relationship to that money. I believe we need to work in valueflows/resource on physical and virtual stocks first, before we can move further with this issue here.

[bhaugen]

We also need to think about environments with virtual accounts and moving money between virtual accounts, e,g, Sensorica and my.enspiral, for two. Enspiralites think of my.enspiral as their internal bank, and move money around at will. They are planning a redesign and re-implementation. @dan-mi-san is involved in that project, and also VF, bringing us RobinHood stories. I think that kind of thing will happen more often, and will be adding some link dumps about another example later today.

[bhaugen]

P.S. those virtual account implementations have no service charge for transfers.

[fosterlynn]

I am rethinking this since my digital currency experience, and also thinking about wire transfers. A fee is charged in both cases, which is for handling the electronic transfer. It is more-or-less a transportation service, just with bits instead of vehicles.

Yes the fee is interesting, and happens a lot. Still seems like a vf:Transfer to me, from whichever party pays the fee to the servicer, or maybe maybe a second Receive on the same vf:Transfer, although I'm a bit nervous about that.

It is more-or-less a transportation service, just with bits instead of vehicles.

Vaguely. I don't think even bits actually flow from one stock resource to another. Two resources are just changed, which I'm trying to make a recording of a transfer (non process) rather than a transport (process).

I suppose the fee is paying for a service though, whether transportation or not. Perhaps the servicing agent would record something to represent the service of facilitating or recording the transfer, in addition to recording the fee itself.

This seems different though than creating a process to get the "resource flow" (let's call it for the moment) of currency from one "place" to another, irrespective of if some agent is providing a service. I think everything you need to know about the resources (whether thinking stock or flow) have been handled by the transfer itself, and don't want or need a process to get anything somewhere else.

Maybe even someone did some work, or some equipment was used, or whatever. But those things aren't the events that increment/decrement the currency resources involved in a transfer, I don't think. Those create a service.

If you had a process, how would it work? I suppose the transfer would only change the agent rights or relationship to some quantity of a unit, but not affect any resources, and the process would affect the bank accounts? Seems overly complex for no good reason that I can think of. Or in that case, we just drop transfer as part of events and resource flows all together, and put the rights question somewhere else in the model, like change of an agent-resource relationship or wherever? Maybe vf:Transfer is a subclass of vf:Process and is not about rights, but is more material? (Not making recommendations!)

Transfer of currency seems to deal more with moving currency between virtual stock/accounts which may or may NOT imply some change of agent in ownership relationship to that money.

I see you are moving that direction, @elf-pavlik (As often happens to me, there are 4 more replies and I haven't sent mine yet. :blush: )

[fosterlynn]

I think in this case, there would be 2 virtual accounts as part of each bank account (the underlying resource). So there would be a vf:Transfer from Lynn to Sam for 100 USD, decreasing Lynn's virtual USD resource and increasing Sam's USD virtual resource. And a vf:Transfer from Sam to Lynn decreasing Sam's virtual EUR resource and increasing Lynn's virtual EUR resource.

In case of vf:Transfer of currency which doesn't change an account we can fully handle it in VF environment. I wouldn't expect mainstream banks to adopt VF any soon

Right, my definition had nothing to do with the bank, they see no transfers from their perspective. But Sam and Lynn clearly do keep track of who has which portion of the bank accounts they share.

[bhaugen]

What happens in the case of a blockchain currency is that the blockchain validates and confirms the transaction: the fee goes to the agents who provide those services: for Bitcoin, the miners.

In bank wire transfers, it's a similar service, just not the same mechanism.

[elf-pavlik]

Yes the fee is interesting, and happens a lot. Still seems like a vf:Transfer to me, from whichever party pays the fee to the servicer

What happens in the case of a blockchain currency is that the blockchain validates and confirms the transaction: the fee goes to the agents who provide those services: for Bitcoin, the miners.

So far we discussed vf:Service as output of vf:Process, now it looks that vf:Transfer also has outpus which may yield vf:Service.

Maybe vf:Transfer is a subclass of vf:Process and is not about rights, but is more material? (Not making recommendations!)

We currently have vf:Transportation defined as subclass of vf:Process with two proposed events/flows specific to it: pick-up (process inflow) & drop-off (process outflow). This process has a specific purpose to move vf:Resource from one location (Stock?) to another location, which in practice decrements amount in one and increments amount in the other one. It has nothing to do with rights to that resource resource which gets relocated.

I see vf:Transfer as something that deals only with rights (conceptual) or relationships in general, between agents and resources. It has nothing to do with the location of the actual (analogue or digital) resource.

If you would like to define vf:Transfer as subclass of process, could you please explain how you see it differ from vf:Transportation?

[bhaugen]

I think the service of validating and confirming money transfers is different enough from transportation to require its own analysis and maybe some different names. Pickup and dropoff don't seem to fit, for example, and the blockchains and clearing centers are not much like vehicles.

[fosterlynn]

I see vf:Transfer as something that deals only with rights (conceptual) or relationships in general, between agents and resources. It has nothing to do with the location of the actual (analogue or digital) resource.

But Location is different than Resource. Resource can be at a Location. I don't see the bank account or virtual account as a Location, but rather a Resource. I want to decrement one resource and increment another resource, and I don't care where they are located. Is that transportation?

If you would like to define vf:Transfer as subclass of process, could you please explain how you see it differ from vf:Transportation?

No, I was just taking it to its logical conclusion. I don't want to have both a Transfer and a Process representing the "movement" of currency from one account to another. One or the other.

[elf-pavlik]

But Location is different than Resource. Resource can be at a Location. I don't see the bank account or virtual account as a Location, but rather a Resource.

I really think we can't move further here before we make few PRs to valueflows/resource which define vf:Stock and possibly vf:CurrencyAccount.

If you see a bank account as a resource, do you transfer rights to that bank account or rights to the particular amount of currency stored/deposited on it? I think we always need to keep in mind those 4 cases ('transfer' != vf:Transfer as currently defined):

• 'transfer' of 50USD - 2 agents & 1 bank account
• 'transfer' of 50USD - 1 agent & 2 bank accounts
• 'transfer' of 50USD - 2 agents & 2 bank accounts
• 'transfer' of 50USD - 2 agents & 2 bank accounts & 1 currency delivery service like https://transferwise.com/

Once we have sample data for it, which uses terms in vf: namespace. We can think of it and discuss it more precisely. Than iterate adding Faircoin example and so on.

[ahdinosaur]

@fosterlynn thanks for saying what was on my mind as well. :smile:

I really think we can't move further here before we make few PRs to valueflows/resource which define vf:Stock and possibly vf:CurrencyAccount.

@elf-pavlik what are we missing that requires yet more terms?

i probably am missing the gut of this discussion, but why not model a bank as being delegated control of all the resources within it (of resource type corresponding to the currency involved), then my bank account is the resources i have the 'rights' to but delegate to the bank? in this way, there's not an "underlyingResource" but more a "delegatedAuthority" or just a "context" as we've used it before. then since currency resource types are substitutable, the bank can transfer in and out using any of it's delegated resources as agents deposit and withdraw in and out of the context of the bank. although, since an agent could have multiple "accounts", maybe an account is a fractal agent within another agent. :)

[coopchange]

Like @ahdinosaur I feel like I might be off track here (mostly as I don't know what's needed in terms of vf:Stock or vf:Account/Currency), and I see the bank as being an interface (intermediary/ tool) by which one does Transactions using whatever currencies/goods they have rights to in the bank.

Transfer makes more sense than Transportation, in a gut sense, and in terms of digital currencies

I don't think even bits actually flow from one stock resource to another. Two resources are just changed, which I'm trying to make a recording of a transfer (non process) rather than a transport (process).

For blockchain currencies, I think the action accompanying the Transfer appears more like a Transform; when a Transaction occurs, a user will propose a Transform of the distributed ledger (the blockchain) that reflects the desired Transfer of digital assets - after it is verified that this Transform is possible (that the paying user has the requisite Resource or Currency to actualize the proposed change to the system) then the Transfer is recorded to the blockchain and the distributed ledger itself is Transformed on all of the computers that are part of the network.

printing and signing a lease agreement, where I still think this is not useful as a Process. It is recording a Transfer. In that case, the landlord may have a process there and want to record his work leasing property, including printing off lease agreements. But that is not the same as the actual recording of the transfer, which just marks that the Transfer has occurred.

It seems like this is a complex __ (as Lynn mentions, preferably not a Process?). In my eyes, here too Transform is a useful concept as a way to semantically conceptualize the recording of the transfer. So that use case would look something like: intention to Transfer => Print Process => Transform (the recording of the Transfer) => completion of Transfer (new agent-relationships to Resource) ...

in some cases it might also require other Processes or Transforms depending on the institutional agreements - perhaps the previous land owner must upload the signed paper to a public repository - I imagine this again would require a Process and a Transform (scanning the document to create a digital copy and then a Transform of whatever database so that it contains the code that vectorally represents the digital copy).

That last bit also draws to light IMO the difficulty with Transportation applying to digital assets; a digital asset can stay on my computer but someone could copy the asset code-line for code-line and reproduce it on their machine; this in effect is Transfer, right? As it changes the nature of agent-relationships to the Resource.

[bhaugen]

By the way, the underlying resource idea was my fault. We haven't implemented it in our own code yet. It arose from virtual accounts as in my.enspiral that are different peoples' sections of a real bank account, trying to figure out how to reconcile the two. The term comes from financial derivatives, which we all know sank the world economy in 2008, so I should probably be chastised for using it...

[fosterlynn]

Hopefully our underlying resource won't be THAT underlying! One level max where at least we can actually find the underlying resource somewhere. :)

[fosterlynn]

If you see a bank account as a resource, do you transfer rights to that bank account or rights to the particular amount of currency stored/deposited on it?

I see like a stock resource, and you can transfer rights to part of the stock (currency stored in it).

then my bank account is the resources i have the 'rights' to but delegate to the bank? in this way, there's not an "underlyingResource" but more a "delegatedAuthority" or just a "context" as we've used it befor

@ahdinosaur to clarify: The bank account is an underlying resource to a virtual account, ala my.Enspiral. Or not, if someone is not using virtual accounts with their bank account then they don't need the concept.

[bhaugen]

But please think up a better name...assuming we need the concept. The future_my_enspiral and all of the other groups that use some form of virtual accounts need something.

[ahdinosaur]

But please think up a better name...assuming we need the concept. The future_my_enspiral and all of the other groups that use some form of virtual accounts need something.

i don't mean to say vf:underlyingResource is a bad idea, in fact i've been super keen since it's been proposed because it is a solid attempt to handle the my.enspiral use case. my comment about is a new seemingly more simple idea, that i just came up with based on reading this thread, it might be better or worse i'm not sure.

[bhaugen]

Um, yes?

a new seemingly more simple idea, that i just came up with based on reading this thread,

You gonna keep us in suspense?

[ahdinosaur]

i probably am missing the gut of this discussion, but why not model a bank as being delegated control of all the resources within it (of resource type corresponding to the currency involved), then my bank account is the resources i have the 'rights' to but delegate to the bank? in this way, there's not an "underlyingResource" but more a "delegatedAuthority" or just a "context" as we've used it before. then since currency resource types are substitutable, the bank can transfer in and out using any of it's delegated resources as agents deposit and withdraw in and out of the context of the bank. although, since an agent could have multiple "accounts", maybe an account is a fractal agent within another agent. :)

• each fractal agents 'owns' resources, could be a group, person, or sub-agent account.
• "depositing" resources in a "bank" is transferring substitutable resources to a group (or group account) that you are a part of.
• "withdrawing" resources from a "bank" is a group (or group account) that you are a part of transferring substitutable resources to you.
• your "balance" is how much resources you've transferred (or have been transferred with your name on them) to the group (or group account) minus how much resource you've been transferred from the group.

wouldn't this remove the need for vf:underlyingResource and be more general for how we handle transfers? or maybe not and i'm missing something.

[ahdinosaur]

hmm, maybe the core of my suggestion is for an account to be a type of agent, as a delegated virtual agent, rather than a resource, where the virtual agent has a "delegatedAuthority" (or something) relationship within the real agent.

part of this thinking is related to this Patchwork message (%xKPuGx396IlsCM2YYKNc3jKpxqDw4TsQAb5x80WWCew=.sha256):

@keks says: I don't know if this has come up before but we could use fractal identities both ways. My identity could be composed of the ssb logs of all my devices.

[elf-pavlik]

• your "balance" is how much resources you've transferred (or have been transferred with your name on them) to the group (or group account) minus how much resource you've been transferred from the group.

wouldn't this remove the need for vf:underlyingResource and be more general for how we handle transfers? or maybe not and i'm missing something.

How do you see it relating to my comment here: https://github.com/valueflows/exchange/issues/6#issuecomment-214384889

In short, Instead of trying to nest virtual accounts I would focus on what we want to capture and in this case it seems that we try to describe ownership shares of certain virtual resource (monetary currency) deposited on particular bank account (also virtual).

[fosterlynn]

• your "balance" is how much resources you've transferred (or have been transferred with your name on them) to the group (or group account) minus how much resource you've been transferred from the group.

wouldn't this remove the need for vf:underlyingResource and be more general for how we handle transfers? or maybe not and i'm missing something.

This is actually true of any rea:EconomicResource, irrespective of its underlying-ness. It can be derived from the sum total of the rea:EconomicEvents affecting it. Bob says Bill McCarthy doesn't instantiate resources, just calculates them when you need them. I think that for our purposes that is too pure, and doesn't scale, and am happy to have vocabulary that describes resources. But hey.

[ahdinosaur]

How do you see it relating to my comment here: #6 (comment)

ah yeah, like that. :smile:

[elf-pavlik]

IMO if we change ownership over monetary currency deposited on singe banking account. We have vf:Transfer. But as soon as we move currency between two different bank accounts, we need vf:Transport to do that. Most of this issue relates to integration with 'legacy' (not WWW) system, For native VF (or WWW) monetary currency, one would never need vf:Transport. But if we want to treat legacy monetary currencies in a way similar to other stock resources. We can't move apples between two different warehouses without having an instance of vf:Transport in a flow.

[ahdinosaur]

But as soon as we move currency between two different bank accounts, we need vf:Transport to do that. Most of this issue relates to integration with 'legacy' (not WWW) system, For native VF (or WWW) monetary currency, one would never need vf:Transport. But if we want to treat legacy monetary currencies in a way similar to other stock resources.

i'm not sure i understand why we can't use vf:Transfer to move currency between two different bank accounts. there's no physical transport, it's a few bits changed here and a few bits changed there, no different from other vf:Transfer use cases in my opinion.

[bhaugen]

In practical terms, to me, it depends on if the transfer includes a fee for doing so. E.g. bank wiretransfers (bank to bank, especially between countries) or blockchain transfers or paypal or credit cards. Different accounts in the same bank, or different virtual accounts in the same bank account, no.

[elf-pavlik]

i'm not sure i understand why we can't use vf:Transfer to move currency between two different bank accounts. there's no physical transport, it's a few bits changed here and a few bits changed there, no different from other vf:Transfer use cases in my opinion.

I think we should follow up on @fosterlynn Transfer of agent-resource-relationship first.

• vf:Transfer - affects only relationship between agent and resource, doesn't affect resource itself in any way
• vf:Process - affects only resources themselves, doesn't affect relationship of resources to agents in any way, vf:Transfer related commitments and claims should deal with changes to relationships between agents and resources related to I/O of the process, combined with rules for composing group agents and resource distribution algorithms.

With nowadays mainstream banking, we have this issue that accounts pretty much represent relationship between agent and 'resource'. So transfer (not to confuse with vf:Transfer) of digital credits between bank accounts often implies change of ownership. To map it to VF we might always need both vf:Transfer and vf:Transport (between accounts). It also depends how we will model currencies and if we model them as vf:Resource, we need to see if some type of process, other than vf:Transport change those currency resources MonetaryCurrency a 'transfer only' resource?

IMO we should expect that trying to treat ISO4217 currencies as vf:Resource might come with some challenges and stay patient while we work on that. They (those ISO4217 currencies) also have this 'magic' aspect to them that banks can 'create' more of it, without process which has I/O constrains similar to natural resources (eg. apples) or digital resources (eg. storage or bandwidth)

[bhaugen]

All non-physical-commodity-based currencies I know of have that magic aspect. Debt creates more money in legal tender, same in mutual credit currencies. Blockchain currencies have miners or minters.

Might be some exceptions; I am not a student of the genre.

[elf-pavlik]

I added two new use cases which we can include looking at this issue

• Timebank
• Mutual Credit

AFAIK both systems usually don't charge fees for transferring currencies, maybe some annual service fees.

I think that we can define vf:Transfer as something operating only on currencies (as I suggest in https://github.com/valueflows/valueflows/issues/128 ) and use vf:Transportation only with physical resources (we may also need something later for moving data on the internet).

For fees related to transferring not native web currencies. We can model a currency transfer service which one can receive, often in exchange for same type of montetary currency as transferred one. This should also work with services like https://transferwise.com/ and Faircoin. In VF we would have two instances of vf:Transfer 1) Alice -> Bob 2) Alice -> Bank

2nd should reference received currency transfer service as reciprocal resource/event (whatever we use for services)

[elf-pavlik]

I think we agreed that material goods, which require transportation, can NOT move between locations with just vf:Transfer. Thinking around FOB (origin/destination)

With FOB and two other possible cases we have:

• the vf:Transfer of ownership happens already before vf:load - recipient already owns the resource but it still stays located at provider site
• in FOB origin (shipping point) the vf:load does trigger the vf:Transfer of ownership
• in FOB destination the vf:unload does trigger the vf:Transfer of ownership
• the vf:Transfer of ownership happens sometimes after the vf:unload event - provider still owns the resource but it already stays located at recipient's site

I think all those options make sense. Also in FOB we have situation where either provider or recipient have ownership rights to the resource, but it stays located at carriers site (or vehicle). I think carrier in most cases newer has ownership rights to the resource, even that it has them in possession.

[fosterlynn]

All of that makes sense....

[gcassel]

All of that makes sense to me too. :)

[fosterlynn]

Here is a yaml example, starting with @elf-pavlik 's simplified bike transportation example from here, https://github.com/valueflows/process/issues/21#issuecomment-238098269. Simplified to less bikes, got rid of the containers (I think it would work fine with containers too).

• There is a transfer FOB destination, when the vf:unload triggers a transfer.
• The service can be transferred immediately (which it was in real life).
• Modeling duality between transfers at a low level rather than using Exchange, which I have wanted to do for a while.

Caveats: Names need some work. My yaml probably needs some work. Trying out the structure for feedback.

Resource state

@context': https://w3id.org/valueflows/v1
'@id': https://coride.example/inventory/0030b345-c9f9-4e3a-a5a6-b45a8137aa05#stock
'@type': vf:Resource
'vf:category': prodont:Bicycle
'vf:model': openbike:miniroller
'vf:serialNumber': 0030b345-c9f9-4e3a-a5a6-b45a8137aa05
'skos:note': one of the bikes
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 1
'vf:currentLocation':  https://coride.example/bikeshed#location
'vf:currentAgentResourceRelationship':
  - 'vf:relationshipType': Custodian
    'vf:agent': https://coride.example#agent

@context': https://w3id.org/valueflows/v1
'@id': https://cohouse.example/inventory/apples#stock
'@type': vf:Resource
'vf:category': prodont:Apple
'skos:note': store of lovely apples
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 20
'vf:currentAgentResourceRelationship':
  - 'vf:relationshipType': Owner
    'vf:agent': https://cohouse.example#agent

Transportation

'@context': https://w3id.org/valueflows/v1
'@id': https://wemove.example/818f30f4-c119-4024-b4c3-abd7bea4920b#process
'@type': vf:Transportation
'skos:note': moving bicycle between two sheds managed by different agents
'vf:io':
  - '@id': '#input-1'
    '@type': vf:ResourceEvent
    'vf:action': vf:load
    'vf:resource': https://coride.example/inventory/0030b345-c9f9-4e3a-a5a6-b45a8137aa05#stock
    'vf:location': https://coride.example/bikeshed#location
    'vf:eventQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 1
    'vf:fromAgent: https://coride.example#agent
    'vf:toAgent': https://wemove.example#agent
  - '@id': '#output-1'
    '@type': vf:ResourceEvent
    'vf:action': vf:unload
    'vf:resource': https://cohouse.example/inventory/0030b345-c9f9-4e3a-a5a6-b45a8137aa05#stock
    'vf:location': https://cohouse.example/station-12#location
    'vf:eventQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 1
    'vf:fromAgent: https://wemove.example#agent
    'vf:toAgent': https://cohouse.example#agent
    'vf:transfer':
        '@id': '#transfer-1'
        '@type': vf:Transfer
        'vf:relationshipType': Custodian
        'vf:toAgent': https://cohouse.example#agent
        'vf:resource': https://cohouse.example/inventory/0030b345-c9f9-4e3a-a5a6-b45a8137aa05#stock
  - '@id': '#output-3'
    '@type': vf:ResourceEvent
    'vf:action': vf:create
    'vf:resource':
      '@id`: https://wemove.example/cee4518b-e5d8-4313-acb3-df0f9d3dc75d#service
    'vf:eventQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 1
    'vf:fromAgent': https://wemove.example#agent
    'vf:toAgent': https://wemove.example#agent
    'vf:transfer':
        '@id': '#transfer-2'
        '@type': vf:Transfer
        'vf:relationshipType': Receiver
        'vf:toAgent': https://cohouse.example#agent
        'vf:resource':
            '@id`: https://wemove.example/cee4518b-e5d8-4313-acb3-df0f9d3dc75d#service

Resource state

@context': https://w3id.org/valueflows/v1
'@id': https://cohouse.example/inventory/0030b345-c9f9-4e3a-a5a6-b45a8137aa05#stock
'@type': vf:Resource
'vf:category': prodont:Bicycle
'vf:model': openbike:miniroller
'vf:serialNumber': 0030b345-c9f9-4e3a-a5a6-b45a8137aa05
'skos:note': one of the bikes
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 1
'vf:currentLocation': https://cohouse.example/station-12#location
'vf:currentAgentResourceRelationship':
  - 'vf:relationshipType': Custodian
    'vf:agent': https://cohouse.example#agent

'@context': https://w3id.org/valueflows/v1
'@id`: https://wemove.example/cee4518b-e5d8-4313-acb3-df0f9d3dc75d#service
'@type`: vf:Service
'skos:note': transportation service of 1 bicycle
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 1
'vf:currentAgentResourceRelationship':
  - 'vf:relationshipType': Receiver
    'vf:agent': https://cohouse.example#agent

Payment for service

'@context': https://w3id.org/valueflows/v1
'@id': https://cohouse.example/fdafafdsdasf#process
'@type': vf:Process
'skos:note': giving apples in exchange for moving bike
'vf:io':
  - '@id': '#input-10'
    '@type': vf:ResourceEvent
    'vf:action': vf:out
    'vf:resource': https://cohouse.example/inventory/apples#stock
    'vf:eventQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 15
  - '@id': '#output-11'
    '@type': vf:ResourceEvent
    'vf:action': vf:in
    'vf:resource': https://wemove.example/inventory/apples#stock
    'vf:eventQuantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 15
    'vf:transfer':
      '@id': '#transfer-3'
      '@type': vf:Transfer
      'vf:relationshipType': Owner
      'vf:toAgent': https://wemove.example#agent
      'vf:resource': https://wemove.example/inventory/apples#stock
      'vf:exchangedFor': 
        '@id': '#transfer-2'
        'vf:eventQuantity':
          '@type': qudt:QuantityValue
          'qudt:unit': unit:Each
          'qudt:numericValue': 1

Resource state

@context': https://w3id.org/valueflows/v1
'@id': https://wemove.example/inventory/apples#stock
'@type': vf:Resource
'vf:category': prodont:Apple
'skos:note': traded apples
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 15
'vf:currentAgentResourceRelationship':
  - 'vf:relationshipType': Owner
    'vf:agent': https://wemove.example#agent

@context': https://w3id.org/valueflows/v1
'@id': https://cohouse.example/inventory/apples#stock
'@type': vf:Resource
'vf:category': prodont:Apple
'skos:note': store of lovely apples
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 5
'vf:currentAgentResourceRelationship':
  - 'vf:relationshipType': Owner
    'vf:agent': https://cohouse.example#agent

[elf-pavlik]

Thank you @fosterlynn, could you quickly add version where vf:Transfer happens before or after vf:Transport? So we don't have transport here but just change of 'Custodian' relationship for `https://coride.example/inventory/0030b345-c9f9-4e3a-a5a6-b45a8137aa05#resource'. If you prefer we can work on that version which doesn't involve transport in https://github.com/valueflows/exchange/issues/29

[elf-pavlik]

Payment for service looks like moving a resource between two stocks at the same location. I think for that we can define split/merge 'stock operations' as I suggested in https://github.com/valueflows/resource/issues/44

I also don't think such stock operations need give and receive, generic vf:outflow and vf:inflow should work. Actually I wrote snippets for such cases in https://github.com/valueflows/process/issues/21#issuecomment-238098269 (check-in & check-out).

If location changes, I would still use vf:Transportation with only vf:load and vf:unload events (instead of give and receive).

What do you think about discussing vf:Transfer specific details in #29 and then in this issue focus on relating vf:Transfer to relevant process (or processes): vf:Transportation, vf:Transformation, or if needed some new vf:StockOperation (for split/merge).

[fosterlynn]

Payment for service looks like moving a resource between two stocks at the same location. I think for that we can define split/merge 'stock operations' as I suggested in valueflows/resource#44

Basically. I'm trying to come up with something that is a process event (since you won't allow it to be a transfer :sweat_smile: ) that is less than vf:Transportation vf:load and vf:unload because there really isn't any transportation that is meaningful. So in this example, the person probably just picked out some apples from their storage place, put them in a bag, and handed it to the other person on the spot. Or the example of I hand you a cookie and you hand me a glass of milk. Or in my not-yet-published vendor managed inventory example, a contractor picks out some bolts or nuts from a bin and walks to the cash register. Basically the only thing we need to do is decrement some stock resource.

@bhaugen said that in manufacturing this would be "issue" and "receipt". But those aren't universal to all domains. Once you issue a resource, it is gone from that inventory (and now buried in some process black hole where it will probably physically disappear during the process). So I re-purposed the old transfer event types, which really are the same thing as they were, there is no creating going on whatsoever. I suppose we could use the generic vf:inflow and vf:outflow, but those don't specify what is really going on, and I'd rather have something that is specific to those event types. Also event types can hopefully know their resource effect, and vf:inflow doesn't know, while vf:give knows to decrement. I'm open to ideas on the terms, of course.... :blush:

If location changes, I would still use vf:Transportation with only vf:load and vf:unload events (instead of give and receive).

I agree. If you need to record a location change, definitely. If you need to record anything about the transportation itself, definitely. And then there are probably gray in-between areas where people can just pick what works for them.

What do you think about discussing vf:Transfer specific details in #29 and then in this issue focus on relating vf:Transfer to relevant process (or processes): vf:Transportation, vf:Transformation, or if needed some new vf:StockOperation (for split/merge).

I'll try. :smile: In this use case, the service kind of led me into finishing the sequence. And it was cool that this attempt at using process events to trigger transfers led to a resolution of the vf:Service issue where once you have delivered a service, it is already transferred in reality. I liked that.

[bhaugen]

Also event types can hopefully know their resource effect,

That is the main purpose of event types: to define that logic once. Otherwise it gets spread out all over the place, inconsistently.

[fosterlynn]

Payment for service looks like moving a resource between two stocks at the same location. I think for that we can define split/merge 'stock operations' as I suggested in valueflows/resource#44

Basically. I'm trying to come up with something that is a process event (since you won't allow it to be a transfer :sweat_smile: ) that is less than vf:Transportation vf:load and vf:unload because there really isn't any transportation that is meaningful.

I'd be open to thinking about vf:Transfer as a subclass of vf:Process, along with vf:Transformation and vf:Transportation. Then just not use the "transfer" term when talking about changing resource-agent-relationships of ownership etc. Although I don't know what we could use, maybe something about rights?

Thinking out loud, not proposing....

We probably need to try a use case where the resource is the rights to an underlying resource.... rental maybe.

[fosterlynn]

I'd be open to thinking about vf:Transfer as a subclass of vf:Process, along with vf:Transformation and vf:Transportation.

It would be something like change of physical possession but not change in any rights (or location). Transportation would be driven by change in location (also could involve change of possession, or not).

[elf-pavlik]

I'd be open to thinking about vf:Transfer as a subclass of vf:Process, along with vf:Transformation and vf:Transportation.

👎

• vf:Process deals only with resources and locations, having nothing to do with 'rights' over resources or resource <-> agent relationships
• vf:Transfer deals only with resource <-> agent relationships, having nothing to do with incrementing or decrementing actual ('underlying') resource/stock or locations.

I find this distinction very important. Otherwise we don't distinguish resources from rights to them, we may end up with rights to rights to rights to ... wait do we still even have any 'underlying resource' related to all those layers of rights or we just completely drifted into our imagination 😉

[fosterlynn]

I was making a new kind of vf:Transfer that does not change any rights (changing the definition), when I suggested making it a process. I was making something where the resource could change physical possession, which affects availability and coordination, not rights at all. To change rights, we would have to trigger another event that does that.

I guess the term Transfer is too hard to move over into process land. I'll try to think of another; or maybe we can use vf:Transportation, but the location doesn't change, so neither vf:Transformation nor vf:Transportation was working for me.

[fosterlynn]

^ further clarification: This would not change any agent-resource relationships, just have a fromAgent and a toAgent in the event to denote the change of physical possession. We could save agent-resource relationships for all the rights related stuff.

[gcassel]

I guess we have to separate the concept of rights from the concept of responsibility-- because if you're in possession (like a delivery driver) you are responsible for a resource, but don't have use-rights.

In theory, I guess that vf:Transfer should be able to apply separately to any specific rights or responsibilities associated with a specific resource. For instance, transferring the responsibilities of possession (don't damage or lose this) to a delivery driver until a customer has acknowledged receipt of an item.

[fosterlynn]

@gcassel that is interesting, yes it starts to get fuzzier with responsibility. And both could get detailed in an agreement. I tend to think that possession should not be equated with responsibility, although they will track quite a bit in common sense practice.

[elf-pavlik]

I was making a new kind of vf:Transfer that does not change any rights (changing the definition), when I suggested making it a process. I was making something where the resource could change physical possession, which affects availability and coordination, not rights at all.

I understand that resource doesn't change location and we don't try to 'bind' location of a resource to location of an agent (issue for that https://github.com/valueflows/resource/issues/35). So it seems to me that we only change resource <-> agent relationship

This would not change any agent-resource relationships, just have a fromAgent and a toAgent in the event to denote the change of physical possession. We could save agent-resource relationships for all the rights related stuff.

If the resource doesn't change its location, the 'possession' seems like some kind of right. Also transfer in the 'Payment' seems to transfer 'ownership' 'vf:relationshipType': Owner so I don't really understand this 'possession' aspect at all.

Related comment by @bhaugen https://github.com/valueflows/exchange/issues/22#issuecomment-220837768 to my understanding we can model 'Possesion' in similar way as ownership. In context of vf:Transport

• vf:load triggers transfer of 'possession' from: provider to carrier
• vf: load triggers transfer of 'possesion' from: carrier to recipient

compared with ownership where carrier doesn't engage in transfers and either 'vf:load' or 'vf:unload' triggers the transfer (depending on FOB origin or FOB destination)

At some point we should dive into consequences of having certain type of relationship between agent and resource. In context of process (the actual resource) and transfer (rights to resource)

e.g.

• ownership - can do everything
• possesion - can transport and not transform
• custody - can neither transport or transfer

If we don't have a way to define consequences of particular type of relationship, we can as well put that information in rdfs:label or skos:note...

Should we continue with non transport related aspects in https://github.com/valueflows/exchange/issues/29 ?

[fosterlynn]

If the resource doesn't change its location, the 'possession' seems like some kind of right. Also transfer in the 'Payment' seems to transfer 'ownership' 'vf:relationshipType': Owner so I don't really understand this 'possession' aspect at all.

My vf:Transfer as subclass of vf:Process thought isn't in any yaml, the thought occurred to me after I did all the yaml yesterday.

If we consider possession as a kind of right, how do we model the physical handing over of a resource that doesn't involve vf:Transportation? When I made transfer events dependent on and triggered by process related events only, I needed some kind of process and event that would do that. This is for when a physical handing over coincides with change of rights. Which will often happen.

I'm not at all attached to the name vf:Transfer as a process; fine with something different. I think load and unload relate to transporting though. We need something that is the physical component of give-receive. Otherwise, we are back to having a transfer that also changes physical possession, but was not transported... and I know you don't want to go there! :)

[gcassel]

Maybe I seem too generic and reductive here (?) but I think vf:Transfer makes sense as the generic process-type which moves/"transports" intentionally scarce virtual resources from agent(s) to agent(s)-- and I think that "virtual resources" here can refer to any sort of digital media (e.g., file transfer), digital currencies (e.g., moving X dollars from one digital account to another), and designated/exclusive rights or responsibilities.

I wrote "intentionally scarce virtual resources" above because virtual resources can technically (and easily) be copied and shared instead of transferred-- but of course, you can't copy and share some types of virtual resources (such as digital currencies, and many types of rights and responsibilities) without consequences which should be carefully considered.