Action verbs model [was Event Types...] #63
Comments
I propose that
This short document talks about how OWL and SKOS can fit together https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html
Let's work it out based on some concrete example? How about our bi-weekly calls #110 through which we create resource(s) which we believe other people will value. |
|
Proposal: In order to not duplicate event/flow structures in recipes, plans, and actuals, we create a set of classes on the type level that can be referenced by anything needing to say what type of event/flow it is. Like commitments or events/flows or that part of the recipe. [Edited to use all "types"] '@context': https://w3id.org/valueflows/v1
'vf:FlowType':
'@type': owl:Class
'vf:InflowType':
'@type': owl:Class
'rdfs.subClassOf': vf:FlowType
'vf:OutflowType':
'@type': owl:Class
'rdfs.subClassOf': vf:FlowType
'vf:ConsumeType':
'@type': owl:Class
'rdfs.subClassOf': vf:InflowType
'vf:UseType':
'@type': owl:Class
'rdfs.subClassOf': vf:InflowType
'vf:CiteType':
'@type': owl:Class
'rdfs.subClassOf': vf:InflowType
'vf:AcceptType':
'@type': owl:Class
'rdfs.subClassOf': vf:InflowType
'vf:WorkType':
'@type': owl:Class
'rdfs.subClassOf': vf:InflowType
'vf:ProduceType':
'@type': owl:Class
'rdfs.subClassOf': vf:OutflowType
'vf:ImproveType':
'@type': owl:Class
'rdfs.subClassOf': vf:OutflowType
'vf:GiveType':
'@type': owl:Class
'rdfs.subClassOf': vf:InflowType
'vf:ReceiveType':
'@type': owl:Class
'rdfs.subClassOf': vf:OutflowTypeI'm missing some we have talked about, but this is most of them so far. |
|
@fosterlynn looks good. 👍 in case there's any doubt i'm of course in support of keeping the type object pattern alive as we explore into LOD land, i see it as a way to manage complexity without creating a new concept for every slightly different use case. (#113) |
|
In vf:Input and vf:Output definitions we see:
BTW I need to make PR to move it to parent class eg. vf:Flow Than we have your old diagram, where I see "InputType", "InputPlan" and "InputEvent" In your comment you define vf:FlowType as owl:Class and various sub classes, which don't have *Type suffix in their name.
I also assume that we discuss Input and Output of vf:Process and not try to use them on vf:Transfer. |
Yeah, I wasn't sure where to go on that one. So I compromised by inconsistency. Ok, not a good idea. 😞 I mean them to be all type classes, so that we can reference them from events, commitments, plans, recipe input and output types. So they aren't subclasses of say Event, because we would have to have the same structure on each level. I guess they should all be called XType. In fact I think I will edit that comment snippet thus so it is clear. (The names aren't that nice, but....) I'll get together an example of how they would be referenced too, coming in another comment.
Actually I was going to try to use that layer for both. But I don't need to. The advantage of using for both is then the value flow can include transfers and processes both in a seamless vocabulary. Which I realize you don't necessarily agree with. If we have different words to relate to vf:Process, than I would prefer Input and Output rather than Inflow and Outflow, since IPO is pretty standard, and that is Input/Output. |
|
Actually maybe I'm off base with the event/flow types in LOD, maybe they should just be verbs (properties). If we can make them be types that way. Can we? Or maybe this is where a suggestion by @elf-pavlik comes in (in chat somewhere) about referencing two classes to identify the @type of something, like [vf:Input, fv:Plan]??? |
|
I think we need to write some YAML / JSON-LD for our main use cases, than continue writing variants of those snippets and compare them side by side. I'll do it for Porridge preparation and will try to add Plan phase, cast intents for some ingredients and describe transactions where I acquire them. |
|
Based on our earlier gitter chat, I will write YAML example of porridge preparation process (Plan & Observation phases) with inputs and outputs. I will do it in I would like to emphasise here that we use term 'Event' in quite inconsistent way. On diagrams 'Event' only appears on 'Reality layer' (now under renaming Observation or Report). If someone refers to rea:Event please prefix it with rea: namespace to clarify intended use. |
|
rea namespace should be rea:EconomicEvent REA does not care about other types of events. |
|
But in general, an rea namespace might be a good idea. How would that best be implemented? I'll ping the REA gang and see if somebody can get on it. (Although my last query got no responses; I must be losing credibility...) We could use what we liked in vf, because we have made several tweaks to what would be "classical REA". |
|
I think we should see how the general object type pattern can look in RDF. What applies to EventType will most likely also apply to ResourceType, ProcessType, TransferType or AgentType. IMO we should all keep those two spec in mind when we discuss it: |
|
Similar snippet as in https://github.com/valueflows/resource/issues/14#issuecomment-219470547 '@context': https://w3id.org/valueflows/v1
'@graph':
- '@id': urn:uuid:ba3f6878-50c2-4698-aff0-f04a00cfd95f
'@type':
- vf:Process
- vf-x:Plan
'vf:consume':
'@id': urn:uuid:3b8e6950-df01-469b-a78c-f4a659f5a49a
'@type':
- vf:Resource
- vf-x:Plan
- prodont:Rolled_oats
'vf-x:amount':
'qudt:numericValue': 0.25
'qudt:unit': unit:Kilogram
'vf:create':
'@type':
- vf:Resource
- vf-x:Plan
- porodont:Porridge
- '@id': urn:uuid:be38a797-d984-4143-8812-85c6b9261e5b
'@type':
- vf:Request
'schema:eligibleRegion':
'@id': https://www.wikidata.org/entity/Q16978314
name: Mexio City
'vf-x:allocationOf':
'@id': urn:uuid:3b8e6950-df01-469b-a78c-f4a659f5a49a
'@type':
- vf:Resource
- vf-x:Plan
- prodont:Rolled_oats
'vf-x:amount':
'qudt:numericValue': 0.25
'qudt:unit': unit:Kilogram
'@reverse':
'vf:consume': urn:uuid:ba3f6878-50c2-4698-aff0-f04a00cfd95f
- '@id': urn:uuid:3b8e6950-df01-469b-a78c-f4a659f5a49a
'@type':
- vf:Transfer
'vf-x:rightsFor':
'@id': urn:uuid:cd812a85-49fd-40a4-9c0c-aef9113a6706
'@type':
- vf:Resource
- vf-x:Observation
- prodont:Rolled_oats
'vf-x:amount':
'qudt:numericValue': 0.25
'qudt:unit': unit:Kilogram
'@reverse':
'as:result': urn:uuid:be38a797-d984-4143-8812-85c6b9261e5bSince I can have resource in vf-x:Plan state/phase (or maybe earlier vf-x:Vision). I can use the same planned resource in Process and Request. Which enables relating Intent to a Process, and to other resources via its inputs/outputs Actually in this case I could use vf:consume as direct (binary) relation, I will write version with N-ary Relation later. |
I agree this would be really useful. 👍 Although I've been thinking that we can possibly treat AgentType and EventType differently. In fact we did treat AgentType differently. This is because there is a small set of types for these, and I think AgentType works well as subclasses of Agent. ProcessType, ResourceType, TransferType, ExchangeType I think will all be all over the map, and already include large taxonomies, especially for the first two. And they will continue to be added to - ResourceType and to large extent ProcessType because new things will be invented, and the others because people will continue to experiment with their operational processes and exchanges to create different modes for a new economy. EventType is a little harder to think about. It has a limited set, although people may think of a few others. I would be good with treating it as subclasses of EconomicEvent (ignore names, just know what I mean. Except for the repeated structure on the different layers. EventTypes are also different than AgentTypes because events are edges and agents are nodes. But in any case, looking at RDF implementation of any of these would be great! And would be transferable to at least some of the others. And would get us a long way to modeling recipes. |
|
In the recent yaml examples, I note that rea:EventType is basically vf:verb. I'm good with this being a property, not a class as I suggested above. I don't right now like the name "verb", seems pretty general for what we are trying to accomplish, and I think we will have a limited number with pre-defined behavior. On the other hand, I suppose new ones will occasionally arise from different people. Just still thinking aloud, not quite ready to close this issue, but feel like we are getting there. 😊 |
Currently I use property |
Can't think of why anyone would do that..... You asked though so you might have something in mind? |
|
Looking at UML in valueflows/valueflows#147 I notice there vf:resourceEffect Currently all verbs stay defined as rdfs:subPropertyOf vf:infolow and vf:outflow (which I think we should change to vf:input and vf:output to follow IPO model).
Having vf:WorkResource and vf:UsageResource we have 'time based resources' which processes actually consume and create. Do we need that vf:resourceEffect in addition to knowing if event represents input or output to the process? |
Inputs are not always consumed, I don't think. We might not have vf:use any more, not sure. We do have vf:cite for resources that are electronically stored, knowledge based, and therefore not consumable. We also have vf:accept, which does not consume the resource. And vf:improve which is an output but does not create the resource. That's why we have that vf:resourceEffect by type of event. Very handy to have it machine readable.
Done! Let's change the doc as we come upon these.
We'll have to figure that one out. Seems like if they are time scheduled, they get created and consumed; if not, there is no effect and not even a vf:Resource until actual observation layer event? In latter case, the vf:Resource is only defined by category and/or model I think? |
|
@fosterlynn could you clarify the rdfs:range of vf:resourceEffect ? Do you expect people to define new values? |
For knowledge resources incrementing and decrementing doesn't seem to make sense at all. We can't have knowledge units to count increments and decrements seem even less relevant. This behavior seems specific to that type of resource and not depending on a type of event.
Those two seem the only exception, but maybe we shouldn't try to fit that resource as input or output but relate it through the output service which that process created. I think we need to think more about vf:accept and vf:improve. |
In NRP, we have a bunch, but it is possible that it boils down to +, - =. Or, increment, decrement, no change. |
I think if a digital resource unit is Kb, or similar, then the knowledge resource unit is probably Each. One document or design or whatever. Knowledge resources can be created also. Knowledge resources can be on paper too, this whole concept probably needs more thought. And even the digital file could have a resource relationship of some kind, maybe vf:underlyingResource, between the digital file and the knowledge resource. And then there's art. Maybe we don't want to get too far into splitting out knowledge..... But in any case a knowledge resource can be created or cited. |
|
A new thought I had about vf:action (event type verbs). It seemed to me in NRP that we had a stable set of event types with data driven behavior (data but not user definable). And then I was OK with just having the verb without the data to define behavior, thinking we could do it in documentation and it would be OK. It seems to me now that we are thinking about new action verbs every day, based on new use cases and thought experiments. This leads me to wonder if we want to make event type user definable, i.e. create a class with the properties necessary to define all the needed behavior. I now don't have confidence that we can define everything people will want to do. |
In https://github.com/valueflows/valueflows/issues/157#issuecomment-245781928 I started capturing how different actions affect resources. I think we should make sure to clearly specify that for actions that we consider very common. When it comes to extending, everyone can define one's own extensions, which can include new actions and specify their effect on resources. We don't need to worry about defining everything that people will want to do. We may also look at process of how extensions can get included into future versions of VF core using constructs like http://meta.schema.org/supersededBy At the same time, if based on VF core set of actions that events can carry, you can come up with formalization for defining how all those different actions affect resources, of course we should investigate this direction. As I understand in NRP you only define how different actions affect quantity of the resource. In VF we already work with how various actions affect locations and start exploring resources combined of other resources (assemble & disassemble). When we broaden common focus again to 'Plan' layer we will again have some availability related effects based on 'allocations'. I guess VF equivalents of rea:Commitment will affect 'availability' of resources, I even notice vf:quantityAvailable in valueflows/resource which on 'Observation' layer may get affected by use actions (which ATM still stay out of common focus) and possibly assemble actions. Allocations of resources for processes and transfers very like will also affect vf:quanittyAvailable. |
|
Another possible data point is whether events relate to process or transfers, are inputs or outputs (and there may be some other nuances in there too). Also labels and inverse labels, and for different languages. |
|
I think we should discuss actions in context of both:
Seems like same actions will appear on both layers, another reason why I prefer to talk about different actions rather than 'event types' since we limit event to the observation layer.
If we define actions as instances of rdf:Property, those definitions would have labels and inverse labels in various languages. |
Definitely. In fact, all 3 layers.
Sure, I'm just using the name for short hand, and to indicate that it may be more of an n-ary thing, while vf:action is not n-ary. I'll try to stop. :) |
|
From gitter chat today, some discussion of this. Where we are at right now:
vf:consume, vf:produce, etc. (the verbs) would be instances of vf:Action. @elf-pavlik points out also that you can have properties of properties, which I hadn't realized. An example: https://github.com/solid/vocab/blob/master/solid-terms.ttl#L54. So if we want to define input/output, increment/decrement, or whatever else, we could do it that way. Cool! |
|
Additional from @elf-pavlik in gitter: on the other hand, i think people don't use other properties on instances of rdf:Property (and its subclasses) than rdfs:label and rdfs:range, rdfs:domain and rdfs:subPropertyOf which allow to infer knowledge based on RDFS reasoning https://www.w3.org/TR/rdf-schema/#ch_properties |
If we define verbs as properties, I think we could just rely on rdfs:subPropertyOf and define consume as sub of decrement, produce as sub of increment etc. This wouldn't require adding any special additional properties. @fosterlynn What do you think about changing in the title of that issue 'Event types' to 'Action verbs'. Since all three Event, Commitment and Intent would need to reference those 'Action verbs'. Currently we use on all three of them vf:action to reference the 'verb' of the action. |
fosterlynn
changed the title
Done! |
Let's try it out. Then for events that don't increment or decrement, what would we do? |
|
let's try quick hierarchy of properties, keeping in mind that each property can have more than one 'super' referenced with rdfs:subPropertyOf if needed
those which neither increment or decrement we simply don't mark as sub property |
|
I almost forgot about our discussions about 'time based stocks' https://github.com/valueflows/resource It may make bigger difference when we make commitments. When we make commitment for consume of 20kg potatoes out of 200kg. We know that we only have 180kg available (commitment decrements the availablity). When we commit to work for 2h, it also decrements our availability to work, so it also has certain decrements like implications. Similar for usage, If someone books flat for 3 days (commitment) its availability for given month decrements. |
Yes, in that case we may be decrementing someone's calendar, so to speak. Usage would be the same way. Even if there is not a strict calendar, there are limits to availability. I wonder if we can unify those 2 use cases (time-based resources that are managed on a calendar, with commitments, etc.; and time-based resources that are just logged without calendar management and without commitments.) Calendar is sort of stock-like; otherwise there is nothing to decrement. Hmmm. |
|
While usage of equipment and human labor share the feature that their availability can be represented on a calendar, I would not want to merge them. I would be afraid of losing the "peculiarities" of humans, which are important. |
I didn't mean merge usage and work. I meant merge work that is planned on a calendar and work that is just done, nothing to decrement. |
|
maybe
We had some discussions about 'start work/use' & 'end work/use' events which could allow tracking when resources/people stay blocked/occupied. load & unload / accept & improve seem related in this sense...
As for 'planned work' we can represent that with intents & commitments i guess? |
|
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
If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there. |
I have been lately representing event types as subclasses of event. Like here and here. (Also been trying out calling an Economic Event a Value Flow, so consider those equivalent names for this discussion, and we'll work on the naming separately.)
As I knew at one point but forgot, and was reminded by @bhaugen , that works fine if you are only talking about the "actually happened" layer. But then you need the same concept at both "recipe" and "plan" layers. Event types define within the recipe what types of events will occur; and commitments on the plan layer also refer to an event type. So now if you use subclasses, you have 3 parallel layers that basically define the subclass same structure for different things. Ouch.
In our software, we have a class called EventType that stores all the event types and all events, commitments, and recipe parts know their event type.
There are a limited number of them, and they are well defined.
Is there any other alternative? Could we define the subclass structure on the recipe layer and just refer to those classes to define the behavior?
Opinions? Especially how would one naturally think about it is LOD / RDF land?
The text was updated successfully, but these errors were encountered: