Core vf model

[fosterlynn]

This is to help us converge on a "final" core model for vf. I think we have worked out most of the core issues (probably not all - will post one on processes and agents). Note that a lot of the names are very much up in the air, so nobody should take offense at my names, trying to represent how it works in the core model. This issue can help resolve names as well as see if we are close on the core model.

Will post pictures.....

[fosterlynn]

First picture, an attempt at a UML diagram. It is right now a bit mixed on object vs data focus, and possibly confusing because sometimes the arrows' direction and names sometimes conflict, I'm thinking.... In any case, it is meant to be something that can be implemented for a VF vocabulary that could be but is not necessarily LOD based. So, there are elements that won't necessarily be in the LOD version. (Note: not yet at any pull request stage.)

[fosterlynn]

OK, another version of the UML above, but focused on relational persistent data structures. Resolved arrow directions vs names, I think, although now I have names that probably won't appear in LOD land.

[fosterlynn]

And a version more focused on the OO perspective:

OK, enough of that fun.... next a VOWL picture (gulp!).

[elf-pavlik]

Thank you @fosterlynn !

Can you imagine making PR to valueflows/process which explains in .md file implications of vf:context relationship? I also see that both vf:Process and vf:EconomicEvent can relate to foaf:Agent via vf:context, example of events having different 'context agent' than the process could help with clarifying it.

[fosterlynn]

example of events having different 'context agent' than the process could help with clarifying it.

That is more because events (although process-type events) do not always have a process. I don't think events would have a different context agent than the process.

[fosterlynn]

Done - to valueflows repo since it covers more than process. Diagram next.

[elf-pavlik]

vf:EconomicEvent recommends use of property vf:eventQuantity, it seems to me that we talk more about vf:resourceQuantity. The event references that resource (I would say stock) and does some action on certain quantity of that resource(stock). If we have for example 'vf:action': vf:consume we can think of it "This event consumed a quantity of that resource(stock)"

[bhaugen]

@elf-pavlik:

it seems to me that we talk more about vf:resourceQuantity

I certainly don't talk that way. It's an event, not a resource. The event may affect a resource, but it is not a resource, and there is no resource that is living on the event.

Moreover, how would that deal with events which are not measured in a quantity that could be interpreted as a quantity of a resource: citations, for example, where the event quantity is a percentage of the value of the other inputs to the process?

[fosterlynn]

Actually in rea, the event is primary in general - it's the movement, the flow, it's what's happening economically. You can derive the resource from event history if you want, at any point in time.

[elf-pavlik]

Moreover, how would that deal with events which are not measured in a quantity that could be interpreted as a quantity of a resource: citations, for example, where the event quantity is a percentage of the value of the other inputs to the process?

Why in NRP you only allow cite inputs to have '% share of the output' assigned but not consume or work and other input events? I consider mentioned use of 'quantity' as 'data model smell', possibly result of inflexibility of relational databases. IMO such 'cite' event or any other input event should use dedicated property for such specific 'value equation' purpose e.g nrp:agreedShareOfOutput.

[bhaugen]

Why in NRP you only allow cite inputs to have '% share of the output' assigned but not consume or work and other input events?

That's the only case where anybody has wanted anything like that. Citations and the percentage option arose from a long discussion between us, Sensorica, and Enspiral about how to treat intellectual resources. The exemplar was academic citations. The percentage idea came from Enspiral.

Consume, work and other input events already get a percentage of the income distributed to that process based on their natural quantities. Citations do not have a natural quantity. So the options for valuing them include both percentage of the value of the other inputs as well as a direct quantity of the unit of value of the value equation, which in Sensorica is always money, but does not need to be logically in NRP or VF.

I consider mentioned use of 'quantity' as 'data model smell', possibly result of inflexibility of relational databases.

That could very well be.

[fosterlynn]

Closing, we have specific issues for anything left in this one.