1. Ontology Modules by Layering Facilitating Reuse in a Geographical Semantic Web Context

2. Role of Semantic Web Ontology Conceptualise and convey a domain of interest. Agree and provide a vocabulary of terms to portray the hierarchical or taxonomic structure and the relationships and constraints. Serve as a vehicle to semantically link, or integrate, information across the Web. Facilitate information reuse – by consistency of terms and fitness- for-purpose. suitable for how it is going to be used

3. Ontology and Integration A Semantic Web lift-off requires critical mass and/via wider acceptance. Ontology development still at a stage where little interchange between organisations? Ontology Reuse is a key Integration benefit. Merger, Alignment and Mapping complexity issues when considering Integration.

4. Ontology and Integration Developer reluctance – easier to re-invent own dedicated local ontology specification than reuse. Reuse of an external ontology will likely result in descriptive and structural irrelevances. A move towards smaller component ontology modules – that can then be improvised as required – may encourage wider usage/take-up

5. Ontology Integration Possible Ontology [ O n ] Objectives 1. Merger: O A + O B → O C 2. Alignment: O A ≡ O B ≡ O C 3. Mapping: a virtual integration where O A, O B and O C concepts are semantically related. Methods –1 and 2 are achieved by rewriting (reformulation). –Original ontologies are subsumed or made consistent (respectively). –3 is achieved by mappings between concepts of imported ontologies. A, B and C endure autonomously. –Ontology Reuse, in this presentation, refers to 3: Mapping.

6. Ontology Mapping

7. “Informal” specific Class Reuse Using namespace declaration to explicitly specify a single external concept, e.g. <rdf:RDF xmlns="http://www.livewiredg.myby.co.uk/rdf/geo-layers/rail.owl#" xmlns:cyc="http://www.cyc.com/2003/04/01/cyc#" > …….. <rdf:RDF xmlns="http://www.livewiredg.myby.co.uk/rdf/geo-layers/rail.owl#" xmlns:cyc="http://www.cyc.com/2003/04/01/cyc#" > …….. Is this acceptable? How would an agent understand the Cyc context of the superclass of “cyc:TransportationCompany”

8. “Formalised” specific Class Reuse E-Connections Representation and reasoning with foreign ontologies (Grau et al, 2005) Allows specific concept linking. Few tools available e.g. SWOOP (OWL Ontology Editor) <rdf:RDF xmlns:global="http://www.livewiredg.myby.co.uk/rdf/geo-layers/global.owl#" xmlns=http://www.owl-ontologies.com/flight.owl# ……..> <rdf:RDF xmlns:global="http://www.livewiredg.myby.co.uk/rdf/geo-layers/global.owl#" xmlns=http://www.owl-ontologies.com/flight.owl# ……..>

9. “Formalised” specific Class Reuse partitioning generates same syntax as “informal reuse” example SWOOP permits ontology partitioning (module extraction)

10. Class reuse by Ontology Import Objective: Map Rail Ontology class “RailOperator” to Cyc Ontology class “TransportationCompany” Action: Import Opencyc into Rail > 6.8MB Effect: adds 2843 classes 1256 properties 6331 instances Protégé “out of memory” load time 1.5 to 7.5 mins

11. Alternative Reuse approach? Consider the way Ontologies structured? Break down domain ontologies into sub-components: effectively domain “sub-classes” (Layers / modules) How to demonstrate? Can be demonstrated using Geographical context

12. Why consider Geography Context? Geographical concepts interact with virtually every aspect of daily life. Geographical elements form a major part of information management systems. Geographical ontologies offer a logical vehicle, to examine how Web semantics can be specified efficiently and effectively.

13. Efficient and Effective: Context Efficient –Minimise rework: i.e. having to update a specification: whereas stability contributes to reusability. Developing durable ontologies: focus on permanence of terms and essentiality. –Minimise redundancy: avoiding duplication of terms: reduce mappings. Minimise query complexity and processing overhead. Effective –Using a consistent best practice approach: Accurately and meaningfully describing concepts: their relationships and constraints. Create small building blocks: small ontological components serving as utility pieces.

14. PC and Ontology Analogy Adding a component to a PC –To enhance our own PC, we would not buy a complete PC with all components specified, –It would require dismantling and refitting – some parts may not be compatible –Result: additional, unnecessary and costly extra work. Accepted Protocol –Build our requirement from small, interchangeable components –Preferably with multiple PC compatibility.

15. Ontological Comparison Ontology Reuse - Imports –should there be a similar approach? –E.g. if OTN 1 is imported: what do we see? –Ontology much smaller than Cyc, but … Multiple sub-domains –potential redundancy –vulnerability to change How relevant are they? Only for an application that uses ALL concepts 1 OTN - Ontology of Transportation Networks (Lorenz et al, 2005)

16. How could we quantify Import issues? Possible Import Inefficiency Metrics Filesize % O A : O B Classes % O A : O B Relevance %O A : O B Load Time % O A : (O A + O B ) Ontology Durability (or Permanence) % O B How well specified is it, in terms of quality of constraints / definition?

17. Ontology Permanence Fixed Concepts Variable Concepts

18. Ontology Permanence Fixed Classes Variable Classes

19. Transport Ontology How might we approach developing a modular ontology set? Previously discussed considering “map layers” No scientific justification for this - but offers a conceptual discipline that could be exploited for our purposes Example: consider a “LandTransport” ontology …..

20. Transport Ontology Applications –Passenger services –Freight services –Tourism –Strategic: route planning and development –Supply industry –Infrastructure planning –Environment and Energy: Waste, pollution, traffic volumes, resource consumption. –Disaster management

21. Land Transport multimodal single-mode ?

22. Road-Rail Interchange

23. Our Transportation Domain M67 M6 A6

24. Transportation Domain Layers M67M6 A6

25. Railway sub-domain Conceptualisation ContainerTerminalhasRoleLoadingPoint UnloadingPoint accessedViaFreightLine RailwayJunction servedByFreightOperator

26. Developing Layers Need to “de-integrate” to allow low-cost integration We are aiming towards “effectively” disjoint domains Achieved by removing concept redundancy – potential duplication Need to promote/relegate concepts and relations Represents a separation of Form and Function both within and between ontology modules e.g. see …… TransportInterchange, LevelCrossing

27. Rail Transport Ontology Road domain Q: rename LevelCrossing → RoadCrossing? But we don’t do roads in rail!

28. Road Transport Ontology Rail domain Q: rename LevelCrossing → RailCrossing? But we don’t do rail in roads!

29. Road-Rail Ontology: Multimodal DriveOn-DriveOffRole TransportInterchange ChannelTunnel Terminal LevelCrossing

30. Development Issues Relegation and Elevation Declare parameters for ontology Scope of ontology development –Purpose and Objectives Concept and Relation definitions

31. Specifying Scope, Conceptualisation

32. Benefits and Issues Advantages –Small is manageable –Select only required building block modules –Independent therefore less vulnerable to change –Change is isolated to the module and subsuming domain? Disadvantages –Increased mappings? –Needs to be examined