valueflows merge requestshttps://lab.allmende.io/valueflows/valueflows/-/merge_requests2023-12-18T20:33:25Zhttps://lab.allmende.io/valueflows/valueflows/-/merge_requests/730Inverse and M:M relationships more RDF friendly2023-12-18T20:33:25ZLynn FosterInverse and M:M relationships more RDF friendly(This mostly relates to issue #701. It has come up concretely in working on extending ActivityPub with VF in order to standardize how VF could work in the fediverse. I still need to verify with @pospi that these changes will also be be...(This mostly relates to issue #701. It has come up concretely in working on extending ActivityPub with VF in order to standardize how VF could work in the fediverse. I still need to verify with @pospi that these changes will also be better or at least not mess up the holochain/graphql work - but I'll create a better doc than this one for that.)
Inverses were added to the relationships that have come up as needed.
M:M relationships where there are no attributes involved (not reified) were changed to 1:M from the direction they would be most often used.
`reciprocal` in ProposedIntent was made into a relationship in order to not have to account for it as an attribute.
`inScopeOf` range was changed to vf:Agent, to simplify the inverse relationship, as well as simplify scoping in general. Since we have added EcologicalAgent to the model, I think that will cover the original stated desire for a more broad `inScopeOf`. (Issue #583)
Note this MR is not complete, we may want to add a directional change to M:M relationships with attributes. I'll remove the "draft" when it is ready.
@elf-pavlik you might be interested in the `inScopeOf` change, I'd like to know if that seems OK with you. :blush: If you decide to take a look, I'd also be interested in your RDF perspective on all of it!1.0.0Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/merge_requests/693Draft: Add resourceContainedIn2022-08-29T18:40:37ZLynn FosterDraft: Add resourceContainedInIn order to not require backend code to understand a whole process with its `produce` event, when creating each `combine` event, we propose creating a new property on EconomicEvent that will explicitly tell the backend what resource to c...In order to not require backend code to understand a whole process with its `produce` event, when creating each `combine` event, we propose creating a new property on EconomicEvent that will explicitly tell the backend what resource to combine into. Calling it `resourceContainedIn`, thanks for that suggestion @srfsh . (We will expect UI/UX code to manage that more complex state to get the produced resource to become the `containedIn` resource for the `resourceInventoriedAs` on the event being created.)
cc @pospi
This can stay Draft until I also create a MR for the vfgraphql spec, and we've had a chance to talk about it as needed.1.0.0Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/merge_requests/668WIP: Add environmental agent2023-01-24T20:31:32ZLynn FosterWIP: Add environmental agentThis comes from some recent discussions on how to use REA for ecological accounting. This has become important as climate change becomes more extreme and urgent. REA (and Valueflows) works very well for this purpose, with a few expansi...This comes from some recent discussions on how to use REA for ecological accounting. This has become important as climate change becomes more extreme and urgent. REA (and Valueflows) works very well for this purpose, with a few expansions of concepts.
This is a placeholder for discussion inside of Valueflows while these external discussions continue.1.0.0Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/merge_requests/651Replaces hy-phens with camelCasing in identifiers2022-07-13T15:11:51ZRobin VobrubaReplaces hy-phens with camelCasing in identifiersIf nobody is using the ontology yet, this should be no problem. otherwise... it needs though.
one alternative would be, to keep them both, and have on just reference the other (with `subPropertyOf`).If nobody is using the ontology yet, this should be no problem. otherwise... it needs though.
one alternative would be, to keep them both, and have on just reference the other (with `subPropertyOf`).1.0.0Lynn FosterLynn Fosterhttps://lab.allmende.io/valueflows/valueflows/-/merge_requests/622Discussion PR: remove `vf:notApplicable` and `vf:PairsWith` in owl schema2022-07-13T15:23:51ZAndrewDiscussion PR: remove `vf:notApplicable` and `vf:PairsWith` in owl schemaHi! After [this pr](https://github.com/valueflows/valueflows/pull/619) and the [included discussion](https://github.com/valueflows/valueflows/issues/615#issuecomment-613091091) I started working with the vf model more (converting to rust...Hi! After [this pr](https://github.com/valueflows/valueflows/pull/619) and the [included discussion](https://github.com/valueflows/valueflows/issues/615#issuecomment-613091091) I started working with the vf model more (converting to rust) and realized something I'd like to bring up for discussion. Keep in mind, these modifications took all of 30s to make, so if ultimately the decision is made to reject this PR I will not be hurt at all.
Effectively I think it makes sense to remove `vf:notApplicable` and `vf:PairsWith`. When converting the rdf spec into rust, I ran into issues where essentially I was hardcoding logic like "if this contains `vf:notApplicable` then the type should be able to return NULL (`None` in rust)" and "if we encounter `vf:PairsWith` ignore it entirely because in reality it's a subset of `vf:Action` which is already defined."
Once logic like this starts sneaking, my first instinct is to ask "am I doing something wrong?"
Then I realized a way this could be done without hardcoding. Remove all instances of `vf:notApplicable`:
```ttl
vf:transfer-custody a owl:NamedIndividual ,
vf:Action ;
vf:inputOutput vf:notApplicable ;
vf:pairsWith vf:notApplicable ;
vf:resourceEffect vf:decrementIncrement ;
rdfs:comment "Give physical custody and control of a resource, without full accounting or ownership rights." ;
rdfs:label "transfer-custody" ;
vs:term_status "unstable" .
vf:use a owl:NamedIndividual ,
vf:Action ;
vf:inputOutput vf:input ;
vf:pairsWith vf:notApplicable ;
vf:resourceEffect vf:noEffect ;
rdfs:comment "For example a tool used in process; after the process, the tool still exists." ;
rdfs:label "use" ;
vs:term_status "unstable" .
```
becomes
```ttl
vf:transfer-custody a owl:NamedIndividual ,
vf:Action ;
vf:resourceEffect vf:decrementIncrement ;
rdfs:comment "Give physical custody and control of a resource, without full accounting or ownership rights." ;
rdfs:label "transfer-custody" ;
vs:term_status "unstable" .
vf:use a owl:NamedIndividual ,
vf:Action ;
vf:inputOutput vf:input ;
vf:resourceEffect vf:noEffect ;
rdfs:comment "For example a tool used in process; after the process, the tool still exists." ;
rdfs:label "use" ;
vs:term_status "unstable" .
```
Given that the `ObjectProperties` for `vf:pairsWith` and `vf:inputOutput` are defined on the enum, the implementor can now say `Action::TransferCustody` should be able to return a `pairs_with()` or `input_output()` value *but they are not defined in all cases* therefor it makes sense to allow the return types to be nullable (which is effectively what the hardcoded `vf:notApplicable` logic was doing anyway).
By extension, if `vf:notApplicable` becomes redundant, `vf:PairsWith` outlives its usefulness as well (since it only exists to union `vf:notApplicable` with a subset of `vf:Action`).
The only part that I don't know is if this is idiomatic owl/rdf/etc or if this would hurt the undertanding of others trying to parse the schema. If you define an `ObjectProperty` on an enum value, is it "ok" for the enum values to not return a value for that property?
Hopefully this all makes sense, I can expand further if needed, and like I said, want this to be more of a discussion. I thought a PR instead of an issue might be appropriate since I know exactly what change I'm envisioning.
Thanks!1.0.0Lynn FosterLynn Foster