OpenGALEN used with the CB-reasoner

Angus Roberts

I successfully loaded the OpenGALEN8 componentised version into a custom build of Protégé 4.1 using 1Gb for Java heap. There are two missing import references to modules in the posted versions which were not difficult to resolve manually. I then was able to save the ontology in OWL 2 functional style syntax, both as a componentised version and as a single ontology.

OpenGALEN response: Thanks for the confirmation that the files can be loaded. We will correct the import reference errors you report and post revised files.

CLASSIFICATION

The output ontology in OWL 2 functional-style syhttp://web.archive.org/web/20160711021122/http://code.google.com/p/cb-reasoner/ntax could be successfully classified using the CB reasoner in about one minute and about 500MB RAM when object property chain inclusions axioms are commented out. The resulting taxonomy consists of around 200,000 direct subsumptions and equivalences. Interestingly, the DB reasoner found around 700 direct subsumptions not found by the structural classifier (listed in the hierarchy dump files), but also appeared not to find a few subsumptions that the structural classifier did find.

ISSUES

    • The hierarchy dump files bundled with the ontology (derived from a structural classifier) do not list only direct parent-child relationships in the inferred hierarchy, but also some indirect ancestor-descendent ones. It would be easier to compare the results if the hierarchy would be transitively reduced by removing all the indirectly inferable ancestor-descendent relationships, and possibly alphabetically sorted.

OpenGALEN response: We will look into this.

    • The set of classes mentioned in the ontology sources includes many auxillary/artefact classes – usually recognisable by having very long names containing the ‘which’ keyword – but most do not appear at all in the hierarchy dump files. Therefore, identifying subsumptions found by a DL reasoner and not reported in the hierarchy dump files requires these classes to be stripped out of any result set before a comparison can be performed. It would be useful if these auxiliary classes were marked more clearly so that they can be distinguished from ordinary classes by the reasoner. Prefixing every auxiliary class with something line “_” would be one solution to this problem.

OpenGALEN response: Many of these auxillary classes are required artefacts created when GRAIL sanctioning statements in the ontology sources are re-expressed within OWL2, though some are also artefacts of the structural classifier. The sanction-related artefacts are never seen by the structural classifier, and so don’t appear in the hierarchy dumps. We have no practical solution to offer for this, other than ignoring inferred relations involving classes with such names, as you suggest.

  • The componentised ontology appears to provide an interesting test case to explore issues of modular ontology development and distributed ontology reasoning algorithms.
  • A few chain inclusion axioms, namely of the form (R o R => R) can be converted to transitivity axioms. But this causes problems because some of the transitive object properties turned out to be functional or inverse functional, such as isFollowedBy, hasEventOccuringDuring, definesSpace, isBlindPouchDivisionOf. Such roles are strictly speaking not allowed in OWL and OWL 2 and are often considered to be modelling problems.

    OpenGALEN response: In GRAIL, rephrased in pseudo-OWL, rephrased in a more modern but I think equivalent way:

    IF
    p is a transitive role,
    and
    A p some B, B p some C
    and
    to say that p manyOne
    THEN this implied that
    (p Some C) subsumed (p some B)
    and as a consequence,
    IF A p some B AND A p some D)
    THEN
    EITHER B p some D
    OR EXISTS C . B p some C AND C p some D.

    (I think that captures the recursion; the original definitions were more verbose)

    The point is that the combination of ‘manyOne’ and ‘transitive’ applied to a property indicated that it was constrained to form an (inverse) tree rather than an acyclic directed graph, that is that for every Entity, there could be only one direct p successor, i.e. each entity could be part of only one branch of the tree defined by the transitive relation “p” – call it the “p-tree”.

    The direction, “looking up” the “p-tree” may seem backwards, but it was usually used for things such as “is-part-of”, where the inverse “has-part” formed a strict tree.

    (Obviously this could equally well have been written hasPart isPartOf oneMany. hasPart Transitive. or isPartOf hasPart manyOne. isPartOf Transitive. As far as I know, OWL cannot express this constraint. The closest one can come is isPartOf transitive isPartOfDirectly subPropertyOf isPartOf. isPartOfDirectly functional.In practice this is what was often done in GRAIL, but the language supported the alternative construct which is why you find properties that are both transitive and given a cardinality of manyOne or oneMany, which would otherwise be translated to OWL as “functional” or “inverseFunctional”.

Total
0
Shares
Leave a Reply
Next Post

What is an open source clinical terminology resource?