Closed bgyori closed 4 years ago
Good point... I think what you're doing is a good solution for now. Ideally, this should be solved through multiple inheritance, to guarantee that these nodes are unique, and they simply have multiple parents. Otherwise, we may end up with different exemplars in each copy, which may result in incoherent grounding situations...
What do others think?
@bgyori , to clarify what you are thinking of. As example, here are the 2 trees of environmental
wm/concept/causal_factor/environmental
- environmental:
- meteorologic:
- weather
- climate
- precipitation:
- rainfall
- storm
- temperature # temperature of ...
- environment
- climate_change_mitigation
- resource_management
- forestry
- natural_resources:
- ...
- pollution:
- ...
wm/concept/causal_factor/crisis_and_disaster/environmental
- environmental:
- crop_failure
- insect_infestation
- natural_disaster:
- flooding
- ...
- weather_issue:
- cold_temperature
- fire # what is on fire?
Do you mean that upon assembly, things might look like the following?
wm/concept/causal_factor/environmental
- environmental:
- meteorologic:
- weather
- climate
- precipitation:
- rainfall
- storm
- temperature # temperature of ...
- environment
- climate_change_mitigation
- resource_management
- forestry
- natural_resources:
- ...
- pollution:
- ...
- crop_failure
- insect_infestation
- natural_disaster:
- flooding
- ...
- weather_issue:
- cold_temperature
- fire # what is on fire?
I.e. the sub-nodes will still be kept.
You don't actually mean that all the sub-nodes under wm/concept/causal_factor/environmental
and wm/concept/causal_factor/environmental
will be collapsed to just the coarse-grained environmental
right?
And yes, certain branches should not be mixed: (causal_factor, entity, time) should not be mixed together. Because causal_factor are events/situations. While entity are Person/Organization, etc. And time is just time.
I'm also thinking that the intervention
branch should not be mixed with other branches. E.g. do not mix the following two. Interventions are usually provision of something:
Right, the sub-nodes wouldn't be collapsed. So based on @chanys's logic, we would have the following rules:
wm/concept/causal_factor/access/infrastructure
wm/concept/causal_factor/intervention/infrastructure
-> not equal because one is an intervention and the other is not
wm/concept/causal_factor/condition/food_security
wm/concept/causal_factor/intervention/provision_of_goods_and_services/food_security
-> not equal because one is an intervention and the other is not
wm/concept/causal_factor/social_and_political/educational/education
wm/concept/causal_factor/intervention/provision_of_goods_and_services/education
-> not equal because one is an intervention and the other is not
wm/concept/causal_factor/crisis_and_disaster/environmental
wm/concept/causal_factor/environmental
-> not equal because neither of these are leaf nodes
wm/concept/causal_factor/intervention/institutional_support/protection
wm/concept/causal_factor/intervention/provision_of_goods_and_services/protection
-> not equal because neither of these are leaf nodes
wm/concept/causal_factor/social_and_political/person_and_group
wm/concept/entity/person_and_group
-> not equal because one is a causal_factor and the other is an entity
wm/concept/causal_factor/environmental/natural_resources/water_management
wm/concept/causal_factor/food_water_and_nutrition/water_management
-> equivalent, since none of the other special cases apply
Does this sound right?
This is mostly superfluous, but perhaps for full disclosure...
At one point, but not now, the grounding procedure in Eidos made use of the words contained in the full path to the ontology leaf node so that the examples below might have matched differently. Some ways of combining the nodes would prevent the distinction from ever being used.
wm/concept/causal_factor/social_and_political/person_and_group
wm/concept/entity/person_and_group
Thanks @bgyori , for the clarification that the sub-nodes wouldn't be collapsed.
I'm not particularly concerned with whether they are leaf nodes or not.
So I think the following could be combined upon assembly:
Similarly, I think the following could be combined upon assembly:
And as you mentioned, the following can be combined upon assembly:
Before lots of hoops are jumped through -- are we maintaining the distinction because we truly believe there is a difference? i.e. -- should we combine:
Or just rename to :
?
On Tue, Oct 8, 2019 at 8:42 AM chanys notifications@github.com wrote:
Thanks @bgyori https://github.com/bgyori , for the clarification that the sub-nodes wouldn't be collapsed.
I'm not particularly concerned with whether they are leaf nodes or not.
So I think the following could be combined upon assembly:
- wm/concept/causal_factor/crisis_and_disaster/environmental
- wm/concept/causal_factor/environmental
Similarly, I think the following could be combined upon assembly:
- wm/concept/causal_factor/intervention/institutional_support/protection
wm/concept/causal_factor/intervention/provision_of_goods_and_services/protection
And as you mentioned, the following can be combined upon assembly:
- wm/concept/causal_factor/environmental/natural_resources/water_management
- wm/concept/causal_factor/food_water_and_nutrition/water_management
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/WorldModelers/Ontologies/issues/31?email_source=notifications&email_token=ABJCPCJKCX7Z77TYUYTWIJ3QNSS53A5CNFSM4I6OIC72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAUUFNA#issuecomment-539574964, or mute the thread https://github.com/notifications/unsubscribe-auth/ABJCPCMZTW5HIO7IU23G3YTQNSS53ANCNFSM4I6OIC7Q .
I'm in favor of renaming wherever that makes sense since then the distinction is obvious.
@BeckySharp , I've renamed/removed where necessary based on this thread's discussions and the duplicate list identified by @bgyori . so that all those have unique names. Please check and approve https://github.com/WorldModelers/Ontologies/pull/32
I confirmed that there are no duplicates left in the latest ontology version. If any do re-appear in the future, INDRA will consider them to be equivalent by default.
Many of the concepts that appeared under multiple branches of the ontology (aka duplicates) were removed in #27. There are still some remaining, and I was wondering if we should still follow the approach we have taken until now, which is that irrespective of the branch of the ontology under which it appears, a concept will be considered to be the same, and further, one of the two will be normalized out and replaced by the other upon assembly. For the sake of example, all instances of wm/concept/causal_factor/intervention/provision_of_goods_and_services/food_security will be considered to be the same as and normalized to wm/concept/causal_factor/condition/food_security upon assembly. Is there any issue with continuing to do this? Are there specific duplicates that we should not do this for?
Here is the current list for reference: