Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Philippe Martin and Jérémy Bénard | Importing, Translating and Exporting Knowledge via an Ontology of Knowledge Representation Languages

207 views

Published on

http://2016.semantics.cc/philippe-martin

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Philippe Martin and Jérémy Bénard | Importing, Translating and Exporting Knowledge via an Ontology of Knowledge Representation Languages

  1. 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. 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. 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. 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. 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. 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

×