Skip to content

Upgrade measures command to work with OWLAPI 5.5.1 - #1298

Open
matentzn wants to merge 5 commits into
v2from
v2-measures
Open

matentzn wants to merge 5 commits into
v2from
v2-measures

Conversation

@matentzn

Copy link
Copy Markdown
Contributor

robot measure --metrics all crashed on the OWLAPI 5 branch (#1295), and once it ran, some metrics came out wrong. This fixes the crash, un-ignores MeasureOperationTest, and updates docs/examples/metrics_all.json. Each value change in that file is in its own commit, with the reason in the message.

  • Cycle detector NPE. OWLAPI 5 rejects an empty ObjectIntersectionOf, which the cycle detector built for undefined classes. It now collects the class signature directly.
  • gci_hidden_count. OWLAPI 5's HiddenGCICount checks for subclasses instead of superclasses, which gives 43 instead of 105 on the example. I ported the OWLAPI 4 logic, so the value stays at 105. This also brings --metrics all on the example from ~5 min down to ~3 s.
  • most_freq_concept. An existing bug: counts were stored and looked up under different keys, so they were never summed. Fixed; the example now reports UBERON_0000922 instead of UBERON_0007530, an artifact of axiom order.
  • Datatype counts. No code change. OWLAPI 5 includes the datatype of an annotation assertion's own literal value in the axiom signature, which OWLAPI 4 did not. XSD_STRING goes from 751 to 3720, XSD_ANY_URI: 7 is new, and the xsd namespace count goes from 751 to 3727.
  • Key order. SymmetricObjectProperty and rdfs move one position because OWLAPI 5 iterates sets in a different order. No values change.

OntologyCycleDetector built an ObjectIntersectionOf over a class's
definitions only to read its class signature. For a class with no
definition the operand set is empty: OWLAPI 4 accepted that, OWLAPI 5
throws "operands cannot be null or empty", which crashed every
`measure --metrics all` / `all-reasoner` run.

Collect the signature directly from the definition expressions instead.
Re-enable MeasureOperationTest, which was ignored because of this crash.
A hidden GCI is a class with an equivalent class axiom and a subclass
axiom in which it is the subclass. OWLAPI 4's HiddenGCICount checked
getSubClassAxiomsForSubClass(cls). OWLAPI 5's version checks
EntitySearcher.getSubClasses(cls), i.e. whether the class has
*children*, which is a different metric: on uberon_fragment.owl it
drops gci_hidden_count from 105 to 43.

Port the OWLAPI 4 logic into OntologyMetrics. gci_hidden_count in
docs/examples/metrics_all.json stays at 105 (unchanged from OWLAPI 4).
This also brings `measure --metrics all` on that file from ~5 min back
to a few seconds; the OWLAPI 5 metric scans the ontology per class.
getMostFrequentlyUsedClassInLogicalAxioms looked up counts under
eachClass.toString() ("<IRI>") but stored them under the bare IRI, so
the lookup never matched and each class's count was overwritten by its
last per-axiom frequency instead of accumulated. The reported class was
therefore an artifact of axiom iteration order, which OWLAPI 5 changed.

Use the bare IRI for both lookup and store. On uberon_fragment.owl
most_freq_concept(_incl) changes from UBERON_0007530 (artifact of the
bug) to UBERON_0000922 (embryo), the class with the highest summed
count.
No code change. datatypes_axiom_count counts axioms whose
getDatatypesInSignature() contains each datatype. All hits on
uberon_fragment.owl are AnnotationAssertion axioms (no logical axiom
uses a datatype).

OWLAPI 4 omitted the datatype of an annotation assertion's own literal
value and only reported datatypes of literals nested in axiom
annotations: only 751 of the 3720 assertions involving xsd:string were
counted (e.g. 79 of 1616 hasDbXref), and none of the 7 xsd:anyURI
rdfs:seeAlso values. OWLAPI 5 reports every literal's datatype.

- datatypes_axiom_count(_incl): XSD_STRING 751 -> 3720, new XSD_ANY_URI 7
- namespace_axiom_count(_incl): xsd 751 -> 3727 (3720 + 7)
No value changes. SymmetricObjectProperty (axiom type lists and counts)
and rdfs (prefix and namespace maps) move one position because OWLAPI 5
iterates these hash-based collections in a different order. Output is
deterministic across runs; CommandLineIT compares JSON byte-for-byte.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant