agent - resource type/etc. - agent

[fosterlynn]

Both @pmackay and @djodjoni have expressed a desire for something like agent - resource type - agent. It would basically say something like "FarmerX provides carrots to FoodHubY". You could probably get this from commitments or past events, but what if you don't want to implement all of that? We talked a bit about maybe trying out Intents for this. It is kind of like an intent, but not exactly.

We also use something like this in LocEcon, which would be theoretically happy to get this kind of data from operational systems, but in fact mostly does not have access to it, and doesn't have a way to gather it yet.

@bhaugen and I talked about this over breakfast, and I want to propose we add this structure to VF, and figure out what would be included.

Something like vf:AgentResourceFlow?

Properties: vf:provider, vf:receiver, vf:category (?? - do we need anything more specific than category?). Might need a vf:action, although that might be 2 action verbs, need to try some things out; or maybe as long as we have the direction, that is all that is needed, I don't know. Might need some dates/durations kind of things. Just brainstorming.

What do people think about including something like this? On one hand, I want to try to get a minimal agreed upon vocab released for basic REA; on the other hand, here are some needs expressed, I think good to go for it while people are actively thinking about it. And I think there will be even higher level constructs needed for community or regional planning, which also might or might not have a link to operational data.

[pmackay]

Thanks for the suggestion @fosterlynn :) Just to check, do you see introducing vf:AgentResourceFlow as preferable to using Intents as discussed on Friday?

Also if start and end Locations needed to be defined, might they be part of this or are you seeing this only working with an Agent per Location?

[fosterlynn]

Just to check, do you see introducing vf:AgentResourceFlow as preferable to using Intents as discussed on Friday?

Well, on thinking about it after we talked, I do think Intents have a somewhat different meaning, and also wouldn't really generally include 2 agents (I think, could be wrong). But what do you think?

Also if start and end Locations needed to be defined, might they be part of this or are you seeing this only working with an Agent per Location?

Locations would be great. Hmmm, would we want locations for the ends of the flow separate from the agents' locations? Maybe for the example of unmanned recycling centers? Or is that getting too far into the weeds for something that provides more general information?

[pmackay]

Sorry, I've confused myself. OK I was seeing Intents as a way for Agents to indicate offers/needs, e..g we repair bikes, recycle clothes, etc. And I was going to look more at how ExchangeAgreements could define a map between Agents. So are you seeing AgentResourceFlow as a more general way to express an ExchangeAgreement?

would we want locations for the ends of the flow separate from the agents' locations?

it depends on that question of whether an Agent is tied to a single location. For me that feels a bit excessive, but maybe I need to play with this a bit more. And certainly unmanned locations would be hard to capture this way.

[bhaugen]

So are you seeing AgentResourceFlow as a more general way to express an ExchangeAgreement?

In our NRP software, it's not an agreement, it is just a record we keep when one Agent performs some Economic Event. If the record exists, we add to the quantity. If not, we create the record with the quantity of the event.

I'm not saying VF should do it like that. The limitation of that approach is that you don't know who can provide resources of what type until an actual event occurs. But keeping a summary of the quantities has been useful.

[pmackay]

@bhaugen it would be great if VF could accommodate both high level flow maps and lower level transactions/events IMHO.

[bhaugen]

it would be great if VF could accommodate both high level flow maps and lower level transactions/events IMHO.

Can do. The Mutual Aid Networks want to do this. @fosterlynn and I will work with them on it. See also https://github.com/valueflows/valueflows/issues/135

[elf-pavlik]

We already have N-ary relation vf:Relationship, one could reuse it and just add category of resources eg.

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/3jwoefjosifjaoif#relationship
'@type': vf:Relationship
'vf:subject': https://coop.example/#identity
'vf:object': https://producer.example/#identity
'vf:relationship': vf:receiver
'vf-x:involvedResourceCategory': wd:Q20136

This requires adding just on instance of rdf:Property and reuses vf:provider and/or vf:receiver which we want to add anyways on events/commitments.

[fosterlynn]

So are you seeing AgentResourceFlow as a more general way to express an ExchangeAgreement?

In our NRP software, it's not an agreement, it is just a record we keep when one Agent performs some Economic Event. If the record exists, we add to the quantity. If not, we create the record with the quantity of the event.

it would be great if VF could accommodate both high level flow maps and lower level transactions/events IMHO.

I was thinking of this mostly being useful for higher level flow maps. And I wasn't thinking of it specifically as an agreement, just a more general statement that could be based on agreement, or just on actual practice.

And yes @pmackay we have thought VF should be able to accommodate the high level flow maps. Haven't done anything about it yet. Locecon maps agents to "functions" and connects functions to each other through the same REA pattern, using "consumes" and "produces" "resource types". Or you can just to the function level if you want.

So for high level flow maps, AgentResourceFlow would be the gateway..... gateway drug? :)

[djodjoni]

nice ! I was imagining just a general relationship but more details could be useful also. so:

'@context': https://w3id.org/valueflows/v1-dev '@id': https://coop.example/3jwoefjosifjaoif#relationship '@type': vf:Relationship 'vf:subject': https://coop.example/#identity 'vf:object': https://producer.example/#identity 'vf:relationship': vf:receiver 'vf-x:involvedResourceCategory': wd:Q20136

so are we sticking to object,subject,context (+ possible involved ResourceCategory) for general relationships also ? this compared to defining specific properties for various relationships?

[elf-pavlik]

After longer discussion with @fosterlynn on chat, it seems that vf:provider and vf:receiver fit more as Agent - Intent/Commitment/Event relationships. For Agent - Agent something like supplier would make more sense, which would also not require any inverse/reverse variant.

[fosterlynn]

@pmackay @djodjoni should we pursue this one now? I'm happy to do so, if you feel like it would be useful to you, and to VF, and would get VF more in sync with where you want to go. Otherwise, I'll leave it on the back burner. :)

[elf-pavlik]

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/3jwoefjosifjaoif#relationship
'@type': vf:Relationship
'vf:subject': https://coop.example/#identity
'vf:object': https://producer.example/#identity
'vf:relationship': wd:Q1762621 # vendor / suppier
'vf-x:involvedResourceCategory': wd:Q20136

I still think we should just use relationship between agents, we can just use wikidata 'vendor / supplier' reference. Possibly we can also use vf:context in more generic way and reference resource taxonomy item with it instead of defining new property, so:

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/3jwoefjosifjaoif#relationship
'@type': vf:Relationship
'vf:subject': https://coop.example/#identity
'vf:object': https://producer.example/#identity
'vf:relationship': wd:Q1762621 # vendor / suppier
'vf:context': wd:Q20136 # root vegeteable

"prducer.example 'is vendor/supplier' of coop.example in context of root vegetables"

I really don't think we need completely different way for this kind of relationship. We still just want to say:

• who has relationship with who (subject & object)
• categorize this relationship ( relationship)
• give this relationship some context (context)

[fosterlynn]

I really don't think we need completely different way for this kind of relationship. We still just want to say

I disagree. It may have a similar looking data structure, but it has a different relational and functional meaning in the real world, and will be used in different ways, on different UI's. It will just make it hard to separate things out in a query.

I feel the same way about context. Trading root vegetables isn't a context. It is a lower level specific detail of this construct. [EDIT] ... "feel the same way" meaning this is another example of not distinguishing in the model at the real world meaning level.

[elf-pavlik]

Putting aside that suggestion of possibly just throwing 'root vegetables' as context. I think the primary part should express: "producer.example 'acts as vendor/supplier of' coop.example" while Relationship seems meant for cases like "bob.example 'acts as a member of' coop.example" etc.

Now we just need to find a way to qualify this relationship with 'root vegetables'. The only reason we have such reified version of relationship comes from need to have a way to qualify them, sometimes make n-ary. Otherwise we could just have <https://coop.example> vcard:hasMember <https://bob.example>. Since we have this Qualified Relation pattern, I don't see reason why not to use it by adding 'root vegetables' as some particular qualification.

[fosterlynn]

Since we have this Qualified Relation pattern, I don't see reason why not to use it by adding 'root vegetables' as some particular qualification.

This is a good example of what I was trying to say, unsuccessfully. Having already a Qualified Relation pattern is really really not a good reason to add a property into it for a new requirement. It is a broadly applicable technical pattern that can be used in lots of ways. The only good reasons would be because it is the same functional meaning and could be used in the same way, etc.

I think the primary part should express: "producer.example 'acts as vendor/supplier of' coop.example" while Relationship seems meant for cases like "bob.example 'acts as a member of' coop.example" etc.

My understanding of Relationship was exactly that is should express any agent relationship by specifying the role of the relationship, which would include supplier/customer. The type or verb tends to be used to filter choices in appropriate places, and we have used it this way a lot in real software. It would be a bit chaotic to have many relationships with the same agents and same role, just because they trade all kinds of veggies or whatevers with each other.

[bhaugen]

Yeah, I'm with Lynn on this one. I think that

'vf:context': wd:Q20136 # root vegeteable

is the wrong property in the wrong place. Wrong granularity.

