Should resource types, exchange types, patterns be tied to contexts like projects?

[bhaugen]

By "context", I mean "context agent", like project, cooperative, group, etc.

As of now, they are not. Resource types apply to all contexts. That is necessary if different contexts want to trade with each other.

It may also be useful to have a set of common resource types that each context does not need to re-invent.

But it can also be confusing, and if a commonly-used resource type gets changed by one project, that can affect other projects.

Possible changes could be:

• tie all resource types to a context, and limit their use to that context, or
• optionally tie resource types to contexts, and allow others to be usable by all contexts, but changes to the common resource types could only be made by Freedom Coop admins.

[fosterlynn]

This would need to start with some discussion of how Freedom Coop wants to think about this on the ground with real projects, some of which will be very separate, and some of which will want more integration across the network.

For example, does FC want to standardize on types of work across the network? Does FC want to be able to trade or use resources of the same defined type across projects and nodes? If so, would a resource type from one project or vendor actually be the same resource type in the system as something that is basically the same but from another project or vendor? Etc.....

Can we look at the groups that exist now (Decentrale, call center, etc.) to get any understanding of this? Can we predict into the future a bit?

Another place to do a bit of research is to see how the FC Marketplace models resources and resource types / categories.

Generally, I'm feeling a need with this issue to step back and make sure we do a good job getting the model to represent what we want into the future.

[bhaugen]

If types of work are not at least somewhat standardized, how will projects offer opportunities to Freedom Coop members who are not yet members of their project? And how will they find people with the skills they need?

[fosterlynn]

If types of work are not at least somewhat standardized, how will projects offer opportunities to Freedom Coop members who are not yet members of their project? And how will they find people with the skills they need?

Yes it seems clear that Freedom Coop in its role to offer work needs to have standardized skills described. But if an existing collective joins, and they don't want to seek more members or work outside themselves, will they want their own very simplified set for their own purposes?

[bum2]

I think we need only standarised types of work (skills). Also we need common resource types, but will be good to give the option of create a particular resource type for the project's scope (acceptation of new 'resource types' is anyway moderated by an admin). If the needed skill or resource type is not present, the user can suggest a new one (now in the comments thread, one day in the 'others' field feature). It has to be moderated and managed by admins the inclusion and editing of 'skills' and 'resource types', so they are common and this let us link and search sinergies between members. If a particular 'resource type' only used by a project is requested by another project, then is not a new one, is the same type but usable by two projects. Anyway we should start with common types for everybody, then the 'others' field feature and moderation system, then we can study this option of private or project's particular 'resource types' in a future version. Perhaps now we should hide some types, only related freedomcoop membership process, by hardcoding them out of lists in the work app.

[fosterlynn]

Perhaps now we should hide some types, only related freedomcoop membership process, by hardcoding them out of lists in the work app.

We should be able to do this by configuring using the facets / facet values and process patterns / exchange types. We may need to add use case(s) to the work app though, and that is code. But would be worth it rather than hard-coding resource types.

[fosterlynn]

Added exchange types and process patterns to the issue name. They all will need to be done.

[bum2]

Perhaps a better approach is to make all these types (resource, exchange and pattern types) tied to a specific context agent, but we use the contexts hierarchy to make common types for all childs. So this way, all member's projects can be childs of a general group (eg. 'FC Members Projects') and the common types are tied to this general agent, so every child of it inherits the types. If we can make branches (like areas of activity) we can then set special types for a branch (and all their child agents)... i think is the most flexible solution, so we can arrange types with the same hierachy of agents, making common or specific types depending on the 'parents' associations. Also we don't need to make a boolean field about public or internal visibility of a type, nor any hardcoding, just configuration with two main agent groups (internal and member's) and all other agents inside them in branches...

[bhaugen]

That's one of the design issues on my mind: whether one context inherits resource types etc from their parent. Easy enuf to do.

In any case, all we need is a context agent field on all of those types, and then the inheritance logic, which we already use in other cases so it's pretty easy.

[bum2]

Yes Bob, seems clear for me. Can you take care of develop the structure for this approach?

[bhaugen]

We're talking about it and think it is necessary. Getting any programming done for us in the near future is a bit of a problem, which I will explain in telegram, but can be done.

[fosterlynn]

I think we should add EconomicResource to the list for adding the optional context_agent field. This would be needed when resources are created with global resource types. Then all resources can be kept within a context (collective, etc.)

[bum2]

I'm re reading all this issue, and here i put also also some key talks in the telegram group (about 'resource types'):

[Forwarded from Lynn Foster] also exchange types (like patterns) have a section referring to resource types, so i think they need to be handled basically at the same level

[Forwarded from Lynn Foster] global exchange types could only refer to global resource types; project resource types would require project exchange types and process patterns

[Forwarded from bumbum] 'purchase', 'sell', 'transfer faircoins', 'material contribution', 'direct exchange', 'room rental' are all general... the others must not appear there for all projects ('shares', 'FC membership' etc)

[Forwarded from Lynn Foster] yes there will be a set of global general ones, like you say

[Forwarded from Lynn Foster] although I'm afraid we will run into trouble even with those, because of the project resource types

[Forwarded from Lynn Foster] for example "sell" - which resource types are sold? might be specific to projects

[Forwarded from Lynn Foster] even some collectives might only sell for local fiat currency, some for faircoin, some for both....

[Forwarded from Lynn Foster] hmmm, good we are thinking in more detail, I had not thought to this level yet

[Forwarded from Lynn Foster] now i am wondering about facets and facet values, can we keep them global?

[Forwarded from Lynn Foster] might be hard to do so

[Forwarded from bumbum] because the exchange types are attached to some resource types?

[Forwarded from Lynn Foster] yes

[Forwarded from Lynn Foster] each exchange type has transfer types (what is exchanged for what), and each transfer type relates to facet values that determine the resource types that will appear for each transfer

[bum2]

Ok, imagine we have this context_agent FK in the EconomicResourceType model. Now let's imagine the workflow to start planning: The goal of the 'plan-work' page is to define a process task and set a related open order, isn't it?

The project coordinator goes to plan new work, the first step is to choose a Pattern... that's an absolute mistery for any user (we need to explain what are patterns there). From what @fosterlynn said, the patterns will require also a context agent FK (if so, only for general contexts). So initially, only the patterns related any upward context agent are shown (maybe in a future release the coordinator can suggest new process patterns).

Once choosed the Pattern, it loads the related Resource Types. That 'pattern' choice is the first and main choice to retrieve a list of resources to start planning, so it makes sense that the patterns act like 'sectorial' sub grouping of resource types (inherited by agent hierachy or faceted), perhaps also related the Skills grouping by 'sectors' of activity. In that sense, a 'tree indented' dropdown (or a better widget) will be fine as a first choice when planning. Another way can be to keep this 'pattern' choices to a very general ones, like: 'making Material outcomes', 'making Non-material outcomes', 'Transport', etc... But i think it don't make much sense, because anyway the filtered set of resource types should be filtered also by the project relations, so it will catch resource types from upward relations (inheriting from parents) and also from downward relations (skills from the project participants).

Going deeper in the code, the ProcessPattern model has only a name, and the methods for getting a list of resource types (like def get_resource_types) uses the related facet values, from a set of facets 'event_types' or slots (kind of relationship types). If we add a context_agent FK in the ProcessPattern model, then we can add a method like def get_context_resource_types to retrieve directly the set of resource types (related the project or parent contexts, and related the skills of participants) to start planning.

Another approach can be related the fact that the ProcessType model has already a 'context_agent' FK (and a 'parent' field). What is this context_agent field used for? If every ProcessPattern is linked to some ProcessType then maybe we can use the context_agent field in the ProcessType model instead of adding a new FK in the pattern... What you think?

Imagine we do this for retrieving a set of resource types after choosing a scope or plan type (now a 'pattern', but related a context, from the set of related contexts of the project), jumping over the facet system here (not using it in this planning first step)... Is it true that we can start planning this way? (if not, please warn!) ...the resource types themselves are related to facets also so we have the info there if needed.

Then we can let the coordinator choose amongst the resource types of his/her own project (initially none) or the types related any of their upwards associations context agents (when the project is child or member of another). This screen to plan work, when filled with the resource types to choose, can contain a section of "Your Custom Resource Types" (initially empty). Also imagine there a 'Add New Resource Type' button and a modal form for coordinators: this form is big (many fields) and now will also include a dropdown to choose the context of the new resource type (by default the project agent) and the options will be only the parents and grand-parents of the project. Also a side note next to the field can say: "If you think this resource type can be useful for other projects, please select the intended scope choosing a more general context agent. To see more common types and more contexts here you can add your project as a child of another broader general project, editing your project Relations." That of course means having the Project Relations page ready (the 'maintain associations' for projects #189).

Then let's imagine the coordinator adds a new resource type (if we can simplify the form!). It should be ready for him/her to be used inmediately, and a task or notification for review the new type is added to the coordinators (maintainers) of the parent context agent*. The new resource type will be linked to the project agent or any of its parents, so it will appear in the plan-work page as an available resource type to start planning.

*I know we don't have such a single 'parent agent', we have plenty of parents for every agent (and i love it!), so we need to define 'which' relation type is the one that constructs the agents hierachy in each case (eg. for find the parent context coordinator), but we can mix them all to get related 'resource types'. In the 'organization' page for admins, are we using 'child' relations to make the indentation of the list.

The possible trees of agent relationships are limited by the 'association behavior' types, and there are now 7 types of this 'behaviors': supplier, customer, member (aka participant or self-employed), child (aka node), custodian (not used?), manager (coordinator) and peer (support). I propose to group these behaviors in 4 blocks to generate 4 kinds of context agent trees, depending on the kind of relationships:

• Participation Tree: a new tree in a new admin sub-page, similar to the organization page we have in coop admin app (using 'child' for the indent), but representing the hierachy of agents generated using only the member association behavior (includes: member, participant and selfemployed types). The 'manager' behavior (coordinator type) should be accounted as member too.
• Sectorial Tree: the same tree we have in the Organization page, representing the hierachy of agents generated using the child behavior. We can build here the sectorial branching with open context agents (autojoin projects) grouping sectors of activity (like a taxonomy), not only to share and inherit 'resource types', 'exchange types' and 'process patterns' but also to organise common needs of the sector or sub-sector.
• Economical Tree: a new tree in a new admin sub-page, representing the hierachy of agents using the supplier and customer behaviors (can they be mixed in a single tree?).
• Support Tree: a new tree in a new admin sub-page, representing the hierachy of agents using only the peer behaviour.

Please answer what you can and share your doubts about my plan for this part of the new release (the "Set a new Work Plan" feature) up to this point. Next point will be from the saving of the new Process and all what happens next. If you see this workflow plan viable and somewhat desirable, note that i'm facing the main task about models and structure but there are many side tasks you can help (the 'relations' page, the 3 new agent trees, the add new resource type button+form, etc)... The other part of the release, the Exchange Types, is also clear to finish (if someone have time)... We decided to make a predefined set of exchange types for projects and a 'suggest new exchange type' feature like the new skills suggestion system.

[fosterlynn]

Another approach can be related the fact that the ProcessType model has already a 'context_agent' FK (and a 'parent' field). What is this context_agent field used for?

We can't actually remember why there is context_agent on ProcessType, but we can use it if we want. Theoretically we could use it to make a recipe context agent specific, but better to use resource type I think.

If every ProcessPattern is linked to some ProcessType then maybe we can use the context_agent field in the ProcessType model instead of adding a new FK in the pattern... What you think?

ProcessType could be very specific, much more than ProcessPattern. In manufacturing, you will get many very specific process types when creating a recipe, like "assemble the xyz part" or whatever, with very specific directions in the description. Process patterns really only need to be added when there get to be so many resource types that it is confusing. Possibly each project could have one or very few per use case.

[fosterlynn]

Imagine we do this for retrieving a set of resource types after choosing a scope or plan type (now a 'pattern', but related a context, from the set of related contexts of the project), jumping over the facet system here (not using it in this planning first step)... Is it true that we can start planning this way? (if not, please warn!) ...the resource types themselves are related to facets also so we have the info there if needed.

Not sure what you mean by jumping over the facet system.... The planner doesn't see the facet system, but the facet values are used to link the pattern slot and the resource types, so we can't get rid of them in the background.

Otherwise, if I understand you correctly, seems OK.

(Note, I'm first going through and answering questions, then will step back and think about the whole thing. Also, I'll do a picture to try to clarify the data structure. I personally always need a picture.)

[fosterlynn]

In the 'organization' page for admins, are we using 'child' relations to make the indentation of the list.

Yes, we can use the "child" behavior of the agent association type for this.

[fosterlynn]

I'll do a picture to try to clarify the data structure.

Actually this is probably better: starting at slide 9 of this tutorial https://speakerdeck.com/mikorizal/3-nrp-resource-type-setup-concepts-and-tutorial (only if it helps of course, feel free to ignore if it doesn't :blush: )

[fosterlynn]

The goal of the 'plan-work' page is to define a process task and set a related open order, isn't it?

Yes correct. This is the "manual" version of planning, when there is no recipe. The user can pick as much or little as they want on this page, and then can add more on the process logging page also. I'm not sure which is easier to use actually.

In terms of the order assignment, that is there so you can add a process plan to an existing order. Or it will create a new one if you don't pick one, just so all processes are attached to some order.

The other way to plan is "Plan Work from Recipe". This way all the user needs to pick is a resource type, and the plan is created.

[fosterlynn]

I decided I did need a picture, even if nobody else does. :) I think I got this right, but let's think about it. The red is where we need to add optional context_agent.

[fosterlynn]

Now I have questions. :) And discussion. Still thinking.

