There's a game, aimed to train imagination, where a player should say, which attributes cannot be applied to an object. E.g. a crocodile - can it be "glassy"? When building relationships between entities, it makes sense to also define the probability of the relationship, which can be "always", "never" and "maybe".
I did read that article and I am talking about a different thing - mandatory/optional/excluded(impossible) attributes (or relations). While you can use probabilities for what I am talking about, this is really something different. A probability term per se (in its strict definition) can be applicable to *repeating* events, not to facts or static relations. For the latter, one can determine, how frequently the relation can be observed within a class of entities, but that's not "probability" and it doesn't need to be estimated - it is calculated based on facts and observations. Such frequency applies to optional attributes or relations. Mandatory (or impossible) attributes not describe but define entities - with a mandatory or excluded attribute, one defines the organic properties of an entity. If the mandatory attribute is not present (or an excluded attribute is present), then an object doesn't belong to the class, i.e. is not a specific entity. So, I am not saying that probabilities in the way you define them are useless, but they are different.
Thank you, now I understand. What you describe is quite similar to what we use, but implemented in a different way. All presented relations means "always", lack of relation means "never", and "object -- maybe --> sign" implemented by introduced additional anonymous concept "(maybe sign)": "object --> (maybe sign)".
Such an approach allows arbitrary relations like "(highly likely)", "(very unlikely)" and so on; any kind of relationship can be added without changing source code.
Indeed, likeliness of a relationship is a good feature which I omitted for simplicity (as it can lead to lots of complication). At the same time, "never" (exclusion) and "lack of relation" seem to be two different things to me. To illustrate what bothers me here, let me refer to the soviet "struggle for peace" concept. It's an oxymoron, of course, but it illustrates the importance of "never" -- if there's a struggle (or war), there can never be peace. We have either peace or war but not both. Why this is important - if we see a relationship that is explicitly marked as "never", not only we need to bypass/skip it, but we need to pay attention and question our knowledge - either our knowledge of the relation is wrong or what we see is misclassified (which is more likely). Another good example - the probability to meet a dinosaur on the street is 0.5 (you either meet one or you don't). But if you do meet one, you need to question both your perception and your knowledge about reality. Hope, you see the application of the explicit "never" state from this.
When "never" is useful, it can be represented as referred above for "maybe":
something --> ( never XYZ );
This is the beauty of our approach: any relationship can be included without changing the code. Of course, it assumes also adding related rules for processing such relations.
There's a game, aimed to train imagination, where a player should say, which attributes cannot be applied to an object. E.g. a crocodile - can it be "glassy"? When building relationships between entities, it makes sense to also define the probability of the relationship, which can be "always", "never" and "maybe".
The usefulness of assigning a probability to every relation is a disputable thing.
Take a look:
https://agieng.substack.com/p/probability-in-decision-making
I did read that article and I am talking about a different thing - mandatory/optional/excluded(impossible) attributes (or relations). While you can use probabilities for what I am talking about, this is really something different. A probability term per se (in its strict definition) can be applicable to *repeating* events, not to facts or static relations. For the latter, one can determine, how frequently the relation can be observed within a class of entities, but that's not "probability" and it doesn't need to be estimated - it is calculated based on facts and observations. Such frequency applies to optional attributes or relations. Mandatory (or impossible) attributes not describe but define entities - with a mandatory or excluded attribute, one defines the organic properties of an entity. If the mandatory attribute is not present (or an excluded attribute is present), then an object doesn't belong to the class, i.e. is not a specific entity. So, I am not saying that probabilities in the way you define them are useless, but they are different.
Thank you, now I understand. What you describe is quite similar to what we use, but implemented in a different way. All presented relations means "always", lack of relation means "never", and "object -- maybe --> sign" implemented by introduced additional anonymous concept "(maybe sign)": "object --> (maybe sign)".
Such an approach allows arbitrary relations like "(highly likely)", "(very unlikely)" and so on; any kind of relationship can be added without changing source code.
Indeed, likeliness of a relationship is a good feature which I omitted for simplicity (as it can lead to lots of complication). At the same time, "never" (exclusion) and "lack of relation" seem to be two different things to me. To illustrate what bothers me here, let me refer to the soviet "struggle for peace" concept. It's an oxymoron, of course, but it illustrates the importance of "never" -- if there's a struggle (or war), there can never be peace. We have either peace or war but not both. Why this is important - if we see a relationship that is explicitly marked as "never", not only we need to bypass/skip it, but we need to pay attention and question our knowledge - either our knowledge of the relation is wrong or what we see is misclassified (which is more likely). Another good example - the probability to meet a dinosaur on the street is 0.5 (you either meet one or you don't). But if you do meet one, you need to question both your perception and your knowledge about reality. Hope, you see the application of the explicit "never" state from this.
When "never" is useful, it can be represented as referred above for "maybe":
something --> ( never XYZ );
This is the beauty of our approach: any relationship can be included without changing the code. Of course, it assumes also adding related rules for processing such relations.