Context is Semantic Web (slides from TimBL)
- Really simple
- Based on RDF standards
- N3 (Notation 3) syntax makes it much easier
Subject, verb and object
All knowledge is just a set of statements
<#pat> <#knows> <#jo> .
### in classical logic: knows(pat,jo)
Object can be literal
<#pat> <#knows> <#jo> .
<#pat> <#age> 24 .
Note: noun form "age" preferred to the verb style "knows" for
predicates.
Saving space: the comma and semicolon
<#pat> <#child> <#al>, <#chaz>, <#mo> ;
<#age> 24 ;
<#eyecolor> "blue" .
- Comma: Here comes another object for same subject & predicate
- Semicolon: here comes another predicate for same subject.
- Aim? Easy scribbling of data.
Data .. e.g. a table
|
age |
eyecolor |
| pat |
24 |
blue |
| al |
3 |
green |
| jo |
5 |
green |
<#pat> <#age> 24; <#eyecolor> "blue" .
<#al> <#age> 3; <#eyecolor> "green" .
<#jo> <#age> 5; <#eyecolor> "green" .
Unnamed things: Square brackets
<#pat> <#child> [ <#age> 4 ] , [ <#age> 3 ].
### in classical logic: ∃x ∃y child(pat,x) ∧ child(pat,y) ∧ age(x,4) ∧ age(y,3)
Note:
- Words used as IDs have no actual meaning.
- Unnamed nodes can't be used elsewhere.
- If things are names, make the name explicit
[ <#name> "Pat"; <#age> 24; <#eyecolor> "blue" ].
[ <#name> "Al" ; <#age> 3; <#eyecolor> "green" ].
[ <#name> "Jo" ; <#age> 5; <#eyecolor> "green" ].
Local concept
<> <#title> "A simple example of N3".
Who or what knows what <#title> is?
Shared concept
<> <http://purl.org/dc/elements/1.1/title>
"Primer - Getting into the Semantic Web and RDF using N3".
To save space:
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:title
"Primer - Getting into the Semantic Web and RDF using N3".
Note
- No <> used when prefixed identifier
- Typically prefix stands for eveything up to including a "#"
- Dublin core example alas does not give RDF schema directly: no "#"
Making vocabularies
Equivalent:
:Person rdf:type rdfs:Class
:Person a rdfs:Class.
which we could use with data;
:Pat a :Person.
Examples: class and property
:Woman a rdfs:Class; rdfs:subClassOf :Person .
and a property:
:sister a rdf:Property.
Something about the Property :sister::
:sister rdfs:domain :Person;
rdfs:range :Woman.
Use:
:Pat :sister :Jo.
Convention:
- Class ids start with capital, Property ids with lowercase
Rules Are Just Statements
# subject verb object
#============= ========== ==============
{ ?x :son ?y } => { ?y a :Male }.
{ ?x :son ?y } log:implies { ?y a :Male }.
### in classical logic: ∀x ∀y son(x,y) ⇒ male(y)
The terms in braces { } are formulas.
The rule statement relates two formulas.
More Complex Antecedent
{ ?x :son ?y.
?y!:age math:lessThan 15 }
=>
{ ?y a :Boy }
More Complex Consequent
{ ?x :son ?y }
=>
{ ?y a :Male.
?y :parent ?x.
?x a :Parent }.
EYE, an open source reasoning engine
- EYE stands for "Euler YAP Engine" and it is a further incremental development of Euler which is an inference engine supporting logic based proofs.
- EYE is a backward-forward-backward chaining reasoner design enhanced with Euler path detection.
- The Euler path detection is roughly "don't step in your own steps" to avoid vicious circles so to speak and in that respect there is a similarity with what
Leonhard Euler discovered in 1736 for the Koenigsberg Bridge Problem.
- The reasoning that EYE is performing is grounded in FOL (First Order Logic).
- Keeping a language less powerful than FOL is quite reasonable within an application, but not for the Web, see
http://www.w3.org/DesignIssues/Logic.html.
- Open source project hosted at http://eulersharp.sourceforge.net/.
Detailed design of EYE
- N3 (Notation 3) parser specified as Prolog DCG (Definite Clause Grammar)
- N3Logic to PCL (Prolog Coherent Logic) compiler allowing existentials,
disjunctions and false in the conclusion of rules
- yasam/1 engine with Euler path detection to avoid loops and with postponed brake mechanism to run at much increased speed
- yasam/3 engine with euler path detection to avoid loops and creating possible models, false models and counter models
- proof construction using the http://www.w3.org/2000/10/swap/reason vocabulary for proofs
- builtins which can be extended via a web based plugin mechanism so that new functionalities can be easily added without a total redesign of the reasoner
- support predicates for the above functionalities
EYE under the hood
In the current design things are layered and cascaded as follows:
.------------------.
.------------|- - - N3S |
| PCL |-----'------------|
|------------|- - -' YASAM |
| YABC |-----'------------|
|------------|- - -' YAAM |
| ASM |-----'------------|
'------------|- - -' CPU |
'------------------'
Legend
------
N3S = Notation 3 Socket
PCL = Prolog Coherent Logic
YASAM = Yet Another Skolem Abstract Machine
YABC = Yet Another Byte Code
YAAM = Yet Another Abstract Machine
ASM = Assembly Code
CPU = Central Processing Unit
EYE intermediate code: Prolog Coherent Logic (PCL)
A PCL rule has the general form
A1 , A2 , . . . , Am => C1 | C2 | . . . | Cn (1)
where the Ai are atomic expressions and each Cj is a conjunction of atomic expressions, m, n >= 1.
The left-hand side of a rule is called the antecedent of the rule (a conjunction) and the right-hand side is
called the consequent (a disjunction). All atomic expressions can contain variables.
If n = 1 then there is a single consequent for the rule (1), and the rule is said to be definite. Otherwise
the rule is a splitting rule that requires a case distinction (case of C1 or case of C2 or . . . case of Cn).
The separate cases (disjuncts) Cj must have a conjunctive form
B1 , B2 , . . . , Bh (2)
where the Bi are atomic expressions, and h >= 1 varies with j. Any free variables occurring in (2) other
than those which occurred free in the antecedent of the rule are taken to be existential variables and their
scope is this disjunct (2).
http://www.ii.uib.no/acl/description.pdf
EYE source code: Yet Another Prolog (YAP)
Plugins
EYE command line interface
Usage: eye <options>* <data>* <query>*
eye
java -jar Euler.jar [--swipl] [--no-install]
yap -q -f euler.yap -g main --
swipl -q -f euler.yap -g main --
<options>
--nope no proof explanation
--no-branch no branch engine
--no-qvars no quantified variables in output
--no-qnames no qnames in output
--no-span no span control
--quiet incomplete e:falseModel explanation
--quick-false do not prove all e:falseModel
--quick-possible do not prove all e:possibleModel
--quick-answer do not prove all answers
--think generate e:consistentGives
--ances generate e:ancestorModel
--plugin <yap_resource> plugin yap_resource
--wcache <uri> <file> to tell that uri is cached as file
--ignore-syntax-error do not halt in case of syntax error
--pcl output PCL code
--strings output log:outputString objects
--warn output warning info
--debug output debug info
--profile output profile info
--version show version info
--help show help info
<data>
<n3_resource> n3 facts and rules
<query>
--query <n3_resource> output filtered with filter rules
--pass output deductive closure
--pass-all output deductive closure plus rules
EYE supports MONADIC reasoning
- MONADIC stands for "MONotonic Abduction-Deduction-Induction reasoning Cycle"
- Monotonicity is a crucial characteristic of FOL (First Order Logic) and abduction, deduction and induction are taken from what was orginally intended
by Peirce according to Flach and Kakas:
Instead, he identified the three reasoning forms
- abduction, deduction and induction - with the
three stages of scientific inquiry:
hypothesis generation, prediction and evaluation.
When confronted with a number of observations she
seeks to explain, the scientist comes up with an
initial hypothesis; then she investigates what
other consequences this theory, were it true,
would have; and finally she evaluates the extent
to which these predicted consequences agree with
reality.
|
 |
A concrete example: wet grass
The background theory
true => (
{:loc001 :ascribed :Cloudy, :NonSprinkler, :Rain, :WetGrass, []}
{:loc001 :ascribed :NonCloudy, :Sprinkler, :NonRain, :WetGrass, []}
{:loc001 :ascribed :Cloudy, :NonSprinkler, :Rain, :WetGrass, []}
...
{:loc001 :ascribed :Cloudy, :NonSprinkler, :NonRain, :NonWetGrass, []}
...
)!e:disjunction
{?S :ascribed :Cloudy, :NonCloudy} => false.
{?S :ascribed :Sprinkler, :NonSprinkler} => false.
{?S :ascribed :Rain, :NonRain} => false.
{?S :ascribed :WetGrass, :NonWetGrass} => false.
A concrete example: wet grass
The observation
:loc001 :ascribed :WetGrass.
A concrete example: wet grass
The queries, expressed as "filter" rules
{?S :ascribed :Sprinkler} => {?S :ascribed :Sprinkler}.
{?S :ascribed :Rain} => {?S :ascribed :Rain}.
A concrete example: wet grass
Was the sprinkler causing wet grass?
[ e:counterModel {:loc001 :ascribed :Cloudy. :loc001 :ascribed :NonSprinkler.
:loc001 :ascribed :Rain. :loc001 :ascribed :WetGrass. :loc001 :ascribed _:sk0}
].
[ e:possibleModel {:loc001 :ascribed :NonCloudy. :loc001 :ascribed :Sprinkler.
:loc001 :ascribed :NonRain. :loc001 :ascribed :WetGrass. :loc001 :ascribed _:sk0}
; r:gives {
:loc001 :ascribed :Sprinkler.
}
].
[ e:falseModel {:loc001 :ascribed :Cloudy. :loc001 :ascribed :NonSprinkler.
:loc001 :ascribed :NonRain. :loc001 :ascribed :NonWetGrass. :loc001 :ascribed _:sk0}
; e:because [ e:integrityConstraint {{:loc001 :ascribed :WetGrass. :loc001 :ascribed :NonWetGrass} => false}
]
].
...
[ e:inductivity 0.567901234567901].
A concrete example: wet grass
Was the rain causing wet grass?
[ e:possibleModel {:loc001 :ascribed :Cloudy. :loc001 :ascribed :NonSprinkler.
:loc001 :ascribed :Rain. :loc001 :ascribed :WetGrass. :loc001 :ascribed _:sk0}
; r:gives {
:loc001 :ascribed :Rain.
}
].
[ e:counterModel {:loc001 :ascribed :NonCloudy. :loc001 :ascribed :Sprinkler.
:loc001 :ascribed :NonRain. :loc001 :ascribed :WetGrass. :loc001 :ascribed _:sk0}
].
...
[ e:inductivity 0.666666666666667].
A concrete example: wet grass
- The wet grass example is just a classical machine learning example where multiple observations are used to predict reality.
- If you always see that the grass is wet when it rains, you can 'predict' that the grass will be wet when it starts raining and deduct that it rains when you see wet grass, unless you turned on the sprinkler, which shows that nothing is black and white.
- There is just a high probability that it rains when the grass is wet, and when the sprinkler works it doesn't say that it is not raining.
The color prediction experiment from Pieter Pauwels
- The input of the experiment is a color stream of 30 randomly chosen color patterns.
- Starting with virtually no background knowledge.
- The reasoner tries to figure out the most probable color name (Red, Green, Black, Blue, Orange) from the color code (RGB) and the pattern that is most likely active (e.g. a Red, Green, Orange traffic light sequence).
- Running two reasoning levels continuously in cycles of abduction, deduction and induction.
- The example shows a nice behaviour where different agents do work on different levels and together they can do the job: one is just recognizing colors, the other is detecting patterns, etc ....
- This is also the idea of the semantic web where everything should be connected and can seamlessly contribute to the "higher goal".
A single EYE reasoning run is MONADIC
- The possible hypotheses (abduction) are generated as e:possibleModel graphs.
- The predictions (deduction) are either generated as a r:gives graph or the possible model becomes an
e:counterModel graph or an e:falseModel graph that is immediately disregarded.
- The reality check (induction) is generated as an e:inductivity triple expressing
the ratio possible/(possible+counter) which is playing nice with belief calculus.
=================================================================
Re: Monotonic abduction and Bayes theorem in N3 coherent logic
http://lists.w3.org/Archives/Public/www-archive/2010Nov/0004.html
=================================================================