-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
subconcepts is now recursive #482
subconcepts is now recursive #482
Conversation
…lass hierarchy of the given class
test_example_concept_learning_neural_evaluation.py seems to have problems with the way we compute the subconcepts. |
This can happen because a neural network assigns scores to all possible entities e.i. every subject or object found in a triple |
should we check than if the current subconcept is in the classes in signature? |
that seems to fix the issue i.e. def subconcepts(self, named_concept: OWLClass) -> List[OWLClass]:
all_subconcepts = []
for subconcept in self.direct_subconcepts(named_concept):
if subconcept not in self.classes_in_signature():
return []
all_subconcepts.append(subconcept)
all_subconcepts.extend(self.subconcepts(subconcept))
return all_subconcepts |
Yes we can do it. Yet, this checking would increase the runtimes. Therefore, please add comments in the code indicating the importance of such checking |
now it would be better to have the classes in signature as a set for avg. O(1) runtime for this check 🤔 |
Absolutely. This should be a to-do for the next next release:) |
somehow this failed again but locally it did not :/ |
Please disable all_subconcepts for the time being. If the disabling doesn't solve it, I will take a look at it. |
I re-ran the checks and weirdly now everything passed locally i ran pytest like 20 times and never had a fail |
subconcepts is now recursive to retrieve subconcepts from the whole class hierarchy