Ähnlich wie Philippe Martin and Jérémy Bénard | Importing, Translating and Exporting Knowledge via an Ontology of Knowledge Representation Languages (20)
Boost PC performance: How more available memory can improve productivity
Philippe Martin and Jérémy Bénard | Importing, Translating and Exporting Knowledge via an Ontology of Knowledge Representation Languages
1. Top-level Ideas about Importing, Translating and Exporting Knowledge
via an Ontology of Knowledge Representation Languages (KRLs)
Philippe MARTIN (philippe.martin@univ-reunion.fr) 1
and
Jérémy BÉNARD (jeremy.benard@logicells.com) 2
1
Associate Professor, EA2525 LIM, University of La Réunion island, France
(+ adjunct researcher of the School of ICT, Griffith University, Australia)
2
PhD student, GTH/Logicells + University of La Réunion island, France
1/6
2. Plan
1. Introduction - Solving Old Problems in Parsing, Translation and Export
=> "fully" representing the involved languages (here KRLs)
2. Used Top-level Ideas for a Normalized/Scalable Representation+Classification of
Languages (models, notations) and Language Elements (relations, functions, sets, frames, ...)
3. Example of Specification for Some Top-level Language Elements in RIF
4. Conclusion
2/6
3. 1. Introduction - Solving Old Problems in Parsing, Translation and Export
=> "fully" representing the languages (here, KRLs)
Classic non-semantic approaches (=> exploiting fixed+syntactic KRLmodels, not a genuine ontology):
* parser generators (e.g., since 1975, Lex&Yacc) + translation/export procedures/rules
* approaches based on abstract+concrete syntax models/grammars, e.g., XML + XSLT + CSS + GRDDL
* graph-based approaches: graph/term rewriting rules and, since 2005, RDF + Fresnel/SparqlTemplate/...
=> lack of possibilities for automatic inferencing and language+process parametrization+updates by users
=> restriction of knowledge sharing and re-use
Classic semantic approaches (=> exploiting abstract model ontologies for 1 or several KRLs):
* KIF+Ontolingua (1990s), CL (2000s), OWL+RIF (W3C), ODM, (OMG), HETS+LATIN+DOL+Ontohub
=> no shared ontology, focused on translation between logics, no representation of notation structures
=> lack of possibilities for KRL comparisons, reuses, parametrizations and specializations
Fully ontology-based approach (=> exploiting 1 user-extendible ontology for
KRL abstract models AND KRL notation models):
* KRLO ( http://www.webkb.org/KRLs/ )
=> generic tools for parsing/translating/exporting from/between/to the specified KRLs
3/6
4. 2. Used Top-level Ideas for a Normalized/Scalable Representation+Classification
of Languages (Models, Notations) and Language Elements (Relations, Functions, ...)
1. Representing only the Description_instrument notions -> using relations i) descr_content_of to
access their Descr_content notions, ii) has_descr_container for Descr_container notions (files)
2. Representing the structure of each abstract/concrete element as having an operator, arguments
and a result, e.g, the relation “has_part (USA Iowa)” has for operator has_part and for result true
3. Representing other relations (<=>, =>, ...) between abstract elements (AEs) of KRLs, e.g.,
i) frame / set of binary relations from a same source, ii) definition / rule / universal quantification,
iii) N-ary relation / binary relation with a set as destination, iv) kinds of meta-statements
4. Representing the presentation of an AE in a notation as an ordering (with delimiters+spacing) on
the presentation of each part of this AE in that notation, e.g., for "o (x y)" :
(o x y) o(x y) o(x,y) (x o y) xoy (x y o) [x y]o {x y}
E.g.: (+ 1 2) +(1 2) +(1,2) (1+2) 1=1.0 (1 2 +) [1 2]+ {1 2}
=> like grammars but i) related to AEs, hence to semantics, ii) with relations and via functions
=> this enables the design of generic parsers/generators and parametrization by users
1/6
5. 3. Example of Specification for Some Top-level AEs in RIF (here in an UML++)
1/6
f_in(AE RIF-M) ?rifAE
rc_spec
fc_spec ( List( fc_OP_from(?rifAE) "("
fc_ARGS_from_(?rifAE) ")" )
f_in(Value_or_reference RIF-M) List(RIF_PS) )
f_in(NR_formula RIF-M)
RIF_AE_that_has_also_and_preferably_an_infix_notation_in_RIF_PS ?i
f_in(Constant RIF-M)
rc_spec
fc_spec ( List( fc_ARG(f_dest(?i has_link_source))
fc_OP_from(?i)
f_in(Universally_quantified_variable fc_ARG(f_dest(?i has_link_destination))
RIF-M) ) List(RIF_PS) )
f_in(NR_atomic_formula RIF-M)
f_in(Composite_formula RIF-M)
f_in(Minimal_frame_as_NR-phrase
RIF-M)
f_in(Formula_with_1_logic_predicate RIF-M) f_in(And-formula RIF-M) f_in(Rule RIF-M)
6. 4. Conclusion
* With the many KRL elements already specified in KRLO, specifying a KRL model or notation
does not take many more lines than writing the grammar of this KRL
* There is no parsing/translation/export tool to implement
* The approach is more powerful than classic (semantic or not) approaches:
- end-users can specify their own KRLs
- KRL models/notations can be compared and the specifications can be written in any KRL
=> ontology-based alternative to XML+XSLT+CSS for specifying models and notations
(but HTML/XML+XSLT+CSS can be re-used for presentation purposes)
=> can reduce the negative effects of the proliferation of KRL/data models/formats
* A rather ad-hoc parser+translator+generator has been implemented by the 2nd author :
see http://www.webkb.org/KRLs/
Generic parser+translator+generator functions are implemented by the 1st author in Javascript
and as "pure functions" (hence, in a declarative way) for them to be added to KRLO
In the future, they will also be represented via logic rules (in various KRLs) and STTL (SPARQL++)
2/6