The project coordinator goes to plan new work, the first step is to choose a Pattern... that's an absolute mistery for any user (we need to explain what are patterns there). From what @fosterlynn said, the patterns will require also a context agent FK (if so, only for general contexts). So initially, only the patterns related any upward context agent are shown (maybe in a future release the coordinator can suggest new process patterns).

What you are assuming for "upward context agents"? Not sure there will be much in the way of parents. I could be wrong, just looking at the collectives who are joining so far. I think unfortunately each collective is going to have to learn how to do this. And I totally agree patterns are a mystery. This is a big training thing, maybe too big for some?

Unfortunately I don't see any way to try to do this with any global piece, because the model is too interconnected. Either everything is global, or everything is context agent related.

Maybe we can figure out a way to simplify it. For sure we could make patterns optional everywhere, and just show all resource types, maybe filtered by the behavior field on resource type. Just brainstorming here.

because anyway the filtered set of resource types should be filtered also by the project relations, so it will catch resource types from upward relations (inheriting from parents) and also from downward relations (skills from the project participants).

What do you mean downward skills from project participants?

Also a side note next to the field can say: "If you think this resource type can be useful for other projects, please select the intended scope choosing a more general context agent.

a task or notification for review the new type is added to the coordinators (maintainers) of the parent context agent*. The new resource type will be linked to the project agent or any of its parents,

I am wondering if we are getting too complex when we don't know if there will even be parent-child projects? I wonder what examples you think we have or will have, or what is the general use case?

[fosterlynn]

custodian (not used?)

correct, this is a Sensorica particularity, we can get rid of it

the supplier and customer behaviors (can they be mixed in a single tree?)

