Discussion of consume/create/transport snippets

[fosterlynn]

An issue to discuss @elf-pavlik snippets of yaml, the next step in working on 0.0. Snippets are here: https://github.com/valueflows/valueflows/tree/master/snippets. They are the material core of the process model: transformation with consume and create; transportation with load and unload. Bikes representing serialized resources; 3d printer parts representing stock non-serialized resources.

[fosterlynn]

@elf-pavlik looks good, thanks 👍

Some minor things I am wondering about:

• What are the implications of which direction the relationships point? Like before we had a process with vf:io container of events; in this example you have the events pointing back to their process with vf:executedIn. Not sure how to think about this in LOD? (I think of the container as more OO structure and the pointer back to the process as more relational db structure.)
• I'm bothered a little with the resource having its most recent event, since people will have to have logic to trace all the events backwards in the IPO chains. So most recent event is no more helpful than any other event. But I'm sure you have a reason?
• For my own education, I'd like to understand the @id and the uuid. (I think there was some discussion of that earlier, I can look for it.)
• Part of the last question, I'm wondering about the @id in general for resources, given people will have various combinations of data that will create the logical indentifier. What you have seems to make sense for someone making and transporting the bikes within their context. (The resource has the same @id before and after being transported.) Would that change if the bkitchen wanted to identify their bikes with serial number plus location? Would that change if the bikes were transported to someone outside of bkitchen?

[fosterlynn]

@elf-pavlik do you want to discuss naming as part of this exercise or leave that for later? Either way works for me.

[fosterlynn]

I also agree with @bhaugen that we would like to have vf:affectedQuantity on all events for ease of querying and processing. But I also understand we can't require anything, and I suppose if people in the same value chain agree that no affectedQuantity property means 1 EA, then they can adjust their code to that.

But still, in terms of examples for people, I'd like to include it on all events, based on our experience in the code.

Perhaps the querying use cases will shed some light....

[fosterlynn]

What are the implications of which direction the relationships point?

A small survey:

org:Organization to org:Post - the Post points to the Organization (more relational)
gr:BusinessEntity to gr:Offering - the BusinessEntity points to its Offerings (container) (more OO)
foaf:Agent to foaf:Thing - points both directions (foaf:maker and foaf:made)

Hmmmm.

[elf-pavlik]

What are the implications of which direction the relationships point?

It doesn't make any significant difference. I just wanted to put more emphasis on events and less on process so I hinted vf:executedIn instead of vf:io. In JSON-LD we can always use @reverese or define alias in @context to use same property in either direction.

I'm bothered a little with the resource having its most recent event, since people will have to have logic to trace all the events backwards in the IPO chains. So most recent event is no more helpful than any other event. But I'm sure you have a reason?

I introduced it as experiment with versioning based on resource state after particular (most recent) event. As you see resource at different moments have different state but same @id. We don't have previous/next relations between events that affect the same resource and if event only have day precision in vf:startTime we can't easily tell their order. For now I see it as simple way to keep track on at which point in sequence of events the snippet captures state of the resource.

For my own education, I'd like to understand the @id and the uuid. (I think there was some discussion of that earlier, I can look for it.)

We discussed that while resources move between inventories, they @id may change from one namespace to another. To reconcile identity of the resource across multiple namespaces we can require each resource to have vf:uuid which in practice works just as vf:serialIdentifier but stays unique across resources of different models and also resources not managed as serialized could have it. I also suggested defining vf:uuid as https://www.w3.org/wiki/InverseFunctionalProperty

Part of the last question, I'm wondering about the @id in general for resources, given people will have various combinations of data that will create the logical indentifier. What you have seems to make sense for someone making and transporting the bikes within their context. (The resource has the same @id before and after being transported.) Would that change if the bkitchen wanted to identify their bikes with serial number plus location? Would that change if the bikes were transported to someone outside of bkitchen?

I think we need to give little more thought to https://github.com/valueflows/resource/issues/13 For resources managed as serialized we can rely on vf:model + vf:serialIdentifier (but we can't define it as owl:InverseFunctionalProperty since it may repeat for resources with different models). Today I want to write an example of transporting 3d printed parts which will require splitting some number of them into a package for shipping. Assemble + disassemble a package may address your comment from gitter.

@elf-pavlik
for load and unload events quantity doesn’t seem needed since we always act on the whole resource
@fosterlynn
don't you think it is optional to split the quantity first? people might want to do it both ways I would think (since you want to split the quantity first and I think it is too much bother ) - but it also might depend on if it is crossing into a different context

Carrier often will have responsible relationship to transported resource. We need a way to identify the resource which gets transported. If we make split optional we don't seem to have a resource which we can reference as in possession of the carrier or located in the vehicle.

[fosterlynn]

I just wanted to put more emphasis on events and less on process so I hinted vf:executedIn instead of vf:io

Understand, thanks - and seems fine to me.

We discussed that while resources move between inventories, they @id may change from one namespace to another.

Good, I think we are on the same page there.

To reconcile identity of the resource across multiple namespaces we can require each resource to have vf:uuid which in practice works just as vf:serialIdentifier but stays unique across resources of different models and also resources not managed as serialized could have it. I also suggested defining vf:uuid as https://www.w3.org/wiki/InverseFunctionalProperty

Thanks, back up to speed on it again. But why would we have to require such a thing to reconcile across namespaces? I think we can trace IPO chains to get that, although sometimes there is some mushiness it is true. But often times resources will get split up (less quantities than the whole will be consumed), then it would need a new uuid. And sometimes people won't care. If they do, it will be serialized or have a lot identifier. In other words, it may not matter to record which exact portion of some commodity type resource people get.

For event date, people might want a datetime for some kinds of processes to help with linking.

Or if agents who are coordinating find it useful to have a uuid, then certainly they can use that.

@bhaugen pinging you on this topic when you have time (no rush) - let's look at your logic for incoming value flows some time so I can be really concrete about how this can work.

Carrier often will have responsible relationship to transported resource. We need a way to identify the resource which gets transported.

Probably most often this is true. But I think not always. If it is transported quickly and internally, people may only care about the beginning and the end.

I suspect that if there is a separate carrier, there is a vf:contains that gets created somewhere, maybe in a process before the pickup (a specific case of your split) where something is packaged and gets a tracking number. So the identifier of the package is the tracking number (and carrier probably), and some data knows what the package contains, but the carrier may or may not care about that. (I'm thinking of US Postal Service or FedEx or UPS, I don't have experience with group level transportation, just personal.)

Today I want to write an example of transporting 3d printed parts

👍

[bhaugen]

@bhaugen pinging you on this topic when you have time (no rush) - let's look at your logic for incoming value flows some time so I can be really concrete about how this can work.

What aspect of, or angle on, incoming value flows would help? Or, what level of detail? (Or, please give me more direction on how to respond?)

[fosterlynn]

What aspect of, or angle on, incoming value flows would help? Or, what level of detail? (Or, please give me more direction on how to respond?)

From lunch discussion, in the simple use cases we are looking at now, where there is always an actual resource created (with an @id), you just use that - output from one process, input to another. Will be more interesting when nothing is inventoried.

At some point, I'll do some code reading in NRP. (I know that part of the code is pretty complex.)

[bhaugen]

Will be more interesting when nothing is inventoried.

Note: I have not made this work in NRP in all cases, either. I think it's doable, just have not needed to do it.

[fosterlynn]

Alternate using @elf-pavlik example as starting point, but without vf:uuid, which I don't see the need for. And no need for the split either in this case. Using an additional transformation process because transportation is not as clear.

This is the starting state for this experiment, "parts after increment". Note 2 batches of the part have been made and put into this one stock resource at this point in the sequence.

'@context':
  - https://w3id.org/valueflows/v1
  - fablab: https://fablab.example/

'@id': fablab:1d14a369-317b-4404-abbd-25fb9d18a408#resource
'@type': vf:Resource
'vf:model': fablab:Cool-Item-44
'vf:currentLocation': fablab:64a0625c-caad-4f2e-a8de-157796c7d203#place
'vf:mostRecentEvent': fablab:e88bae12-615a-4f81-84d5-c5aeffd81242#event
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 8

Next, 3 of this part is consumed in another process:

'@context':
  - https://w3id.org/valueflows/v1
  - fablab: https://fablab.example/

'@graph':
  - '@id': fablab:e09r9eai-4d6d-4716-93eb-40b793c29144#process
    '@type': vf:Transformation
    'skos:note': assembling a combined 3d printed part

  - '@id': fablab:5c586fdf-c3b8-4779-8140-1a23e581e623#event
    '@type': vf:IPOEvent
    'vf:action': vf:consume
    'vf:startTime': 2016-08-14
    'vf:executedIn': fablab:e09r9eai-4d6d-4716-93eb-40b793c29144#process
    'vf:affects': fablab:1d14a369-317b-4404-abbd-25fb9d18a408#resource
    'vf:affectedQuantity':
        '@type': qudt:QuantityValue
        'qudt:unit': unit:Each
        'qudt:numericValue': 3

  - '@id': fablab:ewr908ew90r-615a-4f81-84d5-c5aeffd81245#event
    '@type': vf:IPOEvent
    'vf:action': vf:create
    'vf:startTime': 2016-08-14
    'vf:executedIn': fablab:e09r9eai-4d6d-4716-93eb-40b793c29144#process
    'vf:affects': fablab:df098d9-317b-4404-abbd-25fb9d18a409#resource
    'vf:affectedQuantity':
        '@type': qudt:QuantityValue
        'qudt:unit': unit:Each
        'qudt:numericValue': 1

Resource state at end:

'@context':
  - https://w3id.org/valueflows/v1
  - fablab: https://fablab.example/

'@id': fablab:1d14a369-317b-4404-abbd-25fb9d18a408#resource
'@type': vf:Resource
'vf:model': fablab:Cool-Item-44
'vf:currentLocation': fablab:64a0625c-caad-4f2e-a8de-157796c7d203#place
'vf:mostRecentEvent': fablab:e88bae12-615a-4f81-84d5-c5aeffd81242#event
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 5

'@context':
  - https://w3id.org/valueflows/v1
  - fablab: https://fablab.example/

'@id': fablab:df098d9-317b-4404-abbd-25fb9d18a409#resource
'@type': vf:Resource
'vf:model': fablab:Cool-Item-66
'vf:currentLocation': fablab:64a0625c-caad-4f2e-a8de-157796c7d203#place
'vf:mostRecentEvent': fablab:ewr908ew90r-615a-4f81-84d5-c5aeffd81245#event
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:unit': unit:Each
  'qudt:numericValue': 1

[elf-pavlik]

I've made an example where same resource appears in multiple inventory management systems

'@context':
  - https://w3id.org/valueflows/v1
  - bkitchen: https://bike-kitchen.example/
    coride: https://coride.example/
    colive: https://colive.example/
    osm: https://osm.example/

