1 / 25

Ontology Modules by Layering

Ontology Modules by Layering. Facilitating Reuse in a Geographical Semantic Web Context. 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?

cosima
Download Presentation

Ontology Modules by Layering

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. Ontology Modules by Layering Facilitating Reuse in a Geographical Semantic Web Context

  2. 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.

  3. 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

  4. Ontology Integration Possible Ontology [ On ] Objectives • Merger: OA + OB→ OC • Alignment: OA≡ OB≡ OC • Mapping: a virtual integration where OA, OB and OC 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.

  5. “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#" > <owl:Class rdf:about="&cyc;TransportationCompany"/> <owl:Class rdf:ID="RailOperator"> <rdfs:subClassOf rdf:resource="#RailwayComponent"/> <rdfs:subClassOf rdf:resource="&cyc;TransportationCompany"/> </owl:Class> …….. • Is this acceptable? How would an agent understand the Cyc context of the superclass of “cyc:TransportationCompany”

  6. “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# ……..> <owl:Class rdf:about=“&global;Artifact"/> <owl:Class rdf:ID="Helicopter"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:LinkProperty rdf:about="#hasForm"/> </owl:onProperty> <owl:someValuesFrom rdf:resource="&global;Artifact"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:LinkProperty rdf:ID="hasForm"> <owl:foreignOntology rdf:resource="&global;"/> <rdfs:domain rdf:resource="#Helicopter"/> <rdfs:range> <owl:foreignClass rdf:about="&global;Artifact"> <owl:foreignOntology rdf:resource="&global; "/> </owl:foreignClass> </rdfs:range> </owl:LinkProperty>

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

  8. 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

  9. 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

  10. 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.

  11. 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.

  12. Ontological Comparison • Multiple sub-domains • potential redundancy • vulnerability to change • How relevant are they? • 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 … • Only for an application that uses ALL concepts 1OTN - Ontology of Transportation Networks (Lorenz et al, 2005)

  13. Fixed Concepts Variable Concepts Ontology Permanence

  14. Fixed Classes Variable Classes Ontology Permanence

  15. 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 …..

  16. multimodal single-mode ? Land Transport

  17. Road-Rail Interchange

  18. M6 M67 A6 Our Transportation Domain

  19. M6 M67 A6 Transportation Domain Layers

  20. Railway sub-domain Conceptualisation

  21. 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

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

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

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

  25. 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

More Related