In NRP, we have an AgentResourceType relationship that specifies Agent, ResourceType, and EventType (like, Farmer Marina provides Root Vegetables to Vientos).

Then Farmer Marina can also provide Apples, and Cabbage, and Chile Peppers. And Farmer Marina can also buy seeds from Farmer Alice.

[bhaugen]

P.S. I am not saying VF needs to do this exactly like NRP, but we did meet and solve that problem, so it's worth looking at what worked and what did not work. (As in my first food network software.)

[elf-pavlik]

It would be a bit chaotic to have many relationships with the same agents and same role, just because they trade all kinds of veggies or whatevers with each other.

Since you have vf:context there, you already have to anticipate multiple instances of vf:Relationship each with the same value of vf:subject, vf:relationship, and vf:object. If you just want to get list of unique vf:relationship for specific pair of vf:subject and vf:object you can write query that selects just one and ignores vf:context and whatever other qualifications on those relationships.

Then Farmer Marina can also provide Apples, and Cabbage, and Chile Peppers. And Farmer Marina can also buy seeds from Farmer Alice.

I don't remember if you wanted to define vf:context as functional or not, for the categories of resources we would NOT want it functional, so you can have

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/3jwoefjosifjaoif#relationship
'@type': vf:Relationship
'vf:subject': https://coop.example/#identity
'vf:object': https://producer.example/#identity
'vf:relationship': wd:Q1762621 # vendor / suppier
'vf-x:involvedResourceCategory':
  - wd:Q20136 # root vegetables
  - ??? # apples
  - ??? # cabbage

No need to create one relationship for each category!

[bhaugen]

We found it very useful to keep records of what quantities happened on each agent-resource-action relationship. Can do by summarizing events, too, but very fast for graphs etc to have already denormalized.

[elf-pavlik]

That sounds like new requirement here :smile: but since you throw it in then in stead of 'vf-x:involvedResourceCategory' something like 'vf-x:flowCategorizedStatistic' could reference records which have quantities, so

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/3jwoefjosifjaoif#relationship
'@type': vf:Relationship
'vf:subject': https://coop.example/#identity
'vf:object': https://producer.example/#identity
'vf:relationship': wd:Q1762621 # vendor / suppier
'vf-x:flowCategorizedStatistic':
  - '@id': https://coop.example/stats/5689ef82-01dc-4f74-bf83-7a2f4b0e05ea
    'vf-x:analyzedCategory': wd:Q20136 # root vegetables
    'vf-x:aggegatedQuantity': 
      'qudt:unit': unit:Kilogram
      'qudt:numericValue': 200
  - '@id': https://coop.example/stats/5532076a-7c49-46cf-939a-a25f2622308c
    'vf-x:analyzedCategory': ??? # cabbage
    'vf-x:aggegatedQuantity': 
      'qudt:unit': unit:Kilogram
      'qudt:numericValue': 200

Since we have this Qualified Relation pattern, I don't see reason why not to use it by adding 'root vegetables' as some particular qualification.

We can use it as n-ary relation and reference all those statistical records if we want to. My main point stays the same. We already have dedicated way to express "producer.example 'acts as a vendor / supplier of' coop.example" and then qualify it however we want to.

[elf-pavlik]

Following #123 we can state the same with

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/3jwoefjosifjaoif#relationship
'@type': vf:Relationship
'vf:subject': https://coop.example/#identity
'vf:object': https://producer.example/#identity
'vf:relationship': wd:Q1762621 # vendor / suppier

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/stats/5689ef82-01dc-4f74-bf83-7a2f4b0e05ea
'vf-x:analyzedCategory': wd:Q20136 # root vegetables
'vf-x:aggegatedQuantity': 
  'qudt:unit': unit:Kilogram
  'qudt:numericValue': 200
'@reverse':
  'vf-x:flowCategorizedStatistic': https://coop.example/3jwoefjosifjaoif#relationship

'@context': https://w3id.org/valueflows/v1-dev
'@id': https://coop.example/stats/5532076a-7c49-46cf-939a-a25f2622308c
'vf-x:analyzedCategory': ??? # cabbage
'vf-x:aggegatedQuantity': 
  'qudt:unit': unit:Kilogram
  'qudt:numericValue': 200
'@reverse':
  'vf-x:flowCategorizedStatistic': https://coop.example/3jwoefjosifjaoif#relationship

data of the same graph just serialized to JSON tree using different frame.

[pmackay]

@fosterlynn delayed response to your question - yes I'm keen to keep iterating on this where possible :)

Reading the last bunch of comments, am feeling like AgentResourceFlow seems more logical than reusing relationship. (what kinds of examples would vf:relationship be used for otherwise?)

vf-x:involvedResourceCategory seems a bit cumbersome. Also @elf-pavlik where does the vf-x come from? Is that extended syntax? Shouldnt the aim be to cover this within core VF?

The Mutual Aid Networks want to do this.

Just wondering, would the concepts used in Locecon be a better fit at all? Does Function have a place, if this is a requirement for VF? (or does Intent already cover "Function"?)

[bhaugen]

. The Mutual Aid Networks want to do this. (accommodate both high level flow maps and lower level transactions/events)

Just wondering, would the concepts used in Locecon be a better fit at all?

Locecon was meant to be a high-level aggregated view of the VF event level. The first people we worked with on Locecon, in Nova Scotia, had this idea of what they called "macro" and "micro" views of economic development, where Locecon is the macro view, and VF is the micro view, and that the two views should be connected to each other. The macro view should aggregate the micro view events for analysis: for example, gap analysis. So, for example, in the network of small fishing boats, there was a gap in processing, distributing, and marketing sustainable fish, as opposed to the trawler-dredged unsustainable fish. So they worked on those gaps, with partnerships with processors, "community-supported fisheries", sustainable fish labelling, and a bunch of other stuff. The idea was to take lessons from the macro view and put them back into action in the micro view, and then back around again to see how the interventions worked.

That's also what the Mutual Aid Networks want to do.

Does Function have a place, if this is a requirement for VF? (or does Intent already cover "Function"?)

Function was an aggregate for a set of process types that produce an aggregate set of resource types. An agent might perform more than one function. Like my cousin Leon was a farmer who produced food, but also drove long-haul truck, and participated in a traveling combine crew. Depending on the desired granularity of macro-analysis, you might want to separate the functions of dairy farming, cattle raising, grain farming, vegetable raising, and seed growing.

I am not sure that Function is a requirement for VF. A taxonomy of process types might fit better.

[fosterlynn]

what kinds of examples would vf:relationship be used for otherwise?

Things like member, affiliate, mentor, child (like a sub-group of a group), any role (our herbal network uses grower, harvester, dryer, seller). But also supplier relationships, which is what this is, except for a specific resource category. Basically any kind of relationship that shows the "shape" of the network.

vf-x: is just something we have used when the term is not vf: accepted yet, but we are more proposing it. But we are inconsistent. :)

Just wondering, would the concepts used in Locecon be a better fit at all? Does Function have a place, if this is a requirement for VF? (or does Intent already cover "Function"?)

I am not sure that Function is a requirement for VF. A taxonomy of process types might fit better.

But then @bhaugen you are saying you think the concept is a requirement, true? I like taxonomy of process types. And I like it as part of VF, but I think it will only be a priority when someone wants it. It is not clear to me that the MAN wants function level yet, although they do want to use Locecon at the agent level, with more generic resource categories.

@pmackay is your requirement at the agent level, or at the function level, or both?

or does Intent already cover "Function"?

The more I think about it, the more I think not. Did you have any success with using it for your need? Intents seem more to broadcast a want or offer of the moment, less an ongoing analytical thing.

[bhaugen]

But then @bhaugen you are saying you think the concept is a requirement, true? I like taxonomy of process types. And I like it as part of VF, but I think it will only be a priority when someone wants it. It is not clear to me that the MAN wants function level yet, although they do want to use Locecon at the agent level, with more generic resource categories.

Agree with most of that. I don't think the MAN knows how to think about it yet. A lot of ideas, but no real focused work yet.

[pmackay]

is your requirement at the agent level, or at the function level, or both?

Certainly agents, beyond that needs more iteration.

Did you have any success with using it for your need?

Still working on this :)

I like taxonomy of process types

Me too, I agree that works with VF.

Basically any kind of relationship that shows the "shape" of the network.

Those examples help a lot and IMHO suggest that it could be safer to keep these kinds of relationships separate from a way to connect agents via a general (unquantified) resource flow.

[fosterlynn]

Those examples help a lot and IMHO suggest that it could be safer to keep these kinds of relationships separate from a way to connect agents via a general (unquantified) resource flow.

:+1:

@pmackay Would you be OK if the general (unquantified) resource flow eventually became an optionally quantified resource flow (could be estimated or derived from actuals) quantity per time period? In the same construct?

That makes the relationships also useful to determine (as you roll up to functions) if there is enough or not for the community. I can also imagine uses for it on the agent level.

[pmackay]

Would you be OK if the general (unquantified) resource flow eventually became an optionally quantified resource flow (could be estimated or derived from actuals) quantity per time period? In the same construct?

