Ontology storage & management and Integration within 3D city models

1. Ontology storage & managementandIntegration within 3D city models Gilles Falquet Claudine Métral Université de Genève CUI - IAUG COST C21 - Lyon - 2005 –– 1

2. Contents • Managing multipoint of view ontologies • Storing and interfacing ontologies • Integrating data, ontologies and 3D city models COST C21 - Lyon - 2005 –– 2

3. The ConcepTerm Experiment • Goal: • build a terminological database in a specific domain (furniture) • provide description-based access • povide a description language for terminologists • 1000 concepts • drawn from sources in 4 different languages • Do not rely on usual equivalences • (chair, chaise, sedia)  3 concepts • compute equivalence based on concept definitions COST C21 - Lyon - 2005 –– 3

4. Term equivalence based on characteristics armoire < meuble de rangement size: grand part [1, * ]: corps, part [1, * ]: porte, part [several] : tablette main use: (verb: ranger, object: {linge or vêtements} ) cupboard < closet part [several] : shelf main use: (verb: store, object: household goods ) COST C21 - Lyon - 2005 –– 4

5. Managing conflicts in ontology building • Context: • building an ontology with a lexical level • concept --> {term} • concept --> definition • set of semantic relationships • description logic • Conflict: • in a specialized domain • [Gaines & Shaw] same term --> different concepts • ==> resolution process (agree on a definition) COST C21 - Lyon - 2005 –– 5

6. Multipoint of view model • Accept several definitions for a term • Provided • they belong to different point of views • their interpretations are "sufficiently close" • What is an electron ? • physicist: "particle with charge +1, spin 1/2 and ... " • chemist: "part of atoms, agent of chemical bounds ..." • electrical engineer: "current carrier ..." COST C21 - Lyon - 2005 –– 6

7. Operations to manage the process • Concept comparison • syntax-based approach • semantically sound • Incompatibility detection • Generation of new alternative definitions • union, intersection, difference • Add an argumentation layer on top of the ontology COST C21 - Lyon - 2005 –– 7

8. CTIBIS Model point of view belongs to term concept definition definition element argument endorsement COST C21 - Lyon - 2005 –– 8

9. The UNL Plaza • A portal to ontologies developed in several places • Part of the Universal Networking Language project • Goal: build a reference ontology for the UNL • Format: semantic network (60 types of relations) COST C21 - Lyon - 2005 –– 9

10. Concepts designated by "universal words" • bank(icl>building) • bank(icl>organization) • bank(icl>shore) • language independent, but human readable • Language dictionaries • Universal Word ==> Natural Language Word COST C21 - Lyon - 2005 –– 10

11. Distributed development • Top level ontology • + UW (re)defined for specific translation projects • The same UW can be defined several times • different point of views, different needs • UW may be updated and even deleted • ==> Managing several point of views • ==> Managing several versions COST C21 - Lyon - 2005 –– 11

12. versions UNITAR KB Tokyo KB Tokyo KB UNL KB São Paulo KB import submission Plaza interactive access preparation export Extracted KB NLP application COST C21 - Lyon - 2005 –– 12

13. Managing point of views • Point of view == source • Each concept definition is tagged with its (creator/date) • one concept (UW) ---> 1 or more definitions • Semantics • references to UWs, not to definitions • to fix the semantics => define a selection order among creators • used to produce extracts (partial KBs) COST C21 - Lyon - 2005 –– 13

14. Managing versions • Each definition has a version no. • Different kind of versions • working • stable (current) • archived • deprecated (the creator does not define this UW anymore) COST C21 - Lyon - 2005 –– 14

15. Ontology storage and interfacing • Ontology representation in relational databases • simple • semantic networks (2 tables) • description logic definitions (3-4 tables) • Take advantage of DBMS functionalities • concurrency control, security, integrity • query languages • Integration with organizational data and documents • Tools to create basic Web interfaces COST C21 - Lyon - 2005 –– 15

16. Beyond relational storage • Difficult to compute inferences • Relational DB languages are not Turing complete • storage is not efficient for this type of computation • Next step • use RDF/RDFS storage systems • automatic inference of properties (inheritance) • query with SPARQL (and others) • develop connections with instances stored in relational databases COST C21 - Lyon - 2005 –– 16

17. User interfaces • Very simple data structure (a few tables) • Complex contents (concept definitions, graphs) •  • "Standard" DB interfaces are insufficient, unusable • Hypertext view approach • the user sees the ontology as a hypertext • easy to use / learn • reflect the connected nature of knowledge • integrate (multimedia) data and documents • adapt to specific domains / tasks COST C21 - Lyon - 2005 –– 17

18. A specification approach to interfaces • Specify hypertext node and link types and how to create them from the ontology • Easy to adapt to various needs hypertext view specification generation (dynamic) ontology data / doc hypermedia interface HTML, VRML COST C21 - Lyon - 2005 –– 18

19. Example: exhibition hall metaphor COST C21 - Lyon - 2005 –– 19

20. Future work: IUKA 3D • Long term goals • Provide communication tools for stakeholders • Explain master plans or neighborhood plans to non-specialists • Short term goals • Explore how 3D scenes interfaces can help peopleunderstand and discuss urban planning concepts • Methodology • Develop tools to rapidly produce 3D scenes interfaces (3D hypertexts) • Develop a specification language: concepts->forms • Develop layout managers to position the hypertext nodes COST C21 - Lyon - 2005 –– 20

21. Future work • 3D City Model based spatial hypertext • Hypertext nodes geometrically constrained by a 3D city model: • geometric position relative to the city model • nodes not placed anywhere • the underlying city model used to specify their location • Examples:on top of building Aon the south façade of building Bbetween C and D COST C21 - Lyon - 2005 –– 21

22. A formalism to specify the 3D representation of urban concepts In collaboration with urban actors Not a fixed representation: related to the designer’s choices Define 3DCM layout managers Neighborhood plan text related to the building plan text building 3D entity COST C21 - Lyon - 2005 –– 22

23. Implement an interface generator • Takes as input • a 3D city model, • a knowledge base • a 3D representation specifications • 3DCM-based layout specifications • Produces as output • a spatial hypertext • constrained by the 3D city model • presents the knowledge base according to • the 3D specifications chosen by the designer COST C21 - Lyon - 2005 –– 23

24. Project IUKA3D Neighborhood plan text related to the building plan text building 3D city model 3D entity Interface generator COST C21 - Lyon - 2005 –– 24

25. Questions ? COST C21 - Lyon - 2005 –– 25