owlcs/hermit-reasoner

hermit-reasoner's Issues

Axioms that violate OWL specs - option to ignore

HermiT is not rejecting a sub property axiom, it is saying the construct used can only occur in an asserted axiom if it is a sub property axiom. This is on accordance with the same owl spec you quoted:

Restriction on owl:topDataProperty. The owl:topDataProperty property occurs in Ax only in the superDataPropertyExpression part of SubDataPropertyOf axioms.

There's an explanation of why the restriction exists in the page. In short, accepting such an axiom invalidates some of the owl semantics.

Pellet and FaCT++ are likely identifying the same issue and deciding to ignore the offending axiom. They might be logging messages to that effect.

It is a good point to ask for reasoners to automatically ignore such axioms - it is likely to be an useful feature. However, it is not wrong for the reasoner to throw of out.

From owlcs/owlapi#786

Command line module from original HermiT fork

Some developers have asked for this code to be included.

Entailment check is broken with command line 1.4.6.519

Result is true for attached files and command line

java -jar HermiT.jar --premise=file:///tmp/oro1_s.maowl --conclusion=file:///tmp/oro1_s_ck.maowl --checkEntailment

even when last line contains unknown entiry oro:kover. When some garbage is added after that, parser gives correct error about oro:kover. There are many similar cases when entailment result is true regardless of the content of the check file. HermiT 1.38 works for those cases.

files.zip

Entailment of disjoint data properties fails

Disjoint data properties axiom entailment uses top data property in a cardinality restriction, causing an exception to be raised. The code is asymmetric - disjoint object properties use a method similar to finding the disjoint properties of a specified property, but disjoint data properties do not have the same utility method.

Inverses cause false property equivalences

phillord#8

Defining a property, another property that is inverse of the first one, and then declaring a subproperty of the first also as subproperty of the inverse of the second (which is redundant but legal) causes HermiT to think the subproperty is equivalent to the inverse. This is due to inverse property inferences based on property inclusion, but not precise enough to detect that subproperty of an inverseOf expression is not enough to guarantee bidirectional inclusion.

Example:

Prefix: : <http://example.org/>
    Ontology: <http://asdf>
    ObjectProperty: hasBigPart
        SubPropertyOf: hasPart, inverse (partOf)
    ObjectProperty: hasPart
        InverseOf:  partOf
    ObjectProperty: partOf
        InverseOf: hasPart
        Characteristics: Transitive

hasBigPart is inferred to be equivalent to hasPart. For that to be true, another inclusion is needed.

The issue is that HermiT rewrites inverseOf axioms into bidirectional, independent inclusions (so as to normalize inverses that are not written explicitly but declared via inclusions), but when it builds the inverses map it considers the appearance of one inverseOf expression sufficient to infer the bidirectional inverse relation, which would, in the example above, justify the property equivalence. However, that's wrong - both sides of the inclusion are required for this inference.

hermit reasoner: python vs protege

I have created an ontology and then used the Hermit reasoner to infer triples. I used the Hermit reasoner via Protege (after uploading the ontology created through owlready module), and I used the Hermit reasoner with the owlready module over the same ontology file. I receive different inferred triples. Why is this? Thanks!

Undo unnecessary finals

phillord#11

Configuration was changed without a good reason.

support for swrl buillt-in atoms

Hello there, I'm using SWRL API v2.0.8 to author and manage rules to an ontology, At the same time, i'm using Hermit reasoner v1.3.8.413 to extract entities from the ontology. My problem is I get the following exception whenever i pass an ontology that contains swrl atoms to the createReasoner method, if there are no swrl constructs in the owl file, it would work like a charm. Is there any way to bypass that exception?

Exception in thread "main" java.lang.IllegalArgumentException: A SWRL rule uses a built-in atom, but built-in atoms are not supported yet.
    at org.semanticweb.HermiT.structural.OWLNormalization$RuleNormalizer.visit(OWLNormalization.java:1358)
    at uk.ac.manchester.cs.owl.owlapi.SWRLBuiltInAtomImpl.accept(SWRLBuiltInAtomImpl.java:96)
    at org.semanticweb.HermiT.structural.OWLNormalization$RuleNormalizer.visit(OWLNormalization.java:1247)
    at org.semanticweb.HermiT.structural.OWLNormalization.processAxioms(OWLNormalization.java:185)
    at org.semanticweb.HermiT.structural.OWLNormalization.processOntology(OWLNormalization.java:167)
    at org.semanticweb.HermiT.structural.OWLClausification.preprocessAndClausify(OWLClausification.java:153)
    at org.semanticweb.HermiT.Reasoner.loadOntology(Reasoner.java:208)
    at org.semanticweb.HermiT.Reasoner.<init>(Reasoner.java:199)
    at org.semanticweb.HermiT.Reasoner.<init>(Reasoner.java:173)
    at org.semanticweb.HermiT.ReasonerFactory.createHermiTOWLReasoner(ReasonerFactory.java:51)
    at org.semanticweb.HermiT.ReasonerFactory.createReasoner(ReasonerFactory.java:19)
    at org.semanticweb.HermiT.ReasonerFactory.createReasoner(ReasonerFactory.java:15)
    at com.guc.met.App.main(App.java:32)

`

DateTime parsing error in HermiT

When processing the FIBO quick start ontology (https://spec.edmcouncil.org/fibo/OWL) the following error is reported:

org.semanticweb.HermiT.datatypes.MalformedLiteralException: Literal "2018-11-01T00:44:58.379000"^^http://www.w3.org/2001/XMLSchema#dateTime is malformed

As far as java LocalDateTime is concerned this is a valid dateTime which I think means this literal value is valid.

Run HermiT on the command line

When reading OWL document and server returns HTTP 301 gives now an error

    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:236)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:880)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:800)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadImports(OWLOntologyManagerImpl.java:1278)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1309)

Would be an easy fix to follow the location in this case?