Yes, definitely can see use cases for all 3 variants here.

[elf-pavlik]

Properties: vf:provider, vf:receiver, vf:category (?? - do we need anything more specific than category?).

[...]

Things like member, affiliate, mentor, child (like a sub-group of a group), any role (our herbal network uses grower, harvester, dryer, seller). But also supplier relationships, which is what this is, except for a specific resource category.

Let's take that made up https://producer.example and https://coop.example

1) To express that supplier, seller whatever relationship between them (not specifying any resource categories) we can simply use vf:Relationship.

2) Both https://producer.example and https://coop.example can independently publish intents that they want to receive or issue resources in some particular category

What the suggested vf-x:AgentResourceFlow would provide as addition to above? Statistics derived from past events data? Act as a 'bookmark' of discovered matching between intent to issue resources in some category by https://producer.exampe and receive by https://coop.example?

I just want to make sure that we don't create multiple ways to express the same thing, since that will work against interoperability.

[fosterlynn]

I just want to make sure that we don't create multiple ways to express the same thing, since that will work against interoperability.

Completely valid. Let's make sure. One thing that seems conceptually different is that this whole set of relationship (this level and function level) will work with time periods of an analysis. (Although @pmackay doesn't need that now.) In general, I don't think these are so much to support operations - although Paul and Kalin may disagree from their requirements - which would be interesting. In LocEcon, it is more about analyzing community resource flows, gaps, opportunities.

In my experience (by definition limited), this construct is used much differently than agent relationships, because the emphasis is on the resource flow. But I don't know how Paul and Kalin are thinking about it.

(I'm just continuing to discuss here, not trying to argue.)

What the suggested vf-x:AgentResourceFlow would provide as addition to above? Statistics derived from past events data? Act as a 'bookmark' of discovered matching between intent to issue resources in some category

Could be statistics from past event data. If future, I think of it less of a 'bookmark' than as estimate to be used in analysis. Might need to represent those differently. But let's not do anything with them now unless someone needs them.

Properties: vf:provider, vf:receiver, vf:category (?? - do we need anything more specific than category?).

How about vf:resourceCategory? I think more clearly documented..... but I don't think we need anything more specific than category. @pmackay ? @djodjoni ?

@bhaugen you were putting I think "ability" and "need" into the naming discussion in LocEcon, based on "from each according to ability, to each according to need" kind of thing. Do you have an opinion? I actually think provider and receiver are pretty clear. (To note, we have had a hard time with users understanding this concept sometimes, and have struggled with the names.)

[bhaugen]

@bhaugen you were putting I think "ability" and "need" into the naming discussion in LocEcon, based on "from each according to ability, to each according to need" kind of thing. Do you have an opinion? I actually think provider and receiver are pretty clear. (To note, we have had a hard time with users understanding this concept sometimes, and have struggled with the names.)

I won't get into the names for a minute. First, want to clarify something about Locecon. We looked at potential and actual resource flows. Potential flows exist when one agent function can provide a consistent output of some resource type, and some other agent function consistently needs that same resource type, where agent, function, and resource type might be broad aggregates. An actual flow exists when one agent function does regularly transfer resources of a resource type to another agent function.

The differences between potential and actual resource flows in a community might represent gaps. Or just missing information.

So yes, I put "ability" and "need" into the discussion in Locecon for potential resource flows, but we don't have any consensus or even much of a conversation there yet. That's a long way to explain that I don't have an opinion on the somewhat-but-not-exactly-related VF names...

[edit] I apologize if that was a waste of time...

[elf-pavlik]

We looked at potential and actual resource flows. Potential flows exist when one agent function can provide a consistent output of some resource type, and some other agent function consistently needs that same resource type, where agent, function, and resource type might be broad aggregates.

We still have to clarify how to publish intents in a way that one can interpret them as 'consistently' offering/requesting something, (maybe a template from each 'one time' intents get stamped every month or some other period of time). But that 'potential' seems like a match between two intents - one where agent casting it appears as provider (aka offer) and other where agent casting it appears as receiver (aka request). Actually for Vientos we don't plan any soon to get into AI recommendation engine but consider crowdsourcing finding matches to all the people who use it. To represent 'suggested' match we might end up needing something that expresses that 'potential' between two matching intents. Also related to https://github.com/valueflows/intent/issues/7

[fosterlynn]

First, want to clarify something about Locecon. We looked at potential and actual resource flows. Potential flows exist when one agent function can provide a consistent output of some resource type, and some other agent function consistently needs that same resource type.... An actual flow exists when one agent function does regularly transfer resources of a resource type to another agent function.

Actually, that is a good point. To clarify though, this is different than the question about actual event feeds vs estimates. I think both of those (and @pmackay and @djodjoni can correct me from their requirements point of view) are what we would consider "actuals" in LocEcon. Potentials are when you don't document (and possibly don't know) the agent (or function) on the other side. In this case, the agents have at minimum some agreement with each other to transfer resource category that is being documented.

