| Line 1 was replaced by lines 1-5 |
| - !! Overview |
| + !!! 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 lists the semantic mediation service interfaces: |
| + !!! Overview |
| At line 4 added 2 lines. |
| + The following lists the semantic-mediation service interfaces: |
| + |
| Line 8 was replaced by lines 14-22 |
| - search( ConceptExpression, Set<ResourceType>, RemoteSearchFlag ) :: Set<ResourceID> |
| + 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 ) |
| Line 10 was replaced by line 24 |
| - query( QueryExpression, RemoteSearchFlag ) :: Set<QueryResult> |
| + Set<StructMapping> compose( ResourceID, Connection, ResourceID, RemoteFlag ) |
| At line 11 added 4 lines. |
| + Set<StructMapping> merge( ResourceID, Connection, ResourceID, RemoteFlag ) |
| + |
| + ConceptExpression semanticTypeConcepts( ResourceID, String, RemoteFlag ) // for summarizing annotations |
| + |
| Line 18 was replaced by line 36 |
| - !! {{Search}}: Simple Concept-Based Searching |
| + !!! {{Search}}: Simple Concept-Based Searching |
| Line 20 was replaced by line 38 |
| - {{{search( ConceptExpression, Set<ResourceType>, RemoteSearchFlag ) :: Set<ResourceID>}}} |
| + {{{Set<ResourceID> search( ConceptExpression, Set<ResourceType>, RemoteFlag )}}} |
| Removed line 26 |
| - The service returns a set of resources (as LSIDs) that have semantic annotations "matching" the given search term. |
| At line 27 added 2 lines. |
| + The service returns a set of resources (as LSIDs) that have semantic types "matching" the given search term. |
| + |
| Line 32 was replaced by line 51 |
| - getResourceType( ResourceID ) :: ResourceType |
| + ResourceType getResourceType( ResourceID ) |
| Line 34 was replaced by line 53 |
| - getSemanticAnnotations( RemoteSearchFlag ) :: Set<SemanticAnnotationID> |
| + Set<SemanticTypeID> getSemanticAnnotations( RemoteSearchFlag ) |
| Line 36 was replaced by line 55 |
| - getOntology( OntologyID ) :: Set<Ontology> |
| + Set<Ontology> getOntology( OntologyID ) |
| Line 39 was replaced by line 58 |
| - 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). |
| + 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]. |
| Line 41 was replaced by line 60 |
| - ! Optimized Remote Searching |
| + !! Optimized Remote Searching |
| Line 43 was replaced by line 62 |
| - 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 gather and consider all remote annotations to find matching resources. The {{search}} operation is inherently centralized because of this situation. |
| + 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. |
| Line 48 was replaced by lines 67-128 |
| - getRepositories() :: Set<RepositoryID> |
| + 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 ) |
| + }}} |
| + |
| + |
| + |
| + |
| + !!!{{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 |
| + |
| + {{{ |
| + Set<StructMapping> compose( ResourceID, Connection, ResourceID, RemoteFlag ) |
| + }}} |
| + |
| + !!! {{Merge}}: Suggesting Simple Merging of Heterogeneous Datasets |
| + |
| + {{{ |
| + Set<StructMapping> merge( ResourceID, Connection, ResourceID, RemoteFlag ) |
| + }}} |
| Removed line 50 |
| - getResources( RepositoryID, Set<ResourceType> ) :: Set<ResourceID> |
| Line 52 was replaced by lines 131-134 |
| - partialSearch( RepositoryID, ConceptExpression, ResourceID ) :: Set<ConceptExpression> |
| + !!! {{SemanticType}}: Summarizing Semantic Annotations |
| + |
| + {{{ |
| + ConceptExpression semanticType( ResourceID, String, RemoteFlag ) |
| Removed line 55 |
| - Using these operations, the {{search}} algorithm would procede as follows, assuming that the remote search 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. |
| At line 56 added 1 line. |
| + !!! A Simple Ontology Interface |
| Line 58 was replaced by line 140 |
| - !! {{Query}}: Complex Concept-Based Searching |
| + [simple ontology interface|#1] |
| Line 61 was replaced by lines 143-163 |
| - query( QueryExpression, RemoteSearchFlag ) :: Set<QueryResult> |
| + 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 ) |
| + |
| + Set<ConceptID> getSuperConcepts( OntologyID, ConceptID, DirectFlag ) |
| + |
| + Set<RoleID> getSubRoles( OntologyID, RoleID, DirectFlag ) |
| + |
| + Set<RoleID> getSuperRoles( OntologyID, RoleID, DirectFlag ) |
| + |
| + Booolean satisfies( ConceptExpression, ConceptExpression ) |
| + |
| + } |
| At line 62 added 2 lines. |
| + |
| + !!! Comments |
