Outline

Goals of our project

Accomplishments to date

Planned activity / deliverables

Metrics

Ontology Translation

Must be done by people (people who understand what the component ontologies mean)

What the computer can do is manage ontology mappings:

Suggest correspondences (based on linguistic and structural similarities)

Keep track of component versions

Note contradictions

Apply mappings to datasets (even when datasets make use of multiple ontologies)

Log translation successes and failures

Ontology Translation
= Merging + Deduction + Projection

Bridging Axioms

“When Ontologies Collide”

Example

Significant Accomplishments

Developed model of ontology translation

Implemented a tool for translating PDDL (Planning Domain Definition Language) into DAML (and vice versa)

Implemented DAML mode for Emacs

Wrote type checker for enhanced PDDL

Developed and implemented algorithm for producing interaction plans based on formal descriptions of web services (with DAML-S)

Translated UMLS Medical Ontology into DAML

PDDL <-> DAML

Planned Activity in 2002

Bring our “ontology server” on-line.

Make the PDDL <-> DAML system more supple.

“Webify” our PDDL dialect (e.g., allow a domain to inherit from another located at a URL).

Port existing theorem provers. (Prolog-style for forward and backward chaining, Snark-style for contradiction hunting).

Adapt our glue-code algorithm for the projection task.

Create ontologies to translate! The current ones are mainly defined by English comments.

Deliverables This Year

Ontology server on line

“Thick” ontologies for geoloc information, other domains (esp. those used in ONA)

Suite of tools for

Translating from RDF to PDDL and/or MetaSlang with maximal transparency

Making web content visible as predicate calculus, XML, or HTML

Doing common theorem-proving tasks (e.g., drawing conclusions from a dataset of similar facts)

Logging ontology-service requests, followup on success/failure

Metrics

Number of translation successes / number of attempts

If denominator is zero, we have an obvious problem

Hence “number of attempts” is itself an important metric

How many people/agents try to use the server

Must provide human-friendly interface as well as an automated one

It should be possible to provide a WSDL description of the server as a web service, and register it in a UDDI registry

Any Questions?


	Goals of our project
	Accomplishments to date
	Planned activity / deliverables
	Metrics


	Must be done by people (people who understand what the component ontologies mean)
	What the computer can do is manage ontology mappings:
		Suggest correspondences (based on linguistic and structural similarities)
		Keep track of component versions
		Note contradictions
		Apply mappings to datasets (even when datasets make use of multiple ontologies)
		Log translation successes and failures


	Developed model of ontology translation
	Implemented a tool for translating PDDL (Planning Domain Definition Language) into DAML (and vice versa)
	Implemented DAML mode for Emacs
	Wrote type checker for enhanced PDDL
	Developed and implemented algorithm for producing interaction plans based on formal descriptions of web services (with DAML-S)
	Translated UMLS Medical Ontology into DAML


	Bring our “ontology server” on-line.
		Make the PDDL <-> DAML system more supple.
		“Webify” our PDDL dialect (e.g., allow a domain to inherit from another located at a URL).
		Port existing theorem provers. (Prolog-style for forward and backward chaining, Snark-style for contradiction hunting).
		Adapt our glue-code algorithm for the projection task.
	Create ontologies to translate! The current ones are mainly defined by English comments.


	Ontology server on line
	“Thick” ontologies for geoloc information, other domains (esp. those used in ONA)
	Suite of tools for
		Translating from RDF to PDDL and/or MetaSlang with maximal transparency
		Making web content visible as predicate calculus, XML, or HTML
		Doing common theorem-proving tasks (e.g., drawing conclusions from a dataset of similar facts)
		Logging ontology-service requests, followup on success/failure


	Number of translation successes / number of attempts
	If denominator is zero, we have an obvious problem
	Hence “number of attempts” is itself an important metric
		How many people/agents try to use the server
		Must provide human-friendly interface as well as an automated one
		It should be possible to provide a WSDL description of the server as a web service, and register it in a UDDI registry