yes, these are not really correct because they are the same relationship, just different directions. They are useful from the perspective of one network with relationships outside the scope of the installation. But I don't think that is really true for FC. Needs re-thinking.

[fosterlynn]

I think I am missing something on the trees of agent relationships. It is a cool UI concept, but I am missing the use case for it. Is it about traveling the relationships for notifying other agents about new resource types, etc?

By the way @bum2 , I am impressed and happy with how deep you are getting into this. Don't let all my questions and comments imply anything else!

[fosterlynn]

The other part of the release, the Exchange Types, is also clear to finish (if someone have time)... We decided to make a predefined set of exchange types for projects and a 'suggest new exchange type' feature like the new skills suggestion system.

I didn't think we agreed on this. I still need to go back to Decentrale (hey where is Chris? I don't see his github account....) and remember where we were getting to on structuring their economic flow using exchanges. I think they were pretty specific to them. And I suspect collectives will want to define their own. And I'm worried about adding cumbersome processes of requesting things of overworked admins, who then have to coordinate and normalize among various users.

That doesn't say we shouldn't make an attempt to define a base set of global exchange types for people to use.

[fosterlynn]

^ Another thought on exchange types - since they will reference resource types through facet values, and resource types will be by context, I think that forces us to do exchange types by context also.

[fosterlynn]

Thinking.... here is a list of existing functions I think would want to be pulled over to the work app for this, possibly mostly for coordinators(?):

Facets and Facet Values (new page, currently only in admin) Process Patterns Exchange Types Resource Types Recipes (Manufacturing and Workflow) Plan work without recipe Plan work with recipe

And then add notifications and the other functions needed for the coordination workflow between projects envisioned by @bum2 .

Not a small scope, and it will require quite a bit of testing.

[fosterlynn]

The two biggest questions in my mind:

1. What can we do to make this actually understandable by all these individual projects? Perhaps the system is too configurable? How can we balance global and context specific configurations? Is there a way to make the whole facet value scheme optional, only needing to be added when the resource type lists get too long or confusing? (I think so.) What kind of training could help, or is that unrealistic?
2. What is Freedom Coop's vision for building economic cooperation between group members? And how do we think that will develop over time? What are the immediate requirements based on the groups joining FC now? How should we work towards the vision in steps based on the reality as things develop? (Basically I like a lot where @bum2 is going with this in thinking about building a more cohesive regional economy. I am not clear how this will develop organically on the ground. And I hesitate to make guesses.)

Regarding 2, this minute I see three aspects of possible coordination on these configurations:

1. Groups exchanging with other agents, either groups or people, with finished products or services. I'm thinking more retail, or one-off needs here, basically offers put out there generally and advanced search capability. For this, it seems like exact resource types don't need to be coordinated, more key words and categories. This might be all handled by FairMarket, I don't know. But will need some kind of interface.
2. Groups that develop coordinated supply chains within Freedom Coop. Here groups will need to coordinate on resource types and exchange types, for the specific touch points in the supply chain.
3. Groups that are related to each other, maybe parts of an umbrella organization or something like that. These groups might want to use all or some of the same configuration.

I'd like to have a more broad discussion, especially on 2. Maybe in the admin group assembly, or the Freedom Coop assembly? Or just in telegram?

What are other people's thoughts?

[fosterlynn]

Aha, @bum2 I start to see that 2. above might be where you are going with your proposal to group types of agent associations? To see who might want to coordinate with who on these configuration pieces?

OK, I'll stop posting and wait for some responses when they come.

[bum2]

Yes @fosterlynn , i'm imagining a way to organize common types and patterns per sector of activity, using the multi hierachy system we already have with context agents (very powerful). With this approach we'll need to create groups of projects that will share resource types, exchange types and patterns. Every project can be in many different groups, so inheriting 'types' from different sources. The common types will be related the general groups and also particular types can be set only related the project. In order to exchange or collaborate in a chain, the used types must be common.

To retrieve the list of possible resource types available for a project, i propose to query the two sides of the associations in search of resource types: for one side get the resource types related the project parents (either 'member', 'participant', 'child', 'customer-supplier' behaviours, but not 'peer') and for the other side get the resource types related the project associates (active participants or coordinators), their skills are resource types available for the project, and perhaps other resource types related their skills... of course also are included the 'types' related only the project, so there are 3 sets of types to choose from (own types + upward inherited + downward related).

I understand that exchange types are related facets and resource types, so they should be also related a context_agent if we make this step (and the same 'parent types' inheritance).

Another approach is to use the faceting system as a kind of 'categories' or 'tags' related the sectors of activity, and then the 'types' can be related these facets or categories, so having one or many categories will affect the number of available choices for 'types' in the project UI. This way, the custom 'types' created by the project are not related any facet... If anyway we have to relate the custom 'resource type' to the project that creates it, then makes sense going directly with the first approach and use the 'context types' instead of the 'facets types'. I'm also thinking in a combination of both, because i think maybe we need the facets anyway to run other ocp features... is it true? The point about mixing the two systems is the level of complexity it gets for us... but one simple way to figure it is: every group of projects (sector or subsector of activity) is also a facet or category (e.g. same name), 1 to 1. This way we can have the faceting system running in parallel with the context-types system...

