Ingredient, Tool, Skill

[elf-pavlik]

I would see distinction between various types of resources/assets which one can use as input for a process.

• Ingredient - gets consumed during a process
• Tool - gets used during a process but only wears off by some %
• Skill - a human capacity which gets used during a process, on contrary to tool it grows / improves when put in use 😄

If we define them as sub types of Resource (Asset) expected by Process input/output. We can than easily use any of sub types which can have more specific attributes, for example how much it will wear off or grow when used in process. Actually increasing skill one can see as side effect or even intentional output of a process

@Lars2i what do you think?

See also: valueflows/agent#8 (skills)

[bhaugen]

@elf-pavlik @Lars2i
While some behavior differences of resources in relation to processes can be defined by resource subtype, consider that the same resources will have different behaviors as outputs.

So while an ingredient may be consumed as an input, it may also be created as an output. A tool may be used as an input, and created as an output. A skill, as you mentioned, has completely different behaviors.

Then you have resources that may be both inputs an outputs of the same process, some kind of transformation. For example, a tool could be an input and output of a process to maintain the tool in some way (repair, sharpen, replace parts, etc.) A Guerrilla Translation starts in a Translation process, then goes through an Editing process, and finally a Publication process.

We have specified those behaviors by Event Types (in other words, factoring out the behavior itself): for inputs, Consumption, Use, Citation, Work, and "To be Changed" (for transformations, which is awkward, and we'd like a better name), and then Creation or Production and Change for outputs. That way we can have a Tool that can be both used, created and repaired.

[elf-pavlik]

@bhaugen when we define various types, most of the time we don't define them as owl:disjointWith. Also each instance can have asigned any number of types (no need to choose just one) as well as have different types in different context. I hope you don't look at rdf:type in the same way as most object oriented languages use classes and inheritance.

[bhaugen]

@elf-pavlik re "I hope you don't look at rdf:type in the same way as most object oriented languages use classes and inheritance."

I count on you and Lynn to teach me how to think about it. In the meantime, we will need to be able to handle use cases like:
A tool is created by a process.
A tool is used in a process to create something else (might be another tool).
A tool is repaired or sharpened in a process.

And then we will want to be able to find out:
What inputs are consumed in this process?
What inputs are used in this process?
What inputs are cited by this process?

And provide code for the various input and output behaviors, which presumably can be created once and only once for each behavior.

When I tell how we did something, I don't mean that to determine what I think the common vocab should be. It's just meant as an input, not an output. It does work in the real world, so that's worth something. But it was not developed with rdf:type in mind. Much more influenced by object oriented languages with a generous dose of type objects.

[bhaugen]

P.S. we should also differentiate ingredients, which lose their identity in the output of the process, from components, which do not lose their identity and can be removed and replaced.

[elf-pavlik]

valueflows/resource currently includes

• vf:MaterialResource
• vf:UsageResource
• vf:WorkResource

which relates to

• ingredient
• tool
• skill

A tool may be used as an input, and created as an output.

Since we distinguish vf:UsageResource we use that usage as input resource, not the used tool itself.

[fosterlynn]

valueflows/resource currently includes

• vf:MaterialResource
• vf:UsageResource
• vf:WorkResource

which relates to

• ingredient
• tool
• skill

• ingredient, product, component - and actually, this may also need to refer to electronic resources such as documents and designs, come to think of it (maybe a different name or an additional type...)
• tool, equipment, space
• skill or type of work

Since we distinguish vf:UsageResource we use that usage as input resource, not the used tool itself.

Yes, so this should be:

• Use of a tool, equipment, space (and maybe others that don't come to mind)

Tool, equipment, space are vf:MaterialResource.

[gcassel]

I perceive ingredient, tool and skill as excellent types of input in specific processes. I guess that the terms here became relatively stable? (If there's any related active discussion, I'd appreciate directions.)

FYI I've added relatively consistent descriptions in Modular Organization Terminology: ingredient, tool and skill. However, the terms and links there are still highly "radioactive", and thus not yet truly in a state of request for comments. (But feedback is always welcome.)

[fosterlynn]

@gcassel currently the subclasses of EconomicResource have not been actually added, and I'm not sure we need them, it remains to be seen. So in any case, there aren't stable defined terms for this concept at the moment. :)

[gcassel]

As usual I'm not well-oriented to the precise intended scope of VF, @fosterlynn , but I think that specifying inputs as ingredients, tools or skills certainly could be deeply useful to VF.

However, that depends on many variables. I.e. there could be diverse ways to report the costs and benefits of activities to agents.

[fosterlynn]

@gcassel I think you are in scope. One thing we discovered is that the Action on the EconomicEvent implies some of the same meanings: work, use, consume - so it hasn't yet been useful in our examples to subclass EconomicResource itself. And a subtlety: you might find examples where an ingredient and a tool are the same resource, just used differently in different processes, indicating that ingredient and tool are more role-like than type-like descriptions.