Ontology for Moving Points/Objects/Change... What can ontology contribute to our debate?

1. Ontology for Moving Points/Objects/Change...What can ontology contribute to our debate? • Andrew U. Frank • Geoinformation • TU Vienna • frank@geoinfo.tuwien.ac.at • www.geoinfo.tuwien.ac.at

2. Andew U. Frank From Moving Points to Moving Objects – an ontological contribution in 3 pieces: • 1. andante: What should an ontology for moving objects contain? • 2. largo: How to formalize an ontology for moving objects? • 3. vivace: What can we achieve with it?

3. Andew U. Frank Ontology today • Ontology in information science is defined as • “an explicit formal specification of the terms in the domain and relations among them”.

4. Andew U. Frank Ontology captures structure • Structure of the data is represented in • is_a relations • part_of relations • Instance relations

5. Andew U. Frank Two critical observations: • 1. a static view: no process, no operations, nothing changes; • 2. it is very difficult: • imagine how difficult it is to describe the structure of a dish (e.g. apple pie) in contrast to the recipe (a description of a process)

6. Andew U. Frank Discussing ontology means first discussing the formal methods to describe ontologies: • Natural language descriptions of ontologies are not clarifying the semantics an ontology purports to clarify.

7. Andew U. Frank Formal methods to describe ontologies (highly simplified): • 1. Construct a particular formal language for the type of ontology you are interested in: • - ontology for GIS • - ontology for moving objects • - ontology for flocks ...

8. Andew U. Frank Ontology languages 1: UML • Informal, but extensive use: • Uniform Modeling Language (UML) – limited by lack of formal definition – no conclusions drawn or consistency checked automatically. • Tools (graphical editors) for UML are available: • Nice, easy to use, flexible – but no formal background, therefore no fixed semantics, not much can be checked for consistency!

9. Andew U. Frank Ontology languages 2: Description logics • consists of • A set of unitary predicates denote concept names • A set of binary relations, which denote role names • Recursive constructors to form more complex constructs from the concepts and roles.

10. Andew U. Frank Many variants of Description Logics: • Various DL with different levels of expressive power and computational complexity, depending which constructors are included: • union and intersections of concepts • negation of concepts • value (universal) restriction • existential restriction

11. Andew U. Frank Actual languages: • The Web Ontology Language OWL (the culmination from a sequence of KL-ONE (1985).... DAML, OIL, DAML+OIL). • A compromise between expressive power and tractability of logical deductions (goal: consistent theory!)‏ • Practically: very limited and difficult to use.

12. Andew U. Frank Example “Person - Gender”: • <rdf:RDF • xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" • xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" • xmlns:owl="http://www.w3.org/2002/07/owl#" • xmlns="http://localhost:8080/OWLBuergerInformation.owl#" • xml:base="http://localhost:8080/OWLBuergerInformation.owl"> • <owl:Ontology rdf:about=""/> • <owl:Class rdf:ID="Gender"/> • <owl:Class rdf:ID="Person"/> • <owl:Class rdf:ID="Woman"> • <rdfs:subClassOf rdf:resource="#Person"/> • <owl:equivalentClass> • <owl:Restriction> • <owl:onProperty rdf:resource="#Gender"/> • <owl:hasValue rdf:resource="#female" rdf:type="#Gender"/> • </owl:Restriction> • </owl:equivalentClass> • </owl:Class> • <owl:ObjectProperty rdf:ID="gender" • rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> • <rdfs:range rdf:resource="#Gender"/> • <rdfs:domain rdf:resource="#Person"/> • </owl:ObjectProperty> • <owl:DatatypeProperty rdf:ID="name" • rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> • <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> • <rdfs:domain rdf:resource="#Person"/> • </owl:DatatypeProperty> • <owl:DatatypeProperty rdf:ID="firstname" • rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty"> • <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> • <rdfs:domain rdf:resource="#Person"/> • </owl:DatatypeProperty> • <Person rdf:ID="STilgner" firstname="Susanne" name="Tilgner"> • <Gender rdf:resource="#female"/> • </Person> • </rdf:RDF>

13. Andew U. Frank Ontology editors, e.g. Protege • Ontology editor based on description logic. • Produces ontologies in different output languages (e.g. OWL-Light). • Very difficult to use, very time consuming.

14. Andew U. Frank Example: definition of pizza • Gives list of incredients (structure) but not the process of baking one!

15. Andew U. Frank Extend ontology descriptions with time, change, process • Why is this difficult? • 1. First order logic is essentially static, adding time • - adds confusing bulk to expression: • move (P, A, B, T) :- • is_at (P, A, T1) & is_at (P, B, T2) & before (T1, T) & after (T2, T)‏ • - frame problem: • need to state what does not change to allow logical inference

16. Andew U. Frank First order logic: • Difficult to represent change and process in first order logic • (complicated temporal logics would be needed)‏

17. Andew U. Frank Using existing languages for ontology modelling: • Algebraic background, to be prepared to describe operations and change. • Mathematical rigor and simplicity: • functional languages.