'@graph':
  - '@id': bkitchen:2ffb24c7-176b-4ae0-bd86-595f731c2800#resource
    '@type': vf:Resource
    'vf:uuid': 2ffb24c7-176b-4ae0-bd86-595f731c2800
    'vf:serialIdentifier': 2ffb24c7-176b-4ae0-bd86-595f731c2800
    'vf:model': bkitchen:cargobee#model
    'vf:currentLocation': osm:3965057751
    'vf:quantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 1

  - '@id': coride:2ffb24c7-176b-4ae0-bd86-595f731c2800#resource
    '@type': vf:Resource
    'vf:uuid': 2ffb24c7-176b-4ae0-bd86-595f731c2800
    'vf:serialIdentifier': 2ffb24c7-176b-4ae0-bd86-595f731c2800
    'vf:model': bkitchen:cargobee#model
    'vf:currentLocation': osm:3965057751
    'vf:quantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 1

  - '@id': colive:2ffb24c7-176b-4ae0-bd86-595f731c2800#resource
    '@type': vf:Resource
    'vf:uuid': 2ffb24c7-176b-4ae0-bd86-595f731c2800
    'vf:serialIdentifier': 2ffb24c7-176b-4ae0-bd86-595f731c2800
    'vf:model': bkitchen:cargobee#model
    'vf:currentLocation': osm:3965057751
    'vf:quantity':
      '@type': qudt:QuantityValue
      'qudt:unit': unit:Each
      'qudt:numericValue': 1

In this case vf:uuid allows reconciling identity of the same resource which has different @id in same namespace. At the same time I think it could better if resource would have just a single @idvalid at given time (canonical URI) which would depend on some kind of host relationship between agent which controls the namespace used by the inventory management system and the resource. Since I don't wont to go there for now I will remove all vf:uuid from examples and defer till later attempts to resolve in what cases the @id could change and how we would want to manage it.

[fosterlynn]

At the same time I think it could better if resource would have just a single @id valid at given time

Me too. I think agents trying to jointly use a resource would be well advised to do that. I can't really think of any use case where people would find it easier to have their own identifiers for the same material resource at the same time.

Since I don't wont to go there for now I will remove all vf:uuid from examples and defer till later attempts to resolve in what cases the @id could change and how we would want to manage it.

Yes, it is probably all tangled up with agents, especially context agents.

[elf-pavlik]

I just added more snippets to https://github.com/valueflows/valueflows/tree/master/snippets/produce-box which have assemble and disassemble events. Based on all the snippets I created so far I would like to document how events representing different actions 'mutate properties' of affected resources (we can see them as 'computed properties'). Quick draft

actions affecting quantity

• vf:produce - increment vf:quantity of affected resource by value of vf:affectedQuantity in event
• vf:consume - increment vf:quantity of affected resource by value of vf:affectedQuantity in event

actions affecting location

• vf:load - unset vf:currentLocation of affected resource
• vf:unload - set vf:currentLocation of affected resource to value of vf:atLocation in event

actions affecting grouping and have consequence on location

• vf:assemble - create vf:contains relationship between resource referenced from event with vf:container property and the affected resource & unset vf:currentLocation of affected resource
• vf:disassemble - remove vf:contains relationship between resource referenced from event with vf:container property and the affected resource & set vf:currentLocation of affected resource to value of vf:currentLocation of resource which had vf:contains relationship with it.

As I understand NRP doesn't track location of the resources based on events and from above examples of actions only tracks quantities with create & consume.

[fosterlynn]

As I understand NRP doesn't track location of the resources based on events and from above examples of actions only tracks quantities with create & consume.

Correct. Breaking new ground..... :)

(Of the above event types, NRP only has create and consume.)

Based on all the snippets I created so far I would like to document how events representing different actions 'mutate properties' of affected resources

Good exercise, will be good documentation in the end!

[fosterlynn]

We had some discussion in gitter around a possible economic event called "issue". This relates to disagreement over whether vf:load and vf:unload affect the quantity of the referenced resource, at least in the case of serialized resources transported internal to a context. And to the requirement or not of a process used to "split" part of a stock-type resource in preparation for transportation. And to if we want to have very fine grained types of events, or want to "combine" some of these.

I think this might be relevant. This is from @bhaugen on his experience with varied inventory issue practices.

Aka random thoughts about issues and consumes and their relatives.

When I was a flexo press operator, we had formal inventory issues.

Material handlers would look at the production schedule, figure out
which rolls of paper were required, and take them out of a locked
storeroom and bring them to the machine where they were to be used.

Each roll of paper had a two-part perforated tag on it. The material
handler tore off the first part and put it in a box when taking the
roll out of the storeroom. The flexo press operator tore off the
second part and put it in another box before mounting the roll on the
press.

Waste paper went into wheelie bins and was weighed and baled by the
material handlers.

In the bakery, flour and other materials went into bins and was taken
out as needed. Inventory control was by sight: is a bin getting empty,
do we need more? Somebody ordered more. I don't remember any control
transactions between order and use.

Those were possibly two extremes in a range between strict and loose
inventory control.

Manufacturing in my working time evolved from formal and strict to
looser and looser.

Inventory control devolved from specialized material handlers to line workers.

Kanbans were cards, but they evolved into totes. Each tote had a label
with a part number and a quantity. When a consuming workstation
emptied a tote they send it back to the producing station which filled
it up again and sent it back. There were no records other than the
production schedule and what was produced. What was used was deduced
from what was produced and the bill of materials.

