Process nesting

DO NOT MERGE until we have had some feedback and discussion!!! This is a bit rough yet.

This creates the ability to use processes as higher level entities such as plans, budgets, etc. It maintains the input-process-output pattern.

Looks like a very resilient foundation for developing this key modeling feature! Thanks so much.

I don't see a clear need to define that whole purpose part in VF vocab, unless we can clearly define consequences of using those 4 specific instances that you propose.

I think we need Plan (that is where all of this started out) - we're using it all over the place in FairCoop. And @almereyda and gang are doing Budget for this Solawi app. So either we need something called Plan and something called Budget and/or Budget Process or similar, or we need to have some definable higher level processes. Maybe they could be subclasses, that could be another way to do it? Although if we ever want Transportation, Transformation, and maybe Transfer, that might be orthogonal, not sure. But I sort of like calling it out in subclasses.

I'll define them and see how that sits.

I also would like to understand why do you see need for a different variant of vf:includedIn for intent, commitment and event. I don't think its meaning changes depending on the phase of the flow one uses it with.

I wasn't sure, I started with just includedIn, but didn't see a machine readable way to define that only Intents could be includedIn Intents, Commitments includedIn Commitments, etc. If there is a simpler way to define it, let's do it, I don't like this very much either. On the UML side, it is easy to use the same name on all 3.

I wasn't sure, I started with just includedIn, but didn't see a machine readable way to define that only Intents could be includedIn Intents, Commitments includedIn Commitments, etc.

I think we can just explain it in prose, implementations still need to validate data somehow and instead of relying on separate properties checking type of subject and object should work as well.

I think we need Plan (that is where all of this started out) - we're using it all over the place in FairCoop. And @almereyda and gang are doing Budget for this Solawi app.

In cases where plan has as the last chronological intent issue or load flow. Relating that intent with that plan using inputOf or outputOf doesn't seem accurate. That flow would become input to transportation process included in some other plan. Similar receive and unload intents could appear in a plan but not as inputOf or outputOf that plan, once again transportation process planned elsewhere would have it as output.

I think we can just explain it in prose, implementations still need to validate data somehow and instead of relying on separate properties checking type of subject and object should work as well.

Changed. Take a look and see if it is right, please @elf-pavlik .

In cases where plan has as the last chronological intent issue or load flow. Relating that intent with that plan using inputOf or outputOf doesn't seem accurate. That flow would become input to transportation process included in some other plan. Similar receive and unload intents could appear in a plan but not as inputOf or outputOf that plan, once again transportation process planned elsewhere would have it as output.

I'm not sure I understand this? I think the last flow in a plan will always be an output, like produce, improve, unload. That would apply to any nesting process - it includes whole processes with their inputs and outputs, not part of any sub process. Am I missing something? Or should it be explained better in the doc?

I think the last flow in a plan will always be an output, like produce, improve, unload.

In case where we have three agents

• Bob - grows, harvests and packages tomatoes for shipping
• Alice - produces salsa
• Claus - transports products

Bob might want to plan all the way until the load (issue) of packaged tomatoes. Alice might plan all the way from unload(receive) those packaged tomatoes. None of them would plan the whole transportation, only Claus would do the planning of the transportation process. In that case those load and unload only seem to stay in scope of Bob's and Alice's plans, but as input and output only of Claus' process.

(Without trying to follow the complex flow above) Plan is deeply important. A specific Budget is essentially IMO a type/ subclass of Plan, although that hierarchical semantic relationship doesn't necessarily need to be explicitly denoted in the UI of a systems modeling and mapping system. The hierarchical relationship probably should be visible by default in a standard UI-- to help agents learn and remember the language-- and certainly does need to be present or semantically linked in some machine-readable way.

Actually in that case of plan leading to load / issue or starting with unload / receive, on can simply use vf:inScopeOf to relate that flow to a process, no need to only use more specific vf:inputOf and vf:outputOf for relating flows to a process.

I would still like to clarify something about the purpose. proposed

• operational
• plan
• budget

don't seem to have any consequences other than allow to classify processes. We could possibly just rely on vf:processClassifiedAs and recommend references from wikidata

• budget - http://www.wikidata.org/entity/Q41263
• plan - http://www.wikidata.org/entity/Q1371819

etc.

A specific Budget is essentially IMO a type/ subclass of Plan

Yes, basically agree, budgeting is planning of one sort.