18. Andew U. Frank Example: • Specification of classes • “Boat House” and “Houseboat”. • (Kuhn:Cosit'06) in Haskell (www.haskell.com)‏ • Gives: • classes and subclasses • operations for objects of these classes • Semantics is defined by operations!

19. Andew U. Frank Ontologies with operations is an object-oriented ontology! • In an object orientation view the world consists of • objects with operations! • The object-oriented research in software engineering concentrates uses an algebraic approach to model object classes and operations applicable to the objects.

20. Andew U. Frank Formalization Subclass: • Dogs are Animals; they breath and bark: • class Animals a where • breath :: a -> StateChange World • class Animals => Dogs d where • bark :: d -> StateChange World • eat :: d -> f -> StateChange World

21. Andew U. Frank Programming with inheritance: • The is_a relation does not translate directly to the operations. • class Numbers n where • division :: n -> n -> n • instance Numbers Rational • instance Numbers Int • Int is subset of Rational

22. Andew U. Frank 2nd Problem: Contravariance of Functions functions are contra-variant: applying a function to subsets of the arguments does not guarantee that the result will be a subset of the result of the original function.

23. Andew U. Frank Solution • Parametric polymorphism, as shown in the above example, where • class Numbers n where ... • has a parameter n. • The usual ad-hoc polymorphism of current programming languages (C++, Java) is not theoretically clean.

24. Andew U. Frank Formalizing 1: Moving point • a moving point is a list of tuples (fixes)‏ • t, x, y (,z)‏ • this is what most understand by trajectory, interpreting that the same point was observed at the given location at the given time.

25. Andew U. Frank Formalizing 2: Moving point as a function • a moving point is a function • p (t) = ... • e.g. • p (t) = (x0 + vx * t, y0 + vy * t)‏ • but using a lookup function in the list of fixes and interpolating between known locations can be written as a function as easily.

26. Andew U. Frank Formalizing 3: Moving and changing objects • an object can not only change position, but any other property (heading, speed, color, ownership...)‏ • Model each property as a function from time and objectID to value • e.g. speed (ID, t) = v • color (ID, t) = c

27. Andew U. Frank Formalizing 4: Many changing objects in a world • Populate a world with many objects which change (e.g. SWARM). How to check for interaction between objects, expressed formally! • (Model objects as autonomous agents, with capabilities to obseve the world...)‏

28. Andew U. Frank Formalizing 5: Operations of objects produce change in the state of the world: • operations for objects start with a state of the world and result in a changed new world state: • op:: ID -> WorldState -> WorldState • w1 := op (id, w0)‏

29. Andew U. Frank Formalizing with Monads: • op :: ID -> ChangeWorldState • (where ChangeWorldState = WorldState -> WorldState)‏ • The result of applying an operation to an object (and possible additional parameters) is a function, chaning the world from current state to a next state.

30. Andew U. Frank Special Monad, so called State Monad: • nice algebraic properties for the monad opereations “return” and “binb”: • "return" must preserve all information about its argument. • (return x) >>= f ≡ f x • m >>= return ≡ m

31. Andew U. Frank Special Monad, so called State Monad: • Binding two functions in succession is the same as binding one function that can be determined from them. • (m >>= f) >>= g • ≡ m >>= (\x -> f x >>= g)‏

32. Andew U. Frank Special Monad, so called State Monad: • A monad can define a "zero" value for every type. Binding a zero with any function produces the zero for the result type, just as 0 multiplied by any number is 0. • mzero >>= f ≡ mzero • Similarly, binding any m with a function that always returns a zero results in a zero • m >>= (\x -> mzero) ≡ mzero

33. Andew U. Frank Paradigm change necessary: • Two traditions that are hindering temporal GIS and the necessary ontologies with processes: • - logic (especially Description Logics)‏ • - Inheritance in (imperativ) programming languages (especially C++ and Java)

34. Andew U. Frank Ontology description with algebra : • operations are explicit changing state to new state • t1 = f (t0)‏ • class hierarchy with parametrised polymorphism. • Tools: functional programming languages (eg. Haskell, Caml, Scheme, ML)‏

35. Andew U. Frank Paradigm change must fix more than one problem! • I have argued for a paradigm change in the methods to describe ontologies. • Does this address other pressing problems?

36. Andew U. Frank An ontology based on operations could be used to more than just “clarify semantics”: • The ontology gives a theory! • Constructing a model checks that the model corresponds to our intuition. • Formal ontologies should allow entering instances and observe their behaviour (e.g. Protege)‏

37. Andew U. Frank How? • The data structure part (static ontology) can be used to present the data – this is standard for administrative data processing. • The operations described in the ontology give a computational model.

38. Andew U. Frank Ontology with operations equals “prototype application” • Test the ontology! Improve code where not appropriate. • Ontology gives automatically (minimal, but standardized) interface. • Slogan: • GUI's from ontology for free! • How? Translate the operations to buttons and feed the user input to them!

39. Andew U. Frank Finale • It is necessary and worthwhile to jump to a new paradigm and build ontologies with operations!