Added RecipeAction to initiate discussion. #259
Conversation
|
👎 RecipeAction (naming) currently all 3 - Intent, Commitment and Event use vf:action property, IMO throwing another action here might just make things confusing could you please remind me how does it work? when one creates process from a recipe, probably from each 'RecipeAction' one would get an Intent, later Commitments and Events would follow. I use Intent here not as an advertisement but as what we get in planned process before actual commitments follow.
On the diagram above we had Input/Output Template, it seems that recipes also need some kind of Process Template != Process Classification. A while ago I fiddled with name Slot for processes instead used at that time InputOrOutput, maybe for recipes we could have vf:SlotTemplate and vf:ProcessTemplate ? |
Let's try to compare somewhere how Process and Agreement work 'side by side', possibly we may find a lot of similarities and where may end up with Process Templates we may also get Agreement Templates ~= Proposals |
|
Thanks @elf-pavlik ! I thought about RecipeInputOutput, although I didn't like it as much as RecipeAction, since to me this is the action part of the recipe. I agree, it is not a classification. It is what ties all those classifications into a recipe. There is no use for it unless there is a recipe, unlike the ResourceClassification and ProcessClassification, which are useful by themselves.
Correct. It is like the "consume 10 lbs tomatoes", "consume 1 hot pepper", "use 1 mixing machine", "produce 10 jars salsa". It could create Intents or could create Commitments directly, I think, depending possibly on prior agreements. I do like the name Recipe as part of it, but I'm open. :)
I still don't really like Template, because I think you mean something more specific than can be published as say an open hardware recipe that anyone can use. Why would recipes need something like a process template or something more than a process classification? Or maybe clarify what properties you are thinking of for it? |
OK, I'll give this some thought. |
In some other issue, we discussed that classifications would stay pretty much limited to
If you see it sufficient for process recipes the probably we don't need anything more than that. At the same time if we need something like I also don't find myself convinced about how you proposing to use We may have discussed earlier that 'Classification / Taxonomy Layer |
|
I recall we considered using term Flow in similar way I fiddled with term Slot, pretty much
Which also clarifies how those 3 create together particular progression. Thinking this way, how about
|
|
As I understand NRP, you have 'income redistribution' which pretty much works as agreements, and events and commitments from many processes stay under those agreements. In other scenarios events and commitments from one process can stay under multiple different agreements. So we have sort of 'indirect' M:M between processes and agreements. Hard to illustrate it but here I have thrown 2 agreements together with 1 process, not adding vf:under edges to avoid crazy noise.
Many offers and requests, where you can scale quantities - kilograms, hours etc. come similar to recipes for processes. Following a thought in https://github.com/valueflows/intent/issues/5 some kind of M:M between Flow Intent and Agreement Recipe seems helpful, to express openness for exploring various paths for creating Commitments for those Intents. Eventually one Flow Intent could cause multiple Flow Commitments possibly each under agreement based on different Agreement Recipe. Maybe Flow Recipe could also come useful here. |
NRP has value equations which are agreements that govern income redistributions. A value equation is defined for a context agent, which we have renamed "scope" in VF. A context agent can have more than one value equation, and use any of them for a particular income distribution. A value equation defines events that would be selected for income distribution according to a variety of filters. But the equations apply to economic events, not processes. So different events in the same process might be covered by one or more different value equations. (Even if one of the filters is "Process", as in, only select events from this process.) So it would get pretty tangled to add accurately to that diagram... |
|
P.S. this is a pretty interesting discussion thread. I am in no hurry to merge, if that shortcuts the discussion. |
I see your point. I need to make it work for multiple recipes that create the same resource classification and possibly use the same process classification. (Yes the recipe does need estimatedDuration.) Interestingly, I didn't see much that was process classification in say wikidata. I wonder if we even need that? Or if the process piece is really for recipes?
+1, will change.
Let's see what that would look like, and what "layers" make the most sense for conceptualization. |
Or RecipeFlow? (I will need to study your other comments and the whole discussion in more depth, and can't do it now.... will try for later today, and if not, tomorrow morning!) |
Process and 'ProcessRecipe' could possibly reference some broad classifications but don't have to. Also Process doesn't need to reference a 'ProcessRecipe'. Still I have impression that you look for something more than classification / taxonomy and in that case I would prefer if we don't call it a classification. |
In case of a Process where people harvest apples. Some people doing harvesting stay affiliated with Agent, a coop running that process, and participate in mentioned above 'income distribution' based on a set of 'value equations' that apply. At the same time in the same process some people doing harvesting work, don't stay affiliated and freelance / act as independent contractors. So their work (exactly the same harvesting work) dosn't happen under any umbrella coop affiliation agreement but happens under some specific agreement one per freelancing person. The 'Process Recipe' should not make any assumption about those agreements, it may just have n x 'Flow Recipe' - work (harvesting apples), once Process gets created and 'scaled' it will have 10 x 'Flow Intent' and later it will result in 10 x 'Flow Commitment' but each one can stay under a different agreement.
I have impression that in NRP you might not have supported such granularity of agreements for any given process. Relying on 'context agent' with a set of 'umbrella agreements' NRP might skip the 'Flow Intent' step and go directly into 'Flow Commitment'. For cases where one wants to have more possibilities of 'Conversation for Action' happening, Negotiation around 'Flow Intents' would lead to creation of 'Flow Commitments' |
@elf-pavlik what do you think about including just the label and a iri to something external that contains all the description or specification needed? Or maybe just the iri? Because some of the ResourceClassifications for example will be wikidata type entries, some will be models with a lot of detail surrounding them. Wouldn't need the taxonomy connections, because that would be outside VF vocab. And I'm not sure about using the [edit] Maybe the @id can be the linked open data reference (returns semantic data), while the url/iri (?) can be just a web reference?
@bhaugen disagrees with me on this. I expect he is right. Here are some thoughts (thinking out loud). (Haven't worked in your agreement thoughts @elf-pavlik ) [edit] I am doing the names with "Recipe" first because really the whole thing all together is a recipe, not each of those entities. We don't have any one class that represents the recipe. |
My opinion on NRP value equations re VF: I do not recommend that VF include them. Sensorica kept throwing more ideas into tne mix. Lynn kept designing and redesigning. I think it is a brilliant design, and handles most of the Sensorica use cases that the NRP base software could cover. But Sensorica is not enough experience. And our next experience, FairCoop, does things very differently. So I think they are interesting as a use case, but possibly not worth a lot of discussion here. |
I agree on this for all the gory detail, of which there is much. @bhaugen @elf-pavlik do you think we should remove it from the model all together? Right now we have subclasses of Agreement: ExchangeAgreement, DistributionAgreement. I think I added DistributionAgreement when I was adding the new relationship between events and commitments Reciprocity, but I didn't link to it. And I suppose DistributionAgreement is really a type of ExchangeAgreement for that matter. Mostly I am looking for a way to reference agreements when needed, which could be a lot of places, and to connect agreements to the classification / recipe layer as needed, which is part of this discussion. |
|
I only mean all the gory detail, not the subclasses of Agreement. |
|
Noticing that GR has gf:variantOf for their model class. I like that, but think it might be out of scope for VF. (?) I think that our model already allows for multiple recipes for a ResourceClassification (RecipeResource in my latest thoughts). |
Is this the same as our current model where events and commitments can each be vf:under an Agreement? And could it start to look something like this (on the right)? (Adding in other properties also as I think of it.) |
If based on clear use cases we find need to besides Resource Classification also have something like Resource Recipe I see no problem with that, Let's just try to back it with few use cases of what properties we would see instances of Resource Recipe using.
At this point I see no reason for anything other than Agreement which can help with grouping events, commitments and possibly intents. Possibly instead of subclasses later one we may want to use some kind of Agreement Classification but I would take lazy approach and don't try to figure it out until we really need it.
By trying to involve some of NRP design choices I don't intend to discuss if we should directly adopt them or not. In general I would see it as requirement that VF provides foundation to rebuild NRP systems and enable them to interoperate with other systems. Sometimes I just try to clarify where in NRP you might have made certain design choices taking smaller set of use cases as requirement. Since I see VF aiming at more diverse set of use cases, it may lead to other design decisions. Still in the end it should allow covering all the use cases NRP covers and other ones, which NRP can't handle based on mentioned design choices. |
|
How about in this PR we just add vf:RecipeProcess, vf:RecipeFlow and vf:recipeQuantity plus extend domain and range of vf:inputOf and vf:outputOf. Then I would like to continue conversation if we can also use vf:RecipeFlow with potential vf:RecipeAgreement or we need something distinct for agreements. Whatever we end up using with vf:RecipeAgreement possibly will need a way to reference vf:Intent in a way that multiple vf:RecipeAgreement would reference (possibly via qualified relationship) the same vf:Intent, possibly the same would apply for vf:RecipeFlow if we use it on Recipe layer. The nuance here comes that this vf:RecipeFlow 1:M vf:RecipeAgreement would mean that one can choose from those agreements to create commitment under that agreement from the vf:Intent or vf:RecipeFlow. |
|
Let's try to get this PR merged ASAP and for exploration how vf:RecipeFlow works with both vf:RecipeProcess and vf:RecipeAgreement I propose use case which I extracted from one of the previous comments in this issue #261 It will give us chance to work with instances of all the *Flow types which use vf:work and possibly vf:use. I'd prefer to try with that since vf:produce and vf:consume has this peculiarity that sometimes they can have vf:issue and vf:receive in between and sometimes not. Plus with those two we tend to rely on the resources a lot while with vf:work and vf:use we need to handle it with flows on all the different layers. |
It is just the other side of the same relationship, so eventA can be vf:inputOf processB, and processB can have vf:inputs eventA and eventB. I can't remember when I added those exactly, although we could find the PR. Do you not like it? I pulled the same pattern up to the recipe level. |
I like that. And maybe vf:estimatedDuration. Yes, the rest of it needs more exploration and use cases. I'll get that prepared and do a commit. |
Sure since we go with vf:RecipeProcess not vf:ProcessClassification
I would prefer to only include on the diagram the terms which actually exist in vf: namespace - what we have in the .ttl file. |
| rdfs:comment "A process category, model, taxonomy item, tag, facet value, or other kind of classification." . | ||
| rdfs:comment "A process category, taxonomy item, tag, facet value, or other kind of classification." . | ||
|
|
||
| vf:RecipeProcessClassification a owl:Class ; |
There was a problem hiding this comment.
I understood we agreed on just vf:RecipeProcess or vf:ProcessRecipe the second sounds better and follow the same suffix approach as vf:RecipeClassification
There was a problem hiding this comment.
@bhaugen didn't like RecipeProcess, thought it needed the Classification for clarity.
Re. RecipeProcess vs ProcessRecipe - It is a process that is part of a recipe, the recipe includes the equivalent of processes, events, resources. So it definitely isn't a ProcessRecipe, there is no kind of recipe included in the model explicitly, therefore no ProcessRecipe.
I'm open to either RecipeProcess or RecipeProcessClassification. Or something that is new and better.
There was a problem hiding this comment.
Let's go for now with RecipeProcess, still for me just like we have classification of/for a process we have recipe of/for a process, we don't have a process in neither case.
There was a problem hiding this comment.
So it definitely isn't a ProcessRecipe, there is no kind of recipe included in the model explicitly, therefore no ProcessRecipe.
So far I still like ProcessTemplate the most since we have a template for a process and crate processes based on that template.
There was a problem hiding this comment.
I understood you wanted the template objects to have info that would preclude them from being used as a generic recipe for everyone. So that seems like it could be useful, but doesn't seem like a recipe. Let's keep thinking.....
There was a problem hiding this comment.
Not to get stuck on naming, I think we can start with vf:RecipeProcess and then rename it once we find something we like more. One last try vf:ProcessBlueprint
|
OK, I committed the results of the conversations as I understand them. @elf-pavlik @bhaugen please take a close look and see what you think. Some things I'm not sure we have consensus.
It's been in the ttl file too. Let me know what you think. As a separate thing though, I do see that I left vf:isFinished in the diagram in Commitment, but removed from the ttl file, wasn't sure if you ended up agreeing with that or not @elf-pavlik , from previous PR. I'd like to put it back into Commitment, if that's OK with you, see #255 (comment), and also the following comment. |
https://github.com/valueflows/valueflows/blame/master/release-doc-in-process/all_vf.TTL#L174-L185 commit names don't suggest adding reverse properties, I don't know how did this go through the PR, i can make a PR after this one to remove them |
It is kind of a relational vs object thing, and both were useful in the api I'm doing for FairCoop, so I thought it useful to standardize both names. But if that is a standard, then OK with me. I'll remove the "outputs" and "inputs" ones; will simplify things in any case. |
done also, removed commitment.isFinished from the diagram |
|
My goal with RecipeProcessClassification above was that we have three layers, and Process and Resource are concrete, and Classification is on the same layer as Recipe. Those layers and their relationships are difficult enough for us to keep straight; imaging normal people. So I am trying to keep the layers straight. Any names that accomplish that goal are ok with me. Any names that confuse the layers are not. |
I remember that we also agreed in previous conversations that at the same time we may need distinct Recipes and Classifications. I would like to not prematurely conflate those two unless we figure out how such conflated approach would work. We could call Observation and Plan a Concrete Layers while Recipe and Classification an Abstract Layers. Maybe for now we can go with proposed by @fosterlynn vf:RecipeFlow & vf:RecipeProcess and later work with a diagram to further harmonize terminology? Currently I would think in direction of Once again, let's don't consider this approach to Classifications and Recipies as rock solid. We might find a way to merge at least some classifications and recipes into one, as well as we should remember that any instance can define itself as both a ProcessRecipe and ProcessClassification so by defining those two we don't block a way for someone who wants to create such instances to do so. At the same time providing a clear way when one wants to reuse existing instance of ProcessClassification which in practice might even only define itself as skos:Concept or some other non VF class, and at the same time create another instance for ProcessRecipe. |
|
Closing this very old recipes PR, to make a new one. |
Not ready to merge!!
I'm starting to work more on recipes. I don't yet have a recommendation for how to fit "exchange" into recipes, but it seemed like since the process recipes model is reasonably well proved in practice, I could start there to work out some of the naming.
So please let me know what you think about the names! And anything else, of course.... :)