And 'provider' / 'receiver' might fit best with the 'actual' flows; 'ability' / 'need' more with 'potentials'? Anyhow, we'll see later how those names fly with users.

[bhaugen]

Locecon potential flows were not based on intents. People sometimes misinterpreted them that way. They wanted to be based on aggregate data of actual inputs and outputs, although sometimes that is difficult to get.

Examples of such analysis: Ken Meter came to our area of Wisconsin and got a bunch of relatively accurate data that said we were growing a lot of food that went out of the area, and buying a lot of food that came into the area from outside. So there was a gap, that we could fill by distributing the locally grown food better inside the area, and thus strengthen the local economy.

Similar gaps appeared in analysis of Nova Scotia. One godawful one was that locally caught fish got shipped to China to be filleted and then shipped back to Nova Scotia to be sold.

[fosterlynn]

But that 'potential' seems like a match between two intents

To add on to what Bob said, for us the use case is different. And to clarify for Bob, some intents are cast indefinitely into the future. But in any case, it is not a matter of agents finding each other for immediate specific needs / offers. It is more a community analysis level, and about the aggregate flows over time.

However.... I still don't know if that is where @pmackay or @djodjoni are going with it.... so I think we need to wait for that input, we could be in a different universe. :wink:

[pmackay]

To summarize, are these valid requirements/statements (they all sound valid for me):

• Intents can express general offers/needs, of resourceCategory.
• Intents are also for expressing specific offers/needs, of a resource.
• Intents are one-sided, so not useful for defining a connection between 2 agents.

For resource flows there are:

1. Resource category flows: A-[resourceCategory]->B
2. Quantified resource flows over a time period
3. Potential flows that might be manually modelled or automatically derived from matching Intents

(1) was the original focus of this issue (I think?). How to decide on pros/cons of using Relationship or AgentResourceFlow?

Is this a reasonable summary?

[elf-pavlik]

1. Resource category flows: A-[resourceCategory]->B

I don't understand what do you mean by that, do you want to use a taxonomy item eg. https://www.wikidata.org/entity/Q89 as property that relates agents?

[djodjoni]

My understanding is exactly as @pmackay wrote.

Resource category flows: A-[resourceCategory]->B

I don't understand what do you mean by that, do you want to use a taxonomy item eg. https://www.wikidata.org/entity/Q89 as property that relates agents?

in my case this is Yes. It is a taxonomy item. Might be broad like vegetables or more specific like carrots. This however can be a 'service' category or any other resource that might be.

[pmackay]

I don't understand what do you mean by that, do you want to use a taxonomy item

Sorry, that wasnt the best way to illustate the concept. Earlier discussion has been around the idea of an AgentResourceFlow model that would like provider, receiver and resourceCategory, which I think would be needed to properly model this.

[djodjoni]

Let's kill that one ! :)

So from lightning fast gitter discussion with @fosterlynn I got:

relationships are like member, part of, affiliate of, coordinator, etc etc

where we currently have:

vf:AgentRelationship  a  owl:Class ;
        rdfs:comment  "An ongoing voluntary association between 2 Agents of any kind." ;
        rdfs:label    "vf:AgentRelationship" .

vf:subject  a         owl:ObjectProperty ;
        rdfs:comment  "The subject of a relationship between 2 agents." ;
        rdfs:domain   vf:AgentRelationship ;
        rdfs:label    "subject" ;
        rdfs:range    foaf:Agent .

vf:object  a          owl:ObjectProperty ;
        rdfs:comment  "The object of a relationship between 2 agents." ;
        rdfs:domain   vf:AgentRelationship ;
        rdfs:label    "object" ;
        rdfs:range    foaf:Agent .

vf:context  a         owl:ObjectProperty ;
        rdfs:comment  "The larger context of a relationship between 2 agents, used where the relationship is not relevant outside of that context." ;
        rdfs:domain   vf:AgentRelationship ;
        rdfs:label    "context" ;
        rdfs:range    foaf:Agent .

vf:relationship  a    owl:ObjectProperty ;
        rdfs:comment  "A verb that describes a generic defined relationship that exists between 2 agents." ;
        rdfs:domain   vf:AgentRelationship ;
        rdfs:label    "relationship" ;
        rdfs:range    rdf:Property .