Automated manufacturing systems go back in the strict direction. They
need to tell the robots exactly what to do.

[elf-pavlik]

This relates to disagreement over whether vf:load and vf:unload affect the quantity of the referenced resource, at least in the case of serialized resources transported internal to a context. And to the requirement or not of a process used to "split" part of a stock-type resource in preparation for transportation.

I understand "internal to a context" as @id of a resource doesn't change to another one in different namespace. Currently we don't involve any agents and even less some kind of context relationship between resources and agents.

Also based on discussion with @bhaugen on gitter I understood that in case of assemble event the quantity of a bike frame itself (one with serialIdentifier) would NOT decrement to 0 but only quantity of 'inventory of frames' would decrement by 1 if that frame would stay managed as part of such inventory (possibly similar to my PR for stock - valueflows/resource#41 )

@fosterlynn could you propose alternative YAML to those two snippets describing transportation

• bike with serial number & bikes after transport
• 3d printed parts - 6pcs with no serial number & parts after transport

On Monday I will add assemble and disassemble events for bike frames to the two transformations in bike snippets. IMO only manufacturing of new bike frame should create it and only final recycling of old bike frame should consume it. Between that initial 'birth' and final 'death events it can have many load & unload, assemble & disassemble, issue & receipt, accept & improve etc. events but I don't see why its quantity should ever change from "1 each".

[fosterlynn]

@fosterlynn could you propose alternative YAML to those two snippets describing transportation

Sure I'll give it a shot. Good to have concreteness. :)

I understand "internal to a context" as @id of a resource doesn't change to another one in different namespace. Currently we don't involve any agents and even less some kind of context relationship between resources and agents.

I haven't give the namespace thing enough thought to discuss it really, I'm not sure how it relates to context agents, and I'm not trying to make you talk about agents when you don't want to. I was just trying to sharpen the definition of vf:Resource, to try to understand where we agree and where we don't - I though we had resolved that a while ago, but looks like we have not.

I don't have any problem using data other than the @id to trace things through value flows as needed. There are a lot of complexities to the way resources exist and change. The bike seems pretty simple and obvious, but if we start with a lot for example, there could by anyone's thinking be many vf:Resources with different @id floating around with the same lot number as it gets split up.

[elf-pavlik]

The bike seems pretty simple and obvious, but if we start with a lot for example, there could by anyone's thinking be many vf:Resources with different @id floating around with the same lot number as it gets split up.

In snippet for assembly produce box process I split 5 different lot controlled resources and each part which gets separated gets its own @id while keeping same lotIdentifier. Same lotNumber doesn't mean the same resource, while same serialIdentifier does (at least for same resource model). After splitting a resource with lotIdentifier we still have the orignial resource (which gets decremented) and new resource representing the extracted part. So we have two different resources with two different @id and not two different @id for the same resource.

Actually I would consider defining distinct sub type of a process for such split/merge operations. The neither transform or transport involved resources but simply reorganize them.

[fosterlynn]

Also based on discussion with @bhaugen on gitter I understood that in case of assemble event the quantity of a bike frame itself (one with serialIdentifier) would NOT decrement to 0 but only quantity of 'inventory of frames' would decrement by 1 if that frame would stay managed as part of such inventory

I'm not sure how Bob thinks about it, but I don't see how the frame can continue to be managed as part of any inventory (not sure what "such inventory" is).

To me, if you assemble a serialized bike frame into a bike, the bike frame is not a vf:Resource any more - or a resource in any way of looking at it. The bike is now a resource and a vf:Resource. The bike frame has disappeared from any way of looking at inventory - and nobody wants to manage it. You can always trace back and find out that the specific frame is on the specific bike, which you might want to know. And if the bike is disassembled, then the frame can come back into some inventory; and the bike will disappear from any inventory.

[fosterlynn]

Actually I would consider defining distinct sub type of a process for such split/merge operations. The neither transform or transport involved resources but simply reorganize them.

However the split/merge / out/in / issue/receipt thing comes out, I would agree that we probably should define another subclass for it.

[bhaugen]

I'm not sure how Bob thinks about it, but I don't see how the frame can continue to be managed as part of any inventory (not sure what "such inventory" is).

I totally agree that a bike frame that has been assembled into a bike is no longer a resource, the bike is.

[elf-pavlik]

@bhaugen what if one has warranty for that particular frame and possibly also responsibility to recycle it at some point in the future?

[bhaugen]

what if one has warranty for that particular frame and possibly also responsibility to recycle it at some point in the future?

Recycling doesn't matter as long as it is part of the bike. Might matter if you need to recycle the frame, when I assume it is no longer part of the bike. If it is, then you are recycling the bike.

Re the warranty, I'd have to see it.

In general, edge cases are good for debugging but do not always shed light or lead to good designs.

(Some typo editing went on here...)

[elf-pavlik]

After gitter chat with @fosterlynn TODO for me - write snippets for 2 bike tires assembled into a bike and managed as non-serial resource. They got swapped between front and back wheel couple of times and than one of them gets replaced. In the end all the bike gets disassembled and we keep track of all the assembled and disassembled resources throughout all those processes.

[elf-pavlik]

Second TODO: add affordances to resources (which actions next event can carry) and document how different actions change affordances in current state of the resource.

[fosterlynn]

Some other thoughts after last gitter chat, possibly somewhat random.

Resource identification, when is a new resource created

I think the @id field was confusing me in the discussion, because I was thinking of that as the "unique identifier" of a vf:Resource. It is however just a computer artifact, kind of like sequence numbers in relational tables, a way to keep things unique from a computer's perspective. It is specific to LOD too. Does this seem correct?

There are lots of potential parts of the logical identifier of a vf:Resource, and it depends on how the resource is managed. In some cases, people can identify the exact resource they touched earlier (serialized), in some cases not (maybe just the model and a source). In VF, I think we need to support people's understanding of what identifies a particular resource to them, in all its shades. So I'm thinking it is best to ignore the @id for now - not in the snippets, but in how we think of what is a vf:Resource. Especially until we integrate vf:Agent into the picture.

When a vf:Resource is created as a record in someone's system or namespace I would like to make that less important in the way I think of it at this stage, and work with the logical properties of a vf:Resource.

Subclasses of vf:Process and event types for each

I think it is a good idea (as we discussed briefly) to create a new subclass to cover all the smaller non-transformative, non-transporting processes. I started to make a list of the kinds of things that might fall into this that have been discussed. Like: issue/receive, package/unpackage, split/merge, give/receive (in the process sense, also called out/in). These all have different flavors and apply in different situations, but all are "other" kinds of events. Except maybe package, which does create a new resource of the package. Or it could be just adding a tracking id to a resource.

Thinking of names - something like Management? Like managing resources.

Transformation - I wonder if we want to change vf:create to vf:produce, to avoid confusion with creating records, and updating vs creating new resources?

Transportation - I'd like to add vf:trackingIdentifier as a property of the resource being transported. And in thinking about the difference between transporting serialized resources all within a context, as in @elf-pavlik yaml recently, it does make sense to me that people could want to keep that as the same vf:Resource throughout the transportation process, and in the end, all that changes is the vf:currentLocation. Or, in the case of stock type resources, it will be a new vf:Resource or add to an existing vf:Resource when it emerges from transportation.

That lead me to think about how in Transformation we have vf:consume/vf:create, and we have vf:accept/vf:improve - one decrements/increments, one doesn't. Why don't we just have 2 sets of vf:actions that work with Transportation? One will decrement / increment, and one will not. Don't know what the names should be. That will handle serialized vs stock resources; and who knows what other use cases.

And maybe the Management (or whatever the simple process type is called) will also need a set of event types that decrement /increment and one that doesn't, if the pattern holds true.

And maybe we want a simplified change of location event type which doesn't need all the process trappings, but just changes the vf:currentLocation on a resource. vf:move? As a corollary, we have something that could be called vf:adjust that only changes the quantity, meant to be used to correct inventory that is wrong or for beginning balances when starting the system.

[fosterlynn]

TODO for me - write snippets for 2 bike tires assembled into a bike and managed as non-serial resource. They got swapped between front and back wheel couple of times and than one of them gets replaced. In the end all the bike gets disassembled and we keep track of all the assembled and disassembled resources throughout all those processes.

👍

It might also be interesting to consume a resource too in the same process, like paint or grease, or anything that can't be disassembled. We'd have everything all together.... :)

