SMS Service Interfaces

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

Overview

The following lists the semantic mediation service interfaces:

interface ISemanticMediation {

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

   query( QueryExpression, RemoteFlag )  ::  Set<QueryResult>

   compatible( ResourceID, Connection, ResourceID, StructTypeFlag, RemoteFlag )  ::  Boolean
 
   searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag )  ::  Set<ResourceID>

   compose( ResourceID, Connection, ResourceID, RemoteFlag )  ::  Set<StructMapping>

   merge( ResourceID, Connection, ResourceID, RemoteFlag )  ::  Set<StructMapping>


   semanticType( ResourceID, String, RemoteFlag )  ::  ConceptExpression       // summarizing annotations

}   

The rest of this page describes each of these services and their dependencies.

Search: Simple Concept-Based Searching

search( ConceptExpression, Set<ResourceType>, RemoteFlag )  ::  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

The service returns a set of resources (as LSIDs) that have semantic annotations "matching" the given search term.

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). We assume each concept is associated to the ontology it is defined in (e.g., where the ontology is implied by the concept identifier).

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 remote flag). The last operation returns the ontology for a given ontology identifier (also a resource id).

Optimized Remote Searching

In general, the search operation requires access to all semantic annotations to find matching resources. For example, consider a search expression A and B, i.e., a resource must contribute to both concept A and concept B. To find appropriate matches for this search term, 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). Note that an annotation that states only A may be in one repository, while an annotation that states only B may be in another. Thus, for remote searches, the search algorithm must obtain and consider all remote annotations to find matching resources, making the search operation inherently centralized.

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, making it slightly less centralized. The additional services are:

getRepositories()  ::  Set<RepositoryID>

getResources( RepositoryID, Set<ResourceType> )  ::  Set<ResourceID>

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

Using these operations, the search algorithm would procede as follows, assuming that the remote flag has been selected. With the getRepositories service, the algorithm first obtains the available repositories from the local kepler object manager. The algorithm selects the first returned repository and with the getRepositories service, obtains the relevant resources in the respository. For each resource in the repository, the partialSearch service is used, which returns the parts of the concept expression that the resource matches (e.g., just the concept A). The algorithm then moves to the next repository, performing the same steps. However, for those resources already having partial matches (from the previous step), the algorithm reformulates the search term given to partialSearch to include only the additional required parts of the concept expression (e.g., just the concept B). Once a complete match is found, the resource is considered a match and is not further checked. Finally, the algorithm repeats the process until all repositories have been examined.

Query: Complex Concept-Based Searching

query( QueryExpression, RemoteFlag )  ::  Set<QueryResult>

Compatible: Checking Semantically Well-Formed Connections

compatible( ResourceID, Connection, ResourceID, StructTypeFlag, RemoteFlag )  ::  Boolean

SearchCompatible: Searching for Semantically Well-Formed Connections

searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag )  ::  Set<ResourceID>

Compose: Suggesting Well-Structured Actor Connections

compose( ResourceID, Connection, ResourceID, RemoteFlag )  ::  Set<StructMapping>

Merge: Suggesting Simple Merging of Heterogeneous Datasets

merge( ResourceID, Connection, ResourceID, RemoteFlag )  ::  Set<StructMapping>

SemanticType: Summarizing Semantic Annotations

semanticType( ResourceID, String, RemoteFlag )  ::  ConceptExpression