existing resource vs. planned resource

[elf-pavlik]

During chat on gitter we opened topic of distinguishing already existing resources from planned resources.

• when we transfer rights, we only do it for resources which already exist
• when we make commitments, we do it for resources which we plan but don't exist yet

IMO assigning IRI to planned resource can come very handy for direct identification. If everything happens according to the plan, once resource already exists we just change it state from planned to existing.

Also most offered services seem to fit planned resources, those services which can happen in the future, not those which already happened. I'll make separate issue for drawing further distinction between Resources as schema:Product and Resources as schema:Service.

[bhaugen]

We actually did this with food networks. They sell the crops in the field before they are harvested.

Or CSAs that get their supporting families to subscribe before planting to finance the crop, and then they get food baskets when the crops come in.

[bhaugen]

P.S. in the food network case, the crops in the field are actual rather than potential resources.It would be interesting to analyze the CSA case from a VF perspective. I haven't done it.

[elf-pavlik]

They sell the crops in the field before they are harvested.

By 'sell' do you mean make commitments or transfer rights as part of exchange?

[bhaugen]

Make commitments.

[fosterlynn]

when we make commitments, we do it for resources which we plan but don't exist yet

You can make commitments for resources which do exist. Like committing almost any inflow to a process or transfer. Outflows not so much. Like a piece of equipment to use in a process, say.

[fosterlynn]

As part of this discussion, I'd like to also consider the recipe layer. At that point, there really isn't anything that could eventually become a resource. There really only is a resource type.

So I'm hesitant to eliminate vf:ResourceType. We can't get the properties we need from the taxonomies out on the web for resource type. Like unit and isSubstitutable. And a name so the recipe can be read by humans.

This will apply to other types needed to create a recipe, like ProcessType, which will also have a large and widely spread taxonomy.

Thoughts?

[bhaugen]

Is anybody still thinking seriously about eliminating vf:ResourceType and vf:ProcessType?

[elf-pavlik]

As part of this discussion, I'd like to also consider the recipe layer. At that point, there really isn't anything that could eventually become a resource. There really only is a resource type.

I think we do have some resource of certain type, I see this resource in some kind of 'thinkable' state. Whenever we use quantities, we should use it on an instance of vf:Resource not an instance of ResourceType.

'@context': https://w3id.org/valueflows/v1
'@type': vf:Resource
'vf:kind': 
  '@id': https://www.wikidata.org/entity/Q89
  'name': apple
'vf:amount':
  '@type': qudt:QuantityValue
  'qudt:numericValue': 5
  'qudt:unit': unit:Kilogram

NOT

'@context': https://w3id.org/valueflows/v1
'@type': vf:ResourceType
'vf:kind': 
  '@id': https://www.wikidata.org/entity/Q89
  'name': apple
'vf:amount':
  '@type': qudt:QuantityValue
  'qudt:numericValue': 5
  'qudt:unit': unit:Kilogram

[bhaugen]

I see this resource in some kind of 'thinkable' state.