[elf-pavlik]

And maybe we want a simplified change of location event type which doesn't need all the process trappings, but just changes the vf:currentLocation on a resource. vf:move?

I think one could simply use event carrying vf:unload action and not relate it to any process (so no vf:executedIn. Based on specification of effect on resource I proposed few comments above:

vf:unload - set vf:currentLocation of affected resource to value of vf:atLocation in event

It should serve the purpose of simply changing vf:currentLocation of the resource. It also fits well the Open-world assumption, we never can assume that we have all the relevant data about something (for example all events that affected particular resource). We always need to work with the data we have and anticipate that we can later discover more relevant data. This differ from Closed-world assumption used for example in relational databases, where one assumes having available all the possible data.

[elf-pavlik]

I think the @id field was confusing me in the discussion, because I was thinking of that as the "unique identifier" of a vf:Resource. It is however just a computer artifact, kind of like sequence numbers in relational tables, a way to keep things unique from a computer's perspective. It is specific to LOD too. Does this seem correct?

We can see @id as identifier that gets used as primary and foreign key (in relational databases terminology). The LOD specific part comes with use of IRIs for those identifiers, which makes them globally unique (data from different relational databases would often have collisions) and using http: scheme IRIs makes those identifiers also globally dereferenceable.

There are lots of potential parts of the logical identifier of a vf:Resource, and it depends on how the resource is managed. In some cases, people can identify the exact resource they touched earlier (serialized), in some cases not (maybe just the model and a source). In VF, I think we need to support people's understanding of what identifies a particular resource to them, in all its shades. So I'm thinking it is best to ignore the @id for now - not in the snippets, but in how we think of what is a vf:Resource. Especially until we integrate vf:Agent into the picture.

While the data model needs to allow building applications which people use. I don't think we will try to define relationships between entities based on some set of attributes&values. Even in relational databases one might define ownerships table which would use resource_id and owner_id as foreign keys. In similar way LOD would have statement ex:shoe-1234 vf:owner ex:jane .. When we get to the requirement of resource changing identifier to one in another namespace, we have constructs like owl:InverseFunctionalProperty to help us reconcile identity of the resource across namespaces. So we need two ways of working with identity of resources

1. How people identify resources - possibly combination of attributes (low capacity to define relationships and keep track on significant number of resources and their relationships)
2. How computer systems identify resources - IRIs (at least in LOD) - relationships will rely on those IRIs (high capacity to define relationships and keep track on significant number of resources and their relationships)

[fosterlynn]

How computer systems identify resources - IRIs (at least in LOD) - relationships will rely on those IRIs (high capacity to define relationships and keep track on significant number of resources and their relationships)

As @id's cross namespaces, or for resources managed as stock, we will need to rely on the logic of traveling the IPO chains to track resources and their relationships, and to know what is the "same" or "part of" or whatever another resource. It will be like #1 in many cases.

But that is fine I think, and I am happy to have clarified @id.

[fosterlynn]

^ There is a bit in this: https://github.com/valueflows/valueflows/tree/master/release-doc-in-process, find "Verbs associated with vf:action". But not complete or explicit enough.

Where should we start this? It might get lost in an issue.....

[fosterlynn]

Agreement from gitter chat: vf:consume decrements a resource, vf:produce increments a resource.

[elf-pavlik]

we should also add a note that for resources managed as serialized vf:produce and vf:consume can only have quantity '1 each'

[elf-pavlik]

elf Pavlik @elf-pavlik 17:20
should we have a way that event with vf:produce action can set the vf:serialIdentifier or vf:lotIdentifier if resource doesn't already have one?

Lynn Foster @fosterlynn 17:21
like if it is a new resource?
that seems like the same as your comment on vf:tracking Identifier
the resource will have those
don't need on the event

elf Pavlik @elf-pavlik 17:24
ok, so let's for now assume that event's don't stay responsible for assigning any of those identifiers

Lynn Foster @fosterlynn 17:24
ok

[fosterlynn]

Some other tidbits from chat:

vf:loadedOn, instead of vf:target for the vehicle or whatever a resource is loaded into in vf:load event.

Possibly vf:Place is better than vf:Location (Place is used by schema.org). But I also want to wait and see how this fits in with other vocabs and how it interfaces with TransforMap.

[fosterlynn]

One other agreement from gitter discussion, triggered by the vocabulator: we will support vf:work events with an agent who performs the work, as input to a process. (Name of the property to be decided. Could be vf:performedBy, although to me that is kind of specific.)

[elf-pavlik]

related to #148

[gcassel]

@fosterlynn (and everyone), are we only talking about human work here, or does it refer to any work which an agent takes credit for?

i.e. an agent may take credit for delivering a pizza to the office, but most of the work (from a physical resources standpoint, anyway) is actually done by a vehicle. this fact is very important if the agent who performs the human work (which i usually define as a task) doesn't own the vehicle in question. (Of course, it's also important to know when vehicle's owners try to profit off of other people's driving.)

