Consider the following chain of reasoning:
1. Simba is a lion.
2. All lions have at least one parent.
3. So, Simba has at least one parent.
This is a perfectly valid inference, and it can be represented in predicate logic as follows:
s = Simba
L = is a lion
P = is the parent of
1. Ls
2. (Ax)(Lx --> (Ey)(Pxy))
3. (Ey)(Pys)
In a natural deduction system, one would be permitted to infer 3 (via a series of inference rules) from the conjunction of 1 and 2.
I would expect to see a similar inference generated with OWL reasoners. Suppose we had the following triples (using Turtle syntax):
:Simba rdf:type :Lion .
:Lion a owl:Class ;
rdfs:subClassOf
[
a owl:Restriction ;
owl:onProperty :isParentOf ;
owl:someValuesFrom owl:Thing ;
] ;
.
These statements are translations of 1 and 2 into OWL. However, it appears that OWL reasoners do not infer something like 3. Is this right? Or can something like this inference be made using OWL reasoners?
Related
The trace processing of the functor 'flatten2' with input list: "[4, [3, [2, [1,[ ] ] ] ] ]" (Screenshot of the tracing process)
The above is the screenshot of me calling functor flatten2 with input list "[4, [3, [2, [1,[ ] ] ] ] ]", and a variable 'X'.
The below is the function that I was tracing, stolen from this question: Flatten a list in Prolog.
So my essential question is that during the recursion, what happens to the variable X and its value? Why is the 'X' showed as '_295' in the "call 1", how does prolog grammar calculating this value?
flatten2([], []) :- !.
flatten2([L|Ls], FlatL) :-
!,
flatten2(L, NewL),
flatten2(Ls, NewLs),
append(NewL, NewLs, FlatL).
flatten2(L, [L]).
X is just a local name for "globally visible stuff" that is held in the "term store".
X designates (or names or denotes) either:
Concrete content: A term, which a generally tree. The variable is called "bound" or "instantiated". The leaves of the tree are either concrete content (atoms, numbers etc.) or cells with no content (see below). The inner nodes are called compound terms. If X designates a term, then the query nonvar(X) succeeds. When X is printed, it "disappears": The content is printed instead.
A cell with no content (I like to call this a "hole"), which is meant to be take up a term eventually. In that case the variable is called "unbound" or "uninstantiated". If X is such an unbound variable, i.e. if it designates a hole, then the query var(X) succeeds. When X is printed, its name is printed.
Confusingly (and I should add, rather sloppily), a "variable name" is commonly also called a "term". That's a Prolog tripmine, these two concepts should be held apart but they are not.
If you write your Prolog clause, you will use nice variable names.
flatten2(L, [L]).
Remember these variables names have no particular significance and they are local to the clause.
When Prolog runs, it has to pull new variable names that are distinct from any other names "out of the hat". These fresh variable names look like _295. Different implementations have different conventions here.
An example where new variable names have to be created to describe a list that contains a member foo somewhere (on at least one place). List templates of increasing length are generated. At each place of the list except the place holding foo (a concrete term), there is a "cell without content"/"hole". To express this, a random new variable name distinct from any other variable name is generated and printed. The variable name is probably directly derived from the hole address.
?- member(foo,L).
L = [foo|_23302] ;
L = [_23300, foo|_24038] ;
L = [_23300, _24036, foo|_24774] ;
L = [_23300, _24036, _24772, foo|_25510] ;
L = [_23300, _24036, _24772, _25508, foo|_26246] ;
L = [_23300, _24036, _24772, _25508, _26244, foo|_26982]
Say that I want to validate insertion of a company promotion in a triple Store using Shex. A possible approach would be to code Shex as in:
:Promotion {
my-onto:has_person #:Person ;
my-onto:grants_role #:Role ;
}
:Person {
a [ foaf:Person ] ;
}
:Role {
a [ my-onto:CompanyRole ] ;
}
This is a simplification. The problem is that when inserting the data the triple will be something of:
:promotion-123 my-onto:has_person :person-456 ;
my-onto:grants_role :role-CTO .
and this graph won't pass Shex validation because it lacks all the a triples.
So for defining and documenting what are correct as IRIs in the two relations, it makes sense to have the Shapes but in 90% of all real world scenarios data will come as in the example above without the type (in this example) relation and thus will fail to validate.
What would the correct way of documenting complex and nested shapes for validating RDF but at the same time "disable" some checks a certain points in the graph?
The use case I'm thinking about is when I need to add extra info to "shapes" already existing, using IRIs like owl:NamedIndividuals or constants in an ontology, already existing entities like Persons, companies, etc.
You mean that you insert data without rdf:type (a) declarations and the system adds those declarations by some kind of reasoning system.
ShEx doesn't interfere with reasoning systems and doesn't treat rdf:type declarations in any special way. So there could be several approaches for that use case.
One approach is to have add a question mark to the rdf:type declaration as:
:Promotion {
my-onto:has_person #:Person ;
my-onto:grants_role #:Role ;
}
:Person {
a [ foaf:Person ] ? ;
}
:Role {
a [ my-onto:CompanyRole ] ? ;
}
which says that a :Person can either not have a rdf:type declaration or if it has a rdf:type declaration, then it must contain the single value foaf:Person.
Another approach could be to have two shapes, one before reasoning to check the input data and another after insertion the data to check the correct behaviour of the insertion process.
Notice that it is possible to have different shapes for the same data that act at different points during the data processing pipeline.
I have the next code in a file called "testing.pl":
fact(1).
fact(2).
fact(3).
funcA(X) :- funcB(X).
funcB(X) :- fact(X).
testing :- funcA(_X).
Then, in SWI-Prolog interpreter I query funcA(X). and the output is:
X = 1 ;
X = 2 ;
X = 3.
But, whenever I query testing. the output is:
true ;
true ;
true.
So, my questions is:
How can I use the conclusion of a rule as a premise of another rule (funcA(X) at the right of testing), but having the same effect as if I query that premise (funcA(X))?
In the example above, I would like to write testing. at some point of my "testing.pl" file and to get the funcA(X) to do the same like when I query with the interpreter, so funcB(X) will check for all values that X can take from fact(N) and return it.
My desire result would be to write testing. and to get on screen:
X = 1 ;
X = 2 ;
X = 3.
Thanks.
You can manually print anything on the terminal, using for example predicates like portray_clause/1, format/2 etc.
The only additional piece you need is a way to force backtracking over all answers. One way to do it is using false/0.
So, in your case, you can write for example:
testing :-
funcA(X),
format("X = ~q ;~n", [X]),
false.
And now invoking testing/0 yields, without any further interaction:
?- testing.
X = 1 ;
X = 2 ;
X = 3 ;
In addition, the predicates now fails, so you also get false/0 if you use it interactively (from the toplevel), but not if you invoke testing from the shell via swipl -g testing ....
Also take a look at the important variable_names/1 option that is available to use the intended variable names.
I lave tailoring this output to your exact use case as an exercise. Ideally, the output should be a proper Prolog term, so that you can actually test it easily by reading it with read/1 and comparing it to a reference result.
I am trying to find all of the distinct entries where a person's name is john, peter or fred.
However, if there were, for example, two people called peter, I only want to display one occurrence of the name.
My code so far is as follows:
searchpeople(X) :-
people(_,[X|_]),
X=john; X=peter; X=fred.
I understand that the solution is probably something to do with cuts (having read other posts), but I cannot find an example where cuts are used when trying to retrieve X OR Y OR Z (In my case john, peter or fred).
Thanks in advance.
The problem is that you're confusing operator precedence. Just like more conventional programming languages where writing something like this
if ( A and B OR C OR D )
...
is almost certainly going to get you in trouble, your code has the exact same problem. Operator precedence and associativity causes
searchpeople(X) :-
people(_,[X|_]) ,
X=john ;
X=peter ;
X=fred .
to be parsed as if written
searchpeople(X) :-
( people(_,[X|_]) ,
X = john
) ;
( X = peter ;
X = fred
) .
Which is probably not what you intended.
While you could use parenthesis to get the effect you most likely want:
searchpeople(X) :-
people(_,[X|_]) ,
( X = john ;
X = peter ;
X = fred
) .
You would be better off splitting things up a bit:
search_people(X) :-
people(_,[X|_]) ,
desired_person(X).
desired_person(john).
desired_person(peter).
desired_person(fred).
It makes your intent clearer and easier to understand. It's also easier to debug and extend.
I hope the question is not trivial, I spent a decent amount of time looking for an answer around.
I am creating an ontology in OWL and I've been trying to enforce a particular constraint into a class description but not being able to do it with the tools provided by OWL and resorted to blank nodes as existential variables in the description of the class. Protege5 did not like it a bit.
I'd like to model classes of spaces and movements from one space to another, and in particular I'd like to model a movement that has as a target the same space as the starting space.
In logic I'd describe my InternalMovement class as:
InternalMovement = forall ?x exist ?y (Movement(?x) ^ space(?x,?y) ^ direction(?x,?y))
In OWL variables do not exist and enforcing the identity of a blank nodes throughout a class description doesn't seem possible. I resorted to blank nodes because they should be treated as existential variables and I hope using blank nodes ids would do the trick. I was wrong and I don't know how to model this simple class.
The Turtle snippet is this:
:Movement rdf:type owl:Class .
:Space rdf:type owl:Class .
:direction rdf:type owl:FunctionalProperty ,
owl:ObjectProperty ;
rdfs:domain :Movement ;
rdfs:range :Space .
:space rdf:type owl:FunctionalProperty ,
owl:ObjectProperty ;
rdfs:domain :Movement ;
rdfs:range :Space .
:InternalMovement rdf:type owl:Class ;
owl:equivalentClass [ rdf:type owl:Class ;
owl:intersectionOf ( :Movement
[ rdf:type owl:Restriction ;
owl:onProperty :space ;
owl:hasValue _:sp1
]
[ rdf:type owl:Restriction ;
owl:onProperty :target ;
owl:hasValue _:sp1
]
)
] .
I would expect that the following individual would be classified as InternalMovement, but obviously it doesn't.
:internalmovement rdf:type :Movement ,
:space :room1 ;
:direction :room1 .
:room1 rdf:type :Space.
Can anyone help me, please?
Thanks
It sounds like what you want is to define a class by specifying that it has the same value for two particular properties. If OWL supported property intersection (some description logics do), then you could write
InternalMovement ≡ ∃(space ⊓ direction)
Unfortunately, OWL doesn't have this. However, you could define a property that is a subproperty of both space and target and use that. That is:
spaceAndDirection ⊑ space
spaceAndDirection ⊑ target
InternalMovement ≡ ∃spaceAndDirection
This means that if x is an InternalMovement, then there exists a y such that spaceAndDirection(x,y), and then from the subproperty axioms, we may infer space(x,y) and direction(x,y).
That will take care of some of what you want, but not all of it. If you just know that some movement x has some y as a space and as a direction, you still can't infer spaceAndDirection(x,y), and so you can't infer that x is an InternalMovement.
If you add cardinality axioms that a movement has exactly one space and exactly one direction, then you can ensure that if x has y as its space and direction, then if it has a spaceAndDirection value, then that value must be y.
If you also add the (min or exact) cardinality axiom that InternalMovement has (at least or exactly) one spaceAndDirection value, then if x is an InternalModement, then from any two of the following, you can infer the third:
space(x,y)
Since x is an InternalMovement, it must have a spaceAndDirection value. Call it z. Then spaceAndDirection(x,z). Then, since spaceAndDirection is a subproperty of space and direction, we also have space(x,z) and direction(x,z). Since x is a Movement, it has exactly one space value, so y = z. Then we also have direction(x,y) and spaceAndDirection(x,y).
direction(x,y)
Analogous to above.
spaceAndDirection(x,y)
Since spaceAndDirection is a subproperty of space and direction, we immediately have space(x,y) and direction(x,y).