Seems pretty hand-wavy to me. Assuming we go with this (and I don't), what is vf:ResourceType used for anymore? Or are you seriously thinking of eliminating it?

Looks like vf:kind is the same as ResourceType, and you are introducing the idea of an imaginary Resource.

What am I missing?

[elf-pavlik]

can you please write snippet of data where you specify quantity "5kg of apples" in a Recipe?

[fosterlynn]

I see this resource in some kind of 'thinkable' state.

Seems pretty hand-wavy to me.

I think concretely you can't apply states here. The recipe "resource" is not a prior state of the actual resource that gets created or used. It is a whole different level: the type level. States take some object through different stages.

I'll try to write a snippet, @elf-pavlik

[fosterlynn]

'@context': https://w3id.org/valueflows/v1
'@type': vf:ResourceType
'@id': https://www.wikidata.org/entity/Q89
'name': apple
'qudt:unit': unit:Kilogram
'isSubstitutable': True

'@context': https://w3id.org/valueflows/v1
'@type': vf:ResourceFlowType
'vf:kind': 
  '@id': https://www.wikidata.org/entity/Q89
'vf:processType':
  '@id': https://www.wikidata.org/entity/P99
'vf:flowType':
  '@type': vf:Consume
'vf:amount':
  '@type': qudt:QuantityValue
  'qudt:numericValue': 5
  'qudt:unit': unit:Kilogram

Names and urls made up. Syntax not checked. Probably need a better way to id the resource type and process type that output LOD. But hoping to get the idea across....

[elf-pavlik]

I really don't like the use of vf:amount property on an instance of vf:ResourceFlowType. I would prefer to explore something in following direction

• please notice use of schema:SomeProduct
• vf-x: stands for experimental namespace, to distinguish terms which don't have agreed definitions in relevant .md file.

'@context': https://w3id.org/valueflows/v1
'@type': vf:Input
'vf-x:phase': vf:Recipe
'vf-x:verb': vf:consume
'vf-x:matchingResource':
  '@type':
    - vf:MaterialItem
    - schema:SomeProduct
  'vf-x:kind': 
    '@id': https://www.wikidata.org/entity/Q89
    'name': apple
  'vf-x:amount':
    '@type': qudt:QuantityValue
    'qudt:numericValue': 5
    'qudt:unit': unit:Kilogram

In that case we can just copy same Blank Node as we use for value of vf-x:matchingResource and use it in vf:Request as value of vf-x:intendedResource (possibly with scaled quantity)

'@context': https://w3id.org/valueflows/v1
'@id': urn:uuid:9561b249-9a59-4ed4-b7df-47222fb3ec75
'@type': vf:Request
'vf:agent':
  '@id': urn:uuid:d16cf83a-e4b2-4384-b229-31d9a094b1be
  name: elf Pavlik
'vf-x:periodicity': interval:Week
'schema:eligibleRegion':
  '@id': https://www.wikidata.org/entity/Q16978314
  name: Mexio City
'vf-x:intendedResource':
  '@type':
    - vf:MaterialItem
    - schema:SomeProduct
  'vf-x:kind': 
    '@id': https://www.wikidata.org/entity/Q89
    'name': apple
  'vf-x:amount':
    '@type': qudt:QuantityValue
    'qudt:numericValue': 5
    'qudt:unit': unit:Kilogram

And later in vf:Transfer

'@context': https://w3id.org/valueflows/v1
'@id': urn:uuid:4fab61f6-db9f-4abc-ad8c-fc935c342285
'@type': vf:Transfer
'vf:from':
  '@id': urn:uuid:0e604719-64c9-4892-8eeb-efa45718781f
  name: Jesus
'vf:to':
  '@id': urn:uuid:d16cf83a-e4b2-4384-b229-31d9a094b1be
  name: elf Pavlik
'vf-x:rightsFor':
  '@type':
    - vf:MaterialItem
    - schema:SomeProduct
  'vf-x:kind': 
    '@id': https://www.wikidata.org/entity/Q89
    'name': apple
  'vf-x:amount':
    '@type': qudt:QuantityValue
    'qudt:numericValue': 10
    'qudt:unit': unit:Kilogram

In all cases we use vf-x:amount property on an instance of [ vf:MaterialItem, schema:SomeProduct ], rather than sometimes on instance of vf:Input sometimes on vf:Request etc.

How do you plan to specify rdfs:range and rdfs:domain for vf-x:amount ?

[fosterlynn]

I really don't like the use of vf:amount property on an instance of vf:ResourceFlowType

I am trying to make that be the type object that represents the flow in a recipe, not the resource. It references a resource type, process type, and event type (for lack of a better name at the moment). And it has an amount because recipes need that. The amount is not attached to the resource or resource type, it is attached to the flow type.

I'm looking at the references to schema.org and GR, from here and gitter. But need a bit more time to look and document, can do after a meeting and lunch. And make more concrete in terms of yaml.

[fosterlynn]

I'm not sure of the significance of your bundling the @type, 'vf-x:kind', and 'vf-x:amount' under vf-x:matchingResource, vf-x:intendedResource, vf-x:rightsFor. Looks like those all vf:Resources, or rather subclass vf:MaterialItem. So this gets into the stock vs flow thought process, I think. To you, these are resources as they flow, right? Like as they are consumed or whatever? If so, that is not a REA Resource (or Type), that is a REA Event (or Commitment, or the corresponding recipe object).

What is wrong with un-indenting, thus:

'@context': https://w3id.org/valueflows/v1
'@type': vf:Input
'vf-x:phase': vf:Recipe
'vf-x:verb': vf:consume
'vf-x:matchingResourceType':
  '@type':
    - vf:MaterialItem
    - schema:SomeProduct
  'vf-x:kind': 
    @id': https://www.wikidata.org/entity/Q89
    'name': apple
'vf-x:amount':
  '@type': qudt:QuantityValue
  'qudt:numericValue': 5
  'qudt:unit': unit:Kilogram

[elf-pavlik]

What is wrong with un-indenting

You make vf-x:amount an attribute of instance of vf:Input. I see vf:Input as relationship between instance of vf:Process and instance of vf:Resource (even if we so far only can think of that resource and it has no existence outside of our imagination, always case on Recipe phase). A relationship represented as N-ary relation. I see reasons for vf-x:amount staying and attribute of instance of vf:Resource and not appearing on instances of other classes.

Besides snipped for an instance of vf:Input I also wrote snippets for instances of vf:Request and vf:Transfer. Could you please also write your version of those two, as well as snippet for equivalent vf:Input but in Report phase. This should allow us to analyse the difference in broader context which captures in a way 'a story' with those 5kg of apples appearing in each scene.

[bhaugen]

A vf:Resource will have a quantity. In case of a serialized resource, the quantity is 1. In terms of a stock resource, the quantity could be 1000. The vf:Input might want 10 of those.

[bhaugen]

In other words, the quantity of the input might be different from the quantity of the resource.

[fosterlynn]

You make vf-x:amount an attribute of instance of vf:Input. I see vf:Input as relationship between instance of vf:Process and instance of vf:Resource

Exactly! So a vf:Process (consumes 10) vf:Resource.

[fosterlynn]

Or more clearly: a vf:Process (consumes amount:10) vf:Resource (amount: 1000).

[ahdinosaur]

👎 '@type' of resource type as vf:Product, vf:Service, vf:MaterialItem, etc, with vf:kind as a property of the type to describe the platonic ideal of the resource. whether a resource type is a product, service, or material item seems to be distancing us from what the resources really are, i'd rather in this example the resource type is "apple" (the platonic ideal of the resource) and various resource type behaviors are properties of the type.

[fosterlynn]

You make vf-x:amount an attribute of instance of vf:Input. I see vf:Input as relationship between instance of vf:Process and instance of vf:Resource

Exactly! So a vf:Process (consumes 10) vf:Resource.

OK I see we are talking past each other, sorry about that. So I am seeing the vf:Input as a relationship between the vf:Process and the vf:Resource that exists on the other side of the input, the stock of 1000 apples. You are seeing it as relationship with the "resource" that is part of the flow. Like the 10 apples from the stock of 1000 apples.

@elf-pavlik I've been trying to think about our lengthy gitter chat on this topic... and how to visualize this stuff. I think it is wrong to think of an event/flow as an actual "flow", as in you walking to the market with apples in your bag, which is a process, not a flow. Perhaps that name is a mistake. It is really just an accounting of what happened to the resource (stock) and a description of how that is being incorporated into the next interaction (vf:Process or vf:Transfer). I would like to visualize it as a point in time, more like "event" than "flow", although the whole sequence acts like a flow. Once it has left the resource (stock), it is immediately in an instance of vf:Process or vf:Transfer. It has no life in between.

We can also think of it in terms of queries, say SPARQL. If you want to find out what Pavlik and others in the neighborhood have in terms of apples because you want to make a pie, you want to query the stock-like resources. If those 10 apples are going into another process or transfer, you don't want to know about those. They will either show up in someone else's stock-like resources, or disappear into a process. In either case, you don't want to double count them.

[elf-pavlik]

👎 @type of resource type as vf:Product, vf:Service, vf:MaterialItem, etc, with vf:kind as a property of the type to describe the platonic ideal of the resource.

sure we can do it differently, just keeping in mind http://www.productontology.org/#faq1

[ahdinosaur]

sure we can do it differently, just keeping in mind http://www.productontology.org/#faq1

hmm, by that logic, shouldn't we do the same for all our type objects?

[elf-pavlik]

@ahdinosaur I think we can look at this topic in general in https://github.com/valueflows/valueflows/issues/124

Let's maybe all try to stay here on the topic, I might rename this issue to something like "Phases (or stages) in resource manifestation".

I would like to talk about "resource I envision" as vf:Resource, and don't limit it to already manifested resources. Possibly pattern like `"@type": [ "vf:Resource", "vf:Intended" ] could serve this purpose. We already had chat with @fosterlynn about using https://www.w3.org/TR/2012/REC-owl2-primer-20121211/#Class_Disjointness in defining phases of vf:Input. So instance of vf:Input belongs only to one of those phases at any given time.

[fosterlynn]

@ahdinosaur I think we can look at this topic in general in valueflows/valueflows#124

Actually that issue is about event types; @ahdinosaur 's comment is about resource types, I think.

Although I agree with trying to stay on topic, and am fine with this being about phases and layers. And I also understand that our topics are often quite interconnected.

[fosterlynn]

My thoughts about phases: I think the layers are not phases. They are parallel layers. They are only phases in a broad sense, not in any sense of the objects in them, with the possible exception of commitment and event. But a non-real thing changing into a real thing seems too much for a phase change to me. And just as a note, the plan layer does not always happen, some processes and transfers just aren't intended, planned, committed to. Although they will still need some type information.

On the other hand, I can see some phase-y things within the Plan layer (which needs a better name). Would be interested in a model within that layer. And would be willing to give that a straw-dog shot, although it may not be right away.

[bhaugen]

What happens in the plan layer that is phased is the potential evolution of an Intent into a Plan into a Commitment. Those are horizontal, all in the same layer, but if an intent evolves like that, then the commitment and plan are all related to the intent.

This could be done by states of the same thing or back-references from Commitment to Intent. I think the difference between Plan and Commitment is pretty fuzzy, though: in REA, they are both Commitments.

rea:Commitment:

Ijiri (1975,p.130) defines a commitment as an “agreement to execute an economic event in a well-defined future that will result in either an increase of resources or a decrease of resources.” Commitments are important economic phenomena, and we use Ijiri’s term “executes” for the relation between them and the actual economic events that follow them. We model the pair-wise connection of requited commitments in a fashion similar to actual exchanges except we substitute a reciprocal relationship between the two commitments where an actual exchange has a duality relationship. Because of the importance of reciprocal relationships, we take the additional step of reifying them at a higher level of abstraction as economic agreements, and we differentiate between two different types of agreements: contract and schedule, the definition of which depends on the ultimate nature of the economic exchange. A transfer executes a contract while a transformation executes a schedule.

iso:Commitment:

An Economic Commitment is a promise to execute an Economic Event at some point in the future. The specification of an Economic Commitment may involve relationships with four type-level classes: Economic Resource Type, Location Type, Economic Event Type, and Economic Role. Economic Commitments may also have relationships with Economic Resource (reserves), Person (participate), and Business Location (target).

A little bit buried in the REA paragraph was the two types of commitments: contractual commitments, and schedule commitments. The word "Plan" could be reserved for schedules, and "Commitment" reserved for transfers and exchanges. Both of those are in the same layer, which I have called the Plan layer, and McCarthy lately has taken to calling What is Scheduled. (So we are both mixing our metaphors.)

[fosterlynn]

Taking this a little bit farther, maybe Offers and Wants turn into Commitments for Transfers, and Proposals turn into Plans for Processes... ?

[bhaugen]

Naming alert: @ahdinosaur has been pushing for a simpler naming scheme, where, if I remember correctly, vf:Process becomes vf:Transformation, which is the same as rea:Transformation. Maybe we should get on the stick and nail down more better names down before we confuse ourselves as well as the innocent bystanders.

[fosterlynn]

Naming alert: @ahdinosaur has been pushing for a simpler naming scheme, where, if I remember correctly, vf:Process becomes vf:Transformation, which is the same as rea:Transformation

Actually I think that was vf:Transformation a subclass of vf:Process, as is vf:Transportation. Last I heard. :)

