Ontology Language Extension to Support Collaborative Ontology

BuildingJie Bao and Vasant Honavar

Artificial Intelligence Research Laboratory, Computer Science Department, Iowa State University

Ames IA USA 50010 {baojie,honavar}@cs.iastate.edu

What is it about?

POWL, package-based OWL, a language extension of OWL to represent modularity and localized semantics in ontology is proposed

A model theoretical semantics A XML syntax and an OWL-

compatible syntax Distributed reasoning over POWL

Why Package ?

By its very nature, ontology construction is a collaborative process.

However, current ontology languages are reminiscent of the early programming languages Uncontrolled use of global

variables Spaghetti code Unwanted and uncontrolled

interactions between fragments Difficult to reuse

Modularity and controlled access to ontology fragments are the key solutions

?

Localization vs. Globalization Ontologies represent local views of the world Global semantics could lead to semantic conflicts

A:AsianStudy A:EuropeanStudy = B:AsianStuy A:AsianStudy B:EuropeanStudy A:EuropeanStudy B:TurkeyStudy B:AsianStudy B:EuropeanStudy

Semantics should has its ‘scope’

Partially vs. AllOrNothing Lack of modularity in ontologies forces an all or nothing choice in reusing an existing ontology.

Eg: how to import part of WordNet or GeneOntology ?

Modular ontologies could facilitate more flexible and efficient reuse

Save communication cost (in MB or GB)Reduce memory requirement and parsing time.Focus on want you really need!

Hiding vs. Sharing The provider may only wish to expose partial ontology

copyright considerations, Privacy, security concerns

Hiding definition details of an ontology module may help safe ontology organization

Reduce unexpected coupling, Separate “implementation” and “interface”

Organizational vs. Semantic Structure Organizational structure: how to arrange terms for better usage and understanding

Eg: Computer Science Dictionary and Life Science Dictionary

Semantic structure: how the meaning of terms is related

Eg: ‘Mouse’ is a kind of ‘Animal’ or ‘Mouse’ is part of ‘PC’

Organizational structure is needed even when semantic structure is missing or different

Eg: A long list of instances of the same class

Semantics Syntax

Package

P1

P2

public

private

A package is an ontology module with clearly defined access interface; A package is part of a logic system P is the domain of all packages.Nested Package

A nested package is part of another package Could be used to represent organizational structure

Entity An ontology entity is an axiom e=[C|P|I] where C is a class (concept) definition axiom, P is a property (relation) definition axiom and I is an instance (object) definition axiom. Each entity belongs to a (home) package.

Scope Limitation Modifier

Scope Limitation Modifier of an ontology entity t is a boolean function V(t,r), where r is the identifier of a package that refers t. Package(r) could access t if and only if V(t,r) = True. Predefined SLM

Public (t,r): t is accessible from anywhere Private (t,r): t is only available in home package Protected(t,r): t is accessible from home package and nested packages.

View and Interface View-based information integration

View is a set of query over one or more ontology packages. Interface is view defined on only one package

Views and interfaces offer a flexible mechanism to reuse packages:

A Package with multiple interfaces

P1

P2

P3

A View can be built upon multiple packages and can be referred to by

multiple modules

P1

P3 P4

P2

Option 1: XML extension to OWL A new set of tags are defined, eg powl:Package, powl:Public Incompatible with existing tools

Option 2: OWL/RDF-Compatible Syntax (POWL/RDF)

Embed the package information in OWL/RDF syntax, but with limited expressiveness. Package information can be obtained by reasoning Compatible with existing tools (Editor, Parser…)

POWL/XML

POWL/RDF

Package <powl:package rdf:ID=“animal"></powl:package><powl:package rdf:ID=“GlobalPackage"></powl:package>

<powl:package rdf:ID=“animal"> <owl:Class rdf:ID=“Dog“/> <owl:ObjectProperty rdf:ID=“eats”/> <Dog rdf:ID=“billy”></powl:package>

<powl:package rdf:ID=“animal"> <owl:Class rdf:ID=“Dog“ powl:SLM=“public”/> <owl:ObjectProperty rdf:ID=“eats” powl:SLM=“protected” /> <Dog rdf:ID=“billy” powl:SLM=“private” ></powl:package>

<powl:package rdf:ID=“animal"> <powl:import rdf:resource=“plant”/> (other term definitions…)</powl:package>

<powl:view rdf:ID=“life"> <powl:import rdf:resource=“animal”> <powl:import rdf:resource=“plant”> <owl:Class rdf:ID=“Dog“> <owl:equivalentClass rdf:resource=“animal:Dog" /> </owl:Class></powl:view>

<powl:package rdf:ID=“animal"> <powl:package rdf:ID=“myAnimal"> <owl:Class rdf:resource=“Dog”/> </powl:package ></powl:package>

<owl:Class rdf:ID=“animal "> <rdfs:subClassOf rdf:resource= “powl:Package" /></owl:Class>

powl:Package owl:Class powl:GlobalPackage ∈ powl:Package

ClassDog subClassOf restriction(powl: classIn hasValue (animal))

Propertyeats_helper powl: instanceIn animaleats_helper ∈ powl:Helpereats_helper ∈ eats. eats_helper

InstanceBilly ∈ DogBilly powl:instanceIn animal

ClassDog subClassOf restriction(powl: classPublicIn hasValue(animal))

Propertyeats_helper powl: instanceProtectedIn animaleats_helper ∈ powl:Helpereats_helper ∈ eats. eats_helper

InstanceBilly ∈ DogBilly powl: instancePrivateIn animal

NOTE: we will use “term inPackage package “ as abbreviations for those axioms

<powl:package rdf:ID=“animal"> <powl:import rdf:resource=“plant”/></powl:package> (other term definitions…)

NOTE: they are different! POWL/XML defined a ‘container’ for other definitions, while POWL/RDF defined a package instance that could be used in other triples.

life Viewlife powl:import animallife powl:import plantLife.Dog inPackage lifeLife.Dog animal:Dog

myFavoriteAnimal InterfacemyFavoriteAnimal powl:import animalmyFavoriteAnimal .Dog inPackage myFavoriteAnimal myFavoriteAnimal .Dog animal:Dog

Animal ∈ powl:packagemyAnimal ∈ powl:packagemyAnimal nestIn Animal Dog inPackage myAnimal

Helper:powl:nestIn powl:inPackage

Package

SLM

SLM

Importing

Importing

View

View

Nested Package

Nested Package

Reasoning

package or view could answer a Satisfiable request if a possible interpretation is found locally; otherwise it will consult the packages and views in its domain.

This research is supported in part by grants from the NSF (0219699) and the NIH(GM 066387) to Vasant Honavar