Remove duplicate OBO relationship annotations (keep treeView) - #39
Open
matthewhorridge wants to merge 2 commits into
Open
Remove duplicate OBO relationship annotations (keep treeView)#39matthewhorridge wants to merge 2 commits into
matthewhorridge wants to merge 2 commits into
Conversation
generateGroundTriplesForAxioms only recognised the flat shape SubClassOf(A, someValuesFrom(p, B)) and only for a hard-coded set of OBO properties (part_of, contains, develops_from and their IRIs), gated on the property IRI containing "obo". Relationships on any other property — e.g. EDAM's has_topic/has_output/has_input — were silently dropped, which is why some relationships appear in the class Details view and others do not. Add generateRelationshipTriples, which visits the class expression of every SubClassOf and EquivalentClasses axiom of a named class (RelationshipVisitor, an OWLClassExpressionVisitorAdapter) and emits a relationship triple (subject --p--> filler, under the property's own IRI) for every someValuesFrom, hasValue, and min/exact cardinality (n >= 1). Intersection operands are traversed, both in the superclass expression and in a restriction's filler, so SubClassOf(A, p some (B and C)) yields A p B and A p C, and relationships stated via equivalences are extracted too. Unions, complements and allValuesFrom are not traversed/emitted (not entailed for every instance). This is additive: the existing OBO treeView/hierarchy emission is left unchanged, so the class tree is unaffected; the Details view now shows the full set of relationships. Verified on EDAM and UBERON, and with a fixture covering each shape.
generateGroundTriplesForAxioms emitted, for the whitelisted OBO properties, a metadata/obo/part_of|contains|develops_from annotation and a treeView edge, plus a generic annotation (under the property's own IRI) for any other obo-namespace property. Now that generateRelationshipTriples emits every relationship under the property's own IRI, the metadata/obo/* annotations and the generic branch are redundant: a part_of relationship appeared twice in a class's property listing (once as obo/part_of, once as its own IRI). Keep only the treeView edges, which drive the OBO class hierarchy (OntologyFormat#tree_property), with their existing per-property direction (part_of/develops_from: subclass -> filler; contains: filler -> subclass). The relationships themselves are now emitted once, uniformly, by generateRelationshipTriples. Since the method now only produces treeView edges, rename it generateGroundTriplesForAxioms -> generateTreeViewEdges. The metadata/obo/* relationship predicates have no production consumer in ontologies_linked_data, ontologies_api or bioportal_web_ui; the only reference is the ontologies_linked_data test test_obo_part_of, which asserts obo/part_of and must be updated to match (assert the relationship under the property's own IRI; the treeView assertion is unchanged).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #37. Please review/merge #37 first — this branch is stacked on it (its base is #37's branch, so the diff here is only the de-duplication change).
What
Removes the duplicate OBO relationship annotations left over now that #37 emits every relationship under the property's own IRI.
Before #37,
generateGroundTriplesForAxiomsemitted, for the whitelisted OBO properties, ametadata/obo/part_of|obo/contains|obo/develops_fromannotation plus atreeViewedge, and a generic annotation (under the property's own IRI) for any other obo-namespace property. With #37, the relationship is already emitted under the property's own IRI for every property, so thosemetadata/obo/*annotations and the generic branch are redundant — apart_ofrelationship appeared twice in a class's property listing (once asobo/part_of, once asBFO_0000050).Change
Keep only the
treeViewedges (which drive the OBO class hierarchy,OntologyFormat#tree_property), with their existing per-property direction:part_of/develops_from(and IRIs):treeViewsubclass → fillercontains(and IRI):treeViewfiller → subclassThe relationships themselves are now emitted once, uniformly, by
generateRelationshipTriples. Since the method now only produces treeView edges, it is renamedgenerateGroundTriplesForAxioms→generateTreeViewEdges.Verified on ENVO:
treeViewedges unchanged,metadata/obo/part_ofannotations drop to 0, and eachpart_ofrelationship still present once under its own IRI (BFO_0000050). Full wrapper test suite green (48 tests).Coordinated change required (separate PR)
The
metadata/obo/*relationship predicates have no production consumer inontologies_linked_data,ontologies_api, orbioportal_web_ui. The only reference is theontologies_linked_datatesttest_obo_part_of(test/models/test_ontology_submission.rb), which assertsmetadata/obo/part_offorTAO_0001044 → TAO_0000732. That test must be updated to assert the relationship under the property's own IRI instead; thetreeViewassertion in the same test is unchanged. This will be done as a separate PR againstontologies_linked_data, verified against its (triplestore-backed) test environment.