I am currently working on a ontology.
I created a bunch of individuals (every individual should be sorted to a different optimization problem like TSP, VRP and VRPTW).
But I think the open world assumption creates some problems.
In Individuals I want the reasoner to realize that Auftrag 1 is a TSP, Auftrag 2 is a VRP and Auftrag 3 a VRPTW. At the moment it works
but only because for 1 and 2 I use the "exactly" cardinality in types.
I have to do this because if not the reasoner may think that there could be more than one of this kind (in this example warehouse or simpleVehicle).
Because of that I created this "exactly 1" cardinality on types so that the reasoner can only sort it right. But as soon as I am right the closure axiom could help me so to prevent the open world assumption at this point?
I hope you understand my point.
I attached the file, best regards!
File:
https://www2.zippyshare.com/v/loP7YJNP/file.html
Related
In first place i have to apologize for my very, very poor english.
I've been studying the representation of knowledge in the context of design of experts systems trough ontologies. In particular, i've been using protégé as an OWL ontology editor.
After a large number of fails, finally i've started to realize the huge impact of the OWA on the process of inference and reasoning, mainly when i try to performance some automatic classification task.
I've solve many of the basic problems about that but, going deeper on the idea of making more and more specific classifications, i ran into the need for use cardinality restrictions. (which, at first, i tought that i cleary understand, but in the end, i realize that i'm nowhere close it)
Well, so far i've made a mess. Only a very few classification has been working as i spected. I guess that, as usual, i've been losing sight of the OWA.
Mi concrete doubt is this: What's the point on creating a restriction over an object property with a 'max' and, specially, 'exactly' cardinality in a context where we assume that the world is open?
I bring to you this simple example, based on the Pizza Tutorial, since many concepts can be extrapolated from there: Suppose that i want to define the class of pizzas named "FourChessePizza" and i want that, in principle, any individual that has four "ChesseTopping", i.e., four relationships along the "hasTopping" property with individuals of class "CheeseTopping", are inferred as belonging that class.
So i create an individual and, in "types", i assert this:
hasTopping some MozzarellaToping
hasTopping some ParmesanTopping
hasTopping some FontinaTopping
hasTopping some BlueChesseTopping
All the fillers are disjoints.
(The names of each chesse are merely demostrative; i don't know which cheeses are used)
So far, the reasoner have no way to say that that individual belongs to "FourChessePizza" since, although it has four relationships, the OWA considers the possibility that it can have more relations that might not have been "said". No 'max' or 'exactly' cardinality restriction can be applied since the uncertainty about "how much relations" really have the individual.
So, with only this information i can't found any restriction to my "FourCheesePizza" that clasify this simple individual as own.
Beyond this particular example, my question is more general about the generic process of "counting" asserted relationships with the less possible information.
¿Is there any solution to this kind of problems?¿What is what i'm not thinking in the rigth way to solve this and similar problems?
Thank you very much in advance for your time and your good will.
Cheers!
This is a surprisingly intricate problem! At first sight, it looks like what you need is simply a "closure axiom", something that is describe in the Protégé tutorial with the Pizza ontology. There, the concept of a Margherita pizza is at first described as a pizza that has some mozzarella topping and some tomato topping. But even if you know a pizza has mozzarella and tomato, it is not sufficient to classify it as a Margherita pizza, because other kinds of pizzas have mozzarella and tomato. So the solution is to say that a Margherita pizza only has mozarella and tomato toppings.
Similarly, it would be possible to say that your example pizza only has Mozzarella, Parmesan, Fontina, and Blue Cheese toppings. But would this be sufficient to qualify as a FourCheesePizza? Well, it depends how you define 4 cheese pizzas. If a FourCheesePizza is one that has at least 4 cheese toppings, then yes. But we don't want to have 5-cheese pizzas classified as 4-cheese pizzas, right?
A simple conceptualisation of 4-cheese pizzas would be that it has exactly 4 cheese toppings:
FourCheesePizza subClassOf hasTopping exactly 4 CheeseToppings
So, it means that for any instance of FourCheesePizza, there exists x1, x2, x3, x4 four distinct instances of CheeseTopping. The problem is, the four instances could be all distinct instances of MozzarellaTopping.
In the case of Hector Coscia's example, if we have:
FourCheesePizza subClassOf (
hasTopping some MozzarellaTopping and
hasTopping some ParmesanTopping and
hasTopping some FontinaTopping and
hasTopping some BlueChesseTopping and
hasTopping only (MozzarellaToping or ParmesanTopping or FontinaTopping or BlueChesseTopping)
then it is possible that there are 2 mozzarella toppings, 5 parmesan toppings, 16 fontina toppings, and 42 blue cheese toppings. And yet, this woud arguably be fine as a 4-cheese pizza because what matters is that it uses exactly 4 types of cheeses. But how to express that a pizza only has 4 types of toppings?
In OWL, it is not possible to restrict the number of classes used in a definition. For instance, it is not possible to say: the instances that are member of only 2 classes. Even if it was possible, it would be useless, because every instance X belongs to infinitely many classes: it belongs to the singleton class {X}, it belongs to every superclass of this singleton, and it belongs to the union of {X} with all the classes that are disjoint from {X}.
So the only option is to change the modelling pattern: to make TypeOfCheese a class, and to make Mozzarella, Parmesan, Fontina, Blue Cheese instances of this class. Then it is possible to restrict how many types of cheeses are used. To do so, you may proceed as follows:
create a property typeOfCheese that connects instances of CheeseTopping to instances of TypeOfCheese
create another propery usesTypeOfCheese that connects pizzas to types of cheeses
define a property chain axiom that says: hasTopping o typeOfCheese subPropertyOf usesTypeOfCheese
define FourCheesePizza as the subclass of usesTypeOfCheese exactly 4 TypeOfCheese
define the instances of TypeOfCheese: mozzarella, parmesan, fontina, blueCheese, cancoillotte, etc.
define MozzarellaTopping subClassOf typeOfCheese value mozzarella, ParmesanTopping subClassOf typeOfCheese value parmesan, etc.
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.
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
Let's suppose a simple ontology with the following classes/subclasses:
Subject
Subject_under_60
Subject_over_60
I have a set of incoming data which is transformed into a set of Subject individuals having a data property "has_age".
I'm looking for some nice workaround how to define the Subject's subclasses in the way that reasoners would be able to classify the subject individuals. So far, I was thinking about two approaches:
Data pre-processing where I would add a flag if the subject is or is not over 60 (e.g. subject01 dataProperty:isOver60 True).
Data post-processing, i.e. solve it later in the process in SPARQL queries.
But what I would really appreciate is something like
Subject_over_60 isEquivalent Subject AND (has_age valueOver "60"^^xsd:int).
My goal is to simplify the pre-processing as much as possible (in best case leave there just a date of birt) and leave most of the classification work up to reasoners. Since specific value comparison is limited to "exact value" only, I'm aware that it won't be so easy. I would appreciate any idea or your best practice to solve a similar problem.
I wanna get the total number of relationships between classes (just classes without taking into account individuals) in an ontology, I'm not sure if I can get it through the metrics that provides protege. I'll put an example below to show you what I'm looking for.
This picture represents an excerpt of people ontology. For me the total number of relationshiphs between classes is 11 (8 subclass relationships and 3 other relationships ).
By visualizing the ontology metrics provided by protege, this is what I get (in the picture below): As you can see I have just 5 subclassOf axioms instead of 8. And I don't know if it's possible to get the total number of relationships from only those metrics. I wanna get the total number using java code based on OWL-API. I use Protege just to have an idea of numbers of metrics.
Please if you have any idea that may help me to get the total number, I would be grateful
Thank you
You can count axioms of a specific type with OWLOntology::getAxioms(AxiomType) - I believe that's what Protege is doing - but I don't think that will be enough for your objective. EquivalentClasses axioms with more than two elements in it will count for more than one link, for example.