Kepler Meeting SMS Notes

This is version 4. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

The Semantic Mediation System and KEPLER

Back to Kepler Meeting Agenda

"Eco" ontologies

In SEEK we want to exploit "eco" ontologies for semantic annotation of services to do "smart discovery and integration"

Generic

Our solutions are meant to be generic, and applicable for KEPLER

• Ontologies

An ontology is a set of concept (class) names, subconcept (subclass) links, named (directed, binary) relationships between concepts, and constraints (cardinality, equivalence, conjunction, disjunction, etc.)

• Semantic Annotations

A semantic annotation assigns a 'selected item' to an ontology expression.

** 'Items'

*** Datasets

An entire dataset or some portion (a single table, one or more attributes, one or more data values, etc.)

*** Workflows and components A workflow, a workflow component, or some portion (parameters, ports, substructures of a port type, etc.).

** Item Selection Expressed in general as queries, however, simpler expressions can be used, e.g., XPath/XPointer addresses or possibly using EML identifiers

** Ontology expression An ontology expression defines the semantic "context" of the item selected

Ontology expressions can be as complex as SQL-style update queries or simpler, e.g., as single concepts or paths in an ontology

*** Path Example:

Measurement.spatialContext.loc.latDeg, specifying the location of a Measurement's spatialContext as a latitude in degrees

• Architecture

** Repositories

*** Ontology(ies)

*** Datasets (or metadata stating how to obtain the datasets)

*** Workflows and Workflow Components (or metadata, etc.)

*** Semantic Annotations

Basically, SMS "smart discovery and integration" needs access to these components.

For example, to search for a workflow component, the sms engine would search through semantic annotations, and when an annotation matches, obtain the corresponding component.

You might also want to organize (for browsing) all actors according to their annotations; so need to iterate over actors, or similarly, for datasets.

** SMS-Based Applications

*** Browsing/Keyword Search

Workflow and/or dataset browsing and keyword-search based on ontology concepts

*** Find "compatible" actors

Given an actor, find semantically compatible actors that can be connected as an input or output to the actor (this might result in a dataset as input, e.g.)

Requires port inputs/outputs to be semantically annotated

*** Workflow analysis

Given a workflow, check that each connection (input/output) is semantically compatibly.

As part of analysis, annotation propagation.

*** Workflow component structural integration

Given two components that are semantically compatible, determine a structural transformation (either another component or a transformation step) to make them structurally compatible.

May be a place where SCIA can contribute, to derive structural transformations.

*** Dataset merging/integration

Search for "similar" datasets (that could be potentially "merged" or integrated)

Define a dataset of interest (via an ontology-style query?), find/combine datasets as integrated "view".

Perhaps a place for SCIA to contribute?

** Tools

*** Ontology Editors/Browsers

*** Semantic Annotation Editor

*** Ontology-based query rewriting/answering

• "Smart" Actor Search in Kepler

A very simple keyword-based search implementation within Kepler.

Fakes out: workflow component LSIDs, an actor repository (as a ptolemy xml config file), annotation repository (xml file), LSID service.

The "ontology" is a simple hierarchy. No rels, etc.

• What's Needed for KEPLER

** Ontologies

There basically aren't any.

There also aren't any tools. No tools within Kepler.

** Repositories ...

The Obj. Mngr. can help! We don't have repositories for workflows/components, ontologies, annotations, or datasets in KEPLER.

For annotations, need a searchable "index" of annotations and ids (for components, datasets, etc.), and a mechanism to "retrieve" those items.

For performance, I wonder though if the "index" should be in memory.

** Semantic Annotation Editor This doesn't exist either ... lots of ways/approaches here.

Need GUI design for this. Also, need a good way to access/browse a component/dataset and its attributes, such as is ports and their input/output types.

Similar with datasets

The challenges are making this tool easy to use, and accessible within Kepler.

** Basic Kepler Interfaces / GUI Design

Like for searching, checking semantic compatibility (can steal unit resolver), explanation of semantics (like for searching, etc.)