[fosterlynn]

@gcassel we are talking only of human work here. The usage of the vehicle that delivers pizza is another input, and the economic history of the vehicle and/or who owns it can be available. The output is a pizza delivery service. This way all the separate events or whatever they are called are recorded as simply what they are. People can figure out later what they want to do with that information.

[gcassel]

Let me try to redefine my concern-- and, this may be another subject which deserves a separate topic.

With most types of desired work, I think it's only consistently possible now to identify which work human agents take responsibility for. Whether or not all or most of that work is directly performed by a human being is inexpressably variable, and should IMO be dealt with 'locally' by a given network, community or group which needs work done or accounted for.

For instance, one agent might be able to perform a major delivery in one trip with a large truck, while another might need to make 3-4 trips with a smaller vehicle. Other agents, of course, may lack the ability to perform that delivery at all.

Digital examples: one part of a defined data processing job might be performed by a specific agent using a fancy tool or software program they use, while another specific agent would need to do it manually. Or, one agent may be able to automate a repetitive processing task as a batch process, while another agent would need to perform the process over and over again. It depends on the tools and techniques available to each agent.

It might seem like I'm splitting hairs here and I'm sorry if it does. But I think it's actually deeply important in the long term, as more and more processes are automated or semi-automated, to:

1. identify precisely which goals or processes each (individual or group) agent takes social responsibility for
2. explicitly account human labor and machine labor separately

FWIW, I'm personally fighting a battle to uphold the worth of genuinely human values and interactions in an increasingly automated world. However, this requires profound cultural transformation. For instance, I believe we'll need to stop pretending there's any special value to humans doing specific jobs which can be performed equally or better by a machine. -- and, at the same time, all consent-based human actions and services should be well accounted for, and appreciated.

[fosterlynn]

@gcassel I'm trying to see what you are worried about. Is there anything we have said in VF that tells you it will not be possible to record any amount of detail you want about what is human work, what is also the input by specific machines, etc? That is the whole point of this model. Then what is done to summarize and analyze that base accounting/counting is also people's choice.

Machines or fancy software tools were also created by human work, the value chain always goes back to human work eventually, because that is the only thing that truly creates value. Well I think other living things create value too.....

[elf-pavlik]

Machines or fancy software tools were also created by human work, the value chain always goes back to human work eventually, because that is the only thing that truly creates value. Well I think other living things create value too.....

👍 I would like that systems using VF vocab enable capacity to trace back through IPO chains all the efforts that put together resulted in creating particular resource, as well as all the natural resources that given chain of processes transformed.

[gcassel]

My concern here is that an accounting system should be able to directly identify the work which agents take responsibility for, within the context of each network, community or organization.

If work is highly predictable, it may or may not be automated. It's valuable either way. It's valuable if a human spends long days in backbreaking labor, such as ditch-digging, and it's also valuable if a machine does it instead.