At long term I think is good to group the projects in meta-projects per sector of activity, because this sectorial 'projects' can be used to communicate, can be one day 'coordinated' by a sectorial team, etc. The context agent in ocp will be already there, waiting interested people to coordinate and take care of common aspects of the sector. The best of this is the fact that a project can be 'child' of many parents.

[fosterlynn]

I'm also thinking in a combination of both, because i think maybe we need the facets anyway to run other ocp features... is it true?

The facets are only there to categorize and filter resource types in various situations. That said, we need them for anything that uses a process pattern or exchange type - and they have infinite uses beyond sector grouping - so they'll be there in any case.

[fosterlynn]

then makes sense going directly with the first approach and use the 'context types'

Would you create a context agent for each sector? (Or for whatever groupings make sense to the groups themselves.)

In any case, I think it is a powerful vision, and takes NRP to the next level - community / regional economic ecosystems.

[bum2]

Unfortunately I don't see any way to try to do this with any global piece, because the model is too interconnected. Either everything is global, or everything is context agent related.

Then is going to be everything 'context agent related', but not isolated one from the other because most of the things will be related general contexts, so inherited by all childs.

I think I am missing something on the trees of agent relationships. It is a cool UI concept, but I am missing the use case for it. Is it about traveling the relationships for notifying other agents about new resource types, etc?

Yes, one use case is for notifying other agents or the parent project coordinators about new types, but is just to make clear the different behaviors or kinds of relations. Sometimes we have to reach the parent of a project, so as they can be many parents, we can choose the kind of relation to narrow a subset. These ui trees i propose are indended at admin level just to see the relation-kinds clear and navigate with any of the trees. Of course is nothing urgent, just another todo. The point about this is that i was puzzleing my mind around these relation types and their grouping (behaviors), and the role of the 'child' behavior (or 'node'), different from the 'member' behavior (or 'participant'). What is supposed to be the difference? I'm assuming the 'member' relation is somewhat more 'official', like membership or being part of a commission or project, and the 'child' relation is a more general relation, like being into a sector or another of activity or being a node in a network. If we do this diferentiation, maybe we need to edit actual ocp data or duplicate relations (one with child, one with participant, with the same parent) to achieve what we want.

[fosterlynn]

In any case, I think it is a powerful vision, and takes NRP to the next level - community / regional economic ecosystems.

That said, I still wonder the best way to implement. My 2 cents: I don't think FC has a use case for this yet. It is going to take some thought and some coding. Some collectives are waiting for this before they can complete their OCP setup.

Proposal for discussion:

• First phase we just make this work for each context agent. And at the same time make patterns optional. (Not sure about exchange types.)
• Second phase we add in the agent relationship piece as additional search for all of these context agent related items. And related notifications. I think this is all additional functionality, won't undo anything on the first phase.

What do you think?

[fosterlynn]

One thing to add to the above: Besides the implications to the types-by-context-agent issue, there is a whole piece of discovery, formation, etc. of how projects get to know of each other, figure out how to form associations with each other, etc. within the ecosystem. It strikes me as a big set of features that will require quite a bit of discussion and thought?

[bum2]

... Perhaps is better to get rid of any differentiation (between 'child' and 'member' relation behaviors), and simplify the relation behaviors to 3, joining the 'child' and 'member' concepts into one? In a possible future, the projects with same kinds of activity sharing common types, organized as childs of a sectorial group, will start to use the sectorial grouping context agent really as a global project, so at that point their 'child' relations can be changed to a 'participant' or 'member' relations... so why not directly make them participants from the beginning? This way we can simplify more at ui and dev level. To be a 'child' project of another will mean to 'participate' in it (even if not really initially), and to be a 'node' of another project will mean also to 'participate' in it, or to be a 'member'. We can still use the diferentiation we have with 'members' and 'participants' (being both 'member' behavior) and the 'candidate' pre-state of each.

First phase we just make this work for each context agent. And at the same time make patterns optional. (Not sure about exchange types.) Second phase we add in the agent relationship piece as additional search for all of these context agent related items. And related notifications. I think this is all additional functionality, won't undo anything on the first phase. What do you think?

Very good, let's do this two phases.

In your wonderful diagram you pointed the need to connect facet and facet-values also to context-agents... if this is really a structural need, can it be to setup them automatically in the back? or is really needed the user to define these facets? ...

[fosterlynn]

Perhaps is better to get rid of any differentiation (between 'child' and 'member' relation behaviors), and simplify the relation behaviors to 3, joining the 'child' and 'member' concepts into one?

I can take a look in the system to see how we are using these. One way is on the Organization page, the child type associations show as the indented hierarchy when you open the page; the member and all others show differently. I can't remember other implications but I'm pretty sure there are some.

I do see gray overlap, but to me children imply there is only one parent - like Sensorica the organization is the parent of all the projects organized within Sensorica, who wouldn't exist without Sensorica. Member etc. is more like independent groups or people becoming associated with each other into a group for a reason. Like Decentrale is an independent collective that has chosen to associate itself with Freedom Coop, and could associate with any other number of agents.

On the other hand, we can change whatever we want. :smile: This all grew up in response to specific needs and I'm sure could be improved.

Very good, let's do this two phases.

OK good, then let's figure out how to proceed.

