1 / 34

Artificial Intelligence and Lisp #7

1. Semantic Web 2. Description Languages (done last time) 3. Ontologies (continued from previous lecture) 4. Multiple Inheritance (if time allows). Artificial Intelligence and Lisp #7. Registration: 48 students Number of: lab2a lab2b lab3a

mahlah
Download Presentation

Artificial Intelligence and Lisp #7

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. 1. Semantic Web 2. Description Languages (done last time) 3. Ontologies (continued from previous lecture) 4. Multiple Inheritance (if time allows) Artificial Intelligence and Lisp #7

  2. Registration: 48 students Number of: lab2a lab2b lab3a ------------------------- Reg. Downloads 46 39 11 Orphan downloads 3 2 1 Lab completed 35 7 5 Incomplete upload 0 6 0 Lab statistics

  3. For lab2b • Precondition advise does not work if an action precondition is an or-expression • It should work if the action precondition is an and-expression (being investigated) • Solution not accepted if the remedying action is expressed using H! (not better than fput); there should be a 'natural' action that fixes the precondition • OK to send in a solution that just obtains a solution for one or two verbs, but • Doing it for many or all verbs gives extra credit towards the exam. (Same will apply for later milestone-2 assignments) • John and/or Henrik will deal with the problems for those students who sent in incomplete solutions for this lab.

  4. Cyc and OpenCyc • Started in 1984 as a massive project to build up a knowledgebase • Main knowledgebase is proprietary; subsets are open in general, or open for research • In later years the project has extended in the directions of natural-language dialog and machine learning • OpenCyc (2008): 47.000 concepts, 306.000 links • ResearchCyc (2006): logic base, additional software tools • Read the Wikipedia article about the Cyc project and check out the Cyc webpage!

  5. (#$isa #$BarackObama #$UnitedStatesPresident) (#$genls #$Tree-ThePlant #$Plant) (#$capitalCity #$France #$Paris) (#$implies (#$and (#$isa ?OBJ ?SUBSET) (#$genls ?SUBSET ?SUPERSET)) (#$isa ?OBJ ?SUPERSET)) Cyc, examples of notation

  6. Cyc knowledgebase • Knowledge elements are expressed as propositions (predicate and argument) • Cyc provides a collection of microtheories which are like entityfiles in Leonardo, but consisting of propositions and (sometimes) more complex logical expressions

  7. Protégé is a free, open source ontology editor and a knowledge acquisition system. Like Eclipse, Protégé is a framework for which various other projects suggest plugins. This application is written in Java and heavily uses Swing to create the rather complex user interface. Protege recently has currently 126.870 registered users (17.135, 3.293). It is developed at Stanford University in cooperation with the University of Manchester and others. Protégé

  8. Protégé: one platform, two ontology frameworks • Protégé frames: uses Open Knowledge Base Connectivity Protocol (OKBC). Organized around classes, instances of classes, and slots that are specific to classes. (Classes ~ types in Leonardo, slots ~ attributes). • Protégé OWL: uses Web Ontology Language (OWL). • Protégé has one editor for each of the frameworks and in a common platform. • OKBC is an older approach; OWL is a more recent design and is supported by W3C • Browse the Protégé tutorial for one or the other of these two editors (see Protégé website; will also be linked from the course website)

  9. Approaches to ontologies and knowledgebases • Delivered as formal documents. The user chooses how to integrate this information in his or her system (SUMO) • Delivered as a monolithic knowledgebase that can be queried over the Internet or downloaded as a whole (Dbpedia, Freebase) • Delivered as a software system together with a more or less modular knowledgebase that can be accessed and modified using the system (Protégé, Cyc, Wordnet)

  10. Leonardo's approach • Namespaces: Knowledgebases are built locally and with moderate size, in projects involving one or a few persons. Name conflicts is a minor issue within each project. Name conversion is done when modules are exported and imported, and with the help of the type system. • Administrative information: Located in entityfiles • Types and metatypes: Represented using separate entityfiles • Subsumption: Orthogonal to the type system • Type checking: Posteriori; produces validation report files • Dissemination: knowledge modules are published using the Common Knowledge Library (CKL).

  11. Example of entity and its type --------------------------------------------------------- -- København [: type city] [: in-categories {is-capital}] [: lang-name {[++ English "Copenhagen"] [++ French "Copenhague"] [++ German "Kopenhagen"] [++ Swedish "Köpenhamn"]}] [: in-country Denmark] [: website "http://www.kk.dk/"] [: map-url "http://www.nationsonline.org/oneworld/map/google_map_Copenhagen.htm"] [: source-entities {[: wordnet Copenhagen.n0] [: sumo s.CopenhagenDenmark]}] --------------------------------------------------------- -- city [: type Type] [: attributes <name altnames lang-name details-as in-country in-region in-metropolitan-area website map-url in-division-1 in-division-2 source-entities>] [: has-categories {is-capital}] [: subsumed-by spatial-entity]

  12. Types and attributes • The information about the range of attributes for each type is sufficient for many purposes, e.g. for writing entityfiles • However, for the purpose of type checking it is necessary to have information about the permitted contents in each attribute value • This is done using additional attribute assignments

  13. Example of entity and its type --------------------------------------------------------- -- København [: type city] [: lang-name {[: English "Copenhagen"] [: Swedish "Köpenhamn"]}] [: in-country Denmark] [: website "http://www.kk.dk/"] [: map-url "http://www.nationsonline.org/oneworld/map/google_map_Copenhagen.htm"] [: source-entities {[: wordnet Copenhagen.n0]} .. .. ] --------------------------------------------------------- -- city [: type Type] ... --------------------------------------------------------- -- type [: type Attribute] [: valuetype Type] --------------------------------------------------------- -- lang-name [: type Attribute] [: valuetype (mapping language String)] --------------------------------------------------------- -- in-country [: type Attribute] [: valuetype (join country countrypart autonomous-region territory...)] --------------------------------------------------------- -- website [: type Attribute] [: valuetype String]

  14. Example of entity and its type --------------------------------------------------------- -- København [: type city] --------------------------------------------------------- -- city [: type Type] [: attributes {in-country ...}] --------------------------------------------------------- -- in-country [: type Attribute] [: valuetype country] /simplification/ --------------------------------------------------------- -- type [: type Attribute] [: valuetype Type] --------------------------------------------------------- -- attributes [: type Attribute] [: valuetype (setof Attribute)] --------------------------------------------------------- -- Type [: type Type] [: attributes {attributes}] --------------------------------------------------------- -- Attribute [: type Type] [: attributes {valuetype}] ---------------------------------------------------------

  15. Example of entity and its type --------------------------------------------------------- -- København [: type city] --------------------------------------------------------- -- city [: type Type] [: attributes {in-country ...}] --------------------------------------------------------- -- in-country [: type Attribute] [: valuetype country] /simplification/ --------------------------------------------------------- -- type [: type Attribute] [: valuetype Type] --------------------------------------------------------- -- attributes [: type Attribute] [: valuetype (setof Attribute)] --------------------------------------------------------- -- Type [: type Type] [: attributes {attributes}] --------------------------------------------------------- -- Attribute [: type Type] [: attributes {valuetype}] ---------------------------------------------------------

  16. Signature tower supersignature pol-geography cities

  17. Self-describing supersignatureincomplete, and after some renaming for readability:has-attributes instead of attributes, etc. --------------------------------------------------------- -- Type [: has-type Type] [: has-attributes {has-attributes}] --------------------------------------------------------- -- Attribute [: has-type Type] [: has-attributes {has-valuetype}] --------------------------------------------------------- -- has-type [: has-type Attribute] [: has-valuetype Type] --------------------------------------------------------- -- has-attributes [: has-type Attribute] [: has-valuetype (setof Attribute)] --------------------------------------------------------- -- has-valuetype [: has-type Attribute] [: has-valuetype (join Type (setofexpr Type) --- ??? )] ---------------------------------------------------------

  18. Signature conformance criteria • Apply to a pair of knowledgeblocks, viz. the object block and its signature • The signature must conform to its signature • All entities in the object block must have a has-type attribute whose value is a type entity in the signature • All attributes of an entity in the object block must be in the has-attributes attribute value in the signature • All attribute values in the object block must conform to the value of the attribute's has-valuetype attribute in the signature • The signature tower must be topped by a circular structure (of one or more blocks).

  19. Problem • Some of the information in the supersignature is also needed on the object level, e.g. the knowledgeblock 'cities' • Fortunately, we have (if the unions shown here are OK): • If A and B are knowledgeblocks and both A and B conform to B, then A U B conforms to B and to A U B, and A conforms to A U B. • Therefore, given a supersignature SS that conforms to itself, every time we have a signature S that conforms to SS, we can use S U SS as the signature for object knowledge-blocks • Moreover, this makes it possible to have adjoining blocks to e.g. the supersignature.

  20. Signature tower supersignature measures time pol-geography cities

  21. Signature tower supersignature measures time pol-geography cities

  22. Signature conformance criteria, revised • Apply to a pair of knowledgeblocks, viz. the object block and its signature • The signature must conform toitself • All entities in the object block must have a has-type attribute whose value is a type entity in the signature • All attributes of an entity in the object block must be in the has-attributes attribute value in the signature • All attribute values in the object block must conform to the value of the attribute's has-valuetype attribute in the signature

  23. Fully self-describing supersignature • A number of additional operations have to be added to the supersignature, besides what was shown above, in order to obtain one that conforms to itself according to the above definition • However, this can be done; the details are in the lecture notes • The program for conformity checking produces a validation report which is also expressed as an entityfile • Knowledgeblocks that are to be published in the Common Knowledge Library are provided with such a validation report.

  24. Example of validation report, I --------------------------------------------------------- -- verify-super-cities-01 [: type verification-schema] [: files-to-check {travel-onto}] [: types-to-check All] [: knowledgeblocks {signatures-kb travel-domain-kb}] [: background-files {supersignature scalars-signature cognonto general-attributes-signature naming-domain-onto}] [: program-files {typecheck}] [: lastinstance verify-super-cities-01-001] --------------------------------------------------------- -- verify-super-cities-01-001 [: type verification-instance] [: in-schema verify-super-cities-01] [: executed-on "2008-05-12/22:05"] [: versions-of-files {[: travel-onto <"2008-05-12/22:00">] [: supersignature <"2008-05-12/12:00">] [: scalars-signature <"2007-10-13/23:26">] [: cognonto <"2008-05-12/20:32">] [: general-attributes-signature <"2008-05-12/14:10">] [: naming-domain-onto <"2008-05-07/09:13">] [: typecheck <"2008-05-12/11:57">]}]

  25. Example of validation report, II -------------------------------------------------------- -- verify-cities-01 [: type verification-schema] [: files-to-check {emena-cities sapr-cities latamer-cities afreg-cities}] [: types-to-check All] [: knowledgeblocks {signatures-kb naming-domain-kb cities-kb}] [: signature-files {homonym-list supersignature travel-onto general-attributes-signature}] [: background-files {countries-main countries-subdivisions countries-odd Languages-info .. .. }] [: program-files {typecheck}] [: lastinstance verify-cities-01-001] --------------------------------------------------------- -- verify-cities-01-001 [: type verification-instance] [: in-schema verify-cities-01] [: executed-on "2008-05-12/22:05"] [: versions-of-files {[: emena-cities <"2008-05-11/08:29">] [: sapr-cities <"2008-05-08/16:22">] [: latamer-cities <"2008-05-08/16:50">] [: afreg-cities <"2008-05-08/16:38">] [: homonym-list <"2008-05-05/12:00">] [: supersignature <"2008-05-12/12:00">] [: travel-onto <"2008-05-12/22:00">] [: general-attributes-signature <"2008-05-12/14:10">] [: countries-main <"2008-05-12/14:06">] .. .. }]

  26. Leonardo ontology structure

  27. Top level of the Leonardo ontology • Two attributes: type and subsumed-by • The type attribute is like before; short chains; local usage; specifies correct formal structure wrt attributes etc • The subsumed-by attribute is used as in e.g. • dog subsumed-by mammal • it reflects meanings and allows significantly longer chains • The subsumed-by hierarchy must be extended successively when knowledgeblocks are added to a session • See ontology diagram and the entityfile Core/cognonto in your Leonardo agent for how this works in practice.

  28. thingtype thing individual- entity person Bo_Svensson qualitytype quality visible-quality red color light-red

  29. The two ontological dimensions • Metatype subsumes thingtype, qualitytype, spacetime-type, descriptor-type and aggregate-type • Normally three 'horizontal' levels: metatype, type, object • Subsumption always meaningful on type level • Object level under qualitytype admits subsumption • Object level under thingtype does not in general admit subsumption • If multiple subsumption is requested then a third, set-valued attribute has to be introduced besides type and subsumed-by

  30. SUMO top-level ontology • Begins with definitions of concepts in discrete mathematics and formal logic • Not well modularized • Examples from the base ontology will be displayed in the lecture

  31. (first case; more in next lecture) Multiple inheritance with exceptions

  32. Overriding Grey-animal White-animal Elephant Royal-elephant

  33. Specificity Grey-animal White-animal Elephant Royal-elephant Clyde

  34. Specificity Grey-animal White-animal Elephant Royal-elephant Clyde

More Related