I want to express the following in an OWL ontology in Protege: IndividualA is composed of IndividualB1 at X %, IndividualB2 at Y % and so on, up until 100%.
Does a pattern exists to model this?
I want to express the following in an OWL ontology in Protege:
IndividualA is composed of IndividualB1 at X %, IndividualB2 at Y %
and so on, up until 100%.
Does a pattern exists to model this?
I don't think you'll be able to get the guarantee/restriction on sums that you're looking for in OWL. But part of the structure that you're talking about is just an n-ary relationship. Instead of a two place relationship
isComposedOf(IndividualA, IndividualB1)
you have a three place relationship:
isComposedOfByPercent(IndividualA, IndividualB1, 0.34)
There are lots of ways to represent n-ary relationships using semantic technologies, so many so that the W3C published a working note, Defining N-ary Relations on the Semantic Web. In OWL, one of the most common approaches might be:
x a Composition ;
hasComposite IndividualA ;
hasComponent IndividualB1 ;
hasPercentage 0.34 .
Another might be:
IndividualA hasCompositePart y .
y a CompositePart ;
hasComponent IndividualB1 ;
hasPercentage 0.34 .
Related
In the SWI Prolog manual, I found the following remark:
For example, assume an application that can reason about multiple worlds. It is attractive to store the data of a particular world in a module, so we extract information from a world simply by invoking goals in this world.
This is actually a very good description of what I'm trying to achieve. However I ran into a problem. While I do want to model many different worlds, there are also things that I want to share across all of them. So my idea is to have an allworlds module for things that are true in every world, and one module for every world that I want to reason about, and the latter imports from the former. So I'd do something like this in the REPL:
allworlds:asserta(grandparent(X, Z) :- (parent(X, Y), parent(Y, Z))).
allworlds:dynamic(parent/2).
add_import_module(greece, allworlds, start).
greece:asserta(parent(kronos, zeus)).
greece:asserta(parent(zeus, ares)).
Now I'd like to query greece:grandparent(kronos, X) and get X = ares, but all I get is false. When allworlds:grandparent calls parent, it doesn't call greece:parent like I want it to, but allworlds:parent. My research seems to indicate that I need to make the grandparent predicate module-transparent. But calling allworlds:module_transparent(grandparent/2). didn't fix the issue, and it's also deprecated. This is where I'm stuck. How can I get this working? Is meta_predicate/1 part of the solution? Unfortunately I can't make heads or tails of its documentation.
Prolog modules don't provide a good solution for the "many worlds" design pattern. Notably, making the predicates meta-predicates (or module transparent or multifile) would be a problematic hack. But this pattern is trivial with Logtalk, which is a language extends Prolog and can use most Prolog systems as a backend compiler. A minimal (but not unique) solution for your problem is:
:- object(allworlds).
:- public(grandparent/2).
grandparent(X, Z) :-
::parent(X, Y),
::parent(Y, Z).
:- public(parent/2).
:- end_object.
:- object(greece,
extends(allworlds)).
parent(kronos, zeus).
parent(zeus, ares).
:- end_object.
Here, we use inheritance (the individual worlds inherit the common knowledge) and messages to self (the ::/1 control construct) when common predicates need to access world specific predicate definitions (self is the object/world that received the message - grandparent/2 in the example).
Assuming the code is saved in a worlds.lgt file and that you're using SWI-Prolog as the backend:
$ swilgt
...
?- {worlds}.
% [ /Users/pmoura/worlds.lgt loaded ]
% (0 warnings)
true.
?- greece::grandparent(kronos, X).
X = ares.
P.S. If running on windows, use the "Logtalk - SWI-Prolog" shortcut from the Start Menu after installing Logtalk.
I ultimately solved this by passing the module around explicitly and invoking predicates in it with the : operator. It reminds me a bit of doing OOP in C, where you do things like obj->vtable->method(obj, params) (note how obj is mentioned twice, just like the M in my code below).
Similar to the Logtalk solution, I need to explicitly call into the imported module when I want to consider its clauses. As an example, I've added the fact that a father is also a parent to the allworlds module.
allworlds:assertz(grandparent(M, X, Z) :- (M:parent(M, X, Y), M:parent(M, Y, Z))).
allworlds:assertz(parent(M, X, Y) :- M:father(M, X, Y)).
add_import_module(greece, allworlds, start).
greece:assertz(parent(_, kronos, zeus)).
% need to call into allworlds explicitly
greece:assertz(parent(M, X, Y) :- allworlds:parent(M, X, Y)).
greece:assertz(father(_, zeus, ares)).
After making these assertions, I can call greece:grandparent(greece, kronos, X). and get the expected result X = ares.
in my ontology i got a Recipe-Class which got multiple "children", which are of the class Food. Those foods have Nutritions (protein, carbs, fats...).
Recipe->Food->Nutrition->NutritionAmount
Is it possible to calculate the sum of the proteins of Recipe x with reasoning rules? With Sparql its working well.
I am using the Envelope_3 package of CGAL-4.9.1 and I need to compute an upper envelope where the resulting envelope diagram (Envelope_diagram_2<EnvTraits>) could have edges of three different types:
segments
rays
parabolic arcs (conic arcs)
The three provided models of Envelope_Traits_3 are not enough for this.
I therefore need to create my own EnvTraits (which have to be a model of the concept Envelope_Traits_3).
For now, I made a something like the already provided Env_sphere_traits_3<ConicTraits> model, with which I have at my disposal both parabolic arcs and segments (I just use straight arcs).
The problem arises because I also need to be able to use Rays. How could I do this? Is there a Traits class that I can extend (just like I'm doing right now with Arr_conic_traits_2) that provides X_monotone_curve_2s that can be of the three types that I need?
I found the Arr_polycurve_traits_2 class, hoping that it would allow curves of different type to be stored as subcurves, but it actually just allows to store polycurves that are all of the same kind (linear, bezier, conic, circular...).
What you need is a model of the EnvelopeTraits_3 concept and of the ArrangementOpenBoundaryTraits_2 concept. Among all traits classes provided by the "2D Arrangements" package only instances of the templates Arr_linear_traits_2, Arr_rational_function_traits_2, and Arr_algebraic_segment_traits_2 are models of the later concept.
I suggest that you develop something like Env_your_object_traits_3<AlgebraicTraits_2>, where the template parameter AlgebraicTraits_2 can be substituted with an instance of Arr_algebraic_segment_traits_2.
Efi
Related questions Necessary and sufficient conditions for inferring a property, Representing if-then sentence using OW
Base on my understanding of owl:equivelantClass and rdfs:subClassOf we can represent Necessary Condition and Necessary and Sufficient Condition using subClassOf relation (one directional subClassOf or bi-direction subClassOf which is equivalentClass).
If we want to represent condition N is Necessary Condition of S (IF S THEN N), we can model this in following:
S rdf:type owl:Class;
rdfs:subClassOf [
rdf:type rdf:Restriction;
owl:onProperty :N;
owl:hasValue :D
].
or just say:
S rdfs:subClassOf N.
If we want to represent condition N is Necessary and Sufficient Condition of S (N IIF S), we can model this in following:
N rdf:type owl:Class;
owl:equivalentClass [
rdf:type rdf:Restriction;
owl:onProperty :S;
owl:hasValue :D
].
or just say:
N owl:equivalentClass S.
My question is can we represent sufficient condition using OWL? I'm thinking maybe I can represent the Sufficient Condition by reverse the order of Restriction Class and A.
Edit
According to the definition of Necessary and Sufficient condition, the assertion of N is Necessary for S is equivalent to S is Sufficient to N, we can understand this as N is super-set of S or S is subset of N.
Base on the accepted answer, we can model this relationship as S rdfs:subClassOf N or define a superClassOf property:
:superClassOf owl:inverseOf rdfs:subClassOf
and assert N :superClassOf S.
Conclusion
So the answer is yes, we can represent Sufficient condition by reverse the order (define a inverse property of rdfs:subClassOf) of Necessary condition.
Conditions, of course, refers to "conditions on an individual for class membership", and are expressed in terms of defining ever-smaller (more restricted) subclasses of the overall "class of all things".
In that context, a sufficient condition is simply the inverse of a necessary condition. So in effect, every time you specify a necessary condition, you also specify a sufficient condition.
Let's spell that out.
A necessary condition on a class X is the following: "IF the individual i is an instance of the class X, THEN the condition must be true". subClassOf(X, Y) means that IF an i is of class X, THEN it must also be of class Y, so in other words if we want to say that i is in X, it's necessary that it is also in Y. But it's not sufficient for i to be in Y to conclude that it is in X.
A necessary and sufficient condition on class X is a condition where in addition it also holds that "IF the condition is true, THEN the individual must be an instance of the class". In other words "if i is in class Y, this is sufficient evidence that it is also in X". This is the equivalence relation, which specifies that the sets of individuals of two classes are exactly the same (so if i is in Y, it must be also in X, vice versa).
A condition on X that is only sufficient, but not necessary, would mean that you have some relation R(X,Y) for which it holds that IF an indivual is in Y, it is also in X, but not necessarily that IF it is in X, THEN it is also in Y. This is the superclass relation, in other words the inverse of the subclass relation.
So when you say subClassOf(X, Y) you have not only defined a necessary condition for X, but effectively also a sufficient condition for Y. After all, if we know an individual i is an instance of X, then that is sufficient to conclude it's also an instance of Y. But it's not necessary for i to be an instance of X to also be an instance of Y: there can be instances of Y that are not in X.
In OWL there is no explicit separate owl:superClassOf relation. However if you really wanted to express it in those terms, you could conceivably introduce a superClass relation yourself, simply be defining it as the owl:inverseOf the subClassOf relation.
I've been studying J for the last few weeks, and something that has really buggered me is the dyadic case of the # operator: the only way I've used it yet is similar to the following:
(1 p: a) # a
If this were reversed, the parenthesis could be omitted:
a #~ 1 p: a
Why was there chosen not to take the reverse of the current arguments? Backwards familiarity with APL, or something I'm completely overlooking?
In general, J's primitives are designed to take "primary data" on the right, and "control data" on the left.
The distinction between "primary" and "control" data is not sharp, but in general one would expect "primary" data to vary more often than "control" data. That is, one would expect that the "control" data is less likely to be calculated than the "primary" data.
The reason for that design choice is exactly as you point out: because if the data that is more likely to be calculated (as opposed to fixed in advanced) appears on the right, then more J phrases could be expressed as simple trains or pipelines of verbs, without excessive parenthesization (given that J executed left-to-right).
Now, in the case of #, which data is more likely to be calculated? You're 100% right that the filter (or mask) is very likely to be calculated. However, the data to be filtered is almost certain to be calculated. Where did you get your a, for example?
QED.
PS: if your a can be calculated by some J verb, as in a=: ..., then your whole result, filter and all, can be expressed with primeAs =: 1&p: # ... .
PPS: Note the 1&p:, there. That's another example of "control" vs "primary": the 1 is control data - you can tell because it's forever bound to p: - and it's fixed. And so, uncoincidentally, p: was designed to take it as a left argument.
PPPS: This concept of "control data appears on the left" has been expressed many different ways. You can find one round-up of veteran Jers' explanations here: http://www.jsoftware.com/pipermail/general/2007-May/030079.html .