from https://github.com/valueflows/valueflows/issues/187#issuecomment-286052153

For resource flows there are:

1. Resource category flows: A-[resourceCategory]->B
2. Quantified resource flows over a time period
3. Potential flows that might be manually modelled or automatically derived from matching Intents

(1) was the original focus of this issue (I think?). How to decide on pros/cons of using Relationship or AgentResourceFlow?

So my question is : 1) is rdfs:range rdf:Property in vf:relationship intentional and how it is designed to be used 2) the question of @pmackay :

how to decide on pros/cons of using Relationship or AgentResourceFlow

So I want to say A is coordinator,producer,distributor.. of B which fits in AgentRelationship however this can be also stated as: A -> tax:food, tax:tomatoes, tax:transportService, tax:CoordinationService ->B

but in a similar way i'd like to use more specific things(taxonomies/categories for resources)

A -> tax:tomatoes, tax:intercityRefrigeratedtransportService->B

This essentially describes in a more generic way what kind of resouces are flowing form/to where.

These of course can be extraced by Templates and Plans and actual Events but in some cases you dont need to know the details.

Infact this is one of the things I want to put in openfooddata.org so people will be more aware of the flow of the food :)

[fosterlynn]

@djodjoni

I'm thinking..... a couple questions:

ofd:storesFor a ofd:RelationProperty ;
rdfs:label "storesFor" ;
ofd:relatedService ofd:FoodStorage ;
rdfs:domain foaf:Agent ;
rdfs:range foaf:Agent .

ofd:pickingFor a ofd:RelationProperty ;
rdfs:label "pickingFor" ;
ofd:relatedService ofd:FoodPicking ;
rdfs:domain foaf:Agent ;
rdfs:range foaf:Agent .

In these examples, it seems like the relationship label and the resource category/model duplicate each other in meaning. I'm thinking about what this means, but it does seem like we could get rid of one. If you want to look at resource flows themselves, or some day quantify them, then it seems like we would need that. If not, maybe it is just our existing agent relationship, which can have all kinds of user defined meanings, and can then be used to graph the agent network just in terms of relationships?

Actually, I sort of already asked: do you want to relate this info to resource categories/models in any way in other places in your software or vocab? And do you ever want to know how much of the resource category/model flows between those agents in a year or whatever, without adding up events?

[djodjoni]

ofd:storesFor a ofd:RelationProperty ; rdfs:label "storesFor" ; ofd:relatedService ofd:FoodStorage ; rdfs:domain foaf:Agent ; rdfs:range foaf:Agent .

ofd:pickingFor a ofd:RelationProperty ; rdfs:label "pickingFor" ; ofd:relatedService ofd:FoodPicking ; rdfs:domain foaf:Agent ; rdfs:range foaf:Agent .

these I don't like it was just to tryout but obviously not good as I mentioned in the gitter chat.

what I would like is simple : A -> tax:food, tax:tomatoes, tax:transportService, tax:CoordinationService ->B

it could be expresses as

vf:someRel a vf:AgentResourceRelationship ;
vf:subject A ;
vf:object B ;
vf:resource tax:food , tax:tomatoes , tax:transportService , tax:CoordinationService .

the question is is vf:AgentRelationship suitable for this, which is partially related to my previous quiestion:

is rdfs:range rdf:Property in vf:relationship intentional and how it is designed to be used

[fosterlynn]

is rdfs:range rdf:Property in vf:relationship intentional and how it is designed to be used

It was intentional, it is meant to be a named relationship, similar to Activity Streams https://www.w3.org/TR/activitystreams-vocabulary/#dfn-relationship; and also from NRP agent relationships, which are from some other standard models. Not to say it can't be revisited, we're on 0.1. :)

Bob had a good idea on our walk-n-talk this morning, which I will try out - list all the gradations of the concepts, from simplest to most complex or developed. Probably needs more development, but off the top of my head:

Agent A - relationship - Agent B Agent A - resource cat/mdl - Agent B ( Agent A - resource cat/mdl-quantity-per-time-period - Agent B Function X - resource cat/mdl-quantity-per-time-period - Function Y Function X in general location - resource cat/mdl-quantity-per-time-period - Function Y in general location

And various combinations, multiplicities, etc.

This is an effort to see how many separate data structures we need, the fewer the better possibly, but within the limits of common sense of clear definitions?

[fosterlynn]

Addition to the above, we also could support potential flows. Like Agent A - resource cat/mdl X (provider) Agent B - resource cat/mdl X (receiver)

And same for Functions. And then they can get graphed so you can see where productive links can be made, and where there are opportunities to start something new because there is a gap.

But this is beyond anything @djodjoni or @pmackay have expressed any need for. So later. :)

