On deputation to the CNRS ["Délégation au CNRS"]
at the I3S (SPARKS / WIMMICS) from 1/2/2019 to 31/7/2019
1. Past+Current Research Environments |
1993-1996: PhD thesis at the INRIA - Acacia team (→ Edelweiss, + Kewi → Wimmics)
1997: postdoc at the University of Adelaide, Australia
1998-2007, at Griffith University, Gold coast, Australia
1998-1999: Research Fellow
2000-2003: Senior Research Fellow for the DSTC
2004-2007: Senior Lecturer
2008: Research Engineer at Eurecom (S.A.), Digital Security team
2009-now: Assoc.Prof. (HDR) at the University of La Réunion
ESIROI (esiroi.univ-reunion.fr): → ~50 new engineers / year 3 departments/specialities: * Food science and technology * Sustainable building and energy * I.T. (I headed it in 2013-2016)
LIM (lim.univ-reunion.fr): Maths (11+PhDs) + I.T. (17+PhDs)
2.1. KB Systems for KE With 1-author KBs and Structured documents |
|
Goal: supporting the mixing+interlinking+exploitation of
KRs with other document elements
(→ unlike in RDFa, the KRs are not necessarily hidden)
1993-1996 (PhD). CGKAT (Conceptual Graph based Knowledge Acquisition Tool)
= CoGITo (C++ code for a CG based KBS core; developped by O.Haemmerlé and extended by
the team which became the LIRMM-INRIA Graphik team headed by ML.Mugnier) +
Thot (structured document editor developped at Inria Rhône-Alpes mainly by V.Quint & I.Vatton,
reused in Amaya, the W3C browser-editor) +
Thot data+presentation+event models + 30'000 lines of C code
1997-1999. WebKB-1 (webkb.org): 1-author-KB server
= CoGITo + Libwww (W3C Sample Code Library) + WordNet API +
11000 ligns of HTML+Javascript + 41000 ligns of C
2nd of the "1999 Asia-Pacific Oracle Queensland IT&T Awards for Excellence" in the R&D category
From 2000. WebKB-2 (webkb.org): N-author-KB server = ORDBMS FastDB/Gigabase (main-memory-based:~500Mb / disk-based) + Libwww (W3C library) + 11500 ligns of HTML+Javascript + 38000 ligns of C++ 1st of the "2001 Asia-Pacific Oracle Queensland IT&T awards for excellence" in the R&D category
2.3. Ontologies (main ones)
From 2013. KRLO: ontology of KR models (KRL abstract syntaxes) and KR notations (KRL concrete syntaxes) (currently about 900 types + the descriptions of particular models/notations)
2.4. KRL notations (KRL concrete syntaxes)
General notations (→ including for higher-order logic models such as RIF-FLD): FCG (Frame-CG), FE (Formalized English), FL (For-Links)
Specificities:
meant to be high-level (readable → concise+organized+expressive, normalizing → expressive → higher-order logics)
FL: - includes FCG and FE - allows graph/frame/logic/functional like (re-)presentations - enables any (set of) statement(s) to be presented as 1 connected graph
Specialized notations: PNLF (Petri-Net Linear Form), ADLF (Activity Diagram Linear Form)
2.4. KRL notations (KRL concrete syntaxes) - Basic OWL2-compatible Example
En: By definition, a flying_bird_with_2_wings is a bird that flies and has two wings.
FE: any Flying_bird_with_2_wings is a Bird that is agent of a Flight and
has for part 2 Wing.
FL: Flying_bird_with_2_wings = ^(Bird agent of: a Flight, part: 2 Wing).
// "^" → lambda-abstraction, ...
RDF+OWL2 / Turtle:
:Flying_bird_with_2_wings owl:intersectionOf
(:Bird [a owl:Restriction; owl:onProperty :agent; owl:someValuesFrom :Flight]
[a owl:Restriction; owl:onProperty :part; owl:qualifiedCardinality 2;
owl:onClass :Wing] ).
OWL2 / OWL Functional-Style:
EquivalentClasses( :Flying_bird_with_2_wings
ObjectIntersectionOf( :Bird ObjectSomeValuesFrom( :agent :Flight )
ObjectExactCardinality( 2 :part :Wing ) ) )
| UML_model / UML_concise_notation: |  |
2.4. KRL notations (KRL concrete syntaxes) - More Complex Example
En: On March 21st 2016, John Doe believed that in 2015 and in the USA,
at least 78% of adult healthy carinate birds were able to fly.
FL: [ [ [ [ [at least 78% of Adult Healthy Carinate_bird can be agent of: a Flight ]
place: USA ] time: 2015 ] believer: John_Doe ] time: 2016-03-21 ].
IKLmE / Turtle:
[rdf:value
[rdf:value
[rdf:value
[rdf:value
[rdf:value [rdf:value [:agent_of [a :Flight]
]; pm:q_ctxt [quantifier "78to100pc";
rdf:type :Adult, :Healthy,
:Carinate_bird ]
]; pm:ctxt [:modality :Physical_possibility]
]; pm:ctxt [:place :USA]
]; pm:ctxt [:time "2015"]
]; pm:ctxt [:believer :John_Doe]
]; pm:ctxt [:time 2016-03-21] ].
En: In 2016, John was a student.
FL: [John type: Student] time: 2016].
IKLmE / Turtle:
[rdf:value [owl:sameAs John; rdf:type :Student]; pm:ctxt [:time "2016"] ].
//or: [:id "John"; rdf:type :Student; pm:ctxt [:time "2016"] ].
1 query command: generic operator "?" + query statement (QS) (in any KRL)
?c [a Cat ?c part: a Paw] //→ each cat represented as having a paw
? [a Cat part ^2..4: a Paw] //→ path of 2 to 4 relations of type part
?s [a Cat part: a Paw] >= ?s //→ list of each "minimal connected sub-graph" ?s
// that specializes the left part of ">="
// (i.e. on which this part can be projected)
?s [a Cat part: a Paw] –| ?s //→ list of each "minimal statement" ?s that
// permits to infer the left part of "–|"
? [a Cat part: a Paw] //→ as for the last query but the statements (?s) are organized in a
// specialization hierarchy (graphically, via
// an indented list, ...)
Generic "SPARQL queries for checking constraints" → 1 query for each kind of constraints (from mid-2017, with O. Corby)
Progress on KEO ("Knowledge Engineering" Ontology) which is meant to represent and organize
concepts, ontology design rules/best-practices, techniques and tools (in KE or KR related parts of I.T., security and "fair cooperation")
E.g., from SPARKS/WIMMICS research about
* argumentation theory
* program data flows + security rules (→ mainly with Y. Roudier and N. Le Thanh)
Example of general ODR for KR organization (ODR explained in following slides) Criteria: at-least-minimal KB organization for scalable KR Sharing ODR: "each object (in the KB) must be defined as either comparable or un-comparable to any other object, at least via specialization relations" Name: Spec-comparability
Any such ODR is automatically checkable and hence can be used
Examples of other ODRs, still for comparability and hence KR organization
"each relation type should be automatically derived/derivable from a concept type" "from each concept type usable for deriving relation types (e.g. role types, process types), relation types should be automatically derived when needed" ... (meta-ODR: manual replications of similar specializations at different places of the specialization hierarchy should be avoided)
4.1. Spec-comparability – What? 4.2. Spec-comparability For Terms – How? Why? 4.3. Spec-comparability For Statements – What? Why? How? |
|
Statement: set of connected relations, i.e. a logic formula,
e.g. 1 relation or 1 relation with a meta-statement that contextualizes it
Term: information object that is not a statement,
e.g. a type or an individual that is not a statement
An (information) object specializes another when it represents more information.
An object (type, statement, ...) is comparable to another (via specialization relations)
if one of the 2 objects specializes the other or is equivalent to it,
e.g. `O1 is subtype of O2´ or `O1 => O2´.
not comparable (in a KB) = "not known to be comparable" or
"known to be un-comparable" (in a KB)
An object is (at least weakly) un-comparable to another
if, from what has been asserted, none of the 2 objects can specialize the other,
e.g. ` not `O1 => O2´ and not `O2 => O1´ ´
→ the relation types comparable and un-comparable are exclusive, i.e. disjoint
→ un-comparable => different
An object is strongly un-comparable to another
if they are uncomparable and cannot have common specializations,
e.g. `O1 has for exclusion O2´ or ` `O1 => not O2´ and `O2 => not O1´ ´
Spec-comparability:
from each object, there is an inferred or explicit relation to each of
- its closest generalizations or equivalent objects, and
- its closest uncomparable siblings in the (unique) specialization hierarchy
Spec-genus&minimal-differentia_comparability: Spec-comparability +
at least 1 other "sufficient difference" wrt. each direct generalization and sibling
Spec-genus&full-differentia_comparability: Spec-comparability +
at least 1 "necessary&sufficient difference" wrt. each direct generalization and sibling
Part-comparability
How (the easiest way): relating each type to all its equivalent types and its closest specializations via sets such as
p{...} (owl:disjointUnionOf)e{...}
wp{...} we{...}
cd{...}d{...}
How: Basic example in FL:
$ default_creator: PhM.
Thing = owl#Thing,
exclusion: owl#Nothing,
> p{ (Situation > p{ (Process = Perdurant) State } )
(Entity
> p{ Spatial_entity
(Non-spatial_entity
> p{ (Attribute > e{ Characteristic Measure } )
(Non-spatial_entity_that_is_not_an_attribute
> Description_content-or-instrument-or-container )
} )
} )
}
p{ Type Individual }
v_p{ Atomic_thing Composite_thing }.
Why:
more detections of inconsistencies (incorrect usages of terms) → mis-interpretations of the (full) meaning of some terms e.g. the shared specializations of exclusive terms
more querying possibilities, e.g.
?s [ [a hotel place: Sophia_Antipolis] not disjoint_with: ?s ]
returns all statements about "things that may be hotels" in Sophia_Antipolis
Why:
without this unique place, people can and do put objects at different places in the KB → objects are more and more difficult to relate and hence infer from ↔ there are more and more implicit redundancies and contradictions → the KB cannot scale
What?
Example (with "⇒" referring to the logical derivation):
`at least 1 Bird ⇐ `at least 50% of Bird
can be agent of can be agent of
a Flight´ a Flight´
⇑ ⇖ ⇖
`1 Bird `Tweety can be `each Bird
can be agent of a Flight can be
agent of that has for duration agent of
a Flight´ at least 0.5 Hour´ a Flight´
# ⇑
`Tweety cannot be # `Tweety is agent of a Flight that
agent of a Flight´ has for duration at least 0.5 Hour´
Why?
How?
Basic example of the use of "correction and/or comparability" relations between beliefs:
"Birds fly" (acc. agent_1)
has for specialization (acc. Agent_2)
`every Bird is agent of a Flight´
that has for corrective_specialization (acc. Agent_3)
`every Healthy Adult Carinate_bird can be agent of a Flight´
__[<= "birds are not constantly flying, ratites do not fly,
and young/unhealthy birds may not be able to fly"].
"every Semantic Web KRL should at least have an XML notation"
<= AND{ "XML is a standard",
"the Semantic Web is for KR-based information-sharing",
("for information sharing, standard languages should be used"
With no other arguments/objections, the first sentence is automatically instance of
Unsuccessfully-supported_phrase (→ if needed, it can be filtered out in query results).
corrective_specialization:
"for information sharing, standard languages should be used
if translators from the used language to standard languages
are not readily available to applications" __[author: A2]
)
}__[author: A1],
<= "an XML-based notation supports the use of URIs and Unicode"
__[author: A1, <!= "most KR notations have or can easily be adapted to support
the use of URIs and Unicode" __[author: A2]
].
"every Semantic Web KRL should at least have an XML-based notation"
corrective_negation:
("a Semantic Web KRL does not need to have an XML-based notation"
<= AND{ "the Semantic Web is for KR-based information-sharing",
("an XML-based notation is less adapted than (at least some)
other notations for KR-based information sharing"
<= AND{ "an XML-based notation is hard to read and write",
("an XML-based notation is technically not relevant
for KR exploitation"
<= AND{ "inference engines do not use
XML data structures internally",
"XML tools can hardly exploit KRs"
} )
} )
} ) __[author: A2].
In the previous slide, all the arguments for the 1st sentence have been contradicted.
Thus, in this slide, a correction for the 1st sentence can be given.
If the arguments given for this correction are not contradicted,
this correction is instance of Successfully-supported_phrase
and the 1st sentence is instance of Successfully-contradicted_phrase.
If a multi-authors argumentation structure is not based on logic and transitive relations (e.g. '<='), from experience, it quickly becomes a spaghetti-network and thus cannot scale, especially if its sentences are informal.
If it is, since more precisions are necessarily added by each addition, the "structured discussion" that it supports ends in one of the three possible ways or a combination of these ways:
The preferences of all the potentially affected agents should also be taken into account if they are expressed in a KB. The aggregation function to take these preferences into account may also be selected based on these preferences.
A "static editable view on a KB" is a KB module storing certain objects – e.g. certain relations – satisfying certain criteria (which are generally not formally represented) → the modules are either created via a centralized and arbitrary process or may be partially redundant and contradictory → modules are like independently created KBs → if the same object is in N modules, N equivalence relations have to be set between this object in different modules → there are either as many modules as criteria (and, as the KB grows, there is no limit to the number of criteria that may be useful) or there is a need for multi-inheritance → modules do not avoid the need for multi-inheritance → modules are hard to manage (version related problems, ...) → modules do not scale
How – One basis for the organization of KEO:
the distinction between description content/instrument/container
any Description_process
has for input 0..* Thing //e.g. a Situation or a Cat, as it is perceived by someone
and for instrument 0..* Description_instrument //e.g. terms and a Language
and for output 0..* Abstract_description_instrument //e.g. a Statement, a Function
and for output 0..* Concrete_description_instrument. //e.g. a String, a Graphic
any Description_instrument
is description_instrument of the
Thing_actually_described_by_a_description-instrument, //e.g. a mental concept of a cat
has for attribute 0..* Description-instrument_attribute //e.g. High-levelness, Translatability,
and is object of 0..* Storage // Well-formedness
that has for output 0..* Description_container //e.g. a File
that has for physical_support 1..* Physical_entity //e.g. some Paper or a Disk
and is input of 0..* Information-Technology_task.
Thing_actually_described_by_a_description-instrument = Description_content.
any Description_content //e.g. the mental concept of a Cat
has for attribute 0..* Description-content_attribute. //e.g. Concistency, Completeness wrt. ...
any Information-Technology_task //e.g. accessing/exploiting KRs
has for attribute 0..* IT-task_attribute //e.g. Accessibility, Security, Performance
and for input 1..* Description_instrument
and for instrument 1..* Description_instrument //e.g. (the Software of) a Web_server
and for output 1..* Description_instrument.