In your wonderful diagram you pointed the need to connect facet and facet-values also to context-agents... if this is really a structural need, can it be to setup them automatically in the back? or is really needed the user to define these facets? ...

Facets and facet values are definitely an art, require analysis, and are hard to do well. There is no structural reason in the model that we need to have them connected to context agents. Do you think the central admins could figure out a scheme that would work for everyone? I was thinking groups might want to do their own. But maybe it is worth giving it a try. Gives us a simpler start. Which is a good thing!

[bum2]

One think maybe missing in the diagram by @fosterlynn is the AgentResourceType model. It happened when creating the context_agent FK in the EconomicResourceType model, the django crashes due a Reverse accessor for 'AgentResourceType.agent' clashes with reverse accessor for 'EconomicResourceType.context_agent'. HINT: Add or change a related_name argument to the definition for 'AgentResourceType.agent' or 'EconomicResourceType.context_agent'. Perhaps is not needed the new FK? first i want to understand the use of this AgentResourceType model in OCP... Why it has nearly the same fields as the EconomicResourceType model? (but also a required FK to it)

[fosterlynn]

The AgentResourceType is used for agent skills (types of work the agent has done or can do). May have other uses too, @bhaugen could fill in more if useful.

But in any case, it is not used for context agents, and supports a many-to-many, which is more than we want, so we still need the foreign key. We just have to get unique names everywhere for the related names. Sounds like the related names back to EconomicAgent. If more info is needed, let us know, I can give you more detail, but would have to dive in a bit.

[bhaugen]

The AgentResourceType is used for agent skills (types of work the agent has done or can do). May have other uses too, @bhaugen could fill in more if useful.

It's actually a relationship between an Agent, a Resource Type and an Event Type. And it keeps a total of the quantities of that combination recorded in Economic Events. So for a skill, it's the amount of work an agent has done using that skill. For a supplier, it might be the total quantity of a resource type that the supplier has delivered. Etc. It's redundant: you could figure it all out from the history of economic events on the fly, but the summarized quantities were a lot faster for diagrams etc.

[bhaugen]

Perhaps is better to get rid of any differentiation (between 'child' and 'member' relation behaviors), and simplify the relation behaviors to 3, joining the 'child' and 'member' concepts into one?

There is now a lot of data inheritance going on using child relationships, where something is inherited from a parent. Member or participant does not necessarily have the same semantics. So you'd need to be careful if you merged those relationships into one. They are not semantically the same.

[fosterlynn]

It's redundant: you could figure it all out from the history of economic events on the fly, but the summarized quantities were a lot faster for diagrams etc.

It's not totally redundant, because people can enter their skill (in admin only) - but conceptually, it can show skills you have used or skills you say you have.

[bhaugen]

It's not totally redundant, because people can enter their skill (in admin only) - but conceptually, it can show skills you have used or skills you say you have.

True. Obvious. Why didn't I think of that? I'm losin it!

[bum2]

To achieve a tree of exchange-types and a tree of resource-types to choose from or insert a new one i had two or three options:

• one option is to try to integrate the mptt system into valuenetwork core models (glups)
• another other option is to make new models with tree funcionality (mptt) in work app
• the third option is to just add a whole new app already done by me 2 years ago, called General, that was the core foundation models of the first working version of gestioCI (not used yet), very different from what is nowadays gestioci.

That "general" app is a proof-of-concept in django of a holistic structure of data proposed for the huge project of the Common Distributed Database (see 'holodata' in fairnetwork) and is based on class inheritances and some mptt Tree structures, like the one for Types of items or the one for Skills... (exactly the ones we need in ocp).

I think this General app is also very useful for many purposes like a general or local mapping of stuff around, and gives us a super flexible way of making future developments. So i wanted to try to run this app in parallel with Ocp and then use some parts of 'general' into ocp's 'work' or 'valuenetwork' apps, like a helper side app. In this approach-study I'm doing is only used a branch of the general.Type model (OCP_Record_Types) and two interface models called OCP_Material_Type and OCP_Nonmaterial_Type (also branches of the main general Type tree), that include connections to ocp's EconomicResourceType and FacetValue (one2one).

The whole parts of General app about entities, arts-skills, relations, locations and resources are NOT used in ocp. So, even if you see lot of new tables, only one is used from general app (Types) and the three interface models (for Material and Non-material types and for Record types).

The point is that the tree of types shown in ocp will come from this general app, but they will connect again with ocp resource-types or exchange-types once choosed. Actually the General will only be used for this: to show user selectors in nested style (not limited in levels) and an easy way for coordinators to manage this trees (drag'n'drop) and suggest or auto-add new types. The exchange-types now use a tree to choose from (general 'ocp-exchange-types' branch) and after choosing it returns a related ocp exchange-type to the ocp flow.

Finnally I understood how to join valuenetwork app and general app related resource types, and the point is that some resource Types in the general app are ocp's "facet values" and others are ocp's "resource types". Now these general types can be connected to facetvalues or resourcetypes (in the work.Ocp_Material_Type and work.Ocp_Nonmaterial_Type models), and the OCP code remains running the same, using its own exchange-types, resource-types, facetvalues and facets.

