We are using GraphDB 8.4.0 as a triple store for a large data integration project. We want to make use of the reasoning capabilities, and are trying to decide between using HORST (pD*) and OWL2-RL.
However, the literature describing these is quite dense. I think I understand that OWL2-RL is more "powerful", but I am unsure how so. Can anyone provide some examples of the differences between the two reasoners? What kinds of statements are inferred by OWL2-RL, but not HORST (and vice versa)?
Brill, inside there GraphDB there is a single rule engine, which supports different reasoning profiles, depending on the rule-set which was selected. The predefined rule-sets are part of the distribution - look at the PIE files in folder configs/rules. One can also take one of the existing profiles and tailor it to her needs (e.g. remove a rule, which is not necessary).
The fundamental difference between OWL2 RL and what we call OWL-Horst (pD*) is that OWL2RL pushes the limits of which OWL constructs can be supported using this type of entailment rules. OWL Horst is limited to RDFS (subClassOf, subSpropertyOf, domain and range) plus what was popular in the past as OWL Lite: sameAs, equivalentClass, equivalentProperty, SymmetricProperty, TransitiveProperty, inverseOf, FunctionalProperty, InverseFunctionalProperty. There is also partial support for: intersectionOf, someValuesFrom, hasValue, allValuesFrom.
What OWL 2 RL adds on top is support for AsymmetricProperty, IrreflexiveProperty, propertyChainAxiom, AllDisjointProperties, hasKey, unionOf, complementOf, oneOf, differentFrom, AllDisjointClasses and all the property cardinality primitives. It also adds more complete support for intersectionOf, someValuesFrom, hasValue, allValuesFrom. Be aware that there are limitations to the inference supported by OWL 2 RL for some of these properties, e.g. what type of inferences should or should not be done for specific class expressions (OWL restrictions). If you chose OWL 2 RL, check Tables 5-8 in the spec, https://www.w3.org/TR/owl2-profiles/#OWL_2_RL. GraphDB's owl-2-rl data set is fully compliant with it. GraphDB is the only major triplestore with full OWL 2 RL compliance - see the this table (https://www.w3.org/2001/sw/wiki/OWL/Implementations) it appears with its former name OWLIM.
My suggestion would be to go with OWL Horst for a large dataset, as reasoning with OWL 2 RL could be much slower. It depends on your ontology and data patterns, but as a rule of thumb you can expect loading/updates to be 2 times slower with OWL 2 RL, even if you don't use extensively its "expensive" primitives (e.g. property chains). See the difference between loading speeds with RDFS+ and OWL 2 RL benchmarked here: http://graphdb.ontotext.com/documentation/standard/benchmark.html
Finally, I would recommend you to use the "optimized" versions of the pre-defined rule-sets. These versions exclude some RDFS reasoning rules, which are not useful for most of the applications, but add substantial reasoning overheads, e.g. the one that infers that the subject, the predicate and the object of a statement are instances of rdfs:Resource
Id: rdf1_rdfs4a_4b
x a y
-------------------------------
x <rdf:type> <rdfs:Resource>
a <rdf:type> <rdfs:Resource>
y <rdf:type> <rdfs:Resource>
If you want to stay 100% compliant with the W3C spec, you should stay with the non-optimized versions.
If you need further assistance, please, write to support#ontotext.com
In addition to what Atanas (our CEO) wrote and your excellent example, http://graphdb.ontotext.com/documentation/enterprise/rules-optimisations.html provides some ideas how to optimize your rulesets to make them faster.
Two of the ideas are:
ptop:transitiveOver is faster than owl:TransitiveProperty: quadratic vs cubic complexity over the length of transitive chains
ptop:PropChain (a 2-place chain) is faster than general owl:propertyChainAxiom (n-place chain) because it doesn't need to unroll the rdf:List underlying the representation of owl:propertyChainAxiom.
Under some conditions you can translate the standard OWL constructs to these custom constructs, to have both standards compliance and faster speed:
use rule TransitiveUsingStep; if every TransitiveProperty p (eg skos:broaderTransitive) is defined over a step property s (eg skos:broader) and you don't insert p directly
if you use only 2-step owl:propertyChainAxiom then translate them to custom using the following rule, and infer using rule ptop_PropChain:
Id: ptop_PropChain_from_propertyChainAxiom
q <owl:propertyChainAxiom> l1
l1 <rdf:first> p1
l1 <rdf:rest> l2
l2 <rdf:first> p2
l2 <rdf:rest> <rdf:nil>
----------------------
t <ptop:premise1> p1
t <ptop:premise2> p2
t <ptop:conclusion> q
t <rdf:type> <ptop:PropChain>
http://rawgit2.com/VladimirAlexiev/my/master/pubs/extending-owl2/index.html describes further ideas for extended property constructs, and has illustrations.
Let us know if we can help further.
After thinking this for bit, I came up with a concrete example. The Oral Health and Disease Ontology (http://purl.obolibrary.org/obo/ohd.owl) contains three interrelated entities:
a restored tooth
a restored tooth surface that is part of the restored tooth
a tooth restoration procedure that creates the restored tooth surface (e.g., when you have a filling placed in your tooth)
The axioms that define these entities are (using pseudo Manchester syntax):
restored tooth equivalent to Tooth and has part some dental restoration material
restored tooth surface subclass of part of restored tooth
filling procedure has specified output some restored tooth surface
The has specified output relation is a subproperty of the has participant relation, and the has participant relation contains the property chain:
has_specified_input o 'is part of'
The reason for this property chain is for reasoner to infer that if a tooth surface participates in a procedure, then the whole tooth that the surface is part of participates in the procedure, and, furthermore, the patient that the tooth is part of also participates in the procedure (due to the transitivity of part of).
As a concrete example, let define some individuals (using pseudo rdf):
:patient#1 a :patient .
:tooth#1 a :tooth; :part-of :patient#1
:restored-occlusal#1 a :restored-occlusal-surface; :part-of tooth#1 .
:procedure#1 :has-specified-output :restored-occlusal#1 .
Suppose you want to query for all restored teeth:
select ?tooth where {?tooth a :restored-tooth}
RDFS-Plus reasoning will not find any restored teeth b/c it doesn't reason over equivalent classes. But, OWL-Horst and OWL2-RL will find such teeth.
Now, suppose you want to find all patients that underwent (i.e. participated in) a tooth restoration procedure:
select ?patient where {
?patient a patient: .
?proc a tooth_restoration_procedure:; has_participant: ?patient .
}
Again, RDFS-Plus will not find any patients, and neither will OWL-Horst b/c this inference requires reasoning over the has participant property chain. OWL2-RL is needed in order to make this inference.
I hope this example is helpful for the interested reader :).
I welcome comments to improve the example. Please keep any comments within the scope of trying to make the example clearer. Its purpose is to give insight into what these different levels of reasoning do and not to give advice about which reasoner is most appropriate.
So, here is something with OWL / Protégé I can't quite understand:
Let's say I have a class Clazz which is an enumerated class containing only the individuals I1 and I2. I then create a third individual I3 and declare it to be of type Clazz.
If I now start a reasoner, I would expect it to infer a sameIndividualAs between all (or at least some) of the indidivuals. This is not the case, I tested with both Hermit and Pellet reasoners.
If I explicitly state the three individuals to be different from each other, the ontology becomes inconsistent. Can anyone tell me why the individuals are not showing up to be sameIndividualAs in Protégé in the first case?
As there is no unique name assumption in OWL, the ontology is consistent until it is explicitly asserted that the manually typed individual is owl:differentFrom all of the individuals defining the class (the set restricted with owl:oneOf). If that's not asserted, in case there is more than one individual, the only inference that can be made is that, in your case, I1and I2 are members of the class Clazz. I3 should be the same as one of the individuals, but there is no information to decide as which. You can remove this ambiguity by making Clazz defined as owl:oneOf :I1. Then there will be no ambiguity and sufficient information to infer that :I3 owl:sameAs :I1.
I am working on building a simple software ontology in Protege v5.2 and I am trying to classify pieces of software (using a reasoner plugin) as CPU intensive if their CPU time is larger than 80% of their physical execution time.
For this reason, each individual has the following data properties filled with float values:
a) hasCPUTime
b) hasPhysicalExecutionTime
I have created a class CPUIntensive and I want to add a restriction that individuals which have hasCPUTime > 0.8 * hasPhysicalExecutionTime belong in this class.
Can this be done in Protege?
OWL 2 doesn't allow arithmetic computations, e.g. multiplication (though some kind of comparison is possible using data ranges).
You need SWRL with builtins:
hasCPUTime (?ind, ?cpu) ^
hasPhysicalTime (?ind, ?phy) ^
swrlb:greaterThan (?cpu, ?mul) ^
swrlb:multiply (?mul, 0.8, ?phy)
-> CPUIntensive(?ind)
The swrlb:multiply builtin is satisfied iff the first argument is equal to the arithmetic product of the second argument through the last argument, and if the first argument is unbound, binds it to the arithmetic product of them, much like Mul is 0.8*Phy. works in Prolog.
Pellet does support those builtins:
I have a small ontology defined as shown in the following picture:
I created an individual for Dataset and one for Algorithm. I expected that the reasoner would infer the Algorithm individual as Linear_Least_Regression, but this didn't happen.
This is the definition of the Dataset individual. As it can be seen, the individual fulfils the requirements for a Dataset needed by the Linear_Least_Regression
Also, if I add the Linear_Least_Regression as a type for the Algorithm individual, the reasoner does not complain.
I also tried to get the Linear_Least_Regression as a result with a DL Query but this also didn't work.
Did I miss something when modelling my ontology or does the problem lie at the reasoner?
I tried following two reasoners: FaCT++ 1.6.5 and HermiT 1.3.8.413 and Protégé 5
Actually, I'm getting lost about what can be done and cannot be done using a reasoner in general.
My question is two fold:
I used to think that a reasoner is only dedicated for sumbsumption and taxonomies. Recently, I discovered that a reasoner can be used in multiple ways within some algorithms for example this reference introduces using a reasoner to search for entities compliant to a specific pattern in the ontology:
What is meant by a DL generic reasoning algorithm and how can it
be implemented through a reasoner?
Can you please refer my to
any references where I can get more familiar to things that can be
achieved by reasoning algorithms if any?
My original problem is that: given an OWL ontology and two classes C1 and C2, I want to check whether there is a functional property chain connecting them, i.e.
let's consider (C1 P1 C3), (C3 P2 C4)and (C4 P3 C2) where P1, P2 and P3 are functional object properties, thus the result will be (P1, P2, P3) which is the functional property chain connecting C1 and C2.