The value of creativity and of design is different (and more deeply human, IMO) than the value of predictable/ repetitive labor.

Communities and organizations constantly must make hard decisions about who does and doesn't take responsibility for specific work, and whether or not those agents are compensated or remunerated for those responsibilities. Those decisions depend utterly upon how much actual human work and actual machine work are expected in each case. But, I don't think we can make those decisions properly unless the discussion starts from a sound foundation.

However, @fosterlynn , maybe there's no important difference here, and I just think that "vf:work" inevitably means something slightly different than the terms you're currently using to describe it.

[bhaugen]

My concern here is that an accounting system should be able to directly identify the work which agents take responsibility for, within the context of each network, community or organization.

What would be an example of taking responsibility for some work rather than doing the work? How would somebody explain that responsibility? What would they do to fulfill their responsibility?

If you want to have a sound foundation, you need to define your terms clearly and precisely, and justify a new term so that it is clear how it differs from terms that are already part of the vocab.

I just think that "vf:work" inevitably means something slightly different than the terms you're currently using to describe it.

How so? Please explain as precisely as you can.

[gcassel]

What would be an example of taking responsibility for some work rather than doing the work? How would somebody explain that responsibility? What would they do to fulfill their responsibility?

People constantly take responsibility for work before they do it, and they rarely specify precisely which tools and techniques they will use in the process.

When a person or group plans work, they don't necessarily decide that the work will be done by humans, machines, or any combination of human and machine work. (And frankly, people practically never account those distinctions in detail.) You simply identify the work that needs to get done. If there are any implicit or explicit restrictions on how the work gets done-- for instance, "this must be done by a human"-- those restrictions can be identified and verbalized.

For instance, I might ask for someone to dig a ditch in my yard. That's the work! It's a goal, an objective, which will transform my yard.

Maybe one person would offer to dig it manually with a shovel for $10/ hr over a period of days, and someone else would offer to dig it with a machine for a flat fee of $90. However, I may specify this restriction: "I don't want a backhoe in my yard, compacting my soil".

The desired work-- the goal, the objective-- is what we start with. That's the basis of design. Then we apply any restrictions, if they don't seem obvious.

I just think that "vf:work" inevitably means something slightly different than the terms you're currently using to describe it.
How so? Please explain as precisely as you can.

I think "work" should mean "desired work", "intended work", "assigned work", "completed work" and so on-- i.e., any work which people want or need to get done, and to account. So the term "work" is fine by me. But it's not necessarily human work, and it shouldn't really be identified as such except when it actually is.

[gcassel]

^ and by the way, these thoughts about planned work and assigned responsibility differ from my definition of "task" in Agreement-Based Organization. I believe I need to rebuild that definition.

[bhaugen]

People constantly take responsibility for work before they do it,

In REA (and vf as far as I know), that's a Commitment.

You simply identify the work that needs to get done.

That seems to be defining an output or result or goal, as you described.

In vf so far, we define work as the exertion of human effort to perform a desired effect [edit: by a particular human agent: that is, as human labor]. If you munge all these concepts together, you cannot usefully separate them again.

[gcassel]

When you identify work that humans want to get done, you can perform task analysis and label any parts of that work which require human effort. In many cases, that may be the entire job, because it's inherently creative, artistic and/or socially co-responsible. In many other cases, however, human effort is only part of the work-- and it's only done by humans because we haven't yet automated most of our highly predictable, uncreative goals.

Going back to an old example: human effort is only part of the goal of delivering a pizza to someone's house. Right now, we need a human to drive a car for 100% of that journey, and to transport the pizza to and from the vehicle. Eventually, however, that won't be the case. Driving will be automated, and the pizza may well be transported to and from the vehicle by robots. (And we can be quite sure that most customers won't pay extra for human labor, unless they're forced to.)

Frankly, I think @bhaugen the precise nature of VF's current focus on human work is impractical. However, I'd like to shelve this tangent for now, because we're probably both too busy to have a productive (probably live) discussion on it. Also it's practically irrelevant to the original topic; sorry to anyone trying to follow that.

[bhaugen]

Frankly, I think @bhaugen the precise nature of VF's current focus on human work is impractical.

And I don't think you have thought it through clearly. I'm trying to clarify because you continue to bring up problems that you don't think have already been handled and I wonder if you are doing your homework. Your equally imprecise Task idea also keeps coming up.

If we do not distinguish human labor from that performed by machines, those who want to track or reward human labor (which includes most of the prospective users of VF that I can think of) will not be able to do so. We can't say Work is this whole process with all its inputs and outputs and differentiate human work from anything else. We have Process for the constellation you seem to be calling Work, with Work as human labor as one of its possible inputs.

I am not sure if this is just a matter of what do we call what, or if you have not been paying strict attention to what Lynn and Pavlik have been doing about nailing down Processes and their inputs and outputs. I know it is difficult to keep up (and this whole effort of precisely defining economic relationships is difficult), but if you want to claim we are missing something, you do need to look into the details. We could rename Process to be Work, and Work to be Human Labor, but I don't see any reason to do that.

Anyway, I think that Process as we have defined it covers all of the actual (as in what we have come to call the observation layer) use cases you have mentioned. And planned processes, with however much definition as people need, will cover the planned use cases. If you can think of a use cases that is not covered, please add it to the existing use case directory.

[gcassel]

My whole point here was to distinguish human labor from machine labor. I tried to keep the discussion as simple and self-contained as possible, but that's obviously not working as intended.

