SMS Service Interfaces

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

Overview

The following operations are described in more detail below.

interface ISemanticMediation {
   search( ConceptExpression, Set<ResourceType>, RemoteSearchFlag )  ::  Set<ResourceID>
   query( QueryExpression, RemoteSearchFlag )  ::  Set<QueryResult>
}   

Concept-Based Searching

search( ConceptExpression, Set<ResourceType>, RemoteSearchFlag )  ::  Set<ResourceID>

The arguments for this service are:

1. A search term represented as a description-logic concept expression;
2. A set of resource types, e.g., "actor" and/or "dataset"; and
3. A flag denoting whether local or remote repositories are searched

We assume that (via a GUI) an initial search string has been converted to a description-logic concept expression. A concept expression can be single concept (like "Biomass") or a complex formula (including nested disjunctive and conjunctive formulas, and so on).

The search service depends on the following kepler object manager services:

getResourceType( ResourceID )               :: ResourceType
getSemanticAnnotations( RemoteSearchFlag )  :: Set<SemanticAnnotationID>
getOntology( OntologyID )                   :: Set<Ontology>

The first operation returns the resource type of a given resource identifier (an LSID). The second operation returns the set of semantic annotations known to the kepler object manager (including annotations stored on remote repositories depending on the value of the search flag). The last operation returns the ontology for a given ontology identifier (also a resource id).

In general, the search operation requires access to all semantic annotations (i.e., for remote searches all remote annotations) to find matching resources. Because of this requirement, as the number of semantic annotations increases, this operation can become expensive.

We can reduce the cost by indexing semantic annotations for search. In particular, we can define an index of the form: ontoSearchIndex ( ResourceID, ResourceType, SemanticType ) that can in particular, provide the functions:

AnnotationEngine:   ConceptExpression  getSemanticType( OntoSearchIndex, ResourceID )
AnnotationEngine:   Set<ResourceID>    getResourceIDs( OntoSearchIndex )
AnnotationEngine:   ResourceType       getResourceType( OntoSearchIndex, ResourceID )

This needs some work: what we want to do is, e.g., ask S1 it's resources (e.g., R1, R2, and R3) and then "ship" the expressions (C1 and C2)/R1, (C1 and C2)/R2, and (C1 and C2)/R3 only to S1, which would return R1/match, R2/C1, R3/C2, and then we would want to do something similar with S2: ask it what resources it has, then ship (C1 and C2)/RX to S2 except if X=2 or X=3, in which case we would ship (R2/C2) and (R3/C1), and so on

Here a semantic type is a concept expression generated from a semantic annotation. Providing and index over a resource's