| Line 1 was replaced by lines 1-5 |
| - !! Concept-Based Searching |
| + !!! Intended audience |
| + This document is intended for __SEEK and Kepler developers__. |
| + |
| + It is a __DRAFT DESIGN DOCUMENT__ and does not reflect functionality as it |
| + currently exists in Kepler or SEEK. Comments and feedback are appreciated. |
| Line 3 was replaced by line 7 |
| - The following service interface performs simple concept-based searching of resources: |
| + !!! Overview |
| Line 5 was replaced by line 9 |
| - {{{AnnotationEngine: search( ConceptExpression, Set<ResourceType>, RemoteSearchFlag ) :: Set<ResourceID>}}} |
| + The following lists the semantic-mediation service interfaces: |
| Lines 7-11 were replaced by lines 11-82 |
| - This service takes the following three arguments: |
| - # a search expression represented as a description-logic concept expression; |
| - # a list of resource types (e.g., "actor", "dataset", etc.); and |
| - # 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. |
| + {{{ |
| + interface ISemanticMediation { |
| + |
| + Set<ResourceID> search( ConceptExpression, Set<ResourceType>, RemoteFlag ) |
| + |
| + Set<QueryResult> query( QueryExpression, RemoteFlag ) |
| + |
| + Boolean match( ResourceID, ConceptExpression, RemoteFlag ) |
| + |
| + Boolean compatible( ResourceID, Connection, ResourceID, StructTypeFlag, RemoteFlag ) |
| + |
| + Set<ResourceID> searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag ) |
| + |
| + Set<StructMapping> compose( ResourceID, Connection, ResourceID, RemoteFlag ) |
| + |
| + Set<StructMapping> merge( ResourceID, Connection, ResourceID, RemoteFlag ) |
| + |
| + ConceptExpression semanticTypeConcepts( ResourceID, String, RemoteFlag ) // for summarizing annotations |
| + |
| + } |
| + }}} |
| + |
| + The rest of this page describes each of these services and their dependencies. |
| + |
| + |
| + !!! {{Search}}: Simple Concept-Based Searching |
| + |
| + {{{Set<ResourceID> search( ConceptExpression, Set<ResourceType>, RemoteFlag )}}} |
| + |
| + The arguments for this service are: |
| + # A search term represented as a description-logic concept expression; |
| + # A set of resource types, e.g., "actor" and/or "dataset"; and |
| + # A flag denoting whether local or remote repositories are searched |
| + |
| + The service returns a set of resources (as LSIDs) that have semantic types "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: |
| + {{{ |
| + ResourceType getResourceType( ResourceID ) |
| + |
| + Set<SemanticTypeID> getSemanticAnnotations( RemoteSearchFlag ) |
| + |
| + Set<Ontology> getOntology( OntologyID ) |
| + }}} |
| + |
| + The first operation returns the resource type of a given resource identifier (an LSID). The second operation returns the set of semantic types known to the kepler object manager (including semantic types 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). Note that this last operation could be used with an ontology service, e.g., the simple one described at the end of this page[simple ontology service|1]. |
| + |
| + !! Optimized Remote Searching |
| + |
| + In general, the {{search}} operation requires access to all semantic types 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 semantic types 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 a semantic type that states only {{A}} may be in one repository, while a semantic type that states only {{B}} may be in another. Thus, for remote searches, the {{search}} algorithm must obtain and consider all remote semantic types 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: |
| + |
| + {{{ |
| + Set<RepositoryID> getRepositories() |
| + |
| + Set<ResourceID> getResources( RepositoryID, Set<ResourceType> ) |
| + |
| + Set<ConceptExpression> partialSearch( RepositoryID, ConceptExpression, ResourceID ) |
| + }}} |
| + |
| + 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 |
| + |
| + {{{ |
| + Set<QueryResult> query( QueryExpression, RemoteFlag ) |
| + }}} |
| + |
| Removed line 13 |
| - 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). |
| Line 15 was replaced by lines 85-119 |
| - The search operation requires the following kepler object manager services: |
| + |
| + !!!{{Match}}: Checking Matching Resources |
| + |
| + {{{ |
| + Boolean match( ConceptExpression, ResourceID, RemoteFlag ) |
| + }}} |
| + |
| + |
| + The arguments for this service are: |
| + # A resource whose semantic types are to be checked; |
| + # A concept expression; and |
| + # A flag denoting whether local or remote repositories are searched |
| + |
| + The service returns true if the resource has a semantic type matching the concept expression. Note that given a set of resources {{R}} returned by the {{search}} service for a concept expression {{c}} and remote flag value {{m}} (either true or false), for each {{r}} in {{R}}, {{match(r, c, m)}} is true. That is, {{r}} is a {{match}} for search {{c}}. |
| + |
| + The {{match}} service is included primarily to support browsing of ontologies. |
| + |
| + |
| + !!! {{Compatible}}: Checking Semantically Well-Formed Connections |
| + |
| + {{{ |
| + Boolean compatible( ResourceID, Connection, ResourceID, StructTypeFlag, RemoteFlag ) |
| + }}} |
| + |
| + |
| + |
| + !!! {{SearchCompatible}}: Searching for Semantically Well-Formed Connections |
| + |
| + {{{ |
| + Set<ResourceID> searchCompatible( ResourceID, Port, StructTypeFlag, RemoteFlag ) |
| + }}} |
| + |
| + |
| + !!! {{Compose}}: Suggesting Well-Structured Actor Connections |
| + |
| Lines 17-19 were replaced by line 121 |
| - KeplerObjectManager: ResourceType getResourceType( ResourceID ) |
| - KeplerObjectManager: Set<SemanticAnnotationID> getSemanticAnnotations( RemoteSearchFlag ) |
| - KeplerObjectManager: Set<Ontology> getOntology( OntologyID ) |
| + Set<StructMapping> compose( ResourceID, Connection, ResourceID, RemoteFlag ) |
| Line 22 was replaced by lines 124-128 |
| - 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). |
| + !!! {{Merge}}: Suggesting Simple Merging of Heterogeneous Datasets |
| + |
| + {{{ |
| + Set<StructMapping> merge( ResourceID, Connection, ResourceID, RemoteFlag ) |
| + }}} |
| Removed line 24 |
| - 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. |
| Line 26 was replaced by line 131 |
| - 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: |
| + !!! {{SemanticType}}: Summarizing Semantic Annotations |
| Lines 29-31 were replaced by line 134 |
| - AnnotationEngine: ConceptExpression getSemanticType( OntoSearchIndex, ResourceID ) |
| - AnnotationEngine: Set<ResourceID> getResourceIDs( OntoSearchIndex ) |
| - AnnotationEngine: ResourceType getResourceType( OntoSearchIndex, ResourceID ) |
| + ConceptExpression semanticType( ResourceID, String, RemoteFlag ) |
| Line 34 was replaced by lines 137-153 |
| - 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 |
| + |
| + !!! A Simple Ontology Interface |
| + |
| + [simple ontology interface|#1] |
| + |
| + {{{ |
| + interface ISimpleOntologyAccess { |
| + |
| + Set<ConceptID> getConcepts( OntologyID ) |
| + |
| + Set<RoleID> getRoles( OntologyID ) :: Set<RoleID> |
| + |
| + Set<ConceptID> getMatchingConcepts( OntologyID, String ) |
| + |
| + Set<ConceptID> getMatchingRoles( OntologyID, String ) |
| + |
| + Set<ConceptID> getSubConcepts( OntologyID, ConceptID, DirectFlag ) |
| At line 35 added 10 lines. |
| + Set<ConceptID> getSuperConcepts( OntologyID, ConceptID, DirectFlag ) |
| + |
| + Set<RoleID> getSubRoles( OntologyID, RoleID, DirectFlag ) |
| + |
| + Set<RoleID> getSuperRoles( OntologyID, RoleID, DirectFlag ) |
| + |
| + Booolean satisfies( ConceptExpression, ConceptExpression ) |
| + |
| + } |
| + }}} |
| Line 37 was replaced by line 166 |
| - Here a semantic type is a concept expression generated from a semantic annotation. Providing and index over a resource's |
| + !!! Comments |