I believe there's a deep issue here regarding the difference between plans and reports, and as far as I can tell, another term is needed to address that difference. However, this has been a very inefficient written discussion. I'll follow up elsewhere.

[bhaugen]

My whole point here was to distinguish human labor from machine labor. I tried to keep the discussion as simple and self-contained as possible, but that's obviously not working as intended.

That did not communicate at all. I read it first that you were concerned that we did not diffferentiate human labor from the use of machines, whereas we have carefully and I think consistently done that from the start of VF. And then I read it as you wanted Work to mean the same thing as vf:Process or something like that, where Work is the goal, not the human labor (which is what VF calls work). And now I understand you to have the same concern " to distinguish human labor from machine labor", and if I tell you we always do that, and I can point to a lot of examples, will you believe it? What do you need?

I believe there's a deep issue here regarding the difference between plans and reports

Before I start misunderstanding you again, what do you understand as what vf means by "plans"? (We have not used the term "report" that I know of, but maybe I have not been paying enough attention either.)

However, this has been a very inefficient written discussion.

It certainly has. But I am not happy leaving on the record in this hopelessly confused state where the next reader will think there are some horrible unresolved issues and I don't think so.

How would you make it more efficient?

[gcassel]

I believe we'd agree @bhaugen that some conversations aren't well-suited to openly and persistently documented exchange of asynchronous messages. This seems especially true if one or more parties isn't well-oriented to others' relevant info and concerns. However, I'll try to resolve these issues sufficiently here for your tastes. (Or we could move to#109 .)

I understand that I may be unaware of an existing vf term which either does or could (with tuning) address my concern about the difference between plans and reports. If that's the case, it's certainly 'my fault' because of insufficient orientation.

I referred here to "plans" in an intentionally generic way, but closely corresponding to McCarthy's "Recipe Plan Reality" model. Such plans include commitments and contracts. I referred here to "reports" in a way closely related to McCarthy's "Event" concept. However, "observation is probably more appropriate than "report", which has other potentially important uses.

It's probably true that I've been using "Work" in almost the same way that you've been using vf:Process. However, I've been assuming that an economic modeling and accounting system should be able to describe all observed and all potential processes, including processes which are unintentional and undesirable. Obviously, we wouldn't refer to such processes as "Work".

Perhaps you don't want unintentional and undesirable processes to be in the scope of vf accounting? Or perhaps you'd prefer to distinguish them with special terms, and to assume that vf:Process always means intended and desired by one or more agents? Regardless, I do think we need to be able to directly relate unintentional and undesirable processes to valued work.

I currently believe that my previous use of the term "Task" was practically identical to the way you're using "Work". (But I don't think that's ever been clear between us!) I still don't really know if a term like "Task" is necessary, but I think it's deeply necessary for networks to be able to assign responsibility for intended processes to specific agents. That's inevitably part of collaboration-planning.

In accounting agents' observations after-the-fact of actions, I believe it's often (not always) important to distinguish between actions which were performed by humans and by machines. Agents must be enabled to attach those observational details to the formal reports they submit regarding their actions/performance in pursuit of assigned responsibilities for intended processes.

It's also often important IMO for agents to be able to submit such details in their proposals to take responsibility for complex and complicated processes. For instance, if I think I can do a very technical job, I'll indicate which tools and techniques I'm willing and able to use as part of that work. But really, my main point here (inefficiently addressed) has been that our plans and proposals don't need to be as detailed as our actions and our reports of our actions.

Anyway, here are my main concerns moving forward:

1. It's important to me that communities can easily assign responsibility for intended processes to specific agents.
2. It's important to me that responsible agents can easily report actions related to responsibilities, distinguished as (a) performed directly by them, (b) performed by machines, or (c) performed (if allowed) by delegating or subcontracting to other agents.

[bhaugen]

I think we agree with pretty much everything you wrote there, except for some of the names of some of the concepts, which makes the impression of an argument a little odd.

A couple of minor clarifications: Lynn and I coined "Recipe Plan Reality" in the NRP project. VF renamed Reality to Observations. McCarthy says "What could be, What is scheduled, and What has occurred". In each of those conceptualizations, the Plan or What is scheduled layer has a full set of concepts mirroring those in the Reality, Observation or What has occurred layer. But all of those concepts and layers are somewhat optional. You can observe without planning, and plan without a recipe. And you can model any of it in more or less detail depending on your needs. We have our minimalists and maximalists.

We have discussed responsibilities a little in terms of who is responsible for the care and keeping of a resource, but have not nailed anything down. The concept McCarthy, NRP and VF use for responsibility for process components is Commitment, that is, who has committed to do something. Seems to entail responsibility for doing it, just a different word (again).

[gcassel]

I try to communicate without arguing per se. Asynchronous written discussion of complex subjects is challenging. I don't expect to reach full agreement on most subjects, and I'm not interested in imposing my preferences.

I appreciate the clarifications. I'd say that a commitment is one specific type of responsibility, but that doesn't seem important here. Commitments may be the only type of responsibility (and agreement) which vf ought to bother with anytime soon.

[bhaugen]

I think if you want to prove convergence or not, the best way to do it would be with some fairly detailed examples, real-world as much as possible.

[gcassel]

I think if you want to prove convergence or not, the best way to do it would be with some fairly detailed examples, real-world as much as possible.

That may be true, but I can't prioritize the full reconciliation of our terminologies right now. Hopefully it'll happen sooner or later.

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/forum-valueflo-ws/-/issues/78.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.