Bob might want to plan all the way until the load (issue) of packaged tomatoes. Alice might plan all the way from unload(receive) those packaged tomatoes. None of them would plan the whole transportation, only Claus would do the planning of the transportation process.

Now I understand. Good question. First thoughts: I think the load and unload have to be input and output to Claus' transportation process, true? Normally he would load and unload his own truck. Load could even be its own process. So that means after the packaged tomatoes are produced, that is the end of Bob's plan, unless Bob wants to include the transfer of responsibility to Claus in that plan. (Sorry, can't seem to get away from those transfers.) When Alice receives the tomatoes after they are unloaded, there is a transfer of responsibility from Claus to Alice. (This is apart from whenever the transfer of ownership takes place.) I think transfers of responsibility will happen at the edges of scopes, and cross scopes in this kind of example. But processes with their events won't. (There could be transfers internal to scopes, but that is a different use case.)

I would still like to clarify something about the purpose. proposed operational, plan, budget don't seem to have any consequences other than allow to classify processes. We could possibly just rely on vf:processClassifiedAs and recommend references from wikidata

I thought about that too. But Plan and Budget are not really like process classifications, which are more like Planting, Harvesting. They seem less like what it is, and more like what it is for, how it is used.

But Plan and Budget are not really like process classifications, which are more like Planting, Harvesting.

I think people can classify things using which ever and as many references to taxonomies as they like. All it does it helps filter things based on what categories they reference. I recall that in NRP you have types system where types have also other responsibilities beyond just classifying / categorizing things. In VF classifications have just single purpose - categorizing things. I don't know if we make it clear that one can use as many references as one wants for classifying purpose, so a process can stay classified as plan, manufacturing and anything else that people find helpful to reference.

I think people can classify things using which ever and as many references to taxonomies as they like. All it does it helps filter things based on what in taxonomy they reference. I recall that in NRP you have types system where types have also other responsibilities beyond just classifying / categorizing things. In VF classifications have just single purpose - categorizing things. I don't know if we make it clear that one can use as many references as one wants for classifying purpose, so a process can stay classified as plan, manufacturing and anything else that people find helpful to reference.

Yes, this is part of what I am trying to figure out. If we only the classification layer for things like searching for something, and it is basically just matching text, then this makes sense. And yes, in our software we do use that layer as more a "knowledge layer" which can encompass defined behaviors, policy, etc. It is very useful, in that way you can drive behavior with data that can be user defined. I think we will need to do some of that for recipes. And we do it now for Actions.

If you are only classifying for searching, then it is helpful to have as many classifications as make sense. If you are defining behavior, what a thing is and how it works, then you might want only one that does that. Seems like we want to support both.

If we just have classifications in the top layer, then we need to have something like subclassing all over the other layers so there is a place to define behavior. And subclassing is problematic when we need flexibility for users to define what they want to represent and to do with it, and the combinations of behavior aren't always predictable.

There are a lot of nuances in this stuff, and the part I am struggling with is where to draw some of those lines for simplicity and flexibility and whatever else. As well as rdf vs oo/relational implementations. Nothing is perfect, and we are working with the modeling paradigms we have in the industry. So..... still thinking.... but the conversation is useful I think.

It is very useful, in that way you can drive behavior with data that can be user defined. I think we will need to do some of that for recipes.

I recall that we already agreed that Classification != Recipe, even that in NRP you made architectural choice to combine those responsibilities into single Type. When we get into Recipes, we will need to create dedicated constructs for that. Classifications only stay responsible for categorizing things.

If we just have classifications in the top layer, then we need to have something like subclassing all over the other layers so there is a place to define behavior.

I think it might come more practical to see classifications as sidebar not a layer, constructs on any layers we define will use classification references for purpose of categorizing.

When it comes to including constructs people can use to define behaviors. So far I think we only have actions defined as subproperty of vf:increment and vf:decrement to clarify how they affect resource. For other behaviors I think we need to create dedicated Issues to consider them. What we could do already, we should not expect from classifications anything other than categorizing all kind of things.

I think it might come more practical to see classifications as sidebar not a layer, constructs on any layers we define will use classification references for purpose of categorizing.

OK, that seems like a better visualization for classifications, agree they will be used for anything, now that I understand how you are defining them. And they should be defined so anything can have multiple classifications.

Seems also that classifications themselves then don't need to be defined as classes in VF, just properties inside the 3 layers that can reference classifications from wherever that might be defined in some other vocabulary, or not, just be taxonomies on the web or whatever. Could be processClassifiedAs, etc., or could be just classifiedAs, and it is totally flexible. Does that make sense? Or do you think we need the class with rdfs:label there for vocabulary consistency? I'm fine either way, it is something more in your areas of experience.

And then we come back to needing a name for the stuff that is in the "knowledge layer" not the "classification sidebar". Uh-oh.... :) But I can proceed for now and think about what from this Process model needs that layer and what doesn't.

