1 / 25

Simplified Common Logic

Simplified Common Logic. A flexible framework for information interchange based on first-order logic. Simplified Common Logic. SCL ad-hoc working group (formed Dec 2002):

adora
Download Presentation

Simplified Common Logic

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Simplified Common Logic A flexible framework for information interchange based on first-order logic

  2. Simplified Common Logic SCL ad-hoc working group (formed Dec 2002): Pat Hayes IHMC, US Christopher Menzel Texas A&M U., USJohn Sowa VivoMind, USTanel Tammet U. Goteborg, SwedenBill Anderson OntologyWorks, USMurray Altheim Open University, UKHarry Delugach U. of Alabama, US

  3. conventional First-Order Logic • Lexicon fixed by signature • Lexicon is pre-sorted into relation/function/individual names • One context-free syntax for expressing logical forms • Only ‘pure’ logical forms allowed • No relations in the universe of discourse • No global naming scheme

  4. conventional First-Order Logic (GOFOL) • Lexicon fixed by signature • Lexicon is pre-sorted into relation/function/individual names • One context-free syntax for expressing logical forms • Only ‘pure’ logical forms allowed • No relations in the universe of discourse • No global naming scheme All of this causes problems for interoperability and information exchange None of it is actually required by the FO semantics

  5. conventional First-Order Logic (SCL) • Lexicon fixed by signature No signature required • Lexicon is pre-sorted into relation/function/individual names Lexical categories implicit • One context-free syntax for expressing logical forms Syntactic options may be user-defined • Only ‘pure’ logical forms allowed SCL can be intermixed with other content, including XML markup • No relations in the universe of discourse No restrictions on universe of quantification • No global naming scheme Uses WWW standard URI conventions SCL is first-order logic with syntactic limitations removed and network use in mind.

  6. SCL Overview SCL syntax forms are defined as skins which wrap the kernel The Kernel is a minimal language on which the semantics is defined.

  7. SCL Overview:surface syntax (forall (?x)(implies (and (P ?x) (R ?x)) (PR ?x)))) Different surface syntax forms all map to the kernel, which provides a common central notation for processing and combining information. [@every *x] [If: [P(?x) R(?x)] [Then: PR(?x)]] (∀x)(P(x)&R(x) → PR(x)) (x)not(P(x) R(x) not PR(x))

  8. SCL Overview:ontology Ontology name is URI name = header :: body Header specifies lexical categories, special assumptions, name classes Body contains asserted sentences (‘axioms’) Both expressed as sets of SCL sentences

  9. SCL Overview:ontology headers (( (?x)not(scl:Rel(?x) scl:Ind(?x)) ;;GOFOL syntax scl:Rel(Married Kissed Boy Girl) ;;relation names scl:Ind(Jack Jill) ;; individual names scl:Arity(2 Kissed) ;; Kissed can take 2 arguments 2 =scl:Arity(Married) ;;Married must take 2 arguments 1 =scl:Arity(Boy) ;;end of header )::( Boy(Jack);;beginning of body (?x)not(Boy(?x) (?y)not (Kissed(?x ?y) Girl(?y) ) ;;every boy kissed a girl Married(Jack Jill) )) Header defines syntactic conditions on sentences in body Body contains asserted sentences expressing ontology content

  10. SCL Overview:naming and importing (scl:ontology http://purl.org/scl/1.0/#FOLheader = (()::(?x)not(scl:Rel(?x) scl:Ind(?x)) ;;GOFOL syntax)) ) (( scl:import(http://purl.org/scl/1.0/#FOLheader ) scl:Rel(Married Kissed Boy Girl) ;;relation names scl:Ind(Jack Jill) ;; individual names scl:Arity(2 Kissed) ;; Kissed can take 2 arguments 2 =scl:Arity(Married) ;;Married must take 2 arguments 1 =scl:Arity(Boy) ;;end of header )::( Boy(Jack);;beginning of body (?x)not(Boy(?x) (?y)not (Kissed(?x ?y) Girl(?y) ) ;;every boy kissed a girl Married(Jack Jill) ))

  11. SCL Overview:ontology headers One can put it all in the body, and always have an empty header: (( )::( scl:import(http://purl.org/scl/1.0/#FOLheader ) scl:Rel(Married Kissed Boy Girl) scl:Ind(Jack Jill) scl:Arity(2 Kissed) 2 =scl:Arity(Married) 1 =scl:Arity(Boy) Boy(Jack) (?x)not(Boy(?x) (?y)not (Kissed(?x ?y) Girl(?y) ) Married(Jack Jill) )) This is satisfiable iff the original is, but now one cannot distinguish semantic from syntactic errors: they both appear as logical inconsistencies. The same semantics handles headers and bodies in a uniform way.

  12. SCL semantics One universe of discourse; all quantifiers range over it. Relations may be in the universe, or may not. Functions are treated as a special class of relations. To allow a fully general syntax, we distinguish relations from their extensions. This also allows intensional theories of relations, providing extra flexibility. (Similar to treatment in RDF.)

  13. SCL semantics:FIT A lexicon is just a set of names, all with the same status. Interpretations are required to provide a meaning for any term which can be constructed from these names (i.e., in effect, for the Herbrand universe): this is called the fitting condition. They are also required to be extendable so as to satisfy the header (relations mentioned in the header are not required to be in the ontology universe). Interpretations which do not satisfy the header are considered to be illegal. All of this allows the ‘signature’ to be determined by the semantic interpretation, and so described in a uniform way in SCL itself.

  14. The SCL Kernel Intended for metamathematical use in writing specifications and processing by software. Minimal syntax, not very readable, but easy to define syntactic mappings into and to define semantics clearly and transparently. Completely defines the semantics of all SCL surface syntax forms.

  15. The SCL Kernel: terms and atoms No lexical distinction between relation names, individual names or variables: all referring expressions are treated uniformly. Terms and atoms formed by applying a term to a sequence of terms; no syntactic restrictions on what symbols appear where. married(Jack Jill)when(married(Jack Jill))=3pm(thursday(week(12 year(1997))))married(x) wife(x)=JillConjugalStatus(married Jack)ConjugalStatus(Jill)(Jack)

  16. The SCL Kernel: terms and atoms No lexical distinction between relation names, individual names or variables: all referring expressions are treated uniformly. The same name may play many ‘roles’ at the same time: married(Jack Jill) binary relationwhen(married(Jack Jill))=3pm(thursday(week(12 year(1997)))) binary functionmarried(x) wife(x)=Jill unary predicateConjugalStatus(married Jack) individual entityConjugalStatus(Jill)(Jack) value of a function and also a unary predicate, but not mentioned explicitly. All of these can be used in the same ontology, preserving their intended meanings.

  17. The SCL Kernel: sequence vars seqVars can be used to indicate an arbitrary sequence of any finite length. a(x @z) stands for the infinite set a(x) (z) a(x z) (z z’) a(x z z’) (z z’ z’’) a(x z z’ z’’)…

  18. The SCL Kernel: sequence vars This ‘axiom scheme’ convention allows a form of inductive definition to be used at the top level in SCL, e.g. list()=nillist(x @y)=cons(x list(@y)) entails all sentences like: list(a b c d)=cons(a cons(b cons(c cons(d nil)))) So together with r(@y) iff r(list(@y)) can be used to render all argument sequences as explicit lists and hence defines the ‘standard’ trick (used in RDF and OWL, for example) for mapping n-ary relations into unary predicates.

  19. The SCL Kernel: logic andnotforall (a b c … )not a(a) b That is all.

  20. The SCL Kernel: headers, etc. Headers ((header)::(body))Definitions (ontology <name>= ((header)::(body)) Importations import(<name>) Special forms: numerals, quoted strings Special names: scl:Arity scl:Ind scl:Rel scl:Fun intended for use in headers

  21. The SCL Core Extends Kernel to full FO notation with several convenient features, including: • role-set syntax for atomic sentences eg Married{wife=Jill husband=Jack} • restricted (‘sorted’) quantifiers egforall (x:human) exists (y:dog) Intended as a canonical SCL syntax for human-oriented readability. Can be viewed as an SCL skin. Completely reducible to the kernel syntax.

  22. SCL skin 1: KIF Most of KIF 3.0 syntax can be immediately transcribed into the SCL kernel as a simple skin. (Exceptions: ‘definitions’; quantified sequence variables (free are OK); function/relation convention is modified)

  23. SCL skin 2: Concept Graphs CG syntax represented as can be immediately transcribed into the SCL kernel as a skin, and indeed vice versa. (sequence variables map into applications of relations to lists, which are described in an SCL header.)

  24. SCL skin 3: RDF/OWL RDF(S) maps directly to the conjunctive/existential case of SCL (Datatyped literals are handled by functions.) OWL-DL maps to the first-order subcase of SCL using a conventional embedding of description logics to FOL.

  25. SCL: work still to do Finish specification of XML-based interchange syntax Write up detailed account of skin-fitting algorithm Provide general criteria for conformance of alternative syntaxes Establish clear guidelines for embedding SCL into conventional FO syntax using holds/app translation, with equality, to provide for SCL inference using conventional reasoning engines. Projected date for draft document is mid-January 2004

More Related