Defining Transfer

[bhaugen]

Moved from https://github.com/valueflows/agent/issues/38#issuecomment-150667605

@elf-pavlik wrote

simplest possible definition of vf:Transfer as "transfer of ownership over resource between agents", we need to define concept of ownership first - which seems to make sense as Agent - Resource 'relationship'

[bhaugen]

That definition implies that Transfer does not do anything else but transfer ownership, and ownership is a relationship between Agent and Resource.

Other changes in a resource like moving to another location or changing custodian would not be done by a Transfer event.

[bhaugen]

Question: do we want to do anything else to the "agent owns resource" relationship?

We already know when and how that agent came to be the owner if we have a Production or Transfer event.

But, for example, what distinguishes "owner" from "custodian" except maybe a text description? Is that enough?

I don't want to answer that question yet. Will follow @elf-pavlik's principle and let the examples do the talking, and see what else we need.

[elf-pavlik]

We have an example: https://github.com/valueflows/valueflows/blob/master/use-cases/dhen-value-flow.md and I already started a diagram for it.

Other changes in a resource like moving to another location or changing custodian would not be done by a Transfer event.

As we discussed we can have conceptual (I really don't want to say legal, and I find law quite conceptual) Transfer of ownership without any Transport between physical locations. And we can have physical Transport of a resource between physical locations but without any conceptual Transfer of ownership. This suggest me that we need to have a way to model those two independently. At the same time, as we can add as many relationship between entities as we want. We can also relate particular Transfer to particular Transport, and anything else we would want to relate it with. I hope no one thinks about some constraints coming from using relational databases or document databases, we work with graph model here :wink:

[ahdinosaur]

@elf-pavlik wrote

simplest possible definition of vf:Transfer as "transfer of ownership over resource between agents", we need to define concept of ownership first - which seems to make sense as Agent - Resource 'relationship'

@bhaugen wrote

That definition implies that Transfer does not do anything else but transfer ownership, and ownership is a relationship between Agent and Resource.

i feel the same way as @bhaugen, 'ownership' is one of many relationships that someone may want to 'transfer', 'custodian' also comes to mind for me, but i wonder what the edge is here: what else can we transfer?

[bhaugen]

@ahdinosaur - I'm actually ok with (a) Transfer being limited to transfer of ownership. Otherwise (b) a transfer event needs to specify what relationship toward the resource is being transferred. Which would also be ok with me. I can't off hand tell what the pluses and minuses of (a) and (b) are.

[bhaugen]

Also, in previous projects, we have combined economic events that transfer resources from one agent to another, with a couple of optional fields that also change the resource's location from one place to another. They were used when people did not feel like it was useful to specify the process of transportation. Sort of a cheat, but handy, and we went with handy cheats more than once. As we do when the exchange or the process is more important to track and people would not want to be bothered to specify the other.

[elf-pavlik]

i feel the same way as @bhaugen, 'ownership' is one of many relationships that someone may want to 'transfer', 'custodian' also comes to mind for me, but i wonder what the edge is here: what else can we transfer?

Maybe we could clarify first, what the orange box labeled 'Exchange' means on this diagram? https://github.com/valueflows/valueflows#exchange-oriented-flow

Does this illustration also apply to 'transfer' of responsibility for petting a cat daily? Or 'transfer' responsibility for verifying if a child brushed teeth before going to sleep?

As I understand we already started clarifying that Exchange implies two (or more) ways flow, and Transfer seems like reasonable unidirectional alternative.

We also had conversations in direction of:

• Process - doesn't involve change of ownership
• Exchange - involves change of ownership

Also clear attempt to distinguish them here: https://github.com/valueflows/valueflows/issues/55#issuecomment-148529350

I also stay open to use term OwnershipTransfer if that helps to reduce ambiguity.

Also, in previous projects, we have combined economic events that transfer resources from one agent to another, with a couple of optional fields that also change the resource's location from one place to another. They were used when people did not feel like it was useful to specify the process of transportation. Sort of a cheat, but handy, and we went with handy cheats more than once. As we do when the exchange or the process is more important to track and people would not want to be bothered to specify the other.

Who "did not feel like it was useful to specify the process of transportation"? People who worked on developing software for managing this kind of data? Or people who used some particular software? If the first case, we need to take into account needs of people who develop software applications. If the second case, people who develop software applications need to take responsibility for Interaction Experience. Plumbing details, like if data gets stored in flat files, in CSV, in relational databases, in document databases, in graph databases etc. as well as details about the underlying model of data SHOULD NOT in most cases surface to people using those applications. I see need to have coherent model which allows simpler perspective with lower granularity of information, as well as more complex (but compatible) perspective which allow to express more details.

I'll try to write some more organized thoughts about intended audience of our work and what we take as requirements and what we leave as responsibility of people who build on top of this work to take care of.

[bhaugen]

Who "did not feel like it was useful to specify the process of transportation"? People who worked on developing software for managing this kind of data? Or people who used some particular software?

People who used some particular software. We always develop software as an experiment with particular groups of users, although we also try to include as many groups as possible in each experiment.

This project is not an experiment for a group of users, so the same considerations don't apply. It is, for us, a generalization and summarization from several experiments, and trying to collaborate on that with with the other participants in this project to see if we can create something together that will be better than what we can do by ourselves. And extend our work, because I am in particular getting too old to develop the code anymore. I can still do it, but am much slower and can maintain focus for fewer hours per day.

So sometimes I will explain what we did in some particular software experiments when I think it will have some explanatory value. But I do not intend those as prescriptions for what we should do in this project, just as background.

If that is all confusing, I'll try to be more careful, and would appreciate suggestions in how to do better.

[elf-pavlik]

@bhaugen thank you for clarifications and I do find your hands on experience benefiting this work in fundamental way! Since I still see us as getting into group workflow and continuously understanding each other better and better, I just want to capture where we have common and where we have distinct aims and expectations. This way we can focus together on the common ones and work independently on all he distinct ones.

Going back to defining Transfer, I think we could harvest little more from https://github.com/valueflows/exchange/issues/8

And clearly write how we define Process, Transfer, Exchange and most of all in what ways we see them distinct and how we see them relation to each other.

@fosterlynn said in https://github.com/valueflows/exchange/issues/10#issuecomment-150579417

I have no need to change the name of the repo right now..... I think we want to keep process and exchange at the same level somehow.

I would find it interesting to capture this "same level" thought, with more in depth explanation.

[bhaugen]

@elf-pavlik @ahdinosaur - just to be clear, I agree that we should separate Transfer as a change of ownership from (maybe) Transport, which moves a resource to a different location, and may involve or be a process.

[Edit: I should add that I do not have a coherent model for Transport yet. I have created some in the past, but want to rethink in this context.]

Re Process, Transfer, Exchange and "same level": Transfer is part of Exchange, but if we define Exchange as a set of reciprocal Transfers, could also stand on its own. The difficulty with Transfer standing on its own is that, as we regeneralize, we find it useful to think of both Exchange and Process as different kinds of EconomicInteraction. That is the sense (for me anyway) where Process and Exchange are on the same level of abstraction, and both Process and Exchange will contain potentially many economic events.

[fosterlynn]

@bhaugen thanks for replying about process / exchange on same level.

I am not ready yet to define Exchange as needing to be two (or more) way. We might need that conceptual layer in the model (Process, Exchange == EconomicInteraction in an old version) to tie things together. Or not. But I want to think about it more.

(Side note: Sorry I haven't been keeping up as well as I possibly should, since thinking about the whole model for me requires a focused time. And I'm trying to write code for round trip, which I think we agreed is on the critical path. And also requires focused time, at least for me. I should admit I'm actually a little bit frustrated not feeling able to keep up with the pace of discussion on the model and definitions for process and exchange and resource and etc., since that is actually my skill set more than coding. Although I'm happy to code too, and need to do so to get my head properly oriented towards LOD. I would welcome others' thoughts about our collective priorities and how to keep multiple balls in the air. I don't personally want to get so behind on the discussions of non-Agent subject areas, but keeping up with that would mean not so much code gets written. And I'm very glad @elf-pavlik is digging so deeply into the model and having fruitful discussions with @bhaugen . All of that said, I would love to have some help with coding the round trip if anyone else feels they can plug in !! If not, no worries.)

[fosterlynn]

P.S. Hope that didn't sound like a rant, I'm very happy with this whole project and don't feel a need to rant. But I do want to keep honest discussion and coordination going too.... :smile:

[elf-pavlik]

And I'm trying to write code for round trip, which I think we agreed is on the critical path. And also requires focused time, at least for me. I should admit I'm actually a little bit frustrated not feeling able to keep up with the pace of discussion on the model and definitions for process and exchange and resource and etc., since that is actually my skill set more than coding. Although I'm happy to code too, and need to do so to get my head properly oriented towards LOD. I would welcome others' thoughts about our collective priorities and how to keep multiple balls in the air.

:+1: slowing down with entertaining the future possibilities and focusing on GTD, I'll also get on some coding in next days, If you see me rambling on github or gitter I welcome a gentle nudge!

[fosterlynn]

@elf-pavlik awesome, thanks! :+1:

[ahdinosaur]

@bhaugen says:

This project is not an experiment for a group of users, so the same considerations don't apply. It is, for us, a generalization and summarization from several experiments, and trying to collaborate on that with with the other participants in this project to see if we can create something together that will be better than what we can do by ourselves.

yes. :fist:

@fosterlynn says:

I would welcome others' thoughts about our collective priorities and how to keep multiple balls in the air. I don't personally want to get so behind on the discussions of non-Agent subject areas, but keeping up with that would mean not so much code gets written.

i think it's best when we each do what we want to do, anything else is rubbish. i'm keen to be coding here while y'all dive deeper into the model. :smile:

i started on linked-data-browser (source), since i want to play with linked data interfaces using redux, virtual-dom, and rdfjs libs. still have much to do before it does anything useful.

[bhaugen]

@ahdinosaur I'm excited about http://dinosaur.is/linked-data-browser/ but I mostly want to help an agent round trip happen while keeping some other balls in the air at the same time. (Which I don't think is rubbish.) I could see that browser as part of the round trip.

I gotta finish the DHen value flow traversal report and then I'm plugging in on Lynn's json-LD parser (assuming it's not done yet...).

[fosterlynn]

i started on linked-data-browser (source)

:+1:

[ahdinosaur]

I could see that browser as part of the round trip.

yup, that's where i'm heading, with a focus on pioneering the relevant RDF-based Linked Data problems for client-side apps so Holodex doesn't have to.

[fosterlynn]

I'm working on Transfer and Exchange over in NRP land, with an eye towards valueflows (of course!). Wanted to post my progress, this issue seems like it covers a lot of my current questions. Sorry this is so tiny. :( Also, note this is very preliminary, hoping for some more discussion when y'all have a chance.

Some things to note:

1. I thought about the long conversations we have had about transfers vs exchanges, and what constitutes one flow (like you see in the T-shirt). Also thought about an economic event (now value flow, hope that's OK) best affecting just one resource. So I now have a give and a take flow, separated. Note, McCarthy often shows it this way, although he has different views of it. Changed Take to Receive, sounds less like stealing. :) Ref #8
2. Added Transfer to connect the give and receive flows, which are inseparable.
3. An Exchange then contains 2 (or possibly more) transfers, capturing exchanging one resource for another. I put Transfer and Process on the same level because they are both one-directional flows. Up for discussion! Would like to support a Transfer without an Exchange but so far having a hard time doing that in NRP for reasons not shown on this model, having to do with Exchange Types and Transfer Types.
4. Regarding ownership vs other rights: Pulled that out of any assumptions in Transfer, which just shows a give/receive of a resource for whatever reason. Per @bhaugen 's thoughts for a while, you can model rights as a separate Resource which relates to its underlying Resource. So you could have a Resource representing say the right to use a book from the library for 3 weeks, with the underlying Resource being the book; or the right to occupy an apartment for a year, with the apartment as underlying Resource. You want to know that the book is not available at the library at the moment, but you want to know the library still owns it. Etc.

[bhaugen]

P.S. using a Rights model, ownership could be a defined right that is more or less "all rights". In which case, Transfers always transfer a Rights resource connected to an underlying resource.

Alternatively, a Resource could have an owner or owners as a relationship with one or more Agents. But now you got two ways to do everything.

So we should think about this a bit. Is the Rights model the way to go, or is it too convoluted? If the Rights model fits some situations, does it fit a simple transfer of ownership? Is it better to keep that simpler, or have a uniform way to do transfers (always a Rights resource)?

Or can somebody think of a better way to all that stuff?

I just had a discussion with some REA jocks. They all agreed that transferring rights is the way to go, but they did not all agree on how to model it. I could get into the details of that if anybody wants, but none of those people has developed detailed operational software as far as I know.

[fosterlynn]

Alternatively, a Resource could have an owner or owners as a relationship with one or more Agents. But now you got two ways to do everything.

Or, a transfer of a resource that is not rights, i.e. has no underlying resource, could imply transfer of ownership?

But I like the idea of getting away from an assumption of ownership, and of thinking of ownership as a primary right for everything. Moving towards people thinking of resources in the real world with as few rights as necessary to manage them well. At least having a model that will work well for that day.... :smile:

[fosterlynn]

This is after thinking about the lengthy gitter chat today with @elf-pavlik . And other similar discussions we have had, including above in this issue. This is about what is a Transfer. We have talked about (and modeled) transport as a process, which we all agree on. We have discussed Transfer as "conceptual" not physical, reflecting ownership change, while process is physical.

We have also discussed the principle of not wanting to record everything, just what we need to know in the data. We don't really have agreement on that, and although I tend to go there in our discussions, I am today realizing that this is not the issue.

Basically, I think that conceptual vs physical is not the best place to draw the line between Transfer and Process. I think pushing everything with material effect into Process is too much. A Process creates something or changes something in a way that matters to its usefulness.

If I hand you a glass of my milk, I want to record that as a Transfer, not a Process. If you in return hand me a cookie, same thing. These are 2 Transfers making up an Exchange. It is physical, not conceptual. But I think if we step back, the essence of this is an exchange of material things. The essence is not the process I went through to reach the milk out and you taking it from my hand.

In another example, if agent 1 orders something from agent 2, and pays $10 for the item and $2 for shipping costs, I want to record that as Transfers:

1. the item from agent 2 to agent 1
2. the shipping service from agent 2 to agent 1
3. $12 from agent 1 to agent 2 (There are other things that happen in the background, which agent 1 is not connected with. Of course the shipping agent needs to understand many things about the transport process(es). And agent 2 pays the shipping agent for the shipping. But for agent 1, the above is what is happening.)

What do you all think? (Good ongoing discussion!)

[elf-pavlik]

Basically, I think that conceptual vs physical is not the best place to draw the line between Transfer and Process. I think pushing everything with material effect into Process is too much. A Process creates something or changes something in a way that matters to its usefulness.

I see Transport matching requirements you state above. It changes physical location of a Resource which does change its usefulness. As you stated few comments before:

You want to know that the book is not available at the library at the moment, but you want to know the library still owns it.

Besides that

If I hand you a glass of my milk, I want to record that as a Transfer, not a Process. If you in return hand me a cookie, same thing. These are 2 Transfers making up an Exchange. It is physical, not conceptual.

I understand you want to record flows of values - something conceptual not physical. In this case I see no problem if someone just ignores the physical detail and only records change of ownership over cookie. If you give me a cookie I can eat it myself or give it to another person. This case looks to me as one of the cases where we really don't care about details of what happens in physical reality and focus on conceptual aspects.

What if I hand you a glass of milk or a cookie which we both agree that already belonged to you? Do you still record it as Transfer? In physical reality nothing have changed comparing to the version of this scenario that you proposed, only our cultural interpretation of it changes based on the concept which we call ownership.

[bhaugen]

This has been an ongoing circular discussion/argument that is not getting us anywhere.

I propose that we focus on how we want to handle rights, and make clear that a transfer deals only with rights to resources. And that we focus on two use cases:

• book lending, a right to use a book for 2 or 3 weeks, with an expectation that the book will be returned by the end of the lending period.
• apartment rental, a right to occupy an apartment for the duration of a lease, provided that one pays rent at the beginning of each month.

The two alternatives to defining rights that I can think of are:

• Rights are a separate resource that is connected to an underlying resource to which the rights pertain.
• Rights are defined by a Contract, a Type object (e.g. ExchangeType or TransferType) that defines what rights are being transferred and what reciprocal transfer is expected.

What do you all think?

[fosterlynn]

I like the general approach @bhaugen .

The use cases you suggest seem basically the same, though. How about we start with:

• book lending as proposed, say for 3 weeks
• purchase contribution per Sensorica: a member orders 2 parts needed for a process at the lab, the member pays for the parts, the parts are received at the lab (no separate shipping or tax involved)

If this makes sense to people, I'll try some rdf diagrams. It will be a bit slow, we're still at my mom's.

I understand you want to record flows of values - something conceptual not physical

Actually, maybe a better way to think about it is resource flows. Resources which have value to people. So the value part may be conceptual (decided by people) but the resources can be very real. Or not. Resources that flow can be physical items or electronic or credits or .....

[bhaugen]

Let's try one or more different event types to record physical movements, that are not the same as Transfer. Maybe:

• Transport (a process involving transportation resources)
• Movement (simple record of moving a physical resource from one location to another, where it's not worth recording the process. This is often used in physical inventory systems for recording the fact that an item is now in a new location, but the details of how it happened are not important.)

[elf-pavlik]

I propose that we focus on how we want to handle rights, and make clear that a transfer deals only with rights to resources.

:+1: My main concern relates to blurring distinction between what happens in physical reality and perceptions around it, based on specific cultural constructs, like for example ownership. If we can't agree on that distinction I would like that we patiently keep conversations about it open.

book lending, a right to use a book for 2 or 3 weeks, with an expectation that the book will be returned by the end of the lending period.

I created use case file in main repo and added extra step of reserving the book first via online interface!

Resources that flow can be physical or electronic or credits or .....

As we see sometimes we want to relate flows in physical dimensions (eg. dried herbs moved to another place) to flows in conceptual dimension (herbs coop passed rights to certain amount of herbs to a tea house). While those two relate they can happen independently in time, and we can't always infer one from the other.

When it comes to credits I need to model particular flow of euro currency in next days. I will also add bitcoin mixing service as use case where transferring credits between accounts doesn't mean transferring ownership rights to those credits. Another use case will come with shared bank account where people who share it can do accounting between themselves without need to transfer funds between accounts.

[bhaugen]

@elf-pavlik

My main concern relates to blurring distinction between what happens in physical reality and perceptions around it, based on specific cultural constructs, like for example ownership. If we can't agree on that distinction I would like that we patiently keep conversations about it open.

We mostly agree on that, although edge cases might exist. Transferring rights makes the distinction explicit. Rights are all about economic relationships, laws and customs, not physical reality.

[bhaugen]

shared bank account where people who share it can do accounting between themselves without need to transfer funds between accounts.

Lynn and I have one. In the US it is called a "joint account". We are the joint owners, and as such, are a particular type of organization.

[elf-pavlik]

We mostly agree on that, although edge cases might exist. Transferring rights makes the distinction explicit. Rights are all about economic relationships, laws and customs, not physical reality.

:+1: distinction between Rights and the actual Resource should also come helpful when we get to use cases which include shared ownership. I can think of situations when agent transfers only X% of ownership rights for particular resource.

[bhaugen]

I can think of situations when agent transfers only X% of ownership rights for particular resource.

In those cases, like in Lynn and my joint bank account, the agents who share ownership have some kind of agreement which constitutes an organization of some kind.

[fosterlynn]

Another use case (from gitter chat): DHEN herb flow

https://github.com/valueflows/valueflows/blob/master/use-cases/dhen-value-flow.md

https://drive.google.com/drive/folders/0B6gVU-928vbCaVBFOWw2OU1VNUk

[fosterlynn]

storing this here also (from link dumps) because it is about rights... http://www.w3.org/ns/odrl/2/

[fosterlynn]

Hi all, bringing this issue back from hibernation, based on another :smile: lengthy discussion with @elf-pavlik in gitter chat. Shoot, I have missed the long VF chats with Pavlik.....

Where we got to in the gitter chat (so y'all don't have to actually read it!) is that we would lay out a very simple example of a Transfer so we can see what the data structure might look like. I have split out the data into Transfer, Give Flow, Receive Flow. Pavlik wonders why I made it so complicated and why it can't just be Transfer. The chat also covered the conceptual vs physical ground that we have previously covered in this issue. Including specifically transfer of ownership and "usership" rights, also discussed above.

I think actually, maybe we can use this issue to define Transfer (its title). Then I'll start a new issue for the transfer data structure. Perhaps "underlying resource" should also be a separate issue if it isn't already... I'll look.

My goal is to get to some conclusions on Transfers and Exchanges. (I'm feeling better about doing that now that I have re-coded Exchange and Transfer in NRP, based on VF discussions. And also feeling hope based on uptick in all our participation, that people will have time and energy to nail it down together at this point....)

OK, more issues and comments coming this afternoon.

[fosterlynn]

Gathering suggested definitions for Transfer from this issue, to try to make it easier to think about:

transfer of ownership over resource between agents [then there was discussion over ownership vs other types of rights]

agree that we should separate Transfer as a change of ownership from (maybe) Transport, which moves a resource to a different location, and may involve or be a process.

Transfers always transfer a Rights resource connected to an underlying resource.

Transferring rights makes the distinction explicit. Rights are all about economic relationships, laws and customs, not physical reality.

The two alternatives to defining rights that I can think of are: * Rights are a separate resource that is connected to an underlying resource to which the rights pertain. * Rights are defined by a Contract, a Type object (e.g. ExchangeType or TransferType) that defines what rights are being transferred and what reciprocal transfer is expected.

distinction between Rights and the actual Resource should also come helpful when we get to use cases which include shared ownership

[gcassel]

I tacked on a bit to your gitter conversation before seeing this new issue @fosterlynn . Thanks for conscientiously reporting and trying to further the dialogue here!

My comment regarded specific data-types which I think should be enabled for Transfers:

I guess that it should be possible to attach (optional fields) any existing info (such as numerical IDs, serial numbers etc) which indicate exactly WHICH Resource(s) is being transferred, and also any existing info regarding the provenance of that Resource(s)?

For examples (very crudely):

"from: Bob Haugen to: Elf Pavlik what : table bracket S/N 1217083"

or

"from: Bob Haugen . Community A username bhaug1 to: Elf Pavlik. Community A username epavlik33 what: 210 units Community A FairyGold"

[bhaugen]

Didn't look at the gitter conversation yet, but just for the record: each resource will carry all of its identifying information and know its provenance (which is the history of resource flows, processes, and transfers by which it got to wherever it is now). Those are all properties of the resource-being-transferred, not properties of the transfer itself.

[bhaugen]

See also #16

[gcassel]

Okay, what you're saying @bhaugen perfectly addresses my first example:

"what : table bracket S/N 1217083"

I guess that my second example will also be addressed by proper identification of each Agent involved in the transfer?

I.e. in my example, the transfer would be from the agent identified as "Community A username bhaug1"; and we would only know indirectly (but clearly) that bhaug1 is attached to a main personal profile for a very specific "Bob Haugen"?

[bhaugen]

How to identify agents is a different issue (I think).

Lynn is communing with the Mutual Aid Networks to figure out how to identify agents in a community with two and maybe more systems that each have agent accounts.

But the trend seems to be to identify agents by (hopefully globally) unique cryptographic keys.

In my personal version of the future each agent has their own Personator (tm @Connoropolous ) which is identified by one of those keys and there are no logins or user accounts. Access and authorization will be by capabilities. I either have the proper capability with me, or no access. (I don't know how much of this is practical in what contexts, but I think that @ahdinosaur is at least thinking about it. And I think @dominictarr is working on it.)

[gcassel]

This may seem off-topic, but I'm trying to relate it to Transfers:

Identifying agents by (hopefully globally) unique cryptographic keys is a great goal. However, we currently do online actions and transactions via a very wide variety of accounts. And in fact, I think that pseudonymous accounts are a perfectly valid and healthy way to interact within some social contexts, although I don't use pseudonyms personally. I've blogged a bit about online identity and pseudonyms.

Even if we see the day that there's a practically-global protocol / standard [unique cryptographic key] for each person, real human beings are still going to be interacting online via the medium of those keys and the account (possibly Personator) or multiple accounts which each key "unlocks".

Each key would be a (hopefully secret) data-item which a specific individual human is understood to have the use-rights to, just as we currently have use-rights to various accounts.

So, I personally understand the account to be the agent for interactions (and transfers)- not technically / precisely the real human being-- and I think that Transfer terminology should reflect the fact that each agent's identifier(s) have social/ community context.

Am I making sense, and am I missing anything relevant in your thinking @bhaugen ?

[bhaugen]

I think a variety of agent identification schemes will be required and they will probably vary by community and by sets of technical affordances. So the VF vocabulary and access protocols will need to be flexible.

But every value flow Lynn and I have created so far has had a designated context agent. In other words, a transfer will happen in a context. In Lynn's latest changes, a transfer has both a give and a take, and the contexts for both can differ.

As for individuals, they may have relationships with many contexts, so I don't think you can say that an agent must have a unique context. I don't, for example. I belong to many contexts.

So if I am conducting a transfer from me in one context and somebody else in another context, that can be clearly designated on that transfer, but may not apply to me for the next one. And whether I have an account or not when I do such things seems really conditional to me. In patchwork, my identity is a cryptographic key and I have a mutual following relationship with a couple of Pubs (which are contexts) but they are not really the same as accounts.

[gcassel]

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.

I guess we're somehow talking past each other, and maybe I could express myself more simply and clearly.

It certainly seems to me that a truly interoperable personal identification system should indicate not only a personal name or ID, but the context in which that ID has been created or issued.
(Though in some cases, that context may be explicitly evident by the format of the personal ID. For instance, something like "twitter.com/gregsc1 " )

[ahdinosaur]

@fosterlynn @elf-pavlik ++ thanks for reinvigorating Transfer, very relevant to #6 and #15. :)

@gcassel says: I think that Transfer terminology should reflect the fact that each agent's identifier(s) have social/ community context.

hey @gcassel, as @bhaugen mentions, transfers already have a way to specify how they relate to agents (subject, object, context), if you think this is inadequate do you have an alternative in mind? also below,

@gcassel says: It certainly seems to me that a truly interoperable personal identification system should indicate not only a personal name or ID, but the context in which that ID has been created or issued.

since this is a question of how we describe an agent, can we move this conversation over there? similar to how "each resource will carry all of its identifying information and know its provenance (which is the history of resource flows, processes, and transfers by which it got to wherever it is now)", an agent should indicate the context in which it has been created and relates to other agents.

[fosterlynn]

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.

[fosterlynn]

Straw dog definition, so y'all can tear it apart :)

Transfer: Transfer of rights (such as ownership, right to use, etc.) to an economic resource from one agent to another.

Shouldn't use the same word (transfer), but don't know a better one.....

[bhaugen]

Transfer: Giving rights (such as ownership, right to use, etc.) to an economic resource from one agent to another?

[elf-pavlik]

Transfer: Giving rights (such as ownership, right to use, etc.) to an economic resource from one agent to another?

s/Giving/Re-assigning/ (or just Changing)

So that we have definition from 3rd 'neutral' perspective. 1st and 2nd perspective will see it as either Give or Receive, while uninvolved observer can consider it simply as Re-assignment (Change). We had recently nice chat with @fosterlynn about seeing transfer of ownership as Give or Receive depending who looks at it. I emphasise need to also incorporate a 'neutral' observer perspective besides two perspectives of 'involved' parties.

[bhaugen]

I'm good with a neutral word, but re-assigning does not always apply. For example, a commons organization can give people rights to common resources but they are not really re-assigned. They may be assigned, I suppose.

[gcassel]

^ Well, I think the generic concept of Transfer simply does not apply to the explicit assignment of rights to common resources and newly created resources, and I think that's okay. I figure that such assignments can be created through licensing (including open source software and Creative Commons licenses) and any related community agreements, which may be quite formal / contractual in some cases.

(So, I'd personally like to associate the term "re-assignment" with Transfer)