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?
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.
We are creating our Shex definition files checking that some IRIs are of a given type. There is no problem with our generated code but sometimes we get files generated using Protege and most of the individuals are of type X plus owl:NamedIndividual, making our validation fail because now a given resource has 2 assertions of type rdf:type.
Adding owl:NamedIndividual to all shape checks seems like polluting the Shape definition, so how would you allow extra properties that do not conflict with your shape definition?
In Shex, by default the triple constraints are closed which means that a shape like:
:Shape {
rdf:type [ :X ]
}
means that a node that conforms to :Shape must have exactly one rdf:type declaration whose value is :X.
If you want to allow extra values for the rdf:type declaration, you can express it with the keyword EXTRA as:
:Shape EXTRA rdf:type {
rdf:type [ :X ]
}
The meaning now is that a conforming node must have rdf:type :X and can have zero or mode values for rdf:type.
Notice that the previous example could be defined as:
:Shape EXTRA a {
a [ :X ]
}
In the particular case that you only want to allow an extra rdf:type with value owl:NamedIndividual you could also define it as:
:Shape {
a [:X ] ;
a [ owl:NamedIndividual] ;
}
or as:
:Shape {
a [:X owl:NamedIndividual]{2} ;
}
So I was reading this and it says:
As an example of a necessary and sufficient condition, take a look at
the following definition:
:RedThing a owl:Class ; owl:equivalentClass
[ a owl:Restriction ;
owl:onProperty :color ;
owl:hasValue red^^<http://www.w3.org/2001/XMLSchema#string>
]
What I interpret this to mean is that if something is red, then that thing must be a RedThing.Also, if something is a RedThing, then it must be the color red.
When I added this code snippet to Protege, and I write:
:test_subject :color red^^<http://www.w3.org/2001/XMLSchema#string>
Then the following is inferred by the reasoner:
:test_subject rdf:type :RedThing
What this covers is the necessary part of the restriction definition, i.e. if something is red, then that thing must be a RedThing.
When I add the following to an ontology (again using Protege):
test_subject_2 rdf:type :RedThing
Then the following SHOULD be inferred by the reasoner:
:test_subject_2 :color red^^<http://www.w3.org/2001/XMLSchema#string>
Because this is the sufficient part of the condition. i.e if something is a RedThing, then it must be the color red.
BUT it is NOT inferred. What am I missing here?