SMS Service Interfaces

This is version 36. 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>

}   

Search: Simple 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).

Optimized searching

In general, the search operation requires access to all semantic annotations to find matching resources. For example, if a search expression requires both concepts A and B, the algorithm must look for annotations that explicitly state A and B as well as those that state only A and only B (which taken together make A and B). Thus, for remote searches, the algorithm must consider all remote annotations to find matching resources. Because of this requirement, as the number of semantic annotations increases, this operation can become expensive.

We may reduce the cost of search by adding additional services that can be executed locally at each repository and by altering the search algorithm. The additional services are:

getRepositories()                               ::  Set<RepositoryID>

getResources()                                  ::  Set<ResourceID>

partialSearch( ConceptExpression, ResourceID )  ::  Set<ConceptExpression>

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