Science Environment for Ecological Knowledge
Ecoinformatics site parent site of Partnership for Biodiversity Informatics site parent site of SEEK - Home
Science Environment for Ecological Knowledge









 

 

 



SMS Service Interfaces

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


Concept-Based Searching

The following service interface performs simple concept-based searching of resources:

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

This service takes the following three arguments:

  1. a search expression represented as a description-logic concept expression;
  2. a list of resource types (e.g., "actor", "dataset", etc.); and
  3. whether the search should be local or include remote repositories
The result of applying the operation returns a set of resources (as LSIDs) with semantic annotations that "match" the given search expression.

Here, we assume that an initial search string has been converted to a description-logic concept expression, which can be a simple concept id (like "Biomass") or a more complex formula (including nested disjunctive and conjunctive formulas, and so on).

The search operation requires the following kepler object manager services:

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

Both of these services are implemented by the kepler object manager. 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 (inlcuding any annotations stored on remote repositories denoted by the search flag argument). The last operation returns the ontology for a given ontology identifier (also a resource id).

We note that in general, the search operation requires access to all semantic annotations to determine matching resources (e.g., in the case of search expressions containing conjunctive formulas). As the number of semantic annotations increases, this operation could 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



Go to top   More info...   Attach file...
This particular version was published on 22-Feb-2005 23:28:55 PST by SDSC.bowers.