Could be processClassifiedAs, etc., or could be just classifiedAs, and it is totally flexible.

I think you introduced distinct *classifiedAs for resource, process, exchange and transfer.

I would actually prefer to just have vf:classifiedAs with open domain and range, similar to vf:inScopeOf.

I would also more than happily delete all the matching classification classes. Preferably people will use shared knowledge bases like wikidata, which will not include those classes anyways.

And then we come back to needing a name for the stuff that is in the "knowledge layer"

Do you see something else besides recipies in "knowledge layer"? I recall us discussing all the recipe related constructs as optimization future which allows to better automate things. Preferably we could try to take care of this PR without diving into recipes, we already have some issues open for process and agreement recipes. I think we could start revisiting them next.

I think you introduced distinct *classifiedAs for resource, process, exchange and transfer.

I would actually prefer to just have vf:classifiedAs with open domain and range, similar to vf:inScopeOf.

That's OK with me, I thought you just wanted to rename the type objects because of overlap with @type in rdf, not change their meanings.

I would also more than happily delete all the matching classification classes. Preferably people will use shared knowledge bases like wikidata, which will not include those classes anyways.

Ok with me.

Do you see something else besides recipies in "knowledge layer"? I recall us discussing all the recipe related constructs as optimization future which allows to better automate things.

Recipes are more than automating and optimization, although they are that too. They fundamentally provide open knowledge - for example open hardware recipes are part of a movement for open sourcing what is now proprietary competitive manufacturing and production knowledge.

Other items so far are Actions, AgentRelationshipRoles, and we may discover more.

Preferably we could try to take care of this PR without diving into recipes, we already have some issues open for process and agreement recipes. I think we could start revisiting them next.

Yes let's try it that way. Or maybe we do a small separate PR that just deals with the classifications that exist? Then we can work from an agreed upon blanker slate for this PR. I can do that, although we'll have to agree on some naming.

Since we have #295 separate, I think for this one we just need

• remove all the purpose related parts and explain using classifications in prose
• remove process-nest.TTL, for purpose of creating smaller diagrams you could save your snippets on https://gist.github.com/ let's keep this repo DRY to simplify PRs

Working on the prose part, first draft pushed. Will work on more later, have a couple more things to say and haven't figured out what we need for types of upper level processes. But feedback welcome any time.

@elf-pavlik I've tried to think about this PR without having a way to identify process purposes, and at this moment, all of that is removed. Even though I like having processes "all the way down" (like turtles, if you read Dr. Seuss - citing Jolyon in ssb), I think we have to have the more specific concepts somewhere.

Apps will need to know what behavior to apply to processes used for different purposes. For example: Displaying all processes of the same purpose together for UI/UX. Like a list of open plans. Or, comparing budget to actual. Or this kind of thing valueflows/use-cases/construction-commons.md.

I can only think of the following options: subclass Process; create a role property somewhere that can be referenced (that was ProcessPurpose, name could be better); do it with a simple string (ouch!). Maybe there are other options.

Any way to support the examples above that I haven't thought of? Your preferences?

Apps will need to know what behavior to apply to processes used for different purposes. For example: Displaying all processes of the same purpose together for UI/UX. Like a list of open plans.

In the implementation from which you shared screenshots in #286 Could you just use vf:classifiedAs on processes and filter processes you display in UI based on it?

• budget - http://www.wikidata.org/entity/Q41263
• plan - http://www.wikidata.org/entity/Q1371819

Apps will need to know what behavior to apply to processes used for different purposes. For example: Displaying all processes of the same purpose together for UI/UX. Like a list of open plans.

In the implementation from which you shared screenshots in #286 Could you just use vf:classifiedAs on processes and filter processes you display in UI based on it?

Theoretically you could, but in that example, the UI wants to be able to work with other backends that support VF api. The classifications are now so unspecified, and can be of so many types and sources, that to get people to agree on that as a meaningful classification from some external source would be pretty difficult. Classifications as of now seem more useful for search and matching, rather than anything requiring some definition and common understanding.