[bhaugen]

Oops. Ok with me.

[ahdinosaur]

Actually I think that was vf:Transformation a subclass of vf:Process, as is vf:Transportation. Last I heard. :)

originally my suggestion was vf:Process becomes vf:Transform, alongside vf:Transfer and vf:Transport, as a subclass of vf:Transaction (now vf:Action).

[fosterlynn]

Oh yeah, sorry!

[elf-pavlik]

Do you see vf:Transfer as similar to vf:Transport but with the difference of applying to the rights to resources (which I call currency in #128) not directly to resources?

• vf:Transport - vf:pickup the laptop from place Foo and vf:dropof it in place Bar
• vf:Transfer - vf:take owenrship rigths to the laptop from agent Alice and give that ownership rights to agent Bob

So far we looked at vf:Process putting it in the center, so input/output related it to resources and the verbs get used from perspective of the process (in - consume, out - create) or (in - pick-up, out - drop-off)

In case of vf:Transfer we deal with different kind of relation. Rights to a resource and agents, if we materialize rights (for example as currency) an instance of vf:Transfer could move them between agents. (in - take, out -give) but that ends up as opposite naming to what @fosterlynn proposed for give and receive, looking at it from perspective of agents not the transfer. So vf:Transfer currently looks like N-ary Relation between one resource and two agents - no distinct inputs and outputs.

[elf-pavlik]

from gitter chat https://gitter.im/valueflows?at=57a8df95bc688a133906b30d

@fosterlynn
so do we agree that a vf:Resource is on the observation layer, and if it has a quantity > 0, a person should be able to observe the quantity?
you can't have a planned vf:Resource with a planned quantity?
@elf-pavlik
that should work!

related to #24

'@context': https://w3id.org/valueflows/v1
'@id': https://inventory.example/8dd791fa-9f5f-411a-9385-a4afbc784fd8#resource
'@type':
  - vf:Resource
  - fablab:Cool-Item-44
'vf:quantity':
  '@type': qudt:QuantityValue
  'qudt:numericValue': 0

Above could represent 'planned resources', and observed event would just increment its quantity. This resource could also reference planned events which expect it as one of its input. I'll write YAML of it as comment in another issue.

from https://github.com/valueflows/process/issues/18#issuecomment-238120526

[elf-pavlik]

We should think about planned Service and Usage. As well as modeling availability as stock with timeline and using 'logical resources' on them to have a clear reference for allocation.

[fosterlynn]

I suspect people have done the calendar availability before? Run in to that anywhere @elf-pavlik ?

[elf-pavlik]

We should think about planned Service and Usage. As well as modeling availability as stock with timeline and using 'logical resources' on them to have a clear reference for allocation.

currently discussed in: https://github.com/valueflows/resource/issues/51

[elf-pavlik]

It looks like we can represent plans using vf:Intent and since any vf:EconomicResource can have quantity == 0 one can also create instances just for the sake of planning.