The condition used now is about the facets, to relate one or another 'general' model. So now the facets will be 3: Material, Non-material, Skills. Each one relates a different model in the general app, in order to show the general trees of types. That integration also means that when editing or adding new sub-types in ocp they will be done also in the general app, so they can be used by other apps or platforms if needed (if is public data, like categories), and also means we have ocp groups to manage and comunicate about the categories and branches needed for the projects in each sector (because there's also the context types inheritance rules)...

[bhaugen]

@bum2 I'll check this out in detail if and when you push some code I can run locally, but you need to be careful with concepts like resource types. They are part of an economic ontology that has been carefully design by a global community since 1980 and is an ISO standard (listed in https://github.com/FreedomCoop/valuenetwork/wiki/Links ). That's what NRP and thus OCP are based on.

That's why the whole thing works both economically and for accounting purposes.

[fosterlynn]

Finnally I understood how to join valuenetwork app and general app related resource types, and the point is that some resource Types in the general app are ocp's "facet values" and others are ocp's "resource types".

If it is a tree, it could be all resource types with parents. Facet values are not a tree structure. But I don't know if that is best or facet values are best. Will look forward to taking a look!

To achieve a tree of exchange-types and a tree of resource-types to choose from or insert a new one i had two or three options:

I thought this was #156. @bum2 are you also doing this issue while you do the tree UIs? That is, do the trees work with resource types that can have a context agent related to them?

Another question: I don't think exchange types will work with a tree structure, they don't have inheritance, and it would be really hard to implement that. Why do you want exchange types to be in a tree structure?

[bum2]

The resource types of ocp are not modified in this approach, only the way to select them with a layer of trees and common sectorial branches (linked to facetvalues) and also with a scope or visibility, related to the nestable context agents in ocp. As I see when comparing REA and the General app, the Resources is what i call 'artwork' (names of things), the Events is what i call 'arts' (verbs: relations and skills) and the Agents is what i call 'beings'... the structure of the General app class inheritance is drawed in a diagram, based on 5 main types of information:

Only some of the concept-type branches will be used now in ocp, but perhaps one day we can also use and link other stuff like the entities, the relations, the spaces, the resources... step by step and only if we need it for any purpose in ocp or elsewhere...

[bum2]

I thought this was #156. @bum2 are you also doing this issue while you do the tree UIs? That is, do the trees work with resource types that can have a context agent related to them?

the skills are not modified yet, perhaps after this main 'types' issue i can focus more on the skills side of it (resource type of 'skills' facet)...

Another question: I don't think exchange types will work with a tree structure, they don't have inheritance, and it would be really hard to implement that. Why do you want exchange types to be in a tree structure?

Only the UI chooser (select) will show tree structure (from general app) but the exchange types will not have hierachy: the selected type is linked with a real exchange type behind the scene... Now i'm setting a common set of exchange types, very general, and not letting coordinators create their own. After this season, we can make more sectorised exchange types to have smaller sets of resource types to choose from when creating an exchange (when we have too much types to choose from).

[bhaugen]

@bum2 I am confused. Your General proposal seems unrelated to this issue, which is about connecting things to context agents.

This context agent issue is conceptually simple and fairly easy to understand and implement, although wide ranging in terms of scope of system change. The General app is conceptually complex and possibly difficult to integrate. You wrote above, that it is

a whole new app already done by me 2 years ago, called General, that was the core foundation models of the first working version of gestioCI (not used yet), very different from what is nowadays gestioci.

So it has not been used, that is, not proven in practice. And amounts to layering another ontology on OCP. Seems high risk, but interesting: doesn't mean we should not do it, but we should probably do it carefully. It's clear that you have been thinking about this Holodata ontology for awhile. I'd be interested in discussing it more: how you came up with the ideas, who else agrees with them and wants to use them, and why gestioCI did not adopt them.

Do you intend to make these both parts of the same branch and set of system changes, developed and tested at the same time, where both succeed or fail together? That was Lynn's question above, not clearly answered as far as I can tell. If you do, that seems like a big mistake to me.

General seems to fit this issue better: https://github.com/FreedomCoop/valuenetwork/issues/156

Or maybe General would work better as a new issue (and branch) since it is more pervasive than just skills, and as I mentioned above, is most likely worth a larger discussion.

P.S. Lynn thinks I might be misunderstanding, that you might just mean some UI changes. If so, please correct my misunderstanding.

[bhaugen]

@bum2 you have not responded about whether you are working on your General app in the same branch as the context agent issue. If you are, then the context agents will not be deployable (nor can anybody else build anything else on them) until you are finished with the General app. That's why we keep asking.

[bum2]

Hi Bob, sorry if not seems related... To deal with the context agent of a resource type or exchange type, was needed to figure out how a coordinator will choose from existing types, and then proceed to design the workflow of creation of new exchange or resource types, only for a project context or as a shareable type for more projects. The first part, how to choose a type, is the motivation for the incorporation of the General mptt trees. I'm totally sure this app can help in many other places of ocp, but we will see it step by step. I've tested the behaviour of the context agent applied to exchange types, mixed with the general types trees, and it works good: if an exchage type is set for a particular project context, it only appears if your project is related to that one, so the filtering of types by context and also by tree branches works good together.

I'm trying to put all this advancements in testocp so you all can test it, and then I want to keep developing the parts about new types creation by coordinators (starting with resource types). Also i want to put the new 'resource type choosing tree' to many other places where a resource is choosed, like orders and plan work. Also i want to address the skills choosing system around, and after I can look again in the new skills creation flow, just to update a bit on the skill suggestion system by @bhaugen . As you see, i can't focus other issues like the wallet bugs, the db string system, the relations page or many others.

About the reason for why gestioCi didn't use today the code i did, is a long story. Will try to make it short: Starting summer 2014 no one was able to commit to the task of building a working system for managing integral cooperatives, very needed by the CIC, and the agreed urgency to start using it on 1st September same year. There was lot of work by coordinators about gathering detailed requirements with the commissions and also there was a part of the code (about invoicing) being worked by another developer ( @aleph188 ). Finnally I took the challenge of developing a working system for all the management of membership process, selfemployed management of documentation, invoicing and fees, but also intended to manage resources, locations, skills, relations, etc... in only two months (crazy me!). The other dev was finishing and adapting the invoices part to the General schema (ontology) and I did the rest. The condition i putted was that no real custom GUI interface is possible to be done in that timeframe, and the system will work using the default 'admin' automatic GUI of django (without dealing with web design). This is what i did: a working system that can start managing real data from 1st release, and let you do everything in the admin pages (we create special permissions to access some admin pages for coordinators or users at CIC). The tool was ready to be used starting september 2014 (without a 'frontend'), i was doing the formation for users and so on (other techs at the informatic commission was not around). Then i had to leave the city for 15 days (in which we start faircoop) and that was at the end the strange reason for kicking me out. When I came back to the gestioCi process development the admins at the informatic commission had erased my admin access to the app and after trying many ways i discover that was in purpose. They argue nonsense about their fears and they was angry for my 17 missing days, but at the same time they block me the access, they were asking me for giving good structured basic sql data to them because they break their instances and lack understanding to recover the system. After realising they kick me out the server in purpose i get very angry with them too and left the informatic commission of cic (CICIC) to focus more in faircoop and coopfunding. After months I knew they found other devs and they started again from scratch, and after two years the tool is just starting to be used now, with a lot of missing basic things. I don't study yet the new gestioCi code to see how flexible it is to manage integral data (all kinds of stuff), to scale-up and to adapt to other integral cooperatives with different configurations...

I still believe today that the general approach of this General app is very useful and flexible enough to manage the needs of integral cooperatives of multiple projects of any kind and sector. Over the General app was builded the Welcome app for membership process at cic and also the Invoices app for the self-employed members. Nowadays the General app is not root class of nothing, but I want to make an integral mapping tool for local and worldwide needs, to track and share entities, resources, places, skills, relations, etc... That general common mapping tool can be a part of the OCP one day or instead it can live apart in another domain. This General ontology is also proposed for the Holodata project as a conceptual work, and maybe also can be used the django files, but the whole structure of the backend DB can't not be classic SQL nor centralised. For a real common database (big data) the only way is using distributed and sharded scalable db systems. Let's have time to talk about the commons database (in fairnetwork holodata thread?) and the existent technologies related (synereo, maidsafe, riak, couchdb, neo4j, etc).

[bhaugen]

Thanks for the response and explanation. A couple of followups, but then I want to discuss the General app a bit when we have some time and space, and maybe after you push enough of the models so I can follow along technically as well as semantically.

As you see, i can't focus other issues like the wallet bugs, the db string system, the relations page or many others.

I'm on the wallet bugs with help from Santi. @fosterlynn will take over the relations page, at least for now.

You need to communicate with the new programmers if you want them to work on the db string system, which they have volunteered to do. I think it's a good min-project for them. But it's your issue, you know what is needed and are our local expert on Fobi, which is where a lot of the db translations will go. We can't do it. And if you don't, I would not blame them for getting discouraged. Which you don't want to have happen.

So you need to step up on that one. Take time away from the General app, it will be worth it to have two more programmers working on OCP.

Re the General app: I'll add some comments in Telegram that I think will make clear what I want to do in relation to your work on that. We document that in a different issue, but first I'd prefer to have some more casual discussion, which will be a lower priority for you to respond to than making contact with the new programmers and giving them some guidance about Fobi etc.

For a real common database (big data) the only way is using distributed and sharded scalable db systems.

Sharded is a different animal than distributed. We are working on Value Flows on how to decentralize OCP-related systems, but it's not done yet, and the technical implementations are immature as well. It will happen, but not this year. Sharded is doable sooner, if we have somebody who knows how to do it. I don't.

]> Let's have time to talk about the commons database (in fairnetwork holodata thread?) and the existent technologies related (synereo, maidsafe, riak, couchdb, neo4j, etc).

Those are all very different birds from each other. Some are whole systems, some are dbs. But the hardest part of all of it is the ontology and logic. After that, it's picking a technical approach. You can read here about the approaches I have been thinking about: Searching for a breakthrough. As you can see, it is a bit of a mess. A collection of notes to myself. Don't waste a lot of time on it now. But as you can also probably imagine, it is most likely 2-3 years off. None of the candidates you mentioned above get a mention in that set of notes. I'd be happy to discuss them all in detail, but I don't think it's time yet. We need to work through a set of OCP priorities using the platform that exists now.