[fosterlynn]

Looking at the above list, and ignoring the "potential" flows for now, I'm thinking a suitably downsized list is: Agent A - relationship - Agent B Agent A - resource cat/mdl-quantity-per-time-period - Agent B Function X in general location - resource cat/mdl-quantity-per-time-period - Function Y in general location [where functions can aggregate agents if the data is available - or not]

With some stuff being optional, thus supporting all options. And if there are other parameters that made sense if the 2nd and 3rd, we just add them. But keep the first one clean and simple and supportive of any and all types of agent relationships.

So then the 2nd one would support @djodjoni and @pmackay , and they would ignore the quantity. We could support multiple types of resources listed in one agent-agent "record" in RDF if we are willing to have some different formats, which I don't have enough experience to know if is a bad or good idea, seems like it might be OK. A relational database would have to blow out the multiples anyhow into separate "records"; but that's easy to translate back and forth.

Still running thought experiments..... does this make any sense?

[djodjoni]

With some stuff being optional, thus supporting all options. And if there are other parameters that made sense if the 2nd and 3rd, we just add them. But keep the first one clean and simple and supportive of any and all types of agent relationships.

This seems fine so 2 is what interests me and you suggest to create new Relationship class with options subject, object, resource cat, qty, time.. and add more options when needed? we can extend the general relationship btw,

One point on that relationship class:

is rdfs:range rdf:Property in vf:relationship intentional and how it is designed to be used

It was intentional, it is meant to be a named relationship, similar to Activity Streams https://www.w3.org/TR/activitystreams-vocabulary/#dfn-relationship; and also from NRP agent relationships, which are from some other standard models. Not to say it can't be revisited, we're on 0.1. :)

in https://www.w3.org/TR/activitystreams-vocabulary/#dfn-object the range of relationship is actually Object which is basically anything and in our broader context could be equivalent to owl:Thing, which is what I actually prefer. So my question is still valid :)

[fosterlynn]

we can extend the general relationship btw,

possible problem with that: agent relationship is almost always 2 way, this one basically defines a one way flow (although a relationship is certainly implied)

in https://www.w3.org/TR/activitystreams-vocabulary/#dfn-object the range of relationship is actually Object which is basically anything and in our broader context could be equivalent to owl:Thing, which is what I actually prefer. So my question is still valid :)

looks like it extends Object, maybe not any real difference to your point though? I think you said before, but I can't find it: what would you use for the vf:relationship besides basically a label and inverse label? and why do you think AS extend Object for as:relationship? (missing LOD knowledge on my part)

and, do you even want the vf:relationship on this new thing, or is your question more about the existing AgentRelationship? doesn't seem like we need it on the new thing so far....

[djodjoni]

agent relationship is almost always 2 way

"almost always" can make a difference :) , but even if it is always two way I dont see an issue, this is why we extend it to add some extra meaning, however reusing props.

in https://www.w3.org/TR/activitystreams-vocabulary/#dfn-object the range of relationship is actually Object which is basically anything and in our broader context could be equivalent to owl:Thing, which is what I actually prefer. So my question is still valid :)

sorry I meant https://www.w3.org/ns/activitystreams#relationship

and why do you think AS extend Object for as:relationship?

the range is Object

what would you use for the vf:relationship besides basically a label and inverse label

I would use as range anything(owl:Thing) and probably it will mostly get assigned with some kind of taxonomy identified from with many labels on many languages from wikidata for example. Anyway even if you use it for data values you don't need rdf:Property but xsd:sting for example.

and, do you even want the vf:relationship on this new thing,

why not, there it would be assigned to a narrower set of Resource Taxonomy

[fosterlynn]

"almost always" can make a difference :)

that is true! :) the one example I know that is one way is "follows" and I don't know if anyone would use that in an economic network really...

sorry I meant https://www.w3.org/ns/activitystreams#relationship

yeah I knew that :)

I would use as range anything(owl:Thing) and probably it will mostly get assigned with some kind of taxonomy identified from with many labels on many languages from wikidata for example.

I start to get you maybe.... You are saying that you would use the vf:relationship property for the resource cat/model stuff instead of the relationship label? Interesting, thinking....

[djodjoni]

You are saying that you would use the vf:relationship property for the resource cat/model stuff instead of the relationship label?

Yes. For me a simple label doesn't bring too much semantic value and I would like to put there actual thing/concept.